NEI IMS - Diameter

For internal use MBB CS Network Engineering / Author / Date
1 Nokia Siemens Networks 2012

History and Acknowledgements Main Menu
History Open Issues
Versions Date Reason for Update Item Open Item Description Status / Comments
29/05/20
v1 Draft version
13
11/06/20
v2 Added comments after Internal review
13
Acknowledgements
Szymon Listwan

Main Menu
IMS Diameter interfaces
Introduction
1 Motivation and Feature Overview
Technical Details
2 Functionality and Implementation, Message Flows
Compliance Aspects
3 3GPP, IETF, ETSI
For internal use

NEI Contact:
MBB CS Zarko Vidakovic/ Author / Date
Network Engineering
Introduction Table of Contents Main Menu
IMS IP Multimedia Subsystem
IMS Reference Architecture

Main Menu
Introduction
Technical Details
Compliance Aspects
3 3GPP, IETF, ETSI
For internal use

NEI Contact:
Network Engineering
Technical details Table of Contents Main Menu
CFX-5000 (1/2)
The NSN CFX-5000 fulfills the call session control function (CSCF) as specified in the 3GPP
Technical Specifications (TS) 23.218 and 23.228. It supports the following roles defined by
3GPP:
Proxy call session control function (P-CSCF)
Interrogating call session control function (I-CSCF)
Serving call session control function (S-CSCF)
Emergency call session control function (E-CSCF)
Transit control function (TRCF)
Interconnection border control function (I-BCF)
Breakout gateway control function (BGCF)
Mobility control function (MCF)

CFX-5000 (2/2)
NSN CFX-5000 roles and functional extensions depicted as modular software components

CFX-5000 interfaces
CFX-5000 interfaces

CMS-8200
CMS-8200 is the central data store of IMS.

The subscriber DB is either directly integrated in the CMS-8200 or may serve an external central subscriber
repository through LDAP or SOAP.
The CMS-8200 is aligned with other network elements such as:
Call session control function (CSCF)
Applications servers (AS)
Mobility management entity (MME)
Authentication, authorization & accounting server (AAA server)
Bootstrapping server functionality (BSF)
Network elements in the CS domain
Subscriber administration and operation, administration, and maintenance infrastructure
IP infrastructure devices such as:
dynamic host configuration protocol (DHCP),
domain name system (DNS),
telephone number mapping (ENUM)
remote authentication dial in user service (RADIUS)
network time protocol (NTP) server
switches
routers

CMS-8200 interfaces
CMS-8200 interfaces

Diameter Base Protocol (1/7)
Diameter Base Protocol

RFC 6733
The Diameter base protocol satisfies the minimum requirements for a AAA protocol, as specified by [RFC2989]
All data delivered by the protocol is in the form of Attribute Value Pairs (AVPs)
The Diameter base protocol provides the following facilities:
Ability to exchange messages and deliver AVPs
Capabilities negotiation
Error notification
Extensibility, through addition of new applications, commands, and AVPs
Basic services necessary for applications, such as the handling of user sessions or accounting

Diameter Terminology
Diameter Agent
A Diameter Agent is a Diameter node that provides relay, proxy, redirect, or translation services
Diameter Client
A Diameter client is a node that supports Diameter client applications as well as the base protocol. Diameter clients are often
implemented in devices situated at the edge of a network and provide access control services for that network.
Diameter Node
A Diameter node is a host process that implements the Diameter protocol and acts as either a client, an agent, or a server.
Diameter Peer
Two Diameter nodes sharing a direct TCP or SCTP transport connection are called Diameter peers.
Diameter Server
A Diameter server is a Diameter node that handles authentication, authorization, and accounting requests for a particular realm. By
its very nature, a Diameter server must support Diameter server applications in addition to the base protocol.

Services/Features SCTP TCP
Connection-oriented yes yes
Diameter Transport Full duplex yes yes
The following transport protocols are supported: Reliable data transfer yes yes
Transmission Control Protocol (TCP) Partial-reliable data transfer optional no
Stream Control Transmission Protocol (SCTP) Flow control yes yes
TCP-friendly connection control yes yes

