Content for TS 29.172 Word version: 18.1.0

3.1 Definitions 3.2 Symbols 3.3 Abbreviations 5.1 General 5.2 Use of Diameter base protocol 5.3 Securing Diameter Messages 5.4 Accounting functionality 5.5 Use of sessions 5.6 Transport protocol 5.7 Routing considerations 5.8 Advertising Application Support
...

1 Scope p. 7

The present document specifies the procedures and information coding for the EPC LCS Protocol (ELP) that is needed to support the location services in E-UTRAN, UTRAN and GERAN. The ELP message set is applicable to the SLg interface between the MME and the GMLC and the Lgd interface between the SGSN and the GMLC. ELP is developed in accordance to the general principles stated in TS 23.271.

2 References p. 7

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]

TS 23.271: "Functional stage 2 description of Location Services (LCS)".

[3]

TS 23.032: "Universal Geographical Area Description (GAD)".

[4] Void.

[5]

RFC 2234: "Augmented BNF for syntax specifications".

[6]

TS 23.003: "Numbering, addressing and identification".

[7]

TS 29.171: "LCS Application Protocol (LCS-AP) between the MME and E-SMLC".

[8]

TS 29.274: "Evolved General Packet Radio Service (GPRS) Tunnelling Protocol for Control plane (GTPv2-C)".

[9] Void

[10]

TS 32.299: "Charging management; Diameter charging applications".

[11]

TS 29.272: "Evolved Packet System; MME and SGSN Related Interfaces Based on Diameter Protocol".

[12]

TS 29.329: "Sh Interface based on the Diameter protocol".

[13]

TS 33.210: "3G Security; Network Domain Security; IP Network Layer Security".

[14]

RFC 4960: "Stream Control Transmission Protocol".

[15]

TS 22.071: "Location Services (LCS); Service description".

[16]

RFC 5778: "Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction".

[17]

TS 29.229: "Cx and Dx Interfaces based on the Diameter protocol; protocol details".

[18]

TS 29.173: "Location Services; Diameter-based SLh interface for Control Plane LCS".

[19]

TS 29.002: "Mobile Application Part (MAP) specification".

[20]

TS 49.031: "Location Services (LCS) - Base Station System Application Part LCS Extension - (BSSAP-LE)".

[21]

TS 25.413: "UTRAN Iu Interface RANAP signalling".

[22]

3GPP2 A.S0014-D v5.0: "Interoperability Specification (IOS) for cdma2000 Access Network Interfaces - Part 4 (A1, A1p, A2, and A5 Interfaces) UTRAN Iu Interface RANAP signalling".

[23]

RFC 6733: "Diameter Base Protocol".

[24]

TS 24.080: "Mobile radio interface layer 3 Supplementary services specification; Formats and coding".

[25]

RFC 7944: "Diameter Routing Message Priority".

[26]

TS 29.571: "5G System; Common Data Types for Service Based Interfaces Stage 3".

3 Definitions, symbols and abbreviations p. 8

3.1 Definitions p. 8

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.

EPC-MO-LR:

EPC Mobile Originating Location Request

EPC-MT-LR:

EPC Mobile Terminating Location Request

EPC-NI-LR:

EPC Network Induced Location Request

PS-MO-LR:

Packet Switched Mobile Originating Location Request

PS-MT-LR:

Packet Switched Mobile Terminating Location Request

PS-NI-LR:

Packet Switched Network Induced Location Request

LCS:

LoCation Services

LCS Client:

software and/or hardware entity that interacts with a LCS Server (in this case, the GMLC) for the purpose of obtaining location information for one or more Mobile Stations. LCS Clients subscribe to LCS in order to obtain location information. LCS Clients may or may not interact with human users. The LCS Client is responsible for formatting and presenting data and managing the user interface (dialogue). The LCS Client may reside in the Mobile Station (UE).

LCS QoS:

The QoS class determines the degree of adherence to the quality of service information as required by the source of a location request.

Target:

UE being positioned

3.2 Symbols p. 8

For the purposes of the present document, the following symbols apply:

SLg

Interface between GMLC and MME

Lgd

Interface between GMLC and SGSN

3.3 Abbreviations p. 9

For the purposes of the present document, the abbreviations given in TR 21.905 and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in TR 21.905.

DRMP

Diameter Routing Message Priority

EPC

Enhanced Packet Core

GMLC

Gateway Mobile Location Centre

IMEI

International Mobile Equipment Identity

IMS

IP Multimedia Subsystem

IMSI

International Mobile Subscriber Identity

MME

Mobility Management Entity

TTTP

Transfer To Third Party

User Equipment, as defined in TS 23.032

4 Functional Overview p. 9

4.1 General p. 9

This document defines the EPC LCS Protocol (ELP) used on the SLg interface between the GMLC and the MME and on the Lgd interface between the GMLC and the SGSN in the Evolved Packet Core (EPC).

The location of the SLg interface within the LCS logical architecture is shown in Figure 4.1-1.

Copy of original 3GPP image for 3GPP TS 29.172, Fig. 4.1-1: SLg interface in the LCS Architecture

Figure 4.1-1: SLg interface in the LCS Architecture
(⇒ copy of original 3GPP image)

The location of the Lgd interface within the LCS logical architecture is shown in Figure 4.1-2.

