Subject: [SPIRITS] ID: SPIRITS Support for Location Services

From: "John A. Voelker" <[email-masked]>
Date: Tue, 28 Nov 2000 08:43:55 -0600

http://search.ietf.org/internet-drafts/draft-voelker-spirits-locationservice-00.txt

Spirits Working Group                                    J. Voelker 
Internet draft                                  Lucent Technologies
<draft-voelker-spirits-locationservice-00.txt>                          
Expires June 2001 

                  SPIRITS Support for Location Services 

Status of this Memo  

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.  

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material 
or to cite them other than as "work in progress."  

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.  

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.  

Abstract  

SPIRITS services are those originating in the PSTN and involving
interactions between the PSTN and the Internet.  This document describes
how SPIRITS supports those aspects of location services whereby the PSTN
wireless network provides location related events to internet
applications requesting them.  An example of such an event is a mobile
station entering a pre-specified geographic zone.  

1. Introduction   

SPIRITS [1] services are those originating in the PSTN and involving
interactions between the PSTN and the Internet. This document describes
how SPIRITS can support those aspects of location services whereby the
PSTN wireless network provides location related events; for example,
when a mobile station (MS - aka a cell phone) enters a pre-specified
geographic zone.   Because the PSTN tracks its MS customers in its
conventional role of delivering telephone calls, it can potentially

Voelker                      Internet Draft                   [Page 1]

Spirits Support for Location Services                Expires June 2001

leverage that capability to efficiently assist with certain aspects of
providing advanced location services. [2] also addresses the use of
SPIRITS/PINT for location. 

2. Location Services  

Location services report or utilize the geographic location of one or 
more mobile stations (i.e. cell phones).  Location can be obtained  from
the PSTN wireless network (henceforth called the PSTN),  from GPS
equipped MSs, or via hybrids of these two mechanisms whereby information
from the PSTN is delivered to a GPS equipped MS to improve the
efficiency of the GPS calculations.  

Examples of location services are:  

a) Tell party A the location of party B.  

b) Determine and deliver to a MS the location of some restaurants
nearest  its current location.  

c) Push advertisements for a particular retail store to all MS
subscribed  to the service and within a half mile of that store's
location.  

d) Notify party A of that party B has just landed at a particular
airport  and turned on his/her cell phone.  

e) When party B arrives at a particular airport and turns on his cell
phone,  ring that phone and play  an announcement giving updated hotel
reservation and meeting time information.   Then notify party A, the
source of the announcement, that it has been delivered.  

f) Report the identity of every MS entering or leaving a particular
specified  geographic region. This is hopefully subject to appropriate
privacy protections.  

g) Periodically report the count of MS entering or leaving a particular 
specified geographic region.  

h) Track a particular MS.  

3. Wireless PSTN role in providing location services  

The wireless PSTN is ideally situated to contribute to location services
under certain circumstances which we discuss below.    

3.1 Location Regions Native to the PSTN  

In typical cellular PSTN networks, at any given time, a MS with service 
available is associated with several PSTN network entities.  It is
served by a particular  cell site.  In particular, the MS is served by a
particular sector of that cell site indicating which of three

Voelker                      Internet Draft                   [Page 2]

Spirits Support for Location Services                Expires June 2001

directional antennae is used to communicate with the MS. The cell site
is served by an mobile switching center (MSC) which does call
processing. The MSC is among a set served by a Visitor Location Register
(VLR). The Home Location Register(HLR) has an association with the MS
independent of the MS's current location.   For these entities to work
together, there is distributed within the cellular network information
to track the MS as it moves across cell-sectors, across MSCs, and across
VLRs.   This tracking can be leveraged to assist with location services.
For example, to recognize when a MS has  been turned on at a particular
airport (and presuming the MS will be initially turned at the airport
after it arrived by plane while turned off), it generally suffices to
recognize when that airport's local cell site or MSC begins to serve
that MS. So, normal operation of the cellular PSTN provides, as a side
effect, a trap for location discovery that can be efficiently used for
location services.  

