3GPP TSG SA2 Meeting #14 TSG S2-001440

1

Source: Qualcomm Europe Title:

Document for: Agenda Item:

SA2 White Paper on Open Interface within UTRAN Information

3GPP TSG SA2 Meeting #14

Bristol, England, 4-8 September 2000

TSG S2-001440

Source: Title:

QUALCOMM Europe

The support of an open interface to the SMLC within the 3GPP R’00 UTRAN LCS Specifications

XX

Discussion and Decision

Agenda Item: Document for:

This paper highlights the fact that within the current UTRAN LCS specifications, the SMLC

functionality cannot be realized as a stand-alone network element and is instead considered to be an integrated part of the SRNC. As a result, only proprietary SMLC solutions are supported. This architecture is inconsistent with the GSM LCS and the GERAN LCS architectures, since both of these support SMLC access over an open interface. The intent of this paper is to highlight these architectural inconsistencies and suggest that an open interface to the SMLC be supported in the UTRAN LCS architecture for R’00.

Provided an agreement is reached, this paper will serve as the basis for a series of contributions to various 3GPP standards groups. It describes the changes required to return the flexibility established in the GSM LCS specifications and the developing GERAN LCS specifications to the developing R’00 UTRAN LCS specifications.

2 Purpose and Scope

Standards development organizations have recently completed the LCS standards to address 2G location-based services, including E9-1-1 Phase II. Specifically, the GSM R’98/R’99 LCS specifications (GSM LCS) consist of requirements which,

• Allow for flexibility in technology selection and deployment, and

• Allow for the flexible application of technology based on an operators’ choice.

These requirements have been applied in the developing 3GPP GERAN LCS specifications (GERAN LCS). Unfortunately, within the developing 3GPP UTRAN LCS specifications (UTRAN LCS) this flexibility has been removed and open interfaces have been replaced with proprietary

implementations. The authors recommend that it is essential to leverage the GSM LCS and GERAN LCS standards in the UTRAN LCS standards by,

• Maintaining the existing flexibility and allowing this flexibility to be adapted to new

services, and

• Not prematurely precluding any viable options or limiting an operators' choice through

the standardization process.

This paper discusses one item in particular: Within the current revision of UTRAN LCS, the SMLC functionality cannot be deployed as a stand-alone network element and is instead considered to be an integrated part of the SRNC. As a result, only proprietary SMLC solutions are supported. This architecture is inconsistent with GSM LCS and GERAN LCS, in that both of these standards support SMLC access over an open interface.

The intent of this paper is to highlight these architectural inconsistencies and suggest that an open interface to the SMLC be supported in the UTRAN LCS architecture for R’00.

3 Recommendations

This paper explicitly proposes that the following changes be incorporated into the R’00 UTRAN LCS in order to return it back to a non-proprietary architecture.

• Separating the SMLC functionality from the SNRC and mapping the Lb interface into

UTRAN LCS specifications

• Mapping RRLP defined in GSM 04.31 into UTRAN LCS specifications.

4 Standardization Principles

The lack of open interfaces is inconsistent with the architectural principles specified for 3GPP R’00

[1]. Two particular architectural principles are of interest:

• Decomposition of network functions and

• A list of separate functions that are likely to evolve independently. Specifically,

o Bearer control in both access and network o Multimedia control for multimedia sessions o Switching and routing

o PS Mobility management, session control and access security functions o CS Call Control, Mobility Management and access security functions o Security functions

o Control for and the traffic processing e.g. voice o Location-based service functionality o Service control

󰀁󰀁Service capabilities, VHE for roamers 󰀁󰀁Mail services control 󰀁󰀁Location-based services

󰀁󰀁Service features and applications

The decomposition principle states that operators shall have the freedom to provision, dimension, and upgrade network functionality in a modular fashion. Given that LCS is listed as one of the functions that will have its own evolution path, it is very important that network entities and interfaces

associated with an LCS implementation follow this decomposition principle. This is consistent with what was done in the GSM LCS and GERAN LCS standards.

5 LCS Specification Analysis

This section provides the relevant details from the various 2G and 3GPP LCS specifications

necessary to understand the architectural inconsistencies between both the GSM LCS and the GERAN LCS specifications, and the UTRAN LCS specifications. Specifically:

• The removal of the Lb Interface

o This forces the SMLC to be an internal function of the SRNC

Next, Section 5 describes how these architectural changes affect the end-to-end protocol. Specifically:

• Termination of the RRLP at the SRNC (as opposed to the SMLC).

5.1 GSM R’98 and R’99 LCS Architecture

Figure 1 shows the GSM LCS architecture [2]. It is important to note that all the interfaces depicted have been specified and a true multi-vendor environment is supported. The next few sections will highlight the 3GPP LCS architecture and point out the key change to the UTRAN LCS that results in implementations based on proprietary interfaces and technologies.

