Subject: Re: [SIP] geographical location

From: Lawrence Conroy <[email-masked]>
Date: Fri, 23 Feb 2001 13:26:42 +0000

Javier said:
>There are at least two features involved, one is a specific header for
>location information. It would be similar to GSM, which includes in every
>call establishment information related to the cell the call is "sent" from.
>It is a sort of location information, and currently most of the
>call-related location services are based on this cell-info. I presume
>probably 3GPP would require a SIP specific header for this purpose , also.
>
>The second feature is how to handle the delivery of "location change" in a
>not-call related basis. This problem (and also the presence information
>delivery) will be faced by CAMEL Phase 3 (see 3GPP TS 23.078) by defining a
>subscriber category (M-CSI) which is stored in the user profile in HLR and
>also in the visited MSC-VLR. This category includes different triggers,
>such as
>* Location update in the same VLR service area
>* Location update in another VLR service area
>* IMSI attach, i.e. 1st REGISTER from the UA)
>* MS initiated IMSI attach (explicit detach), i.e. un-REGISTER
>* Network initiated IMSI detach (implicit detach), i.e. the UA does not
>send another REGISTER in the specified time
>So it is the MSC-VLR (visited SIP server, I think) the one that generates
>such information from the one generated by the UA itself.
>Seems that your extension in the NOTIFY behaviour is a sort of Location
>update in the cellular environment. The difference is that in the cellular
>environment this Location Update procedure is standardised, but i am not
>sure your NOTIFY extension would be covered by all UAs. See also that CAMEL
>Phase 1 is the one currently deployed in GSM networks, so it will take some
>time to see CAMEL Phase 3 running
>
>hope this helps
>
To which I reply:
CAMEL is not alone; there is other work being developed in 3GPP that
isn't directly part of that particular "horse designed by a committee".

The LCS work is being done to design a system that provides location
info without being tied to the I.N./CAMEL system; the "location entities"
(GMLC, SMLC,...) are separate units. These may well need to be considered.

Also, as Keith commented, a "SIPish" architecture is being developed
in 3GPP; the MSC-VLR is not necessarily the same beast as a V-CSCF
(i.e. the first SIP proxy); it may well be the SMLC that generates the
data. How this fits with a SIP architecture is not yet clear.

I'm not sure that one can ASSUME that the UA knows where it is *in
a form that is of any use to anyone (i.e. not a Cell Global Id)*
As I understand it, for most of the LCS work, the current assumption
seems to be that the Network is most likely to calculate the position
of the Mobile User (i.e. the mobile user doesn't know where they are or
doesn't care to tell anyone the truth - a problem with E911).

I'm not sure how this fits into a SIP "end-to-end" architecture.
We seem to need not only a new header (with data in a form that's usable),
but also we need to decide who can put this data into the header. If it's
done by a proxy somewhere in the middle of the trail between end users,
this is ugly, IMHO.
-- 
All the best, Lawrence
-------------------------------------------------
| [email-masked]       |HomeGeo:50o55'15"N,1o24W|
|Personal Opinions only| ?Cell Colour Code = 3? |

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: hammer michael <[email-masked]>
Date: Fri, 23 Feb 2001 14:48:27 -0800

Lawrence,

We also need to keep in mind that there are two types of location:  logical 
and physical.  (At the end you seem to cross over from one type to the 
other.)  The former is location relative to the topology of the network; 
that is, I can route signaling and media to you, but you could be anywhere 
in the world.  The second is related to geographical location, ie Latitude, 
Longitude, Altitude, Degree of Error.  There may be little correlation of 
one to the other, so they may need to be handled independently.

Mike Hammer

At 01:26 PM 02/23/2001 +0000, Lawrence Conroy wrote:
>To subscribe to it, send mail to [email-masked] 
>with "subscribe" in the body.

---

From: Lawrence Conroy <[email-masked]>
Date: Sun, 25 Feb 2001 17:07:19 +0000

At 2:48 pm -0800 23/2/01, hammer michael wrote:
>We also need to keep in mind that there are two types of location: 
>logical and physical.  (At the end you seem to cross over from one 
>type to the other.)  The former is location relative to the topology 
>of the network; that is, I can route signaling and media to you, but 
>you could be anywhere in the world.  The second is related to 
>geographical location, ie Latitude, Longitude, Altitude, Degree of 
>Error.  There may be little correlation of one to the other, so they 
>may need to be handled independently.

To which I agree:
Good point; however, the current assumptions seem to be that routing 
to (and from) a mobile SUAS is done by the Mobile Network 
Infrastructure (using "MobileIP-ish" means for the plumbing, and 
using a V-CSCN as the "local" SIP entity).

The drafts on SIP mobility that were presented last year (i.e. 
mobility at the application layer) are still *very* FFS; the 
"mainline view" seems to be that the physical routing side of things 
*should* be hidden within the mobile network plumbing.
In terms of the SIP level, the mobile SUAS/user will probably have a 
"phone number" and use something like enum - yes, that *is* mentioned 
in 23.228 :).

Amusingly, the same discussions that entertained us in Adelaide in 
the SPATIAL BoF are still with us on end user location;
there's physical location and civil location, and either may be 
required for the recipient of the info. Where one translates from 
what one has (somewhere along the trail) into something that the 
recipient end user needs is a big question. For example, with some 
measurement techniques, you get the "Base station Colour Code", which 
is as much use a chocolate soldier in a fire to most entities; how 
and where this is converted is "an interesting question".

Finally, whether or not all of this needs any extension to SIP, 
rather than just a usage profile, is another good question; I for one 
await some concrete proposals with interest.
-- 
All the best, Lawrence
-------------------------------------------------
| [email-masked]       |HomeGeo:50o55'15"N,1o24W|
|Personal Opinions only| ?Cell Colour Code = 3? |

---

From: Jiri Kuthan <[email-masked]>
Date: Mon, 26 Feb 2001 02:05:33 +0100

Maybe I missed some substantial point but I do not
understand why users and their applications should
be willing to deal with some technology-dependent 
geographical format. I really cannot expect
a Web/SIP server to understand coordinations expressed
in a format used by my local wireless company.

Geographical coordinates (latitude, longitude, elevation
and precision) will not change. Technological coordinates
(my GSM cell id) or civil names ("Europe Blvd" formerly
"Lenin Blvd" formerly "Stalin Blvd" formerly "Hitler
Blvd" in the city where I was born.) will.

I'd really prefer conveying *geo-coordinates* in web/sip
requests, regardless how they were obtained, what their
original encoding was and what the application dealing with 
them is.

I do not think that they should be bound to a specific
request method (like previously SUB-NOT or REGISTER were 
mentioned.) Something like 
INVITE [email-masked]?latitutude=x;logitude=y;elevation=z 
would be useful as well.

Jiri