diameter server assignment request

Wireless 4G Core Network

IP Network Emulation

• MAPS™
• Diameter Protocol Emulator

MAPS™ Diameter Protocol Emulator

Emulation of Diameter protocol for S6a, S6d, S13, S13’, Cx/Dx, Gx, Gy, Rf, Ro, Rx, Sh, SLg, SLh, and Zh interfaces supporting Authentication, Authorization and Accounting (AAA) framework for all next generation fixed and mobile IP- based networks (IMS, LTE).

The Diameter protocol is intended to provide a framework for Authentication, Authorization and Accounting (AAA) applications such as network access, roaming, and IP mobility. The AAA protocols are used to determine whether the user is allowed to connect to the network (Authentication) and use a particular service (Authorization). It is also used to track network resources used by end-user for accurate billing (Accounting).

AAA protocols such as TACACS and RADIUS were initially deployed to provide dial-up PPP and terminal server access.  Over time, with the growth of the Internet and the introduction of new access technologies, including wireless, DSL, Mobile IP and Ethernet, routers and network access servers (NAS) have increased in complexity and density, putting new demands on AAA protocols. As a result, the Diameter protocol has been chosen as the AAA protocol in all next generation fixed and mobile IP- based networks (IMS, LTE). The Diameter protocol is a considerably more sophisticated protocol for mobility management, policy and charging (online and offline) control. It is designed to support data, services, and applications with extreme flexibility and is expected to replace all legacy protocols such as MAP, LDAP, Radius, and others.

LTE Diameter network also includes LCS (Location Services) specific elements and entities, their functionalities, interfaces, as well as communication messages, necessary to implement the positioning functionality in a cellular network. Location Services (LCS) architecture follows a client/server model with the gateway mobile location Center (GMLC) acting as the server providing information to External LCS Clients.

• Protocol Stack
• Call Simulation

MAPS™ Diameter can emulate S6a, S6d, S13, S13’, Cx/Dx, Gx, Gy, Rf, Ro, Rx, Sh, SLg, SLh, and Zh interfaces and LTE IMS network elements such as Mobility Management Entity (MME), Home Subscriber Server (HSS), Equipment Identity Register (EIR), and Serving GPRS Support Node (SGSN), Application Server (AS), Serving Call State Control Function (SCSCF), Policy and Charging Rules Function (PCRF), Policy and Charging Enforcement Function (PCEF), Charging Trigger Function (CTF), Packet Data Network Gateway (PDN GW), Online Charging System (OCS), Application Function (AF), Call Session Control Function (CSCF), Bootstrapping Server Functionality (BSF), and Gateway Mobile Location Center (GMLC). This active emulation framework empowers users to thoroughly test and analyze the behavior of these network nodes and their interactions.

MAPS™ Diameter is enhanced to simulate Location Service (LCS) based SLh and SLg interfaces between the GMLC <-> HSS and GMLC <->MME defined for the Control Plane as per 3GPP TS 23.271 specifications.

The application   supports both SCTP (Stream Control Transmission) and TCP (Transmission Control Protocol) transport protocol layers for PSTN signaling messages over IP networks. MAPS™ Diameter also supports TCP/TLS (Transport Layer Security) for the secured information transfer.

MAPS™ Diameter Emulator   includes powerful utilities like Message Editor, Script Editor, and Profile Editor which allow new scenarios to be created or existing scenarios to be modified using Diameter messages and parameters. "Message sequences" are generated through scripts. "Messages" are created using message templates. These features give the users the unlimited ability to edit messages on supported interfaces to support various procedures listed below.

MAPS™ also supports End-to-End 4G LTE Communications Network Lab with all components to simulate E-UTRAN, EPC (Evolved Packet Core) and IMS, allowing complete testing of the LTE-IMS network.

Real-Time Applications:

• Emulate up to thousands of Smartphones (UEs) powering up and down
• Authenticate and confirm security procedures
• Temporary addressing management for mobility and security
• Supports real-time applications of location-based services, providing up-to-date information for vehicle tracking, stolen assets tracking, temperature monitoring, traffic services, and emergency services

GL also provides a GUI based  All-IP PacketScan Analyzer  for on-line capture and decode of the Diameter signaling in real-time both during tests and as a stand-alone tracer for live systems.

Main Features

