OsmoHLR User Manual

As GSM and UMTS operate in licensed spectrum, please always double-check that you have all required licenses and that you do not transmit on any ARFCN or UARFCN that is not explicitly allocated to you by the applicable regulatory authority in your country.

The software developed by the Osmocom project and described in this manual is Free / Open Source Software (FOSS) and subject to so-called copyleft licensing.

Copyleft licensing is a legal instrument to ensure that this software and any modifications, extensions or derivative versions will always be publicly available to anyone, for any purpose, under the same terms as the original program as developed by Osmocom.

This means that you are free to use the software for whatever purpose, make copies and distribute them - just as long as you ensure to always provide/release the complete and corresponding source code.

Every Osmocom software includes a file called COPYING in its source code repository which explains the details of the license. The majority of programs is released under GNU Affero General Public License, Version 3 (AGPLv3).

If you have any questions about licensing, don’t hesitate to contact the Osmocom community. We’re more than happy to clarify if your intended use case is compliant with the software licenses.

All trademarks, service marks, trade names, trade dress, product names and logos appearing in this manual are the property of their respective owners. All rights not expressly granted herein are reserved.

For your convenience we have listed below some of the registered trademarks referenced herein. This is not a definitive or complete list of the trademarks used.

Osmocom® and OpenBSC® are registered trademarks of Holger Freyther and Harald Welte.

sysmocom® and sysmoBTS® are registered trademarks of sysmocom - systems for mobile communications GmbH.

ip.access® and nanoBTS® are registered trademarks of ip.access Ltd.

The software is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the License text included with the software for more details.

Please see [licenses-gfdl] for further information.

Currently, probably the easiest way to automatically import subscribers to OsmoHLR is to write out a text file with SQL commands per subscriber, and feed that to sqlite3, as described below.

A difficulty is to always choose subscriber IDs that are not yet in use. For an initial import, the subscriber ID may be incremented per subscriber record. If adding more subscribers to an existing database, it is necessary to choose subscriber IDs that are not yet in use. Get the highest ID in use with:

A full SQL example of adding a single subscriber with id 23, IMSI 001010123456789, MSISDN 1234, Ki for COMP128v1, and K and OPC for Milenage:

Table entries to auc_2g and/or auc_3g may be omitted if no such key material is required.

UMTS Milenage auth (on both 2G and 3G RAN) is configured by the auc_3g table. algo_id_3g must currently always be 5 (MILENAGE).

The algorithm IDs for algo_id_2g and algo_id_3g are:

Create an empty HLR database with

Repeat above SQL commands per subscriber, incrementing the subscriber ID for each block, then feed the SQL commands for the subscribers to be imported to the sqlite3 command line tool:

To upgrade from old OsmoNITB to OsmoHLR, use osmo-hlr-db-tool:

Be aware that the import is lossy, only the IMSI, MSISDN, nam_cs/ps and 2G auth data are set.

If you type a single ? at the prompt, the VTY will display possible completions at the exact location of your currently entered command.

If you type ? at an otherwise empty command (without having entered even only a partial command), you will get a list of the first word of all possible commands available at this node:

If you have already entered a partial command, ? will help you to review possible options of how to continue the command. Let’s say you remember that show is used to investigate the system status, but you don’t remember the exact name of the object. Hitting ? after typing show will help out:

You may pick the bsc object and type ? again:

By presenting <cr> as the only option, the VTY tells you that your command is complete without any remaining arguments being available, and that you should hit enter, a.k.a. "carriage return".

The VTY supports tab (tabulator) completion. Simply type any partial command and press <tab>, and it will either show you a list of possible expansions, or completes the command if there’s only one choice.

At this point, you may choose show, and then press <tab> again:

The list command will give you a full list of all commands and their arguments available at the current node:

The VTY allows to edit the configuration at runtime. For many VTY commands the configuration change is immediately valid but for some commands a change becomes valid on a certain event only. In some cases it is even necessary to restart the whole process.

