02 mn2976eu03mn 0001 loc platf archit feat
Post on 03-Jun-2018
229 Views
Preview:
TRANSCRIPT
-
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
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
2/76
Siemens Location platform architecture - features
MN2976EU03MN_0001
2002 Siemens AG
2
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
3/76
Location platform architecture - features Siemens
MN2976EU03MN_00011 2002 Siemens AG
3
1 Location platform architecture
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
4/76
Siemens Location platform architecture - features
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
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
5/76
Location platform architecture - features Siemens
MN2976EU03MN_00011 2002 Siemens AG
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
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
6/76
Siemens Location platform architecture - features
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.
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
7/76
Location platform architecture - features Siemens
MN2976EU03MN_00011 2002 Siemens AG
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/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
8/76
Siemens Location platform architecture - features
MN2976EU03MN_0001
2002 Siemens AG
8
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
9/76
Location platform architecture - features Siemens
MN2976EU03MN_00011 2002 Siemens AG
9
2 Location platform 3.0 features
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
10/76
Siemens Location platform architecture - features
MN2976EU03MN_0001
2002 Siemens AG
10
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
11/76
Location platform architecture - features Siemens
MN2976EU03MN_00011 2002 Siemens AG
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.
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
12/76
Siemens Location platform architecture - features
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)
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
13/76
Location platform architecture - features Siemens
MN2976EU03MN_00011 2002 Siemens AG
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
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
14/76
Siemens Location platform architecture - features
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.
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
15/76
Location platform architecture - features Siemens
MN2976EU03MN_00011 2002 Siemens AG
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.
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
16/76
Siemens Location platform architecture - features
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
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
17/76
Location platform architecture - features Siemens
MN2976EU03MN_00011 2002 Siemens AG
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
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
18/76
Siemens Location platform architecture - features
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)
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
19/76
Location platform architecture - features Siemens
MN2976EU03MN_00011 2002 Siemens AG
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
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
20/76
Siemens Location platform architecture - features
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
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
21/76
Location platform architecture - features Siemens
MN2976EU03MN_00011 2002 Siemens AG
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
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
22/76
Siemens Location platform architecture - features
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).
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
23/76
Location platform architecture - features Siemens
MN2976EU03MN_00011 2002 Siemens AG
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
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
24/76
Siemens Location platform architecture - features
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"
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
25/76
Location platform architecture - features Siemens
MN2976EU03MN_00011 2002 Siemens AG
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.
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
26/76
Siemens Location platform architecture - features
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.
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
27/76
Location platform architecture - features Siemens
MN2976EU03MN_00011 2002 Siemens AG
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
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
28/76
Siemens Location platform architecture - features
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.
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
29/76
Location platform architecture - features Siemens
MN2976EU03MN_00011 2002 Siemens AG
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
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
30/76
Siemens Location platform architecture - features
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.
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
31/76
Location platform architecture - features Siemens
MN2976EU03MN_00011 2002 Siemens AG
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
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
32/76
Siemens Location platform architecture - features
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.
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
33/76
Location platform architecture - features Siemens
MN2976EU03MN_00011 2002 Siemens AG
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
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
34/76
Siemens Location platform architecture - features
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.
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
35/76
Location platform architecture - features Siemens
MN2976EU03MN_00011 2002 Siemens AG
35
Location Platform Configuration Manager
Fig. 17
Location Platform Task Manager
Fig. 18
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
36/76
Siemens Location platform architecture - features
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.
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
37/76
Location platform architecture - features Siemens
MN2976EU03MN_00011 2002 Siemens AG
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
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
38/76
Siemens Location platform architecture - features
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.
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
39/76
Location platform architecture - features Siemens
MN2976EU03MN_00011 2002 Siemens AG
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
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
40/76
Siemens Location platform architecture - features
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.
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
41/76
Location platform architecture - features Siemens
MN2976EU03MN_00011 2002 Siemens AG
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
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
42/76
Siemens Location platform architecture - features
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.
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
43/76
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
44/76
Siemens Location platform architecture - features
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.
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
45/76
Location platform architecture - features Siemens
MN2976EU03MN_00011 2002 Siemens AG
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
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
46/76
Siemens Location platform architecture - features
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.
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
47/76
Location platform architecture - features Siemens
MN2976EU03MN_00011 2002 Siemens AG
47
Overload
DetectionService
Fig. 26
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
48/76
Siemens Location platform architecture - features
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.
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
49/76
Location platform architecture - features Siemens
MN2976EU03MN_00011 2002 Siemens AG
49
Read Delay
on HTTP(s)
Connections
Fig. 27
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
50/76
Siemens Location platform architecture - features
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
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
51/76
Location platform architecture - features Siemens
MN2976EU03MN_00011 2002 Siemens AG
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
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
52/76
Siemens Location platform architecture - features
MN2976EU03MN_0001
2002 Siemens AG
52
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
53/76
Location platform architecture - features Siemens
MN2976EU03MN_00011 2002 Siemens AG
53
4 Location platform 3.0 software components
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
54/76
Siemens Location platform architecture - features
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
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
55/76
Location platform architecture - features Siemens
MN2976EU03MN_00011 2002 Siemens AG
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
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
56/76
Siemens Location platform architecture - features
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.
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
57/76
Location platform architecture - features Siemens
MN2976EU03MN_00011 2002 Siemens AG
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.
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
58/76
Siemens Location platform architecture - features
MN2976EU03MN_0001
2002 Siemens AG
58
The Location Platform core software (GMLC Base, GBASE) is part of the SXFramework.
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
59/76
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
60/76
Siemens Location platform architecture - features
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.
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
61/76
Location platform architecture - features Siemens
MN2976EU03MN_00011 2002 Siemens AG
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
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
62/76
Siemens Location platform architecture - features
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.
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
63/76
Location platform architecture - features Siemens
MN2976EU03MN_00011 2002 Siemens AG
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
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
64/76
Siemens Location platform architecture - features
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.
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
65/76
Location platform architecture - features Siemens
MN2976EU03MN_00011 2002 Siemens AG
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
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
66/76
Siemens Location platform architecture - features
MN2976EU03MN_0001
2002 Siemens AG
66
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
67/76
Location platform architecture - features Siemens
MN2976EU03MN_00011 2002 Siemens AG
67
5 Location platform hardware
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
68/76
Siemens Location platform architecture - features
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
2x Nortel Alteon ACE 184
up to 400.000 TPH
hardware load balancing, high availability
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
2x Nortel Alteon ACE 184
up to 600.000 TPH
hardware load balancing, high availability
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
69/76
Location platform architecture - features Siemens
MN2976EU03MN_00011 2002 Siemens AG
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
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
70/76
Siemens Location platform architecture - features
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.
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
71/76
Location platform architecture - features Siemens
MN2976EU03MN_00011 2002 Siemens AG
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
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
72/76
Siemens Location platform architecture - features
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.
-
8/12/2019 02 Mn2976eu03mn 0001 Loc Platf Archit Feat
73/76
Location platform architecture - features Siemens
MN2976EU03MN_00011 2002 Siemens AG
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
top related