• Supports emulation of real-time LTE network using “ MAPS 4G Wireless Lab Suite ”
• Allows users to configure MAPS™ Diameter emulator as MME, HSS, PCRF, PCEF, CSCF, SGSN, PDN GW, EIR, AF, BSF, and AS entities to emulate a variety of interfaces such as S6a, S6d, S13, S13’, Cx/Dx, Gx, Gy, Rf, Ro, Rx, Sh, SLg, SLh, and Zh
• Supports simulation of Location Services (LCS) based SLh and SLg interfaces between the GMLC <-> HSS and GMLC <->MME entities
• User-friendly GUI generates hundreds of UE Signaling for load testing over SCTP/TCP Layers
• Users can apply impairments to messages in the emulator to emulate error conditions
• Supports customizing call flows and message templates using the Script Editor and Message Editor
• Supports scripted call generation and automated call reception
• Provides a protocol trace with full message decoding and graphical ladder diagrams, with time stamps, for visualizing call flows
• Software architecture is script-based and protocol independent
• During call generation, the emulator provides call statistics along with associated captured events and error events
• Supports Command Line Interface (CLI) based on a client-server model, allowing users to control all features through Python APIs
• Support for TCP/TLS for secured information transfer
• Additional licenses for the software allow users to modify messages on its interfaces, supporting different procedures:
• S6a interface - Location Management, Subscriber Data Handling, Authentication, Fault Recovery, and Notification procedures
• S13/S13' interface - Mobile Equipment Identity Check procedure
• CxDx interface – Server and User Authentication procedures
• Gx interface - IP-CAN Session Establishment and Modification procedures
• Gy/Ro interface - Online Credit Control procedure
• Rf interface - Offline Charging procedure
• Rx interface - Initial Provisioning, Modification of Session Information and AF Session Termination procedures
• Sh interface - User Data Handling (User-Data-Update, Subscriber-Notification, User-Data-Pull) procedures
• SLg interface - Subscriber Location procedures
• SLh interface - Location Service Routing Information procedures
• Zh interface - Bootstrapping- procedure

Supported Protocols Standards

Diameter Protocol Stack

S6a Interface

Rx/gx interface, s13/s13' interface.

• Gy Interface
• SLh Interface
• SLg Interface
• Sh Interface

CxDx Interface

The S6a interface enables the transfer of subscriber related data between the MME and the HSS

MAPS™ Diameter at the MME end initiates the following S6a interface procedures:

• initiates the Authentication procedure by sending Authentication-Information-Request message
• initiates the Update Location procedure by sending Update-Location-Request message
• initiates the Purge UE procedure by sending Purge-UE-Request message

MAPS™ Diameter Supporting S6a Interface Procedures (Authentication, Location Update, Notification, Faulty Recovery Procedures)

Call Generation at MME Node (S6a Interface)

Call Reception at HSS Node (S6a interface)

The following illustrates the Authentication Authorization (AA) procedure in Diameter Rx interface and Gx interface:

MAPS™ Diameter Supporting Rx Interface Procedures (Authentication, Authorization - AA Procedures)

The MAPS™ Diameter simulates 3GPP AAA (Authentication Authorization Procedure) call control messages between the AF and PCRF nodes. Supported procedures in Rx interface are - AA-Request/Answer, Re-Auth-Request/Answer, Abort-Session-Request/Answer, Session-Termination-Request/Answer, Subscription to Notification of Signaling Path Status, Access Network Charging Information Notification, Reporting Access Network Information, and Provisioning of AF Signaling Flow Information.

Call Generation (Rx Interface)

Call Reception (Rx Interface)

The following illustrates the ME (Mobile Equipment) Identity Check procedure in Diameter S13 interface:

The Mobile Equipment Identity Check Procedure is used between the MME and the EIR to check the Mobile Equipment's identity status (e.g. to check that it has not been stolen, or, to verify that it does not have faults).

This procedure is mapped to the following commands in the Diameter application -

• ME-Identity-Check-Request (ECR) Command
• ME-Identity-Check-Answer (ECA) Command

S13/S13' Interface Procedure

S13 Interface Node Simulation

Call Reception S13’ Interface

Call Generation S13’ interface

Testing CTF and OCS in Gy/Ro interface

Both Gy and Ro interfaces define procedures for online charging in IMS & LTE networks. Ro interface is between IMS entity (CSCF) and Online Charging System (OCS) & Gy interface is between the PCEF (e.g., PDN GW) and the OCS.

The PCEF node in LTE network, and CSCF node in IMS network perform the role of a Charging Trigger Function (CTF) entity to issue charging events to an Online Charging System (OCS). The charging events can be immediate (IEC), event-based (ECUR), or session-based (SCUR). An Online Charging System (OCS), is a functional architecture that provides support for all three levels (service level, subsystem level, and bearer level) of online charging as depicted in the image below.

MAPS™ Diameter as CTF and OCS

As provided in the figure below, MAPS™ Diameter can be configured as CTF or OCS, while the other acting as the DUT in the network. If MAPS™ Diameter is configured as CTF, it tests the DUT (OCS) by initiating the messages towards OCS.

Similarly, if MAPS™ Diameter is configured as OCS, it tests the DUT (CTF) by receiving the requests from CTF and sending responses back to the CTF (DUT).

MAPS™ configured as CTF in GY/RO interface ( Session Based Charging)

 Session Based Charging is a credit-control process that makes use of several interrogations: the first (INITIAL_REQUEST), a possible intermediate (UPDATE_REQUEST), and the final (TERMINATION_REQUEST). The first interrogation is used to reserve money from the user’s account and to initiate the process. The intermediate interrogations may be needed to request new quota while the service is being rendered. The final interrogation is used to exit the process.

