Subject: Re: [SPIRITS] More on SPIRITS requirements

From: [email-masked]
Date: Fri, 8 Sep 2000 10:26:55 +0200

Hi Jane,

Thanks a lot for the comments. I think they are very useful to clarify
many things.

Let me try to clarify as much as I can. I will mark my comments with **JG.

Please, feel free to send as many additional comments you may have.

Regards,

Jorge Gató
Airtel Móvil

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

**JG Igor has already clarified this. With SMS I did not mean GSM Short
Message
Service, but Service Management System. This is a name used to refer to the
physical implementation of the Service Management Function (SMF) from IN
ITU-T
standards (Q.12XX).
I apologyse for the confusion this has caused. I do not like using to many
acronyms either (believe it or not)!**JG

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

**JG If we base SPIRITS on the benchmark services, nothing from CAMEL is
needed. Thinking about CAMEL is to prepare SPIRITS for future services for
mobile users.
You are right that CAMEL can refer to "circuit" subscribers and "packet"
subscribers (GPRS). I was only thinking about "circuit" subscribers, since
they are like "moving PSTN subscribers".
I must recognise I have not though a lot of specific service scenarios.
The only ones I have considered so far is replacing a fixed PSTN subscriber
with a mobile subscriber in the benchmark services**JG

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

**JG Yes, you are totally right.**JG

  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

**JG Again, you are right.**JG

  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

**JG Yes, I did not explain myself very well. What I meant is that the
basic
call (although based on a subscription mark in the HLR O-CSI, T-CSI, etc.)
they
refer to Detection Points (DPs) which can be mapped to the Basic Call State
Models (BCSMs) used for PSTN. However, for Mobility Management this is not
the case (we can say that they are call unrelated).
In regards to the difference between MAP and INAP, I do not think this
should
matter for SPIRITS. In the scenarios we are talking about, both are used to
access the SCP to trigger a service action.
I agree this can affect the SPIRITS architecture and some work would be
needed
there (minor clarification could be enough).**JG

  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

**JG You have explained very well how the Mobility Management triggers
work. I
do not see a difference between setting the M-CSI from a CAMEL Operations
Centre
than from a SPRITS service node. In both cases, the HLR should notify the
VLR
of the new subscriber profile (if I remeber well an InsertSubscriberData
MAP
operation should be sent from the HLR to the VLR).
The service scenario that I see is integrating mobility and location into
SPIRITS service. For example, for Internet Call Waiting, the treatment of
an
incoming call could be "send to my mobile if attached, otherwise take the
call
and release the internet session".**JG

    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

**JG Correct.**JG

  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

**JG You are right. I only meant "circuit" subscribers. I do not think that
even
SPIRITS apply to "packet" subscribers.

  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

**JG Correct.**JG

"End of email extract.

Regards

Jane Humphrey
Marconi Communications

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