Preface

Document Conventions

This manual uses several conventions to highlight certain words and phrases and draw attention to specific pieces of information.

In PDF and paper editions, this manual uses typefaces drawn from the Liberation Fonts set. The Liberation Fonts set is also used in HTML editions if the set is installed on your system. If not, alternative but equivalent typefaces are displayed. Note: Red Hat Enterprise Linux 5 and later includes the Liberation Fonts set by default.

Typographic Conventions

Four typographic conventions are used to call attention to specific words and phrases. These conventions, and the circumstances they apply to, are as follows.

Mono-spaced Bold

Used to highlight system input, including shell commands, file names and paths. Also used to highlight key caps and key-combinations. For example:

To see the contents of the file my_next_bestselling_novel in your current working directory, enter the cat my_next_bestselling_novel command at the shell prompt and press Enter to execute the command.

The above includes a file name, a shell command and a key cap, all presented in Mono-spaced Bold and all distinguishable thanks to context.

Key-combinations can be distinguished from key caps by the hyphen connecting each part of a key-combination. For example:

Press Enter to execute the command.

Press to switch to the first virtual terminal. Press to return to your X-Windows session.

The first sentence highlights the particular key cap to press. The second highlights two sets of three key caps, each set pressed simultaneously.

If source code is discussed, class names, methods, functions, variable names and returned values mentioned within a paragraph will be presented as above, in Mono-spaced Bold. For example:

File-related classes include filesystem for file systems, file for files, and dir for directories. Each class has its own associated set of permissions.

Proportional Bold

This denotes words or phrases encountered on a system, including application names; dialogue box text; labelled buttons; check-box and radio button labels; menu titles and sub-menu titles. For example:

Choose System > Preferences > Mouse from the main menu bar to launch Mouse Preferences. In the Buttons tab, click the Left-handed mouse check box and click Close to switch the primary mouse button from the left to the right (making the mouse suitable for use in the left hand).

To insert a special character into a gedit file, choose Applications > Accessories > Character Map from the main menu bar. Next, choose Search > Find from the Character Map menu bar, type the name of the character in the Search field and click Next. The character you sought will be highlighted in the Character Table. Double-click this highlighted character to place it in the Text to copy field and then click the Copy button. Now switch back to your document and choose Edit > Paste from the gedit menu bar.

The above text includes application names; system-wide menu names and items; application-specific menu names; and buttons and text found within a GUI interface, all presented in Proportional Bold and all distinguishable by context.

Note the menu:>[] shorthand used to indicate traversal through a menu and its sub-menus. This is to avoid the difficult-to-follow 'Select from the Preferences ▸ ] sub-menu in the menu:System[ menu of the main menu bar' approach.

Mono-spaced Bold Italic or Proportional Bold Italic

Whether Mono-spaced Bold or Proportional Bold, the addition of Italics indicates replaceable or variable text. Italics denotes text you do not input literally or displayed text that changes depending on circumstance. For example:

To connect to a remote machine using ssh, type ssh username@domain.name at a shell prompt. If the remote machine is example.com and your username on that machine is john, type ssh john@example.com.

The mount -o remount file-system command remounts the named file system. For example, to remount the /home file system, the command is mount -o remount /home.

To see the version of a currently installed package, use the rpm -q package command. It will return a result as follows: package-version-release.

Note the words in bold italics above —username, domain.name, file-system, package, version and release. Each word is a placeholder, either for text you enter when issuing a command or for text displayed by the system.

Aside from standard usage for presenting the title of a work, italics denotes the first use of a new and important term. For example:

When the Apache HTTP Server accepts requests, it dispatches child processes or threads to handle them. This group of child processes or threads is known as a server-pool. Under Apache HTTP Server 2.0, the responsibility for creating and maintaining these server-pools has been abstracted to a group of modules called Multi-Processing Modules (MPMs). Unlike other modules, only one module from the MPM group can be loaded by the Apache HTTP Server.

Pull-quote Conventions

Two, commonly multi-line, data types are set off visually from the surrounding text.

Output sent to a terminal is set in Mono-spaced Roman and presented thus:

books        Desktop   documentation  drafts  mss    photos   stuff  svn
books_tests  Desktop1  downloads      images  notes  scripts  svgs

Source-code listings are also set in Mono-spaced Roman but are presented and highlighted as follows:

package org.jboss.book.jca.ex1;

import javax.naming.InitialContext;

public class ExClient
{
   public static void main(String args[])
       throws Exception
   {
      InitialContext iniCtx = new InitialContext();
      Object         ref    = iniCtx.lookup("EchoBean");
      EchoHome       home   = (EchoHome) ref;
      Echo           echo   = home.create();

      System.out.println("Created Echo");

      System.out.println("Echo.echo('Hello') = " + echo.echo("Hello"));
   }

}

Notes and Warnings

Finally, we use three visual styles to draw attention to information that might otherwise be overlooked.

Note

A note is a tip or shortcut or alternative approach to the task at hand. Ignoring a note should have no negative consequences, but you might miss out on a trick that makes your life easier.

Important

Important boxes detail things that are easily missed: configuration changes that only apply to the current session, or services that need restarting before an update will apply. Ignoring Important boxes won’t cause data loss but may cause irritation and frustration.

Warning

A Warning should not be ignored. Ignoring warnings will most likely cause data loss.

Provide feedback to the authors!

If you find a typographical error in this manual, or if you have thought of a way to make this manual better, we would love to hear from you! Please submit a report in the the {this-issue.tracker.ur}, against the product Restcomm GMLC` `, or contact the authors.

When submitting a bug report, be sure to mention the manual’s identifier: Restcomm GMLC

If you have a suggestion for improving the documentation, try to be as specific as possible when describing it. If you have found an error, please include the section number and some of the surrounding text so we can find it easily.

1. Introduction to Restcomm GMLC

Restcomm GMLC is an Open Source Java based Gateway Mobile Location Centre platform, which enables offering Location Based Services (LBS) around mobile subscribers roaming accross either legacy GSM or UMTS/HSPA+ networks, or Next Generation Networks like LTE/LTE-Advanced.

Restcomm GMLC strictly adheres to the standards and specifications defined by the International Telecommunications Union (ITU) and the 3rd Generation Partnership Project / Long Term Evolution (3GPP/LTE) .

Restcomm GMLC is easy-to-install and easy-to-deploy allowing you to have the Gateway set up and configured very quickly.

Restcomm GMLC comes with an efficient Command Line Interface (CLI) tool allowing you to completely configure the Gateway at run-time and manage it using simple commands rather than do everything manually. Restcomm GMLC also comes with a Graphical User Interface (GUI) that will allow you to configure, monitor and manage the Gateway through a convenient user-friendly interface.

Further, the Open Source Software gives you flexibility to understand the readily available source code and freedom to customise the product to meet your Enterprise needs.

This guide provides details on configuring and using the platform and information regarding the supported protocols and compliant standards.

For installation instructions, please refer to the Installation Guide published along with this.

2. GMLC

2.1. Overview

GMLC stands for Gateway Mobile Location Centre and enables offering Location Based Services (LBS) to mobile subscribers roaming across several Mobile Network Operator’s Radio Access Networks, regardless of the type of access (GERAN, UTRAN or E-UTRAN).

Existing PLMN (Public Land Mobile Network) network elements are proprietary and run on non-standard operating environments located in trusted operator’s zones which make it difficult to build and deploy new applications. Also, these network elements do not provide the tools and interfaces needed to access and retrieve data from content providers over the Internet. The GMLC connects to these network elements and enables the flow of LCS messages to be extended to an open, standards-based Application Server (AS) located in the IP network. The AS also provides the tools and interfaces to enable access to content providers through the Internet.

A GMLC is the first node an external LCS client accesses in a PLMN (Public Land Mobile Network). There may be more than one GMLC in a PLMN.