To give the user an overview, which configuration change applies when, the VTY implemets a system of attribute flags, which can be displayed using the show command with the parameter vty-attributes

The attributes are symbolized through a single ASCII letter (flag) and do exist in three levels. This is more or less due to the technical aspects of the VTY implementation. For the user, the level of an attribute has only informative purpose.

The global attributes, which can be found under the same attribute letter in every osmocom application, exist on the top level. The Library specific attributes below are used in various osmocom libraries. Like with the global attributes the attribute flag letter stays the same throughout every osmocom application here as well. On the third level one can find the application specific attributes. Those are unique to each osmocom application and the attribute letters may have different meanings in different osmocom applications. To make the user more aware of this, lowercase letters were used as attribute flags.

The list command with the parameter with-flags displays a list of available commands on the current VTY node, along with attribute columns on the left side. Those columns contain the attribute flag letters to indicate to the user how the command behaves in terms of how and when the configuration change takes effect.

There are multiple columns because a single command may be associated with multiple attributes at the same time. To improve readability each flag letter gets a dedicated column. Empty spaces in the column are marked with a dot (".")

In some cases the listing will contain commands that are associated with no flags at all. Those commands either play an exceptional role (interactive commands outside "configure terminal", vty node navigation commands, commands to show / write the config file) or will require a full restart of the overall process to take effect.

Some VTY commands are considered relatively dangerous if used in production operation, so the general approach is to hide them. This means that they don’t show up anywhere but the source code, but can still be executed. On the one hand, this approach reduces the risk of an accidental invocation and potential service degradation; on the other, it complicates intentional use of the hidden commands.

The VTY features so-called expert mode, that makes the hidden commands appear in the interactive help, as well as in the XML VTY reference, just like normal ones. This mode can be activated from the VIEW node by invoking the enable command with the parameter expert-mode. It remains active for the individual VTY session, and gets disabled automatically when the user switches back to the VIEW node or terminates the session.

A special attribute in the output of the list with-flags command indicates whether a given command is hidden in normal mode, or is a regular command:

Logging messages to the interactive command-line interface (VTY) is most useful for occasional investigation by the system administrator.

Logging to the VTY is disabled by default, and needs to be enabled explicitly for each such session. This means that multiple concurrent VTY sessions each have their own logging configuration. Once you close a VTY session, the log target will be destroyed and your log settings be lost. If you re-connect to the VTY, you have to again activate and configure logging, if you wish.

To create a logging target bound to a VTY, you have to use the following command: logging enable This doesn’t really activate the generation of any output messages yet, it merely creates and attaches a log target to the VTY session. The newly-created target still doesn’t have any filter installed, i.e. all log messages will be suppressed by default

Next, you can configure the log levels for desired categories in your VTY session. See [log_categories] for more details on categories and [log_levels] for the log level details.

For example, to set the log level of the Call Control category to debug, you can use: log level cc debug

Finally, after having configured the levels, you still need to set the filter as it’s described in [log_filters].

To review the current vty logging configuration, you can use: show logging vty

To avoid having separate VTY session just for logging output while still having immediate access to them, one can use alarms target. It lets you store the log messages inside the ring buffer of a given size which is available with show alarms command.

It’s configured as follows:

In the example above 98 is the desired size of the ring buffer (number of messages). Once it’s filled, the incoming log messages will push out the oldest messages available in the buffer.

GSMTAP is normally a pseudo-header format that enables the IP-transport of GSM (or other telecom) protocols that are not normally transported over IP. For example, the most common situation is to enable GSMTAP in OsmoBTS or OsmoPCU to provide GSM-Um air interface capture files over IP, so they can be analyzed in wireshark.

