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

From: "Buller, Jeremy" <[email-masked]>
Date: Tue, 28 Nov 2000 14:15:33 -0500

John,

Maybe I'm confused, but I suspect that I am not. I thought 
the basic tenet for the differentiation of PINT and SPIRITS 
services was achieved via consideration of the initiator 
of a request.

  IP domain initiates   = PINT
  PSTN domain initiates = SPIRITS

I thought this included (in PINT anyway) the SUBS/NOT 
mechanism. If so, some of the services described would 
appear to be more PINT than SPIRITS like (more service 
discussion below).

If I may just jump to section 4.1 The description leads 
me at least to think that this more akin to a PINT client 
sending a SUBS message to a PINT server. The description
covered in b) would then occur in the PINT executive system. 
There is no need for SPIRITS involvement in this description.
Messages (the response notifications) seem to be returned 
to the PINT client, but these are only responses to the 
original PINT subscription. Think of it this way, would 
you call a SUBS from the PSTN to the IP domain, say to
inform party N when an email has been read a PINT or 
SPIRITS SUBS message. To me (and I'm willing to be proved 
wrong), it's a SPIRITS subscription 'like' mechanism, the 
notification returned from the IP domain allows the 
originating SPIRITS client to, for example, phone the 
subscriber and play an announcement about the email.

Location Services - section 2
-----------------------------
I am also a little confused as to why there is a need for 
IP domain involvement in some of these services unless the 
intent is to move some of the mobile service data related 
to location out of the PSTN. If I take a closer look at 
each of the location services identified in 2 :

a) if both party A and B are MS, why is there a need for
either PINT or SPIRITS? It seems unlikely that you would 
propose a SPIRITS query from one MS into the IP domain 
which only gets 'looped back' to the PSTN domain. The other 
possibility of course is that your intent is that the 
location data is stored (probably duplicated) in the IP 
domain as well as the PSTN domain. i.e. SPIRITS client 
case - party B REGISTERS location with entity in IP 
domain or, PINT server case, NOTIFICATION made to IP 
domain PINT client related to a previous SUBSCRIPTION 
sent by that client. 

b) Well I assume the information relayed will be in a 
useful and intelligible format (not just a list of phone
numbers). This would seem to require an IP connection 
from the MS. Location, I guess, would be provided either 
by the MS via GPS or by the mobile PSTN domain itself. 
So I guess I have an IP connection, a mechanism for 
determining location, so I would need PINT or SPIRITS 
for what exactly? Well, I can see that if I were the 
user of this service I might use PINT via my IP 
connection to connect me to a restaurant whose details 
I may be viewing (e.g. variant of click to dial).

c) Push Advertisements
Ouch! the often quoted possibility of spamming the PSTN 
rears it's ugly head. OK, so this ID states that it is a 
subscription service from the MS and thereby if I 
stretched my imagination I would still only call this a 
'quasi'-SPIRITS service. Why? Because of what subs/not 
mechanism implies i.e. tell me when something happens or 
changes. In the SPIRITS case the subscription for which 
notifications are sought is in the IP domain but the 
actual change (i.e. the location) actually occurs in the
PSTN domain, even if this is subsequently reported to the 
IP domain. So if I think about how the service might work
a query to locate the adverts requires SPIRITS for what
exactly? PINT may have been used to SUBS to an 'MS entering 
arena' notifications I suppose.

d) Similar to a) above.

e) Sounds like PINT to me i.e. PINT client subscribes to 
notification from PSTN regarding cell phone 'turning on'. 
Then PINT client initiates call connecting party B to an 
annoucement server. Next, either initiate call to party 
A using PINT or use some other mechanism to inform party 
A e.g. email.

f), g) & h) Spooky! To what end exactly? I must confess to 
not knowing a great deal about radio, but I would have 
thought you could only do this either on a the 'macro' radio 
cell basis or rely on a GPS enabled MS to tell you where it 
was, in which case BTW I guess it'd be nice if I could enable 
and diasble this functionality as I saw fit. I would have 
thought other mechanisms (other than GPS that is) to more 
accurately determine location, such as triangulation, might 
prove somewhat more difficult in say, city environments, 
with shadows and reflections, but as I say I am no radio 
expert.

In short there is a difference between the requirements 
for 1) constantly recorded real-time and 2) occasional 
registration of, or requesting of, location information.

In 2) an end point might say 'I'm here, get me... something',
or, another party may (using PINT) say, 'tell me when party N
gets to here' or 'where is party N?'. The cases and 
services requiring 1) seem, to me at least, difficult to 
justify, not to mention the increase in traffic and posible 
data replication (in the two domains) problems that would 
appear to be inherent in implementing it. 

Apologies to all for being so verbose.

Regards,

Jim Buller

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

---

From: "John A. Voelker" <[email-masked]>
Date: Wed, 29 Nov 2000 16:05:30 -0600

Jim,

