Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?


Interworking of AAA with Service Control Gateway


The AAA functionality in Service Control Gateway includes the following characteristics:

  • The Packet Forwarding Engine receives RADIUS messages on the default port number of 1813 and Diameter requests on the default port number of 3868.

  • The received Accounting request is parsed.

  • Detection and handling of RADIUS duplicate requests of occurs.

  • Interaction with the application framework.

  • Start and stop of sessions.

  • Diameter connectivity with PCRF and OCS.

  • Formatting and parsing of Diameter messages.

  • Two levels of Diameter retransmission: retransmission to next reachable address (peer) within the same 'virtual' server configured as Diameter- network-element. A Diameter-network-element is a collection of interchangeable peers. Also, retransmission to the next 'virtual' server (target) within a Diameter profile.

  • Delivery of server responses and server-initiated requests to application framework.

  • Intimation to the application framework about server restart indicated by Origin-Host-Id

Processing Incoming RADIUS Requests

TDF acts as RADIUS Accounting server. RADIUS Accounting Start triggers session creation and downloading rules from PCRF. Parsed incoming RADIUS request data serves as a material for constructing the Diameter CCR. The following sequence describes AAA part of RADIUS request processing:

  1. Parsing the request and obtaining the Framed-IP-Address attribute value.

  2. Selecting a TDF domain by evaluating the tdf-domain-selection terms against the received data.

  3. Selecting the session PIC to handle this Framed-IP-Address .

  4. Handling duplicate requests.

  5. Reading VRF and subscription-id from tdf-domain.

  6. Informing application about RADIUS event Application is provided with parsed request data in the same way (and the same API) as used by Diameter support in PGW.

Processing Accounting On/Off and Immediate Accounting Response to subscriber edge network element

When TDF receives Accounting On or Off, it starts a background job of removing all sessions associated with that NAS-IP-Address/NAS-Identifier. The associated sessions can reside on more than one SPIC and the background job is propagated to other SPICs if necessary. The session creation on TDF is triggered by Accounting-Start message from subscriber edge network element. TDF interacts with PCRF to get policies to establish the session. To reduce the turnaround time from TDF to subscriber edge network element, TDF contains an option (per-domain) to enable or disable the accounting response from TDF even before the session establishment finishes at TDF.

Enabling this option causes TDF to send response to subscriber edge network element as soon as the request is received. TDF receives policies from PCRF and finish the local establishment before replying if this option is turned off. The advantage of enabling immediate accounting response is a quick turnaround time from TDF. This behavior avoids timeouts at subscriber edge network element.

Subscription-Id Values

RADIUS request can contain user identity in different forms and formats. TDF must configured with predefined choices of exactly the same attributes configured in the CCR as subscription-id. The CCR can contain multiple subscription-ids. The following choices are recognized on TDF:

The configuration of subscription-id is done for each TDF domain. The CLI provides provision to configure six ordered lists of subscription-id combinations per domain. Each combination can have a maximum of three components. The following is an example configuration of susbcription ID values:

In the aforementioned configuration, two different sets are configured, namely, IMSI + MSISDN and NAS-PORT + NAS-PORT-ID. The constant default- subscription-id-option value is also configured. While sending the CCR-I towards PCRF, TDF analyzes the values received in Accounting-Start message and tries to encode the subscription-id sets in the order of configuration. The first set that can be fulfilled with the available values is sent to the PCRF. If the Accounting-Start message has IMSI and MSISDN values, the CCR-I has two instances of subscription-id AVP with IMSI and MSISDN types. Similarly, if NAS-PORT and NAS-PORT-ID are available instead of IMSI and MSIDDN, they are sent to PCRF. If no set of subscription-id-options list can be encoded, the constant value is used as subscription-id in CCR-I to PCRF. A failure to encode any of the provided options and non-availability of constant subscription-ID value causes a session establishment failure.

Some IDs are having the type END_USER_PRIVATE on Gx interface. They cannot be distinguished by looking at the type encoded within the AVP. The configuration is performed according to the agreement with PCRF. The following are the possible combinations of subscription-ID value combinations that may be used by the operator :

  • Mobile Subscribers—IMSI and/or MSISDN value

  • Wireline Subscribers

    • NAI and “NAS-PORT or NAS-PORT-ID”

    • Username and/or realm and “NAS-PORT or NAS-PORT-ID”


The CLI does not contain strict checks to make sure that only the above combinations can be configured. The flexibility is being provided to take care of any requirement that may be come up at a later stage. The CLI only does the basic validation checks to ensure the sanity of the configuration.

Selection of a TDF Domain

The key for TDF session context lookup is subscriber data plane VRF and subscriber address. TDF derives the “data plane” VRF from tdf-domain configuration. Incoming RADIUS request serves as an input criterion for the tdf-domain to be selected. The TDF domain is selected based on a term.

You can configure a term that can be used to select the TDF domain for the subscriber. Multiple terms (up to 10 terms) can be configured for the TDF domain selection, and each term is applied in the order in which it is configured. Multiple match conditions can be specified within the from statement of a term, and all of the conditions have to match. If the incoming RADIUS request from the subscriber matches the criteria in a term, then the TDF domain specified in the then statement of the term is used to create the TDF subscriber session.