GSMTAP logging is now a method how Osmocom software can also encapsulate its own log output in GSMTAP frames. We’re not trying to re-invent rsyslog here, but this is very handy When debugging complex issues. It enables the reader of the pcap file containing GSMTAP logging together with other protocol traces to reconstruct exact chain of events. A single pcap file can then contain both the log output of any number of Osmocom programs in the same timeline of the messages on various interfaces in and out of said Osmocom programs.

It’s configured as follows:

The hostname/ip argument is optional: if omitted the default 127.0.0.1 will be used. The log strings inside GSMTAP are already supported by Wireshark. Capturing for port 4729 on appropriate interface will reveal log messages including source file name and line number as well as application. This makes it easy to consolidate logs from several different network components alongside the air frames. You can also use Wireshark to quickly filter logs for a given subsystem, severity, file name etc.

Note: the logs are also duplicated to stderr when GSMTAP logging is configured because stderr is the default log target which is initialized automatically. To descrease stderr logging to absolute minimum, you can configure it as follows:

As opposed to Logging to the VTY, logging to files is persistent and stored in the configuration file. As such, it is configured in sub-nodes below the configuration node. There can be any number of log files active, each of them having different settings regarding levels / subsystems.

To configure a new log file, enter the following sequence of commands:

This leaves you at the config-log prompt, from where you can set the detailed configuration for this log file. The available commands at this point are identical to configuring logging on the VTY, they include logging filter, logging level as well as logging color and logging timestamp.

syslog is a standard for computer data logging maintained by the IETF. Unix-like operating systems like GNU/Linux provide several syslog compatible log daemons that receive log messages generated by application programs.

libosmocore based applications can log messages to syslog by using the syslog log target. You can configure syslog logging by issuing the following commands on the VTY:

This leaves you at the config-log prompt, from where you can set the detailed configuration for this log file. The available commands at this point are identical to configuring logging on the VTY, they include logging filter, logging level as well as logging color and logging timestamp.

systemd has been adopted by the majority of modern GNU/Linux distributions. Along with various daemons and utilities it provides systemd-journald [1] - a daemon responsible for event logging (syslog replacement). libosmocore based applications can log messages directly to systemd-journald.

The key difference from other logging targets is that systemd based logging allows to offload rendering of the meta information, such as location (file name, line number), subsystem, and logging level, to systemd-journald. Furthermore, systemd allows to attach arbitrary meta fields to the logging messages [2], which can be used for advanced log filtering.

[1] https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html [2] https://www.freedesktop.org/software/systemd/man/systemd.journal-fields.html

It was decided to introduce libsystemd as an optional dependency, so it needs to be enabled explicitly at configure/build time:

You can configure systemd based logging in two ways:

In this example, logging messages will be passed to systemd without any meta information (time, location, level, category) in the text itself, so all the printing parameters like logging print file will be ignored. Instead, the meta information is passed separately as fields which can be retrieved from the journal and rendered in any preferred way.

See man 7 systemd.journal-fields for a list of default fields, and man 1 journalctl for general information and available formatters.

In this example, logging messages will be pre-processed by libosmocore before being passed to systemd. No additional fields will be attached, except the logging level (PRIORITY). This mode is similar to syslog and stderr.

If you’re not running the respective application as a daemon in the background, you can also use the stderr log target in order to log to the standard error file descriptor of the process.

In order to configure logging to stderr, you can use the following commands:

The GET operation is performed by an external application to get a certain value from inside the Osmocom application.

The SET operation is performed by an external application to set a value inside the Osmocom application.

The program can at any time issue a trap. The term is used in the spirit of SNMP.

You can use osmo_ctrl.py to listen for traps the following way:

For example, if a subscriber is currently visiting another village, establish a phone call / send SMS towards that village.

The current location of a subscriber may change at any time, and, when moving across locations, a subscriber may suddenly lose reception to the previous location without explicitly detaching. Hence an mslookup request for the current location of an MSISDN may get numerous responses. To find the currently valid location, mslookup includes the age of the subscriber record, i.e. how long ago the subscriber was last reached. The one response with the youngest age reflects the current location.

