6.2.1 Actors

The actors for this application include the Diameter application that is using the base Accounting‐Request and Accounting‐Answer commands in addition to its own Diameter application commands for authentication and authorization. We will call this application a Network Access Server (NAS). The other actors include the accounting application client and the accounting application server.

6.2.2 Accounting Application Setup

Typically a successful transaction with the NAS starts the accounting application. The accounting application server selects how often the accounting application client should send accounting records based on provisioned information about the user and any relationships with roaming partners (if the accounting application is deployed in a mobile network), and communicates this mode to the client via the Acct‐Interim‐Interval and Accounting‐Realtime‐Required AVPs in its main application response.

• Acct‐Interim‐Interval: The inclusion of this AVP (type Unsigned32) instructs the client to send snapshots of usage during a user's session, known as an interim record. Interim records provide a partial accounting of a user's session in case a device or network problem prevents the delivery of a session summary message or session record.
  • The omission of this AVP or its inclusion with its value field set to 0 means that the client should produce only event records, start records, and stop records.
  • The inclusion of the AVP with its value field set to a non‐zero value means that the client produces interim records between the start record and the stop record. The value field of this AVP specifies the interval in seconds between the sending of these records. The client starts a timer when it sends a start record, sends the first interim record roughly when this interval time elapses, and continues to send interim records at timed intervals until the session ends, at which point the client sends a stop record. The client randomizes the production times of interim records to avoid creating message storms around a common service start time.
• Accounting‐Realtime‐Required: This AVP provides guidance to the client on what the client should do when its transfer of accounting records is delayed or unsuccessful. Real‐time accounting is the processing of information on resource usage within a defined time window in order to limit financial risk.
  • 1 DELIVER_AND_GRANT: The service is granted only when there is a connection to an accounting server or to a set of accounting servers.
  • 2 GRANT_AND_STORE: Service is granted when there is a connection or for as long as the client can store records. This is the default behavior if the Accounting‐Realtime‐Required AVP is not included.
  • 3 GRANT_AND_LOSE: Service will be granted even if the records cannot be delivered or stored.

  Note that the Accounting‐Realtime‐Required AVP doesn't indicate whether the accounting data is actually sent to the server in real time. The Diameter Credit‐Control Application (Section 6.3 ) and the 3GPP Rf interface (Section 6.2.10) are examples of real‐time accounting applications.

When the client receives a successful authentication and/or authorization message from the Diameter server, it starts collecting accounting information for the session according to the server's directives.

Depending on which accounting service, described in the next section, is used by the Diameter application, the client sends accounting information either to the main application server or to a centralized accounting server. The client transmits accounting records to the server via the Accounting‐Request message. The server acknowledges with the Accounting‐Answer message.

If the client interacts with an accounting server directly after successful authorization, then that accounting server can override directives given previously by the main application server by including the Acct‐Interim‐Interval or Accounting‐Realtime‐Required AVP in the Accounting‐Answer message. The client always uses the latest values received.

6.2.3 Accounting Services

Diameter applications that want to incorporate the base accounting commands can route them in one of the following ways:

• Split Accounting Service

  The Accounting‐Request and Accounting‐Answer commands carry the Application‐Id of 3, which is the Application‐Id of the Diameter base accounting application, and they can be routed to Diameter nodes other than the server that handles the main Diameter application, such as centralized accounting servers (Figure 6.1). Since the Application‐Id doesn't provide information about the specific Diameter application that is sending the commands, the accounting server needs to inspect the message's other AVPs or their content to correlate messages.¹

  

  Because of this overhead, if you are creating a new Diameter application that requires an accounting component (designing new applications is covered in Chapter 7), the split accounting service is not recommended.

  Examples of applications that use split accounting services are the Diameter Extensible Authentication Protocol (EAP) Application (Section 6.5 ) and the 3GPP Rf interface (Section 6.2.10 ).

• Coupled Accounting Service

  The Accounting‐Request and Accounting‐Answer commands carry the Application‐Id of the Diameter application that is using it. The accounting messages are routed the same way as the other Diameter application messages and thus go to the authorization server (Figure 6.2). The authorization server then either processes the accounting records itself or forwards them to an accounting server.

  

  When creating new Diameter applications that have an accounting component, the best current practice is to use the coupled accounting service.

  Examples of applications that use a coupled accounting service are the Diameter Network Access Server Application 2 and the Diameter Mobile IPv4 Application 3.

6.2.4 Accounting Records

Accounting records, which summarize the user's resource consumption, vary by the type of accounted service and the authorization server's directions. The client sends the accounting record in an Accounting‐Request, where the details are captured in the service‐specific AVPs.

If the accounted service is a one‐time event, meaning that the start and stop of the event are simultaneous, then the client sets the Accounting‐Record‐Type AVP to EVENT_RECORD in the Accounting‐Request.

If the accounted service session continues for some length of time, then the client sets the Accounting‐Record‐Type AVP to the value START_RECORD in the initial Accounting‐Request for a session. When the client sends the last Accounting‐Request, it sets the Accounting‐Record‐Type AVP value to STOP_RECORD. If the authorization server has enabled interim accounting, then the client sends additional records between the START_RECORD and STOP_RECORD, marked INTERIM_RECORD.

A session sequence then is either one record with Accounting‐Record‐Type AVP set to the value EVENT_RECORD or several records starting with START_RECORD, followed by zero or more INTERIM_RECORDs and a single STOP_RECORD. Since a session can have more than one accounting sequence, the Accounting‐Sub‐Session‐Id is used to identify a particular sequence.

6.2.5 Correlation of Accounting Records

A Diameter application defines the concept of a session that is being accounted, and it may define the concept of a multi‐session. For instance, the Diameter Network Access Server Application 2 treats a single point‐to‐point (PPP) connection 4 to an NAS as one session and a set of multilink PPP sessions as one multi‐session.

An application can correlate accounting records within a session by using the Session‐Id AVP found in the messages. If the accounting messages use a different Session‐Id than the application sessions, then other session‐related information is needed to perform correlation.