The base Diameter protocol is run on port 3868 for
ECN capable yes yes
both TCP and SCTP
Ordered data delivery yes yes
Unordered data delivery yes no
Path MTU discovery yes yes
Application PDU fragmentation yes yes
Application PDU bundling yes yes
Preserves application PDU boundaries yes no
Multistreaming yes no
Multihoming yes no
Protection against SYN flooding attack yes no
Allows half-closed connections no yes
Reachability check yes yes
Pseudo-header for checksum no (uses vtags) yes
Time-wait state for vtags for 4-tuple
Uses selective ACKs yes optional

Diameter Header
The packet consists of a Diameter header and a variable number of Attribute-Value Pairs
(AVPs) for encapsulating information relevant to the Diameter message
0 8 16 2431
Version Message Length
Command Flags Command-Code
Application-id
Hop-by-Hop Identifier
End-to-End Identifier
AVPs

Diameter header
Each command is assigned a command code, which is used for both Requests and Answers
Command codes:
Capabilities-Exchange-Request/Answer CER/CEA 257
Device-Watchdog-Request/Answer DWR /DWA 280
Disconnect-Peer-Request/Answer DPR/DPA 282
Re-Auth-Request/Answer RAR/RAA 258

Diameter application:
Is a protocol based on the Diameter base protocol
Application-ID for different applications:
Diameter Credit-Control Application DCCA
Diameter Session Initiation Protocol Application

Command flags:
The "R" (Request) bit If set, the message is a request. If cleared, the message is an answer


Diameter Base Protocol AVPs

Diameter AVPs carry:
Authentication, Accounting, Authorization information
Routing information
Configuration details for the request and reply
AVPs
Acct-Interim-Interval AVP 0 8 16 2431
Origin-Host
Session-Id AVP Code
Destination-Host AVP Flags AVP Length

Vendor ID (opt)
Data

Diameter trace example
Header
AVPs

Rf interface
Offline charging is a process with which charging information for network resource usage is collected concurrently with resource
usage. It does not affect, in real-time, the service rendered
The charging information is then passed through a chain of logical charging functions.
At the end of this process, CDR (Charging Data Records) files are generated by the network, which are then transferred to the
network operator's billing domain for the purpose of subscriber billing and/or inter-operator accounting
Exchange of offline charging information between the CTF and CDF is performed over the Rf interface, using a 3GPP-specific
Diameter application
CTF: Charging trigger function

CDF: Charging data function
C C C
CGF: Charging gateway function
Rf Ga Bx BD: Billing domain. This may also be a billing
T D G Billing Domain mediation device / post-processing System.
F F F

Rf interface
Over Rf interface, accounting requests (ACR) are used to transfer offline charging information
The Rf interface relays the messages described here between S-/P-CSCF and CDF
Diameter Rf application of the Diameter Base Protocol as used in IMS
The Diameter Rf application is the protocol of the Rf interface, which is an interface in the IP Multimedia Subsystem (IMS)
The following figure shows the complete protocol stack of the Rf interface as used in IMS
NSN Extension NSN Extension
3GPP Diameter Charging 3GPP Diameter Charging

Application Application
DIAMETER DIAMETER
TCP TCP
IP IP
S-CSCF/P-CSCF Rf CDF
Rf interface Diameter commands
Diameter commands
The Rf interface relays the messages described here between S-/P-CSCF and CDF
The messages always consist of a request and answer pair
Each pair has a command code assigned to it. The command code is in the header of each message. Requests are
identified as such by the "R" bit in the header
Accounting-Request /Answer (ACR/ACA)
Capabilities-Exchange-Request/Answer (CER/CEA)
Device-Watchdog-Request/Answer (DWR/DWA)
Disconnect-Peer-Request/Answer (DPR/DPA)