In order to evaluate several responses, mslookup always waits for a fixed amount of time (1 second), and then evaluates the available responses.

Services are not limited to SIP and SMPP, arbitrarily named services can be added to the mslookup configuration.

For example, when attaching to a local network, a local resident gets serviced directly by the local village’s HLR, while a visitor from another village gets serviced by the remote village’s HLR (Roaming).

A home HLR typically stays the same for a given IMSI. If the home site is reachable, there should be exactly one response to an mslookup request asking for it. The age of such a home-HLR response is always sent as zero.

If a response’s age is zero, mslookup does not wait for further responses and immediately uses the result.

If there were more than one HLR accepting service for an IMSI, the one with the shortest response latency is used.

Here is an osmo-hlr.cfg mslookup configuration example for one site, which is explained in subsequent chapters.

OsmoHLR has both an mslookup server and a client.

The mslookup service can be implemented by various methods. At the time of writing, the only method implemented is mDNS.

The stock mslookup method is mDNS, multicast DNS. It consists of standard DNS encoding according to [ietf-rfc1035] and [ietf-rfc3596], but sent and received on IP multicast. In the response, standard A and AAAA records return the service’s IP address, while additional TXT records provide the service’s port number and the MS attach age.

In OsmoHLR, the mDNS server and client are typically both enabled at the same time:

Server and client can also be enabled/disabled individually:

These examples use the default mslookup multicast IP address and port. It is possible to configure custom IP address and port, but beware that the IP address must be from a multicast range, see [ietf-rfc5771]:

Domain names generated from mslookup queries (e.g. "sip.voice.123.msisdn") should not collide with IANA permitted domains. Therefore we add the "mdns.osmocom.org" suffix. It can be overridden as follows:

The mslookup server requires a list of service addresses provided at the local site, in order to respond to service requests matching locally attached subscribers.

In this example:

Obviously, these IP addresses must be routable back to this site from all other sites. Using link-local or "ANY" addresses, like 127.0.0.1 or 0.0.0.0, will not work here. Instead, each service config requires a public IP address that all remote requestors are able to reach (not necessarily on the host that osmo-hlr is running on).

If a site has more than one MSC, services can also be configured for each MSC individually, keyed by the IPA unit name that each MSC sends on the GSUP link:

Here, "msc-262-42-0" is the IPA name of a local OsmoMSC instance. To configure an OsmoMSC’s IPA name on the GSUP link, see osmo-msc.cfg, setting hlr / ipa-name.

For mslookup service responses, only Location Updatings in the Circuit Switched domain are relevant. OsmoHLR does manage IMSIs attaching in the Packet Switched domain (via an SGSN) similarly to Circuit Switched (via an MSC), but mslookup completely ignores the Packet Switched attach status.

When responding to home-HLR requests, OsmoHLR implicitly by default responds with its locally configured GSUP bind address (setting hlr / gsup / bind ip). If required, an explicit local GSUP address and port can be configured, for example:

The gsup.hlr service can only be configured globally (because requests come from arbitrary mDNS clients, before a Location Updating has associated the IMSI with the requesting MSC).

For reliable GSUP proxy routing to a remote HLR (Roaming), it is important that each GSUP client, i.e. each HLR, MSC and SGSN instance, has a unique IPA name.

Example for configuring an OsmoHLR instance’s IPA name:

Here, "hlr-23" is the unique identification of this OsmoHLR instance across all potentially connected D-GSM sites.

Furthermore, each MSC and SGSN must have a uniquely distinct IPA name across all sites (here "msc-262-42-0" and "msc-901-70-0" are used as example IPA names for local MSCs).

When this OsmoHLR connects to a remote HLR, be it for GSUP proxying or SMS-over-GSUP, it communicates its own IPA name (on GSUP link-up) as well as the IPA name of the requesting client MSC/SGSN (as Source Name in each message) to the remote OsmoHLR GSUP server. These names are used to route GSUP responses back to the respective requesting peer.