When an application requires multiple accounting sub‐sessions, then each sub‐session is differentiated by an Accounting‐Sub‐Session‐Id AVP. The Session‐Id remains constant for all sub‐sessions and is used to correlate all the sub‐sessions to a particular application session.

There are cases where an application needs to correlate multiple application sessions into a single accounting record; the accounting record may span multiple Diameter applications and sessions used by the same user at a given time. When the main application server determines that a request belongs to an existing session, it sends the Acct‐Multi‐Session‐Id AVP during the authorization phase. The client then includes the Acct‐Multi‐Session‐Id AVP in all subsequent accounting messages. The contents of Acct‐Multi‐Session‐Id AVP are implementation specific, but are globally unique and do not change during the life of a session.

When the split accounting service is used, a centralized Diameter accounting server will need to sort messages from different applications; however, the Accounting‐Request messages all use the same Application‐Id of 3. The accounting server will need to look for application‐specific AVPs in order to determine to which application the message applies.

6.2.6 Sending Accounting Information

The client sends an Accounting‐Request (Figure 6.3) command to provide accounting information to the main application server or to an accounting server. In addition to the AVPs covered below, Accounting‐Request messages usually include service‐specific accounting AVPs.

       <ACR> ::= < Diameter Header: 271, REQ, PXY >           < Session-Id >           { Origin-Host }           { Origin-Realm }           { Destination-Realm }           { Accounting-Record-Type }           { Accounting-Record-Number }           [ Acct-Application-Id ]           [ Vendor-Specific-Application-Id ]           [ User-Name ]           [ Destination-Host ]           [ Accounting-Sub-Session-Id ]           [ Acct-Session-Id ]           [ Acct-Multi-Session-Id ]           [ Acct-Interim-Interval ]           [ Accounting-Realtime-Required ]           [ Origin-State-Id ]           [ Event-Timestamp ]          * [ Proxy-Info ]          * [ Route-Record ]          * [ AVP ] 

By issuing an Accounting‐Request corresponding to the authorization response, the client or the local realm implicitly agrees to provide the service indicated in the authorization response. If the local realm cannot provide the service, it sends a DIAMETER_UNABLE_TO_COMPLY error message within the Accounting‐Request.

The server acknowledges an Accounting‐Request command with an Accounting‐Answer command (Figure 6.4). The Accounting‐Answer command contains the same Session‐Id as the corresponding request.

       <ACA> ::= < Diameter Header: 271, PXY >           < Session-Id >           { Result-Code }           { Origin-Host }           { Origin-Realm }           { Accounting-Record-Type }           { Accounting-Record-Number }           [ Acct-Application-Id ]           [ Vendor-Specific-Application-Id ]           [ User-Name ]           [ Accounting-Sub-Session-Id ]           [ Acct-Session-Id ]           [ Acct-Multi-Session-Id ]           [ Error-Message ]           [ Error-Reporting-Host ]           [ Failed-AVP ]           [ Acct-Interim-Interval ]                  [ Accounting-Realtime-Required ]                     [ Origin-State-Id ]                     [ Event-Timestamp ]                   * [ Proxy-Info ]                   * [ AVP ] 

In addition to the AVPs listed in RFC 6733, Accounting‐Answer messages usually include service‐specific accounting AVPs.

6.2.7 Accounting AVPs

This section describes the AVPs that carry accounting usage information related to a specific session.

• Accounting‐Record‐Type: Identifies the type of accounting record:
  • 1 EVENT_RECORD: This record contains all information relevant to the service, and it is the only record of the service.
  • 2 START_RECORD: Initiates an accounting session and contains accounting information that is applicable to the start of the session.
  • 3 INTERIM_RECORD: Contains cumulative accounting information for an existing session. Interim Accounting Records are sent every time a re‐authentication or re‐authorization occurs or when triggered by application‐specific events. The use of interim records is determined by the Acct‐Interim‐Interval AVP.
  • 4 STOP_RECORD: Ends an accounting session and contains cumulative accounting information relevant to the existing session. When a service uses the accounting portion of the Diameter protocol, even in combination with an application, session termination messages are not used, since a session is terminated with an accounting stop message.
• Accounting‐Record‐Number: Identifies this record within one session. Since Session‐Id AVPs are globally unique, the combination of Session‐Id and Accounting‐Record‐Number AVPs can be used to identify a single record within a session.
• Acct‐Session‐Id: This AVP is only used when RADIUS/Diameter translation occurs. This AVP contains the contents of the RADIUS Acct‐Session‐Id attribute.
• Acct‐Multi‐Session‐Id: Links multiple, related accounting sessions, where each session has a unique Session‐Id but the same Acct‐Multi‐Session‐Id AVP. The server provides the value for this AVP, which the client includes in all accounting messages for the given session.
• Accounting‐Sub‐Session‐Id: Contains the accounting sub‐session identifier. The combination of the Session‐Id and this AVP is unique per sub‐session, and the value of this AVP is monotonically increased by one for all new sub‐sessions. If the client does not include this AVP, then there are no sub‐sessions in use, except when Accounting‐Record‐Type is set to STOP_RECORD, which signals the termination of all sub‐sessions for a given Session‐Id.

6.2.8 freeDiameter Example

Here is an example of a Split Accounting Service message exchange captured from freeDiameter:

6.2.9 Fault Resilience

If the primary server fails, clients are expected to fail over to alternate servers in order to minimize loss of accounting data. To guard against reboots, extended network failures, and server failures, the client should store accounting records in non‐volatile memory immediately after creation and until a positive Accounting‐Answer has been received from the server. The client should overwrite any previously locally stored interim accounting records to ensure that only one interim record exists for a session. Upon a reboot, the client should send stored records to the accounting server after updating the records' termination cause, session length, and other relevant information.

Diameter peers acting as agents or offline processing systems should detect duplication caused by the sending of the same record to several servers and duplication of messages in transit by inspecting the Session‐Id and Accounting‐Record‐Number AVP pairs.