The simplest location information a GMLC can retrieve is by issuing a MAP ATI (Any Time Interrogation) request to the HLR (Home Location register). MAP ATI is part of CAMEL phase 1. If the GMLC is allowed to proceed with the operation at the HLR, the latter will respond with the Cell Global Identity (CGI) as for the latest MAP Update Location operation carried out between the HLR and VLR at which the target mobile equipment is attached too (therefore, an additional parameter known as "Age of Location Information" is also included in the response). As shown in the figure below taken from 3GPP TS 23.003, CGI is made up of multiple components, namely, MCC (Mobile Country Code), MNC (Mobile Network Code), LAC (Location Area Code) and CI (Cell Identity). The combination of MCC and MNC represents the PLMN at which the cell is located, in other words, the country and Mobile Network Operator it belongs to. LAC represents a geographic location area in which a cluster of Base Transceiver Stations (BTS) are located for radio access, while CI, uniquely identifies the BTS providing service to the target subscriber in that area (more commonly known as cell). From CAMEL phase 4 compliance onward, MAP ATI can also retrieve the IMEI and MS Classmark.

Cell Global Identity

CGI represents the location information with greatest error margin retrievable by a GMLC in GSM based core networks.

As for 3GPP specs, hypothetically a Stand-Alone SMLC can be placed within the BSC for triggering more precise location procedures, but in practice this is hardly found. More accurate positioning methods were developed for cellular networks, particularly from 3G (UMTS) and beyond. Naturally, accuracy comes with a price. When these dearer location capabilities are available, the GMLC may request routing information from the HLR via the Lh interface or HSS (Home Subscriber Server) via the SLh/Lh interface.

LCS GSM UMTS

While Lh interface resides in a Circuit-Switched Core Network and therefore demands SS7 MAP operations, SLh is placed in the Evolved Packet Core (EPC) and is a Diameter-based interface for LTE location services, as specified by 3GPP TS 29.173. After performing registration authorization, it may send positioning requests to either VMSC (Visited Mobile Switching Centre), SGSN (Serving GPRS Support Node), MSCS (Mobile Switching Centre Server) or MME (Mobility Management Entity) and receives final location estimates from the corresponding entity via the Lg, Lgd or SLg interface. Again, Lg/Lgd interfaces demand SS7 MAP operations while SLg is a Diameter-based interface for LTE location occupying ELP procedures, where ELP stands for EPC Location Protocol as specified by 3GPP TS 29.172.

LCS LTE

In summary, location information retrieval within the control plane of a Mobile Core Network is done through the GMLC and its counterparts, the Stand-Alone Serving Mobile Location Centre (SAS) for location within the UTRAN (UMTS Terrestrial Radio Access Network) or Enhanced-SMLC (E-SMLC) for location within the E-UTRAN (Enhanced-UTRAN or LTE), along with the positioning methods available in the RAN (OTDOA, UTDOA, E-OTD, etc.). Location information retrieval in the control plane is performed through a positioning system using OMA’s Secure User Plane Location (SUPL) protocol, also known as SLP (SUPL Location Platform). Control plane positioning is depicted in previous figure too, although it’s not part of Restcomm GMLC albeit it’s in TeleStax' R&D roadmap. Moreover, SUPL demands SETs (SUPL Enabled Terminals), which scarce nowadays. Nevertheless, it’s placed there as it will be added in the future and a combination of a solution in either planes is considered the ideal by the industry for location services in Next Generation Networks.

Up to this point, what is known as "Immediate Location Request" has been covered. A GMLC can also handle "Deferred Location Request", which represents retrieving of location contingent on some current or future events where the response from the LCS Server to the LCS Client may occur some time after the request was sent, as described in 3GPP TS 23.271. When a deferred location request is triggered by the GMLC, event-based "Subscriber Location Reports", either conveyed through MAP or ELP are sent back to the GMLC by the entity at which the target mobile equipment is attached to (VMSC, MSCS, SGSN or MME).

Next figure exhibits Restcomm GMLC architecture and interfaces with aforementioned entities and RestComm (and particularly, RestComm Geolocation API).

GMLC RestComm MNO

Finally, Restcomm GMLC supports the following MAP and Diameter-based operations for LCS (Location Services) within Mobile Network Operators:

  • MAP ATI: Any-Time-Interrogation, to gather Cell Global Identity, age of location information and state of the target mobile station from the HLR.

  • MAP SRIforLCS: Send Routing Information for Location Services, to gather IMSI and core network entity address (MSC or SGSN) to which send further location request.

  • MAP PSL: Provide Subscriber Location, to gather location information from the UTRAN (UMTS Terrestrial Radio Access Network), which should include, besides Cell Global Identity, location estimates in geographic coordinates of the target User Equipment, depending on available positioning methods (e.g. E-OTD, OTDOA, UTDOA, A-GPS, etc.).

  • MAP SLR: Subscriber Location Report, to gather location of a target User Equipment from the MSC or SGSN when a request for location is either implicitly administered or made at some earlier time in MAP PSL for event based deferred type of location.

  • Diameter Routing Information Request/Answer (RIR/RIA): analogous to MAP SRIforLCS but over Diameter based SLh interface between GMLC and HSS.

  • ELP Provide Location Request/Answer (PLR/PLA): analogous to MAP PSL but over Diameter-based Evolved Packet Core Location Protocol (ELP) SLg interface between GMLC and MME.

  • ELP Location Report Request/Answer (LRR/LRA): analogous to MAP SLR, but over Diameter-based Evolved Packet Core Location Protocol (ELP) SLg interface between GMLC and MME.

2.2. Message Flow

2.2.1. HTTP and MAP messages flow for GSM Location Services

GMLC service begins when the network sends an HTTP (GET/POST) request to the GMLC.

Next figure displays the signal flow between an application and Restcomm GMLC within an GSM Core Network, from where location services are reduced to retrieving Global Cell Identity, Age of Location information and MSC/VLR address at which the target MSISDN is currently attached to, by means of a MAP ATI request to the HLR (subscriber’s state can be included in the response if requested in MAP ATI, from which «assumedIdle», «camelBusy» or «notProvidedByVlr» are the available responses). The application, via a REST Web Service, delivers an HTTP GET request to Restcomm GMLC. Restcomm GMLC then performs a MAP ATI request to the concerning GSM Core Network HLR and receives the corresponding response with location information as previously stated.

App GMLC GSM flow

A deeper look inside the messages exchanged as for the previous diagram is shown next (all information depicted are fictitious, as an example)

HTTP GET:

Internet Protocol Version 4, Src: 192.168.26.1, Dst: 192.168.26.128
Transmission Control Protocol, Src Port: 48200 (48200), Dst Port: 8080 (8080), Seq: 1, Ack: 1, Len: 509
Hypertext Transfer Protocol
    GET /restcomm/gmlc/rest?msisdn=59899077937 HTTP/1.1\r\n
        [Expert Info (Chat/Sequence): GET /restcomm/gmlc/rest?msisdn=59899077937 HTTP/1.1\r\n]
        Request Method: GET
        Request URI: /restcomm/gmlc/rest?msisdn=59899077937
        Request Version: HTTP/1.1

MAP ATI Request

IP 4, Src: 192.168.26.128, Dst: 41.188.110.5
SCTP, Src Port: 8012 (8012), Dst Port: 8011 (8011)
MTP 3 User Adaptation Layer (M3UA)
SCCP
    Called Party address
        SubSystem Number: HLR (Home Location Register) (6)
        Global Title 0x4 (9 bytes)
            Called Party Digits: 59899077937
    Calling Party address
        SubSystem Number: GMLC(MAP) (145)
        Global Title 0x4 (6 bytes)
            Calling Party Digits: 222333
TCAP
    begin
        dialogueRequest
            application-context-name: 0.4.0.0.1.0.29.3 (anyTimeInfoEnquiryContext-v3)
        components: 1 item
            Component: invoke
                    invokeID: 0
                    opCode: localValue: 71
GSM MAP
    Component: invoke (1)
        invoke
            invokeID: 0
            opCode: anyTimeInterrogation (71)
            subscriberIdentity: msisdn (1)
                msisdn: 919598097739f7
            requestedInfo
                locationInformation
                subscriberState
            gsmSCF-Address: 91223233