The MAPS™ Diameter as CTF initiates a call by sending a CCR (Credit Control Request) message to the test the OCS. The CCA (Credit Control Answer) response message received back from the DUT (OCS) can be verified as shown in the message sequence window below.

Diameter Gy/Ro Interface Session based Charging Procedure

Call Generation Diameter DCCA Interface for Session Based Charging

MAPS™ configured as OCS in GY/Ro interface ( Event Based Charging)

Event Based Charging is a  one-time event process used when there is no need to maintain any state in the Diameter credit-control server; for example, enquiring about the price of the service. The use of a one-time event implies that the user has been authenticated and authorized beforehand.

In CTF testing, MAPS™ Diameter is loaded with a set of inbuilt scripts to handle the incoming messages. MAPS™ Diameter acts as OCS and sends response to the one-time event based charging request as shown in the message sequence window below.

SLh Interface (Location Service)

The following call flow illustrates the Location Service Routing Info procedure over Diameter based SLh interface between GMLC and HSS entities:

Location Service Routing Info Procedure

MAPS™ Diameter configured as GMLC (Gateway Mobile Location Center) which initiates the procedure to retrieve routing information for LCS of a specified user from HSS.

LCS Routing Procedure for SLh interface

MAPS™ Diameter configured as HSS (Home Subscriber Server) responds with the correct MME identity for the subscriber specified.

Call Reception for SLh interface

SLg Interface (Location Service)

The following call flow illustrates the Provide Subscriber Location and Subscriber Location Report procedures over Diameter based SLg interface between GMLC and MME entities:

• Provide Subscriber Location - The Provide Subscriber Location operation is used by GMLC to request the location of a target UE from the MME
• Subscriber Location Report - Subscriber Location Report operation is used by MME or SGSN to provide the location of a target UE to GMLC when a request for location has been implicitly issued.

MAPS™ Diameter configured as GMLC (Gateway Mobile Location Center) which initiates the procedure requesting MME to provide subscriber location information of the targeted UE.

Provide Location Info Procedure for SLg interface

MAPS™ Diameter configured as MME (Mobile Management Entity) upon reception of the request, performs authentication privacy verification and retrieves the location information of the target UE from E-UTRAN according to the procedure.

Call Reception for SLg interface

Sh interface

Method of communication between the AS (Application Server) function and the HSS (Home Subscriber Server), AS uses the Sh interface in two basic ways:

• To query or update a user's data stored on the HSS
• To subscribe to and receive notifications when a user's data changes on the HSS

The following illustrates the procedure in Diameter Sh interface:

Application is requested for user data In this case, the AS (Application Server) sends a message to the HSS requesting data for a certain user.

Application receives subscription to user data In this case, the AS (Application Server) service subscribers in HSS to receive notifications of changes in user profile data. Once the subscription is established, the HSS will be notified.

Call Generation - Sh Interface

Call Reception - Sh Interface

The Diameter Cx and Dx interfaces are the reference points for interactions between Home Subscriber Server (HSS) and Interrogating Call Session Control Function (I-CSCF) or Serving Call Session Control Function (S-CSCF).

Serving-CSCF (S-CSCF) is always located in the home network. It is the central node of the signaling plane and performs session control as well. S-CSCF uses Diameter Cx and Dx interfaces to the HSS to download and upload user profiles, it has no local storage of the user. All requisite information will be loaded from the HSS.

Interrogating-CSCF (I-CSCF) is an another function located at the edge of an administrative domain. I-CSCF queries the HSS using the Diameter Cx interface to retrieve the user location and then routes the SIP request to its assigned S-CSCF.

Server-Assignment-Request (SAR): The Diameter client in a SIP server sends Server-Assignment-Request command to the Diameter server to indicate the completion of the authentication process and to request that the Diameter server store the URI of the SIP server that is currently serving the user. The main functions of the Diameter SAR command are to inform the Diameter server of the URI of the SIP server allocated to the user, and to store or clear it from the Diameter server.

Server-Assignment-Answer (SAA): The Diameter server sends Server Assignment Answer command in response to a previously received Diameter Server-Assignment-Request (SAR) command. The response may include the user profile or part of it, if requested.

User-Authentication-Request (UAR): The Diameter client in a SIP server sends User Authentication Request command to the Diameter server to request authorization for the SIP User Agent to route a SIP REGISTER request. Because the SIP REGISTER request implicitly carries a permission to bind an AOR to a contact address, the Diameter client uses the Diameter UAR as a first authorization request towards the Diameter server to authorize the registration.

User-Authentication-Answer (UAA): The Diameter server sends User-Authentication-Answer command in response to a previously received Diameter User-Authorization-Request (UAR) command. The Diameter server indicates the result of the requested registration authorization.

Call Generation - CxDx Interface

Call Reception - CxDx Interface

Diameter Base Protocol: Establishing a Diameter Peer Connection

This chapter provides information about configuring and troubleshooting the Diameter Base protocol to establish a Diameter peer connection.

Topics in this chapter include:

Applicability

Configuration.

This information and configuration in this chapter are based on SR OS Release 19.10.R1.

