Subject: [SPIRITS] Daniel Moreno's I-D on Mobility Management

From: Alec Brusilovsky <[email-masked]>
Date: Thu, 25 Apr 2002 13:35:46 -0500

Ladies and Gentlemen,

Please take a look at the new I-D "Mobility Events Management in 
SPIRITS" that was posted by Daniel Moreno and is available from:
http://www.ietf.org/internet-drafts/draft-moreno-mobility-events-00.txt

This I-D describes in detail mobility events as per SPIRITS Architecture 
and SPIRITS Protocol Requirements.

Kind regards,
Alec

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

---

From: "Unmehopa, Musa (Musa)" <[email-masked]>
Date: Fri, 26 Apr 2002 10:53:42 +0200

Daniel,

Thank you very much for authoring and posting the mobility events I-D. It provided a very interesting read. This is very useful in proceeding towards the completion of the SPIRITS protocol. I went through your document and have a couple of questions.

I studied your DTDs and used 3G TS 29.002 as a reference. This specification contains the definition of the NoteMM-Event MAP operation from the VLR to the gsmSCF.

I have some questions regarding some of the element definitions in your DTDs:

MM_event_notify:
================
Why did you not include the ServiceKey? Wouldn't this be useful to identify the specific application at the SPIRITS Server? For instance, in <draft-ietf-spirits-in-01.txt> section B.3.34 ServiceAddressInformation, defining SP_INAP_SAI.DTD, the ServiceKey is included.

LocationInformation:
====================
I notice that you did not include VLR-number and MSC-number, althoug these are included in 3G TS 29.002 in the definition of LocationInformation. Was there any specific rationale for omitting these? Are these deemed insufficiently accurate?

LSAIdentity:
============
As comment you state that the content is undefined, whreas in your main body of text you list 3G TS 23.073 as a reference.

GeodeticInformation:
====================
Why did you specify this as a #PCDATA element? You did decide to detail out the definition of GeographicalInformation. Should these two definitions not be brought in line for consistency?

E.g.

   <!--
   ************************************************
   ELEMENT: GeodeticInformation
   COMMENT: This information element corresponds to
   the Calling Geodetic Location defined in ITU-T
   Q.763
   ************************************************
   -->
   <!ELEMENT GeodeticInformation (ScreeningInd,
   TypeOfShape, LAT, LON, Confidence)  >

GeographicalInformation:
========================
The Sign of Latitude bit in 3G TS 29.002 is only defined as part of the ellipsoid point definition. What is the rationale for introducing it at the top level of this element definition?

CellIdOrLAI:
============
In 3G TS 29.002 this field is called cellGlobalIdOrServiceAreaIdOrLAI. What was the rationale for just using CellIdOrLAI?

Basic_MSISDN:
=============
Can the address definition from <draft-ietf-spirits-in-01.txt>, section E.4.9 ADDRESS (SPIRITS_ADR.DTD) be used for this definition? This way we can reuse existing data definitions.

Thank you and kind regards,
Musa

> -----Original Message-----
> From: Alec Brusilovsky [mailto:[email-masked]]
> Sent: Thursday, April 25, 2002 20:36
> To: SPIRITS list
> Subject: [SPIRITS] Daniel Moreno's I-D on Mobility Management
> 
> 
> Ladies and Gentlemen,
> 

Kind regards,
Alec

---

From: [email-masked]
Date: Tue, 30 Apr 2002 10:17:28 +0200

Musa,
Thanks for taking some time to read the mobility events I-D. I'll try to answer all your
questions/suggestions in the same order you wrote them:

MM_event_notify:
================
I didn't consider the inclusion of Service Key parameter because I thought it was more useful in
environments where several network nodes can trigger different services in the gsmSCF, even from
external network nodes, without much more information about the triggering origin. I thought that
SPIRITS server wouldn't require so much complexity, as the SPIRITS server can identify every spirits
client that is notifying an event. Anyway, it could be included in the mobility management
parameters in order to tie in with <draft-ietf-spirits-in-01.txt>, and to prevent possible
restrictions in future implementations.

