5 General LCS architecture

03.713GPPFunctional descriptionLocation Services (LCS)Release 1999Stage 2TS

5.1 LCS access interfaces and reference points

There is one reference point between the LCS PLMN server and LCS client called Le. Its protocol specifics are for further study. There may be more than a single LCS network interface to several different LCS clients or other networks. These networks may both differ in ownership as well as in communications protocol. The network operator should define and negotiate interconnect with each external LCS client or other network.

An interface differs from a reference point in that an interface is defined where specific LCS information is exchanges and needs to be fully recognized.

There is an inter-LCS PLMN interface called Lg that connects two independent LCS networks for message exchange.

Figure 1: LCS Access Interfaces and Reference Points

5.2 LCS Functional diagram

GSM 02.71 [2] describes the overall LCS service description from the LCS client point of view. In this specification, a more detailed description of LCS is given. The LCS functional diagram shown in Figure 2 depicts the interaction of the LCS client and the LCS server within the PLMN. The PLMN uses the various LCS components within LCS server to provide the target MS Location Information to the LCS client.

Figure 2: PLMN LCS capability server Functional Diagram

5.3 LCS CLIENT

An LCS client contains an LCS component with one or more client(s) which by using location information can provide location based services.

An LCS client is a logical functional entity that requests from the LCS server in the PLMN location information for one or more than one target MS within a specified set of parameters such as Quality of Service (QoS). The LCS Client may reside in an entity (including the MS) within the PLMN or in an entity external to the PLMN. The specification of the LCS Client’s internal logic and its relation to the external use is outside the scope of this document.

5.3.1 LCS Component

5.3.1.1 Location Client Function (LCF)

The Location Client Function (LCF) provides a logical interface between the LCS client and the LCS server. . This function is responsible for requesting location information for one or more MEs/MSs with a specified "QoS" and receiving a response, which contains either location information or a failure indicator.

5.4 LCS Server

5.4.1 Client handling component

5.4.1.1 Location Client Control Function (LCCF)

The Location Client Control Function (LCCF) manages the external interface towards LCF. The LCCF identifies the LCS client within the GSM PLMN by requesting client verification and authorization ( i.e. verifies that the LCS client is allowed to position the subscriber) through interaction with the Location Client Authorization Function (LCAF) . The LCCF handles mobility management for location services (LCS) e.g., forwarding of positioning requests to VMSC. The LCCF determines if the final positioning estimate satisfies the QoS for the purpose of retry/reject. The LCCF provides flow control of positioning requests between simultaneous positioning requests. It may order the Location Client Coordinate Transformation Function (LCCTF) to perform a transformation to local coordinates. It also generates charging and billing related data for LCS via the Location System Billing Function (LSBF).

5.4.1.2 Location Client Authorization Function (LCAF)

The Location Client Authorization Function (LCAF) is responsible for providing access and subscription authorization to a client. Specifically, it provides authorization to a LCS client requesting access to the network and authorizes the subscription of a client. LCAF provides authorization to a LCS client requesting Location Information of a specific MS.

5.4.1.2.1 Access Subfunction

An Access Subfunction enables LCS clients to access LCS services. This subfunction provides verification and authorization of the requesting client.

When a LCS is requested, the Access Subfunction uses the information stored in the LCS client subscription profile to verify that:

– the LCS client is registered; and

– the LCS client is authorized to use the specified LCS request type;

– the LCS client is allowed to request location information for the subscriber(s) specified in the LCS request;

5.4.1.2.2 Subscription Subfunction

The LCS client Subscription profile shall contain a minimum set of parameters assigned on per LCS client basis for an agreed contractual period. The LCS client profile shall contain the following set of access parameters:

– LCS client identity;

– Allowed LCS request types (i.e. LIR, LDR or both);

– Maximum number of subscribers allowed in a single LCS request;

– Priority;

– Position override indicator;

– State(s);

– Event(s) (applicable to LDR requests only );

– Local coordinate system;

– LCS client access barring list (optional);

– PLMN access barring list applicability.

For certain authorized LCS client internal to the PLMN, a subscription profile is unnecessary. These clients are empowered to access any defined service that is not barred for an MS subscriber. This permits positioning of emergency calls without the need for pre-subscription.

5.4.1.3 Location Client Zone Transformation Function (LCZTF)

The Location Client Zone Transformation Function (LCZTF) performs transformations of a location (latitude and longitude) into a zone identity, which in North America identifies a particular emergency services zone.

