TR 22.814
LCS support in EPC for non-3GPP Accesses
V10.0.0 (Wzip)
2010/04 9 p.
- Rapporteur:
- Dr. Song, Jin han
SK Telecom
Content for TR 22.814 Word version: 10.0.0
1 Scope p. 5
This Technical Report (TR) presents the results of the Study on LCS support for non-3GPP accesses.
One main concept of EPC is to support a variety of different access systems (existing and future) ensuring mobility and service continuity between these access systems. In that perspective, the LCS support for non 3GPP accesses should be also taken into account. However, historically, TS 22.071 has been applicable only to 3GPP accesses and any new requirements for non 3GPP accesses have not been discussed yet.
Therefore we need to consider how to support LCS in EPC for non 3GPP accesses, e.g. 3GPP2 and WiMAX. Supporting LCS in EPC for non 3GPP access does not necessarily mean that all positioning methods available in various kinds of non 3GPP accesses should be supported in EPC or inventing new positioning methods for other accesses. However, how to realize the presentation of location information in EPC when users are connected in non 3GPP accesses should be at least taken into account. In addition, the service scenarios should be discussed whether new service requirements are needed for the users camping on non 3GPP accesses through EPC.
This work will examine whether requirements in TS 22.071 would be applicable for non 3GPP accesses and specify new service requirements for the users connected to non 3GPP accesses through EPC.
Consideration will be given, but not limited, to the following:
- High level requirements of LCS support for non 3GPP accesses;
- Location information provided to the LCS client for non 3GPP accesses;
- QoS requirements of LCS support for non 3GPP accesses.
- Priority between different LCS services for non 3GPP accesses.
- Privacy requirements of LCS support for non 3GPP accesses.
- Periodic location report of LCS services for non 3GPP accesses.
- Impact on the LCS client and the LCS server to support LCS services for non 3GPP accesses
2 References p. 5
The following documents contain provisions which, through reference in this text, constitute provisions of the present document.
- References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific.
- For a specific reference, subsequent revisions do not apply.
- For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.
[1]
TR 21.905: "Vocabulary for 3GPP Specifications".
[2]
Open Mobile Alliance, OMA TS MLP: "Mobile Location Protocol", (http://www.openmobilealliance.org )
[3]
Open Mobile Alliance, OMA TS RLP: "Roaming Location Protocol", (http://www.openmobilealliance.org )
[4]
Open Mobile Alliance, OMA RD SUPL: "Secure User Plane Requirements",(http://www.openmobilealliance.org )
[5]
Open Mobile Alliance, OMA AD SUPL: "Secure User Plane Location Architecture",(http://www.openmobilealliance.org )
[6]
Open Mobile Alliance, OMA TS ULP: "User Plane Location Protocol",(http://www.openmobilealliance.org )
[7]
TS 22.071: "Technical Specification Group Systems Aspects; Location Services (LCS); Stage 1".
[8]
TS 23.271: "Technical Specification Group Systems Aspects; Location Services (LCS); Functional stage 2 description of Location Services (LCS)".
3 Definitions, and abbreviations p. 6
3.1 Definitions p. 6
For the purposes of the present document, the terms and definitions given in TR 21.905 and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905.
3.2 Abbreviations p. 6
4 Considerations p. 6
4.1 User plane solution p. 6
4.1.1 Introduction p. 6
User plane solution has been developed in OMA based on IP to accommodate different radio accesses. Consequently, regardless of current attached access networks, as long as IP connection is available, then OMA solution works through direct communication between the location server and the UE. This protocol is called 'Secure User Plane Location: SUPL' and this seems to be well-suited to support LCS for non-3GPP accesses since naturally EPC is for All-IP. And this solution is also working for non-3GPP terminal for 3GPP2 and WiMAX and even WiMAX side already decided that SUPL would be used for location service. SUPL also rely on a support of transport of the initiation message ( SUPL INIT). The SUPL today mandates WAP Push over SMS (or HTTP) for 3GPP and SMS for 3GPP2. In addition SIP Push and UDP are optional. It is believed that there is no problem for 3GPP2 terminal to support SUPL.
4.1.2 Roaming target UE p. 6
If OMA SUPL is adopted, it seems obvious that there is no impact at all on EPC, however, it needs to consider other aspects such as the interaction between location servers in HPLMN and VPLMN to support the positioning of the UE in the VPLMN.
If the location server in VPLMN has a capability to calculate the position of the UE connected to non-3GPP access then the location server in the VPLMN may calculate the position of UE. But according to roaming agreement and operator policy, if the location server in the VPLMN cannot calculate the position of the UE connected to non-3GPP access, then VPLMN shall be possible to deliver assistance data to the location server in the HPLMN to calculate the position of the UE. The assistance data may consist of access specific information.
If the VPLMN does not have capabilities to calculate the position of UE connected to non-3GPP access then the location server in the VPLMN shall be possible to deliver the assistance data such as access specific parameters and so on to the location server in the HPLMN to calculate the position of UE.
To achieve these cases, the interface between the location server in VPLMN and the location server in HPLMN shall support the deliver of these assistance data such as access specific parameters. Historically, this interface was specified in the OMA and the protocol has been specified in the RLP [3].
In turn, in this TR, requirement discussed above can be specified, then OMA can discuss further gap analysis to meet this requirement as done that for LCS support for GSM / WCDMA such as MLP [2] and RLP. MLP is stage 3 specification for the Le reference point [8] and RLP is stage 3 specification for the Lr reference point [8]. Additionally, RLP is an instantiation of a reference point between SUPL Providers with the purpose to transport information between SUPL Providers to enable positioning of roaming SUPL Enabled Terminals. Examples of such information are coarse position used when generating GPS assistance data or the actual GPS assistance data.
4.1.3 Quality of Service p. 7
Quality of Serivice consists of horizontal accuray, vertical accuracy, response time and QoS class. Since OMA SUPL supports all aspects of QoS requirements, if OMA SUPL is used to locate non-3GPP terminals connected in EPC, then QoS requirements in OMA SUPL can be applied as it is.
4.1.4 Priority between different LCS applications p. 7
Location requests for difference services may be processed with different levels of priority. For example, for value added services, the LCS server may allow different location requested to be assigned different levels of priority. This aspect is already supported in OMA SUPL.
4.1.5 Privacy p. 7
Privacy requirements such as authorization of positioning attempts based on privacy profile, user permission requests and handling of permission responses from users, conditional positioning based on user's permission, conditional reporting based on user's location and so on are also supported in OMA SUPL. If OMA SUPL is used to locate non-3GPP terminals connected in EPC, then privacy requirements in OMA SUPL can be applied as it is.
4.1.6 Periodic Location Report p. 7
Periodic location reporting specified in TS 22.071 is the act of the location server initiating multiple position locations spread over a period of time. OMA SUPL satisfies this requirement with the functionality called 'triggered location request', which enables to generate multiple location determinations of the target terminal at periodic intervals.
4.2 Control plane solution p. 7
Control plane solution would be considered to support LCS for non-3GPP accesses in EPC, however, it seems to be very complicated to realize this since a lot of network interfaces should be involved including non-3GPP access networks and terminals.
However a similar approach as is specified in TS 23.271 for I-WLAN positioning should be considered for non-3GPP terminal positioning. The above specification supports MO, MT and emergency call positioning procedures that are based on combined user plane and control plane capabilities. The principle is that relevant core network procedures such as authorization of LCS Client, determination of LCS support by the terminal, allowance to position a terminal, retrieval of position information and forwarding it to the client and finally sending accounting information to an accounting function. The actual location determination is accomplished using SUPL capabilities, communication between GMLC and terminal in particular.
5 Requirements p. 8
In order to support roaming non-3GPP terminals that are connected to EPC it is assumed that location information, assisting location determination, may be exchanged between home and visited networks. OMA RLP is a candidate for such information exchange. However, such protocol requirements are outside 3GPP mandate.
- LCS for non-3GPP networks shall be supported by interworking with V-GMLC (assuming it supports Lr interface) to the extent the LCS capabilities are supported by the non-3GPP network. The non-3GPP network must support the corresponding capabilities on the Lr interface.
- LCS shall be supported by interworking with non-3GPP network based on use of information in AAA and HSS.
- Interworking with non-3GPP network should be based on OMA SUPL when applicable.
6 Conclusion p. 8
LCS is one of the killer services in current mobile telecommunication services. As EPC is designed as a common core for both 3GPP and non-3GPP accesses, it is essential to consider how to support LCS in EPC for non-3GPP accesses as well.
This Study has identified potential requirements for LCS for non-3GPP access. However, the identified requirements are found to be addressed by other 3GPP specifications. Thus no more specification work is necessary.
$ Change history p. 9