Most natural to the PSTN are location regions defined by cell/sector,
MSC control area,  and VLR control area.  SPIRITS interworking has the
greatest potential benefit for location services which based on the
entry/exit of MS from these natural (i.e. already monitored for MS
presence) wireless PSTN regions.  (This is not to say that other
location services may not also benefit from the use of a SPIRITS
interface.)  

For completeness, note that the PSTN, when augmented with Mobile
Positioning Centers (MPC) and Positioning Determining Equipment (PDE)
can locate a MS with great precision not restricted to these "natural"
regions. To accomplish this the radio signals received at multiple
cell/sectors in the vicinity of the MS are compared.  Also, GPS
information collected at the MS itself can be used.  In addition there
are hybrid technologies utilizing cell site's radio reception of the
MS's radio transmissions to supplement GPS calculations performed within
the MS.  

3.2 Triggered location events vs. polling  

If the PSTN is asked (say via PINT mechanism) to notify some entity when
one of a set of MS enters a particular cell site, the PSTN need only
perform a low overhead check when an MS enters that cell site.  That is,
it would need to check to see whether the entering MS is on the list of
MS that it is monitoring.  In contrast, a polling mechanism would need
to  undertake what is likely to be a relatively more expensive
operation. Polling involves querying for the location of each MS on the
list at periodic intervals.  Most of these polling queries may apply to
a MS not powered up, not moving, or distant from the region of interest.
So, to identify when an MS enters a cell site or some other region
natural to the PSTN, asking the PSTN to provide a trap or trigger based 
mechanism may be more efficient than polling the MS. As the number of MS
whose entry to region is of interest increases, the relative advantages
of a trap mechanism relative to polling increases.  

Hybrid usage of trigger and polling methods may sometimes be
appropriate. For example, entry of an MS into a region that is not

Voelker                      Internet Draft                   [Page 3]

Spirits Support for Location Services                Expires June 2001

natural to the PSTN could be monitored in a two stage manner. First use
a PSTN trigger mechanism to determine when the MS entered one a set of
(say) cell sites that together overlay the desired region.  When this
trigger occurs, use polling to determine when the MS enters the actual
target region.  Such polling may be controlled from within the PSTN or
be controlled from the IP world with the individual polling queries
using PINT protocol.        

4. SPIRITS and Location Services 

SPIRITS provides a means for the PSTN to signal entities in the IP world
that a PSTN monitored trigger has occurred.  See Figure 1 in the
appendix for the SPIRITS architecture.  

Note that what we are here calling triggers are not included among the 
the set of triggers conventionally defined for the intelligent network.
The conventional triggers are based upon telephone call events whereas
entry/exit from a region is a trigger having no necessary relation to a
telephone call.    

4.1 Operation 

We use the term "application" to refer to the end-user of the location
information. The operational sequence would be the following:  

a) The application, via PINT mechanisms, registers with the PSTN to be
notified when a location trigger is encountered.  The location trigger
is defined in terms of a location region and some set of MS.  (The
nature of a location trigger is discussed further below.) 
Alternatively, but of likely less utility, the registration information
can be provisioned in the PSTN network.  

b) The PSTN, using means outside the scope of SPIRITS (and perhaps not
yet implemented in real PSTN networks) arranges to test the identity of
each MS observed to enter (or perhaps exit from) from the registration
defined region against the registration defined set of MS. If the
registration permits (see section 4.2), prune MS from the monitored set
once they have met the entry/exit criterion.  

c) When a MS on the list is observed meeting a trigger criterion, the
PSTN transfers the identity of that MS, with a reference to the
particular  registration, to the SPIRITS client. Note that transfer may
be delayed if batch reporting is in effect.  

d) The SPIRITS client transfer the identity of the MS, with a reference
to the particular registration, to SPIRITS server.  