6.2.10 Example: 3GPP Rf Interface for Mobile Offline Charging

A real‐world example of the Diameter base accounting application is its use in mobile networks for offline charging. Offline charging is the simultaneous collection of charging information for the use of a network resource (a voice call, data transport, or multimedia message transmission) that does not affect, in real‐time, the service rendered. That is, the future use of the resource during the session is not based on the current use, for example a customer may be billed more for exceeding the number of minutes in her call plan, but she will not be cut off.

Within 3GPP networks, one of the offline charging applications is the Rf interface 5. The Rf interface is the reference point between a 3G network element,² and more specifically a component within that network element known as a Charging Trigger Function (CTF), and the Charging Data Function (CDF), which collects the accounting data to send it to the network operator's billing domain.

The CTF acts as a Diameter client and the CDF acts as a stateless accounting server that implements the functionality of the Diameter base accounting application. With each chargeable event, the CTF creates an Accounting Request (ACR) and sends it to the CDF in real time. Chargeable events include the transmission of a multimedia message, the start of a session, like a voice call, a change in a session, for instance a change in quality of service, and the end of a session

The Rf interface handles both event‐based and session‐based accounting records. The event record is used for registration or interrogation and for successful service events (the sending of a multimedia message, for instance) triggered by a network element. In addition, event records are also used for unsuccessful session establishment attempts. The ACR record types used for accounting data related to successful sessions are start, interim, and stop. Interim events describe changes to session characteristics (e.g., tariff time switch, change of quality of service or change of session media types) or when certain limits (e.g., time or volume) are exceeded.

The CDF transfers the charging events to the network operator's billing domain via FTP.

h3

6.3.1 Credit‐Control‐Request Command

After the user has been authenticated and authorized, the Diameter credit‐control client requests credit authorization from the credit‐control server for a given service with the Credit‐Control‐Request message (Figure 6.5).

  <Credit-Control-Request> ::= < Diameter Header: 272, REQ, PXY >                              < Session-Id >                              { Origin-Host }                              { Origin-Realm }                              { Destination-Realm }                              { Auth-Application-Id }                              { Service-Context-Id }                              { CC-Request-Type }                              { CC-Request-Number }                              [ Destination-Host ]                              [ User-Name ]                              [ CC-Sub-Session-Id ]                              [ Acct-Multi-Session-Id ]                              [ Origin-State-Id ]                              [ Event-Timestamp ]                            * [ Subscription-Id ]                              [ Service-Identifier ]                              [ Termination-Cause ]                              [ Requested-Service-Unit ]                              [ Requested-Action ]                            * [ Used-Service-Unit ]                              [ Multiple-Services-Indicator ]                            * [ Multiple-Services-Credit-Control ]                            * [ Service-Parameter-Info ]                              [ CC-Correlation-Id ]                              [ User-Equipment-Info ]                            * [ Proxy-Info ]                            * [ Route-Record ]                            * [ AVP ]           

The following AVPs occur in both the Credit‐Control‐Request and Credit‐Control‐Answer messages:

• CC‐Request‐Type: Contains the reason for sending the message:
  • 1 INITIAL_REQUEST: Used to initiate a credit‐control session.³
  • 2 UPDATE_REQUEST: Sent when the allocated quota or validity time expires and re‐authorization is needed, or when service‐specific events trigger an update.
  • 3 TERMINATION_REQUEST: Sent to terminate a session.
  • 4 EVENT_REQUEST: Used when the credit‐control server does not need to maintain session state. The request contains all information relevant to the service, and is the only request of the service. The reason for the Event request is given in the Requested‐Action AVP.
• CC‐Request‐Number: Identifies the request message within one session. The combination of Session‐Id and CC‐Request‐Number, which is globally unique, can be used in matching credit‐control requests with answers.
• CC‐Sub‐Session‐Id: Contains the credit‐control sub‐session identifier. Applications that require multiple credit‐control sub‐sessions can send messages with the same Session‐Id AVP and different CC‐Sub‐Session‐Id AVPs. If there are multiple credit sub‐sessions, the sub‐sessions are closed before the main session is closed to ensure proper reporting. If this AVP is not included, then there are no sub‐sessions.
• Multiple‐Services‐Credit‐Control: Contains the AVPs related to the independent credit control of multiple services feature.

The following AVPs are specific to the Credit‐Control‐Request message:

• Service‐Context‐Id: Contains a unique identifier of the service‐specific document that applies to the request. Service‐specific documents are documents created by standards bodies, service providers, or vendors that define the AVPs that are used as input to the rating process. The format of this AVP is a token that contains an arbitrary string, plus the domain of the standards body or the FQDN of the service provider or vendor if the identifier is allocated by a private entity and no interoperability is required.
• Subscription‐Id: Identifies the end user.
• Service‐Identifier: Contains the identifier of a service. The combination of the Service‐Identifier and Service‐Context‐Id AVPs uniquely identifies the specific service.
• Requested‐Service‐Unit: Contains the number of units requested by the credit‐control client. Units can include CC‐Time and CC‐Money.
• Requested‐Action: Included when the CC‐Request‐Type AVP indicates an Event request, and contains the requested action:
  • 0 DIRECT_DEBITING: Decreases the end user's account using the information in the Requested‐Service‐Unit and/or the Service‐Identifier AVPs.
  • 1 REFUND_ACCOUNT: Increases the end user's account using the information in the Requested‐Service‐Unit and/or the Service‐Identifier AVPs.
  • 2 CHECK_BALANCE: Indicates a balance check request.
  • 4 PRICE_ENQUIRY: Indicates a price enquiry request.