A term can also be used to select a PCEF profile for a subscriber. This is required if the TDF domain selected for a subscriber does not specify a PCEF profile or you want to allow different members of the same TDF domain to have different PCEF profiles.

Once a term matches and a TDF domain is selected, further terms are not evaluated if the PCEF profile is specified in either the then statement or in the selected TDF domain. If a PCEF profile is not specified in either the then statement or in the selected TDF domain, further terms are evaluated to find a PCEF profile for the subscriber.

Guidelines for AAA Interoperation With TDF

The following important points and operational notes apply to AAA processing for TDF subscriber sessions:

  • The application framework and AAA modules maintain a context for each session. The context database is indexed by the VRF and IP address combination. When a RADIUS request arrives, a lookup of the context by the {VRF, Framed-IP-Address} combination is performed. A context contains subscriber identity (IMSI or MSISDN) and the list of all Acct-Session-Ids. An idle timeout is the duration after which inactive sessions are deleted (by sending CCR-T).

  • When an accounting start message is received, the context using the (VRF, Framed-IP-Address) combination is determined. If the context is not present, the session is created. The CCR-I message is transmitted to download rules from PCRF. If the context is already present, then if both identity and APN (Called-Station-Id) are the same (in the received request and the context), it is assumed that this request is for the same session. A CCR-I message is not sent in such a scenario. If either identity or APN (Called-Station-Id) is different, a new session is initiated because termination of the existing session might have not been performed. The existing session (sending CCR-T) is detached and a new session (sending CCR-I) is created. The context is updated with the received Acct-Session-Id.

  • When the accounting stop message is received, and if the context is present, a verification is made for the stop indicator. If the stop indicator is present in the request, then the detach procedure is initiated (sending CCR-T). An accounting response is sent. If the stop indicator is not present, and if Acct-Session-Id matches one of those in the cookie, then it is nullified. If all Acct-Session-Id in the cookies are nullified or crossed out, then the detach procedure is initiated (sending CCR-T). An accounting response is sent. Otherwise, the Acct-Session-Id does not match any of those in the context) the request is dropped. An accounting response is not sent. Similarly, if the context is not present, the request is dropped.

  • When an interim accounting message is received, and if the context is present, for a matching Acct-Session-Id with one of the IDs in the cookie, an accounting response is sent. If the Acct-Session-Id does not match any of those in the context, the request is dropped and an accounting response is not sent. If the context is not present, it possibly denotes that the session was erroneously deleted by inactivity timeout (which indicates misconfiguration of timeout value) or that the previous Accounting Start was lost (or out-of-order). A session is created and a CCR-I is transmitted to download rules from PCRF. We may receive Accounting-Start for the very same session later (if it is out-of-order or if first retransmission was lost).

Application Function and AAA Interaction

The SMD interacts with AAA in the following cases:

  • Attach request—The SMD-AF initiates a session for the specified user (IP address, APN, and IMSI). After completing the attach functions, a response is sent to AAA. The response indicates success/failure depending on whether the session is setup or not.

  • Detach request—The SMD terminates the session for the specified user. After the session is terminated, a response is sent to AAA.

  • PGW Restart event—The SMD terminates all sessions that are initiated from this client using a background job. NAS-ip-address and/or NAS-identifier of a given client PGW, is used to identify the sessions from this client. When an attach request cannot be handled because of overload, the SMD informs about CAC to AAA. The AAA will redirect the request to another SPIC. After a session is setup for a user, if any failure is encountered, the SMD informs the AAA to clean up the session.

The Packet Forwarding Engine system component is responsible for packet steering, at its core. But as a part of the Mobile Broadband Gateway solution, the Packet Forwarding Engine has been enhanced to provide subscriber-aware forwarding plane, which is capable of providing subscriber-aware and flow-aware services in an inline form. These enhancements will be leveraged to provide a uniform, scalable and efficient “subscriber-aware” data plane for TDF. Subscriber in TDF is an entity represented by its IP address. The IP address is the one that was assigned to the subscriber by the GGSN/PGW. In addition to the IP, TDF uses the routing instance that the subscriber belongs to, to provide IP isolation for subscribers belonging to different access point nodes (APNs), as well as to be able to interact with multiple GGSN/PGW. So essentially in TDF, the subscriber is represented by (VRF ID, IP address) pair.

The Packet Forwarding Engine subsystem can operate in non-anchor Packet Forwarding Engine mode where it acts as a packet steering entity that is responsible for steering of data traffic to the tethered service modules implemented in Service PICs. In this mode the forwarding plane is not subscriber-aware, but rather directs subscriber traffic to the services plane for further processing. The service plane is subscriber-aware and is able to provide subscriber-aware services on the subscriber traffic. In addition, Packet Forwarding Engine is also responsible for steering of control packets to Session plane that is comprised of Session PICs. Functionally, the following components contribute to the forwarding path functionality in TDF:

  • Packet handling at subscriber edge network element facing and MIF interface

  • Control packet steering

  • Packet handling at the service Packet Forwarding Engine