MAP ATI Response

IP 4, Src: 41.188.110.5, Dst: 192.168.26.128
SCTP, Src Port: 8011 (8011), Dst Port: 8012 (8012)
MTP 3 User Adaptation Layer (M3UA)
SCCP
    Called Party address
        SubSystem Number: GMLC(MAP) (145)
        Global Title 0x4 (6 bytes)
            Calling Party Digits: 222333
    Calling Party address
        SubSystem Number: HLR (Home Location Register) (6)
        Global Title 0x4 (9 bytes)
            Called Party Digits: 59899077937
TCAP
    end
        Destination Transaction ID
        oid: 0.0.17.773.1.1.1 (id-as-dialogue)
        dialogueResponse
            application-context-name: 0.4.0.0.1.0.29.3 (anyTimeInfoEnquiryContext-v3)
            result: accepted (0)
        components: 1 item
            Component: returnResultLast
                    invokeID: 0
                    opCode: localValue: 71
GSM MAP
    Component: returnResultLast (2)
        returnResultLast
            invokeID: 0
            resultretres
                opCode: localValue (0)
                    localValue: anyTimeInterrogation (71)
                subscriberInfo
                    locationInformation
                        ageOfLocationInformation: 5
                        geographicalInformation: 104f01231f9a0e00
                        vlr-number: 915555556566
                        cellGlobalIdOrServiceAreaIdOrLAI: cellGlobalIdOrServiceAreaIdFixedLength: 52f0107d0000dd
                    subscriberState: assumedIdle (0)
                        assumedIdle

HTTP GET Response:

IP Version 4, Src: 192.168.26.128, Dst: 192.168.26.1
Transmission Control Protocol, Src Port: 8080 (8080), Dst Port: 48200 (48200), Seq: 230, Ack: 510, Len: 5
Hypertext Transfer Protocol
    HTTP/1.1 200 OK\r\n
        [Expert Info (Chat/Sequence): HTTP/1.1 200 OK\r\n]
        Request Version: HTTP/1.1
        Status Code: 200
        Response Phrase: OK
    [HTTP response 1/1]
    [Time since request: 0.341487879 seconds]
    [Request in frame: 10]
    HTTP chunked response
        Data chunk (61 octets)
        End of chunked encoding
        \r\n
    Data (61 bytes)  mcc=250,mnc=1,lac=32000,cellid=221,aol=5,vlrNumber=5555555666

The latter describes a success scenario, where the application gets the following answer to it HTTP GET tequest:

mcc=250,mnc=1,lac=32000,cellid=221,aol=5,vlrNumber=5555555666

Following, some non succesful HTTP GET responses are displayed:

MAP ATI response with Subscriber State but no Location Information received:

SubscriberState: SubscriberState [subscriberStateChoice=netDetNotReachable, notReachableReason=notRegistered]

MAP ATI response received with no Subscriber Information:

Unknown SubscriberInfo received: xxxx

Erroneous MAP ATI response received:

Unknown AnyTimeInterrogationResponse received: xxxx

MAP ATI response received with UnknownSubscriber error:

ReturnError: 1 : MAPErrorMessageUnknownSubscriber [, unknownSubscriberDiagnostic=imsiUnknown]

MAP ATI response received with other error messages:

ReturnError: <error code> : <MAP Error message description>
ReturnError: 34 : MAPErrorMessageSystemFailure [networkResource=hlr]

When MSISDN is absent in the GET HTTP request - bad HTTP request syntax:

Invalid MSISDN specified

When a timeout occurs (e.g. no response from an HLR is received):

DialogTimeout

When other SS7 stack errors happen:

DialogReject: <description>
DialogProviderAbort: <description>
DialogUserAbort: <description>
RejectComponent: <description>

Next figure displays the analogous signal flow as the one explained before, but including RestComm Geolocation API between the application and Restcomm GMLC. Likewise, in this case, the MAP ATI request is triggered by RestComm by an HTTP POST request with MLP Standard Location Immediate Request (SLIR).

RestComm GMLC GSM flow

Following, see an example of MLP payload included in HTTP POST request received by Restcomm GMLC:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE svc_init SYSTEM "MLP_SVC_INIT_310.DTD">
<svc_init xmlns="MLP_SVC_INIT_310.dtd">
	<hdr>
		<client>
       			<id>USERNAME</id>
       			<pwd>PASSWORD</pwd>
       			<serviceid>SERVICEID</serviceid>
     		</client>
   	</hdr>
   	<slir>
     		<msids>
       			<msid type="MSISDN">59899077937</msid>
     		</msids>
     		<loc_type type=""CURRENT_OR_LAST" />
    </slir>
</svc_init>

The corresponding answer to the MLP SLIR request (after reception of MAP ATI response from the HLR), i.e. the MLP SLIA (Standard Location Immediate Answer) is shown next:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE svc_result SYSTEM "MLP_SVC_RESULT_310.DTD">
<svc_result xmlns="MLP_SVC_RESULT_310.dtd" ver="3.1.0">
    <slia ver="3.1.0">
        <pos>
            <msid>59899077937</msid>
            <pd>
                <time utc_off="-0300">20160828181421</time>
                <plmn>
                    <mcc>250</mcc>
                    <mnc>1</mnc>
                </plmn>
                <gsm_net_param>
                    <cgi>
                        <mcc>250</mcc>
                        <mnc>1</mnc>
                        <lac>32000</lac>
                        <cellid>221</cellid>
                    </cgi>
                    <neid>
                        <vlrid>
                            <vlrno>5555555666</vlrno>
                        </vlrid>
                    </neid>
                </gsm_net_param>
            </pd>
        </pos>
    </slia>
</svc_result>

An MLP SLIA including an unsuccessful location information retrieval due to "Unknown Subscriber" error received in MAP ATI response is shown next.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE svc_result SYSTEM "MLP_SVC_RESULT_310.DTD">
<svc_result xmlns="MLP_SVC_RESULT_310.dtd" ver="3.1.0">
    <slia ver="3.1.0">
        <result resid="4">UNKNOWN SUBSCRIBER</result>
        <add_info>ReturnError: 1 : MAPErrorMessageUnknownSubscriber [, unknownSubscriberDiagnostic=imsiUnknown]</add_info>
    </slia>
</svc_result>

An MLP SLIA including an unsuccessful location information retrieval due to "System Failure" error received in MAP ATI response is shown next.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE svc_result SYSTEM "MLP_SVC_RESULT_310.DTD">
<svc_result xmlns="MLP_SVC_RESULT_310.dtd" ver="3.1.0">
    <slia ver="3.1.0">
        <result resid="1">SYSTEM FAILURE</result>
        <add_info>ReturnError: 34 : MAPErrorMessageSystemFailure [networkResource=hlr]</add_info>
    </slia>
</svc_result>

2.2.2. HTTP and MAP messages flow for UMTS Location Services

Following figure displays the signaling call flow between an application, RestComm Geolocation API and Restcomm GMLC within an UMTS Core Network. The term RAN (Radio Access Network) might involve the RNC (Radio Network Controller), a Stand-Alone SMLC (Serving Mobile Location Centre), the NB (Node B -base station-) and the UE (User Equipment).

RestComm GMLC UMTS flow

The terms MLP SLIR/SLIA and SLIREP stand for Mobile Location Protocol Standard Location Immediate Request/Response/Report as for OMA (Open Mobile Alliance) Mobile Location Protocol 3.2 specification.

Next figure shows an example signal flow exclusively between Restcomm GMLC within an UMTS Core Network for location retrieval by means of MAP operations destined to a Circuit-Switched Core Network where a Stand-Alone SMLC (Serving Mobile Location Center) is operational and positioning methods are available at the Radio Access Network (e.g. OTDOA). Then, UMTS Terrestrial Radio Access Network (UTRAN) comprises positioning procedures involving the Stand-Alone SMLC (SAS), NB (Node Basestation), and the UE.The example considers a location report sent back to Restcomm GMLC, triggered by an event previously armed at the Radio Access Network (e.g. a UE exiting a geofence).

GMLC UMTS call flow