• Used‐Service‐Unit: Contains the number of used units measured either from the point when the service became active or when the previous measurement ended, if interim interrogations are used.
• Multiple‐Services‐Indicator: Indicates whether the credit‐control client can handle multiple services independently within a (sub‐)session.
• Service‐Parameter‐Info: Contains service‐specific information used for price calculation or rating. The contents of this AVP are defined by the service‐specific documentation.
• CC‐Correlation‐Id: Contains information to correlate requests generated for different components of the service, for instance transport and application levels.
• User‐Equipment‐Info: Indicates the identity and capabilities of the end user's terminal.

6.3.2 Credit‐Control‐Answer Command

The credit‐control server sends a Credit‐Control‐Answer message (Figure 6.6) to the credit‐control client to acknowledge a Credit‐Control‐Request command.

  <Credit-Control-Answer> ::= < Diameter Header: 272, PXY >                             < Session-Id >                             { Result-Code }                             { Origin-Host }                             { Origin-Realm }                             { Auth-Application-Id }                             { CC-Request-Type }                             { CC-Request-Number }                             [ User-Name ]                             [ CC-Session-Failover ]                             [ CC-Sub-Session-Id ]                             [ Acct-Multi-Session-Id ]                             [ Origin-State-Id ]                             [ Event-Timestamp ]                             [ Granted-Service-Unit ]                           * [ Multiple-Services-Credit-Control ]                             [ Cost-Information]                             [ Final-Unit-Indication ]                             [ Check-Balance-Result ]                             [ Credit-Control-Failure-Handling ]                             [ Direct-Debiting-Failure-Handling ]                             [ Validity-Time]                           * [ Redirect-Host]                             [ Redirect-Host-Usage ]                             [ Redirect-Max-Cache-Time ]                           * [ Proxy-Info ]                           * [ Route-Record ]                           * [ Failed-AVP ]                           * [ AVP ]         

The following AVPs are specific to the Credit‐Control‐Answer message:

• CC‐Session‐Failover: Indicates whether the client can move the credit‐control message stream of an ongoing session to a backup server during a communication failure.
• Granted‐Service‐Unit: Contains the number of service units that the credit‐control client can provide to the end user until the client must send another Credit‐Control‐Request.
• Cost‐Information: Contains cost information of a service, such as an estimate in the case of price enquiry or accumulated cost estimation in the case of a session, that the credit‐control client can then provide to the end user.
• Final‐Unit‐Indication: Indicates that the Granted‐Service‐Unit AVP contains the final units for the service. When these units have been exhausted, the credit‐control client performs the action indicated in the Final‐Unit‐Action AVP given in this AVP:
  • 0 TERMINATE: The credit‐control client must terminate the service session.
  • 1 REDIRECT: The user must be redirected, using protocols other than Diameter, to the address specified in the Redirect‐Server‐Address AVP. This can be a web page that allows the user to refresh his account balance, for instance.
  • 2 RESTRICT_ACCESS: The access device must restrict the user access according to the IP packet filters defined in the Restriction‐Filter‐Rule AVP or or the Filter‐Id AVP. Packets that do not match the filters are to be dropped.
• Check‐Balance‐Result: Contains the result of the balance check.
• Credit‐Control‐Failure‐Handling: The credit‐control client uses information in this AVP to decide what to do if sending messages to the credit‐control server has been interrupted due to network issues:
  • 0 TERMINATE: The credit‐control client can only grant the service as long as it has a connection to the credit‐control server. If the client does not receive a Credit‐Control‐Answer message within the Tx timer, then it terminates the end user's service session. This is the default behavior if the AVP is not included.
  • 1 CONTINUE: The credit‐control client should resend the request to a backup server if one exists. The client should continue to grant the service even if its credit‐control messages are not delivered.
  • 2 RETRY_AND_TERMINATE: The credit‐control client should resend the request to a backup server if one is available. The client should terminate the service if its credit‐control messages cannot be delivered.
• Direct‐Debiting‐Failure‐Handling: The credit‐control client uses information in this AVP to decide what to do if sending direct‐debiting messages to the credit‐control server has been interrupted due to network issues:
  • 0 TERMINATE_OR_BUFFER: The credit‐control client grants the service as long as there is a connection to the credit‐control server. If the client does not receive a Credit‐Control‐Answer message within the Tx timer, then the client terminates the service if it can determine from the failed answer that units have not been debited. Otherwise the client grants the service and tries to re‐send the request. This is the default behavior if the AVP is not included.
  • 1 CONTINUE: The client should continue to grant the service even if its credit‐control messages are not delivered.
• Validity‐Time: Contains the validity time of the granted service units. The credit‐control client starts to measure the the validity time when it receives the Credit‐Control‐Answer. If the granted service units have not been consumed within the specified validity time, the credit‐control client sends a Credit‐Control‐Request with CC‐Request‐Type set to UPDATE_REQUEST.

6.3.3 Failure Handling

To ensure that the end user's account is not debited or credited multiple times for the same service event, only one place in the credit‐control system should perform duplicate detection.

As covered in Section 6.3.2, the credit‐control server provides guidance to the credit‐control client on how to handle communication interruptions with two optional AVPs:

• Credit‐Control‐Failure‐Handling
• Direct‐Debiting‐Failure‐Handling

If the Credit‐Control‐Answer does not contain the above AVPs, then the credit‐control client grants service as long as it has a connection to the credit‐control server, otherwise it terminates the end user's service session.

6.3.4 Extensibility

Because the credit‐control application is a generic framework, it has been made extensible, and use of service‐specific documents to define inputs to the rating process is expected. It is assumed that any service‐specific AVPs are known to both the credit‐control client and the credit‐control server before Diameter credit‐control messages are exchanged between them, and the document that defines those AVPs is captured in the Service‐Context‐Id AVP of the Credit‐Control‐Request. To help with interoperability, it is preferable that new credit‐control AVPs are defined within a standards organization. For example, 3GPP has several service‐specific documents, and the Service‐Context‐Id AVP contains a reference to the technical specification that defines the AVPs.