LMUType ACBCCBC-SMLCSMLCLpSMLCUmCBC-BSCLbHLRLsLhLgGatewayMLCMSAbisBSCBTS(LMUType B)AMSC/VLRLeExternalLCS clientLgAbisLMUType B LcGatewayMLCgsmSCFOther PLMN Figure 1 GSM Release 98 and Release 99 LCS Architecture

5.2 3GPP R’00 Architecture

Figure 2 shows the 3GPP R’00 LCS Architecture [3]. The next two sections show the details of the GERAN and UTRAN portions of this diagram.

CSCFAGERAN2G-MSC2G-SGSNLgLggsmSCFLe?LcOSA-LCSGbUmMSIu-psGMLCLgUuUTRANIuIu3G-SGSNMSCserverLe(OSA-LCS?)External LCSClient LgLhHSS*note 1

Figure 2 3GPP Release 2000 LCS Architecture

5.3 3GPP R’00 TSG-GERAN

Figure 3 shows the proposed architecture for 3GPP R’00 GERAN [4]. As one can see, the Lb Interface from GSM LCS has been retained.

GERANAMSCGbMSUmBTSLMUAbisBSCSMLCLbIu-ps2G-SGSNGMLCExternal LCSClient3G-SGSNSMLCType ALMUCBC-SMLCCBC

Figure 3 3GPP Release 2000 GERAN LCS Architecture

5.4 3GPP R’99 UTRAN Architecture

Figure 4 shows the 3GPP R’99 UTRAN LCS Architecture [5]. Note that unlike the GSM LCS and the GERAN LCS architectures, the SMLC is not retained as a stand-alone network entity. It is recommended that this decision be revisited. Such architecture has the following shortcomings:

• It is inconsistent with both the GSM LCS and GERAN LCS architectures, • It prevents a smooth migration from 2G to 3G via software upgrade,

o It prevents a path where, through software upgrades, the 2G SMLC could be

transformed into a 3G SMLC and then interconnected to the SRNCs,

• It is inconsistent with the decomposition principle and will prohibit location services

from evolving independently of the core SRNC services.

LMUType ACBCUuIuBCIu 3G-SGSNLhHLRUENode B(LMUType B)IubSRNC(SMLCfunctio-nality)3G-LgMSC/VLRLeGatewayMLCLcExternalLCS clientIurNode B(LMUType B)IubRNCLgGatewayMLCgsmSCFOther PLMN

Figure 4 3GPP UTRAN LCS Architecture

Figure 5 shows the details of the SRNC [5]. . Note that the interface between the SRNC Handling Entities and Positioning Handling Entities shown in the center of the figure is not an open interface. This interface should be an open Lb Interface.

LMU (remote)

PSMF

UTRAN LCS EntitiesD-RNC Iur LocationServiceRequestUE LCFS-RNC Handling EntitiesLCF LSOFLSCF IuPCF Location Service Core Network (CN)LCS Entities(Client, Subscriber) PRCFResponse PSMFPositioningHandlingEntities PRRMPCF b IuExternal LCFLCS Application UuPSMF Node-B, LMU

Figure 5 Detailed SRNC Architecture for UTRAN 2000

5.5 LCS Analysis Summary and Architectural Recommendations

The following table highlights the issue. It shows that the UTRAN LCS is the only specification

that dictates a proprietary SMLC implementation.

Table 1 Proposed SMLC Implementation Options

Integrated to RNC/BSC

SMLC in GSM (approved) SMLC in GERAN (in progress) SMLC in UTRAN(in progress)

yes yes yes

Connected to RNC/BSC

yes yes no

Integrated to SGSN/MSC

yes no no

Connected to SGSN/MSC

yes no no

If it is agreed in principle that a stand-alone SMLC should be introduced into the UTRAN LCS architecture, then the following figures are proposed to serve as the starting point for such architectural changes.

Figure 6 shows a proposed modification to the UTRAN LCS architecture figure described in TS 25.305. CBC-

SMLC

\\ LMU Type A CBC SMLC IuBC Uu Lb 3G-SGSN HLR Lh UE Node B (LMU Type B) Iub SRNC Iu 3G-Lg MSC/VLR Le Gateway MLC Lc External LCS client Iur Node B Iub (LMU Type B) Lg Gateway MLC RNC gsmSCF Other PLMN Figure 6 Proposed 3GPP UTRAN LCS Architecture

Additionally, Figure 7 shows how the inclusion of the stand-alone SMLC into the UTRAN LCS architecture can be represented in a functional entities diagram. This figure shows a proposed modification to the corresponding figure in TS 25.305.

LMU (remote)

PSMF

UTRAN LCS EntitiesD-RNC Iur LocationServiceRequestUE LCFS-RNC LCFHandling Entities LSOFLSCF IuLb PCF PRRM Location Service Core Network (CN)LCS Entities(Client, Subscriber) Response PSMFPositioningHandlingEntities PRCFExternal LCFLCS Application UuPCF SMLC Iub PSMF Node-B, LMU Figure 7 Proposed UTRAN LCS Functional Entities

