Location Inter-operability Forum (LIF)
Mobile Location Protocol
Page 18 (92)
LIF TS 101 Specification
Version 3.0.0 6 June 2002
4.3 Service Layer Definitions
Each message may have two main parts, namely a context or header part
and a body part. The body part consists of the request/answer and is
described in sections 4.3.2 - 4.3.7. The context or header part consists of the
information that identifies the client as defined in section 4.3.1.
4.3.1 Header Components
The subclient elements, if present, identify the ASPs, resellers and portals in
the chain of service providers between the network and the end-user. The
distinction between client and subclient elements is that the client element
identifies the provider of the service that the Location Server has the initial
relationship with, whereas the subclient elements identify the chain of other
service providers up to the end-user. The final service provider in the chain is
identified as such (last_client="YES"). On the other hand requestor is
indicating the initiator of the location request, so in this context besides an
ASP it could also be an MS subscriber who is asking the position of another
target MS. The identity of the requestor may be an MSISDN or any other
identifier identifying the initiator of the location request.
The sessionid element is used to represent the current session between the
LCS Client and the Location Server. It may be used to replace the id and
pwd elements, used in the context by the LCS Client to "login" to the Location
Server, for the transactions that make up a session. For the first transaction
of the session the LCS Client will need to "login" as usual. The Location
Server may optionally return the sessionid in the response to this first
transaction. If the Location Server does not return a sessionid the LCS
Client will need to continue to "login" for subsequent transactions. The LCS
Client can opt to ignore the sessionid if desired and continue to "login" for
subsequent transactions.
The Location Server will decide the policy to be used to determine how the
sessionid will be created and maintained. For example, the Location Server
may determine the session as being just the transactions pertaining to a
single service/MSID combination – this being restrictive and hence secure
whilst still being useable, or the Location Server may allow the session to
apply to a number of transactions between the Location Server and LCS
Client. The Location Server may also allow the sessionid to be used for a
particular period of time. The Location Server may also decide to return a
different sessionid on each response, which the LCS Client will then use on
the next transaction of the session.
The sessionid cannot be used instead of the req_id as this latter id refers to
a set of reports that have been requested to be delivered from the Location
Server to the LCS Client and do not form part of an existing LCS Client to
Location Server connection. These reports are delivered by the Location
Server "logging in" to the LCS Client for each one and the use of a sessionid,
here would allow the security of the LCS Client to be breached.