2.2.3. HTTP and Diameter-based messages flow for LTE Location Services

Next figure shows an example signaling call flow exclusively between Restcomm GMLC within an Evolved Packet Core Network for location retrieval by means of Diameter based procedures as for 3GPP TS 29.172 and 29.173 (i.e. SLg and SLh interfaces). These Diameter requests are destined to a Packet-Switched Core Network like LTE’s EPC, where an Evolved-SMLC is operational and positioning methods are available at the Radio Access Network (e.g. OTDOA). Then, LTE’s Radio Access Network (EUTRAN) involves positioning procedures comprising the E-SMLC (Evolved SMLC), eNB (evolved NB), and the UE. The example considers a location report sent back to Restcomm GMLC, triggered by an event previously armed at the Radio Access Network (e.g. a UE entering a geofence).

GMLC LTE call flow

Next figure displays the analogue call flow as previous, but including RestComm Geolocation API and Restcomm GMLC within an EPS (Evolved Packet System) for LTE/LTE-Advanced/LTE-Pro location services.

RestComm GMLC LTE flow

An analogous signal call flow as the one explained before for GSM location but consistent with previous signal flow for LTE location is described next. The mentioned MLP SLIR example would be almost identical to the one shown for GSM location, but with some additions as following:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE svc_init SYSTEM "MLP_SVC_INIT_310.DTD">
<svc_init xmlns="MLP_SVC_INIT_310.dtd">
    <hdr>
        <client>
            <id>ACae6e420f425248d6a26948c17a9e2acf</id>
            <pwd>f8bc1274677b173d1a1cf3b9924eaa7e</pwd>
            <serviceid>0005</serviceid>
        </client>
    </hdr>
    <slir>
        <msids>
            <msid type="MSISDN">59899077937</msid>
        </msids>
        <loc_type type="CURRENT" />
		<geo_info>
			<CoordinateReferenceSystem>
				<Identifier>
					<code>4004</code>
					<codeSpace>EPSG</codeSpace>
					<edition>6.1</edition>
				</Identifier>
			</CoordinateReferenceSystem>
		</geo_info>
		<change_area>
			<target_area>
				<name_area>a51</name_area>
			</target_area>
			<type>MS_WITHIN_AREA</type>
			<loc_estimates>FALSE</loc_estimates>
			<no_of_reports>1</no_of_reports>
		</change_area>
		<duration>3600</duration>
		<lcs_ref>579</lcs_ref>
	</slir>
</svc_init>

Corresponding transmission of ELP PLR to the LTE network is shown next (only AVPs shown for simplicity):

[PLR] Sending Request: 8388620 [E2E:1263534084 -- HBH:1693441831 -- AppID:16777255]
[PLR] Request AVPs:
[PLR] <avp name="Session-Id" code="263" vendor="0" value="51.0.0.1;343; 3840918879;SLg-PLA34277987203" />
[PLR] <avp name="Vendor-Specific-Application-Id" code="260" vendor="0">
[PLR]   <avp name="Vendor-Id" code="266" vendor="0" value="10415" />
[PLR]   <avp name="Auth-Application-Id" code="258" vendor="0" value="16777255" />
[PLR] </avp>
[PLR] <avp name="Destination-Realm" code="283" vendor="0" value="tel1.com" />
[PLR] <avp name="Origin-Realm" code="296" vendor="0" value="restcomm.com" />
[PLR] <avp name="Auth-Session-State" code="277" vendor="0" value="1" />
[PLR] <avp name="Origin-Host" code="264" vendor="0" value="aaa://51.0.0.1:13868" />
[PLR] <avp name="SLg-Location-Type" code="2500" vendor="10415" value="0" />
[PLR] <avp name="MSISDN" code="701" vendor="10415" value="59899077937" />
[PLR] <avp name="LCS-EPS-Client-Name" code="2501" vendor="10415">
[PLR]   <avp name="LCS-Name-String" code="1238" vendor="10415" value=" ACae6e420f425248d6a26948c17a9e2acf" />
[PLR]   <avp name="LCS-Format-Indicator" code="1237" vendor="10415" value="2" />
[PLR] </avp>
[PLR] <avp name="LCS-Client-Type" code="1241" vendor="10415" value="1" />
[PLR] <avp name="LCS-Requestor-Name" code="2502" vendor="10415">
[PLR]   <avp name="LCS-Requestor-Id-String" code="1240" vendor="10415" value="Restcomm Geolocation API" />
[PLR]   <avp name="LCS-Format-Indicator" code="1237" vendor="10415" value="0" />
[PLR] </avp>
[PLR] <avp name="LCS-Priority" code="2503" vendor="10415" value="1" />
[PLR] <avp name="LCS-QoS" code="2504" vendor="10415">
[PLR]   <avp name="LCS-QoS-Class" code="2523" vendor="10415" value="1" />
[PLR]   <avp name="Horizontal-Accuracy" code="2505" vendor="10415" value="120" />
[PLR]   <avp name="Vertical-Accuracy" code="2506" vendor="10415" value="99999" />
[PLR]   <avp name="Vertical-Requested" code="2507" vendor="10415" value="0" />
[PLR]   <avp name="Response-Time" code="2509" vendor="10415" value="1" />
[PLR] </avp>
[PLR] <avp name="Deferred-Location-Type" code="2532" vendor="10415" value="4" />
[PLR] <avp name="LCS-Reference-Number" code="2531" vendor="10415" value="579" />
[PLR] <avp name="Area-Event-Info" code="2533" vendor="10415">
[PLR]   <avp name="Occurrence-Info" code="2538" vendor="10415" value="0" />
[PLR]   <avp name="Interval-Time" code="2539" vendor="10415" value="3600" />
[PLR] </avp>
[PLR] <avp name="Area-Definition" code="2534" vendor="10415">
[PLR]   <avp name="Area-Type" code="2536" vendor="10415" value="2" />
[PLR]   <avp name="Area-Identification" code="2537" vendor="10415" value="a51" />
[PLR] </avp>
[PLR] <avp name="PLR-Flags" code="2545" vendor="10415" value="4" />
[PLR] <avp name="Area-Event-Info" code="2533" vendor="10415">
[PLR]   <avp name="Reporting-Amount" code="2541" vendor="10415" value="1" />
[PLR]   <avp name="Reporting-Interval" code="2542" vendor="10415" value="3600" />
[PLR] </avp>
[PLR] </avp>
[PLR] <avp name="GMLC-Address" code="2405" vendor="10415" value="52.21.78.91" />
[PLR] <avp name="PLR-Flags" code="2545" vendor="10415" value="4" />
[PLR] </avp>

Reception of ELP PLA from the LTE network is shown next (only AVPs shown for simplicity):

[PLA] Received Answer: 8388620 [E2E:1263534084 -- HBH:1693441831 -- AppID:16777255]
[PLA] Request AVPs:
[PLA] <avp name="Session-Id" code="263" vendor="0" value="51.0.0.1;343; 3840918879;SLg-PLA34277987203" />
[PLA] <avp name="Vendor-Specific-Application-Id" code="260" vendor="0">
[PLA] <avp name="Vendor-Id" code="266" vendor="0" value="10415" />
[PLA] <avp name="Auth-Application-Id" code="258" vendor="0" value="16777255" />
[PLA] </avp>
[PLA] <avp name="Result-Code" code="268" vendor="0" value="2001" />
[PLA] <avp name="Auth-Session-State" code="277" vendor="0" value="1" />
[PLA] <avp name="Location-Estimate" code="1242" vendor="10415" value="S35°38'15.37" W58°45'21.77"" />
[PLA] <avp name="Accuracy-Fulfilment-Indicator" code="2513" vendor="10415" value="0" />
[PLA] <avp name="Age-Of-Location-Estimate" code="2514" vendor="10415" value="0" />
[PLA] <avp name="EUTRAN-Positioning-Data" code="2516" vendor="10415" value="0A73F937" />
[PLA] <avp name="ECGI" code="2517" vendor="10415" value="EFB9437" />
[PLA] <avp name="Serving-Node" code="2401" vendor="10415">
[PLA]   <avp name="SGSN-Number" code="1489" vendor="10415" value="59899004501" />
[PLA]	<avp name="SGSN-Name" code="2409" vendor="10415" value="SGSN01" />
[PLA]	<avp name="SGSN-Realm" code="2410" vendor="10415" value="sgsn.tel1.com" />
[PLA]   <avp name="MME-Name" code="2402" vendor="10415" value="MME710" />
[PLA]   <avp name="MME-Realm" code="2408" vendor="10415" value="mme.tel1.com" />
[PLA]   <avp name="3GPP-AAA-Server-Name" code="318" vendor="10415" value="aaa.restcomm.com" />
[PLA]   <avp name="LCS-Capabilities-Sets" code="2404" vendor="10415" value="99900123" />
 [PLA]   <avp name="GMLC-Address" code="2405" vendor="10415" value="52.21.78.91" />