If two MSCs were accidentally configured with identical names, a problem will occur as soon as both MSCs attempt to attach to the same OsmoHLR (either directly or via GSUP proxying). The MSC that shows up first will work normally, but any duplicate that shows up later will be rejected, since a route for its name already exists.

The OsmoHLR provides an mslookup client C library, libosmo-mslookup. Service lookups can be integrated directly in client programs using this library. However, its mDNS implementation requires the libosmocore select() loop, which can be challenging to integrate in practice. An alternative solution is the osmo-mslookup-client tool.

The mslookup C library is available, but often, a simpler approach for client implementations is desirable:

The osmo-mslookup-client cmdline tool provides a trivial way to synchronously acquire the single result for an mslookup request. The service client can invoke an osmo-mslookup-client process per request and read the result from stdout.

Each invocation obviously spawns a separate process and opens a multicast socket for mDNS. For better scalability, osmo-mslookup-client can also be run as a daemon, providing results via a unix domain socket. Using synchronous write() and recv() allows blocking until a result is received without interfering with the client program’s select() setup.

By itself, osmo-mslookup-client is also helpful as a diagnostic tool:

For full help including example client invocations in Python, see the output of:

The SGSN or VLR sends a SEND_AUTHENTICATION_INFO_REQ message containing the MS’s IMSI to the peer. On errors, especially if authentication info is not available for that IMSI, the peer returns a SEND_AUTHENTICATION_INFO_ERR message. Otherwise the peer returns a SEND_AUTHENTICATION_INFO_RES message. If this message contains at least one authentication tuple, the SGSN or VLR replaces all tuples that are assigned to the subscriber. If the message doesn’t contain any tuple the SGSN or VLR may reject the Attach Request. (see 3GPP TS 09.02, 25.5.6)

Using this procedure, the SGSN or VLR reports authentication failures to the HLR.

The SGSN or VLR sends a UPDATE_LOCATION_REQ to the peer. If the request is denied by the network, the peer returns an UPDATE_LOCATION_ERR message to the SGSN or VLR. Otherwise the peer returns an UPDATE_LOCATION_RES message containing all information fields that shall be inserted into the subscriber record. If the PDP info complete information element is set in the message, the SGSN or VLR clears existing PDP information fields in the subscriber record first. (see 3GPP TS 09.02, 19.1.1.8)

Using the Location Cancellation procedure, the Network Peer (HLR) can request the SGSN or VLR to remove a subscriber record.

Using the Purge MS procedure, the SGSN or VLR can request purging of MS related state from the HLR. It is used after the SGSN or VLR detects that no radio contact has been established for a prolonged duration (i.e. longer than the periodic LU timeout). See 3GPP TS 23.012 Section 3.6.1.4 for a description of this procedure.

Using the Delete Subscriber Data procedure, the Peer (HLR) can remove some of the subscriber data from the SGSN or VLR. This is used in case the subscription details (e.g. PDP Contexts / APNs) change while the subscriber is registered to that SGSN VLR.

The VLR asks the EIR to check if a new ME’s IMEI is acceptable or not. The EIR may implement a blacklist or whitelist and reject the IMEI based on that. Against the original purpose of the Check IMEI Procedure, this could also be used to save the IMEI in the HLR DB.

MSC-A has an active RAN connection and hands it over to MSC-B.

MSC-B has an active RAN connection, and asks MSC-A to hand it over to MSC-B'.

MSC-A is forwarding a message from its BSS (Base Station Subsystem) to MSC-B. MSC-B forwards the message to its BSS, and answers to MSC-A with a Process Access Signalling Request.