Rf interface Diameter AVPs
Diameter AVPs
Nokia-Siemens-Information ::= < AVP Header: 1 28458>
[ 3GPP-Charging-ID ]
[ Accounting-Session-ID ]
[ Service-Information ]
[ Access-Information ]
[ SCSCF-CDR-Version ]
[ Signaling-Volume ]
[ Total-Volume ]
[ Extra-Bearer-Volume ]
[ Sub-Record-Type ]
[ MSISDN ]
[ 3GPP-IMSI ]
[ Extra-Information ]
[ Emergency-Call-Indication ]
[ Refer-To-Header ]
[ Accept-Contact-Header ]
[ To-Header ]
[ From-Header ]
[ Diversion-Header ]
[ History-Info-Header ]
[ User-Agent-Information ]
[ Release-Reason-Information ]
[ Served-User-IP-Address ]
[ Served-User-Port-Number ]
[ Last-Known-Activity-Time-Stamp ]
Rf interface message flows (1/6)
Message flows
Session-based charging is the process of reporting usage for a session and uses the ACR Start, ACR Interim and
ACR Stop messages. During a session, the S-/P-CSCF may transmit multiple ACR Interim messages depending on
the session proceedings.
The sequence of steps for session-based charging is as follows:
The S-/P-CSCF receives an indication that a service has been requested, that is a 200 OK for a SIP INVITE.
In order to start an accounting session, the S-/P-CSCF sends an Accounting-Request (ACR) with Accounting-Record-Type AVP set
to START_RECORD to the CDF.
The CDF returns an Accounting-Answer (ACA) with Accounting-Record-Type set to START_RECORD to the S-/P-CSCF, and
possibly an Acct-Interim-Interval (AII) AVP set to a non-zero value indicating the desired intermediate charging interval.
When either an Acct-Interim-Interval (AII) elapses or charging conditions changes are recognized at the S-/P-CSCF, it sends an
Accounting-Request (ACR) with Accounting-Record-Type AVP set to INTERIM_RECORD to the CDF.
The CDF returns an Accounting-Answer (ACA) with Accounting-Record-Type set to INTERIM_RECORD to the S-/P-CSCF.
The service is terminated, that is the S-/P-CSCF receives a SIP BYE request.
The S-/P-CSCF sends an Accounting-Request (ACR) with Accounting-Record-Type AVP set to STOP_RECORD to the CDF.
The CDF returns an Accounting-Answer (ACA) with Accounting-Record-Type set to STOP_RECORD to the S-/P-CSCF

Session Establishment
USER A S-CSCF/P-CSCF CDF IMS B
SIP INVITE
SIP INVITE
SIP 200 OK
SIP 200 OK
ACR Start
ACA Start
SIP ACK
SIP ACK

Session Ongoing / Session Condition Changes
SIP Re-INVITE/UPDATE
SIP Re-INVITE/UPDATE
SIP 200 OK
SIP 200 OK
ACR Interim
ACA Interim
SIP ACK (Re-INVITE)

SIP ACK (Re-INVITE)

Session Release
SIP BYE
SIP BYE
ACR Stop
ACR Stop
SIP 200 OK
SIP 200 OK

Message flows
In the case of Event-based charging, the S-/P-CSCF reports the usage of the service rendered in a single operation
to the CDF. It is reported using the ACR Event message, which is triggered for the session-unrelated SIP methods
MESSAGE, PUBLISH, and OPTIONS, as well as configurable, so-called new methods .
The SIP methods for which event charging should be applied is configurable. If configured, event-based charging can
also be triggered for failed session establishments.
The sequence of steps for event-based charging is as follows:
The S-/P-CSCF receives an indication that the service has been used/delivered.
The S-/P-CSCF sends an Accounting-Request (ACR) with Accounting-Record-Type AVP set to EVENT_RECORD to indicate
service-specific information to the CDF.
The CDF receives the relevant service charging parameters and processes the accounting request.
The CDF returns an Accounting-Answer (ACA) with Accounting-Record-Type AVP set to EVENT_RECORD to the S-CSCF in order
to inform that the charging information was received.

