02 Mn2976eu03mn 0001 Loc Platf Archit Feat

8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat

1/76

Location platform architecture - features Siemens

MN2976EU03MN_00011 2002 Siemens AG

1

Contents

1 Location platform architecture 31.1 The LCS interfaces 41.2 Functional blocks and interfaces 62 Location platform 3.0 features 92.1 API 1 features 112.2 SS7 network interface 202.3 Core features 222.4 Operation and maintenance features 323 Network integration 503.1

CAMEL-based ATI positioning in GSM and UMTS 50

3.2 LCS standard positioning in GSM and UMTS R99 514 Location platform 3.0 software components 534.1 Siemens SX framework 564.2 What is CORBA? 604.3 What is VisiBroker? 645 Location platform hardware 675.1 High availability solution 70

Location platform architecture - features


2/76

Siemens Location platform architecture - features

MN2976EU03MN_0001

2002 Siemens AG

2


3/76



3

1 Location platform architecture


4/76


MN2976EU03MN_0001

2002 Siemens AG

4

1.1 The LCS interfaces

GSM 03.71 describes the necessary network architecture for LCS. Siemens haschosen the BSS-centric variant where the SMLC is connected via Lb interface to theBSC instead of via Ls to the MSC/VLR. The G-MLC is implemented via the LocationPlatform and Location Enabling Server.

Serving Mobile Location Center (SLMC)

Lbinterface.Interface between the BSC and the SMLC

Lpinterface.Interface between two SMLC

Lsinterface.Interface between the SMLC and the MSC/VLR

Location Enabling Server (LES)

Leinterface (API2).Interface between an External LCS Client (Application) andthe LES. This interface is also called API2.

API1.Interface between Location Platform and LES

Location Platform

Lginterface.Interface between the Location Platform and the MSC/VLR. Thereby,

the Location Platform can also belong to a different PLMN. Lhinterface.Interface between the Location Platform and the HLR

API1.Interface between Location Platform and LES


5/76



5

BTS BSC MSC /

VLR

External

LCS Client

CBC S-

MLC

S-

MLC

HLRG-

MLC

Abis A

Lg

Lg

Le/

API2

Lp

Lh

LbCBC-

BSC

CBC-

SMLC

Um

D

MLC Mobile Location Center (Serving/Gateway)

Lx LCS Interfaces

Different

PLMN

Ls

G-MLC

LES/GTB

API1Location

Platform

Fig. 1

Location Platform 3.5 main functionality and interfaces

NMS(IP-

Manager)

Logging

/ Billing

LESLocation Platform 3.5

Provides location informationfrom mobile core or handset toIP-world

Provides presence informationfrom mobile core to IP-world

for 2G, 2.5G and 3G networks Standard compliant interfaces

Location Server User planesupport (LSU)

SNMP-integration into O&Msystem

Electronic Data Records for

logging of location requests

Location Platform 3.5

Provides location informationfrom mobile core or handset toIP-world

Provides presence informationfrom mobile core to IP-world

for 2G, 2.5G and 3G networks

Standard compliant interfaces

Location Server User planesupport (LSU)

SNMP-integration into O&Msystem

Electronic Data Records for

logging of location requests

LoggingData

M

OBILENETWORK

SNMP

FTP

Lh / Lg

SMS

MPM

API 1 V1.1/2.0

API 1 V2.0

ATI / PSI

SLS (internal)

WAP/PPG-IF

SMLC

WAP- /

PP-GW(MSP)

Fig. 2


6/76


MN2976EU03MN_0001

2002 Siemens AG

6

1.2 Functional blocks and interfaces

The Location Platform consists of 3 main software modules:

Common Services

They offer services for the installation and administration of the Location Platform andits location services (e.g. tracing, logging and task management). They provideOA&M clients with access to the Location Platform via CORBA interfaces. Theyprovide external operation systems with alarms and performance data via SNMP.

Location Services

The Location Services module implements the handling of all supported types oflocation requests (standard, emergency) and location reports (standard, emergency).

Message Handling Services

The Message Handling Services implement SS#7 network communication withHLR/HSS/MSC/SGSN and IP-based communication with API-1 clients, e.g. LES.


7/76



7

Location Platform Software Architecture

Common Services Location Services

Error and

Performance

Management

License

Service

Trace

Service

UserAdministra-

tion Service

Configura-

tion Service

Backup &

Restore

Service

Installation

Service

LoadDetection

Service

DB

LCS Client

Handling

Service

Cell Id

Translation

Service

CacheService

Logging

Service

API-1

Adapter

MLP

Services

HTTP Message Handling Sservices

core network elements (HLR, MSC, SGSN)

NMS

OAM

Console

LES MPMDirect

Clients

API-1 V1.1/2.0 API-1 V2.0

Lg/Lh, ATI, SRI/PSI, SM-MT

Admin

Filesftp: Cell-table upload

Auxiliary

Common

Services SS7 Service

MAP

AdapterSMLC

WAP-GW /

PPG

(MSP)

WAP

Adapter

SLS

Adapter

Fig. 3


8/76


MN2976EU03MN_0001

2002 Siemens AG

8


9/76



9

2 Location platform 3.0 features


10/76


MN2976EU03MN_0001

2002 Siemens AG

10


11/76



11

2.1 API 1 features

LP 3.0 offers two flavors of the external interface to LCS clients, called API-1 V1.1and API-1 V2. Both interfaces use the same connection handling provided by theinternal Message Handling Service.

The API-1 Interface the Location Platform offers sockets based communicationchannels for LCS clients. It offers both secure (HTTPS) and insecure (HTTP)connections on different configurable port numbers. On secure connections acertificate is presented to the client on connection establishment.

LP 3.0 offers a unique URL address and a limited configurable number of parallelconnections to be shared by all API-1 clients (LES, MPM, Direct LCS clients).

If a client attempts to establish more connections than allowed it gets an immediate

response indicating that no more connections are available.

After successfully establishing a connection (secure or insecure) the client can startsending HTTP(S)/1.1 POST Requests, each one containing a single API-1 LocationRequest message. LP 3.0 allows (and expects) that the client sends more than asingle HTTP(S) Request using the same connection, although a single HTTP(S)Request per connection is possible. The client must indicate in the http(s) headerfield Connection that a connection should be kept. In this case, LP 3.0 keeps theconnection open until the client explicitly indicates a connection close or until aconnection time out occurs. In case LP 3.0 is unable to receive further HTTP(S)Requests (for whatsoever reason) it may indicate closing of a connection. In both

cases, no further HTTP(S) Requests are allowed on a closed connection. PendingHTTP(S) Re-quests are processed and answered. In case a connection was closedabnormally on the client side the HTTP MHS is able to detect this and to actaccordingly, i.e. to close the connection and discard all pending requests andresponses.

Authorization on http level is a configurable option on API-1 V1.1 to ensure upwardcompatibility to LR 2.0.If activated API 1 clients must provide valid authorizationinformation in the HTTP(S) Request header.

For API-1 V2.0 no authorization is done on the level of HTTP(S) header parameters.According to the LIF MLP 3.0 specifications, API-1 V2.0 requests are authorized by

client ID and password included in the XML message body of the request.


12/76


MN2976EU03MN_0001

2002 Siemens AG

12

2.1.1 API 1 V1.1

The API 1 V1.1 interface is based on the Mobile Location Protocol (MLP).

It is based on HTTP and XML in order to facilitate the development of location-basedapplications.

The API-1 is an application-level protocol for querying the position of mobile terminalsindependent of the underlying network technology. API-1 V1.1 supports the StandardLocation Immediate Service and the Emergency Location Immediate Servicefollowing LIF V1.1 specifications.

Authentication of the LCS Client is done by means of the HTTP protocol orID/password as provided in the XML request parameters.

The Standard Location Immediate Serviceis used when a single location responseis required immediately (within a set time).

The Standard Location Immediate Service consists of the following messages:

Standard Location Immediate Request (SLIR)

Standard Location Immediate Answer (SLIA)

The Emergency Location Immediate Serviceis used to retrieve the position of amobile sub-scriber / user equipment in an emergency situation. The response to thisservice is required immediately (within a set time).

The service consists of the following messages:

Emergency Location Immediate Request (ELIR)

Emergency Location Immediate Answer (ELIA)

In LP 3.0 the Emergency Location Immediate Service differs from the StandardLocation Immediate Service, in that its usage is restricted to emergency clients only.On the SS#7 interface, the Privacy Override Flag is set, the LCS Client Typeindicates an emergency client and the LCS Priority is set to high.