The GSUP server can not route any of the requests above, and responds with an E Routing Error. Possible reasons for not being able to route the message are missing routing IEs, a mismatching source name IE ([gsup-ie-source-name]), the destination not being connected to the GSUP server or a failed attempt to send the message from the GSUP sever to the destination. To figure out, what went wrong in detail, refer to the GSUP server’s logs.

In the traditional GSM MAP world, the participants of an E procedure are directly connected, hence this routing error message does not exist in MAP.

Every message is based on the following message format

If a numeric range is indicated in the presence column, multiple information elements with the same tag may be used in sequence. The information elements shall be sent in the given order. Nevertheless after the generic part the receiver shall be able to received them in any order. Unknown IE shall be ignored.

Besides a numeric range, the presence column may have M (Mandatory), O (Optional) or C (Conditional). The format column holds either V (Value) or TLV (Tag Length Value).

Direction: SGSN / VLR ⇒ HLR

The conditional AUTS and RAND IEs are both present in case the SIM (via UE) requests an UMTS AKA re-synchronization procedure. Either both optional IEs are present, or none of them.

The conditional PDP Info IE is only present in the CEAI interface used by the ePDG. It should contain the PDP Context ID, PDP Address (dynamic addressing) and Access Point Name IEs.

Direction: HLR ⇒ SGSN / VLR

Direction: HLR ⇒ SGSN / VLR

Direction: SGSN / VLR ⇒ HLR

Direction: SGSN / VLR ⇒ HLR

Direction: HLR ⇒ SGSN / VLR

Direction: HLR ⇒ SGSN / VLR

If the PDP info complete IE is present, the old PDP info list shall be cleared.

Direction: HLR ⇒ SGSN / VLR

Direction: SGSN / VLR ⇒ HLR

TODO

Direction: SGSN / VLR ⇒ HLR

Direction: SGSN / VLR ⇒ HLR

Direction: HLR ⇒ SGSN / VLR

Direction: HLR ⇒ SGSN / VLR

Direction: HLR ⇒ SGSN / VLR

If the PDP info complete IE is present, the old PDP info list shall be cleared.

Direction: SGSN / VLR ⇒ HLR

Direction: SGSN / VLR ⇒ HLR

Direction: HLR ⇒ SGSN / VLR

Direction: SGSN / VLR ⇒ HLR

Direction: HLR ⇒ SGSN / VLR

Direction: bidirectional

This message is used in both directions in case of USSD, because it is not known is it request or response without parsing the GSM 04.80 payload.

Direction: EUSE / HLR ⇒ MSC

Direction: EUSE / HLR ⇒ MSC

The purpose of this message is not clear yet. Probably, it can be used to notify the MSC that a structured supplementary service is successfully activated or deactivated, etc.

Direction: MSC / SGSN ⇒ SMSC (via HLR)

This message is used to forward MO short messages from MSC / SGSN to an SMSC. The corresponding MAP service is MAP-MO-FORWARD-SHORT-MESSAGE, see 3GPP TS 29.002, section 12.2.

Direction: SMSC (via HLR) ⇒ MSC / SGSN

This message is used to indicate a negative result of an earlier MO short message delivery. The corresponding MAP service is MAP-MO-FORWARD-SHORT-MESSAGE, see 3GPP TS 29.002, section 12.2.

Direction: SMSC (via HLR) ⇒ MSC / SGSN

This message is used to indicate a successful result of an earlier MO short message delivery. The corresponding MAP service is MAP-MO-FORWARD-SHORT-MESSAGE, see 3GPP TS 29.002, section 12.2.

Direction: SMSC (via HLR) ⇒ MSC / SGSN

This message is used to forward MT short messages from an SMSC to MSC / SGSN. The corresponding MAP service is MAP-MT-FORWARD-SHORT-MESSAGE, see 3GPP TS 29.002, section 12.9.

Direction: MSC / SGSN ⇒ SMSC (via HLR)

