Transcript - IEEE Mentor

IEEE 802.23 Emergency Services Working Group
DCN: 23-11-0002-00-SUPL-Tutorial.ppt
Title: SUPL Tutorial
Date Submitted: January 17, 2011
Presented at IEEE 802 Interim, Los Angeles, USA
Authors or Source(s):
Farrokh Khatibi
Abstract: This is a brief tutorial of OMA SUPL
21-10-0184-00-0000
Page 1
1
SUPL 2.0 Architecture (cont’d)
Network Architecture applicable to SUPL for Emergency Call
support:
VoIP
Circuit Switched
V-PLMN
RAN
V-PLMN
Access
Network
PSTN / PSAP
PSTN /
Internet
SIP
MSC
MF/
ISUP
UE
Li
V-SLP
E-SLP
RLP
MF/
ISUP
E.G. (J-STD-036 E2’)
MLP or
RLP
call related interfaces
location related interfaces
V-SLP
E-SLP
RLP
Page 2
PSAP
S/R
GMLC
SUPL
ULP
MLP or
RLP
MGCF
MF/
ISUP
SUPL
ULP
E.G. (J-STD-036 E2’)
SUPL
ULP
SIP
PSAP
MPC/
GMLC
SUPL
ULP
E-CSCF
SIP
MF/
ISUP
MAP
UE
SIP (SIP capable PSAP)
P-CSCF
S/R
call related interfaces
location related interfaces
SUPL 2.0 Positioning Features
Positioning Methods and Positioning Protocols
Positioning Protocol
TIA-801
(CDMA/UMB)
RRLP
(GSM/GPRS/WCDMA/
LTE/WLAN/WiMAX)
RRC
(WCDMA)
A-GPS (A-GANSS) SET
Assisted



A-GPS (A-GANSS) SET
Based



Autonomous GPS/GANSS



AFLT

NA
NA
Enhanced Cell ID



Enhanced Observed Time
Difference (E-OTD)
NA
 (GSM only)
NA
Observed Time Difference of
Arrival (OTDOA)
NA
NA