Copy of original 3GPP image for 3GPP TS 29.172, Fig. 4.1-2: Lgd interface in the LCS Architecture

Figure 4.1-2: Lgd interface in the LCS Architecture
(⇒ copy of original 3GPP image)

The high level functions of the ELP protocol are described in TS 23.271.

The main functions of the protocol are:

To allow the GMLC to request position estimates for a particular target UE from the MME or SGSN in order to support the EPC-MT-LR or PS-MT-LR positioning procedures. This is achieved using the Provide Subscriber Location message;
To allow the MME or SGSN to return a position estimate or an error report to the GMLC in response to a Provide Subscriber Location request as part of an EPC-MT-LR or PS-MT-LR positioning procedure;
To allow the MME to forward an unsolicited position estimate to the GMLC as part of the EPC-MO-LR or EPC-NI-LR procedures. This is achieved using the Subscriber Location Report message;
To allow the SGSN to forward an unsolicited position estimate to the GMLC as part of the PS-MO-LR, PS-NI-LR or periodic MO-LR TTTP procedures. This is achieved using the Subscriber Location Report message;
To allow the GMLC to acknowledge receipt of an unsolicited position estimate as part of the EPC-MO-LR, EPC-NI-LR, PS-MO-LR, PS-NI-LR or periodic MO-LR TTTP procedures;
To allow the GMLC to request position estimates for a particular target UE from the SGSN or MME as part of the deferred MT-LR procedure. This is achieved using the Provide Subscriber Location message;
To allow the SGSN or MME to acknowledge receipt of position estimate request to the GMLC as part of a deferred MT-LR procedure;
To support the procedures for handover of an IMS emergency call with EPS/GPRS access.

5 ELP Message Transport p. 10

5.1 General p. 10

The ELP protocol is defined as a Vendor Specific diameter application (SLg application). It reuses the basic mechanisms defined by the Diameter base protocol as specified in IETF RFC 6733 [23], and it defines a number of additional commands and AVPs to implement the SLg, Lgd specific procedures.

5.2 Use of Diameter base protocol p. 10

The Diameter base protocol as specified in IETF RFC 6733 [23] shall apply except as modified by the defined support of the methods and the defined support of the commands and AVPs, result and error codes as described in this specification. Unless otherwise specified, the procedures (including error handling and unrecognised information handling) shall be used unmodified.

5.3 Securing Diameter Messages p. 11

For secure transport of Diameter messages, see TS 33.210.

5.4 Accounting functionality p. 11

Accounting functionality (Accounting Session State Machine, related command codes and AVPs) shall not be used on the SLg, Lgd interfaces.

5.5 Use of sessions p. 11

Between the MME and the GMLC and between the SGSN and the GMLC, Diameter sessions shall be implicitly terminated. An implicitly terminated session is one for which the server does not maintain state information. The client shall not send any re-authorization or session termination requests to the server.

The Diameter base protocol as specified in IETF RFC 6733 [23] includes the Auth-Session-State AVP as the mechanism for the implementation of implicitly terminated sessions.

The client (server) shall include in its requests (responses) the Auth-Session-State AVP set to the value NO_STATE_MAINTAINED (1), as described in IETF RFC 6733 [23]. As a consequence, the server shall not maintain any state information about this session and the client shall not send any session termination request. Neither the Authorization-Lifetime AVP nor the Session-Timeout AVP shall be present in requests or responses.

5.6 Transport protocol p. 11

Diameter messages over the SLg and Lgd interfaces shall make use of SCTP (see IETF RFC 4960 [14]).

5.7 Routing considerations p. 11

This clause specifies the use of the Diameter routing AVPs Destination-Realm and Destination-Host.

Destination-Realm AVP shall always be included in all diameter requests, and therefore is declared as mandatory in the ABNF for all commands.

When a request is initiated by the GMLC, the name of the MME or SGSN shall be determined by querying the HSS over the SLh interface, and retrieve the specific MME or SGSN that is currently serving the UE. Therefore, Destination-Host AVP shall always be included in the commands originated at the GMLC, and is declared as mandatory in the ABNF.

When a request is initiated by the MME or SGSN, the name of the GMLC may be either locally configured in the MME/SGSN (e.g., in the intra-domain scenario, when the GMLC belongs to the same PLMN as the MME/SGSN), or it is known from a previously received location procedure initiated at the GMLC. Therefore, the Destination-Host AVP is declared as mandatory in the ABNF of the commands originated at the MME or SGSN.

If the Vendor-Specific-Application-ID AVP is received in any of the commands defined in this specification, it shall be ignored by the receiving node, and it shall not be used for routing purposes.

5.8 Advertising Application Support p. 11

The MME, SGSN and GMLC shall advertise support of the Diameter SLg Application by including the value of the application identifier in the Auth-Application-Id AVP within the Vendor-Specific-Application-Id grouped AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands.

The vendor identifier value of 3GPP (10415) shall be included in the Supported-Vendor-Id AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands, and in the Vendor-Id AVP within the Vendor-Specific-Application-Id grouped AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands.

The Vendor-Id AVP included in Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands that is not included in the Vendor-Specific-Application-Id AVPs as described above shall indicate the manufacturer of the Diameter node as per IETF RFC 6733 [23].