The main point of the I-D was that certain location services can usefully
involve SPIRITS.  The list of location services in Section 2 was meant to
provide a view of some of the breadth of location services.  Some - not all - of
these example location services (c, d, e, f, g, and perhaps h) can exploit the
fact the PSTN, in the course of its regular (i.e. non-location service focused)
operation observes when particular MS enter particular regions (e.g. cell sites
or VLR areas). These entries by particular MS into particular already monitored
regions can be used like "triggers" by the PSTN.  Upon the firing of those
triggers, the PSTN can use SPIRITS as a conduit to the appropriate entity in the
IP world interested in that event.  

Of course, the PSTN needs to be informed somehow which "triggers" are active
(which MS for which region), and I suggested this can be done via PINT or via
provisioning of the PSTN.  If done by PINT, you seem to view this as the start
of the service - and this is the crux of the issue.  I prefer to focus on the
core (vs. the "start") of the service which I see as the PSTN monitoring MS
"sightings" in various natural regions and resultant trigger firing (MS
enterring the region). Note that the trigger firing may follow any registration
by months, may occur multiple times per registration, or may never occur despite
a registration - a loose coupling.  I think the core of the service is the PSTN
monitoring for the triggers.  The registration, although needed (unless use
provsioning which is a kind of registration) seems to me somewhat loosely
coupled to the trigger firing and the consequent need to report event to the IP
domain. The proximate cause of the report initiation is MS presense detected by
certain PSTN equipment (e.g. cell site). 

I don't claim to have demonstrated your viewpoint wrong, only that I look at the
situation differently.  

What is important is that certain kinds of location tasks can be more
efficiently done by this PSTN triggering mechanism than by say periodic polling
(every five minutes asking the PSTN: has MS A or B or C enterred Chicago yet?). 
If we believe trapping or triggering for location is a useful function in some
location service situations, then we need protocol mechanisms by which the PSTN
can inform the IP domain of those events.  The case that SPIRITS as that
protocal seems to me reasonable since the core of the service involves PSTN
"trigger" firing intiating an action toward the IP world.

Some additional minor comments inline.

Regards, 

John

>   PSTN domain initiates = SPIRITS

JV: More than one way to interpret "initiates". I tend to
see the PSTN initiating a reporting action toward the IP
world when the PSTN observes an event.  This event may 
happen months after any registration.  Or may never happen.
You seem to see the registration as the initiation -
a reasonable view, but not my preference.
 
> covered in b) would then occur in the PINT executive system.

JV: would occur in the PSTN. No need to attribute this PSTN 
work to a "PINT executive system."

> original PINT subscription. 

JV: also are responses to a PSTN trigger firing some time
after the registration.

Think of it this way, would
> subscriber and play an announcement about the email.

JV: Nice analogy.  I prefer to see a SPIRITS 
registration for a PINT service.  When the IP domain
eventually observes that the email has been read, it initiates
an action toward the PSTN.  PINT and SPIRITS can
work cooperatively.

> Location Services - section 2

JV: The list of location services, as I mentioned above, was 
intended only to describe location services per se.  I agree that not
all necessarily need the involvement of the IP domain. Next
version of this I-D will make that clearer.

> either PINT or SPIRITS? 

JV: I agree.  Even if party A is in the IP world, the PSTN is
simply providing info in immediate and direct response to a
query from an IP entity.  So this is not the PSTN trigger firing initiated
situation that I think can use SPIRITS.

It seems unlikely that you would
> Then PINT client initiates call connecting party B to an

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.

> f), g) & h) Spooky! To what end exactly? I must confess to

JV: There are some non-spooky uses for this; e.g. fleet management.

---

From: Jörgen Björkner <[email-masked]>
Date: Thu, 30 Nov 2000 23:12:53 +0100

Hi,
I agree with John that SPIRITS not necessary have to deal with setting up the triggers, and that was one of my points in the presentation I did in Pittsburgh. In fact the charter clearly states that the WG shall develop an request/response protocol that originates requests in PSTN towards an IP network and expects a response back. How the requests in the "black box" below (I think Steve used this term a few times...) is initiated is clearly out of foce of this WG, and I don't see a need of mixing them up at all. Whne this protocol is finished coul maybe someone write an informational RFC how to use PINT to set up those services, or if any furter developent is needed in that protocol it should be to within a wg that is chartered to focus on that problem.

I focused only on the service execution point (or trigger firing), and that is what my I-D was about. This makes sense since setup of triggers could be done in *many* different ways like calling the customer support (and they sets the triggers by magic), entering a web page that uses PINT++ etc...

For those new or that didn't read my draft before the Pittsburgh meeting I would like you to have a look at it since it is an actual proposal to how the protocol could be designed, without to have to invent anything new, and to be able to re-use all services currently being developed for the SIP networks for PSTN using SPIRITS. The basic idea is to let a SIP application server also to be a SPIRITS server, without to have to change the state machine of the application server, all needed is to add support for E.164 numbers and maybe a few new headers in the messages.

You find the draft at the IETF archives:
http://search.ietf.org/internet-drafts/draft-bjorkner-spirits-vsua-00.txt

cheers
Jörgen

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of John A. Voelker
> Sent: den 29 november 2000 23:06
> To: [email-masked]
> Subject: Re: [SPIRITS] ID: SPIRITS Support for Location Services
> 
> 
> Jim,
>