02 Mn2976eu03mn 0001 Loc Platf Archit Feat

Location platform architecture - features Siemens
MN2976EU03MN_00011
2002 Siemens AG
1
Contents
1 Location platform architecture 3
1.1 The LCS interfaces 4
1.2 Functional blocks and interfaces 6
2 Location platform 3.0 features 9
2.1 API 1 features 11
2.2 SS7 network interface 20
2.3 Core features 22
2.4 Operation and maintenance features 32
3 Network integration 50
3.1 CAMEL-based ATI positioning in GSM and UMTS 50
3.2 LCS standard positioning in GSM and UMTS R99 51
4 Location platform 3.0 software components 53
4.1 Siemens SX framework 56
4.2 What is CORBA? 60
4.3 What is VisiBroker? 64
5 Location platform hardware 67
5.1 High availability solution 70

Location platform architecture - features
Siemens Location platform architecture - features

MN2976EU03MN_0001
2002 Siemens AG
2

MN2976EU03MN_00011
2002 Siemens AG
3
1 Location platform architecture

MN2976EU03MN_0001
2002 Siemens AG
4

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

Serving Mobile Location Center (SLMC)
L
b
interface. Interface between the BSC and the SMLC
L
p
interface. Interface between two SMLC
L
s
interface. Interface between the SMLC and the MSC/VLR
Location Enabling Server (LES)
L
e
interface (API2). Interface between an External LCS Client (Application) and
the LES. This interface is also called API2.
API1. Interface between Location Platform and LES
Location Platform
L
g
interface. Interface between the Location Platform and the MSC/VLR. Thereby,
the Location Platform can also belong to a different PLMN.
L
h
interface. Interface between the Location Platform and the HLR
API1. Interface between Location Platform and LES


MN2976EU03MN_00011
2002 Siemens AG
5

BTS BSC
MSC /
VLR
External
LCS Client
CBC
S-
MLC
S-
MLC
HLR
G-
MLC
Abis
A
Lg
Lg
Le/
API2
Lp
Lh
Lb CBC-
BSC
CBC-
SMLC
Um
D
MLC Mobile Location Center (Serving/Gateway)
Lx LCS Interfaces
Different
PLMN
Ls
G-MLC
LES/GTB
API1
Location
Platform

Fig. 1
Location Platform 3.5 main functionality and interfaces
NMS
(IP-
Manager)
Logging
/ Billing
LES
Location Platform 3.5
Provides location information
from mobile core or handset to
IP-world
Provides presence information
from mobile core to IP-world
for 2G, 2.5G and 3G networks
Standard compliant interfaces
Location Server User plane
support (LSU)
SNMP-integration into O&M
system
Electronic Data Records for
logging of location requests
Provides location information
from mobile core or handset to
IP-world
Provides presence information
from mobile core to IP-world
for 2G, 2.5G and 3G networks
Standard compliant interfaces
Location Server User plane
support (LSU)
SNMP-integration into O&M
system
Electronic Data Records for
logging of location requests
Logging
Data
M
O
B
I
L
E

N
E
T
W
O
R
K
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

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 and
its location services (e.g. tracing, logging and task management). They provide
OA&M clients with access to the Location Platform via CORBA interfaces. They
provide external operation systems with alarms and performance data via SNMP.

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

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


MN2976EU03MN_00011
2002 Siemens AG
7

Location Platform Software Architecture
Common Services Location Services
Error and
Performance
Management
License
Service
Trace
Service
User
Administra-
tion Service
Configura-
tion Service
Backup &
Restore
Service
Installation
Service
Load
Detection
Service
DB
LCS Client
Handling
Service
Cell Id
Translation
Service
Cache
Service
Logging
Service
API-1
Adapter
MLP
Services
HTTP Message Handling Sservices
core network elements (HLR, MSC, SGSN)
NMS
OAM
Console
LES MPM
Direct
Clients
API-1 V1.1/2.0 API-1 V2.0
Lg/Lh, ATI, SRI/PSI, SM-MT
Admin
Files
ftp: Cell-table upload
Auxiliary
Common
Services
SS7 Service
MAP
Adapter
SMLC
WAP-GW /
PPG
(MSP)
WAP
Adapter
SLS
Adapter

Fig. 3

MN2976EU03MN_0001
2002 Siemens AG
8


MN2976EU03MN_00011
2002 Siemens AG
9

2 Location platform 3.0 features