At the time of writing of this book, RFC 4006 is being updated by the IETF. Changes include updating references, fixing errata, improving the security section, clarifying details of some of the AVPs (Used‐Service‐Unit, Redirect‐Address‐Type, Filter‐Rule), and adding a few new ones to extend current AVPs, such as User‐Equipment‐Info‐Extension, Subscription‐Id‐Extension, Redirect‐Server‐Extension, and QoS‐Final‐Unit‐Indication, which supports quality of service.

6.3.5 Example: 3GPP Ro Interface for Online Charging

3GPP uses a credit‐control application on the Ro interface for online charging for SIP services, the details of which are captured in TS 32.240 7 and TS 32.299 5. The Ro interface supports real‐time transactions, and both stateless (event‐based charging) and stateful (session‐based charging) modes of operation. The Ro interface exists between a charging trigger function (CTF or credit‐control client) and an online charging system (OCS or credit‐control server). The CTF is a 3G network element and can be a media resource function controller or a SIP application server. The CTF sends charging events via Credit‐Control‐Requests for online charging to the OCS.

Two new AVPs are added to the Credit‐Control‐Request command:

• AoC‐Request‐Type: Denotes if the user equipment (UE) has requested advice of charge (AoC) and what type of information, such as cost or tariff information, is needed.
• Service‐Information: Holds service‐specific parameters as defined by the service's charging technical specification.

The following AVPs defined for the Credit‐Control‐Request command are not used in 3GPP networks:

• CC‐Sub‐Session‐Id
• Acct‐Multi‐Session‐Id
• Service‐Identifier
• Requested‐Service‐Unit
• Used‐Service‐Unit
• Service‐Parameter‐Info

The OCS sends a Credit‐Control‐Answer to acknowledge these charging events to the CTF to grant or reject the network resource usage requested in the charging event, according to the decision taken by the online charging system.

The following AVPs defined for the Credit‐Control‐Answer command are not used in 3GPP networks:

• User‐Name
• CC‐Sub‐Session‐Id
• Acct‐Multi‐Session‐Id
• Origin‐State‐Id
• Event‐Timestamp
• Granted‐Service‐Unit
• Final‐Unit‐Indication
• Check‐Balance‐Result
• Validity‐Time

Although the protocol may be stateless for event‐based charging, the CTF and OCS may keep internal state across the different charging events.

6.4.1 Actors

The actors in the Diameter QoS application include both Diameter and non‐Diameter entities. Although RFC 5866 assigns stylized acronyms to all of the actors, it does not rigidly define the behavior of the non‐Diameter actors:

• application endpoint (AppE) This is the end user's signaling application. The AppE exchanges messages, for instance SIP messages, with an application server and/or with other AppEs. It may or may not have the ability to request QoS enhancement for its signaling messages.
• application server This non‐Diameter node supports the signaling protocol. Depending on the signaling protocol used, the application server may be a source of authorization for QoS‐enhanced application flows.
• network element (NE) This is the Diameter client in the QoS application and is a QoS‐aware router. It can effect QoS changes when it is given information from the Diameter server (AE) that handles the Diameter QoS application.
• authorizing entity (AE) This is the Diameter server in the QoS application and authorizes QoS requests. It may be a standalone entity or may be integrated with an application server.
• resource‐requesting entity (RRE) This non‐Diameter, logical node supports the signaling protocol interaction for QoS resources. The RRE resides in the AppE and communicates with its peer logical entity in the AE or NE to trigger the QoS authorization process. The communication between the RRE and the NE or AE is not defined by the QoS application.

The Diameter QoS application is executed between the NE and AE.

6.4.2 Modes of Operation

The Diameter QoS mechanisms can be divided into two modes: Push or Pull. Which mode is used depends on the AppE's ability to initiate QoS resource requests. If the AppE cannot initiate QoS requests, Push mode is used. If the AppE can initiate QoS requests, Pull mode is used.

After receiving the authorization request from the application server or the NE, the AE decides the appropriate mode (Push or Pull) based on information received from the request and/or based on configuration.

6.4.3 Authorization

6.4.3.1 Push Mode Authorization Schemes

Push mode can be divided into two types: endpoint‐initiated and network‐initiated.

In the endpoint‐initiated mode (Figure 6.7), the RRE sends a QoS request to the application server via application signaling. The application server extracts application‐level QoS information and triggers the authorization process to the AE.

In the network‐initiated mode, the application server triggers the authorization process without a QoS request from the endpoint.

If the endpoint does not indicate QoS attributes, the AE and/or application server determines the QoS requirements from a combination of application‐level QoS information, network policies, end‐user subscription, and network resource availability.

The AE makes an authorization decision and sends the decision to the NE directly.

6.4.3.2 Pull Mode Authorization

Authorization schemes for Pull mode can involve either two or three parties. From the Diameter QoS application's point of view, these authorization schemes differ only in the type of information carried.

In the two‐party scheme, the NE authenticates the QoS RRE. The NE either makes authorization decisions locally or delegates the decision to a trusted entity. No Diameter QoS protocol interaction is required for this authorization scheme.

In the basic three‐party scheme (Figure 6.8), the NE forwards a received QoS reservation request to the AE, which makes the authorization decision.

The figure also shows an accounting step to track resources used by the application endpoint.

The token‐based three‐party scheme (Figure 6.9) uses authorization tokens to assist the authorization process at the NE or the AE. Tokens can assist in preventing fraud and ensuring accurate billing. RFC 3521 11, Framework for Session Set‐up with Media Authorization, covers using tokens in establishing media streams with QoS.

The RRE requests an authorization token from the AE via the application layer. If the authorization decision is successful, the AE generates an authorization token and sends it to the RRE for inclusion in the QoS signaling protocol. For an RRE/AE interaction example, refer to RFC 3313 12, which specifies Session Initiation Protocol (SIP) extensions for media authorization.

The authorization token associates the application‐layer authorization decision with the corresponding QoS signaling session. At a minimum the authorization token contains the following authorization parameters:

• an identifier for the issuing AE,
• an identifier for the application protocol session for which the token was issued,
• a keyed message digest or digital signature protecting the token's content.