Event-based charging
SIP MESSAGE
SIP MESSAGE
SIP 200 OK
SIP 200 OK
ACR Event
ACA Event

Ro interface
The Diameter Ro application is the protocol of the Ro interface, which is an interface in the IP
Multimedia Subsystem (IMS)
The following figure shows the complete protocol stack of the Ro interface.

Ro interface online charging
The Ro interface connects the S-CSCF with the online charging system (OCS).
Credit control requests (CCR) are used to transfer charging information between S-CSCF and the online charging system (OCS).
Online charging is a process with which charging information for network resource usage is collected concurrently with resource
usage.
For online charging the network resource usage must be authorized in real-time by the online charging system (OCS).
Exchange of online charging information and authorization is performed over the Ro interface using a 3GPP-specific Diameter
application.
CTF: Charging Trigger Function

OCF: Online Charging Function
C O C CGF: Charging Gateway Function
Ro Ga Bo BD: Billing Domain. This may also be a
T C G Billing Domain billing mediation device
F F F

Ro interface Diameter commands
Diameter commands
The messages always consist of a request and answer pair, for example, Credit-Control-Request and Credit-
Control-Answer.
Each pair has a command code assigned to it.
The command code is in the header of each message. Requests are identified as such by the R-bit ("REQ") in the
header.
Each message contains several attribute-value pairs (AVPs), each of which consists of an AVP code, and a value of
variable length allocated to a certain data type.
Credit-Control-Request /Answer (CCR/CCA)
Re-Authorization-Request /Answer (RAR/RAA)
Abort-Session-Request /Answer (ASR/ASA)

Ro interface Diameter AVPs (1/3)
Diameter AVPs
<CCR> ::= < Diameter Header: 272, REQ, PXY 4 >
< Session-Id >
Multiple-Services-Credit-Control ::= < AVP Header: 456 >
{ Origin-Host }
[ Requested-Service-Unit ]
{ Origin-Realm }
[ Granted-Service-Unit ]
{ Destination-Realm }
[ Used-Service-Unit ]
{ Auth-Application-Id }
[ Result-Code ]
{ Service-Context-Id }
[ Rating-Group ]
{ CC-Request-Type }
[ Validity-Time ]
{ CC-Request-Number }
[ Final-Unit-Indication ]
[ Destination-Host ]
[ Reporting-Reason ]
[ User-Name ]
[ Trigger-Type ]
[ Origin-State-Id ]
[Event-Timestamp]
[Subscription-Id]
[Termination-Cause]
[Multiple-Services-Indicator]
[Multiple-Services-Credit-Control]
[Service-Information]
[Siemens-Information]
[ Nokia-Siemens-Information ]
[ AVP ]
Diameter AVPs
<CCA> ::= < Diameter Header: 272, PXY 4 >
< Session-Id >
Multiple-Services-Credit-Control ::= < AVP Header: 456 >
{ Result-Code }
[ Requested-Service-Unit ]
{ Origin-Host }
[ Granted-Service-Unit ]
{ Origin-Realm }
[ Used-Service-Unit ]
[ Result-Code ]
{ CC-Request-Type }
[ Rating-Group ]
{ CC-Request-Number }
[ Validity-Time ]
[ Multiple-Services-Credit-Control ]
[ Final-Unit-Indication ]
[ Credit-Control-Failure-Handling ]
[ Reporting-Reason ]
[ Redirect-Host ]
[ Trigger-Type ]
[ Proxy-Info ]
[ Route-Record ]
[ Failed-AVP ]
[ AVP ]

MSCC (Multiple-Services-Credit-Control) AVP

This AVP contains the AVPs related to the independent credit-control of the multiple services feature.
Each instance of this AVP carries units related to one or more services or related to a single rating group
CCR MSCC AVP
CCA MSCC AVP