MN2976EU03MN_0001
2002 Siemens AG
10


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.1
and API-1 V2. Both interfaces use the same connection handling provided by the
internal Message Handling Service.
The API-1 Interface the Location Platform offers sockets based communication
channels for LCS clients. It offers both secure (HTTPS) and insecure (HTTP)
connections on different configurable port numbers. On secure connections a
certificate is presented to the client on connection establishment.
LP 3.0 offers a unique URL address and a limited configurable number of parallel
connections 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 start
sending HTTP(S)/1.1 POST Requests, each one containing a single API-1 Location
Request message. LP 3.0 allows (and expects) that the client sends more than a
single 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) header
field Connection that a connection should be kept. In this case, LP 3.0 keeps the
connection open until the client explicitly indicates a connection close or until a
connection 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. Pending
HTTP(S) Re-quests are processed and answered. In case a connection was closed
abnormally on the client side the HTTP MHS is able to detect this and to act
accordingly, i.e. to close the connection and discard all pending requests and
responses.
Authorization on http level is a configurable option on API-1 V1.1 to ensure upward
compatibility to LR 2.0.If activated API 1 clients must provide valid authorization
information 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.


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-based
applications.
The API-1 is an application-level protocol for querying the position of mobile terminals
independent of the underlying network technology. API-1 V1.1 supports the Standard
Location Immediate Service and the Emergency Location Immediate Service
following LIF V1.1 specifications.
Authentication of the LCS Client is done by means of the HTTP protocol or
ID/password as provided in the XML request parameters.

The Standard Location Immediate Service is used when a single location response
is 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 Service is used to retrieve the position of a
mobile sub-scriber / user equipment in an emergency situation. The response to this
service 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 Standard
Location 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 Type
indicates an emergency client and the LCS Priority is set to high.

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

The service consists of the following message:
Emergency Location Report (ELR)


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 1
Location Info
XML/HTTP(S)
Location Platform

Fig. 4

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 on
HTTP 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 mobile
terminals independent of underlying network technology.
Authentication of the Client performing a location request is done by means of the
API-1 parameters clientID and password. No subscriber-related information is used
for authentication.
API-1 V2.0 offers the following services according to LIF MLP 3.0 specifications:
The Standard Location Immediate Service is used for requesting the location of a
Mobile Subscriber. The service is used when a location response is required
immediately (within a set time). In the request, the LCS client can choose between a
synchronous and an asynchronous variant of this service. Asynchronous requests
are new in MLP 3.0 and reduce the number of concurrent http-connections that must
be 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 Service is used to retrieve the position of a
mobile sub-scriber / user equipment that is involved in an emergency call or has
initiated an emergency service in some other way. The response to this service is
required 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 Standard
Location 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 Type
indicates an emergency client and the LCS Priority is set to high.


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 or
IMSI. Identification based on IMSI supports certain operator scenarios to handle
number portability as the subscribers HPLMN is uniquely identified by IMSI as
opposed 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.

MN2976EU03MN_0001
2002 Siemens AG
16

The Emergency Location Reporting Service is used when the mobile network
initiates the positioning of an emergency call using the network-initiated Location
Request (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 is
configurable on LP 3.0. Note that in this case LP 3.0 initiates the dialog instead of the
LCS client.

This service consists of the following message:
Emergency Location Report


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.0
Emergency Report
XML/HTTP(S)
Location Platform
(Server)

Fig. 6


MN2976EU03MN_0001
2002 Siemens AG
18

The Subscriber State Service is an extension of MLP V3.0.0. This service enables
the MPM and Direct LCS Clients to obtain the subscriber status from the SS7
network. Possible states are:
CamelBusy: The MS is engaged in a transaction for a mobile originating or
terminated circuit-switched call.
NetworkDeterminedNotReachable: The network can determine from its internal
data that the MS is not reachable. The MAP standard 3GPP TS 29.002 defines
four 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 subscriber
state 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 with
HTTP 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 are
registered 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)


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 four
sub-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.0
Location Info
XML/HTTP(S)
Location Platform
(Server)
Mobile Presence
Manager
(Client)
API 1 v2.0
Subscriber State
XML/HTTP(S)
Location Platform
(Server)

Fig. 7

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 TCAP
API 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 specifications
like notably the US and Chinese market. The SCCP dialect to use in LP 3.0 is
configured according the HPLMN. Roaming support on SS#7 is restricted to networks
using 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 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 signaling point codes (instead of 14
Bit) 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


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 VMSC
and 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
VLR
SGSN
Camel
Based
ATI
HLR
VLR
PSI
SMS
HLR
VMSC
VLR
MAP
Based
PSI