An example structure for the authorization token can be found in RFC 3520 13, Session Authorization Policy Element.

The RRE sends the QoS signaling message containing the authorization token to the NE. The NE uses the authorization token to authorize the QoS request. Alternatively, the NE can forward the authorization token to the AE in the user's home network using the Diameter QoS application.

In scenarios where the RRE interacts with the AE at the application layer, binding mechanisms that do not use tokens can also work. For instance, the application‐layer protocol interaction may inform the RRE of the transport port numbers where it will receive media streams. The RRE then informs the NE about the port numbers in an IP filter indication so that the NE can tunnel the inbound packets. The NE forwards the RRE's IP address and the IP filter indications to the AE in the QoS authorization request. The AE matches the filter information with the port numbers given in the earlier application‐layer protocol interaction and identifies the policy information to send to the NE in its QoS authorization response.

6.4.4 Establishing and Managing a QoS Application Session

 <QoS-Authorization-Request> ::= < Diameter Header: 326, REQ, PXY >                                < Session-Id >                                { Auth-Application-Id }                                { Origin-Host }                                { Origin-Realm }                                { Destination-Realm }                                { Auth-Request-Type }                                [ Destination-Host ]                                [ User-Name ]                             *  [ QoS-Resources ]                                [ QoS-Authorization-Data ]                                [ Bound-Auth-Session-Id ]                             *  [ AVP ] 

  <QoS-Authorization-Answer> ::= < Diameter Header: 326, PXY >                                < Session-Id >                                { Auth-Application-Id }                                { Auth-Request-Type }                                { Result-Code }                                { Origin-Host }                                { Origin-Realm }                             *  [ QoS-Resources ]                                [ Acct-Multisession-Id ]                                [ Session-Timeout ]                                [ Authorization-Session-Lifetime ]                                [ Authorization-Grace-Period ]                             *  [ AVP ] 

    <QoS-Install-Request> ::= < Diameter Header: 327, REQ, PXY >                             < Session-Id >                             { Auth-Application-Id }                             { Origin-Host }                             { Origin-Realm }                             { Destination-Realm }                             { Auth-Request-Type }                             [ Destination-Host ]                          *  [ QoS-Resources ]                             [ Session-Timeout ]                             [ Authorization-Session-Lifetime ]                             [ Authorization-Grace-Period ]                             [ Authorization-Session-Volume ]                          *  [ AVP ] 

      <QoS-Install-Answer> ::= < Diameter Header: 327, PXY >                              < Session-Id >                              { Auth-Application-Id }                              { Origin-Host }                              { Origin-Realm }                              { Result-Code }                           *  [ QoS-Resources ]                           *  [ AVP ] 

6.4.5 Re‐Authorizing a Session

Re‐authorization policies depend on the QoS signaling protocol.

6.4.6 Terminating a Session

6.6.1 Evolved Packet Core

The four main network elements of the EPC are the Mobility Management Entity, the Home Subscriber Server, the Serving Gateway, and the Packet Data Network Gateway. Figure 6.14 illustrates the EPC network architecture and its main Diameter‐based signaling interfaces.

The Mobility Management Entity (MME) is the network element that provides UE authentication, network security, UE roaming capability, and selection of the UE's Serving Gateway and Packet Data Network Gateway. Generically, it is also referred to as a serving node in 3GPP specifications. The MME is a Diameter client node in the S6a application.

The MME accesses the Home Subscriber Server (HSS) for identity, authentication, and policy information about the UE's subscriber. The HSS is a Diameter server node in the S6a application.

The Serving Gateway (Serving GW) is the anchor point when the UE moves from one cell to another and when the UE moves from one 3GPP technology to another (2G to LTE, for example). The SGW routes user data packets and keeps track of UE session data.

The Packet Data Network Gateway (PDN GW) provides the UE with an entrance to and exit from the external packet data networks like the Internet. The PDN GW provides the UE an IP address and enforces operator policy, filters packets, and provides charging support, lawful interception, and packet screening.

6.6.2 S6a Overview

The S6a interface is the Diameter interface between the MME and the HSS. The S6a interface enables the transfer of subscriber‐related (subscription and authentication) data between the HSS and the MME over SCTP. It is also used to communicate location changes (roaming) of the UE. Multiple Diameter commands are defined for this interface and are listed in Table 6.5. This application does not use the base Diameter accounting commands. This book only provides an overview of the S6a interface. For more information on the S6a Diameter commands and AVPs, see TS 29.272 16. Details of HSS and MME behavior can be found in TS 23.401 17.

Note there is a very similar interface, known as S6d, between the HSS and the Serving GPRS Support Node (SGSN), which is responsible for the delivery of data packets to and from the mobile stations using older radio access technologies. The S6d interface uses the same Diameter commands as the S6a interface, but includes different AVPs.

The HSS and MME advertise support of the Diameter S6a application in CER/CEA commands by including the value of the S6a Application‐Id (16777251) in the Auth‐Application‐Id AVP within the Vendor‐Specific‐Application‐Id grouped AVP.

The 3GPP's vendor identifier (10415) is used in the Supported‐Vendor‐Id AVP and Vendor‐Id AVPs within the Vendor‐Specific‐Application‐Id grouped AVP. The manufacturer of a S6a Diameter node includes its ID in the top‐level Vendor‐Id AVP in the CER/CEA only, and not in the Vendor‐Specific‐Application‐Id AVP.