Ro interface message flow (1/2)
Message flows
Session charging with unit reservation UE S-CSCF OCS
IMS session establishment
Initial interrogation IMS Session Establishment
Intermediate interrogation Initial Interrogation
IMS session ongoing
Intermediate interrogation
IMS session release IMS Session ongoing
Final interrogation Intermediate Interrogation
IMS Session ongoing
Final Interrogation

Ro interface message flow (2/2)
Message flows
Event charging with unit reservation UE S-CSCF OCS
IMS Service request
Initial interrogation
IMS Service Request
IMS Service execution
Final interrogation Initial
Initial interrogation
Interrogation
IMS Service Execution
Final interrogation

Rx interface
The PCRF (Policy Control and Charging Rules Function) is a functional element that encompasses policy control
decision and flow based charging control functionalities
The Rx interface is used for the service-based policy set-up information exchange between the policy and charging
rule function (PCRF) and the proxy-call session control function (P-CSCF). This information is used by the PCRF for
the service based local policy (SBLP) decisions.
The Rx application is defined as an IETF vendor specific Diameter application, where the vendor is 3GPP and the
Application-ID for the Rx application in the present release is 16777236
With regard to the Diameter protocol defined over the Rx reference point, the PCRF acts as a Diameter server
One PCRF is able to serve more than one P-CSCF and one given P-CSCF interacts with a number of PCRFs
(although on a P-CSCF session basis, it interacts with only a single PCRF)

Rx interface commands
Diameter commands
Authentication-Authorization-Request /Answer (AAR/AAA)
Re-Auth-Request /Answer (RAR/RAA)
Session-Termination-Request/Answer (STR/STA)
Abort-Session-Request /Answer (ASR/ASA)

Rx interface AVPs (1/2)
Diameter AVPs
<AA-Request> ::= < Diameter Header: 265, REQ, PXY >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
* [ Media-Component-Description ]
[ Service-Info-Status ]
[ AF-Charging-Identifier ]
[ SIP-Forking-Indication ]
* [ Specific-Action ]
* [ Subscription-ID ]
[ Reservation-Priority ]
[ Framed-IP-Address ]
[ Framed-IPv6-Prefix ]
[ Service-URN ]
[ Origin-State-Id ]
[ LI-Indicator ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]

Rx interface AVPs (2/2)
Diameter AVPs
<AA-Answer> ::= < Diameter Header: 265, PXY >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
[ Result-Code ]
[ Experimental-Result ]
* [ Access-Network-Charging-Identifier ]
[ Access-Network-Charging-Address ]
[ Acceptable-Service-Info ]
[ IP-CAN-Type ]
[ 3GPP-RAT-Type ]
[ 3GPP2-BSID ]
[ User-Equipment-Info ]
[ 3GPP-User-Location-Info ]
[ Error-Message ]
[ Error-Reporting-Host ]
* [ Failed-AVP ]
* [ AVP ]

Cx interface
Cx interface is used for the following tasks:

Location management procedures
The operations regarding registration and de-registration.
Location retrieval operation.
User data handling procedures

The download of user information during registration and to support recovery mechanisms.
Operations to support the updating of user data and recovery mechanisms.
User authentication procedures

IMS Restoration Procedures (Refer to 3GPP TS 23.380) to support S-CSCF service interruption

Cx interface messages (1/2)
Command-Name Source Destination Abbr. Code Cx message

Messages User-Authorization-Request I-CSCF HSS UAR 300 Cx-Query + Cx-Select-Pull
User-Authorization-Answer HSS I-CSCF UAA 300 Cx-Query Resp + Cx-