[PLA] </avp>
[PLA] <avp name="PLA-Flags" code="2546" vendor="10415" value="0" />
[PLA] <avp name="ESMLC-Cell-Info" code="2552" vendor="10415">
[PLA]  <avp name="ECGI" code="2517" vendor="10415" value="EFB9437" />
[PLA]  <avp name="Cell-Portion-ID" code="2553" vendor="10415" value="0" />
[PLA] </avp>

The corresponding answer to the MLP SLIR request (after reception of ELP PLA from the LTE network), i.e. the MLP SLIA (Standard Location Immediate Answer) embedded in HTTP POST response is shown next.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE svc_result SYSTEM "MLP_SVC_RESULT_310.DTD">
<svc_result xmlns="MLP_SVC_RESULT_310.dtd" ver="3.1.0">
    <slia ver="3.1.0">
        <lcs_ref>579</lcs_ref>
        <pos>
            <msid>59899077937</msid>
            <pd>
                <time utc_off="-0300">20161023235151</time>
		        <geo_info>
			        <CoordinateReferenceSystem>
				        <Identifier>
					        <code>4326</code>
					        <codeSpace>EPSG</codeSpace>
					        <edition>6.1</edition>
				        </Identifier>
			        </CoordinateReferenceSystem>
			        <shape>
			            <CircularArea>
			                <coord>
			                    <X>35 38 15.37S</X>
			                    <Y>58 45 21.77W</Y>
			                </coord>
			                <radius>-1</radius>
			            </CircularArea>
			        </shape>
		        </geo_info>
		    </pd>
	    </pos>
    </slia>
</svc_result>

When the settled event occurs, it triggers a location report back to the GMLC, the ELP LRR/LRA messages are subsequently conveyed back and forth between the MME and GMLC, as displayed next:

[LRR] Sending Request: 8388621 [E2E:1370488836 -- HBH:1693543583 -- AppID:16777255]
[LRR] Request AVPs:
[LRR] <avp name="Session-Id" code="263" vendor="0" value="51.0.0.1;343; 3841024432;-SLg-LRR34277987203" />
[LRR] <avp name="Vendor-Specific-Application-Id" code="260" vendor="0">
[LRR]   <avp name="Vendor-Id" code="266" vendor="0" value="10415" />
[LRR]   <avp name="Auth-Application-Id" code="258" vendor="0" value="16777255" />
[LRR] </avp>
[LRR] <avp name="Destination-Realm" code="283" vendor="0" value="restcomm.com" />
[LRR] <avp name="Origin-Realm" code="296" vendor="0" value="tel1.com" />
[LRR] <avp name="Auth-Session-State" code="277" vendor="0" value="1" />
[LRR] <avp name="Origin-Host" code="264" vendor="0" value="aaa://51.0.0.1:13868" />
[LRR] <avp name="Location-Event" code="2518" vendor="10415" value="4" />
[LRR] <avp name="LCS-EPS-Client-Name" code="2501" vendor="10415">
[LRR]   <avp name="LCS-Name-String" code="1238" vendor="10415" value="ACae6e420f425248d6a26948c17a9e2acf" />
[LRR]   <avp name="LCS-Format-Indicator" code="1237" vendor="10415" value="2" />
[LRR] </avp>
[LRR] <avp name="3GPP-IMSI" code="1" vendor="10415" value="748039876543210" />
[LRR] <avp name="MSISDN" code="701" vendor="10415" value="59899077937" />
[LRR] <avp name="IMEI" code="1402" vendor="10415" value="011714004661057" />
[LRR] <avp name="Location-Estimate" code="1242" vendor="10415" value=" S35°37'10.91" W58°01'33.07"" />
[LRR] <avp name="Accuracy-Fulfilment-Indicator" code="2513" vendor="10415" value="0" />
[LRR] <avp name="Age-Of-Location-Estimate" code="2514" vendor="10415" value="3" />
[LRR] <avp name="Velocity-Estimate" code="2515" vendor="10415" value="0" />
[LRR] <avp name="EUTRAN-Positioning-Data" code="2516" vendor="10415" value="0A73F937" />
[LRR] <avp name="ECGI" code="2517" vendor="10415" value="E1F0023" />
[LRR] <avp name="Service-Area-Identity" code="1607" vendor="10415" value="service-area-umts-3" />
[LRR] <avp name="LCS-Service-Type-ID" code="2520" vendor="10415" value="234" />
[LRR] <avp name="Pseudonym-Indicator" code="2519" vendor="10415" value="0" />
[LRR] <avp name="LCS-QoS-Class" code="2523" vendor="10415" value="1" />
[LRR] <avp name="Serving-Node" code="2401" vendor="10415">
[LRR]   <avp name="SGSN-Number" code="1489" vendor="10415" value="59899004501" />
[LRR]	<avp name="SGSN-Name" code="2409" vendor="10415" value="SGSN01" />
[LRR]	<avp name="SGSN-Realm" code="2410" vendor="10415" value="sgsn.tel1.com" />
[LRR]   <avp name="MME-Name" code="2402" vendor="10415" value="MME710" />
[LRR]   <avp name="MME-Realm" code="2408" vendor="10415" value="mme.tel1.com" />
[LRR]   <avp name="3GPP-AAA-Server-Name" code="318" vendor="10415" value="aaa.restcomm.com" />
[LRR]   <avp name="LCS-Capabilities-Sets" code="2404" vendor="10415" value="99900123" />
 [PLA]   <avp name="GMLC-Address" code="2405" vendor="10415" value="52.21.78.91" />
 [LRR] </avp>
[LRR] <avp name="LRR-Flags" code="2530" vendor="10415" value="0" />
[LRR] <avp name="LCS-Reference-Number" code="2531" vendor="10415" value="579" />
[LRR] <avp name="Deferred-MT-LR-Data" code="2547" vendor="10415">
[LRR]   <avp name="Deferred-Location-Type" code="2532" vendor="10415" value="4" />
[LRR]   <avp name="Termination-Cause" code="2548" vendor="10415" value="7" />
[LRR] </avp>
[LRR] <avp name="GMLC-Address" code="2405" vendor="10415" value="52.21.78.91" />
[LRR] <avp name="Periodic-LDR-Info" code="2540" vendor="10415">
[LRR]   <avp name="Reporting-Amount" code="2541" vendor="10415" value="8639910" />
[LRR]   <avp name="Reporting-Interval" code="2542" vendor="10415" value="8639998" />
[LRR] </avp>
[LRR] <avp name="ESMLC-Cell-Info" code="2552" vendor="10415">
[LRR]   <avp name="ECGI" code="2517" vendor="10415" value="EFC9452" />
[LRR]   <avp name="Cell-Portion-ID" code="2553" vendor="10415" value="12393" />
[LRR] </avp>
[LRR] <avp name="1xRTT-RCID" code="2554" vendor="10415" value="00000010" />
[LRR] <avp name="Civic-Address" code="2556" vendor="10415" value="<civicAddress xml:lang='en-GB' xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" xmlns:cdc="http://devon.canals.example.com/civic">
        <country>UY</country>
	<A1>MV</A1>
	<ap:airport>MVD</ap:airport>
	<ap:terminal>Carrasco International</ap:terminal>
	<ap:concourse>A</ap:concourse>
	<ap:gate>4</ap:gate>
      </civicAddress>" />
