Connecting ECE to a RADIUS Client

Overview of Authentication and Accounting Using RADIUS Gateway

You use RADIUS Gateway for authenticating access requests and processing accounting requests for online charging when your customers use your terminal server or NAS to connect to ECE. RADIUS Gateway does the following when it receives a request from the RADIUS client:

Translates the request into an ECE request.
Submits the ECE request to the ECE server.
Receives the ECE response from the ECE server and translates it into a RADIUS message response.
Sends the RADIUS message response to the RADIUS client.

The following steps summarize how to set up ECE for authentication and accounting using RADIUS Gateway:

Add additional RADIUS Gateway nodes required for your topology and configure each instance.
(Optional) Customize the RADIUS data dictionary to include custom vendor-specific attributes.
Load your event definitions from PDC into ECE.
Load customer data and data keys from BRM into ECE.
Load the RADIUS mediation specification data.
Map RADIUS network attributes to event attributes.
Start the RADIUS Gateway nodes.

When the RADIUS Gateway nodes start, they automatically join the Coherence cluster gaining access to ECE caches and invocation services that it uses to send requests to ECE.

About RADIUS Gateway Authentication

RADIUS Gateway supports the following authentication mechanisms for querying the ECE server and authenticating access requests:

Password Authentication Protocol (PAP). An authentication protocol that uses the user name and password to validate users. See "Authenticating Access Requests by Using PAP" for more information on how RADIUS Gateway performs the PAP authentication.
Challenge Handshake Authentication Protocol (CHAP). An authentication protocol that authenticates a user to a network entity; for example, the Web. This protocol ensures that the server sends a challenge to the RADIUS client after the RADIUS client establishes a network connection to access the Web server. See "Authenticating Access Requests by Using CHAP" for more information on how RADIUS Gateway performs the CHAP authentication.
Extensible Authentication Protocol (EAP). An authentication protocol that supports multiple authentication mechanisms for authenticating network access; for example, EAP-Message Digest 5 (MD5). See "Authenticating Access Requests by Using EAP" for more information on how RADIUS Gateway performs the EAP authentication.

Authenticating Access Requests by Using PAP

You use PAP to authenticate access requests based on the clear-text user name and user password. Only Access-Request requests are considered for PAP authentication: other messages are ignored. The PAP authentication is performed based on the User-Name and User-Password AVP values in the Access-Request request.

The PAP authentication process is as follows:

RADIUS Gateway receives the Access-Request request from the RADIUS client.
RADIUS Gateway authenticates the RADIUS client using the sharedsecret password that you provided during installation.

Note:

If RADIUS clients are represented by using an IP address range, ensure that all the RADIUS clients within the IP address range use the same sharedsecret password.
RADIUS Gateway translates the Access-Request request into an ECE query.
RADIUS Gateway sends the query with the User-Name AVP value to the ECE server to validate the user name.
If the user name is not found in the ECE server, the ECE server returns a failed response. RADIUS Gateway translates the failed response into the Access-Reject message and returns it to the RADIUS client.
If a match for the user name is found, RADIUS Gateway sends a query with the User-Password AVP value in the request to the ECE server to validate the user password.
The ECE server returns a password. If the password is encrypted, RADIUS Gateway decrypts the password using a data key loaded from BRM before validating the user password. The data key to be used is identified using the key ID in the password returned by the ECE server.
If the user password in the ECE server matches the User-Password AVP value in the query, the ECE server returns a success response. RADIUS Gateway translates the success response into the Access-Accept message and returns it to the RADIUS client.
If the user password does not match, the ECE server returns a failed response. RADIUS Gateway translates the failed response into the Access-Reject message and returns it to the RADIUS client.

Sample Access-Request Request for PAP Authentication

 Code: Access-Request(1)
  Identifier: 0
  Length: 120
  Authenticator: 0x7D564C041FD183A4DBA037E03E3244F3
  User-Name: alias#1006
  User-Password: 0x41FD183A4335037E03E3244F3123123
  NAS-IP-Address: 128.1.2.3
  NAS-Port-Type: 1034
  Service-Type: 2

Authenticating Access Requests by Using CHAP