Select-Pull Resp
Server-Assignment-Request S-CSCF HSS SAR 301 Cx-Put + Cx-Pull
Server-Assignemnt-Answer HSS S-CSCF SAA 301 Cx-Put Resp + Cx-Pull Resp
Location-Info-Request I-CSCF HSS LIR 302 Cx-Location-Query
Location-Info-Answer HSS I-CSCF LIA 302 Cx-Location-Query Resp
Multimedia-Auth-Request S-CSCF HSS MAR 303 Cx-AuthDataReq
Multimedia-Auth-Answer HSS S-CSCF MAA 303 Cx-AuthData Resp
Registration-Termination- Request HSS S-CSCF RTR 304 Cx-Deregister
Registration-Termination- Answer S-CSCF HSS RTA 304 Cx-Deregister Resp
Push-Profile-Request HSS S-CSCF PPR 305 Cx-Update_Subscr_Data
Push-Profile-Answer S-CSCF HSS PPA 305 Cx-Update_Subscr_Data Resp

interface messages (2/2)
User-Authorization-Request (UAR) / User-Authorization-Answer (UAA)

This procedure is used between the I-CSCF and the HSS during SIP registrations. The procedure is invoked by the I-
CSCF and is used:
To authorize the registration of the Public User Identity, checking multimedia subsystem access permissions and roaming
agreements.
To perform a first security check, determining whether the Public User Identity in the message is associated with the Private User
Identity sent in the message.
To obtain either the S-CSCF where the Public User Identity is registered or unregistered (i.e. registered as a consequence of an
originating or terminating request or there is a S-CSCF keeping the user profile stored), or the list of capabilities that the S-CSCF
has to support.

Cx interface AVPs (1/2)
Diameter AVPs
<Cx-User-Authorization-Request> ::= < Diameter Header: 300, REQ,PXY, 16777216 >
< Session-Id >
{ Vendor-Specific-Application-ID }
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
{ User-Name }
{ Public-Identity }
{ Visited-Network-Identifier }
[ User-Authorization-Type ]
[ UAR-Flags ]
*[ Supported-Features ]
*[ AVP ]

Cx interface AVPs (2/2)
Diameter AVPs
<Cx-User-Authorization-Answer> ::= < Diameter Header: 300, PXY, 16777216>
< Session-Id >
{ Vendor-Specific-Application-ID }
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ Result-Code ]
[ Server-Name ]
[ Server-Capabilities ]
*[ Supported-Features ]
*[ Failed-AVP ]
*[ AVP ]

Cx interface trace (1/2)
Cx-User-Authorization-Request trace

Cx interface trace (2/2)
Cx-User-Authorization-Answer trace

Gq interface
Gq interface
The Gq interface is used for the service-based policy set-up information exchange between the SPDF and the AF,
e.g. the P-CSCF
Diameter commands

Gq interface commands
Authentication-Authorization-Request (AAR) is sent by a P-CSCF to the PDF to request the authorization for the
bearer usage for the P-CSCF session
Authentication-Authorization-Answer (AAA) command is sent by the PDF to the P- CSCF in response to the AAR
Re-Auth-Request (RAR) command is sent from the PDF to the P-CSCF to indicate Gq specific action. As an option,
the P-CSCF may send an AAR command to the PDF to update the service information when receiving an RAA
command.
Re-Auth-Answer (RAA) command is sent by the P-CSCF to the PDF in response to RAR
Session-Termination-Request (STR) command is sent by the P-CSCF to inform the PDF that an authorized session
is being terminated.
Session-Termination-Answer (STA) command is sent by the PDF to the P-CSCF in response to the STR command
Abort-Session-Request (ASR) command is sent by the PDF to inform the P-CSCF that all bearer resources for the
authorized session have become unavailable
Abort-Session-Answer (ASA) command is sent by the P-CSCF to the PDF in response to the ASR command

Gq interface AVPs (1/2)
Diameter AVPs
<AA-Request> ::= < Diameter Header: 265, REQ, PXY >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
* [ Media-Component-Description ]
[ AF-Charging-Identifier ]
[ SIP-Forking-Indication ]
[ Specific-Action ]
* [ AF-Session-Type ]
[ LI-Indicator ]
[ UE-Access-Network]
[ User-Name ]
[ Binding-Information ]
[ Latching-Indication ]
[ Globally-Unique-Address ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ AVP ]