[LRR] <avp name="Barometric-Pressure" code="2557" vendor="10415" value="101327" />
[LRA] Received Answer: 8388621 [E2E:1370488836 -- HBH:1693543583 -- AppID:16777255]
[LRA] Request AVPs:
[LRA] <avp name="Session-Id" code="263" vendor="0" value="51.0.0.1;343; 3841024432;-SLg-LRR34277987203" />
[LRA] <avp name="Vendor-Specific-Application-Id" code="260" vendor="0">
[LRA]   <avp name="Vendor-Id" code="266" vendor="0" value="10415" />
[LRA]   <avp name="Auth-Application-Id" code="258" vendor="0" value="16777255" />
[LRA] </avp>
[LRA] <avp name="Result-Code" code="268" vendor="0" value="2001" />
[LRA] <avp name="Auth-Session-State" code="277" vendor="0" value="1" />
[LRA] <avp name="GMLC-Address" code="2405" vendor="10415" value="52.21.78.91" />
[LRA] <avp name="LRA-Flags" code="2549" vendor="10415" value="0" />
[LRA] <avp name="Reporting-PLMN-List" code="2543" vendor="10415">
[LRA]   <avp name="Visited-PLMN-Id" code="1407" vendor="10415" value="74803, 74801" />
[LRA]   <avp name="Periodic-Location-Support-Indicator" code="2550" vendor="10415" value="1" />
[LRA]   <avp name="Prioritized-List-Indicator" code="2551" vendor="10415" value="0" />
[LRA] </avp>
[LRA] <avp name="PLMN-ID-List" code="2544" vendor="10415">
[LRA]   <avp name="Visited-PLMN-Id" code="1407" vendor="10415" value="74803, 74801" />
[LRA]   <avp name="Periodic-Location-Support-Indicator" code="2550" vendor="10415" value="1" />
[LRA] </avp>
[LRA] <avp name="LCS-Reference-Number" code="2531" vendor="10415" value="579" />
[LRR] <avp name="Origin-Host" code="264" vendor="0" value="51.0.0.1" />
[LRR] <avp name="Origin-Realm" code="296" vendor="0" value="restcomm.com" />

The corresponding answer MLP SLREP (Standard Location Immediate Answer) embedded in HTTP POST response is shown next.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE svc_result SYSTEM "MLP_SVC_RESULT_310.DTD">
<svc_result xmlns="MLP_SVC_RESULT_310.dtd" ver="3.1.0">
    <slirep ver="3.1.0">
        <lcs_ref>579</lcs_ref>
	    <pos>
	        <msid>59899077937</msid>
	        <imsi>748039876543210</imsi>
 	        <imei>011714004661057</imei>
 	        <speed>0</speed>
            <pd>
                <time utc_off="-0300">20161023235901</time>
		        <geo_info>
			        <CoordinateReferenceSystem>
				        <Identifier>
					        <code>4326</code>
					        <codeSpace>EPSG</codeSpace>
					        <edition>6.1</edition>
				        </Identifier>
			        </CoordinateReferenceSystem>
			        <shape>
			            <CircularArea>
			                <coord>
			                    <X>35 37 10.91S</X>
			                    <Y>58 01 33.07W</Y>
			                </coord>
			                <radius>100</radius>
			            </CircularArea>
			        </shape>
		        </geo_info>
		    </pd>
	    </pos>
    </slirep>
</svc_result>

2.3. Restcomm GMLC

2.3.1. Major Features

Restcomm GMLC implementation of GMLC is the first and only open source GMLC with a host of rich features and advantages.

Java-based

Restcomm GMLC is the only Java based GMLC Gateway. It is robust and reliable and can be installed on any Operating System that supports Java (JDK 7 and SCTP).

Open Source

The Software is open-source, giving you the freedom to understand the code and customise it to your enterprise needs. It is supported by a vibrant Open source community.

Carrier Grade Performance

Restcomm GMLC has been developed to be deployed at Mobile Network Operators around the world so as to process billions of LCS transactions every day. A single Restcomm GMLC node can process up to 1500’s LCS/sec and can be adapted to the needs of Communication Service Providers of different sizes in any country reducing CAPEX and OPEX costs.

Cloud Ready

Restcomm GMLC is Cloud-ready. It can be deployed on dedicated hardware, private cloud infrastructure or public IaaS such as AWS.

SS7 Hardware Cards

Restcomm GMLC can be used with Intel family boards (Dialogic SS7 cards) or Zaptel/Dahdi compatible TDM devices (Digium, Sangoma). For production its recommended to use Dialogic boards only.

SIGTRAN (M3UA)

It also has in-built support for SIGTRAN (M3UA using SCTP).

Diameter-based SLh and SLg (ELP)

Restcomm GMLC also has in-built support for LCS in LTE networks.

HTTP interface

Restcomm GMLC HTTP interface is a common interface that can be used for connection with service applications. Restcomm GMLC supports network/application/service initiated LCS requests.

MLP

Location requests can be sent to the Restcomm GMLC using plain XML over HTTP(S), with the request being encoded in OMA MLP (Mobile Location Protocol). See the full OMA MLP technical specification here: http://technical.openmobilealliance.org/Technical/technical-information/release-program/current-releases/mlp-v3-1

JAIN SLEE

JAIN SLEE (Java API for Integrated Networks Service Logic Execution Environment) specification constitutes the JAVA community framework for the high standards in terms of performance, availability, portability, scalability, robustness, event oriented execution logic, etc., suitable for services/applications inter-working within telecommunication networks. JAIN SLEE architecture, through its Resource Adaptors (RA), adjusts information from peripheral agents of the SLEE, namely: Mobile Switching Centre Servers (MSC/MSCS), Media Gateways (MGW, MGC/MGCF), Signaling Gateways (SGW), Mobility Management Entities (MME), SIP servers/proxies like Serving/Interrogating/Proxy-Call Session Control Functions (S-CSCF, I-CSCF, P-CSCF), Media Resource Function Control, mobile subscribers data base query to HSS/HLR through Diameter/MAP respectively, Signaling Control Points (SCP) through CAP/INAP, and other service protocols like SOAP (Simple Object Access Protocol), OSA/Parlay, LDAP (Lightweight Directory Access Protocol), JDBC (Java Data Base Connectivity), JPA (Java Persistence API), etc. The components that carry out logic implementation of services/applications according to JAIN SLEE are named Service Building Blocks or SBB. The SBB are executed within a «components container», which controls their life cycle and eases their composition. An SBB may comprise multiple child SBBs, which are also reusable for other services, encompassing Java code usually generated in a dynamic Service Creation Environment or SCE (e.g. RestComm Visual Designer RVD) or middleware platforms containing JAIN SLEE SBBs (e.g. RestComm GMLC). JAIN SLEE service developer undergoes SBB construction by gathering logic items which represent events during the process of a service. As JAIN SLEE has been specially designed for event oriented logic execution, services are initiated by events like Diameter Requests/Answers. The generated SBBs then act together with the RAs under the JAIN SLEE framework so as to provide service to diverse external entities. Every arriving event at the SLEE through the RAs is distributed among the SBBs in order to process them. This functionality is carried out by the «event router» as it is named within the functional structure of the JAIN SLEE framework.

Easy Configuration and Management

Restcomm GMLC comes with an efficient Command Line Interface (CLI) tool allowing you to completely configure the Gateway at run-time and manage it using simple commands rather than do everything manually. Restcomm GMLC also comes with a Graphical User Interface that will allow you to configure, monitor and manage the Gateway through a convenient user-friendly interface.

Next figure shows an architectural overview of Restcomm GMLC and its external interfaces, servers and clients, either within the infrastructure of a Mobile Network Operator or the Internet and specifically, with Restcomm Geolocation API.

GMLC Architecture

2.3.2. Technical Specifications