5.4.2 System handling component

5.4.2.1 LMU Mobility Management Function (LMMF)

The LMU Mobility Management Function (LMMF) is responsible for maintaining the operational status of LMUs and registering each LMU in an SMLC. Operation of the LMMF is independent of other logical LCS functions and its output is provided to the PRCF. The LMMF only applies to Type A LMUs.

5.4.2.2 Location System Control Function (LSCF)

The Location System Control Function (LSCF) is responsible for coordinating location requests. This function manages call-related and non-call-related positioning requests of GSM LCS and allocates network resources for handling them. The LSCF retrieves MS classmark for the purpose of determining a positioning method. The LSCF performs call setup if required as part of a LCS e.g., putting the ME in a dedicated mode and obtains Cell-ID. It also caters for coordinating resources and activities with regard to requests related to providing assistance data needed for positioning. This function interfaces with the LCCF, LSPF, LSBF and PRCF. Using these interfaces, it conveys positioning requests to the PRCF, relays positioning data to the LCCF and passes charging related data to the LSBF.

5.4.2.3 Location System Billing Function (LSBF)

The Location System Billing Function (LSBF) is responsible for charging and billing activity within the network related to location services (LCS). This includes charging and billing of both clients and subscribers. Specifically, it collects charging related data and data for accounting between PLMNs.

5.4.2.4 Location Client Coordinate Transformation Function (LCCTF)

The Location Client Coordinate Transformation Function (LCCTF) provides conversion of a location estimate expressed according to a universal latitude and longitude system into an estimate expressed according to a local geographic system understood by the LCF and known as location information. The local system required for a particular LCF will be either known from subscription information or explicitly indicated by the LCF.

5.4.2.5 Location System Operations Function (LSOF)

The Location System Operations Function (LSOF) is responsible for provisioning of data, positioning capabilities, data related to clients and subscription (LCS client data and MS data), validation, fault management and performance management of GSM LCS.

5.4.2.6 Location System Broadcast Function (LSBcF)

The Location System Broadcast Function (LSBcF) provides broadcast capability. The LSBcF capability is only used when broadcast data is required for E-OTD or A-GPS positioning methods.

5.4.3 Subscriber Component

5.4.3.1 Location Subscriber Authorization Function (LSAF)

The Location Subscriber Authorization Function (LSAF) is responsible for authorizing the provision of a location service (LCS) for a particular mobile. Specifically, this function validates that a GSM LCS can be applied to a given subscriber. The LSAF verifies the client MS’s subscription.

5.4.3.2 Location Subscriber Privacy Function (LSPF)

The Location Subscriber Privacy function is responsible performs all privacy related authorizations. For an target MS it shall authorize the positioning request versus the privacy options of the target MS, if any.

5.4.4 Positioning component

5.4.4.1 Positioning Radio Coordination Function (PRCF)

The Positioning Radio Control Function (PRCF) manages the positioning of a mobile through overall coordination and scheduling of resources to perform positioning measurements. This function interfaces with the PSMF and PCF and possibly with a PRAF. The PRCF determines the positioning method to be used based on the QoS, the capabiities of the network, and the MS’s location capabilities. It determines which PSMFs to be involved or what to measure, and obtains processed signal measurements from PSMF. Next, it packs the signal measurement data from the PSMF into a certain format and forwards it to the PCF.

5.4.4.2 Positioning Radio Assistance Function (PRAF)

The Positioning Radio Assistance Function (PRAF) provides additional support for the PRCF when radio coordination is distributed among multiple network elements. A particular function of the PRAF for network based position methods is to induce positioning signals from the target MS. For mobile based and mobile assisted position methods, the PRAF could induce position signals from the network or from some other external reference source.

5.4.4.3 Positioning Calculation Function (PCF)

The Positioning Calculation Function (PCF) is responsible for calculating the position of the mobile. It obtains BTS related data e.g., BTS geographic co-ordinates and stores this data. This function applies an algorithmic computation on the collected signal measurements to compute the final location estimate and accuracy. It also supports conversion of mobile’s location estimate between different geodatic reference systems.

5.4.4.4 Positioning Signal Measurement Function (PSMF)

The Positioning Signal Measurement Function (PSMF) is responsible for gathering uplink or downlink radio signal measurements for calculation of a mobile’s position. These measurements can be positioning related or ancillary.

5.5 Information Flows between Client and Server

Other types of national specific information flows may be supported in addition to the information flow specified here.