Gq interface AVPs (2/2)
Diameter AVPs
<AA-Answer> ::= < Diameter Header: 265, PXY >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
[ Result-Code ]
[ Authorization-Token ]
* [ Access-Network-Charging-Identifier ]
[ Access-Network-Charging-Address ]
[ Error-Message ]
[ Policy-Service-Status ]
[ Binding-Information ]
[ Error-Reporting-Host ]
* [ Failed-AVP ]
* [ Proxy-Info ]
* [ AVP ]

Sh interface
Sh interface
Used to exchange User Profile information between an AS and HSS.
Operations on the Sh interface are classified in functional groups:
Data handling procedures
The download of data from the HSS to an AS.
The update of data in the HSS.
Subscription/notification procedures
An AS can subscribe to receive notifications from the HSS of changes in data.
The HSS can notify an AS of changes in data for which the AS previously had subscribed.

Sh interface commands (1/2)
Diameter commands
User-Data-Request /Answer (UDR/UDA)
source AS, destination HSS
Profile-Update-Request/Answer (PUR/PUA)
Subscribe-Notifications- Request/Answer (SNR/SNA),

Push-Notification-Request /Answer (PNR/PNA)


Sh interface commands (2/2)
Sh message to Diameter command mapping

Sh message Source Destination Command-Name Abbreviation
Sh-Pull AS HSS User-Data-Request UDR
Sh-Pull Resp HSS AS User-Data-Answer UDA
Sh-Update AS HSS Profile-Update-Request PUR
Sh-Update Resp HSS AS Profile-Update-Answer PUA
Sh-Subs-Notif AS HSS Subscribe-Notifications-Request SNR
Sh-Subs-Notif Resp HSS AS Subscribe-Notifications-Answer SNA
Sh-Notif HSS AS Push-Notification-Request PNR
Sh-Notif Resp AS HSS Push-Notification-Answer PNA

Sh interface AVPs (1/2)
Diameter AVPs
< Sh-User-Data -Request> ::= < Diameter Header: 306, REQ, PXY, 16777217 >
<Session-Id>
{Vendor-Specific-Application-Id}
{Auth-Session-State}
{Origin-Host}
{Origin-Realm}
[Destination-Host]
*[Supported-Features]
{Destination-Realm}
{User-Identity}
[Server-Name]
*[Service-Indication]
*{Data-Reference}
[Requested-Domain]
[Requested-Nodes]
[Current-Location]
*[Identity-Set]
[User-Data]
*[AVP]

Sh interface AVPs (2/2)
Diameter AVPs
< Sh-User-Data-Answer > ::= < Diameter Header: 306, PXY,
16777217 >
<Session-Id>
{Vendor-Specific-Application-Id}
{Auth-Session-State}
{Origin-Host}
{Origin-Realm}
*[Supported-Features]
[Experimental-Result]
[Result-Code]
[User-Data]
[Framed-IP-Address]
[Framed-IPv6-Prefix]
[Framed-Interface-Id]
*[Failed-AVP]
*[AVP]

Sh interface messages (1/2)
Data Update, Registration, Notification Support

Messages flow (1/2)
1. A user subscribes to a new service. The operator provisions the service in an
AS. The AS stores some service data for a user in the HSS, Sh-Update (user
identity, updated data) e.g. repository data.
2. HSS confirms the data is updated
3. Some time later, user registers with the network
4. S-CSCF downloads the data from the HSS (during the procedure S-CSCF
Registration Notification on Cx interface).
Filter criteria specify that the AS wants to be notified that the end user is
registered
5. 200 OK
6. S-CSCF sends third party registration message to the application server to notify
that user is registered.
7. 200 OK

Sh interface messages (2/2)
Data Update, Registration, Notification Support