6.6.3 Authentication

     < AIR > ::= < Diameter Header: 318, REQ, PXY, 16777251 >                < Session-Id >                [ DRMP ]                [ Vendor-Specific-Application-Id ]                { Auth-Session-State }                { Origin-Host }                { Origin-Realm }                [ Destination-Host ]                { Destination-Realm }                { User-Name }                [ OC-Supported-Features ]              * [ Supported-Features ]                [ Requested-EUTRAN-Authentication-Info ]                { Visited-PLMN-Id }                [ AIR-Flags ]              * [ AVP ]              * [ Proxy-Info ]              * [ Route-Record ]  

        < AIA > ::= < Diameter Header: 318, PXY, 16777251 >                   < Session-Id >                   [ DRMP ]                   [ Vendor-Specific-Application-Id ]                   [ Result-Code ]                   [ Experimental-Result ]                   [ Error-Diagnostic ]                   { Auth-Session-State }                   { Origin-Host }                   { Origin-Realm }                   [ OC-Supported-Features ]                   [ OC-OLR ]                 * [ Load ]                 * [ Supported-Features ]                   [ Authentication-Info ]                   [ UE-Usage-Type ]                 * [ AVP ]                 * [ Failed-AVP ]                 * [ Proxy-Info ]                 * [ Route-Record ]  

6.6.4 Location Management

The S6a interface commands Update‐Location‐Request/Answer (ULR/ULA) (command code 316) allow the MME to inform the HSS that it is currently serving an UE, and allow the HSS to update the MME with user subscription data.

  < ULR > ::= < Diameter Header: 316, REQ, PXY, 16777251 >             < Session-Id >             [ DRMP ]             [ Vendor-Specific-Application-Id ]             { Auth-Session-State }             { Origin-Host }             { Origin-Realm }             [ Destination-Host ]             { Destination-Realm }             { User-Name }             [ OC-Supported-Features ]           * [ Supported-Features ]             [ Terminal-Information ]             { RAT-Type }             { ULR-Flags }             [ UE-SRVCC-Capability ]             { Visited-PLMN-Id }             [ Homogeneous-Support-of-IMS-Voice-Over-PS-Sessions ]             [ GMLC-Address ]           * [ Active-APN ]             [ Equivalent-PLMN-List ]             [ MME-Number-for-MT-SMS ]             [ SMS-Register-Request ]             [ SGs-MME-Identity ]             [ Coupled-Node-Diameter-ID ]             [ Adjacent-PLMNs ]             [ Supported-Services ]           * [ AVP ]           * [ Proxy-Info ]           * [ Route-Record ]   

      < CLR > ::= < Diameter Header: 317, REQ, PXY, 16777251 >                 < Session-Id >                 [ DRMP ]                 [ Vendor-Specific-Application-Id ]                 { Auth-Session-State }                 { Origin-Host }                 { Origin-Realm }                 { Destination-Host }                 { Destination-Realm }                 { User-Name }               * [ Supported-Features ]                 { Cancellation-Type }                 [ CLR-Flags ]               * [ AVP ]               * [ Proxy-Info ]               * [ Route-Record ]  

         < CLA > ::= < Diameter Header: 317, PXY, 16777251 >                    < Session-Id >                    [ DRMP ]                    [ Vendor-Specific-Application-Id ]                  * [ Supported-Features ]                    [ Result-Code ]                    [ Experimental-Result ]                    { Auth-Session-State }                    { Origin-Host }                    { Origin-Realm }                  * [ AVP ]                  * [ Failed-AVP ]                  * [ Proxy-Info ]                  * [ Route-Record ]  

         < ULA > ::= < Diameter Header: 316, PXY, 16777251 >                    < Session-Id >                    [ DRMP ]                    [ Vendor-Specific-Application-Id ]                    [ Result-Code ]                    [ Experimental-Result ]                    [ Error-Diagnostic ]                    { Auth-Session-State }                    { Origin-Host }                    { Origin-Realm }                    [ OC-Supported-Features ]                    [ OC-OLR ]                    [ Load ]                  * [ Supported-Features ]                    [ ULA-Flags ]                    [ Subscription-Data ]                  * [ Reset-ID ]                  * [ AVP ]                  * [ Failed-AVP ]                  * [ Proxy-Info ]                  * [ Route-Record ]   

6.6.5 Subscriber Data Handling

     < ISDR > ::= < Diameter Header: 319, REQ, PXY, 16777251 >                 < Session-Id >                 [ DRMP ]                 [ Vendor-Specific-Application-Id ]                 { Auth-Session-State }                 { Origin-Host }                 { Origin-Realm }                 { Destination-Host }                 { Destination-Realm }                 { User-Name }               * [ Supported-Features ]                 { Subscription-Data }                 [ IDR-Flags ]               * [ Reset-ID ]               * [ AVP ]               * [ Proxy-Info ]               * [ Route-Record ] 

       < ISDA > ::= < Diameter Header: 319, PXY, 16777251 >                   < Session-Id >                   [ DRMP ]                   [ Vendor-Specific-Application-Id ]                 * [ Supported-Features ]                   [ Result-Code ]                   [ Experimental-Result ]                   { Auth-Session-State }                   { Origin-Host }                   { Origin-Realm }                   [ IMS-Voice-Over-PS-Sessions-Supported ]                   [ Last-UE-Activity-Time ]                   [ RAT-Type ]                   [ EPS-User-State ]                   [ EPS-Location-Information ]                   [ Local-Time-Zone ]                   [ Supported-Services ]                 * [ Monitoring-Event-Report ]                 * [ Monitoring-Event-Config-Status ]                 * [ AVP ]                 * [ Failed-AVP ]                 * [ Proxy-Info ]                 * [ Route-Record ] 

     < DSR > ::= < Diameter Header: 320, REQ, PXY, 16777251 >                < Session-Id >                [ DRMP ]                [ Vendor-Specific-Application-Id ]                { Auth-Session-State }                { Origin-Host }                { Origin-Realm }                { Destination-Host }                { Destination-Realm }                { User-Name }              * [ Supported-Features ]                { DSR-Flags }                [ SCEF-ID ]              * [ Context-Identifier ]                [ Trace-Reference ]              * [ TS-Code ]              * [ SS-Code ]              * [ AVP ]              * [ Proxy-Info ]              * [ Route-Record ]  

        < DSA > ::= < Diameter Header: 320, PXY, 16777251 >                   < Session-Id >                   [ DRMP ]                   [ Vendor-Specific-Application-Id ]                 * [ Supported-Features ]                   [ Result-Code ]                   [ Experimental-Result ]                   { Auth-Session-State }                   { Origin-Host }                   { Origin-Realm }                 * [ AVP ]                 * [ Failed-AVP ]                 * [ Proxy-Info ]                 * [ Route-Record ]  