This chapter covers the Diameter base protocol implementation that is available from SR OS Release 16.0.R4 onward (configured in the aaa CLI context as diameter node ). The legacy Diameter base implementation (configured in the aaa CLI context as diameter-peer-policy ) is supported in maintenance mode only, without any further feature enhancement planned. Nokia recommends using or transitioning to the new Diameter base protocol implementation.

Diameter is an Authentication, Authorization and Accounting (AAA) protocol defined by the IETF in RFC 6733, Diameter Base Protocol . While historically wireline access networks were largely based on RADIUS for subscriber authentication, authorization, and accounting, it was decided by 3rd Generation Partnership Project (3GPP) that wireless access networks will be largely based on Diameter. Over time, operators are looking to converge both types of networks, and one of the aspects of this is to replace RADIUS in wireline access networks by Diameter.

Diameter is based on three layers: the transport layer, the Diameter base protocol layer and the Diameter applications as shown in Diameter protocol stack .

The bottom layer is the transport layer and can be either TCP or SCTP. SR OS supports TCP. The Diameter base protocol implementation in SR OS is based on RFC 6733. The top layer contains the Diameter applications. SR OS supports NASREQ for authentication, Gx for authorization, policy management and usage monitoring and Gy or Diameter Credit Control Application (DCCA) for online charging.

Diameter network topology shows a Diameter network topology that will be used in the configuration examples in this chapter.

A Diameter Client (BNG) is connected via peer-1a and peer-1b to two Diameter Agents (DRA-1 and DRA-2) that provide connectivity to the Diameter Application Servers (PCRF). Via these peers, the BNG can authenticate and perform policy control of subscriber sessions using the NASREQ and Gx applications. The same Diameter Client (BNG) is also directly connected to another Diameter Application Server (OCS) via peer-2. Via this peer, on-line charging can be done for the subscriber sessions using the Gy application.

The Diameter base protocol and the Diameter applications are configured separately, where the Diameter base protocol must be configured first, and the Diameter applications next. The transport layer configuration is part of the Diameter base protocol layer. This example describes the Diameter base protocol configuration.

The Diameter base protocol and the corresponding transport layer configuration is based on Diameter Nodes. Each Diameter Node represents a Diameter routing instance and contains a list of peers in the routing domain that provide direct or indirect connectivity to application servers.

An example Diameter node configuration that corresponds with the topology in Diameter network topology is shown below.

A Diameter node configuration requires a unique origin host as key. The origin host is used in Diameter application policies to associate the application with the node. All Diameter base and application messages forwarded via the peers of that node use the configured origin host in the Origin-Host AVP. The value for the Origin-Realm AVP is by default derived from the configured origin host: the realm is the part of the origin host after the first dot (".") as delimiter or equal to the origin host when it does not contain a delimiter. For example, for node " bng-gx.realm-1.com ": Origin-Host = "bng-gx.realm-1.com", Origin-Realm = "realm-1.com". It is also possible to explicitly configure an origin realm as shown in the example for the node " bng-gy.realm-1.com ".

A node configuration can include a routing context, and an IPv4 and/or IPv6 source address. These parameters are used to establish the TCP transport connection for all peers in the node. The specified source address must be a reachable local interface address in the specified or in the default routing instance. For node " bng-gx.realm-1.com " in the example, no routing instance is specified. By default, the TCP connections are established in the Base router using the specified source addresses. For node " bng-gy.realm-1.com " in the example, the out of band routing instance router " management " is used to establish the TCP connection of its peer. As no source address is specified, the system will automatically select an interface address, in this case an out of band IP address configured in the Boot Options File (BOF).

Within a Diameter node, up to 5 peers can be configured with an index value between 1 and 5 as key, an IPv4 or IPv6 destination address for the TCP connection, and a mandatory destination host that is used as Destination-Host AVP value for all Diameter base messages on the peer. In a Diameter node, one peer is selected to forward application messages for a specific application session. The other peers provide redundancy when supported by the Diameter application, such as Gy session failover. A Diameter peer for application messages is selected based on following criteria:

Forwarding:

If the application message contains a Destination-Host AVP, select the peer in the peer table with a matching configured destination host. This is the forwarding phase.

When the lookup in the peer table fails, perform a lookup in the realm routing table and select the peer with realm name equal to the Destination-Realm AVP in the application message, and with matching application ID. When multiple peers are matched, select in order of priority until a single peer is found:

the peer with the lowest configured preference (default preference is 50)

the peer with the lowest index

Default peer:

When both forwarding lookup in the peer table and routing lookup in the realm routing table were unsuccessful, use the peer configured as default-peer . Only a single peer in a node can be configured as a default-peer:

For node " bng-gx.realm-1.com " in the example, peer-1a with index 1 has a configured preference of 10 and peer-2 with index 2 has a configured preference of 20. Diameter Gx application messages will fail the peer table lookup as the destination host of the PCRF will not be present (no direct connection between Diameter client and Diameter application server):