Any of the information flows here indicated may not be externally realized if the information does not flow over an open interface. On the other hand, if a flow goes over an open interface, it shall abide to a well-defined protocol, which will be further specified in other relevant specifications.

5.5.1 Location Service Request

Via the Location Service Request, the LCS client communicates with the LCS server to request for the location information of one or more than one MS within a specified quality of service. There exist two types of location service requests:

– Location Immediate Request (LIR); and

– Location Deferred Request (LDR).

The following attributes are identified for Location Service Request information flow:

– Target MS;

– LCS identity;

– State (idle, dedicated)

– Event (applicable to LDR requests only);

– Quality of Service information;

– Local coordinate system;

– Geographical area.

5.5.2 Location Service Response

The Location Service Response is sent to the LCS client as the result of the Location Service Request by the LCS Server:

Immediate Response; and

Deferred Response;

These deferred responses can be either single or periodic.

5.6 Logical architecture

LCS is logically implemented on the GSM structure through the addition of one network node, the Mobile Location Center (MLC). It is necessary to name a number of new interfaces. A generic LCS logical architecture is shown in figure 3. LCS generic architecture can be combined to produce LCS architecture variants. No inference should be drawn about the physical configuration on an interface from figure 3.

Figure 3: Generic LCS Logical Architecture

5.6.1 BSS

The BSS is involved in the handling of various positioning procedures. Specific BSS functionality is specified in each of the positioning procedures section.

5.6.2 LCS Client

The LCS client is outside the scope of this standard.

5.6.3 GMLC

The Gateway Mobile Location Center (GMLC) contains functionality required to support LCS. In one PLMN, there may be more than one GMLC.

The GMLC is the first node an external LCS client accesses in a GSM PLMN (i.e. the Le reference point is supported by the GMLC). The GMLC may request routing information from the HLR via the Lh interface. After performing registration authorization, it sends positioning requests to and receives final location estimates from the VMSC via the Lg interface.

5.6.4 SMLC

The Serving Mobile Location Center (SMLC) contains functionality required to support LCS. In one PLMN, there may be more than one SMLC.

The SMLC manages the overall coordination and scheduling of resources required to perform positioning of a mobile. It also calculates the final location estimate and accuracy.

Two types of SMLC are possible:

NSS based SMLC: supports the Ls interface.

BSS based SMLC: supports the Lb interface.

An NSS based SMLC supports positioning of a target MS via signaling on the Ls interface to the visited MSC. A BSS based SMLC supports positioning via signaling on the Lb interface to the BSC serving the target MS. Both types of SMLC may support the Lp interface to enable access to information and resources owned by another SMLC.

The SMLC controls a number of LMUs for the purpose of obtaining radio interface measurements to locate or help locate MS subscribers in the area that it serves. The SMLC is administered with the capabilities and types of measurement produced by each of its LMUs. Signaling between an NSS based SMLC and LMU is transferred via the MSC serving the LMU using the Ls interface and either the Um interface for a Type A LMU or the Abis interface for a Type B LMU. Signaling between a BSS based SMLC and LMU is transferred via the BSC that serves or controls the LMU using the Lb interface and either the Um interface for a Type A LMU or the Abis interface for a Type B LMU.

The SMLC and GMLC functionality may be combined in the same physical node, combined in existing physical nodes, or reside in different nodes.

For Location Services, when a Cell Broadcast Center (CBC) is associated with a BSC, the SMLC may interface to a CBC in order to broadcast assistance data using existing cell broadcast capabilities. The SMLC shall behave as a user, Cell Broadcast Entity, to the CBC (refer to GSM.03.41).

5.6.5 MS

The MS may be involved in the various positioning procedures. Specific MS involvement is specified in each of the positioning procedures section.

5.6.6 LMU

An LMU makes radio measurements to support one or more positioning methods. These measurements fall into one of two categories:

a) Location measurements specific to one MS used to compute the location of this MS

b) Assistance measurements specific to all MSs in a certain geographic area

All location and assistance measurements obtained by an LMU are supplied to a particular SMLC associated with the LMU. Instructions concerning the timing, the nature and any periodicity of these measurements are either provided by the SMLC or are pre-administered in the LMU.

Two types of LMU are defined:

Type A LMU: accessed over the normal GSM air interface.

Type B LMU: accessed over the Abis interface.