6.6.6 Fault Recovery

The S6a interface commands Reset‐Request/Answer (RSR/RSA) (command code 322) are used by the HSS to indicate to the MME that a failure has occurred. The RSR can also be used by the HSS as part of operation and maintenance actions to allow planned HSS outages without service interruption.

      < RSR > ::= < Diameter Header: 322, REQ, PXY, 16777251 >                 < Session-Id >                 [ DRMP ]                 [ Vendor-Specific-Application-Id ]                 { Auth-Session-State }                 { Origin-Host }                 { Origin-Realm }                 { Destination-Host }                 { Destination-Realm }               * [ Supported-Features ]               * [ User-Id ]               * [ Reset-ID ]                 [ Subscription-Data ]                 [ Subscription-Data-Deletion ]               * [ AVP ]               * [ Proxy-Info ]               * [ Route-Record ] 

             < RSA > ::= < Diameter Header: 322, PXY, 16777251 >                        < Session-Id >                        [ DRMP ]                        [ Vendor-Specific-Application-Id ]                      * [ Supported-Features ]                        [ Result-Code ]                        [ Experimental-Result ]                        { Auth-Session-State }                        { Origin-Host }                        { Origin-Realm }                      * [ AVP ]                      * [ Failed-AVP ]                      * [ Proxy-Info ]                      * [ Route-Record ]  

6.6.7 Notifications

The S6a interface commands Notify‐Request/Answer (NOR/NOA) (command code 323) are used between the MME and the HSS when an inter‐MME location update does not occur, but the HSS needs to be notified about the following updates:

• terminal information
• changes in UE SRVCC capability (if the MME supports SRVCC)
• an assignment/change of a dynamically allocated PDN GW for an APN, depending on access restrictions
• the HSS needs to send a Cancel‐Location‐Request to the current SGSN
• removal of MME registration for SMS
• when the SMS in MME feature is applied
• when the HSS has requested to be notified about when the UE is reachable, or if there is an update of the Homogeneous Support of IMS Voice Over PS Sessions.

 < NOR > ::= < Diameter Header: 323, REQ, PXY, 16777251 >            < Session-Id >            [ Vendor-Specific-Application-Id ]            [ DRMP ]            { Auth-Session-State }            { Origin-Host }            { Origin-Realm }            [ Destination-Host ]            { Destination-Realm }            { User-Name }            [ OC-Supported-Features ]          * [ Supported-Features ]            [ Terminal-Information ]            [ MIP6-Agent-Info ]            [ Visited-Network-Identifier ]            [ Context-Identifier ]            [ Service-Selection ]            [ Alert-Reason ]            [ UE-SRVCC-Capability ]            [ NOR-Flags ]            [ Homogeneous-Support-of-IMS-Voice-Over-PS-Sessions ]            [ Maximum-UE-Availability-Time ]          * [ Monitoring-Event-Config-Status ]            [ Emergency-Services ]          * [ AVP ]          * [ Proxy-Info ]          * [ Route-Record ]  

        < NOA > ::= < Diameter Header: 323, PXY, 16777251 >                   < Session-Id >                   [ DRMP ]                   [ Vendor-Specific-Application-Id ]                   [ Result-Code ]                   [ Experimental-Result ]                   { Auth-Session-State }                   { Origin-Host }                   { Origin-Realm }                   [ OC-Supported-Features ]                   [ OC-OLR ]                 * [ Load ]                 * [ Supported-Features ]                 * [ AVP ]                 * [ Failed-AVP ]                 * [ Proxy-Info ]                 * [ Route-Record ]  

6.6.8 Ending Subscriber Sessions

When the user detaches from the network by turning off the phone or by being inactive for several days, the MME deletes the UE's subscription data and context and then informs the HSS via a Purge‐UE‐Request command (PUR) (Figure 6.29). Depending on implementation, the MME may delete UE data immediately after its detachment, or the MME may wait before purging, so that it can reuse the UE data when the UE attaches again without accessing the HSS.

     < PUR > ::= < Diameter Header: 321, REQ, PXY, 16777251 >                < Session-Id >                [ DRMP ]                [ Vendor-Specific-Application-Id ]                { Auth-Session-State }                { Origin-Host }                { Origin-Realm }                [ Destination-Host ]                { Destination-Realm }                { User-Name }                [ OC-Supported-Features ]                [ PUR-Flags ]              * [ Supported-Features ]                [ EPS-Location-Information ]              * [ AVP ]              * [ Proxy-Info ]              * [ Route-Record ] 

        < PUA > ::= < Diameter Header: 321, PXY, 16777251 >                   < Session-Id >                   [ DRMP ]                   [ Vendor-Specific-Application-Id ]                 * [ Supported-Features ]                   [ Result-Code ]                   [ Experimental-Result ]                   { Auth-Session-State }                   { Origin-Host }                   { Origin-Realm }                   [ OC-Supported-Features ]                   [ OC-OLR ]                 * [ Load ]                   [ PUA-Flags ]                 * [ AVP ]                 * [ Failed-AVP ]                 * [ Proxy-Info ]                 * [ Route-Record ] 

6.6.9 Extensibility

The S6a interface supports many features and is extensible. To preserve backwards‐compatibility, any new functionality should be defined as optional. When extending the S6a application by adding new AVPs, the new AVPs should have the M‐bit cleared and are defined as optional in the command code format.

However, if changes are unavoidably backwards‐incompatible, the new functionality should be introduced as a new feature, and support for it advertised with the Supported‐Features AVP. If the receiver must support the feature in order to process the request, then the feature is included in the Supported‐Features AVP and the M‐bit of the Supported‐Features AVP is set.