You use CHAP to authenticate access requests by validating the identity of the RADIUS client using Access-Challenge messages. The CHAP authentication is performed based on the CHAP-Password and CHAP-Challenge AVP values in the Access-Request request. RADIUS Gateway uses the State AVP value in the Access-Request request or the noOfChallenges value that you configured in ECE to carry out the number of Access-Challenge messages for a given authentication session.

At any time in a given authentication session, RADIUS Gateway can also request the RADIUS client to send an Access-Challenge message. The CHAP authentication uses encrypted passwords for authentication and the Access-Challenge message can be requested for authentication by RADIUS Gateway at any time. Therefore, the CHAP authentication process is considered more secure than the PAP authentication process.

The CHAP authentication process is as follows:

The RADIUS client encrypts a clear-text user password by using the CHAP identifier and CHAP-Challenge AVP value and sends it in the CHAP-Password AVP in an Access-Request request.
RADIUS Gateway authenticates the RADIUS client using the sharedsecret password that you provided during installation.

Note:

If RADIUS clients are represented by using an IP address range, ensure that all the RADIUS clients within the IP address range use the same sharedsecret password.
RADIUS Gateway translates the Access-Request request into an ECE query.
RADIUS Gateway sends the query with the User-Name AVP value to the ECE server to validate the user name.
If the user name is not found in the ECE server, the ECE server returns a failed response. RADIUS Gateway translates the failed response into the Access-Reject message and returns it to the RADIUS client.
If a match for the user name is found, the ECE server returns the password associated with the user name. If the password is encrypted, RADIUS Gateway decrypts the password into a clear-text password using the data key loaded from BRM before validating the password. The data key to be used is identified using the key ID in the password returned by the ECE server.
RADIUS Gateway generates an MD5 hash value using the password, CHAP-Challenge AVP, and CHAP identifier (which is the first byte of the CHAP-Password AVP), and compares it with the CHAP-Password AVP value in the Access-Request request.
If the values do not match, RADIUS Gateway returns a failed response. RADIUS Gateway returns an Access-Reject message to the RADIUS client.
If the MD5 hash value and the CHAP-Password AVP value match, RADIUS Gateway returns a success response.
RADIUS Gateway sends an Access-Challenge message to the RADIUS client.

RADIUS Gateway uses the State AVP value in the Access-Request request to determine the number of Access-Challenge messages to be sent to the RADIUS client. For example, if the State AVP value is 0, RADIUS Gateway directly returns the Access-Accept message. If the State AVP value is 1, RADIUS Gateway sends only one Access-Challenge message to the RADIUS client.
If the State AVP value is null or if the value is not set, RADIUS Gateway calculates a random number between one and the maximum number of challenges configured in ECE and sends the Access-Challenge messages to the RADIUS client.
The RADIUS client responds with a value calculated through the MD5 hash function.
RADIUS Gateway checks the response against its calculation of the expected hash value.
If the values match, RADIUS Gateway repeats the Access-Challenge messages based on the State AVP value or the number calculated by RADIUS Gateway.
If the values do not match, RADIUS Gateway returns an Access-Reject message to the RADIUS client.

Sample Access-Request Request for CHAP Authentication

 Code: Access-Request(1)
  Identifier: 0
  Length: 144
  Authenticator: 0x7D564C041FD183A4DBA037E03E3244F3
  CHAP-Password: 0x423423432412ADA123CC1123124123
  Chap-Challenge="0xFBFCE5676F94433682718EF97F8AB24900"
  NAS-IP-Address: 127.0.0.8
  State: 0
  NAS-Port-Type: 1816
  Service-Type: 2

Authenticating Access Requests by Using EAP

You use EAP to authenticate users using different authentication mechanisms. EAP includes password-based authentication methods and secure certificate-based authentication methods. The EAP authentication is performed based on the EAP-Message AVP value in the Access-Request request. RADIUS Gateway supports the following EAP authentication methods:

