Subject: Re: [SPIRITS] More on SPIRITS requirements

From: "Jane Humphrey" <[email-masked]>
Date: Thu, 7 Sep 2000 23:53:57 +0100

Jorge,

I have a few comments and clarifications to add to your email, I have marked
these with **JH in the text below (which is an extract from your orginal email):

Extract of email begins "

1) TDPs setting (Igor's question).

According to the ITU-T standards, the SMS could be used to set the desired
TDPs in the
SSPs.  However, the SMSs from some suppliers are not able to do so. In some
cases an access
to the SSP is done via a different nodes (e.g. used for operation and
maintenance of the switch).

**JH Could you please explain the first sentence, what you mean by the ITU-T
standards (which ones?) and the Short Message Service being used to set
triggers.  First, why and second, which types of SMS, orginating or terminating
or both?  Third, what is the service we are trying to achieve here and finally
what are the restrictions to which you refer?  I am assuming you mean the GSM
SMS.  Unfortunately I did not receive the email from Igor that was dated 29th
July so the context of your response to the questions from Igor is not clear to
me.**JH

I think we should let this as an implementation option.

The requirement is that there exists a way to set the desired TDP in the
correct SSF(s). This should
be preferrably started from the SPIRITS Server (e.g. when the subscriber
activates ICW
subscription).

2) CAMEL DPs in SPIRITS (Igor's suggestion).

I am not sure if we should add CAMEL DPs in the SPIRITS requirements.

**JH I tend to agree with your comment my reasoning being that from the
perspective of voice calls the DPs are just a subset of the ETSI Core INAP CS3
(as you are referring to CAMEL Phase 3 features).  [Note that CAMEL does not use
the DP specific approach but DP generic].  From the SPIRITS perspective, what
service scenarios are being considered??  Is the CAMEL subscriber the SPIRITS
served "user" and where is the CAMEL subscriber located, only in the PSTN?**JH

In CAMEL phase 3, several types of "calls" are covered:

  a) Voice Calls. In this case no new DP is needed since CAMEL DPs are
included in CS2. The only
  special case is the "Not Reachable" case which is mapped as a special
cause in the Busy DP.
  Since we would receive the Busy DP parameters (if a SPIRITS service has
subscribed to Busy),
  we would be able to distinguish a busy from a not reachable situation .

  b) USSD. This is not a PSTN call so it does not apply to SPIRITS.

**JH Just a minor point, the interaction between the SCP and HLR is not IN but
MAP (Mobile Application Part) and the USSD interaction in non call related **JH

  c) GPRS. Same comment.

  d) SMS. Same comment.

**JH Just a minor point, CAMEL Phase 3 only supports triggering for Mobile
Originated SMS, the terminating case will not be supported until the next Phase
of CAMEL.  Also, the SMS can be either via GPRS switched (in which case the
triggering will be located in the SGSN) or MSC Switched (in which case the
triggering will located in the MSC/VLR). **JH

  e) Mobility Management.

  This could allow a SPIRITS server to be notified in changed of location
of a mobile user. However,
  triggering of these type of services is not based on DPs, but in a
subscription mark in the HLR.

**JH  Just a clarification to the above statement, the use of subscription
information in the HLR for triggering CAMEL services is not just restricted to
Mobility Management but all types of "calls" listed above  [Note that the HLR
does not support an IN interface - does this matter for SPIRITS??]**JH

  Adding this to SPIRITS, means:

    i) Adding a requirement to allow setting subscription marks in the
subscriber's HLR. This is
    equivalent to setting TDPs in the SSP (but in this case M-CSI is set in
the HLR).

**JH  I think this is an over simplification.  The HLR is not the SSP, it is the
MSC/VLR  which acts on this subscription information.  These "triggers" are set
by the HLR downloading the Camel Subscription information to the VLR on change
of location, etc.  In the case of Mobility Management, the changing of the M-CSI
in the HLR achieves nothing until the new M-CSI is downloaded to the VLR  where
the triggering will actually occur.  The notifications are sent to the gsmSCF by
the VLR using the MAP protocol and not IN operations.  How do you envisage this
mechanism working in the Spirits environment and what sort of service scenario
are you thinking of??  **JH

    ii) Mapping the CAMEL specific operations into events notification to
the SPIRITS client. Since
    the SCP receives the information about the mobility state, this
involves the C interface (is just
    an extension of the DP notification).

**JH  As stated above the operations are MAP not IN **JH

  I think this is useful for mobile networks and should be added to the
requirements. What do you
  think ?.

  The events (not DPs!) which could be notified are:

  - Location Update in the same VLR service area.
  - Location Update in another VLR service area.
  - IMSI attach.
  - MS initiated IMSI detach.
  - Network initiated IMSI detach.

**JH  How do you envisage this information being used?? I assume you are only
considering mobility of the user within the CS network but perhaps you could
clarify.  I do not believe that these mobility events will have meaning in an IP
domain. **JH

  f) Supplementary Services Notification.

  This mechanism could allow a SPIRITS server to be aware of a subscriber
having invoked one
  of the following supplementary services: Explicit Call Transfer, Call
Deflection, Call Completion
  on Busy Subscriber or Multi-Party.

  It is also based on subscriptions marks in the HLR, but in this case I do
not think this information
  can be used for SPIRITS services.

**JH As with the Mobility Management these events are sent to the gsmSCF via the
MAP protocol from the MSC.  The IN protocol is not used.  **JH

"End of email extract.

Regards

Jane Humphrey
Marconi Communications

_______________________________________________
SPIRITS mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/spirits

---

From: Igor Faynberg <[email-masked]>
Date: Thu, 07 Sep 2000 19:59:28 -0400

Jane,

I believe the message Jorge referred to (anyway, it could be found on in the
archive) is the one in which I was ruminating on  setting DPs and mentioned
TDPs. According to the ITU-T IN standard, this is done by the SMF statically; in
the US Wireless IN standard, I understand it can be done dynamically. So, the
gist of Jorge's reply is that it should be left to implementation. I agree. What
that means is that SPIRITS (or, rather PINT, to be more precise) protocol will
NOT postulate setting TDPs via SPIRITS client/PINT server.

I hope this answers some of your questions. As for the usage of "SMS," I am
absolutely sure Jorge uses it for Service Management System not "Short Message
Service."  Mea culpa: I suspect it was I who set the precedence in SPIRITS for
this usage, which is wide-spread in the US OSS parlance. So SMS is really what
Q.12x4 calls "SMF" (or Q.12x5, "SMP"). Now I think everything is clear.

What is interesting is that the acronyms have become so overloaded ("What is
IP--Internet Protocol or Intelligent Peripheral?" I was recently asked by a
technical editor looking at a PINT picture in which  IP marked BOTH. ) that I
think we ought to use symbols rather than letter combinations. An ingenious
idea: we could use Chinese characters! 

Respectfully,

Igor

> Jorge,

...