Positioning Method
Page 3
SUPL 2.0 Services
Supported Services - SET Initiated
• Immediate Services
– Single Fix
– Location Request of a 3rd Party
– Single Fix with Transfer to 3rd Party
• Triggered Services
– Periodic Fixes
– Periodic Fix with Transfer to 3rd Party
– Area Event Fixes
Page 4
SUPL 2.0 Services (cont’d)
Supported Services – Network Initiated
• Immediate Services
– Single Fixes
– Notification Based on Location
– Emergency Call Support
• Triggered Services
– Periodic Fixes
– Historical Fixes
– Area Event Fixes
Page 5
SUPL 2.0 Services (cont’d)
Triggered Periodic Key Features
• Defined by Number of Fixes, Interval between Fixes and (optionally)
Start Time.
• V-SLP to V-SLP roaming allowed within a triggered periodic session.
• Supports three different types of reporting:
– Real time reporting
– Quasi real time reporting
– Batch reporting
• Historical Reporting includes:
– Position
– Position
– Positioning method
– Enhanced Cell/Sector measurements
– Multiple Location ID
– Result Code
– Time Stamp
Page 6
SUPL 2.0 Services (cont’d)
Triggered Area Event Key Features
• Trigger criteria defined as:
– Entering the geographical target area
– Leaving the geographical target area
– Being inside the geographical target area
– Being outside the geographical target area
• Geographical target area defined as
– Circle
– Ellipsoid
– Polygon
• Area-Id concept to optimize battery lifetime
– Each geographical area id has a super (or sub) set Area Id
– While outside (or inside) the Area Id(s), no precision positioning takes place
– Area Id defined in terms of MCC, MNC, LAC and CI (SID, NID and Base Id for CDMA)
Page 7
SUPL 2.0 Services (cont’d)
Area Id Concept
Entering Target Area:
Area-Id 1
Target
Area
Area-Id 2
Target Area
• Area Id completely overlaps
target area.
• As long as SET is outside of
Area Id, no precision position
determination takes place
Leaving Target Area:
• Target area completely overlaps
target area.
Leaving
Entering
Page 8
• As long as SET is inside of Area
Id, no precision position
determination takes place
SUPL 2.0 Services (cont’d)
Area Event Use Case Examples
1) Single report when SET is inside target area
Behaviour:
Report once only the first
time the SET detects it is
inside the target area.
Example use case:
An advertising service is
triggered once a user is
within a certain area.
SET starts here
SET starts here
Single report sent
Single report sent
Target area
Triggers:
“Entering” trigger with no
repeated reporting OR
“Inside” trigger with no
repeated reporting.
Behaviour:
Report once only the first
time the SET detects it is
outside the target area .
Example use case:
An asset tracking service
generates an alert if a
vehicle goes outside a
predetermined area.
Triggers:
“Leaving” trigger with no
repeated reporting OR
“Outside” trigger with no
repeated reporting.
Target area
2) Single report when SET is outside target area
SET starts here
SET starts here
Single report sent
Target area
Single report sent
Page 9
Target area
SUPL 2.0 Services (cont’d)
Area Event Use Case Examples (cont’d)
3) Repeated report when SET is inside target area
SET starts here
Behaviour:
Report at regular intervals
while the SET is inside the
target area .
Example use case:
A staff locator service
tracks the location of
employees while they are
on campus, but not while
they are off-site.
Repeated reports
Repeated reports
Target area
Triggers:
“Inside” trigger with
repeated reporting.
4) Repeated report when SET is outside target area
Repeated reports
SET starts here
Report at regular intervals
while the SET is outside the
target area .
Example use case:
An asset tracking service
tracks the location of
company vehicles while
they are on the road, but not
while they are within their
compound.
Triggers:
Target area
Repeated reports
Page 10
Behaviour:
“Outside” trigger with
repeated reporting.
SUPL 2.0 Services (cont’d)
Area Event Use Case Examples (cont’d)
5) Repeated report each time SET enters target area
Behaviour:
SET starts here
Example use case:
First report
Report each time SET
enters the target area.
A social networking service
alerts friends whenever a
user enters a predefined
area.
Triggers:
“Entering” trigger with
repeated reporting.
Behaviour:
Report each time SET
leaves the target area.
Target area
Second report
6) Repeated report each time SET leaves target area
SET starts here
First report
Example use case:
Second report
Page 11
Target area
Triggers:
An employee tracking
service records each time an
employee leaves an
assigned region.
“Leaving” trigger with
repeated reporting.
SUPL 2.0 Architecture
Supported Bearers
– GSM/GPRS
– WCDMA
– CDMA
– WLAN
– LTE
– UMB
– WiMAX
Supported Architectures
• Proxy Mode
– Mandatory for GSM/GPRS/WCDMA/LTE/WiMAX
– Optional for CDMA/UMB and WLAN
• Non-Proxy Mode:
– Optional for all Bearers
Page 12
SUPL 2.0 Architecture (cont’d)
Transport Layer
• TCP/IP for SUPL message exchange
• SUPL Network Initiated Service Initiation:
– WAP Push for CDMA/UMB, GSM/GPRS/WCDMA/LTE and WiMAX
– MT SMS for CDMA/UMB, GSM/GPRS/WCDMA and WiMAX
– UDP/IP for CDMA/UMB, GSM/GPRS/WCDMA/LTE and
WLAN/WiMAX
– SIP/IP for CDMA/UMB, GSM/GPRS/WCDMA and WLAN/WiMAX
Security
• General Concept
– Mutual authentication between SET and H-SLP (proxy)
– Mutual authentication between SET and H-SLP and V-SLP (non-proxy)
– Authentication based on shared keys between SET and H-SLP (V-SLP)
– Alternative Client Authentication based on SET_ID/IP Address mapping
Page 13
SUPL 2.0 Architecture (cont’d)
Security (cont’d)
• Key Management
– 3GPP: GBA [3GPP 33.220]
– 3GPP2: GBA [S.S0109]
– WiMAX: SEK based method
• Alternative Client Authentication (proxy mode only):
– H-SLP server authentication based on public key
– SET client authentication based on bearer level authentication i.e.
MSISDN and IP address mapping
• SUPL INIT Protection
– Network based VER Authentication
– SUPL INIT Protection Protocol
• SUPL Security Synchronization
– Providing refreshed keys for Triggered Sessions
Page 14
SUPL 2.0 Architecture (cont’d)
SIP/IP
Core
SIP Push (P-2)
MLS Application/
SUPL Agent
SIP Push (P-2)
WAP PPG
New in SUPL 2.0:
PAP (P-1)
POTAP (P-2)
• SIP support for SUPL INIT
transport
SIP Push (P-1)
SMS (Lup)
Le/L1
SMSC/MC
Lr/LCS-z
SMS Telecommunication/
Teleservice (Lup)
GM
Emergency
IMS Core
Lz
• UDP/IP support for SUPL INIT
transport
• Open Llp interface
SUPL Location Platform
• E-SLP
UDP/IP
to Charging
SET
MLS Application/
SUPL Agent
SET-to-SLP (Lup)
SET-to-SLC* (Lup)
Home / Requesting /
Visiting / Emergency
SUPL Location Center
•
The E-SLP in an SLP associated with the PLMN
serving the SET and used to perform positioning
for an emergency call initiated by the SET
•
The E-SLP may be the H-SLP if the SET is not
roaming
•
Positioning may occur without interaction with
the H-SLP
•
A V-SLP may be chosen by the E-SLP to assist
positioning if the SET initiated the emergency
call outside the coverage area of the E-SLP
Lpp
Llp
Lh/Lg/L2
SET-to-SPC* (Lup)
* SET-to-SLC/SPC interface is applicable only
to Non-Proxy mode operation
Page 15
Home / Requesting /
Visiting / Emergency
SUPL Positioning Center
SUPL 2.0 Positioning Features (cont’d)
Support of A-GNSS according to 3GPP and 3GPP2
• The A-GNSS concept is introduced to allow additional
Navigation Satellite System assisted positioning technology
to be utilized, e.g. A-GPS, A-Galileo, etc.
• Applicability of a particular A-GNSS is subject to the support
in relevant 3GPP and 3GPP2 specifications that SUPL 2.0 is
reliant on.
Support of Stand Alone positioning technologies
such as Autonomous GNSS
• In Network Initiated scenarios, SUPL is only used to initiate
an autonomous positioning determination at the SET and to
return the result to the requesting SUPL Agent.
Page 16
SUPL 2.0 Positioning Features (cont’d)
Multiple Location ID
• As optional parameter Multiple Location ID is an addition to
Location ID which allows the SLP to enhance positioning by
creating a “Network Measurement Trajectory” of up to 10 min
• Multiple Location ID consists of:
– Location ID (serving or camped on cell)
– Relative timestamp
– Serving Cell Flag
• Multiple Location ID allows SET to send network
measurements from serving and idle radio cells including
WLAN Access Points
• Used in:
– SUPL START
– SUPL TRIGGERED START
– SUPL POS INIT
Page 17
SUPL 2.0 Positioning Features (cont’d)
Multiple Location ID (cont’d)
• To filter the amount of information the SET is allowed to send to the
SLP in Multiple Location ID, the Supported Network Information
parameter is introduced.
• Supported Network Information represents a bit map indicating
which information is allowed to be sent:
– WLAN Flag (if true, WLAN AP Information may be sent)
– Supported WLAN AP Information (bit map of permitted information)
– GSM Flag (if true, GSM information may be sent)
– WCDMA Flag (if true, WCDMA information may be sent)
– Supported WCDMA Information (bit map of permitted information)
– LTE Flag (if true, LTE information may be sent)
– CDMA Flag (if true, CDMA information may be sent)
– HRPD Flag (if true, HRPD information may be sent)
– UMB Flag (if true, UMB information may be sent)
– WiMAX Flag (if true, WiMAX information may be sent)
– Historic Flag (if true, historic network information may be sent)
– Non-serving Flag (if true, non-serving cell information may be sent)
Page 18
SUPL 2.0 Positioning Features (cont’d)
Multiple Location Ids constitute a set of individual Location Ids:
MultipleLocationIds ::= SEQUENCE SIZE (1..MaxLidSize) OF LocationIdData
LocationIdData ::= SEQUENCE {
locationId
LocationId,
relativetimestamp
RelativeTime,
servingFlag
BOOLEAN
... }
LocationId ::= SEQUENCE {cellInfo CellInfo,
status
Status,
...}
CellInfo ::= CHOICE {
gsmCell
GsmCellInformation,
wcdmaCell WcdmaCellInformation,
cdmaCell CdmaCellInformation,
...,
ver2-CellInfo-Extension Ver2-CellInfo-Extension}
Page 19
SUPL 2.0 Backwards Compatibility
• ULP Version Negotiation assumes that the SLP may support more than one
major version of SUPL and that the SET supports only one version of SUPL.
• The SLP may support a contiguous range of versions from M2 to M1 (M2
being the lower version and M1 being higher version).
• Network Initiated SUPL sessions:
– During session establishment, the H-SLP indicates the intended version M1.m1
(major.minor version) in the version parameter of the SUPL INIT message. The HSLP also indicates the lowest version M2 it supports and for which service
continuation is possible (M2 depends on the service invoked e.g. for triggered
services, the minimum value of M2 is 2, however, for immediate services the
minimum value – if supported by the H-SLP is 1). The SET continues the SUPL
session normally if it supports a version M with M2 ≤ M ≤ M1. Otherwise the SET
sends a SUPL END message and terminates the session.
• SET Initiated SUPL sessions:
– During session establishment the SET sends its supported version M1.m1 in the
version parameter of the initial message. The H-SLP continues the session if it
supports the same major version M1. Otherwise the H-SLP terminates the SUPL
session with a SUPL END message.
Page 20
SUPL 2.0 Backwards Compatibility
• Exceptions for SUPL 1.0:
– For a Network Initiated SUPL session between a H-SLP supporting a version of
SUPL above 1.0 and a SET that supports only 1.0, the SET responds to the SUPL
INIT message with a SUPL END. The H-SLP then restarts the session using SUPL 1.0
if supported and if compatible with the intended SUPL service.
– For a network initiated SUPL session between a H-SLP supporting only SUPL 1.0
and a SET that supports only a higher version, the SET recognizes that the H-SLP
only supports SUPL 1.0 and responds to the SUPL INIT message with SUPL END.
– For a SET initiated SUPL session between a H-SLP supporting a version of SUPL
above 1.0 and a SET that supports only 1.0, the SET indicates SUPL 1.0 in the first
SUPL message and the H-SLP, recognizing this, either has to continue the session
using SUPL 1.0 or terminate the session with a SUPL END message.
– For a SET initiated SUPL session between a H-SLP supporting only SUPL 1.0 and a
SET that supports a higher version, the H-SLP responds to the first SET message
with a SUPL END message and terminates the session.
Page 21
SUPL 2.0 Status in OMA LOC
• As far as OMA LOC is concerned, SUPL 2.0 is
completed;
• However, no IOP testing is currently performed in
OMA IOP;
• It is unclear when SUPL 2.0 will be formally
approved as an OMA enabler;
• Regardless, SUPL 2.0 is being deployed by major
carriers.
Page 22