Restcomm GMLC is not restricted by Transaction Per Second model. The only restricting factor is memory + CPU capacity of the host servers, third-party applications or the underlying database service.

  • Restcomm GMLC supports as many as 1073741823 incoming and 1073741823 outgoing concurrent sessions/dialogs.

  • Restcomm GMLC supports unlimited E1 links and the only limiting factor is the underlying TDM board used.

  • Restcomm GMLC SCTP supports as many associations as supported by the underlying Operating System. Can be setup in multihome.

  • Restcomm GMLC M3UA can be confgured to have as many ASP’s / IPSP’s as needed by the system.

  • Restcomm GMLC SCCP can be confgured to have virtually unlimited Global Title Translation rules and also supports wild characters for partial matching of Global Title digits.

2.3.3. HTTP Transfer Mechanism

Restcomm GMLC makes use of HTTP protocol between the gateway and the third-party applications (or Value Added Service Modules). Restcomm GMLC receives location service requests from third-party applications and then translates these requests to SS7 MAP or Diameter based commands when applies. The HTTP callback mechanism allows the third-party application to be agnostic to Operating System, Programming Language and Framework. The third-party application can be either of the following technologies on any Operating System:

  • Apache Tomcat, JBoss AS, Oracle Application Server, IBM Websphere, etc. for JSP/Servlet on Java

  • PHP

  • Microsoft IIS for ASP

3. Running

3.1. Running the Gateway

Procedure: Run Restcomm GMLC
  1. Pre-requisite:

    • You must have Restcomm GMLC installed as explained in the Installation Guide.

    • If you are using the SS7 board on server, you must ensure that the java.library.path variable is set to point to the directory containing the native component. Alternatively you can copy it to the JBoss native library path manually.

  2. All you have to do to start the Gateway is start the JBoss Application Server. To start the JBoss Server you must execute the run.sh (Unix) or run.bat (Microsoft Windows) startup script in the installation directory restcomm-gmlc-/jboss-5.1.0.GA/bin. Note that this will start the server in the default profile. The "default" profile is a clean profile where you start from scratch and configure the entire SS7 Stack and GMLC Gateway to suit your requirements.

  3. Result: If the service started properly you should see the following last few output lines in the Unix terminal or Command Prompt depending on your environment:

    19:49:43,856 INFO  [ServiceManagementImpl] (main) Activated ServiceID[name=mobicents-gmlc,vendor=org.mobicents,version=1.0]
    19:49:44,123 INFO  [ShellServer] (main) Starting SS7 management shell environment
    19:49:44,124 INFO  [ShellServer] (main) ShellExecutor listening at /127.0.0.1:3435
    19:49:44,175 INFO  [Ss7Management] (main) Starting ...
    19:49:44,175 INFO  [MBeanHostImpl] (main) Found MBeanServer matching for agentId=jboss
    19:49:44,175 WARN  [MBeanHostImpl] (main) Found non-matching MBeanServer with default domian = null
    19:49:44,176 INFO  [Ss7Management] (main) Started ...
    19:49:44,184 INFO  [MBeanHostImpl] (main) Registered MBean with ObjectName=org.mobicents.ss7:layer=ALARM,type=Management,name=AlarmHost
    19:49:44,184 INFO  [Ss7Management] (main) Registered MBean: AlarmHost
    19:49:44,192 INFO  [CounterProviderManagement-CounterHost] (main) Starting ...
    19:49:44,192 INFO  [CounterProviderManagement-CounterHost] (main) CounterManagement configuration file path /home/telestax/RestComm/restcomm-gmlc-1.0.66/jboss-5.1.0.GA/server/default/data/CounterHost_CounterProvider.xml
    19:49:44,207 INFO  [MBeanHostImpl] (main) Registered MBean with ObjectName=org.mobicents.ss7:layer=COUNTER,type=Management,name=CounterHost
    19:49:44,211 INFO  [Ss7Management] (main) Registered MBean: CounterHost
    19:49:44,243 INFO  [CounterProviderManagement-CounterHost] (main) Started ...
    19:49:44,337 INFO  [MBeanHostImpl] (main) Registered MBean with ObjectName=org.mobicents.ss7:layer=SCTP,type=Management,name=SCTPManagement
    19:49:44,338 INFO  [Ss7Management] (main) Registered MBean: SCTPManagement
    19:49:44,366 INFO  [MBeanHostImpl] (main) Registered MBean with ObjectName=org.mobicents.ss7:layer=M3UA,type=Management,name=Mtp3UserPart
    19:49:44,366 INFO  [Ss7Management] (main) Registered MBean: Mtp3UserPart
    19:49:44,392 INFO  [MBeanHostImpl] (main) Registered MBean with ObjectName=org.mobicents.ss7:layer=SCCP,type=Management,name=SccpStack
    19:49:44,392 INFO  [Ss7Management] (main) Registered MBean: SccpStack
    19:49:44,397 INFO  [MBeanHostImpl] (main) Registered MBean with ObjectName=org.mobicents.ss7:layer=SCCP,type=Router,name=SccpStack
    19:49:44,397 INFO  [Ss7Management] (main) Registered MBean: SccpStack
    19:49:44,399 INFO  [MBeanHostImpl] (main) Registered MBean with ObjectName=org.mobicents.ss7:layer=SCCP,type=Resource,name=SccpStack
    19:49:44,399 INFO  [Ss7Management] (main) Registered MBean: SccpStack
    19:49:44,433 INFO  [TcapManagementJmx-TcapStack] (main) Starting ...
    19:49:44,436 INFO  [MBeanHostImpl] (main) Registered MBean with ObjectName=org.mobicents.ss7:layer=TCAP,type=Management,name=TcapStack
    19:49:44,437 INFO  [CounterProviderManagement-CounterHost] (main) Registered CounterMediator: Tcap-TcapStack
    19:49:44,437 INFO  [Ss7Management] (main) Registered MBean: TcapStack
    19:49:44,437 INFO  [TcapManagementJmx-TcapStack] (main) Started ...
    19:49:44,530 INFO  [Http11Protocol] (main) Starting Coyote HTTP/1.1 on http-127.0.0.1-8080
    19:49:44,566 INFO  [AjpProtocol] (main) Starting Coyote AJP/1.3 on ajp-127.0.0.1-8009
    19:49:44,571 INFO  [ServerImpl] (main) JBoss (Microcontainer) [5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221634)] Started in 1m:35s:965ms
  4. If you are starting GMLC-2.0.0-SNAPSHOT for the first time, SS7 is not configured. You can use either the Shell Client or the GUI to connect to GMLC-2.0.0-SNAPSHOT and configure the SS7 Stack, GMLC parameters and Routing Rules. Once configured, the state and configuration of SS7 and GMLC are both persisted which stands a server re-start operation. The next chapter will discuss in detail about configuring SS7 and the GMLC Gateway.

Procedure: Stop the Gateway
  1. To stop the Restcomm GMLC , you must shut down the JBoss Application Server. To shut down the server(s) you must execute the shutdown.sh -s (Unix) or shutdown.bat -s (Microsoft Windows) script in the installation directory restcomm-gmlc-/jboss-5.1.0.GA/bin.

  2. If the server stopped properly, you will see the following three lines as the last output in the Unix terminal or Command Prompt:

    INFO  [ServerImpl] (JBoss Shutdown Hook) Shutdown complete
    Shutdown complete
    Halting VM

3.2. Running the Gateway - Simulator Profile

The Restcomm GMLC offers you an option to run the Gateway with a "simulator" profile for testing purpose. The "simulator" profile is a pre-configured profile to work with the jss7-simulator. Starting the Gateway with the "simulator" profile is similar to the steps explained for the "default" profile except that you must pass the string value "simulator" to the -c command line option when invoking the run script.

[bin]$ ./run.sh -c simulator

By default, the GMLC Simulator profile is configured for use in Linux systems. For using it in Microsoft Windows systems, you must configure the parameters as explained below.

Open the file restcomm-gmlc-<version>/jboss-5.1.0.GA/server/simulator/data/SCTPManagement_sctp.xml and replace in two places, the parameter ipChannelType="0" with ipChannelType="1" to enable TCP connection instead of SCTP since Windows does not support SCTP. If you are using in a Linux system, there is no modification required to the settings.