e) The SPIRITS server transfers the identity of the MS, with a reference
to the particular registration, to the application that generated the
registration.  

Note that the application thusly notified that a particular MS has
entered the registered region, may next elect to poll for the location

Voelker                      Internet Draft                   [Page 4]

Spirits Support for Location Services                Expires June 2001

of the MS  (now known to be in the vicinity of the desired region) to
determine when it enters a more tightly defined region. In general, this
polling will not involve Spirits.          

4.2 Registration data 

Registration data may include 

a) Reference to a specification of location region. This must be
understood by the PSTN in terms such as cell site or MSC area or a union
of such natural regions.  If a more general location region is defined,
the PSTN would need additional capabilities to map that region to
natural regions and to poll once entry to the natural region has been
triggered.  

b) Set of MS.  This can be an explicit list or can be an implicit
definition of a set based on specifying some characteristics of the  MS
to be monitored. Can also reference a provisioned set. 

c) Whether the trigger involves entry, exit, or both from the region.  

d) Reporting criterion. Batch or single event. If batch, what delimits a
batch; e.g. periodic reporting interval, number of accumulated events, 
whichever of the above occurs first, etc.  

e) For a particular MS, should multiple entry (or exits) from the region
be reported. Note that requiring this places extra load on the PSTN
trigger monitoring function. Being able to prune the set of monitored MS
as they trigger events reduces the cost of matching a triggering MS
against the contracting list of monitored MS.  

f) Time to live.  If the TTL=0, then an explicit registration
cancellation is needed.  If the registration was done via provisioning,
cancellation is probably also via provisioning.  

4.3 Returned data  

The data returned may be some subset of the following:   

a) set of MS (perhaps only a single member in set) meeting the trigger
criterion  

b) for each reported MS, whether entry or exit event  

c) time stamp for each MS trigger event  

d) count of MS meeting trigger criterion within some time period.  In
this case, probably not include the identities of particular MS.  Has
privacy advantages in some uses.  

e) report of audio message (as specified by registration) when that
audio message is played in response to the MS entering the target
region. E.g. when passenger lands at airport, phone rings  and message

Voelker                      Internet Draft                   [Page 5]

Spirits Support for Location Services                Expires June 2001

is played providing updated hotel reservations.  The requesting
application is then notified via Spirits that the audio message was
delivered.         

4.4. Privacy 

Privacy is obviously of great importance in location services.  It is
not clear where in the architecture the Policy Enforcement Point (PEP)
should be located.  The PEP must permit the location of a user to be
delivered only in accordance with the user's (or subscriber's) wishes
expressed as a function of the particular application receiving the
user's location and whether that application can associate the location
with the identity of the user. (In some cases, government requirements
or carrier policy may override user/subscriber preference.) 

Upon initial processing of a registration by the PSTN, the list of
monitored MS should be pruned to conform to privacy policy. In other
words, filter for privacy before investing in the work of collecting
location information that is not allowed to be delivered to the
requesting application.  

5. Services provided by SPIRITS architecture  

The following aspects of location services using SPIRITS can and should
use the same mechanisms as other kinds of services using SPIRITS:
security  (including authentication and confidentiality), billing,
accounting, transport of messages, binding of trigger firing reports to
the associated registered request.  

6. Acknowledgments  

Bill Opdyke, Margaret Ervin-Willis, and especially Kumar Vemuri provided
helpful feedback on this draft. Jack Kozik suggested location as a
potential SPIRITS contribution.  

6. Reference 

[1] L. Slutsman (Ed.), I. Faynberg, H. Lu, M. Weissman, "The SPIRITS
Architecture". <draft-spirits-architecture.01.txt>, Work in Progress. 
October 2000. 

[2] I. Faynberg, J. Gato, H. Lu, "IN and PINT-related Requirements  for
SPIRITS Protocol", <draft-faynberg-spirits-inpintreqs-01.txt>, work in
progress.  November 2000. 