Instead a realm routing table lookup is performed to find the peer for forwarding the application messages. In this case peer-1a (dra-1.realm-2.com) is selected based on the matching destination realm (realm-2.com), application ID (Gx) and the lower preference value:

The realm routing table is populated based on the Origin-Realm AVP and Application-Id AVP received in the Capability Exchange Answer message together with the configured index and preference values.

Note that Diameter answer messages do not rely on peer or realm routing table lookups. Answers are forwarded over the same route in the reverse direction of the matching requests. This is achieved with a transactional cache in each traversed Diameter node, using the Hop-by-Hop AVP to match requests with answers.

When enabling the peer (no shutdown), the system tries to establish the transport TCP connection. Once the TCP session is up, the system starts a Diameter Capability Exchange using the configured Diameter identity (Origin-Host and Origin-Realm AVPs) and advertising support for all SR OS Diameter applications in Application-Id AVP's (NASREQ, Gx, and Gy). When the Origin-Host AVP in the received CEA message corresponds with the destination host configured for the peer (case insensitive) and at least one application in the CEA is common with the SR OS advertised applications, then the peer moves to the I-Open state (I from Initiator). An example of a Capability Exchange is illustrated in detail in the troubleshooting section.

Optionally, a connection and a watchdog timer can be configured in the Diameter node:

connection-timer

The connection timer or Tc timer controls the frequency at which a transport connection is attempted to be established. The default value is 30 seconds. This timer can be configured per node to be used by all peers or overridden per peer.

watchdog-timer

The watchdog timer controls the frequency at which Device-Watchdog-Request messages are transmitted to the peer, and is called the Tw timer in RFC 3539, Authentication, Authorization and Accounting (AAA) Transport Profile . A small timer results in a faster detection of a peer failure at the expense of generating more messages. The timer is configured per peer and its default value is 30 seconds.

A Python policy can be configured in the Diameter node to manipulate Diameter messages transmitted to and/or received on its peers.

Manipulating Diameter messages, such as changing the content or format of AVPs using Python is out of the scope of this chapter.

By default, Diameter messages are sent with a DSCP set to AF41. The DSCP value can be changed with the sgt-qos configuration:

SR OS uses TCP as transport and the TCP destination port number is fixed to the standard Diameter base protocol port 3868. The source port is randomly chosen from the ephemeral port range.

Troubleshooting

The status and statistics of the Diameter peers can be verified with following show commands:

To clear the peer statistics, use following command:

Diameter debugging is split between node and application level:

In this chapter, the Diameter base protocol debugging for peer messages is explained, configured at the node level debug. When a Python script is active for the node, the debug messages are logged after Python processing.

To debug the Diameter base protocol messages for peer " dra-1.realm-2.com ", use the following debug commands:

The peer-to-peer option enables debug output for all Diameter base messages of the specified peer: Capabilities Exchange, Device Watchdog and Disconnect Peer messages. By default, error conditions are also logged in the debug output. Debug for error conditions can be disabled per Diameter node or per peer with the debug option no on-error . Errors reported at the node level include Diameter base errors that are unrelated to a peer, such as a routing problem for a Diameter application message. Errors reported at the peer level include all errors that occur after peer selection and peer connection errors.

Let's start with the peer connection in Closed state (remote end rebooting):

The Connection timer (s) field in above peer details output show that in 18 seconds, a new connection attempt will be made, followed by a Capabilities Exchange when successful. The transmitted Capabilities-Exchange-Request (CER) and received Capabilities-Exchange-Answer (CEA) are shown in the debug output:

The result of the successful Capabilities Exchange is that the peer moved to the I-Open state, ready to forward NASREQ and Gx application messages:

The Watchdog timer (s) field in preceding peer details output shows that in 9 seconds, a Device Watchdog exchange will be initiated. The transmitted Device-Watchdog-Request (DWR) and received Device-Watchdog-Answer (DWA) are shown in the debug output:

Now let's try to bring up the peer in the node bng-gy.realm-1.com :

Debug is enabled at the peer level for error conditions without the peer-to-peer option. Failures are reported, but not all transmitted and received peer messages.

The Diameter server is provisioned with an origin host different from the configured destination host for the peer, resulting in a failure and peer reset:

Following events are defined for the Diameter base protocol:

The tmnxDiamNdPeerStatActiveChanged event is generated when the state of a Diameter peer toggles between active / not active:

The tmnxDiamMessageDropped event is generated when Diameter base drops a malformed message.

As a result of fixed mobile network convergence, Diameter is used in fixed access networks as an alternative for Radius based AAA. Diameter peering provides reliable and secure transport with peer redundancy. Its functionality is defined in a base Diameter protocol specified in RFC 6733. Various applications can be layered on top of base Diameter and they can utilize the robust transport capabilities that Diameter provides.

September 22, 2023

IMS Diameter Server Module

Carsten bock.

Copyright © 2016-2017 ng-voice GmbH

Table of Contents

List of Examples

Chapter 1. Admin Guide

1. overview.

This module implements a generic Diameter Server.