The Emergency Location Reporting Serviceis used when the mobile networkinitiates the positioning of an emergency call using the network-initiated LocationRequest (NI-LR) procedure. LP 3.0 forwards position and related data to theindicated LCS client. A default address in case no emergency client is indicated isconfigurable on LP 3.0. Note that in this case LP 3.0 initiates the dialog instead of theLCS client.

The service consists of the following message:

Emergency Location Report (ELR)


13/76



13

LES Access API-1 v1.1 in LP 3.0

Location Platform API-1:

Downwards compatible to LR2.0 API-1 v1.0

IMSI support added

Required if LES API-2 v1.1 is used

Based on XML/HTTP(S) protocols (4444, 4454)

LCS client authentication via HTTP Header or API 1

parameters

API-1 provides access to LES and other API-1

Clients:

Standard Location Immediate Service (SLIR, SLIA)

Emergency Location Immediate Service (ELIR, ELIA)

Emergency Location Report (ELR)

Location Enabling

Server (LES)

API 1Location Info

XML/HTTP(S)

Location Platform

Fig. 4


14/76


MN2976EU03MN_0001

2002 Siemens AG

14

2.1.2 API 1 V2.0

API-1 V2 is based on the LIF / OMA Mobile Location Protocol MLP 3.0, It is based onHTTP and XML in order to facilitate the development of location-based applications.

The API-1 V2.0 is an application-level protocol for querying the position of mobileterminals independent of underlying network technology.

Authentication of the Client performing a location request is done by means of theAPI-1 parameters clientID and password. No subscriber-related information is usedfor authentication.

API-1 V2.0 offers the following services according to LIF MLP 3.0 specifications:

The Standard Location Immediate Serviceis used for requesting the location of aMobile Subscriber. The service is used when a location response is requiredimmediately (within a set time). In the request, the LCS client can choose between asynchronous and an asynchronous variant of this service. Asynchronous requestsare new in MLP 3.0 and reduce the number of concurrent http-connections that mustbe maintained by clients and LP 3.0.

The Standard Location Immediate Service consists of the following messages:

Standard Location Immediate Request

Standard Location Immediate Answer

Standard Location Immediate Report

The Emergency Location Immediate Serviceis used to retrieve the position of amobile sub-scriber / user equipment that is involved in an emergency call or hasinitiated an emergency service in some other way. The response to this service isrequired immediately (within a set time).

The service consists of the following messages:

Emergency Location Immediate Request

Emergency Location Immediate Answer

In LP 3.0 the Emergency Location Immediate Service differs from the StandardLocation Immediate Service, in that its usage is restricted to emergency clients only.On the SS#7 interface, the Privacy Override Flag is set, the LCS Client Typeindicates an emergency client and the LCS Priority is set to high.


15/76



15

Mobile Location Protocol API-1 v2.0

Location Platform API 1 v2.0 :

Compliant with Mobile Location Protocol MLP 3.0 (LIF

specification TS 101, Version 3.0.0 )

Extension mechanism for Presence

based on XML/HTTP(S) protocols (9210, 9211)

IMSI and MSISDN Support

LCS client authentication via API 1 parameters

API 1 provides access to LES, MPM ore other API 1

Clients: Standard Location Immediate Service (slir, slia, slirep

asynchronous)

Emergency Location Immediate Service (eme_lir,

eme_lia)

Emergency Location Report (emerep)

Subscriber State Service (ssr, ssa, ssrep -

asynchronous)

Location Enabling

Server (LES)

(Client, MPM)

API 1 v2.0

Location

Presence

Info

XML/HTTP(S)

Location Platform

(Server)

Fig. 5

Enhanced mobile subscriber identification by IMSI

In LP 3.0 the mobile subscriber to be located can be identified by either MSISDN orIMSI. Identification based on IMSI supports certain operator scenarios to handlenumber portability as the subscribers HPLMN is uniquely identified by IMSI asopposed to the MSISDN.

If the subscriber is identified by IMSI, the SMS based pre-paging feature for Camel-

based positioning cannot be used as SRI requires the MSISDN as identifier.


16/76


MN2976EU03MN_0001

2002 Siemens AG

16

The Emergency Location Reporting Serviceis used when the mobile networkinitiates the positioning of an emergency call using the network-initiated LocationRequest (NI-LR) procedure. Position and related data are forwarded by LP 3.0 to the

indicated LCS client. A default address in case no emergency client is indicated isconfigurable on LP 3.0. Note that in this case LP 3.0 initiates the dialog instead of theLCS client.

This service consists of the following message:

Emergency Location Report


17/76



17

Mobile Location Protocol API-1 v2.0

Emergency Location Reporting Service

Supports network initiated positioning

Dispatches location information to indicated emergency

applications

Benefit

Allows operators to offer advanced emergency services

To meet (upcoming) legal requirements in many countries

Location Enabling

Server (LES)

(Client)

Location Platform

(Server)

Emergency

Application

(Client)

API 1 v2.0Emergency Report

XML/HTTP(S)

Location Platform

(Server)

Fig. 6


18/76


MN2976EU03MN_0001

2002 Siemens AG

18

The Subscriber State Serviceis an extension of MLP V3.0.0. This service enablesthe MPM and Direct LCS Clients to obtain the subscriber status from the SS7network. Possible states are:

CamelBusy: The MS is engaged in a transaction for a mobile originating orterminated circuit-switched call.

NetworkDeterminedNotReachable: The network can determine from its internaldata that the MS is not reachable. The MAP standard 3GPP TS 29.002 definesfour sub-states giving a possible reason for not being reachable.

AssumedIdle: The state of the MS is neither "CamelBusy" nor"NetworkDeterminedNotReachable".

NotProvidedFromVLR: The VLR did not provide any information on subscriberstate even though it was requested.

This service consists of the following messages:

Subscriber Status Request

Subscriber Status Answer

Subscriber Status Report

LP 3.0 will provide two socket ports for operation of API-1 V2, one for encryption withHTTP and SSL/TLS and one for XML over HTTP traffic.