Fig. 9

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 cell
table on LP 3.0 in order to get a received CGI translated into the corresponding
shape.
This service is triggered whenever LP 3.0 is configured for explicit cell-ID translation
and a SLIR provides a CGI. In this case, the MSID is not evaluated and may take an
arbitrary value. The SS#7 network is not accessed, instead the CGI is translated into
a 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 by
LES, LP 3.0 will not perform any positioning procedures but just resolve the CGI via
its cell-table.

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


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


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 reduce
SS#7 communication and to provide the best possible position estimate in failure
situations.
IP-based roaming support is triggered by reception of a VLRId and/or CGI on API-1
V1.1 or a VMSCId and/or CGI on API-1 V2.0. Dependent on the capability of the
VLR/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 a
more actual and more accurate position estimate.
In case of an error during positioning, the position based on the CGI if available is
returned.
LP 3.0 can be forced to cell-ID translation in case a CGI is available by activating the
Explicit 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 by
AnyTimeInterrogation towards the HLR. If a CGI is already provided additionally in
the 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 described
later.

2.3.3 Pre-standard roaming support on API-1
As a configurable option LP 3.0 supports special return codes to indicate roaming
scenarios and to support the IP-based roaming procedures of LES:
If Location Information is obtained via ATI and a VMSC/VLR address and CGI (or
optional a UGAD Shape) from outside the home domain is returned:
API-1v1.1: "303 PRESTANDARD ROAMING"
API-1v2.0: "503 PRESTANDARD ROAMING"


MN2976EU03MN_00011
2002 Siemens AG
25