This module translates incoming Diameter Messages into a JSON structure and will pass this on to the routing engine for further operations.

The module expects a reply (again in JSON), which then is translated into a Diameter Response.

Additionally, it allows you to send Diameter-Requests to another peer.

The JSON contains an array with all AVP's in the Diameter-Message and its attributes. The format is identical for both requests and replies.

The module could be used (for example) for:

a Home-Subscriber-Server (it was written do be used as one)

a Charging-Server (Ro/Rf)

for testing Diameter-Applications

a PCRF/PCEF Emulator/Gateway

a Diameter-Routing-Agent (DRA)

2. Dependencies

2.1. kamailio modules.

The following modules must be loaded before this module:

CDP - C Diameter Peer

CDP_AVP - CDP AVP Applications

2.2. External Libraries or Applications

No external libraries are required.

3. Functions

3.1.  diameter_request([peer], appid, commandcode, message).

This method will send a Diameter Request.

Meaning of the parameters is as follows:

peer - send the diameter request directly to a diameter peer [optional]. If this parameter is omitted, the default routing is used (see CDP).

appid - Diameter-Application, e.g.:

Typical App-ID's are:

16777216 - Diameter Cx/Dx

16777217 - Diameter Sh

4 - Diameter Ro (Online Charging)

commandcode - Diameter-Command-Code, e.g.:

300 - Diameter Cx/Dx User-Assignment Request (UAR)

301 - Diameter Cx/Dx Server-Assignment Request (SAR)

message - the Diameter Message (as JSON), which should be sent.

This function can be used from any route.

Example 1.1.  diameter_request usage

3.2.  diameter_request_async([peer], appid, commandcode, message)

This method will send a Diameter Request asynchronously. The Reply to this request will be visible in the event-route "diameter:response".

The meaning of the parameters are identical to the diameter_request function.

This function is only available, if the diameter:response event-route is defined.

4. Exported Pseudo Variables

4.1.  $diameter_application.

This PV provides the requested Diameter Application, for example:

4.2.  $diameter_command

This PV provides the requested Diameter Command, for example:

4.3.  $diameter_request

This PV provides the Diameter Request as JSON.

4.4.  $diameter_response

The Response is read from the PVAR.

5. Event routes

5.1.  diameter:request.

This route is called for any incoming Diameter Request

5.2.  diameter:response

This route is called for incoming Diameter replies, if the request was processed asynchronously.

Diameter SWx Interface explained.

The SWx interface is a diameter protocol-based interface between the AAA server and HSS. AAA means Authentication, Authorization, and accounting. The standard protocol is defined in 3GPP Spec .   This interface is used when UE does non-3GPP access. We have discussed in the  s6a interface that MME is the node in EPC that does the authentication with the HSS over the s6a interface.

But why do we need another interface for authentication, e.g., SWx? This is because LTE provides a way to connect UE from a network other than MME. This may be a non-3GPP network. One example is WiFi calling . Where a home WiFi antenna works as an LTE tower. The following diagram shows the SWx interface and other interfaces in EPC.

  Procedures/messages over the SWx interface:

This section describes the protocol messages over the SWx interface. The base protocol is the diameter. Over the base, the application uses 3GPP application id 16777265.

Multimedia Authentication Request (MAR)/Answer(MAA) :

AAA server sends this command to the HSS for accessing security information. The command code value is 303. In the message, there is a diameter AVP called User Name. This AVP may have a subscriber IMSI for identifying a subscriber on HSS. If the subscriber is found and allowed to use non-3GPP access, HSS returns the security information in the answer command; else, an error is returned, and authentication fails.

Push Profile Request (PPP)/Answer(PPA): 

The push profile request command has command code 505. HSS sends this command to the AAA server if any subscription data has been changed on the HSS for a subscriber. The data may be related to the call or other.

E.g., if a mobile user’s validity has expired, then HSS will push the subscriber data, where the subscriber will not be allowed to make calls. AAA server successfully updated the data. Then the answer message has success. Else has an error code.

Server Assignment Request (SAR)/ Answer (SAA):

The command code for the server assignment request is 301. AAA server initiates the request towards the HSS. This can be a register, a user profile download, and use a de-registration request. If all is fine on HSS, there is a success in the answer else error code.

Registration termination request (RTR)/Answer(RTA) :

The command code is 304. The multimedia server sends this message to a multimedia client over the Swx interface for the de-registration of a client.

Navigation Menu

Search code, repositories, users, issues, pull requests..., provide feedback.

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly.

To see all available qualifiers, see our documentation .

• Notifications You must be signed in to change notification settings

Implementation of Diameter Server-Client architecture using Python Diameter library

sandu-alexandru/asn_diameter_python

Folders and files.

Repository files navigation

Diameter client-server architecture in python.

This repository contains a sample server which can be used as an Diameter Terminator (sending Diameter responses to specific requests) for the purpose of testing, which I plan to develop further in the future, in order to simulate a CDF (Charging Data Function).

For additional information about the Diameter Protocol, please consult https://tools.ietf.org/html/rfc6733