The two port numbers given below are chosen in line with those of MLP 3.0 and areregistered by IANA (Internet Assigned Numbers Authority, cf.http://www.iana.org/assignments/port-numbers).

9210 for XML transfers over HTTP

9211 for XML transfers over secure HTTP (HTTPS)


19/76



19

Mobile Location Protocol API 1 v2.0

Combined Location & Subscriber state report

Combined Location & Subscriber State Service:

Implemented as an extension of MLP V3.0 on API-2

provides the subscriber state and Location Information from

the SS7 network with one single Request

Possible states are:

CAMELBusy: The UE/MS is engaged on a transaction for a

mobile originating or terminated circuit-switched call.

NetworkDeterminedNotReachable: The network can

determine from its internal data that the UE/MS is not

reachable. The MAP standard 3GPP TS 29.002 defines foursub-states giving a possible reason for not being reachable.

AssumedIdle: The state of the UE/MS is neither

"CAMELBusy" nor "NetworkDeterminedNotReachable".

NotProvidedFromVLR: The VLR did not provide any

information on subscriber state even though it was

requested.

Positioning:

immediate location report (asynchronous)

Location Enabling

Server (LES)

(Client)

API 1 v2.0Location Info

XML/HTTP(S)

Location Platform

(Server)

Mobile Presence

Manager

(Client)

API 1 v2.0Subscriber State

XML/HTTP(S)

Location Platform

(Server)

Fig. 7


20/76


MN2976EU03MN_0001

2002 Siemens AG

20

2.2 SS7 network interface

The Location Platform provides a MAP interface to HLR/HSS, MSC and SGSN.

LP 3.0 supports the following MAP V3 messages:

MAP-ANY-TIME-INTERROGATION (ATI)

MSP-PROVIDE-SUBSCIRBER-INFORMATION (PSI)

MAP-SEND-ROUTING-INFO-FOR-LCS (Lh)

MAP-PROVIDE-SUBSCRIBER-LOCATION (Lg)

MAP-SUBSCRIBER-LOCATION-REPORT (Lg)

MAP-SEND-ROUTING-INFO-FOR-SM (MAP v3 and MAP v2)

MAP_MT_FORWARD_SHORT_MESSAGE (MAP v3 and MAP v2)

With the SS7 network LP 3.0 communicates via TCAP. LP 3.0 uses a JAIN TCAPAPI implementation provided by SignalWare.

Support of Different SCCP Dialects

LP 3.0 supports both ITU-T and ANSI specifications for SCCP. This allows to deploy

LP 3.0 in ITU compliant networks, but as well in networks using ANSI specificationslike notably the US and Chinese market. The SCCP dialect to use in LP 3.0 isconfigured according the HPLMN. Roaming support on SS#7 is restricted to networksusing the same SCCP dialect or providing corresponding gateway functionality.

Support of ANSI and Chinese SS7 GSM, GPRS and UMTS networks

LP 3.0 contains the following SS7 protocol stack versions:

3GPP R4 MAP over ITU-T Q.770-779 TCAP over ITU-T Q.711-719 SCCP overITU-T Q.701-709 MTP

3GPP R4 MAP over ITU-T Q.770-779 TCAP over ANSI T1.112 SCCP over ANSIT1.111 MTP

Same as bullet 1, but with 24 Bit addresses for signaling point codes (instead of 14Bit) for Chinese SS7 networks.

Point Code Formats:

ITU SS7:Integer: 0 to 16383

Chinese SS7: String: M-S-P; M, S, and P represent numbers range from 1 to 255

ANSI SS7: String : N-C-M; Network 1 to 254, Cluster 0 to 255, Member 1 to 255


21/76



21

The SS7 interfaces are based 3GPP Standarts. LP 3.0 supports

the following MAP messages: MAP-ANY-TIME-INTERROGATION (ATI)

MAP-PROVIDE-SUBSCRIBER-INFORMATION (PSI)

MAP-SEND-ROUTING-INFO-FOR-LCS (Lh)

MAP-PROVIDE-SUBSCRIBER-LOCATION (Lg)

MAP-SUBSCRIBER-LOCATION-REPORT (Lg)

MAP-SEND-ROUTING-INFO-FOR-SM (MAP v3 and MAP v2)

MAP-MT-FORWARD-SHORT-MESSAGE (MAP v3 and MAP v2)

Support of ITU, ANSI and Chinese SS7 networks 3GPP R4 MAP over ITU-T Q.770-779 TCAP over ITU-T Q.711-719

SCCP over ITU-T Q.701-709 MTP

3GPP R4 MAP over ITU-T Q.770-779 TCAP over ANSI T1.112 SCCP

over ANSI T1.111 MTP

Same as bullet 1, but with 24 Bit addresses for signalling point codes

(instead of 14 Bit) for Chinese SS7 networks.

SS7 Network Interfaces

Fig. 8

SS7 Interfaces

Lh: Interface between GMLC and HLR

This interface is used by the LP to request

the address of the visited VMSC or SGSN

for a particular target UE whose location

has been requested.

Lg: Interface between GMLC VMSCand GMLC - SGSN

This interface is used by the LP to convey

a location request to the VMSC or SGSN

currently serving a particular target UE

whose location was requested. The

interface is used by the VMSC or SGSN to

return location results to the LP.

ATI/PSI: Pre-standard method to

retrieve CGI from VLR

SMS:

Enforce location update in VLR

Location

Platform (LP 3.0)

Lh

HLR

Lg

VMSC

VLRSGSN

Camel

Based

ATI

HLR

VLR

PSI

SMS

HLR

VMSC

VLR

MAP

Based

PSI

Fig. 9


22/76


MN2976EU03MN_0001

2002 Siemens AG

22

2.3 Core features

2.3.1 Explicit cell ID translation

The Explicit cell-ID translation feature of LP 3.0 allows LCS clients to access the celltable on LP 3.0 in order to get a received CGI translated into the correspondingshape.

This service is triggered whenever LP 3.0 is configured for explicit cell-ID translationand a SLIR provides a CGI. In this case, the MSID is not evaluated and may take anarbitrary value. The SS#7 network is not accessed, instead the CGI is translated intoa shape by the Cell-ID Translation Service.

Explicit Cell ID translation is possible on both interfaces: API-1 V1.1 and API-1 V2.0.It is support for API-1 clients of all types.

Note that if Explicit Cell-ID Translation is configured, this will also influence the IP-based roaming procedures of LES in the sense that whenever a CGI is provided byLES, LP 3.0 will not perform any positioning procedures but just resolve the CGI viaits cell-table.

SS7 positioning

If neither a VLRId nor a CGI is present, LP 3.0 will serve the request by standardizedSS#7 positioning procedures or -- if meeting the QoS by cached positioninformation. SS#7 positioning is performed according to Camel (ATI), the LCSstandard (Lg/Lh) or a Siemens proprietary SMLC-based solution in SR 9 (SF 933).


23/76



23

Explicit Cell-ID Translation in LP 3.0

supports SIM Toolkit Applications and Roaming

SIM Toolkit Applications

LP translates CGI data provided by SMS-

applications into Latitude, Longitude and Accuracy

This translation is performed without any mobile

network access.

Roaming

LP translates CGI data for an inbound roaming

subscriber which are provided by a visited LES

into Latitude, Longitude and Accuracy.

This translation is performed without any mobile

network access.

Benefit

Avoids undesirable mobile network access for

subscriber positioning. Reduces traffic in the

mobile network.

Provides access to a CGI-to-Location translation

service.

Location Enabling

Server (LES)

(Client)

Location Platform

(Server)

LES or Direct Client

Location Platform

API-1

CGI API-1

X, Y, Acc.

Cell-Table

CGI from VLES

Fig. 10


24/76


MN2976EU03MN_0001

2002 Siemens AG

24

2.3.2 IP-based roaming support

LP 3.0 supports the IP-based roaming scenarios of LES to position inbound roamers.LP 3.0 will make use of any passed-in VLRId, VMSCId and CGI in order to reduceSS#7 communication and to provide the best possible position estimate in failuresituations.

IP-based roaming support is triggered by reception of a VLRId and/or CGI on API-1V1.1 or a VMSCId and/or CGI on API-1 V2.0. Dependent on the capability of theVLR/VMSC the following actions are performed:

VLR / VMSC supports MAP-PROVIDE-SUBSCRIBER-LOCATION on Lg-Interface:

If a VLRId/VMSCId is available and the VLR is known to support the Lg-Interface (by

configuration on LP 3.0), LP 3.0 directly performs MAP-PROVIDE-SUBSCRIBER-LOCATION request without prior interrogation of the HLR. This is intended to yield amore actual and more accurate position estimate.

In case of an error during positioning, the position based on the CGI if available isreturned.

LP 3.0 can be forced to cell-ID translation in case a CGI is available by activating theExplicit cell-ID translation feature.

VLR / VMSC does not support MAP-PROVIDE-SUBSCRIBER-LOCATION on

Lg-Interface:If only the VLRId/VMSCId is available and the VLR is known to not support the Lg-Interface (by configuration on LP 3.0), LP 3.0 initiates Camel-based positioning byAnyTimeInterrogation towards the HLR. If a CGI is already provided additionally inthe API-1 request, ATI is skipped. In both cases, the CGI is translated to a shape,which is returned on API-1.

Roaming requests are served from the cache according to the cache policy describedlater.

2.3.3 Pre-standard roaming support on API-1

As a configurable option LP 3.0 supports special return codes to indicate roamingscenarios and to support the IP-based roaming procedures of LES:

If Location Information is obtained via ATI and a VMSC/VLR address and CGI (oroptional a UGAD Shape) from outside the home domain is returned:

API-1v1.1: "303 PRESTANDARD ROAMING"

API-1v2.0: "503 PRESTANDARD ROAMING"


25/76



25

Return ofVMSC and CGI in

VPLMN together

with Roaming

Code

Roaming Support on API-1 (IP based roaming)to reduce inter-PLMN SS7 traffic

ASP Domain

LES

Roaming

Manager

other

LES

API 2

ASP

Location

Platform

HPLMN

API 1

API 2

Location

Platform

VPLMN

API 1

GTB

Use of VMSC and/or

CGI for positioning of

roaming subscriber

without access to

SS7 network

Cannot resolve CGI to

Coordinates, because

visited cell-sector

data not available

- Prestandard Roaming Support

Just use CGI received over API1 to

resolve to Coordinates, no need

to access SS7 network

- explicit CellID translation

Fig. 11

If Location Information is obtained via ATI and none of the optional parametersVMSCaddress or CGI is returned, i.e. ATI did not return enough information to derivea roaming situation

API-1v1.1: "304 PRESTANDARD UNDEFINED"

API-1v2.0: "504 PRESTANDARD UNDEFINED"

If Location Information is obtained via "pure" Lg/Lh usage and the VMSC is not partof the home domain:

API-1v1.1: "301 ROAMING"

API-1v2.0: "501 ROAMING"

The basic idea behind the roaming return codes is to enable the LCS client and inspecific the Location Enabling Server to trigger IP-based roaming procedures and touse any indicated VMSC address or CGI for resolution in the VPLMN.

A location platform in the VPLMN, e.g. LP 3.0 may use the CGI and perform explicitCell Id Translation, thus avoiding further SS7 traffic.


26/76


MN2976EU03MN_0001

2002 Siemens AG

26

2.3.4 Location cache service

To reduce SS#7 signaling traffic, LP 3.0 maintains a cache of recently obtained sub-scriber positions. QoS criteria of the API-1 request control whether cachedinformation is used or not. The caching service is available for all location request onAPI-1.

There are different reasons to access the cache of the LP 3.0.

An API-1 client has requested location information without any time delay (API-1parameter resp_req_type = NO_DELAY) and accepts the current or last knownlocation (API-1 parameter loc_type_type = CURRENT_OR_LAST | LAST).

An API-1 client has explicitly requested the last known, but not the current location(API-1 parameter loc_type_type = LAST), the cache is accessed al-though a time

delay is accepted.

An access attempt to the SS7 network for the current location request has failedand the API-1 client also accepts the last known location (API-1 parameterloc_type_type = CURRENT_OR_LAST).

An API-1 client has set the max_loc_age parameter in an API-1 V2.0 request. Thecache is accessed to find out if it holds recent enough position information for therequested MSISDN / IMSI. If max_loc_age is specified, the cache is accessedindependent of the settings of resp_req_type and loc_type_type. If there's nocache entry, or the location information in the cache is too old, then the SS7network is accessed.

LP 3.0 does not process requests without any time delay (API-1 parameter(resp_req_type = NO_DELAY) that only accept the initial or current location (API-1parameter loc_type_type = CURRENT | INITIAL).

Reasons to access the SS7 network are:

All requests from API-1 clients that accept a time delay and request the INITIAL orCURRENT location.

API-1 client has explicitly requested the last known, but not the current location

(API-1 parameter loc_type_type = LAST), a time delay is accepted and a prioraccess attempt to the cache has failed.

LES or Direct LCS Client has set the max_loc_age parameter, but the cache didnot contain any, or too old location information for the MSISDN or IMSI.


27/76



27

LOW_DELAY,

DELAY_TOLERATED or

Parameter RESP_TIMERset

NO_DELAY

INITIAL

CURRENT

CURRENT_OR_LAST

LAST

Parameter resp_req_type

/

Parameter loc_type_type

Only SS7 network access. Not possible. An error

code is set.

Only SS7 network access. Not possible. An error

code is set.

1st preference: cache

access with respect to

max_loc_age2nd preference: SS7

network access if no cache

hit or cache info out of date

Only cache access.

1st preference: cache

access with respect to

max_loc_age

2nd preference: SS7

network access if no cache

hit or cache info out of date

Only cache access.

Fig. 12


28/76


MN2976EU03MN_0001

2002 Siemens AG

28

2.3.5 Support of different LCS client types

The LCS standard identifies four categories of usage of the location service. Theseare the Commercial LCS, the Internal LCS, the Emergency LCS and the LawfulIntercept LCS. The LP 3.0 supports all these different clients.

The Commercial LCS (or Value Added Services) will typically be associated withan application that provides a value-added service through knowledge of the UElocation to the subscriber of the service. This may be, for example, a directory ofrestaurants in the local area of the UE, together with directions for reaching themfrom the current UE location.

The Internal LCS will typically be developed to make use of the locationinformation of the UE for Access Network internal operations. This may include; for

example, location assisted hand-over and traffic and coverage measurement. Thismay also include support certain O&M related tasks, supplementary ser-vices, INrelated services and GSM bearer services and tele-services.

The Emergency LCS will typically be part of a service provided to assist sub-scribers who place emergency calls. In this service, the location of the UE caller isprovided to the emergency service provider to assist them in their response. Thisservice may be mandatory in some jurisdictions. In the United States, for example,this service is mandated for all mobile voice subscribers.

The Lawful Intercept LCS will use the location information to support variouslegally required or sanctioned services.

LP 3.0 supports clients for all four service categories and maintains a client type at-tribute in the client profile. Furthermore, LP 3.0 adds the client types LocationEnabling Server and Presence Manager to support the operators middleware.

Each API-1 client provisioned on LP 3.0 must belong to one of the six possible clienttypes. The client type attribute controls client authorization to use the LP 3.0 locationservices according to the following table.

The client type will not influence request processing with the exception of Lawfulinterception clients, which will not be logged and for which no EDRs will begenerated.

The client type is provided on the SS#7 interface in the case of LCS standardpositioning. Requests from LES (not supported on SS#7) are mapped to client typeVAS for SLIR and to client type Emergency for ELIR. Clients of type PresenceManager are not allowed to issue positioning requests, thus a mapping to the LCSstandard is obsolete.


29/76



29

API-1 service /

client type

SLIS ELIS ELR SSS

Value Added Service(commercial LCS Client)

x x

Emergency x x

PLMN operator x x x x

Lawful interception x x

Location Enabling

Server

x x x x

Presence Manager x

Location Platform 3.0, API-1 Client Types

SLIS Standard Location Immediate Service

ELIS Emergency Location Immediate Service

ELR Emergency Location Report

SSS Subscriber State Service Fig. 13


30/76


MN2976EU03MN_0001

2002 Siemens AG

30

2.3.6 Multiple home networks support

LP 3.0 supports the configuration of a home domain consisting of multiple PLMNs.These may reside in the same or different countries. The Home domain consists ofall PLMNs administered as home network rather than as other network as de-scribed in 5.3.9. Using the Multiple Home Network feature, multiple operators mayshare the same LP 3.0 installation for subscriber positioning. This may be interestingfor regionally cooperating small operators or within an operator group.

Positioning can be enabled for subscribers roaming within the home domain, while itis not supported outside the home domain. Note that for Camel-based positioning,this requires to administer the CGIs of all home networks on LP 3.0.

The Goal of the feature is that the Operator can use the Platform in different

Networks independent of NCC or NDC. On this way the services can be integrateseamless in 2G and 3G networks or in different countries.

2.3.7 Interpretation (split up) of MSISDN and IMSI

A MSISDN received in a location request is split up into CC+NDC+SN in order to de-rive the capabilities of the associated HLR from the hierarchically organized table.Likewise the IMSI is split up into MCC+MNC+MSISN. In the presence of values ofdifferent length, this is done by the following three step mechanism.

1. Try to split up the MSISDN/IMSI using the "home domain" configuration, i.e.matching to the CCs, MCCs and NDCs, MNCs defined for the home domain.This is efficient as most location requests will be for subscribers of the HPLMN.

2. If that fails, try to split-up matching to values of other configured PLMNs.

3. If that fails, try to split-up using a built in fallback mechanism.

If the MSISDN/IMSI cannot be interpreted, the location request is rejected via "207Misconfiguration of location server" plus an ADD-INFO, indicating that LP 3.0 was notable to derive the HLR-Id from the MSISDN/IMSI.


31/76



31

ASP Domain

Multiple Home Network Support in LP 3.0

Support of multipleoperator networks with a

single location platform

LP 3.0 distinguish Home

and other networks

For Home networks the

cell-id translation to

coordinates is performed

For other networks the

VMSC address and the

CGI are returned and pre-standard roaming is

indicated to the LES

Different Networks can be

combined to one HPLNM

The network Id's 49172,

49173 and 49174 define the

HPLMN and will be used for

MSISDN / IMSI split-up.

LES

API 2

ASP

Location

Platform

HPLMN

(+48172)

API 1

HPLMN

(+50174)

GTB

HPLMN

(+49173)

Network

dataCell-ID

data

Roaming

(+43676)

Fig. 14


32/76


MN2976EU03MN_0001

2002 Siemens AG

32

2.4 Operation and maintenance features

2.4.1 User administration service

The User Administration Service manages administrator logins and their assigneduser roles. It provides a GUI for administrator management. Multiple roles can be as-signed to an administrator login. The User Administration Service defines a systemwide unique user identification for each registered administrator.

The following table lists the data maintained for each administrator login:

Parameter Description

Assigned roles List of user roles.

Password limitations Must be changed after n days.

Must change password after firstlogin (otherwise new password setby authorized personnel) boolean.

User login It consists of login name, login typeand password. Passwords areencrypted before being stored in thedatabase.

Additional attributes: Internal user id,login creator and last modifier.

Time limits Login validity time: The login must beused within the last n days beforeautomatic lock.

User profile Real name (last name, first name),company, sales organization,address, phone number, e-mailaddress, account holder, comment

for login.

Access Control

LP 3.0 authenticates administrators by user name and password. Service accessauthorizations are assigned to user roles by configuration. Administrators may havemultiple user roles assigned.


33/76



33

Location Platform User Administration

Parameter Description

Assigned roles List of user roles.

Password limitations Must be changed after n days.

Must change password after first login (otherwise

new password set by authorized personnel)

boolean.

User login It consists of login name, login type and

password. Passwords are encrypted before being

stored in the database.

Additional attributes: Internal user id, login creatorand last modifier.

Time limits Login validity time: The login must be used within

the last n days before automatic lock.

User profile Real name (last name, first name), company,

sales organization, address, phone number, e-

mail address, account holder, comment for login. Fig. 15

Fig. 16


34/76


MN2976EU03MN_0001

2002 Siemens AG

34

2.4.2 Configuration service

Configuration Management in LP 3.0 is implemented as a centralized file systembased solution using Java property files. The Configuration Service provides anaccess control mechanism to the property files and a GUI. Instead of the GUIadministrators may use a standard editor to manipulate the property files.

Configuration parameters in LP 3.0 may have different scopes, e.g. for a task or for aservice regardless in how many tasks the service is running.

HA Configurations

In HA Configurations with multiple nodes one node is configured as PrimaryApplication Server (PAS). Updates of configuration parameters always occur initiallyon the PAS. All other nodes are configured as Secondary Application Servers (SAS).

They listen to changes in the PAS configuration parameters and update their localconfiguration parameters accordingly.

2.4.3 Task manager service

The Task Manager Service controls LP 3.0s tasks except OEM product tasks.

LP 3.0 tasks are organized in task groups which are started and stopped in a definedsequence, controlled by configuration parameters. The Task Manager Servicesupervises all tasks on a node. If a task dies the Task Manager Service restarts it

automatically.

Single tasks can be stopped and restarted, e.g. for administration purposes. If theadministrator stops a task manually the task remains stopped until it is explicitly re-started. After a shutdown with automatic restart tasks deactivated by configurationparameters remain deactivated.

Every node in a HA configuration executes its own Task Manager Service instancewhich controls the tasks on this node. Task Manager Service instances on differentnodes in a HA Configuration supervise each other mutually. If a Task Manager Ser-vice instance fails (and cannot be restarted by the operating system) the supervisingTask Manager Service instance sends an alarm.

Standard shut down of LP 3.0 is performed by a GUI provided by the Task ManagerService, while emergency shut down can be done by a start / stop script. Standardshutdown affects all nodes in a HA configuration. Emergency shut down only affectsan individual node. In both cases the shutdown procedure (via a stop signal to theUNIX PID of the Task Manager Service) protects LP 3.0 from data loss.

It does not control OEM product tasks such as: OS tasks, TCP-IP tasks, DB producttasks, Web Server tasks.


35/76



35

Location Platform Configuration Manager

Fig. 17

Location Platform Task Manager

Fig. 18


36/76


MN2976EU03MN_0001

2002 Siemens AG

36

2.4.4 Error service

The Error Service provides an interface for error reporting and exception handling ifany misbehavior has been detected. Whenever an object is not able to resolve a re-quest it throws an exception. This is often, but not necessarily an error. Exceptionsare returned to the requesting object, which uses the Error Service to register thoseexceptions that they consider to be an error and to create CORBA exceptions fortrans-mission to the GUIs.

Occurred errors are stored in an internal database and on the file system.

Errors are reported to a network management system (e.g. Siemens IP Manager) bySNMP (via SNMP Service). Alternatively the Error Service provides a GUI for localerror examination.

2.4.5 SNMP service

Alarm Messages SNMP Traps

The SNMP Service provides an interface used by the Error Service forward errorsand alarms to a Network Management System, e.g. the IP Manager. The SNMPService supports SNMP V1.0. The alarm messages are stored by the Error Service inthe DB on the PAS. Sending of alarms is possible from each LP 3.0 nodeautonomously.

LP 3.0 sends SNMP traps distinguishable by

Category and

Severity

LP 3.0 supports the categories Error and Threshold. The category Error is usedfor all traps generated by the Error Service. The category Threshold is used by thePerformance Management Service when reporting reached thresholds.

The software production procedure creates trapinfo.xml files for definition of thetraps. They are created within one configurable directory. The situations of AlarmReporting are described in detail in the appendix in Table 36.

SNMP Agent

The SNMP Agent as part of the SNMP service passively provides the performancecounter data for the Network Management System.


37/76



37

error report

SNMP Traps

Category Error

Arbitrary Service

Error Service

SNMP Service

IP Manager

Location Platform Error / SNMP Service

SUN

SNMP Agent

LP

SNMP Agent

161 7777

SNMP Management

Station (IP Manager)

GET

GET

162

TRAP

PAS SAS

SUN

SNMP Agent

161

GETPerformanceManagement

Service

SNMP Traps

Category Threshold

Fig. 19


38/76


MN2976EU03MN_0001

2002 Siemens AG

38

2.4.6 Database logging of administrative actions

Creation of Logging Records

LP 3.0 stores actions that are relevant for tracking the system usage in order to pro-vide a complete overview about the administrative activities on LP 3.0.

Logging records are stored in an internal database. Each logging entry consists oftwo parts, a fixed header with the searchable key fields and a variable part whichcontains the log specific data in ASCII format.

The header itself also consists of two parts: the fixed descriptor of the logging entryand service specific key fields and values. The service specific key fields may option-ally be written.

The following logging options can be configured per task:

Logging On/Off. If logging is turned off no logging information is written to thedatabase.

Detail Logging On/Off. If detail logging is off no variable part is written to thedatabase.

Examination of Logging Records

The Logging Service provides a GUI to view the logging data.

Export of Logging Records

The Logging Service provides a configurable file writer to periodically export loggingrecords from the database to files. The files can be used for post processing.Exported records contain a header and an application specific part. By default, theheader is a comma separated list of values of the original header fields. Optionallythis header can be overwritten with column (field) names defined by configurationparameters.

The start time and frequency of export of logging records is configurable as well assome filter criteria controlling which logging records are exported.

It is the responsibility of the administrator to remove old exported logging files. If thefile system has not enough space to hold the logging files the Logging Servicereports the problem as critical error to alert the administrator. Periodical export oflogging records is suspended and resumes as soon as free space is available again.No data are lost as the logging records are maintained in the database. If export oflogging records fails for another reason the problem will be reported as error, butperiodical exporting is not suspended.

The administrator may start the file writer manually using shell commands if exportingof logging records failed at the scheduled time, or for creating additional logging fileswith a different time range.

The information which logging records have been exported, is stored in a databasetable.


39/76



39

Logging of Administrative Actions

Log records stored in database

Old records will be deleted automatically

Records can be exported to files

Log records stored in database

Old records will be deleted automatically

Records can be exported to files

Fig. 20


40/76


MN2976EU03MN_0001

2002 Siemens AG

40

2.4.7 File logging of API-1 requests

The File Logging Service provides means for storing relevant data of locationrequests for charging and/or statistics purposes. The EDRs are stored in files.

For API-1 V2.0 requests/reports two types of logging records are supported:

CHARGINGrecords contain the information who issued a request, who waslocated and further charging relevant information; but no indication of the trackedsubscribers location.

LOCATIONrecords contain the location of the tracked subscriber and furtherstatistically relevant information but no subscriber identification

For API-1 V1.1 requests/reports the following type of logging record is supported andfully downwards compatible to LR 2.0

LR 2.0 format BILLING records contain information who issued a request, whowas located and further charging relevant information, but no indication of thetracked subscribers location.

For each request, LP 3.0 writes either API V1.1 or API-1 V2.0 EDRs. This isdetermined from the interface used. For Location reports (NI-LR), the type of EDRto generate is a parameter of the client profile.

The following options can be configured for both charging and LR 2.0 format billingrecords:

Charging Logging On/Off: If turned off no charging records or LR 2.0 format billingrecords, respectively, are written.

Charging Logging File Path: Defines the path of the logging file.

Charging Max Logging Entries: Defines the maximum number of charging recordsper file.

Charging Max Logging File: Defines the maximum number of logging files per task.

The oldest logging file is removed when an additional logging file is opened.

Charging Logger Class: Full qualified logger implementation class name for formatconversion for charging or LR 2.0 billing records. CSV-format conversion is usedas default.


41/76



41

Logging / Billing / Statistics Support

distinguishes three types of EDRs

File logging for charging of API-1 V1.1 requests

Billing records: Who issued the request, who was located and furthercharging relevant information but no indication of the trackedsubscribers location.

File logging for charging of API-1 V2.0 requests and location statistics

CHARGING records: Who issued the request, who was located andfurther charging relevant information but no indication of the trackessubscribers location.

LOCATION records: Where was the tracked subscriber locationinformation but no identification of the tracked subscriber. Used forstatistics collection

Fig. 21

Statistics Collection

Location statistic records

Each retrieved location information can be logged (can be switched off)

No identification of the located subscriber possible

Information is written in CSV format

Can easily be imported in statistic tools

Helps the operator to identify where and how his service is usedHelps to refine the service according to the usage

Location record information

Begin Time, Recording Entity, VMSC Id, Request Type, Error Code,Horizontal Accuracy Requested, Altitude Accuracy Requested, AccuracyDelivered, Data Size, Content Category, Location Information

Fig. 22


42/76


MN2976EU03MN_0001

2002 Siemens AG

42

2.4.8 Trace service

The Trace Service is used to keep track of the flow of program execution. It providesplatform developers and maintenance personnel of LP 3.0 with debugginginformation on a per service basis with several tracing levels that provide differentlydetailed tracing information as the level gets higher.

The Trace Service is used by all Services of LP 3.0.

Trace data are collected in files. One process (and all its threads) uses exactly onetrace file at a time.

The following trace information is recorded with every trace method call:

actual trace time (in milliseconds),

trace class (equivalent to the used trace method), caller's class name,

thread name,

unique trace point number within the caller's class,

remaining trace information,

stack dump optional,

error class optional,

exception information - optional.

The Trace Service offers service and task specific tracing and tracing specific to userservices, controlled by configuration parameters of the component / task / user ser-vice. For each task the trace functionality can be turned on/off.

Because the Trace Service is intended for experienced users like developers no GUIis provided.


43/76


44/76


MN2976EU03MN_0001

2002 Siemens AG

44

2.4.9 Performance service

LP 3.0 provides a large set of counter values for performance management.Counters are persistently stored in LP 3.0s internal database for inspection via anadministrator GUI or later file export. Counter values are accessible via SNMP andSNMP traps are automatically generated when configured threshold values areexceeded. LP 3.0 supports

Usage counters to monitor the interfaces, both http and SS7 and

System counters to monitor HW performance

Performance management is implemented in the Performance Management Servicewhich provides the generic functionality for storage, visualization and reportingperformance counters.

Usage Counters

The next table shows the events monitoring the usage of LP 3.0 interfaces.. The graylines contain the respective event group, the white ones single events. Node-specificperformance counters are provided for these events. They can be accessed via GUIand SNMP. For HA configurations, accumulated counter values are provided on theLP 3.0 GUI and on the Siemens IP Manager network management system. The clientpart of the service presents the node-local counters to a central counter service,which is located on arbitrary HA-nodes of LP 3.0. The central counter service stores

the counters in the database. It provides CORBA interfaces for counter retrieval. TheGUI uses these interfaces. The GUI reads the values from the cache of the centralservice due to performance reasons.

System Counters

In addition to incrementing counters the Performance Management Service providesa mechanism to store hardware performance values. This method is used to registerhardware performance values as

CPU usage

memory usage

These performance values are accessed via sar -brucommand of Solaris. As in

case of the normal incremental counters this mechanism stores the delivered valuesinto the database. The system counters are stored in a memory cache also in theclient part of the performance management service. As with counters thePerformance Management Service compares the received values with configurablethresholds and informs the IP Manager when the thresholds are reached.


45/76



45

Overall received messages

Any type via HTTP

Any type via SS7

Received messages (per request type)

Received Standard Location Immediate Requests

Received Emergency Location Immediate Requests

Received Emergency Location Reports

Received Subscriber State Service Requests

Received messages (per client type)

Received Requests from VAS clients

Received Requests from Emergency clients

Received Requests from Lawful Interception clients

Received Requests from Operator Internal clients

Successfully (OK) handled requests per request type

Standard Location Immediate Responses OK

Emergency Location Immediate Responses OK

Emergency Location Report OK

Subscriber State Service Responses OK

Any type via HTTP OK

Any type via SS7 OK

Successfully (OK) handled requests (per client type)

OK Responses to VAS clients

OK Responses to Emergency clients

OK Responses to Lawful Interception clients

OK Responses to Operator Internal clients

Unsuccessfully handled requests

Timeout on HTTP handling

Timeout in Location Service

Timeout on SS7

Request skipped by HTTP-MH because of overload

Request skipped by MLP-Adapter because of overload

Wrong input (XML)

General error on HTTP message handling

Routing not possible

SS7 provider errors

SS7 user errors

Cache get accesses

Cache requests

Cache requests OK

Messages to service enablers

Messages to HLR/HSS

Messages to MSC/SGSN

Thread numbers

Average of HTTP thread amount

Average of SS7 thread amount

Average thread runtime

Average runtime of HTTP thread

Average runtime of SS7 thread

Fig. 24

Performance Counters

stored in database but

accessible via:

GUI

SNMP

File

Performance Counters

stored in database but

accessible via:

GUI

SNMP

File

Performance Service Usage Counters

Fig. 25


46/76


MN2976EU03MN_0001

2002 Siemens AG

46

2.4.10 Overload detection service

LP 3.0 manages the load on its external request interfaces, distributes requestsamong multiple nodes in a HA configuration and skips request execution in case ofdetected overload.

Internally, the Load Detection Service is responsible for gathering and reporting theload situation (i.e. percent CPU idle) of all nodes in the HA configuration. The LoadDetection Service evaluates the load situation on all nodes periodically (e.g. 5seconds) by a RPC call to the kernel statistics server (rstat-daemon) of each node.This information is used by the HTTP MHS and API-1 Adapter to manage the loadsituation. If an RPC call fails for a certain time period (e.g. 5 minutes) an alarm issent.


47/76



47

Overload

DetectionService

Fig. 26


48/76


MN2976EU03MN_0001

2002 Siemens AG

48

Overload control on API-1 is implemented by the HTTP message handler service andthe API-1 Adapter service as depicted in the next figure.

The http message handler (HTTP MHS)

uses thread pooling to control the number of requests handled concurrently.Whenever a configurable number MaxThreadPoolSize of active threads isreached, Further request handling is delayed until the next thread becomesavailable. This keeps the needed system resources (threads) constant even in thecase of overload.

dispatches requests among the nodes of a HA installation. Dependent on loadmeasurements on all nodes, it forwards API-1 requests to API-1 Adapterprocesses on different nodes and performs a kind of internal load balancing.

detects an overload situation on the local host by comparing the CPU idle value to

the configurable CpuIdleTimePercentage parameter. In overload, a read delayfor the next request is introduced, where the delay time is adapted according to theindicated load level.

Note that as all requests are received on the same port, no filtering of emergencyre-quests can be performed on the level of the HTTP MHS. Therefore,

The API-1 adapter interprets the XML content and eventually skips low priority SLIrequests in overload situations. Since distribution of requests based on system-wide load levels has already been done by the HTTP-MHS, the API1 Adapter onlyevaluates CPU idle time of the local host. API1 Emergency Location Requests aredelivered to the Location Request Service in any case. API1 Standard Location

Requests and Subscriber State Requests may be rejected in overload situations.The amount of rejected requests depends on the overload level.

To handle overload situations of the PLMN, the MAP Adapter reports overloadrelated error messages to the Location Request Service. On occurrence of aresource limitation the Location Request Service blocks all standard locationrequests to the concerned SS7 network element for a configurable time. Similarly, incase of network congestion the Location Request Service blocks all standard locationrequests for a configurable time. The Location Request Service does not block anyemergency location requests.

When receiving location reports (NI-LR) from the SS7 network LP 3.0 all emergencyreports, regardless of its overload status. Mobile originated and deferred location re-quests are discarded in overload situations with an appropriate SS7 error message.


49/76



49

Read Delay

on HTTP(s)

Connections

Fig. 27


50/76


MN2976EU03MN_0001

2002 Siemens AG

50

3 Network integration

3.1 CAMEL-based ATI positioning in GSM and UMTS

Camel-based ATI positioning in GSM and UMTS

One GMLC serves 2G, 2.5G and 3G networks

LocationPlatform(GMLC)

2G-

MSC**

External LCS

Clients

3G-SGSN

HSS*

MS

*Note 1: HSS includes both 2G-HLR and 3G-HLR functionality

**Note 2: MSC also provides the cell-ID for class B GPRS handsets

ATI MAP AnyTimeInterrogation

PSI MAP Provide Subscriber Information

ATI API1

UmPSI

PSIUu

Pre-standard GMLC/SMLCfunctionality

MSCServer

LES

(OMIP)

LCS

Roaming

GISBilling

User

Database

...

LES

(other PLMN)

API2

2G-SGSN

Fig. 28


51/76



51

3.2 LCS standard positioning in GSM and UMTS R99

LCS standard positioning in GSM and UMTS R99

One GMLC serves 2G, 2.5G and 3G networks

Location

CapableMobile

LocationPlatform(GMLC)

2G-MSC

2G-SGSN

BSC

External LCSClients

3G-MSC

2G-SMLC

HSS*

* HSS includes both 2G-HLR and 3G-HLR functionality

A

Lh(ATI)

Um

Lg

Lg

Gb

Uu

lu

SMLC

SRNC

3GSGSN

LES

GTB

API-1 API-2

RNC

BTS Abis

Lb

Iur

NodeB

Iub

NodeB

Iub

SAG Location Server

Further LCS equipment

Core/Radio network

B&R

Backend infrastructure

Radio

Data

Fig. 29


52/76


MN2976EU03MN_0001

2002 Siemens AG

52


53/76



53

4 Location platform 3.0 software components


54/76


MN2976EU03MN_0001

2002 Siemens AG

54

The following software components make up the Location Platform 3.0:

Sun Solaris 8 incl. SDS 4.2.1Java Environment

J2E SX Framework (Siemens AG)

JRE 1.3.1 (Sun)

Interbase 6.01 (Borland)

Visibroker 4.5.1 ORB / Gatekeeper (Borland)

Signalware 8.02 SP4 (Ulticom)

FlexLM (Globetrotter)

SNMPv (AdventNet)

Agent Toolkit (AdventNet)

ASN.1 Tools (Siemens AG)

Web Technology

HTTP Server 1.3.19 (Apache)

Open SSH

Watchdog 1.2

Alteon Switch OS 10.0.25


55/76



55

Location Platform 3.0 Software Components

Sun Solaris 8 incl. SDS 4.2.1

J2E SX Framework V3.3 (Siemens AG)

JRE 1.3.1 (Sun)

Interbase 6.01 (Borland)

Visibroker 4.5.1 ORB / Gatekeeper (Borland)

Signalware 8.02 SP4 (Ulticom)

FlexLM (Globetrotter)

SNMPv (AdventNet)

Agent Toolkit (AdventNet)

ASN.1 Tools (Siemens AG)

HTTP Server 2.0 (Apache)

OpenSSH

Watchdog 1.2

Alteon Switch OS 10.0.25

Fig. 30


56/76


MN2976EU03MN_0001

2002 Siemens AG

56

4.1 Siemens SX framework

ServiceXpress is a homogeneous, secure and efficient tool for the administration ofdistributed networks (e.g. telecommunication networks).

It offers an easy-to-use graphical user interface and allows access via internet. Theapplied CORBA based technology permits the quick integration of external systems.

ServiceXpress consists of various modules, which can be plugged together accordingto any customer's needs. The core of ServiceXpress is the SX Framework module,which contains all generic classes. For the administration of a concrete

telecommunication service, an SX Framework Application module must be pluggedinto the SX Framework module. The SX Framework Application modules contain alltelecommunication service specific classes.

The following figure shows the modular software architecture.

The SX Framework is the link between the external systems, which are representedby SX Plugins, and the SX Framework Applications, which implement the businesslogic for specific topics.

The SX Framework Applications do not directly access the SX Plugins. They useservices from the SX Framework to use the functionality provided by the Plugins. TheSX Framework defines interfaces, which are driven by generic SX Frameworkfunctionality. These interfaces therefore have to be resolved by the Plugins.

The database is split into an SX Framework database, which stores all SXFramework data (like users, orders,...) and an SX Framework Application database.The SX Framework Application is responsible for the structure of the seconddatabase. The SX Framework has no access to these application specific databases.An SX Framework Application has access to the SX Framework database, but only

by using the SX Framework Components, not directly.

The Client Applications represent the user interfaces for the SX FrameworkApplications.


57/76



57

Siemens ServiceXpress Framework Software Architecture

Fig. 31

The generic SX Client Applications represent the user interfaces for the SXFramework.

There are the following generic Client Applications:

Administration Order Manager. The Administration Order Manager provides aninterface for viewing and managing asynchronous orders that are controlled by theOrder Management Component.

Configuration Manager. The Configuration Manager provides an interface for theconfiguration of all SX Framework Components as well as SX FrameworkApplications and Plugins.

Error Viewer.The Error Viewer allows to view the errors stored in the database.

Logging Viewer.The Logging Viewer provides an interface for selecting andviewing logging records stored in a database.

Task Manager. The Task Manager displays all SX tasks and provides variousoperations to change the state of tasks.

User Manager. The User Manager provides an interface for managing SX usersand their data.


58/76


MN2976EU03MN_0001

2002 Siemens AG

58

The Location Platform core software (GMLC Base, GBASE) is part of the SXFramework.


59/76


60/76


MN2976EU03MN_0001

2002 Siemens AG

60

4.2 What is CORBA?

The Common Object Request Broker Architecture (CORBA) allows distributedapplications to interoperate (application to application communication), regardless ofwhat language they are written in or where these applications reside.

The CORBA specification was adopted by the Object Management Group(www.omg.org) to address the complexity and high cost of developing distributedobject applications. CORBA uses an object-oriented approach for creating softwarecomponents that can be reused and shared between applications. Each objectencapsulates the details of its inner workings and presents a well-defined interface,which reduces application complexity. The cost of developing applications is reduced,because once an object is implemented and tested, it can be used over and overagain.

The Object Request Broker (ORB) connects a client application with the objects itwants to use. The client program does not need to know whether the objectimplementation it is in communication with resides on the same computer or islocated on a remote computer somewhere on the network. The client program onlyneeds to know the objects name and understand how to use the objects interface.

The ORB takes care of the details of locating the object, routing the request, andreturning the result.

The ORB itself is not a separate process. It is a collection of libraries and networkresources that integrates within end-user applications, and allows your client

applications to locate and use objects via requests.

CORBA has several mechanisms to handle these requests. The client can use thefollowing:

IDL stub.An interface that is completely defined in the IDL and tied to a specifictarget object.

Dynamic invocation. A general interface that is independent of the target objectinterface.

The client also can talk directlyto the ORB, but this is used only rarely.

The programmer selects which of the two types of skeleton interfaces through whichthe object implementation will receive requests from a client:

Static IDL skeleton. A static interface defined in the IDL

Dynamic skeleton. A general interface for receiving requests

The object implementation may decide to communicate with either the ORB or theobject adapter, which the ORB provides, while it is processing a request. The objectadapter is the primary method of communication with the ORB and its services.


61/76



61

What is CORBA?

ORB (Object Request Broker)

ClientObject

Implementation

Fig. 33

What is CORBA?

ORB

ClientObject

Implementation

IDL

stubs

Dynamic

invocation

ORB

interface

StaticIDL

skeleton

Dynamic

skeleton

ORB Object Request Broker

IDL Interface Definition Language

Object

adapter

Fig. 34


62/76


MN2976EU03MN_0001

2002 Siemens AG

62

IDL

IDL (interface definition language) is a generic term for a language that lets aprogram or object written in one language communicate with another program written

in an unknown language. In distributed object technology, it's important that newobjects be able to be sent to any platform environment and discover how to run inthat environment. An Object Request Broker (ORB) is an example of a program thatwould use an interface definition language to "broker" communication between oneobject program and another one.

An interface definition language works by requiring that a program's interfaces bedescribed in a stub or slight extension of the program that is compiled into it. Thestubs in each program are used by a broker program to allow them to communicate.

stub

A stub is a small program routine that substitutes for a longer program, possibly to beloaded later or that is located remotely. For example, a program that uses RemoteProcedure Calls (RPC) is compiled with stubs that substitute for the program thatprovides a requested procedure. The stub accepts the request and then forwards it(through another program) to the remote procedure. When that procedure hascompleted its service, it returns the results or other status to the stub which passes itback to the program that made the request.

IIOP

IIOP (Internet Inter-ORB Protocol), pronounced "eye-op", is a protocol that makes itpossible for distributed programs written in different programming languages tocommunicate over the Internet. IIOP is a critical part of a strategic industry standard,the Common Object Request Broker Architecture (CORBA). Using CORBA's IIOPand related protocols, a company can write programs that will be able tocommunicate with their own or other company's existing or future programs whereverthey are located and without having to understand anything about the program otherthan its service and a name.


63/76



63

What is CORBA?

ORB 1

Client

IDLstubs

Dynamicinvocation

ORBinterface

ORB Object Request Broker

IDL Interface Definition Language

IIOP Internet Inter ORB Protocol

ORB 2

Object

Implementation

ORBinterface

StaticIDL

skeleton

Dynamicskeleton

Object

adapter

IIOP

Fig. 35


64/76


MN2976EU03MN_0001

2002 Siemens AG

64

4.3 What is VisiBroker?

VisiBroker is one of three editions of the Borland Enterprise Server.VisiBroker Edition provides a complete CORBA 2.4 ORB runtime and supportingdevelopment environment for building, deploying, and managing distributed for bothC++ and Java applications that are open, flexible, and inter-operable. Objects builtwith VisiBroker Edition for Java and C++ are easily accessed by Web-basedapplications that communicate using OMGs Internet Inter-ORB Protocol (IIOP)standard for communication between distributed objects through the Internet orthrough local intranets. VisiBroker Edition has a built-in implementation of IIOP thatensures high-performance and inter-operability.

VisiBroker Edition Smart Agent architecture

VisiBroker Editions Smart Agent (OSAgent) is a dynamic, distributed directoryservice that provides facilities for both client applications and object implementations.

Multiple Smart Agents on a network cooperate to provide load balancing and highavailability for client access to server objects. The Smart Agent keeps track of objectsthat are available on a network, and locates objects for client applications atinvocation time. VisiBroker Edition can determine if the connection between yourclient application and a server object has been lost, due to an error such as a servercrash or a network failure. When a failure is detected, an attempt is automaticallymade to connect your client to another server on a different host, if it is so configured.

Gatekeeper

Gatekeeper is an OMG-CORBA compliant GIOP Proxy Server developed by BorlandSoftware Corporation, which enables CORBA clients and servers to communicateacross networks, while still conforming to security restrictions imposed by Internetbrowsers, firewalls and Java sandbox security. In effect, Gatekeeper serves as agateway or proxy for clients and servers when security restrictions prevent clientsfrom communicating with the servers directly. Gatekeeper is often used when you donot want to expose the server directly to clients or when a clients access to theserver is restricted. In latter case, the client is an unsigned applet or there is anintervening firewall.

Gatekeeper uses the Smart Agent to locate server objects. Gatekeeper canautomatically locate the Smart Agent if one is found in the same network. When thereis no Smart Agent running in the same network where Gatekeeper runs, the locationof the Smart Agent has to be specified explicitly. This can also be used to specifyadditional Smart Agent running in other networks.


65/76



65

Web Edition components

VisiBroker Edition

AppServer Edition

Fig. 36

Gatekeeper - Smart Agent (osagent)

Gatekeeper

Smart

AgentClient

Object

Implementation 1

Object

Implementation 2

Object

Implementation 3

Objects register

at osagent

I like to use

Object 2

Where is

Object 2 ?

Proxy Service

with full security

Locates

Objects

Fig. 37


66/76


MN2976EU03MN_0001

2002 Siemens AG

66


67/76



67

5 Location platform hardware


68/76


MN2976EU03MN_0001

2002 Siemens AG

68

Market Trial

1x Sun Blade 150

1x Ulticom SS7 Card no performance guaranty

no high availability

Single Server

1x Sun Fire 280R (2 CPUs)

2x Ulticom SS7 Card

up to 100.000 TPH

Entry Level

2x Sun Fire 280R (2 CPUs)

4x Ulticom SS7 Card

2x Nortel Alteon ACE 184

up to 200.000 TPH

hardware load balancing, high availability

Mid Range Level

2 x Sun Fire 280R (2 CPUs) with 2 Ulticom SS7 Cards each

2 x Sun Fire 280R (2 CPUs) no SS7 cards


up to 400.000 TPH


High End Level

2 x Sun Fire 280R (2 CPUs) with 2 Ulticom SS7 Cards each

4 x Sun Fire 280R (2 CPUs) no SS7 cards


up to 600.000 TPH



69/76



69

Location Platform 3.0 Hardware Concept

Entry Level / Single Server

Mid-Range / High-End Level

SF 280

SS7

SF 280

SS7

SF 280

SS7

SF 280

SS7

Fig. 38


70/76


MN2976EU03MN_0001

2002 Siemens AG

70

5.1 High availability solution

The next figures show the proposed connection to the SS7 network. Two nodes of LP3.0 are equipped with two Ulticom SS7 cards and run the Ulticom cluster SW - also inthe case of a 4-node or 6-node installation. For Ulticom cluster internalcommunication both nodes are interconnected with two LANs (Ulticom LAN 1,Ulticom LAN 2) using one port from each Quad Ethernet card on both nodes.

Each Ulticom node (CE 1, CE 2) is connected to the SS7 network via the two UlticomSS7 cards. LP 3.0 supports a redundant connection to two STPs (STP1, STP2). ViaUlticom configuration two Linksets are defined, one from each CE to the STP 1 andthe other from each CE to the STP 2. For example, Linkset 1 consists of 8 Links fromCE 1 to STP 1 and 8 Links from CE 2 to STP 1. Linkset 2 consists of 8 Links from CE1 to STP 2 and 8 Links from CE 2 to STP 2. For each Destination Point Code (DPC),which means HLR or MSC, a route must be defined which uses both Linksets andhas defined UseLoadShare=yes, which means a load sharing over both Linksets. Inother words the CE 1 respectively CE 2 uses Linkset 1 and Linkset 2 in a round robinmanner to perform load sharing over the 2 STPs for addressing the DPC (HLR orMSC).

The number of required SS7 links depend on the used service mix (ATI, Lg / Lh, Pre-paging) and the traffic load.


71/76



71

linkset 1 linkset 2

SunFire 280SunFire 280

HTTP message

handling services

Signalware

interconnect

SS7 messagehandling services

Location services

virtual machine

Common services

HTTP message

handling services

SS7 message

handling services

Location services

Common services

Location Platform 3.0 High Availability Solution

HW Load Balancer HW Load Balancer

SW basedload balancing

SS7 #1 SS7 #2 SS7 #3 SS7 #4

STP 1 STP 1

MSC HLR

e.g. 8 links

Fig. 39


72/76


MN2976EU03MN_0001

2002 Siemens AG

72

Load distribution:

The LP 3.0 HA Configuration is reachable via the public LAN. On the public LAN a

load balancer is connected which offers the IP address for LP 3.0. A second loadbalancer exists as backup which has a doubled interconnect to the first loadbalancer. Each of the load balancers is connected to two internal LANs.

The load balancer forwards connection requests to the HTTP MHS running on the LP3.0 nodes. Each LP 3.0 node runs multiple HTTP processes on different internal portnumbers. Each HTTP process contacts the Location process via CORBA, whereby aredundancy over all LP 3.0 nodes is available.


73/76



73

linkset 1 linkset 2

PAS / CE1

SX Framework

Singalware

Apache

Interbase

Location Platform 3.0

High Availability Solution

HW Load Balancer HW Load Balancer

SS7 #1 SS7 #2

STP 1 STP 1

MSC HLR

SAS 1 / CE2

SX Framework

Singalware

SS7 #3 SS7 #4

SAS 2 / CE3

SX Framework

Singalware

SAS 3 / CE4

SX Framework

Singalware

SAS 4 / CE5

SX Framework

Singalware

SAS 5 / CE6

SX Framework

Singalware

Signalware interconnect

Fig. 40

8/12/2019 02 Mn2976eu03mn 0001 Loc Platf

Documents

02 Mn2976eu03mn 0001 Loc Platf Archit Feat