EAP-Tunneled Transport Layer Security (TTLS). Authentication between RADIUS Gateway and the RADIUS client uses a secured connection in two phases. In the first phase, RADIUS Gateway and the RADIUS client exchange authentication certificates for establishing the secured connection. In the second phase, RADIUS Gateway authenticates the RADIUS client by using different authentication mechanisms, such as EAP-PAP, EAP-CHAP, and EAP-MD5. These authentication mechanisms use the attributes in the Access-Request request to perform the authentication. You can also configure a custom EAP authentication mechanism by using the RADIUS Gateway extension points.
EAP-Non-TTLS. Authentication between RADIUS Gateway and the RADIUS client uses a configured list of EAP authentication mechanisms. The EAP-Non-TTLS authentication process is as follows:
1. RADIUS Gateway performs a standard check on the Access-Request request received from the RADIUS client.
2. RADIUS Gateway sends the EAP-Type AVP in the Access-Challenge message that contains the value corresponding to the first EAP type configured.
3. If the RADIUS client returns NAK, RADIUS Gateway sends the next EAP type in the configured list in the Access-Challenge message. RADIUS Gateway continues this process until the RADIUS client responds with an Access-Accept message or until the end of the configured list is reached. In that case, RADIUS Gateway sends an Access-Reject message.
RADIUS Gateway, by default, supports only the EAP-MD5 authentication mechanism in the EAP-Non-TTLS method. To use a different authentication method, use the CustomAuth and CustomEAPChallenge extension points. The CustomEAPChallenge extension point sends the initial EAP challenge to the RADIUS client. The CustomAuth extension point performs the authentication and returns the authentication result. Based on the result received, RADIUS Gateway sends the appropriate RADIUS response to the RADIUS client.

Sample Access-Request Request for EAP-MD5 Authentication

 Code: Access-Request(1)
  Identifier: 0
  Length: 120
  Authenticator: 0x7D564C041FD183A4DBA037E03E3244F3
  User-Name: BOB
  NAS-IP-Address: 127.0.0.1
  Calling-Station-Id: 02-00-00-00-00-01
  Framed-MTU: 1400
  NAS-Port-Type: 19
  Connect-Info: CONNECT 11Mbps 802.11b
  Service-Type: 2
  EAP-Message: 0x0200000801424F42
  Message-Authenticator: 0x4FB1186DDA9643CED0CD13D59ECD9D4E

Loading Data Keys Extracted from BRM into ECE

As part of the initial load of customer data into ECE, Customer Updater loads data keys into ECE. When RADIUS Gateway is started, the data keys are decrypted using the BRM root key in the Oracle wallet file and stored in the memory with a data key ID for each data key. These data keys are used for decrypting the passwords in authentication responses from ECE.

When you add or modify a data key in BRM, you must load the newly added or modified data key extracted from BRM into ECE.

To load data keys extracted from BRM into ECE:

Access the ECE configuration MBeans in a JMX editor, such as JConsole. See "Accessing ECE Configuration MBeans".
Expand the UpdateEventhandler node.
Expand Update.
Expand Operations.
Select updateDataKeys.
Click the updateDataKeys button.

The newly added or modified data keys extracted from BRM are loaded into ECE.

Customizing the RADIUS Data Dictionary

This section covers customizing the RADIUS data dictionary.

About the RADIUS Data Dictionary

The data dictionary includes a list of AVPs that are used by RADIUS Gateway to perform authentication and accounting operations. The RADIUS data dictionary contains the standard AVPs that are prescribed in RADIUS Request for Comments (RFC) 2865, 2866, and 2869, and also some sample vendor-specific attributes. You can use the sample vendor-specific attributes as a template for adding custom vendor-specific attributes. The default location of the RADIUS data dictionary file is ECE_home/config/radius/radiusDictionary.xml.

Note:

Do not remove, rename, or move the RADIUS data dictionary file to a different location.

Creating a Custom Data Dictionary

You can create a custom data dictionary file by using the ECE_home/config/radius/radiusDictionary.xml file as a template. The default location for your custom data dictionary file is ECE_home/config/radius/custom/dictionary_file, where dictionary_file is the name of your custom data dictionary file. You can add new vendor-specific attributes to your custom data dictionary file. See "Adding Custom Vendor-Specific Attributes".

Selecting a RADIUS Data Dictionary When Using Different NAS Vendors

If you must use NAS servers from multiple vendors, you have the following options:

If your NAS is RFC 2865 compliant, you can use the RFC2865 data dictionary. This is the preferred solution. Update the dictionary file with any vendor-specific attributes associated with the NAS.
If your NAS is not RFC 2865 compliant, you can use the RADIUS data dictionary files for adding vendor-specific attributes. See "Adding Custom Vendor-Specific Attributes" for more information.

Adding Custom Vendor-Specific Attributes

In special cases, where you are using NAS servers from multiple vendors, you must add the vendor attribute and code in your custom data dictionary file.

The syntax for adding a vendor-specific attribute is:

<?xml version="1.0" encoding="UTF-8"?>
    <dictionary schemaLocation= "radiusDictionary.xsd"
       <vendor value="vendor_ID"name="vendor_name"/>
       </attribute name="attribute_name" vendor="vendor_name" syntax="data_type" code="attribute_ID"/>
     /dictionary>

Table 20-1 lists the vendor-specific attribute values and descriptions.

Table 20-1 Vendor-specific Attribute Values

Parameters	Description
vendor_ID	Number used to identify the NAS or gateway vendor. These numbers are assigned by the Internet Advisory Board (IAB). See your vendor's documentation for details. Some common vendor identification numbers are: 9 (Cisco) 10415 (3GPP) 2636 (Juniper)
vendor_name	Name of the vendor.
attribute_name	Name of the attribute. This must be unique. Important: Do not use the same attribute name as used in the default RADIUS data dictionary file. Using the same attribute name in the custom data dictionary file overrides the attribute values in the default RADIUS data dictionary file.
attribute_ID	Identification number assigned to the attribute in the dictionary.
data_type	Any one of the following data types: UnsignedInt 32-bit unsigned value in big endian order (high byte first). Integer 32-bit value in big endian order (high octet first). String 0-253 octets Ipaddr 4 octets in network octet order Binary 0-254 octets Password (n * 16) (>= 16) octets. This field is encrypted according to the User-Password AVP in RFC 2865. Short 16-bit value Octet 8-bit value ifid IPv6 interface ID ipv6addr IPv6 address date UNIX timestamp in seconds (since January 1, 1970 GMT)

Loading the RADIUS Mediation Specification Data

RADIUS Gateway uses the RADIUS mediation specification data to determine which product and event type combination and network mapping applies to an incoming request from the RADIUS client.

To load the RADIUS mediation specification data:

Create a mediation specification file or open the sample RADIUS mediation specification file.

A sample mediation specification file (ECE_home/sample_data/config_data/specifications/ece_simple) is available.

Note:

Create only one RADIUS mediation specification file to represent the mediation specification for RADIUS Gateway.
Load the pricing data from PDC into ECE.

For every event definition, which contains charging operation types (for example, Initiate) loaded into ECE from PDC, ECE generates network mapping files.
Add a row (in the table) for each new product to be rated that specifies the following information:
- Service-Identifier AVP
  
  A unique identifier of the service. The Service-Identifier AVP value is sent by the RADIUS request. “null" is valid if the field is not expected to be present in the request.
- ProductType
  
  The product type that you have defined for the event in its associated request specification.
- EventType
  
  The event type that you have defined for the event in its associated request specification.
- Version
  
  The version number of the request specification that you want to apply to the event.
- ValidFrom
  
  A future date and time when you want RADIUS Gateway to recognize a newly deployed request specification.
  
  To have requests processed according to a new specification, you would enter:
  
  yyyy-mm-ddThh:mm:ss [timezone]
  
  If timezone is not specified, it defaults to UTC.
- Network-Mapping-FileName
  
  The name of the network mapping file generated for the product and event combination.
Open the ECE_home/config/management/migration-configuration.xml file.
Search the configObjectsDataDirectory parameter and copy the value. For example:
```
configObjectsDataDirectory = ECE_home/sample_data/config_data
```
Save the mediation specification file to that same directory.
Load the file into the ECE server by running the following command:
```
start configLoader
```
The utility loads the RADIUS mediation specification data to the ECE cluster. The configLoader utility uses the location in the configdata parameter for loading the data. As mediation specification files have same names, so any existing RADIUS mediation specification data in the ECE cluster is overwritten.