Return of
VMSC 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 parameters
VMSCaddress or CGI is returned, i.e. ATI did not return enough information to derive
a 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 part
of 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 in
specific the Location Enabling Server to trigger IP-based roaming procedures and to
use 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 explicit
Cell Id Translation, thus avoiding further SS7 traffic.


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 cached
information is used or not. The caching service is available for all location request on
API-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-1
parameter resp_req_type = NO_DELAY) and accepts the current or last known
location (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 failed
and the API-1 client also accepts the last known location (API-1 parameter
loc_type_type = CURRENT_OR_LAST).
An API-1 client has set the max_loc_age parameter in an API-1 V2.0 request. The
cache is accessed to find out if it holds recent enough position information for the
requested MSISDN / IMSI. If max_loc_age is specified, the cache is accessed
independent of the settings of resp_req_type and loc_type_type. If there's no
cache entry, or the location information in the cache is too old, then the SS7
network 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-1
parameter 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 or
CURRENT 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 prior
access attempt to the cache has failed.
LES or Direct LCS Client has set the max_loc_age parameter, but the cache did
not contain any, or too old location information for the MSISDN or IMSI.


MN2976EU03MN_00011
2002 Siemens AG
27

LOW_DELAY,
DELAY_TOLERATED or
Parameter RESP_TIMER
set
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.
1
st
preference: cache
access with respect to
max_loc_age
2
nd
preference: SS7
network access if no cache
hit or cache info out of date
Only cache access.
1
st
preference: cache
access with respect to
max_loc_age
2
nd
preference: SS7
network access if no cache
hit or cache info out of date
Only cache access.

Fig. 12

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. These
are the Commercial LCS, the Internal LCS, the Emergency LCS and the Lawful
Intercept LCS. The LP 3.0 supports all these different clients.
The Commercial LCS (or Value Added Services) will typically be associated with
an application that provides a value-added service through knowledge of the UE
location to the subscriber of the service. This may be, for example, a directory of
restaurants in the local area of the UE, together with directions for reaching them
from the current UE location.
The Internal LCS will typically be developed to make use of the location
information of the UE for Access Network internal operations. This may include; for
example, location assisted hand-over and traffic and coverage measurement. This
may also include support certain O&M related tasks, supplementary ser-vices, IN
related 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 is
provided to the emergency service provider to assist them in their response. This
service 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 various
legally 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 Location
Enabling 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 client
types. The client type attribute controls client authorization to use the LP 3.0 location
services according to the following table.
The client type will not influence request processing with the exception of Lawful
interception clients, which will not be logged and for which no EDRs will be
generated.
The client type is provided on the SS#7 interface in the case of LCS standard
positioning. Requests from LES (not supported on SS#7) are mapped to client type
VAS for SLIR and to client type Emergency for ELIR. Clients of type Presence
Manager are not allowed to issue positioning requests, thus a mapping to the LCS
standard is obsolete.


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

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 of
all 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 may
share the same LP 3.0 installation for subscriber positioning. This may be interesting
for regionally cooperating small operators or within an operator group.
Positioning can be enabled for subscribers roaming within the home domain, while it
is 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 integrate
seamless 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 of
different 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 "207
Misconfiguration of location server" plus an ADD-INFO, indicating that LP 3.0 was not
able to derive the HLR-Id from the MSISDN/IMSI.


MN2976EU03MN_00011
2002 Siemens AG
31

ASP Domain
Multiple Home Network Support in LP 3.0
Support of multiple
operator 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
data
Cell-ID
data
Roaming
(+43676)

Fig. 14


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 assigned
user roles. It provides a GUI for administrator management. Multiple roles can be as-
signed to an administrator login. The User Administration Service defines a system
wide 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 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 creator and 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.

Access Control
LP 3.0 authenticates administrators by user name and password. Service access
authorizations are assigned to user roles by configuration. Administrators may have
multiple user roles assigned.


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 creator
and 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

MN2976EU03MN_0001
2002 Siemens AG
34

2.4.2 Configuration service
Configuration Management in LP 3.0 is implemented as a centralized file system
based solution using Java property files. The Configuration Service provides an
access control mechanism to the property files and a GUI. Instead of the GUI
administrators 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 a
service regardless in how many tasks the service is running.
HA Configurations
In HA Configurations with multiple nodes one node is configured as Primary
Application Server (PAS). Updates of configuration parameters always occur initially
on the PAS. All other nodes are configured as Secondary Application Servers (SAS).
They listen to changes in the PAS configuration parameters and update their local
configuration 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 defined
sequence, controlled by configuration parameters. The Task Manager Service
supervises 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 the
administrator stops a task manually the task remains stopped until it is explicitly re-
started. After a shutdown with automatic restart tasks deactivated by configuration
parameters remain deactivated.
Every node in a HA configuration executes its own Task Manager Service instance
which controls the tasks on this node. Task Manager Service instances on different
nodes 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 supervising
Task Manager Service instance sends an alarm.
Standard shut down of LP 3.0 is performed by a GUI provided by the Task Manager
Service, while emergency shut down can be done by a start / stop script. Standard
shutdown affects all nodes in a HA configuration. Emergency shut down only affects
an individual node. In both cases the shutdown procedure (via a stop signal to the
UNIX 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 product
tasks, Web Server tasks.


MN2976EU03MN_00011
2002 Siemens AG
35

Location Platform Configuration Manager

Fig. 17
Location Platform Task Manager

Fig. 18


MN2976EU03MN_0001
2002 Siemens AG
36

2.4.4 Error service
The Error Service provides an interface for error reporting and exception handling if
any 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. Exceptions
are returned to the requesting object, which uses the Error Service to register those
exceptions that they consider to be an error and to create CORBA exceptions for
trans-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) by
SNMP (via SNMP Service). Alternatively the Error Service provides a GUI for local
error examination.

2.4.5 SNMP service
Alarm Messages SNMP Traps
The SNMP Service provides an interface used by the Error Service forward errors
and alarms to a Network Management System, e.g. the IP Manager. The SNMP
Service supports SNMP V1.0. The alarm messages are stored by the Error Service in
the DB on the PAS. Sending of alarms is possible from each LP 3.0 node
autonomously.
LP 3.0 sends SNMP traps distinguishable by
Category and
Severity
LP 3.0 supports the categories Error and Threshold. The category Error is used
for all traps generated by the Error Service. The category Threshold is used by the
Performance Management Service when reporting reached thresholds.
The software production procedure creates trapinfo.xml files for definition of the
traps. They are created within one configurable directory. The situations of Alarm
Reporting are described in detail in the appendix in Table 36.

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


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
GET Performance
Management
Service
SNMP Traps
Category Threshold

Fig. 19


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 of
two parts, a fixed header with the searchable key fields and a variable part which
contains the log specific data in ASCII format.
The header itself also consists of two parts: the fixed descriptor of the logging entry
and 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 the
database.
Detail Logging On/Off. If detail logging is off no variable part is written to the
database.
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 logging
records 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, the
header is a comma separated list of values of the original header fields. Optionally
this header can be overwritten with column (field) names defined by configuration
parameters.
The start time and frequency of export of logging records is configurable as well as
some filter criteria controlling which logging records are exported.
It is the responsibility of the administrator to remove old exported logging files. If the
file system has not enough space to hold the logging files the Logging Service
reports the problem as critical error to alert the administrator. Periodical export of
logging 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 of
logging records fails for another reason the problem will be reported as error, but
periodical exporting is not suspended.
The administrator may start the file writer manually using shell commands if exporting
of logging records failed at the scheduled time, or for creating additional logging files
with a different time range.
The information which logging records have been exported, is stored in a database
table.


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

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 location
requests 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:
CHARGING records contain the information who issued a request, who was
located and further charging relevant information; but no indication of the tracked
subscribers location.
LOCATION records contain the location of the tracked subscriber and further
statistically relevant information but no subscriber identification

For API-1 V1.1 requests/reports the following type of logging record is supported and
fully downwards compatible to LR 2.0
LR 2.0 format BILLING records contain information who issued a request, who
was located and further charging relevant information, but no indication of the
tracked subscribers location.
For each request, LP 3.0 writes either API V1.1 or API-1 V2.0 EDRs. This is
determined from the interface used. For Location reports (NI-LR), the type of EDR
to generate is a parameter of the client profile.

The following options can be configured for both charging and LR 2.0 format billing
records:
Charging Logging On/Off: If turned off no charging records or LR 2.0 format billing
records, respectively, are written.
Charging Logging File Path: Defines the path of the logging file.
Charging Max Logging Entries: Defines the maximum number of charging records
per 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 format
conversion for charging or LR 2.0 billing records. CSV-format conversion is used
as default.


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 further
charging relevant information but no indication of the tracked
File logging for charging of API-1 V2.0 requests and location statistics
CHARGING records: Who issued the request, who was located and
further charging relevant information but no indication of the trackes
LOCATION records: Where was the tracked subscriber location
information but no identification of the tracked subscriber. Used for
statistics 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 used
Helps 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, Accuracy
Delivered, Data Size, Content Category, Location Information

Fig. 22

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 provides
platform developers and maintenance personnel of LP 3.0 with debugging
information on a per service basis with several tracing levels that provide differently
detailed 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 one
trace 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 user
services, 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 GUI
is provided.


MN2976EU03MN_00011
2002 Siemens AG
43

Configure Trace Behavior for each Task

Fig. 23


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 an
administrator GUI or later file export. Counter values are accessible via SNMP and
SNMP traps are automatically generated when configured threshold values are
exceeded. 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 Service
which provides the generic functionality for storage, visualization and reporting
performance counters.

Usage Counters
The next table shows the events monitoring the usage of LP 3.0 interfaces.. The gray
lines contain the respective event group, the white ones single events. Node-specific
performance counters are provided for these events. They can be accessed via GUI
and SNMP. For HA configurations, accumulated counter values are provided on the
LP 3.0 GUI and on the Siemens IP Manager network management system. The client
part 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. The
GUI uses these interfaces. The GUI reads the values from the cache of the central
service due to performance reasons.

System Counters
In addition to incrementing counters the Performance Management Service provides
a mechanism to store hardware performance values. This method is used to register
hardware performance values as
CPU usage
memory usage
These performance values are accessed via sar -bru command of Solaris. As in
case of the normal incremental counters this mechanism stores the delivered values
into the database. The system counters are stored in a memory cache also in the
client part of the performance management service. As with counters the
Performance Management Service compares the received values with configurable
thresholds and informs the IP Manager when the thresholds are reached.


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

MN2976EU03MN_0001
2002 Siemens AG
46

2.4.10 Overload detection service
LP 3.0 manages the load on its external request interfaces, distributes requests
among multiple nodes in a HA configuration and skips request execution in case of
detected overload.
Internally, the Load Detection Service is responsible for gathering and reporting the
load situation (i.e. percent CPU idle) of all nodes in the HA configuration. The Load
Detection Service evaluates the load situation on all nodes periodically (e.g. 5
seconds) 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 load
situation. If an RPC call fails for a certain time period (e.g. 5 minutes) an alarm is
sent.


MN2976EU03MN_00011
2002 Siemens AG
47

Overload
Detection
Service

Fig. 26

MN2976EU03MN_0001
2002 Siemens AG
48

Overload control on API-1 is implemented by the HTTP message handler service and
the 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 is
reached, Further request handling is delayed until the next thread becomes
available. This keeps the needed system resources (threads) constant even in the
case of overload.
dispatches requests among the nodes of a HA installation. Dependent on load
measurements on all nodes, it forwards API-1 requests to API-1 Adapter
processes 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 delay
for the next request is introduced, where the delay time is adapted according to the
indicated load level.
Note that as all requests are received on the same port, no filtering of emergency
re-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 SLI
requests in overload situations. Since distribution of requests based on system-
wide load levels has already been done by the HTTP-MHS, the API1 Adapter only
evaluates CPU idle time of the local host. API1 Emergency Location Requests are
delivered 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 overload
related error messages to the Location Request Service. On occurrence of a
resource limitation the Location Request Service blocks all standard location
requests to the concerned SS7 network element for a configurable time. Similarly, in
case of network congestion the Location Request Service blocks all standard location
requests for a configurable time. The Location Request Service does not block any
emergency location requests.
When receiving location reports (NI-LR) from the SS7 network LP 3.0 all emergency
reports, regardless of its overload status. Mobile originated and deferred location re-
quests are discarded in overload situations with an appropriate SS7 error message.


MN2976EU03MN_00011
2002 Siemens AG
49

Read Delay
on HTTP(s)
Connections

Fig. 27

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
Location
Platform
(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
Um
PSI
PSI
Uu
Pre-standard GMLC/SMLC
functionality
MSC
Server
LES
(OMIP)
LCS
Roaming
GIS
Billing
User
Database
...
LES
(other PLMN)
API2
2G-
SGSN

Fig. 28


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
Capable
Mobile
Location
Platform
(GMLC)
2G-MSC
2G-
SGSN
BSC
External LCS
Clients
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
3G
SGSN
LES
GTB
API-1 API-2
RNC
BTS
Abis
Lb
Iur
Node
B
Iub
Node
B
Iub
SAG Location Server
Further LCS equipment
Core/Radio network
B&R
Backend infrastructure
Radio
Data

Fig. 29


MN2976EU03MN_0001
2002 Siemens AG
52


MN2976EU03MN_00011
2002 Siemens AG
53

4 Location platform 3.0 software components

MN2976EU03MN_0001
2002 Siemens AG
54

The following software components make up the Location Platform 3.0:

Sun Solaris 8 incl. SDS 4.2.1
Java 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


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

MN2976EU03MN_0001
2002 Siemens AG
56

4.1 Siemens SX framework
ServiceXpress is a homogeneous, secure and efficient tool for the administration of
distributed networks (e.g. telecommunication networks).

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

ServiceXpress consists of various modules, which can be plugged together according
to 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 plugged
into the SX Framework module. The SX Framework Application modules contain all
telecommunication service specific classes.
The following figure shows the modular software architecture.

The SX Framework is the link between the external systems, which are represented
by SX Plugins, and the SX Framework Applications, which implement the business
logic for specific topics.

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

The database is split into an SX Framework database, which stores all SX
Framework data (like users, orders,...) and an SX Framework Application database.
The SX Framework Application is responsible for the structure of the second
database. 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 Framework
Applications.


MN2976EU03MN_00011
2002 Siemens AG
57

Siemens ServiceXpress Framework Software Architecture

Fig. 31
The generic SX Client Applications represent the user interfaces for the SX
Framework.
There are the following generic Client Applications:

Administration Order Manager. The Administration Order Manager provides an
interface for viewing and managing asynchronous orders that are controlled by the
Order Management Component.
Configuration Manager. The Configuration Manager provides an interface for the
configuration of all SX Framework Components as well as SX Framework
Applications 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 and
viewing logging records stored in a database.
Task Manager. The Task Manager displays all SX tasks and provides various
operations to change the state of tasks.
User Manager. The User Manager provides an interface for managing SX users
and their data.

MN2976EU03MN_0001
2002 Siemens AG
58

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


MN2976EU03MN_00011
2002 Siemens AG
59

Fig. 32


MN2976EU03MN_0001
2002 Siemens AG
60

4.2 What is CORBA?
The Common Object Request Broker Architecture (CORBA) allows distributed
applications to interoperate (application to application communication), regardless of
what 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 distributed
object applications. CORBA uses an object-oriented approach for creating software
components that can be reused and shared between applications. Each object
encapsulates 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 over
again.
The Object Request Broker (ORB) connects a client application with the objects it
wants to use. The client program does not need to know whether the object
implementation it is in communication with resides on the same computer or is
located on a remote computer somewhere on the network. The client program only
needs 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, and
returning the result.
The ORB itself is not a separate process. It is a collection of libraries and network
resources 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 the
following:
IDL stub. An interface that is completely defined in the IDL and tied to a specific
target object.
Dynamic invocation. A general interface that is independent of the target object
interface.
The client also can talk directly to the ORB, but this is used only rarely.

The programmer selects which of the two types of skeleton interfaces through which
the 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 the
object adapter, which the ORB provides, while it is processing a request. The object
adapter is the primary method of communication with the ORB and its services.


MN2976EU03MN_00011
2002 Siemens AG
61

What is CORBA?
ORB (Object Request Broker)
Client
Object
Implementation

Fig. 33
What is CORBA?
ORB
Client
Object
Implementation
IDL
stubs
Dynamic
invocation
ORB
interface
Static
IDL
skeleton
Dynamic
skeleton
ORB Object Request Broker
IDL Interface Definition Language
Object
adapter

Fig. 34

MN2976EU03MN_0001
2002 Siemens AG
62

IDL
IDL (interface definition language) is a generic term for a language that lets a
program or object written in one language communicate with another program written
in an unknown language. In distributed object technology, it's important that new
objects be able to be sent to any platform environment and discover how to run in
that environment. An Object Request Broker (ORB) is an example of a program that
would use an interface definition language to "broker" communication between one
object program and another one.
An interface definition language works by requiring that a program's interfaces be
described in a stub or slight extension of the program that is compiled into it. The
stubs 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 be
loaded later or that is located remotely. For example, a program that uses Remote
Procedure Calls (RPC) is compiled with stubs that substitute for the program that
provides a requested procedure. The stub accepts the request and then forwards it
(through another program) to the remote procedure. When that procedure has
completed its service, it returns the results or other status to the stub which passes it
back to the program that made the request.

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


MN2976EU03MN_00011
2002 Siemens AG
63

What is CORBA?
ORB 1
Client
IDL
stubs
Dynamic
invocation
ORB
interface
ORB Object Request Broker
IDL Interface Definition Language
IIOP Internet Inter ORB Protocol
ORB 2
Object
Implementation
ORB
interface
Static
IDL
skeleton
Dynamic
skeleton
Object
adapter
IIOP

Fig. 35


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 supporting
development environment for building, deploying, and managing distributed for both
C++ and Java applications that are open, flexible, and inter-operable. Objects built
with VisiBroker Edition for Java and C++ are easily accessed by Web-based
applications that communicate using OMGs Internet Inter-ORB Protocol (IIOP)
standard for communication between distributed objects through the Internet or
through local intranets. VisiBroker Edition has a built-in implementation of IIOP that
ensures high-performance and inter-operability.

VisiBroker Edition Smart Agent architecture
VisiBroker Editions Smart Agent (OSAgent) is a dynamic, distributed directory
service that provides facilities for both client applications and object implementations.
Multiple Smart Agents on a network cooperate to provide load balancing and high
availability for client access to server objects. The Smart Agent keeps track of objects
that are available on a network, and locates objects for client applications at
invocation time. VisiBroker Edition can determine if the connection between your
client application and a server object has been lost, due to an error such as a server
crash or a network failure. When a failure is detected, an attempt is automatically
made 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 Borland
Software Corporation, which enables CORBA clients and servers to communicate
across networks, while still conforming to security restrictions imposed by Internet
browsers, firewalls and Java sandbox security. In effect, Gatekeeper serves as a
gateway or proxy for clients and servers when security restrictions prevent clients
from communicating with the servers directly. Gatekeeper is often used when you do
not want to expose the server directly to clients or when a clients access to the
server is restricted. In latter case, the client is an unsigned applet or there is an
intervening firewall.
Gatekeeper uses the Smart Agent to locate server objects. Gatekeeper can
automatically locate the Smart Agent if one is found in the same network. When there
is no Smart Agent running in the same network where Gatekeeper runs, the location
of the Smart Agent has to be specified explicitly. This can also be used to specify
additional Smart Agent running in other networks.


MN2976EU03MN_00011
2002 Siemens AG
65

Web Edition components
VisiBroker Edition
AppServer Edition

Fig. 36
Gatekeeper - Smart Agent (osagent)
Gatekeeper
Smart
Agent Client
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

MN2976EU03MN_0001
2002 Siemens AG
66


MN2976EU03MN_00011
2002 Siemens AG
67

5 Location platform hardware

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


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

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 LP
3.0 are equipped with two Ulticom SS7 cards and run the Ulticom cluster SW - also in
the case of a 4-node or 6-node installation. For Ulticom cluster internal
communication 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 Ulticom
SS7 cards. LP 3.0 supports a redundant connection to two STPs (STP1, STP2). Via
Ulticom configuration two Linksets are defined, one from each CE to the STP 1 and
the other from each CE to the STP 2. For example, Linkset 1 consists of 8 Links from
CE 1 to STP 1 and 8 Links from CE 2 to STP 1. Linkset 2 consists of 8 Links from CE
1 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 and
has defined UseLoadShare=yes, which means a load sharing over both Linksets. In
other words the CE 1 respectively CE 2 uses Linkset 1 and Linkset 2 in a round robin
manner to perform load sharing over the 2 STPs for addressing the DPC (HLR or
MSC).
The number of required SS7 links depend on the used service mix (ATI, Lg / Lh, Pre-
paging) and the traffic load.


MN2976EU03MN_00011
2002 Siemens AG
71

linkset 1 linkset 2
SunFire 280 SunFire 280
HTTP message
handling services
Signalware
interconnect
SS7 message
handling 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 based
load balancing
SS7 #1 SS7 #2 SS7 #3 SS7 #4
STP 1 STP 1
MSC HLR
e.g. 8 links

Fig. 39


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 load
balancer exists as backup which has a doubled interconnect to the first load
balancer. Each of the load balancers is connected to two internal LANs.
The load balancer forwards connection requests to the HTTP MHS running on the LP
3.0 nodes. Each LP 3.0 node runs multiple HTTP processes on different internal port
numbers. Each HTTP process contacts the Location process via CORBA, whereby a
redundancy over all LP 3.0 nodes is available.


MN2976EU03MN_00011
2002 Siemens AG
73

linkset 1 linkset 2
PAS / CE1
SX Framework
Singalware
Apache
Interbase
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


MN2976EU03MN_0001
2002 Siemens AG
74

The Ulticom SS7 T1/E1 Interface Board
A PCI T1/E1 board is integrated with the Signalware software platform to provide a
fault resilient service execution environment and a complete suite of SS7 protocol
components. The PCI T1/E1 provides the link interface for Signalware to the SS7
signaling network. It consists of an intelligent co-processor, and up to sixteen
communications link interfaces. It performs MTP Level 1 and 2 and portions of Level
3 for ANSI, ITU-T, Chinese and Japanese SS7. The T1/E1 interface board offers a
short form factor (7" X 4 ") universal PCI bus interface with a T1/E1 network
interface controlled by a 486DX5 processor. The boards support the standard PCI
version 2.1 compatible bus interface. The interface to the PCI bus supports both 5V
and 3.3V logic levels, full bus master, slave and DMA capability with buffer chaining.
The T1/E1 SS7 network interface supports 2, 4, 8, 12, and 16 DS0 56/64 Kb/s
channels. The line interface is configured to support both T1/E1 and all standard
frame and line encoding formats for "Intra-Building" connections. Ulticom, Inc. also
supplies cPCI T1/E1 boards supporting up to sixteen links, and PCI serial boards
supporting up to sixteen links. Ulticom verifies that all Signalware boards meet ISO
9001-1994 certifications. Ulticom certifies that Signalware boards comply with UL,
CE, and FCC requirements.

Connector Signal List: RJ-48C Connector

PIN Signal Description Type
1 T1 Receive Pair T1
2 R1 Receive Pair R1
3 NC No Connection
4 T Transmit Pair T
5 R Transmit Pair R
6 NC No Connection
7 CGND Chassis/Shield Ground
8 CGND Chassis/Shield Ground


MN2976EU03MN_00011
2002 Siemens AG
75

SIGNALWARE PCI BUS SS7 T1/E1 INTERFACE BOARD -- PC0200
E1/T1 jumper
E1 T1

Fig. 41


MN2976EU03MN_0001
2002 Siemens AG
76

02 Mn2976eu03mn 0001 Loc Platf Archit Feat

Caricato da

Informazioni sul documento

Descrizione originale:

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

02 Mn2976eu03mn 0001 Loc Platf Archit Feat

Caricato da

Copyright:

Formati disponibili

Location platform architecture - features Siemens

Potrebbero piacerti anche