6 End-to-End protocol Issues

This section provides the details of the changes that have occurred between the 2G and 3GPP

specifications with respect to the end-to-end protocols (between the SMLC functionality and the handset) used by handset based positioning technologies. The changes can be globally classified as follows:

• Termination of the RRLP at the SRNC (as opposed to the SMLC)

A brief overview of the details follow along with suggested corrections to ensure an open SMLC interface can be supported in 3GPP specifications.

6.1 GSM R’98/R’99 End-to-End Protocols

As discussed in the previous section, for GSM LCS and GERAN LCS, the SMLC is not

necessarily integrated into the BSC / SRNC. Taking GSM LCS as an example, there are two key protocols associated with a stand-alone SMLC. Specifically:

• GSM 04.31 defines the Radio Resource LCS Protocol (RRLP) to support point-to-point LCS services,

• GSM 09.31 defines the BSSAP-LE protocol used between the SMLC and the BSC.

The end-to-end messages defined in GSM 04.31 are encapsulated in different protocols when transmitted between different interfaces. Figure 8 [1] shows the encapsulation of point-to-point RRLP messages between an SMLC and target MS as defined for a BSS based SMLC.

RRLP (04.31)

Relay BSSLAP RR (04.08) RRLP (04.31)BSSLAP (08.71) BSSAP-LE (09.31) SCCP

RR L2 (LAPD) L1 BSSLAP-LE L2 (LAPDm) L1 Target MS

Um

SCCP MTP MTP BSC SMLC Lb

= highest layer where segmentation of upper layers is supported

Figure 8 Signaling between an SMLC and Target MS with BSS based SMLC

6.2 R’99/R’00 End-to-End Protocol

Unlike GSM LCS, where there is a separate document (GSM 04.31) for point-to-point LCS messages, there is only one document for 3GPP R’99/R’00: TS 25.331. TS 25.331 uses Radio Resource Control (RRC) messages to carry point-to-point LCS contents. This is a deviation from the GSM LCS architecture and perhaps is an end result of the “integration” that has occurred.

If the closing of the Lb interfaces is reversed, corresponding changes are necessary in associated standards such that the messages destined for the SMLC can be managed in an open fashion by the SRNC. Table 2 summarizes the future standardization work deemed necessary to implement this architectural change to R’00 UTRAN LCS.

Table 2 – Required End-to-End Protocol Standardization Work

Release Point-to-Point LCS messages Lb interface GSM R’98/R’99

GSM 04.31

GSM 09.31

Translate section 6 of GSM

09.31 into 3GPP specification

3GPP R’99/R’00 TS 25.331

As mentioned in the previous section, GSM 09.31 defines the BSSAP-LE protocol used between the SMLC and the BSS (Lb). To support an equivalent Lb interface within the UTRAN LCS, section 6 of GSM 09.31 will need to be translated into the 3GPP specification such that point-to-point LCS messages can be encapsulated and transported to and from the UE.

7 Conclusions

This paper highlights the fact that within the current UTRAN LCS specifications, the SMLC

functionality cannot be realized as a stand-alone network element and is instead considered to be an integrated part of the SRNC. As a result, only proprietary SMLC solutions are supported. This architecture is inconsistent with the GSM LCS and the GERAN LCS architectures, in that both of these support SMLC access over an open interface. Due to these architectural inconsistencies it is suggested that an open interface to the SMLC be supported in the UTRAN LCS architecture for R’00. Certainly, open interfaces promote competition and provide different choices of SMLC product/vendors to operators.

Provided an agreement is reached, this paper will serve as the basis for a series of contributions to various 3GPP standards groups. It describes the changes required to return the flexibility established in the GSM LCS specifications and the developing GERAN LCS specifications to the developing R’00 UTRAN LCS specifications.

8 References

[1] 3G TR 23.821 V1.0.1 7/00 – 3GPP; Technical Specification Group Services and System Aspects; Architecture Principles for Release 2000

[2] ETSI TS 101 724 V7.3.0 2/00.- Digital cellular communications systems (Phase 2+); Location Services (LCS); (Functional Description) – Stage 2 (GSM 03.71 version 7.3.0 Release 1998)

[3] 3G TS 23.271 V0.0.0 5/00 – 3GPP; Technical Specification Group Services and System Aspects - Functional stage 2 description of LCS (Release 2000)

[4] SMG#2 1035 – Digital cellular communications systems (Phase 2+); GSM/EDGE Radio Access Network (GERAN); Location Services in GERAN; Stage 2; GSM 03.xx version 0.0.1 Release 2000, 5/00

[5] 3G TS 25.305 V3.21.0 6/00 – 3GPP; Technical Specification Group Radio Access Network; Stage 2 Functional Specification of Location service in UTRAN (Release 1999) (NOT APPROVED)