Example 20-1 Sample RADIUS Mediation Specification Entry

RadiusMediationTable {
Service-Identifier| ProductType | EventType | Version |  ValidFrom |  Network-Mapping-FileName|
 "1" | "TelcoGprs" | "EventDelayedSessionTelcoGprs" | 2.0 | "2010-12-31T12:01:01 PST" | "EventDelayedSessionTelcoGprs_TelcoGprs.xml" |
}

When you load the RADIUS mediation specification data into the ECE cluster, RADIUS Gateway re-creates its in-memory usage-request builder map and uses the mapping definitions to send requests to ECE.

About Mapping RADIUS Network Attributes to Event Attributes

To process requests from RADIUS clients, you map network attributes from RADIUS clients to the corresponding event attributes in ECE. You do this by editing the network mapping file. When you load the pricing data from PDC into ECE, ECE generates the network mapping file for each product and event combination. Some default network mappings are already pre-configured in the files generated by ECE. You can update the default values in these files.

RADIUS Gateway uses this mapping in ECE to process requests by dynamically mapping the values of the network attributes in the RADIUS request to the corresponding event attributes in ECE.

Mapping RADIUS Network Attributes to Event Attributes

If you add or remove an event attribute from the event definition in PDC, you have to add or remove the corresponding network attributes in ECE. You do this by editing the network mapping file in ECE.

Before you map the attributes, load the RADIUS mediation specification file. See "Loading the RADIUS Mediation Specification Data" for more information.

To map network attributes to event attributes:

Load the pricing data from PDC into ECE.

Mapping files will be automatically generated when the pricing data is published from PDC to ECE.

For every event definition, which contains charging operation types (for example, Initiate) loaded into ECE from PDC, ECE generates the network mapping files. The network mapping files are stored in the directory specified by the configObjectsDataDirectory parameter in the ECE_home/config/management/migration-configuration.xml file

A sample network mapping file is available in the (ECE_home/sample_data/config_data/specifications/ece_end2end/network_mapping) directory. You can use this as a reference for mapping the attributes.
Open a network mapping file in a text editor.
Ensure that the ORIGIN_NETWORK event attribute is added as a top-level attribute in the network mapping file.
Map the network attributes to the event attributes by doing the following:
1. Search for the event attribute that you want to map to the network attribute.
2. Add the following entry:
```
<networkField>NetworkAttribute</networkField>
```
  where NetworkAttribute is the attribute of the requests received from RADIUS clients.
  
  For example:
```
<attributeMapping type="RadiusMediationEntries">
     <attribute>
       <name>TERMINATE_CAUSE</name>
       <networkField>Acct-Terminate-Cause</networkField>
     </attribute>
   </attributeMapping>
```
Save and close the file.

Note:

Verify that the name of this network mapping file is specified in the RADIUS mediation specification file.
Load the network mapping data by doing one of the following:
- If RADIUS Gateway is running, run the following command:
```
start configLoader loadNetworkMapping
```
- If RADIUS Gateway is not running, run the following commands:
```
start customerUpdater
start radiusGateway
```
  The network mapping data is loaded into the ECE cluster. Any existing network mapping data available for the product and event specification in the ECE cluster is overwritten. ECE is now in a usage-processing state, where it can accept requests from RADIUS Gateway.

When you load the network mapping into the ECE cluster, RADIUS Gateway re-creates its in-memory usage-request builder map and begins using the latest mapping definitions to send requests to ECE.

About RADIUS Gateway Accounting

RADIUS Gateway processes the accounting requests to track information about customer usage. For example, RADIUS Gateway tracks when customers log in to a network for using the services and when customers log out of the network. The information tracked by RADIUS Gateway is used for statistical purposes, network monitoring, and billing the customers based on the duration of the sessions or the type of services used.

To track customer usage information, RADIUS Gateway uses the network mapping definitions in ECE and maps the accounting requests received from the RADIUS clients to the usage requests with the corresponding operation types configured in ECE.

See the following topics for information on the different types of accounting requests received from the RADIUS clients:

The RADIUS Gateway accounting process is as follows:

At the start of accounting or the start of a user session, the RADIUS client sends an accounting request to RADIUS Gateway. The Acct-Status-Type AVP value in the request indicates the start of accounting or start of a session for the user.
RADIUS Gateway processes the request and records the information as either an accounting-on record or an accounting-start record in ECE, based on the accounting request received.
RADIUS Gateway returns an Accounting-Response message to the RADIUS client to acknowledge the accounting-start or accounting-on request.
While the session is active, the RADIUS client sends periodic updates on the data usage to RADIUS Gateway through accounting requests with the Acct-Status-Type AVP set to Interim-Update.
RADIUS Gateway processes the requests and records the information as accounting-interim-update records in ECE.
RADIUS Gateway returns Accounting-Response messages to the RADIUS client to acknowledge the interim-update requests.
At the end of accounting or the end of the user session, the RADIUS client sends an accounting request that contains the Acct-Status-Type AVP value indicating the end of accounting or the end of the user session.
RADIUS Gateway processes the request and records the information as either an accounting-off record or an accounting-stop record in ECE, based on the accounting request received.
RADIUS Gateway returns an Accounting-Response message to the RADIUS client to acknowledge the accounting-off or accounting-stop request. At any time, if the RADIUS client does not receive an Accounting-Response message, it continues to send accounting requests until it receives a response.

About Accounting-Start and Accounting-Stop Requests

When a client is configured to use RADIUS accounting, the RADIUS client sends an Accounting-Start request, which specifies the start of a session for delivering a service, and an Accounting-Stop request, which specifies the end of the session that was started for delivering a service, to RADIUS Gateway. The Accounting-Start request describes the type of service being delivered and the user who is using that service. The Accounting-Stop request describes the type of service that was delivered. The Accounting-Stop request might also contain statistics, such as elapsed time, input and output octets, or input and output messages. The RADIUS client uses the Acct-Status-Type AVP to specify the start of a session and to specify the end of a session.

The following AVPs must be present in an Accounting-Start or Accounting-Stop request:

Acct-Session-Id

Note:

The Accounting-Start and Accounting-Stop requests for a given session must have the same Acct-Session-Id AVP.
Acct-Status-Type
NAS-IP-Address or NAS-Identifier
User-Name
The AVP that you configured to derive the service in ECE by using the avpName and vendorId parameters.

For an Accounting-Start request, the Acct-Status-Type AVP must be set to 1. When a RADIUS client sends the Accounting-Start request, the RADIUS client indicates that the user service session has started. When RADIUS Gateway receives the Accounting-Start request, RADIUS Gateway records the information contained in the request for billing purpose and returns the Accounting-Response message to the RADIUS client.

For an Accounting-Stop request, the Acct-Status-Type AVP must be set to 2. When a RADIUS client sends the Accounting-Stop request, the RADIUS client indicates that the user service session has ended. When RADIUS Gateway receives the Accounting-Stop request, RADIUS Gateway records the information contained in the request for billing purposes and returns the Accounting-Response message to the RADIUS client.

The RADIUS client continues to send the Accounting-Start or Accounting-Stop requests until it receives the Accounting-Response message.

Sample Accounting-Start Request for Accounting

[Code: Accounting-Request(4)
 Identifier: 0
 Length: 94
 Authenticator: 0x30303030303030303030303030303030
 Acct-Session-Id: 123456
 Acct-Status-Type: 1
 NAS-Identifier: telco.org
 User-Name: alias#5000
 Service-Type: 1]
Radius Response Packet 
[Code: Accounting-Response(5)
 Identifier: 0
 Length: 20
 Authenticator: 0x00000000000000000000000000000000]

Sample Accounting-Stop Request for Accounting

[Code: Accounting-Request(4)
 Identifier: 1
 Length: 87
 Authenticator: 0x30303030303030303030303030303030
 Acct-Session-Id: 123456
 Acct-Status-Type: 2
 Acct-Input-Octets: 10	
 Acct-Output-Octets: 18
 Acct-Session-Time: 200
 NAS-Identifier: telco.org
 User-Name: alias#5000
 Service-Type: 1]
Radius Response Packet
[Code: Accounting-Response(5)
 Identifier: 1
 Length: 20
 Authenticator: 0x00000000000000000000000000000000]

