Subject: Re: [SIP] geographical location

From: <[email-masked]>
Date: Fri, 23 Feb 2001 11:29:07 +0100

Well, it is a long time since i do not follow SIP drafts, so maybe i am
talking about something already defined. Sorry if so.

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

-----------------------------< O >-----------------------------------
Javier Ferreiro Garcia
Telefonica Moviles Spain
Consultant
Dpto. de Desarrollo de Mercado
Voice Services Unit
    Telf.: +34 630 00 43 13
-----------------------------< O >-----------------------------------

>I will be sending out a brief note on this topic early next week.
>However, you're probably looking at extensions of the presence format,
>rather than a SIP extension.

>Janak Mehta wrote:
>>
>> Hi,
>>
>> I'm extending SIP to provide geographical location of the mobile
>> host within Wireless LAN. Basically I'm trying to send geographical
>> location with presence information like "Online/Offline/Away" through
>> NOTIFY method to subscriber of that particular presentity.
>>
>> I want to update(NOTIFY) all the subscibers of the particular presentity
>> when that presentity moves within campus.
>>
>> Is there any defined header in sip through which I can send geo-
>> graphical location in NOTIFY method?
>>
>> Can someone send me some pointers if work is already been done?
>>
>> Thanks,
>> Janak
>>
>> --------------------------------------------
>> Janak S. Mehta
>> Information Networking Institute
>> Carnegie Mellon University
>> Hamburg Hall, Room No A020,
>> 4800 Forbes Avenue,
>> Pittsburgh, PA 15213.
>>

_______________________________________________
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.

_______________________________________________
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: Jerome Privat <[email-masked]>
Date: Fri, 23 Feb 2001 19:05:41 +0100

I think that Lawrence is on target when mentioning LCS.

I think we need to distinguish two different functions in LCS:
- how the location information is conveyed to the LCS server (what you
discussed in your email)
- how a LCS client subscribes to this LCS server and how it receives
answers.

IMHO, this second function could be nicely implemented using the
SUBSCRIBE/NOTIFY methods. This way, location infomation could be combined
with presence information and allow some new interesting services...

Jerome

-----Original Message-----
From: Lawrence Conroy [mailto:[email-masked]]
Sent: Friday, February 23, 2001 2:27 PM
To: [email-masked]
Subject: Re: [SIP] geographical location

>time to see CAMEL Phase 3 running
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? |

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 25 Feb 2001 22:56:38 -0500

> From: Jerome Privat [mailto:[email-masked]]
> Sent: Friday, February 23, 2001 1:06 PM
> To: 'Lawrence Conroy'; [email-masked]
> Subject: RE: [SIP] geographical location
> 
> 

There are three things, in fact.

Publication: whereby information about a presentity is sent to the presence
server for the presentity.

Subscription: whereby users in the network can request changes in
information about presence state of a presentity.

Notification: whereby subscribers are told by the presence server about
changes in presence state.

Particularly, note that publication and notification are different. In sip
for presence, REGISTER plays the role of a possible publication mechanism.
There are many others, and I think future communications systems will
involve presence coming from many disparate devices, through many different
protocols. As a result, a presence server will speak many languages in order
to collect the sum total presence information for a presentity.

Note also that it is inherent to the model, and even with SIP REGISTER, that
third parties can publish information for a presentity (specifically, the
From field of a REGISTER need not match the To field). 

So, I won't pretend to understand which device in the 3gpp architecture is
ideally suited to know the location of the mobile. But, once you figure it
out (and it could be more than one), those devices would publish presence
information to the presence server, possibly with REGISTER if its
convenient, or possibly with something else altogether. Then, this
information is included in the NOTIFYs generated by the presence server.
This requires fields added to the presence document format for location
information.

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: <[email-masked]>
Date: Mon, 26 Feb 2001 13:20:04 +0100

Hi, Lawrence, thank you
some comments below

-----Original Message-----
From: Lawrence Conroy [mailto:[email-masked]]
Sent: Friday, February 23, 2001 2:27 PM
To: [email-masked]
Subject: Re: [SIP] geographical location

>a form that is of any use to anyone (i.e. not a Cell Global Id)*

Well, as it happens now with location based services in GSM every CellID
needs to be mapped on the geographical position of the antenna covering
that Cell, as I mentioned it is a 'kind of' location information, the only
one currently used so far by cellular operators. I agree with you that if
this information is to be delivered to third parties it must be translated
before, i.e. a server in the network should translate it into Latitude,
Longitude, Altitude, Degree of Error. I´ve just read a few documents
covering LCS a couple of years ago, and if I understood it properly, one of
the location methods proposed needed a GPS-capable terminal, that, for
"real" time bahaviour, should be "assisted", i.e. need an interaction with
a server placed in the network which helps with positioning the satellites
and saves some time in the process. There was two more methods which
offered triangulation processes, but it seems you are used to work with LCS
and know the current status of that architecture. What I am not sure is if
LCS provides real-time information, which is needed in some scenarios. I
wanted to focus also the posibility to define triggers in the network
(CAMEL categories) to propagate location information to 3rd parties
whenever this location info. related to a particular subscriber changes. I
think this approach is more elegant than a continuous polling from the 3rd
party to the subscriber, and it is also more similar to the
SUBSCRIBE/NOTIFY model discussed here. Anyway CAMEL Phase 3 and LCS both
have pros and cons, and it will take some time to see both of them in real
networks.

What I wanted to point out is the UA will handle the Cell Global Id, and it
is already available  and it is included in the signalling messages (i.e.
IAM) that supports the ISUP based session stablishment. It is real-time,
call-related, currently available, and it is better than nothing :)

>I'm not sure how this fits into a SIP "end-to-end" architecture.

You are right, if a translation is needed, it doesn't fit in the SIP
"end-to-end" architecture. Neither assisted GPS nor network-based
triangulation methods fit in a "end-to-end" architecture.

>We seem to need not only a new header (with data in a form that's usable),

The location information handled by a terminal is provided by the network
in most of the cases, i.e. the terminal handles measurements related to the
radio subsystem, which are converted into location information. The only
scenario I know (i´m not an expert) with no interaction with the cellular
network is pure GPS, which do not provide real-time performance. Take into
account that GPS does not interact with the cellular network but with a
satellite network, which acts as a "server" providing some sort of
information to the GPS "client" . So, a "pure-end-to-end" solution for
location seems to me impossible, you need to trust on a server (let´s call
it CAMEL CSE, LCS, GPS satellite, or whatever suits your needs better)
regards
Javier F.

--