Voelker                      Internet Draft                   [Page 6]

Spirits Support for Location Services                Expires June 2001

Appendix

         Subscriber's            IP Network
         IP Host

          _______________    ....................
         | _____________ | A . ________________ .
         | |PINT Client|*******| PINT Server  |********
         | |___________| |   : |______________| :     *
         | ____________  |   :        *         :     *
         | |  SPIRITS  | | B . _______*________ :     *
         | |  Server   |*******|SPIRITS Proxy | :     *
         | |___________| |   : |______________| :     *
         |_______________|   .........*..........     *
                                      *C              *
         _________________      ______*________       *
        |  Subscriber     |    |SPIRITS Client |      *
        |  Telephone      |    |               |      *
        |_________________|    |_______________|      *
                 *                    *               * E
                 * Line               * D             *
       ++++++++++*+++++++++++ PSTN +++*+++++++++++++++*++
                 *                    *               *
         +-------------------+     +-----------------+
         | Service Switching |*****| Service Control |
         | Function          | SS7 | Function        |
         +-------------------+     +-----------------+

          Figure 1:  SPIRITS Architecture

Voelker                      Internet Draft                   [Page 7]

Spirits Support for Location Services                Expires June 2001

Author's Address

      John Voelker
      Lucent Technologies
      Room 1A-417
      263 Shuman Blvd
      Naperville, Il. 60566-7050
      E-mail: [email-masked]
      Telephone: +1 630 713 5538

Full Copyright Statement

   Copyright (C) The Internet Society (1998). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph   are
   included on all such copies and derivative works.   However, this
   document itself may not be modified in any way, such as by removing the
   copyright notice or references to the Internet   Society or other
   Internet organizations, except as needed for the   purpose of
   developing Internet standards in which case the   procedures for
   copyrights defined in the Internet Standards   process must be
   followed, or as required to translate it into   languages other than
   English.   The limited permissions granted above are perpetual and will
   not be revoked by the Internet Society or its successors or assigns.
   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
   NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
   NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
   FITNESS FOR A PARTICULAR PURPOSE.

---

From: "Buller, Jeremy" <[email-masked]>
Date: Wed, 29 Nov 2000 18:24:56 -0500

John,

Thanks for the answers/clarifications.

> I don't claim to have demonstrated your viewpoint wrong, only 
> that I look at the situation differently.  
Two sides of the same coin? A parallax if you will. Reading 
through your responses the main point of difference appears 
to be the terms that we are using to describe essentially 
similar implementation alternatives, as well as, the broadness 
and use of the terms REGISTER and SUBS.

Seeing as the next step would presumably be to start looking 
at protocol implementation alternatives perhaps it would be 
prudent to start thinking about a list of descriptive term
definitions in order to reduce the possibility of such 
confusion in the future?

> JV: Incidentally, I was thinking of the case whereby the 
> PSTN would automatically
> place the call and play out the message to party B upon 
> noting his/her arrival.  Having an IP entity initiate
> that call (upon learning from the PSTN on B's arrival)
> is also an interesting way to provide the service.
> Whether this ovrerall example is PINT or SPIRITS involves 
> issues discussed above.
It is indeed likely that components of PINT and SPIRITS 
services will need to work in a coopertaive manner in order 
to provide some of the 'cleverer' services. As such there 
is probably a list of 'things' one might expect each to 
provide, this is something that Lawrence Conroy and I 
attempted to capture in the following IDs:

http://search.ietf.org/internet-drafts/draft-conroy-spirits-act-00.txt
http://search.ietf.org/internet-drafts/draft-conroy-pint-act-00.txt

> JV: There are some non-spooky uses for this; e.g. fleet management.
What, you mean ships? ;)

Kind regards,

Jim Buller

----------------------------------
 Unisphere Networks,
 7800 Congress Avenue, Suite 100,
 Boca Raton, FL 33487. USA

 (+)1 561 981 7011
----------------------------------

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