A type A LMU is accessed exclusively over the GSM air interface (Um interface): there is no wired connection to any other network element. A type A LMU has a serving BTS and BSC that provide signaling access to a controlling SMLC. With an NSS based SMLC, a type A LMU also has a serving MSC and VLR and a subscription profile in an HLR. A type A LMU always has a unique IMSI and supports all radio resource and mobility management functions of the GSM air interface that are necessary to support signaling using an SDCCH to the SMLC. A type A LMU supports those connection management functions necessary to support LCS signaling transactions with the SMLC and may support certain call control functions of to support signaling to an SMLC using a circuit switched data connection.

NOTE: A network operator may assign specific ranges of IMSI for its LMUs and may assign certain digits within the IMSI to indicate the associated SMLC. Certain digits in the IMSI may also be used as a local identifier for an LMU within an SMLC.

To ensure that a Type A LMU and its associated SMLC can always access one another, an LMU may be homed (camped) on a particular cell site or group of cell sites belonging to one BSC or one MSC. For any Type A LMU with a subscription profile in an HLR (applies only with an NSS based SMLC), a special profile is used indicating no supplementary services, except possibly SMS-PP MT (for data download via the SIM application toolkit), and barring of all incoming and possibly outgoing calls. An identifier in the HLR profile also distinguishes an LMU from a normal MS. All other data specific to an LMU is administered in the LMU and in its associated SMLC.

A Type B LMU is accessed over the Abis interface from a BSC. The LMU may be either a standalone network element addressed using some pseudo-cell ID or connected to or integrated in a BTS. Signaling to a Type B LMU is by means of messages routed through the controlling BSC for a BSS based SMLC or messages routed through a controlling BSC and MSC for an NSS based SMLC.

The following assistance measurements obtained by an LMU have a generic status in being usable by more than one position method:

Radio Interface Timing measurements – comprise Absolute Time Differences (ATDs) or Real Time Differences (RTDs) of the signals transmitted by Base Stations, where timing differences are measured relative to either some absolute time difference (ATD) or the signals of another Base Station (RTD).

5.6.7 MSC

The MSC contains functionality responsible for MS subscription authorization and managing call-related and non-call related positioning requests of GSM LCS. The MSC is accessible to the GMLC via the Lg interface and the SMLC via the Ls interface. If connected to SGSN through the Gs interface, it checks whether the mobile station is GPRS attached to decide whether to page the mobile station on the A or Gs interface.

5.6.8 HLR

The HLR contains LCS subscription data and routing information. The HLR is accessible from the GMLC via the Lh interface. For roaming MSs, HLR may be in a different PLMN that the current SMLC.

5.6.9 gsmSCF

The Lc interface supports CAMEL access to LCS and is applicable only in CAMEL phase 3. The procedures and signaling associated with it are defined in GSM 03.78 and GSM 09.02, respectively.

5.6.10 LMU and SMLC association

The LCS architecture is intended to support a high degree of flexibility, whereby any physical SMLC can support multiple Ls or Lb interfaces (e.g. allowing a BSS based SMLC to serve multiple BSCs) and whereby a mixture of different SMLC types can serve a single network or single MSC area. Figure 4 illustrates the case where different SMLC types and different LMU types are supported in a single MSC area.

Figure 4: Mixed Network with BSS and NSS based SMLCs and Type A and B LMUs

5.6.11 SGSN

The SGSN forwards the circuit-swiched paging request received from the Gs interface to the BSS.

5.7 Embedded Architecture

The embedded common open architecture between the logical LCS functions is shown in Figure 5. This architecture applies to both BSS and NSS based SMLCs and to both types of LMU.

The protocol between peer SMLCs allows an LMU to effectively perform measurements for any one or more of several SMLCs and may be used to solve border area problems where LMUs on one side of an SMLC border would not normally be available to the SMLCs that control LMUs on the side. The intent is to impact only the SMLC in resolving border area problems and not LMUs.

Figure 5: Common Embedded Architecture between Logical LCS Functions

5.8 Assignment of functions to general logical architecture

Table 1: Mapping of LCS Functions into Network Elements

MS

LMU

BTS

BSC

GMLC

SMLC

MSC

HLR

gsmSCF

LCS Client

LCF

X

X

X

X

LCCF

X

LCAF

X

LCZTF

X

LMMF

X

LSCF

X

LSPF

X

LSAF

X

LSBF

X

X

LSBcF

X

LSOF

X

X

X

X

X

LCCTF

X

PRAF

X

PRCF

X

PCF

X

X

PSMF

X

X

X