This message is used to indicate a negative result of an earlier MT short message delivery. The corresponding MAP service is MAP-MT-FORWARD-SHORT-MESSAGE, see 3GPP TS 29.002, section 12.9.

Direction: MSC / SGSN ⇒ SMSC (via HLR)

This message is used to indicate a successful result of an earlier MT short message delivery. The corresponding MAP service is MAP-MT-FORWARD-SHORT-MESSAGE, see 3GPP TS 29.002, section 12.9.

Direction: MSC / SGSN ⇒ SMSC (via HLR)

This message is used between the MSC / SGSN and an SMSC when a subscriber indicates memory available situation (see TS GSM 04.11, section 7.3.2). The corresponding MAP service is MAP-READY-FOR-SM, see 3GPP TS 29.002, section 12.4.

Direction: SMSC (via HLR) ⇒ MSC / SGSN

This message is used to indicate a negative result of an earlier MO SMMA (Memory Available) indication. The corresponding MAP service is MAP-READY-FOR-SM, see 3GPP TS 29.002, section 12.4.

Direction: SMSC (via HLR) ⇒ MSC / SGSN

This message is used to indicate a successful result of an earlier MO SMMA (Memory Available) indication. The corresponding MAP service is MAP-READY-FOR-SM, see 3GPP TS 29.002, section 12.4.

Direction: VLR ⇒ EIR (via HLR)

Direction: EIR (via HLR) ⇒ VLR

Direction: EIR (via HLR) ⇒ VLR

Direction: MSC-A=MSC-I ⇒ MSC-B=MSC-T (via HLR)

Direction: MSC-B=MSC-T ⇒ MSC-A=MSC-I (via HLR)

Direction: MSC-B=MSC-T ⇒ MSC-A=MSC-I (via HLR)

Direction: MSC-B=MSC-I ⇒ MSC-A (via HLR)

Direction: MSC-A ⇒ MSC-B=MSC-I (via HLR)

Direction: MSC-A ⇒ MSC-B=MSC-I (via HLR)

Direction: MSC-B=MSC-T ⇒ MSC-A=MSC-I (via HLR)

Direction: MSC-A=MSC-I ⇒ MSC-B=MSC-T (via HLR)

Direction: MSC-A ⇒ MSC-B=MSC-I (via HLR)

Direction: MSC-B=MSC-T ⇒ MSC-A=MSC-I (via HLR)

Direction: MSC-A ⇒ MSC-B=MSC-I (via HLR)

Direction: MSC-A ⇒ MSC-B (via HLR)

This message was added to GSUP for the inter-MSC handover. But so far it is not used yet.

Direction: GSUP Server (HLR) ⇒ GSUP Client (MSC)

Direction: GSUP Client (strongswan) ⇒ GSUP Server (ePDG)

Direction: GSUP Server (ePDG) ⇒ GSUP Client (strongswan)

Direction: GSUP Server (ePDG) ⇒ GSUP Client (strongswan)

The category of the message is indicated by the last two bits of the type. Request, Error and Result messages only differ in these last two bits, so it is trivial to transform them.

The value part is encoded like in the Packet data protocol address IE defined in 3GPP TS 24.008, Chapter 10.5.6.4. PDP type organization must be set to IETF allocated address.

This is a container for information elements describing a single PDP.

The conditional IE are mandantory unless mentioned otherwise.

The value part is encoded like in the Packet data protocol address IE defined in 3GPP TS 24.008, Chapter 10.5.6.4. Hence this value also relates to End User Address (EUA) IE defined in 3GPP TS 29.060, 7.7.27. The PDP type organization value must be set to IETF allocated address.

The spare bits are left undefined. While 3GPP TS 29.060 7.7.27 defines them as 1 1 1 1, there are MAP traces where these bits are set to 0 0 0 0. So the receiver shall ignore these bits.

Examples:

The PDP type context ID IE consists of a single integer byte wrapped in a TLV.

This is a container for information elements describing a single authentication tuple.