Currently, the Diameter Server can only process requests with following command codes:

• 257 (Capability Exchange), sending an answer containing information based on the data present in the AVPs of the request message.
• 280 (Device Watchdog), sending a watchdog answer based on requests data to ensure the connection keepalive mechanism.

This is to be improved, mainly by Accounting messages support with Rf charging implementation(Session management, etc.).

**On any Diameter request that is being processed having a command code which is not present/implemented support for, the application will respond with DIAMETER_UNABLE_TO_COMPLY(5012) result code

Protocol information

Diameter is a Authentication Authorization and Accounting (AAA) protocol. It works on the Application Layer if we consider OSI Layered model. Diameter is a message based protocol, where AAA nodes exchange messages and receive Positive or Negative acknowledgment for each message exchanged between nodes. For message exchange it internally uses the TCP and SCTP which makes diameter reliable. Its technical specifications are given in RFC-6733 Diameter Base Protocol.

Diameter is Message (Packet) based protocol. There are two types of messages Request Messages and Answer Messages. The message structure is of following sort:

A summary of the Diameter header format is shown below. The fields are transmitted in network byte order.

Capability negotiation

The basic motive of this process is to KNOW about the other node to which a node intended to communicate before establishing the connection, ie. whether other node contains the applications for which node wants to communicate.

Technically speaking, It is the process where two diameter peer exchange their identity and its capabilities (such as protocol version number, supported diameter applications, security mechanism etc.). Peer share their capabilities by CER/CEA Message (Capability-Exchange-Request/Capability-Exchange-Answer).

The Capabilities-Exchange-Request (CER), indicated by the Command Code set to 257 and the Command Flags' 'R' bit set, is sent to exchange local capabilities.

Message Format

The Capabilities-Exchange-Answer (CEA), indicated by the Command Code set to 257 and the Command Flags' 'R' bit cleared, is sent in response to a CER message.

Transport Failure Detection

Given the nature of the Diameter protocol, it is recommended that transport failures be detected as soon as possible. Detecting such failures will minimize the occurrence of messages sent to unavailable agents, resulting in unnecessary delays, and will provide better failover performance. The Device-Watchdog-Request and Device- Watchdog-Answer messages, defined in this section, are used to pro- actively detect transport failures.

Device-Watchdog-Request

The Device-Watchdog-Request (DWR), indicated by the Command-Code set to 280 and the Command Flags' 'R' bit set, is sent to a peer when no traffic has been exchanged between two peers (see Section 5.5.3). Upon detection of a transport failure, this message MUST NOT be sent to an alternate peer.

Device-Watchdog-Answer

The Device-Watchdog-Answer (DWA), indicated by the Command-Code set to 280 and the Command Flags' 'R' bit cleared, is sent as a response to the Device-Watchdog-Request message.

• Python 100.0%

Nick vs Networking

Telco network engineering.

Diameter and SIP: User-Authorization-Request/Answer

These posts focus on the use of Diameter and SIP in an IMS / VoLTE context, however these practices can be equally applied to other networks.

The Diameter User-Authorization-Request and User-Authorization-Answer commands are used as the first line of authorization of a user and to determine which Serving-CSCF to forward a request to.

When a SIP Proxy (I-CSCF) receives an incoming SIP REGISTER request, it sends a User-Authorization-Request to a Diameter server to confirm if the user exists on the network, and which S-CSCF to forward the request to.

When the Diameter server receives the User-Authorization-Request it looks at the User-Name (1) AVP to determine if the Domain / Realm is served by the Diameter server and the User specified exists.

Assuming the user & domain are valid, the Diameter server sends back a User-Authorization-Answer , containing a Server-Capabilities (603) AVP with the Server-Name of the S-CSCF the user will be served by.

I always find looking at the packets puts everything in context, so here’s a packet capture of both the User-Authorization-Request and the User-Authorization-Answer .

First Registration

If this is the first time this Username / Domain combination (Referred to in the RFC as an AOR – Address of Record) is seen by the Diameter server in the User-Authorization-Request it will allocate a S-CSCF address for the subscriber to use from it’s pool / internal logic.

The Diameter server will store the S-CSCF it allocated to that Username / Domain combination (AoR) for subsequent requests to ensure they’re routed to the same S-CSCF.

The Diameter server indicates this is the first time it’s seen it by adding the DIAMETER_FIRST_REGISTRATION (2001) AVP to the User-Authorization-Answer .

Subsequent Registration

If the Diameter server receives another User-Authorization-Request for the same Username / Domain (AoR) it has served before, the Diameter server returns the same S-CSCF address as it did in the first User-Authorization-Answer .

It indicates this is a subsequent registration in much the same way the first registration is indicated, by adding an DIAMETER_SUBSEQUENT_REGISTRATION (2002) AVP to the User-Authorization-Answer .

User-Authorization-Type (623) AVP

An optional User-Authorization-Type (623) AVP is available to indicate the reason for the User-Authorization-Request. The possible values / reasons are:

• Creating / Updating / Renewing a SIP Registration (REGISTRATION (0))
• Establishing Server Capabilities & Registering (CAPABILITIES (2))
• Terminating a SIP Registration (DEREGISTRATION (1))

If the User-Authorization-Type is set to DEREGISTRATION (1) then the Diameter server returns the S-CSCF address in the User-Authorization-Answer and then removes the S-SCSF address it had associated with the AoR from it’s own records.

Other Diameter Cx (IMS) Calls

User-Authorization-Request / User-Authorization-Answer Server-Assignment-Request / Server-Assignment-Answer Location-Info-Request / Location-Info-Answer Multimedia-Auth-Request / Multimedia-Auth-Answer Registration-Termination-Request / Registration-Termination-Answer Push-Profile-Request / Push-Profile-Answer

References:

3GPP Specification #: 29.229

RFC 4740 – Diameter Session Initiation Protocol (SIP) Application

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Sign me up for future posts via email.

Want more telecom goodness?

I have a good old fashioned RSS feed you can subscribe to.

You can get the latest posts dropped into your inbox by subscribing to our mailing list Your email address

I cross post some of this content to LinkedIn and Twitter .

draft-ietf-aaa-diameter-sip-app-02 Internet-Draft

• About the Dictionary
• Diameter Result Codes

Seagull - Diameter protocol

Diameter protocol details, first try explained, generic configuration, actions in commands for diameter.

The implementation of Diameter in Seagull conforms to RFC 3588 . Other applications, like 3GPP/IMS applications (Cx, Dx, Ro, Rf, Sh, ...) are available through Seagull dictionaries.

Getting started with Diameter

So that you can get familiar with Seagull in the context of Diameter, here is an example that will launch one Diameter server (a server expects a message as the first scenario command) and one Diameter client (a client sends a message as the first scenario command). The client and the server will talk to each other using the loopback interface (127.0.0.1). The scenario is the following:

Open two terminal sessions. Terminal 2 will be the server and Terminal 1 the client. Examples are located in the "run" directory. So the first thing you need to do is to go in this directory (in both terminal windows):

In Terminal 2 window type:

In Terminal 1 window type:

On Terminal 2 (server side), you will see:

If you have Ethereal tool that is started to monitor local (lo) interface, then you should see the Diameter traffic.

If you don't have Ethereal, you can take a look at Seagull's log files, which also contain the decoded Diameter messages if Seagull is started with "M" log level ( -llevel ETM ). By default, those files are respectively client.date.log and server.date.log , suffixed with the date and time at which traffic started.

How easy was that? Now let's jump to the next section to learn how all that works.

Here is the script (start_client.ksh) that launched the client in our example:

Our example is based on one client that takes care of sending SAR and receiving SAA messages and one server that takes care of receiving SAR and answering SAA messages.

Both sides are relying on the Diameter Base/Cx dictionary provided with Seagull: base_cx.xml to encode Diameter messages. Refer to dictionary configuration section for more information on the format of this dictionary. The dictionary is specified using the -dico parameter on the command line .

The generic configuration (including network and other parameters) is different for the client and the server. The client uses conf.client.xml and the server uses conf.server.xml . The configuration file is specified using the -conf parameter on the command line .

Here are both files:

Example client and server configuration

As you can see, the only practical differences between a server and a client are the "mode" (that can be either server or client) in the open scenario command and the call-rate parameter which is only specified on the client side.

Now comes the real stuff: the scenario.

First, the scenario source: sar-saa.client.xml

And now the commented version:

In this example, the init section takes care of sending a CER and receiving a CEA. You can put any <avp> described in the base_cx.xml dictionary. The traffic section keeps sending SAR/SAA messages.

The generic configuration file describes the network environment as well as traffic parameters.

The network environment is described through " transport channel entities ". The transport entity is then used as an attribute of send and receive scenario commands, as well as during the opening of the transport channel (see below).

Diameter dictionary

Diameter is constituted of a base protocol and additional "applications". In order for Seagull to be versatile enough, Diameter messages and parameters are described in an XML dictionary. Seagull comes with a complete Diameter base and Cx interfaces dictionary.

A dictionary contains several XML sections

"types" section contains all types needed for the protocol. For Diameter, these are:

"header" section contains the description of message header. For Diameter, this is:

"body" section contains the description of message body (which naturally comes after the header). For Diameter, this is:

"dictionary" section contains all possible parameters that a message can contain. Here is a description for some Diameter AVPs:

"command" section contains all possible Diameter messages (called command in RFC 3588). Here is an example of Diameter messages:

The <send> and <receive> scenario commands include an <action> and <command> section.

The <action> section can be placed before or after the <command> section.

Actions placed before the command (called " pre-actions ") are executed before the message is actually sent or received. Actions placed after the command (called " post-actions ") are executed after the message is sent or received.

In the context of Diameter, the following actions are used to maintain Diameter Hop-by-Hop ID, End-to-End ID and Session ID. Example:

Actions that can be placed after a command are actions to retrieve an AVP value after the message has been received. Example:

The list of possible actions is available in the reference section.