3.3. Running GMLC Examples in Simulator

If you are not familiar with the Restcomm jSS7 Simulator, you can find instructions about using the jSS7-simulator in the Restcomm jSS7 User Guide. You will also find example test cases explained in detail in the jSS7 User Guide. In this section you will find a simple Location Service example explained using the jSS7 Simulator.

Procedure: Running Restcomm jSS7 Simulator - MAP ATI TEST SERVER Example
  1. Change the working directory to the bin folder in the Simulator’s installation directory.

    [vinu@vinu-neha ~]$ cd restcomm-gmlc-<version>/tools/restcomm-ss7-simulator/bin
  2. Ensure that the run.sh start script is executable.

    bin$ chmod +x run.sh
  3. Execute the run.sh Bourne shell script with the command ./run.sh gui.

    bin$ ./run.sh gui

    This will launch the Simulator GUI Application.

  4. When the GUI shows up, select "main" (default) as host name [or type "win" as host name under Windows] and press the 'Start' button. The Simulator is already pre-configured to connect to the GMLC Gateway (running in simulator profile). Press 'Run test' and again click on 'Start' in the next screen. The Simulator will connect to GMLC (via a SIGTRAN SCTP/M3UA association). The Low layer is configured to SCTP (not TCP) protocol, therefore you can test the GMLC in a Linux environment. To test under Windows OS, you must change the SS7 simulator settings to TCP.

  5. After approximately 30 seconds you will see the appear two events in the the Simulator window log showing "Sctp connection is up" and "M3UA connection is active" as in figure below:

    GMLC SS7 Simulator ACTIVE
  6. Restcomm GMLC is configured, in simulator mode, to process an HTTP GET to trigger a MAP ATI at the jSS7 Simulator, which will return a fake answer for the only purpose of testing. Assuming the server is running with no IP binding (i.e. it’s running in loopback address 127.0.0.1), open a browser and perform an HTTP GET test, for example (msisdn can be any number except the dummy one reserved, i.e. 19395550113): http://127.0.0.1:8080/restcomm/gmlc/rest?msisdn=87583439

You should immediately receive the following testing response with GCI + Age of Location Information parameters: mcc=250,mnc=1,lac=32000,cellid=221,aol=5,vlrNumber=5555555666

If you check the SS7 simulator (where the MAP ATI was sent and responded back), you should be able to see the following request and response (click on "Open Event Window" on each event logged):

SS7sim MAP ATI req
SS7sim MAP ATI resp
Procedure: Running Restcomm jSS7 Simulator - HTTP POST MLP Request
  1. You must first start the Restcomm GMLC in simulator profile.

[telestax@127 ~]$ cd restcomm-gmlc-<version>/jboss-5.1.0.GA/bin
[telestax@127 bin]$./run.sh -b 127.0.0.1 -c simulator
  1. To send an OMA MLP request test, in the same path from where you just ran the server, issue the following command:

curl -X POST -d @mlpreq.txt http://127.0.0.1:8080/restcomm/gmlc/mlp

mlpreq.txt is like this (you may change the MSISDN):

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE svc_init SYSTEM "MLP_SVC_INIT_310.DTD">
<svc_init xmlns="MLP_SVC_INIT_310.dtd">
	<hdr>
		<client>
       			<id>USERNAME</id>
       			<pwd>PASSWORD</pwd>
       			<serviceid>SERVICEID</serviceid>
     		</client>
   	</hdr>
   	<slir>
     		<msids>
       			<msid type="MSISDN">59899077937</msid>
     		</msids>
     		<eqop>
        		<resp_timer>15</resp_timer>
     		</eqop>
   	</slir>
</svc_init>

You should immediately receive the following testing MLP response:

<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE svc_result SYSTEM "MLP_SVC_RESULT_310.DTD">
<svc_result xmlns="MLP_SVC_RESULT_310.dtd" ver="3.1.0">
    <slia ver="3.1.0">
        <pos>
            <msid>59899077937</msid>
            <pd>
                <time utc_off="-0300">20160801211238</time>
                <shape>
                    <CircularArea>
                        <coord>
                            <X>27 28 25.00S</X>
                            <Y>153 01 43.00E</Y>
                        </coord>
                        <radius>5000</radius>
                    </CircularArea>
                </shape>
            </pd>
        </pos>
    </slia>
</svc_result>

3.4. Running the Shell

You must start the Shell client and connect to the managed instance prior to executing commands to configure the Gateway. Shell can be started by issuing the following command from restcomm-gmlc-/jboss-5.1.0.GA/bin directory:

[$] ./ss7-cli.sh

Once console starts, it will print following information and await further commands:

version=7.0.1383,name=Restcomm jSS7 CLI,prefix=restcomm,vendor=TeleStax

Before issuing further commands you must connect to a managed instance. For more details on connecting to an instance and for a list of all supported commands and details on configuring the SS7 stack refer to the Restcomm SS7 Stack User Guide.

3.5. Connect to a new Instance

You can connect to a new instance by entering the IP:Port values and then login credentials in the top left corner of the GUI.

3.6. Authentication

Restcomm GMLC GUI Management Security is based on the JBoss Security Framework.

As of now, there is basic authentication offered (which is based on the JBoss Security framework). When you try to start the Web Console, you will be prompted to enter login credentials. These credentials can be configured in the files jmx-console-roles.properties and jmx-console-users.properties located at restcomm-gmlc-<version>/jboss-5.1.0.GA/server/<profile>/conf/props/.

You can also change the authentication from flat file system to database by making necessary configurations in the file restcomm-gmlc-<version>/jboss-5.1.0.GA/server/<profile>/conf/login-config.xml.

For detailed instructions and to know more about JBoss Security Framework please refer to the JBoss Installation Guide here.

Deafult user-id and password for GUI Management Console is admin and admin. You can change the user-id and password in files jmx-console-roles.properties and jmx-console-users.properties located at restcomm-gmlc-<version>/jboss-5.1.0.GA/server/<profile>/conf/props/

4. Configuring

You must fine-tune Memory and Database settings for better performance before using Restcomm GMLC in production. Once you complete setting up the Gateway you must configure the SS7 Stack and GMLC paramters. Restcomm GMLC comes with a convenient user-friendly Graphical User Interface (GUI) and a Command Line Interface (CLI) that will allow you to configure, monitor and manage the Gateway. While the CLI tool allows complete configuration and control of the Gateway, the GUI-based management enhances the usability of the Gateway and gives you the ability to configure and manage the GMLC Gateway dynamically. This chapter will explain how to manage the Gateway effectively using both the GUI and the CLI.

4.1. Memory Settings

You should fine tune the JVM memory settings based on your needs but we recommend you allocate a minimum of 3 GB for initial and maximum heap size. These settings are specified in the file[path]restcomm-gmlc-/jboss-5.1.0.GA/bin/run.conf.

-Xms3072m

Initial heap size, set in megabytes

-Xmx3072m

Maximum heap size, set in megabytes

4.2. JSupported Java Version

GMLC Gateway can run only with Java 7 JRE or JDK. We refered Oracle Java 7 JDK.

4.3. Configuring JSLEE http-client RA

Restcomm GMLC acts as a HTTP Client to achieve GMLC pull by sending a HTTP POST/GET request to GMLC gateway. You must configure the HTTP Client JSLEE Resource Adaptor’s properties to suit your requirements. Please refer to the SLEE RA HTTP Client User Guide available in restcomm-gmlc-/docs/slee/RestComm_SLEE_RA_HTTP_Client_User_Guide.pdf.

4.4. Configuring the SS7 Stack

You must configure the SS7 Stack prior to configuring GMLC. For details on configuring the SS7 Stack please refer to the RestComm SS7 Stack User Guide. The RestComm SS7 Stack User Guide lists all available Shell commands and GUI operations to configure SS7. In addition, help files are also available for every Shell command providing all details relevant to the command.

Appendix A: Revision History