Subject: RE: [SPIRITS] Representing non-call related events

From: "CHATRAS Bruno FTRD/DAC/ISS" <[email-masked]>
Date: Wed, 5 Feb 2003 10:41:25 +0100

Some thoughts about the CUSF!

Three modes of operations have been defined for the CUSF (See ITU
Q.1238.7):

1) For relaying ROSE APDUs to/from an ISDN terminal

2) For triggering an IN service during the execution of a non-call
related supplementary service (e.g.; CCBS)

3) For relaying USI information to/from an ISDN terminal

Only the first two modes seem to be relevant for this discussion. On
both cases, a BCUSM - which includes a few DPs - is involved. The main
difference between the two options is the location of the supplementary
service execution. In the first case, the supplementary service is
executed in the SCF, the CUSF acts almost as a transparent relay. In the
second case, the supplementary service is executed by the switch. The
CUSF is used to enable an IN service to incluence the processing of the
supplementary service (e.g.; modify the called party number in a
CCBS-Request), just like the SSF does in a call related context.

The first option is not appropriate for SMS or Mobility Management are
these "services" - unlike ISDN supplementary services - are generally
not implemented using ROSE. The second option would make sense. However,
this would require extensions to the protocol as the INAP operations
used by the CUSF (e.g.; EventReportBCUSM)do not include SMS or
MM-related parameters. 

It is interesting  to note that GSM/UMTS standards do not use of the
CUSF for SMS. They use a dedicated state model, with SMS-specific DPs.
The INAP operations are not those defined for the CUSF but are also
specific to the SMS service.

I hope this helps.

Bruno

> -----Message d'origine-----
> De : Vijay K. Gurbani [mailto:[email-masked]]
> Envoye : mardi 4 fevrier 2003 18:49
> A : Vijay K. Gurbani
> Cc : SPIRITS list
> Objet : Re: [SPIRITS] Representing non-call related events
> 
> 
> Folks:
> 
> Regarding the discussion below, it was suggested to me in a private
> email that the CUSF functional entity of IN-CS2 be looked into.
> 
> Is there anyone on the list familiar with this and willing to pitch
> in some time?  Any discussion (and help) will be extremely fruitful, I
> think...
> 
> Thanks,
> 
> - vijay
> 
> Vijay K. Gurbani wrote:
> > Folks:
> > 
> > I want to start a discussion about how to best represent non-call
> > related events in the SPIRITS XML payload.
> > 
> > Non-call related events include those concerned with mobility,
> > location, SMS, etc.  Note that no DP is involved here; in fact,
> > SPIRITS has a Event token called 'spirits-user-prof' for these
> > types of events.
> > 
> > One way to represent these events to have a specific element
> > called <SUP> for such SUPplementary services.  Thus, in order
> > to transform a SMS into an IM, the SUBSCRIBE payload could
> > conceivably contain:
> > 
> >     <spirits-event>
> >          <SUP app="SMS"/>
> >          <Mode>Notify</Mode>
> >          
> <CallingPartySubaddress>16302240216</CallingPartySubaddress>
> >     </spirits-event>
> > 
> > However, that puts us in the dubious position of specifying all
> > the possible supplementary services in SPIRITS -- which is
> > definitely NOT what we want to do.  One way to combat that problem
> > is to say that the value of "app" attribute is a token, the details
> > and semantics of which are dependent on the token.
> > 
> > How do we handle location?  Maybe we can scour geopriv for some
> > answers (see
> > 
http://www.ietf.org/internet-drafts/draft-daviel-html-geo-tag-05.txt)
> as well as Daniel Moreno's draft on mobility events management
>
(http://www.ietf.org/internet-drafts/draft-ietf-spirits-mobility-00.txt)
> 
> Any other ideas?  Any thoughts would be appreciated.
> 
> Thanks,
> 
> - vijay

-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Wireless Networks Group/Internet Software and Services
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216

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