About Accounting-On and Accounting-Off Requests

When a client is configured to use RADIUS accounting, the RADIUS client sends an Accounting-On request, which specifies the start of accounting, and an Accounting-Off request, which specifies the end of accounting, to RADIUS Gateway. The RADIUS client uses the Acct-Status-Type AVP to specify the start of accounting and to specify the end of accounting.

The following AVPs must be present in an Accounting-On or Accounting-Off request:

Acct-Status-Type
NAS-IP-Address or NAS-Identifier
The AVP that you configured to derive the service in ECE by using the avpName and vendorId parameters.

For an Accounting-On request, the Acct-Status-Type AVP must be set to 7. When a RADIUS client sends the Accounting-On request, the RADIUS client indicates that it is ready for service. When RADIUS Gateway receives the Accounting-On request, RADIUS Gateway closes or terminates any open accounting session associated with that RADIUS client before the RADIUS client indicated it was ready for service.

For an Accounting-Off request, the Acct-Status-Type AVP must be set to 8. When a RADIUS client sends the Accounting-Off request, the RADIUS client indicates that it is going out of service. When RADIUS Gateway receives the Accounting-Off request, RADIUS Gateway closes or terminates all the open accounting sessions associated with that RADIUS client.

Sample Accounting-On Request for Accounting

[Code: Accounting-Request(4)
 Identifier: 4
 Length: 68
 Authenticator: 0x30303030303030303030303030303030
 Acct-Session-Id: 131
 Acct-Status-Type: 7
 NAS-Identifier: telco.org
 User-Name: alias#5000
 Service-Type: 1
[Code: Accounting-Response(5)
 Identifier: 4
 Length: 20
 Authenticator: 0x00000000000000000000000000000000]

Sample Accounting-Off Request for Accounting

[Code: Accounting-Request(4)
 Identifier: 5
 Length: 68
 Authenticator: 0x30303030303030303030303030303030
 Acct-Session-Id: 131
 Acct-Status-Type: 8
 NAS-Identifier: telco.org
 User-Name: alias#5000
 Service-Type: 1
Radius Response Packet
[Code: Accounting-Response(5)
 Identifier: 5
 Length: 20
 Authenticator: 0x00000000000000000000000000000000]

About Accounting-Interim-Update Requests

During a session, the RADIUS client periodically sends Accounting-Interim-Update requests, which specify the current session duration and current data usage, to RADIUS Gateway. The RADIUS client uses the Acct-Status-Type AVP to specify the interim update.

The following AVPs must be present in an Accounting-Interim-Update request:

Acct-Session-Id

Note:

The Accounting-Interim-Update requests for a given session must have the same Acct-Session-Id AVP.
Acct-Status-Type
NAS-IP-Address or NAS-Identifier
User-Name
The AVP that you configured to derive the service in ECE by using the avpName and vendorId parameters.

When periodic Accounting-Interim-Update requests are sent for the same active session, the identifier in each Accounting-Interim-Update request must be unique. If the identifier is the same, RADIUS Gateway considers only the first request received with that identifier and ignores other requests.

For an Accounting-Interim-Update request, the Acct-Status-Type AVP must be set to 3. When a RADIUS client sends the Accounting-Interim-Update request, the RADIUS client indicates that the session is active. When RADIUS Gateway receives the Accounting-Interim-Update request, RADIUS Gateway records the information contained in the request for billing purposes and returns the Accounting-Response message to the RADIUS client.

The RADIUS client continues to send Accounting-Interim-Update requests until it receives the Accounting-Response message.

Sample Accounting-Interim-Update Request for Accounting

[Code: Accounting-Request(4)
 Identifier: 0
 Length: 95
 Authenticator: 0x30303030303030303030303030303030
 Acct-Session-Id: 123456
 Acct-Status-Type: 3
 Acct-Input-Octets: 6
 Acct-Output-Octets: 10
 NAS-Identifier: telco.org
 User-Name: alias#5000
 Service-Type: 1]
Radius Response Packet
[Code: Accounting-Response(5)
 Identifier: 0
 Length: 20
 Authenticator:0x00000000000000000000000000000000]