LocationInformation:
====================
I think that these two elements wouldn't add any useful information, as they are used for routing
to/from other network nodes (even to other external networks), but they don't provide real location
information. These parameters are set by each network operator following internal rules for routing,
with no information about physical location. What the SPIRITS server would receive in these two
elements would be a Global Title parameter or a combination of Destination Point Code + Sub-System
Number identifying the VLR/MSC.

LSAIdentity:
============
As far as I know, this parameter is coded in different ways by network operators, depending on their
service areas distribution. If the SPIRITS server doesn't know each operator's definition this
element won't be useful.

GeodeticInformation:
====================
You are absolutely right. I was not able to get a complete definition list for each of its
parameters, so I decided to leave its DTD definition open. We can use the one you suggested.

GeographicalInformation:
========================
I decided not to create too many sub-elements, so that's why I included all the geographical
information elements into the same level. But your point of view is OK, so I can change it too.

CellIdOrLAI:
============
I chose a shorter name for this parameter, but I'm not restricting the use of Service Area ID. I
think it can be used as a valid value too. By the way, in some networks, Service Areas and Location
Areas have the same ID values.

Basic_MSISDN:
=============
Yes. I agree with you that ADDRESS parameter can be reused for this definition.

Kind regards,
Daniel.

jgato
26/04/2002 14:33
Asunto:   RE: [SPIRITS] Daniel Moreno's I-D on Mobility Management

Daniel,

Por si no te ha llegado.

Saludos,

Jorge

---------------------- Remitido por jgato/AIRTEL con fecha 26/04/2002 14:32
---------------------------

"Unmehopa, Musa (Musa)" <[email-masked]>@lists.bell-labs.com con fecha 26/04/2002 10:53:42

Enviado por:   [email-masked]

Asunto:   RE: [SPIRITS] Daniel Moreno's I-D on Mobility Management

Daniel,

Thank you very much for authoring and posting the mobility events I-D. It provided a very
interesting read. This is very useful in proceeding towards the completion of the SPIRITS protocol.
I went through your document and have a couple of questions.

I studied your DTDs and used 3G TS 29.002 as a reference. This specification contains the definition
of the NoteMM-Event MAP operation from the VLR to the gsmSCF.

MM_event_notify:
================
Why did you not include the ServiceKey? Wouldn't this be useful to identify the specific application
at the SPIRITS Server? For instance, in <draft-ietf-spirits-in-01.txt> section B.3.34
ServiceAddressInformation, defining SP_INAP_SAI.DTD, the ServiceKey is included.

LocationInformation:
====================
I notice that you did not include VLR-number and MSC-number, althoug these are included in 3G TS
29.002 in the definition of LocationInformation. Was there any specific rationale for omitting
these? Are these deemed insufficiently accurate?

LSAIdentity:
============
As comment you state that the content is undefined, whreas in your main body of text you list 3G TS
23.073 as a reference.

GeodeticInformation:
====================
Why did you specify this as a #PCDATA element? You did decide to detail out the definition of
GeographicalInformation. Should these two definitions not be brought in line for consistency?

E.g.

   <!--

GeographicalInformation:
========================
The Sign of Latitude bit in 3G TS 29.002 is only defined as part of the ellipsoid point definition.
What is the rationale for introducing it at the top level of this element definition?

CellIdOrLAI:
============
In 3G TS 29.002 this field is called cellGlobalIdOrServiceAreaIdOrLAI. What was the rationale for
just using CellIdOrLAI?

Basic_MSISDN:
=============
Can the address definition from <draft-ietf-spirits-in-01.txt>, section E.4.9 ADDRESS
(SPIRITS_ADR.DTD) be used for this definition? This way we can reuse existing data definitions.

Kind regards,
Alec