Messages flow (2/2)
8. The AS subscribes to notifications and downloads data needed for providing service
from HSS, by means of Sh-Subs-Notif (user identity, requested data, service
information and send data indication).
9. HSS confirms the subscription request and sends data to AS
10.At some moment, the AS decides to update users service data e.g. repository data in
the HSS, by means of Sh-Update (user identity, updated data).
11.The HSS confirms the service data is updated.
12.At some moment, user data is updated in the HSS. As the AS subscribed to notifications
(step 8), the HSS sends to the AS the requested updates, by means of Sh-Notif (user
identity, updated data).
13.The AS acknowledges the notification.

Main Menu
Introduction
Technical Details
Compliance Aspects
3 3GPP, IETF, ETSI
For internal use

NEI Contact:
Network Engineering
Compliance aspects Table of Contents Main Menu
NSN Customer documentation

3GPP TS 29.209
3GPP TS 29.328
3GPP TS 23.203
3GPP TS 32.299
3GPP TS 29.229


NEI IMS - Diameter

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

NEI IMS - Diameter

Încărcat de

Drepturi de autor:

Formate disponibile

For internal use MBB CS Network Engineering / Author / Date

1 Nokia Siemens Networks 2012

History Open Issues

For internal use MBB CS Network Engineering / Author / Date

For internal use

IMS Reference Architecture

For internal use MBB CS Network Engineering / Author / Date

For internal use

For internal use MBB CS Network Engineering / Author / Date

For internal use MBB CS Network Engineering / Author / Date

For internal use MBB CS Network Engineering / Author / Date

CMS-8200 is the central data store of IMS.

For internal use MBB CS Network Engineering / Author / Date

For internal use MBB CS Network Engineering / Author / Date

Diameter Base Protocol

For internal use MBB CS Network Engineering / Author / Date

For internal use MBB CS Network Engineering / Author / Date

Transmission Control Protocol (TCP) Partial-reliable data transfer optional no

Stream Control Transmission Protocol (SCTP) Flow control yes yes

TCP-friendly connection control yes yes

Unordered data delivery yes no

Path MTU discovery yes yes

Application PDU fragmentation yes yes

Application PDU bundling yes yes

Preserves application PDU boundaries yes no

Protection against SYN flooding attack yes no

Allows half-closed connections no yes

Reachability check yes yes

Pseudo-header for checksum no (uses vtags) yes

Time-wait state for vtags for 4-tuple

Uses selective ACKs yes optional

For internal use MBB CS Network Engineering / Author / Date

Version Message Length

Command Flags Command-Code

For internal use MBB CS Network Engineering / Author / Date

For internal use MBB CS Network Engineering / Author / Date

Diameter Base Protocol AVPs

For internal use MBB CS Network Engineering / Author / Date

Diameter trace example

For internal use MBB CS Network Engineering / Author / Date

CTF: Charging trigger function

For internal use MBB CS Network Engineering / Author / Date

3GPP Diameter Charging 3GPP Diameter Charging

For internal use MBB CS Network Engineering / Author / Date

For internal use MBB CS Network Engineering / Author / Date

USER A S-CSCF/P-CSCF CDF IMS B

For internal use MBB CS Network Engineering / Author / Date

Session Ongoing / Session Condition Changes

USER A S-CSCF/P-CSCF CDF IMS B

SIP ACK (Re-INVITE)

For internal use MBB CS Network Engineering / Author / Date

USER A S-CSCF/P-CSCF CDF IMS B

For internal use MBB CS Network Engineering / Author / Date

For internal use MBB CS Network Engineering / Author / Date

USER A S-CSCF/P-CSCF CDF IMS B

For internal use MBB CS Network Engineering / Author / Date

For internal use MBB CS Network Engineering / Author / Date

CTF: Charging Trigger Function

For internal use MBB CS Network Engineering / Author / Date

For internal use MBB CS Network Engineering / Author / Date

For internal use MBB CS Network Engineering / Author / Date

MSCC (Multiple-Services-Credit-Control) AVP

CCR MSCC AVP

CCA MSCC AVP