DIAMETER

Diameter
for LTE
By: Samuel Dratwa
Samuel.dratwa@gmail.com
Copyright © 2011 LOGTEL
Logtel’s Activities
Software
Training Consulting
Development
Logtel’s fields
Computer
Telecom Hardware
Tech. Skills
Product Training
Israel Hi Tech Companies
Outsourcing
Worldwide Logtel’s Branches Partners
Copyright © 2011 LOGTEL 2

About the Copyright
This documentation is protected by Copyright © 2011 LOGTEL,

32 Shacham St., Petah Tikva, 49170, Israel. World rights reserved.
The possession and use of this documentation is subjected to the
restrictions contained in this license.
No part of this documentation may be stored in a retrieval system,
transmitted or reproduced in any way, including but not limited to
photocopy, photograph, magnetic or other record, without the prior
agreement and written permission of LOGTEL.
Participants of this seminar are entitled to keep their copy of this
documentation for references purposes only.

Agenda
 Introduction
 Overview of Diameter protocol and usage
 Diameter message flow and message format
 The need for DRA
 The role of Diameter in EPC
 The role of Diameter in IMS
 The role of Diameter in roaming and hand-off
 The role of Diameter in QoS and policies
 Final exerciser (end to end flow)

What are we selling ?
customer satisfaction !
It’s all about

customer satisfaction
Diameter usage

What is Diameter?
• Next generation signaling protocol, replacing
SS7
• Exchange subscriber profile data between
fundamental core network elements/systems:
– IMS
– EPC
– Billing systems
– Roaming exchanges
Diameter usage
Diameter is an authentication, authorization, and accounting
protocol for computer networks. It evolved from and replaces
the much less capable RADIUS protocol that preceded it.
 AAA
 Charging / credit control
 DB inquiry
 Signaling (?)
The Diameter protocol was initially developed by Pat R. Calhoun, Glen Zorn, and
Ping Pan in 1998 to provide a framework for authentication, authorization and
accounting (AAA) that could overcome the limitations of RADIUS.

Mapping SS7 protocols to SIP/Diameter

New Business Models Drive Diameter Signaling
Policy Control Drives Signaling
 Guarantee quality of service for Quality

of Service
a video application Service Tier
 Provide subscriber profile,

preferences or usage data to a
mobile advertiser Preferences
Location
 Provide customized and
dynamic service offerings for
subscribers
Personal
Usage Ads
10 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

Rapid Diameter Signaling Growth
 Diameter traffic worldwide

will increase to more than 98
million MPS by 2017 (140%
CAGR)
 NA has the largest volumes
overall
 Other regions showing signs
of traffic growth
 LTE Penetration still
projected at only 13%
worldwide by 2017*
* Informa Telecoms & Media

Diameter Signaling Growth by Use Case
 Policy is the top contributor to

Diameter signaling
 Online Charging (OCS) is the
fastest growing use case CAGR
 More complex policy rules 163%
179%
adding to Diameter growth 75%
(i.e., Policy on the Device) 102%
 Mobility and Offline Charging

other contributors
 Future drivers include Service
Delivery Applications

Diameter Protocol

Diameter Packet format
Flags
• "R" (Request) bit – If set, the message is a request.
If cleared, the message is an answer.
• "P" (Proxiable) bit – If set, the message MAY be proxied, relayed or redirected.
• "E" (Error) bit – If set, the message contains a protocol error.
• "T" (Potentially re-transmitted message) bit – This flag is set after a link failover procedure,
to aid the removal of duplicate requests.

Interoperability with RADIUS
 Diameter is upwards compatible with RADIUS, so

 Messages and AVPs
 AVP codes 1-255 is reused from RADIUS
 Command codes 0-255 is reused from RADIUS
 Diameter NASREQ (RFC4005) maps RADIUS messages to/from
Diameter AA-Request and AA-Answer message
 Use of RADIUS<->Diameter Translation Agents

Interoperability with RADIUS (Cont’d)
 Translations issues
 Diameter messages can be larger than maximum RADIUS packet
 Ongoing work
 Mapping of new RADIUS extension types to Diameter
 Ongoing work
• Usage of Nas-Port-Type and Service-Type vs. defining a

new Application Id
• Use of zero(0) AppId for all base protocol messages

Result-Code AVP
 The Result-Code AVP (AVP Code 268) is of type
Unsigned32 and indicates whether a particular request was
completed successfully or an error occurred. All Diameter
answer messages in IETF-defined Diameter application
specifications MUST include one Result-Code AVP.
 Diameter provides the following classes:
 1xxx (Informational)
 2xxx (Success)
 3xxx (Protocol Errors)
 4xxx (Transient Failures)
 5xxx (Permanent Failure)

Error list
Value Message Name Description
3001 DIAMETER_COMMAND_UNSUPPORTED The Request contained a Command-Code that the
receiver did not recognize or support.
3002 DIAMETER_UNABLE_TO_DELIVER This error is given when Diameter can not deliver the
message to the destination.
3003 DIAMETER_REALM_NOT_SERVED The intended realm of the request is not recognized.

3004 DIAMETER_TOO_BUSY When returned, a Diameter node should attempt to
send the message to an alternate peer.
3005 DIAMETER_LOOP_DETECTED An agent detected a loop while trying to get the

message to the intended recipient.
3006 DIAMETER_REDIRECT_INDICATION A redirect agent has determined that the request could
not be satisfied locally.
3007 DIAMETER_APPLICATION_UNSUPPORTED A request was sent for an application that is not

supported.
3008 DIAMETER_INVALID_HDR_BITS A request was received whose bits in the Diameter
header were either set to an invalid combination.
3009 DIAMETER_INVALID_AVP_BITS A request was received that included an AVP whose flag
bits are set to an unrecognized value.
3010 DIAMETER_UNKNOWN_PEER A CER was received from an unknown peer.

Diameter nodes and agents
 Diameter is designed as a Peer-To-Peer architecture, and
every host who implements the Diameter protocol can act
as either a client or a server depending on network
deployment.
 Diameter nodes:
 Diameter client
 Diameter server
 Diameter agents
 Relay Agent
 Proxy Agent
 Redirect Agent
 Translation Agent
Although the architecture just described looks like a traditional client-server architecture, a node
acting as the Diameter server for some requests might actually act as a Diameter client in some
situations; the Diameter protocol is actually peer-to-peer-based architecture in a more generic
sense.
Proxy Agent

Redirect Agent
A Redirect Agent acts as a centralized configuration

repository for other Diameter nodes. When it receives
a message, it checks its routing table, and returns a
response message along with redirection information
to its original sender. This would be very useful for
other Diameter nodes because they won't need to
keep a list routing entries locally and can look up a
Redirect Agent when needed.
Translation Agent
The responsibility of this agent, is to convert a message from one AAA
protocol to another. The Translation Agent is helpful for a company or a
service provider to integrate the user database of two application domains,
while keeping their original AAA protocols.
Another situation is that a company wants to migrate to Diameter
protocol, but the migration consists of many phases. The Translation
Agent could provide the backward capability for a smooth migration.

Transport layer
• Protocols
– Certain nodes MUST support at least SCTP or TCP (i.e. Diameter
Client)
– Others MUST support SCTP and TCP (i.e. Diameter Servers and
Agents)
• Security
– TLS and IPSec
• Selection Process (in order of execution)
– IPSec, SCTP, TCP, TLS
• SCTP or TCP is always attempted prior to capabilities exchange
• TLS tried after capability negotiation
• IPSec and TLS maybe used exclusively

Capabilities Negotiation
• Capabilities Exchange
– Use of Capabilities-Exchange (CER/CEA) messages
– Message exchange advertises:
• Peer Identity
• Security schemes – Indicates the use of TLS
• SCTP host addresses if used
– CER/CEA may or may not be protected
• Peer Table Creation
– Lists all peers that passes capabilities negotiation
– Indicates the connection status of each peers
– Also used for message routing

Peer Liveness and Disconnection
• Liveness Test
– Use of Device-Watchdog exchange (DWR/DWA)
– Aid in Failover performance: pro-active detection of failure
• Disconnection
– Use of Disconnect-Peer exchange (DPR/DPA)
– Provides hints for future reconnection attempts
– Routing table updates

Typical Diameter Exchanges
Client Agent Server
Peer Discovery
Discovery via DNS or Static Configuration
Peer Discovery
Capabilities
Exchange Request
A Capabilities Exchange message carries a peer's
Capabilities
Exchange Request identity and its capabilities (protocol version number,
Capabilities supported Diameter applications, etc.). A Diameter node
Capabilities Exchange Answer only transmits commands to peers that have advertised
Exchange Answer
support for the Diameter application associated with the
given command.
Device Watchdog
Request Application-level heartbeat messages are used to
Device Watchdog proactively detect transport failures. These messages
Answer are sent periodically when a peer connection is idle and
when a timely response has not been received for an
Request
outstanding request.
Request
There are two types of messages, Requests and

Answer
Answer Answers.. Every answer message carries a Result-Code
AVP. The data value of the Result-Code AVP is an integer
code indicating whether a particular request was
completed successfully or whether an error occurred.

Diameter CER Example
<CER> ::= < Diameter Header: 257, REQ >
{ Origin-Host } /* Required AVP, Occurrence: 1 */
{ Origin-Realm }
1* { Host-IP-Address } /* Required AVP, Occurrence: 1+ */
{ Vendor-Id }
{ Product-Name }
[ Origin-State-Id ] /* Optional AVP, Occurrence: 0 or 1 */
* [ Supported-Vendor-Id ] /* Optional AVP, Occurrence: 0+ */
* [ Auth-Application-Id ]
* [ Inband-Security-Id ]
* [ Acct-Application-Id ]
* [ Vendor-Specific-Application-Id ]
[ Firmware-Revision ]
* [ AVP ]

Diameter Transport and Session-ID
Each Diameter process running on a host generates, or is configured with, a Diameter Identity.
The Diameter Identity is a URI-syntax string with substrings representing the host's fully qualified
domain name (FQDN), one of the ports used to listen for incoming connections, the transport used
to listen for incoming connections (i.e. TCP or SCTP), the AAA protocol (i.e. Diameter), and the
transport security (i.e. none or TLS).
The following is an example of a valid Diameter host identity:
aaa://host.abc.com:1812;transport=tcp;protocol=diameter
Sessions Sessions
AF PCRF AGW
TCP or SCTP Transport TCP or SCTP Transport
A Diameter message pertaining to a specific user session includes a Session-Id AVP, the value of
which is constant throughout the life of a session. The value of the Session-Id AVP is a globally
and eternally unique text string, intended to uniquely identify a user session without reference to
any other information.
The Diameter client initiating the session creates the Session-Id. The Session-Id begins with the
originator's Diameter Identity string and is followed by any sequence guaranteeing both topological
and temporal uniqueness.
Failover-Failback Procedure
Relay 3. Request
T-bit set
Request
Queue
4. Answer
2. Request
T-bit set
5. Answer
Server
1. Request 2. Request
Client Relay
3. Answer
Request Request
Queue Queue
4. Answer

Duplicate Detection
• Duplicates can occur
– Due to Failover
– Nodes re-sending un-answered requests: Due to reboot
• Detection
– End-to-End Id is unique for a node
– Re-sent request must have T-flag set
– Therefore, use T-flag as a hint for possible duplication, then
• Use End-to-End Id and Origin-Host AVP to detect duplication
• Duplicate request SHOULD cause the same answer to be sent
• Other Considerations
– Use of Session-Id for duplicate detection in accounting records
– Time needed to wait for duplicate messages

Diameter applications

What is Diameter Application ?
 A Diameter Application is a protocol based on the Diameter
base protocol defined in RFC 6733 (Obsoletes: RFC 3588).
Each application is defined by an application identifier and
can add new command codes and/or new mandatory AVPs.
Adding a new optional AVP does not require a new
application.
 Examples of Diameter applications:
 Diameter Mobile IPv4 Application (MobileIP, RFC 4004)
 Diameter Network Access Server Application (NASREQ, RFC 4005)
 Diameter Extensible Authentication Protocol Application (RFC 4072)
 Diameter Credit-Control Application (DCCA, RFC 4006)
 Diameter Session Initiation Protocol Application (RFC 4740)
 Various applications in the 3GPP IP Multimedia Subsystem
 Each interface in LTE

Credit Control Application Overview
• Specified in RFC 4006

• Can be used to provide real time credit control for various
applications, e.g. messaging services, gaming services
• Used between the network element providing the service
(client) and credit control server (server)
• Uses Application-Id 4

Credit Control Application Messages
 Credit Control Request (CCR)
 Sent from client to server to request authorization for a given
service
 Credit Control Answer (CCA)
 Sent from server to client and carries the result of the
corresponding authorization request
 Reauthorization Request (RAR)
 Sent by server to trigger a new CCR, e.g. after successful credit
replenishment during a service
 Reauthorization Answer (RAA)
 Sent by client as an answer to RAR

Operation Modes
• Event Based
– A single CCR/CCA exchange in each session
– Used when it is sure that requested service event will be
successful
• Session Based
– Multiple CCR/CCA exchanges in a session
– Required when there is a need to reserve credits before
providing the service
– Requires state maintenance on the server side
– Server first reserves the credits and debits them after receiving
the subsequent CCR

Some important AVPs
• CC-Request-Type AVP
– Indicates type of the request for a CCR
– Possible values are INITIAL_REQUEST, UPDATE_REQUEST,
TERMINATION_REQUEST for session based scenarios and
EVENT_REQUEST for event based scenarios
• CC-Request-Number AVP
– Identifies a request within a session
• Requested-Action AVP
– Used to indicate type of the requested action for event based
scenarios. Possible values are DIRECT_DEBITING,
REFUND_ACCOUNT, CHECK_BALANCE and PRICE_ENQUIRY

Event Based Scenario Example
Client Server
CCR, Session-Id = S-Id1, Service-Identifier
CC-Request-Type = EVENT_BASED
Requested-Action = PRICE_ENQUIRY
CCA, Session-Id = S-Id1
Cost-Information
CCR, Session-Id = S-Id2, Subscription-Id,
Requested-Action = BALANCE_CHECK,
Service-Identifier
Check-Balance-Result
CCR, Session-Id = S-Id3, Service-Identifier
Requested-Action = DIRECT_DEBITING
Subscription-Id
Granted-Service-Unit

Session Based Scenario Example
Client Server
CCR, Session-Id = S-Id1, Requested-Service-Unit
CC-Request-Type = INITIAL_REQUEST
Subscription-Id
Granted-Service-Unit, Validity-Time
CCR, Session-Id = S-Id1, Requested-Service-Unit,
CC-Request-Type = UPDATE_REQUEST
Subscription-Id
Granted-Service-Unit, Validity-Time
CCR, Session-Id = S-Id1,

CC-Request-Type = TERMINATION_REQUEST
Used-Service-Unit

Cost-Information

Credit Control Timers
 Tx timer
 Used by client to guard against non-receipt of CCA after a CCR is
sent
 Can’t rely on Tw, configuring Tw to a low value may be undesirable
and Tw on the whole message path may not be under control of the
client administrating entity
 Tcc timer
 Used by server to guard against non-receipt of CCR for session
based scenarios

Subsessions and Multiple Services
• Multiple sub-sessions may be included in a credit control

sessions. Each of them is identified by a unique CC-Sub-
Session -Id AVP and have their own credit control life cycle
• Credit control for multiple services could be performed in a
credit control session
– The goal is to limit use of network and client/server resources
– Multiple-Services-Indicator AVP is sent by client to indicate support
for multiple services
– Multiple-Services-Credit-Control AVP carries credit control related
information from server to client

Multiple Services Related Terms
• Service-Id
– Identifier for a specific service
• Rating-Group
– A group of services subject to the same cost and rating type
• Quota
– Authorized amount of resources for a specific service or rating group
• Credit Pool
– Authorized amount of resources for services/rating groups with
different charging characteristics

Tariff-Change
• Server can inform client when a tariff change will occur

with Tariff-Time-Change AVP
• Client reports used units before and after tariff change
with Tariff-Change-Usage AVP

Duplicate Detection
• Session-Id AVP, CC-Request-Number AVP and CC-

Request-Type can be used to detect duplicates
(mechanism described in RFC3588 will work too, i.e.
using Origin-Host AVP and End-to-End Identifier

High Availability/Failure Handling Features
• CC-Session-Failover AVP
– Used by servers to inform clients whether a backup instance is
present ( Client needs to know identity of backup peer by other
means )
• Credit-Control-Failure-Handling AVP
– Used by server to inform client about the expected behavior for
session based scenarios, when CCA for a CCR is not received
• Direct-Debiting-Failure-Handling AVP
– Used by server to inform client about the expected behavior for
event based scenarios, when CCA for a CCR is not received

End of Tutorial
Thank You

DRA

For scalability and configuration simplicity an agent (similar to STP in SS7/SIGTRAN
networks) links all the Diameter nodes (MME, HSS, PCEF, PCRF, OCS, OFCS, all
IMS entities, etc.) and routes the Diameter requests/answers between them.
All Diameter nodes have one entry in their routing table to deliver any DIAMETER
message to the Agent. The Diameter agent is able to route between nodes of the
same network or between nodes of different networks. To ensure availability,
agents are deployed by matted pair. Every Diameter client or server is connected
to the two Agents of that matted pair.

DRA advantages
 Scalability - Considering N entities which need to interact with M
entities, the number of TCP or SCTP connections between them is NxM
if no Diameter agent is introduced. The number is N+M if an agent is
present.
 Simplification - The Diameter in the EPS leads to the update of the
routing tables of all the entities which need to communicate with the
new entity, if no agent is involved. With the presence of an agent, only
the routing tables of the agent and the new entity are impacted.
 Network interconnection with topology hiding - The agent enables
simplifying the interconnection with other networks for the support of
roaming agreements. The agent also hides the topology of the internal
network.
 Application layer routing - The agent enables performing application-
based routing such as load balancing in the context of PCC (Policy and
Charging Control), HSS identification in the case of interaction between
MME and HSS, etc.
 AAA protocol conversion - Translation agents are important when
migration to Diameter occurs. They support interconnection with other
Diameter Signaling and Control
Network Resiliency
Prevent Failure, Avoid Outage, Assure Recovery
A robust Diameter signaling
and control architecture must Diameter Diameter
Server Server
 Control amount of traffic to/from

Clients and Servers
 Detect and Route around congestion
and failures
DSR
 Orderly discard (based on Message
Priority) of traffic from Client if needed
 Facilitate Wi-Fi Offload using Analytics
and other key indicators (i.e., Diameter
Subscriber profile) Client
Diameter Diameter
Client Client
RAN
Diameter Client: MME, PGW, CSCF, AS, etc

Diameter Server: HSS, PCRF, OCS, OFCS, etc
50 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

Comparison of Diameter and RADIUS

Diameter in EPC/EPS

Interface list
 S6 - enables transfer of subscription and authentication data for
authenticating/authorizing user access to the EPS. This interface is
between MME HSS
 S13 - used for IMEI check. This interface is between MME and EIR
(Equipment Identity Register)
 Gx - allows the PCEF (i.e., PDN GW) obtaining policy and charging rules
from the PCRF. With those rules, PCEF knows how to
authorize/block/restrict IP flows and charge those flows.
 Gy - online charging interface between PCEF and OCS
 Gz - offline charging interface between PCEF and OFCS
 S9 - the interface between the PCRF in a visited network and the PCRF
in the home network. This interface is used when the PDN GW who
terminates the bearers of the visiting user, belongs to the visited
 Rx - enabling IMS to request access network resources (i.e., dedicated
bearer) to guarantee the quality of service of the IMS sessions. Rx is
between IMS and the PCRF.
EPS Architecture

EPS Architecture with DRA

PCC in an IMS Voice Call

EPS initial attach

S13 Commands ECR
< ME-Identity-Check-Request > ::= < Diameter Header: 324, REQ, PXY, 16777252 >
< Session-Id >
[ Vendor-Specific-Application-Id ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ Destination-Host ]
{ Destination-Realm }
{ Terminal-Information }
[ User-Name ]
*[ AVP ]
*[ Proxy-Info ]
*[ Route-Record ]

S13 Commands ECA
< ME-Identity-Check-Answer> ::=< Diameter Header: 324, PXY, 16777252 >
< Session-Id >
[ Result-Code ]
[ Experimental-Result ]
{ Origin-Host }
{ Origin-Realm }
[ Equipment-Status ]
*[ AVP ]
*[ Failed-AVP ]
*[ Proxy-Info ]
*[ Route-Record ]

Authentication-Information-Request (AIR)
< Authentication-Information-Request>::=<Diameter Header: 318, REQ, PXY, 16777251 >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
{ User-Name }
*[Supported-Features]
[ Requested-EUTRAN-Authentication-Info ]
[ Requested-UTRAN-GERAN-Authentication-Info ]
{ Visited-PLMN-Id }
*[ AVP ]
*[ Proxy-Info ]
*[ Route-Record ]

Authentication-Information-Answer (AIA)
< Authentication-Information-Answer> ::=< Diameter Header: 318, PXY, 16777251 >
< Session-Id >
[ Result-Code ]
[ Error-Diagnostic ]
{ Origin-Host }
{ Origin-Realm }
* [Supported-Features]
[ Authentication-Info ]
*[ AVP ]
*[ Failed-AVP ]
*[ Proxy-Info ]
*[ Route-Record ]

Diameter Update Location Request
 MME updates the UE
location in HSS
 Origin and Destination are
specified as Host and Realm
 The user name in the
request is set to IMSI
 The Radio Access
Technology is set to EUTRAN
for LTE
 The Visited PLMN is also
included in the message

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

Diameter Update Location Answer
 The HSS accesses the
database and responds with
user information to the MME
 The Aggregate Maximum Bit
Rate (AMBR) occurs twice in
the message:
 The first occurrence specifies
the maximum bit rate for the
default PDP
 The second occurrence
specifies the maximum data
limit via the APN.
 APN configuration includes:
IP address of the PDN
Gateway. This address is
used to determine the
default route for the traffic
towards the Internet

Insert-Subscriber-Data-Request (IDR)
< Insert-Subscriber-Data-Request> ::=< Diameter Header: 319, REQ, PXY, 16777251 >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Host }
{ User-Name }
*[ Supported-Features]
{ Subscription-Data}
[ IDR- Flags ]
*[ AVP ]
*[ Proxy-Info ]
*[ Route-Record ]

Subscription-Data AVP
Subscription-Data ::= <AVP header: 1400 [ 3GPP-Charging-Characteristics ]

10415> [ AMBR ]
[ Subscriber-Status ] [ APN-Configuration-Profile ]
[ MSISDN ] [ RAT-Frequency-Selection-Priority-ID ]
[ A-MSISDN ] [ Trace-Data]
[ STN-SR ] [ GPRS-Subscription-Data ]
[ ICS-Indicator ] *[ CSG-Subscription-Data ]
[ Network-Access-Mode ] [ Roaming-Restricted-Due-To-Unsupported-
[ Operator-Determined-Barring ] Feature ]
[ HPLMN-ODB ] [ Subscribed-Periodic-RAU-TAU-Timer ]
*10[ Regional-Subscription-Zone-Code] [ MPS-Priority ]
[ Access-Restriction-Data ] [ VPLMN-LIPA-Allowed ]
[ APN-OI-Replacement ] [ Relay-Node-Indicator ]
[ LCS-Info ] [ MDT-User-Consent ]
[ Teleservice-List ] [Subscribed-VSRVCC ]
*[ Call-Barring-Info ] [Subscription-Data-Flags ]
*[ AVP ]

Insert-Subscriber-Data-Answer (IDA)
< Insert-Subscriber-Data-Answer> ::= < Diameter Header: 319, PXY, 16777251 >
< Session-Id >
*[ Supported-Features ]
[ Result-Code ]
{ Origin-Host }
{ Origin-Realm }
[ IMS-Voice-Over-PS-Sessions-Supported ]
[ Last-UE-Activity-Time ]
[ RAT-Type ]
[ IDA-Flags ]
[ EPS-User-State ]
[ EPS-Location-Information ]
[Local-Time-Zone ]
*[ AVP ]
*[ Failed-AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
EPS initial attach (cont.)

CCR for Gx (based on DCCA(
<CC-Request> ::= < Diameter Header: 272, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Origin-Host }
{ Origin-Realm }
{ CC-Request-Type }
{ CC-Request-Number }
[ Credit-Management-Status ]
[ Origin-State-Id ]
*[ Subscription-Id ]
[ TDF-Information ]
[ Network-Request-Support ]
*[ Packet-Filter-Information ]
[ Packet-Filter-Operation ]
[ Bearer-Identifier ]
[ Bearer-Operation ]
[ Dynamic-Address-Flag ]
[ Dynamic-Address-Flag-Extension ]
[ PDN-Connection-Charging-ID ]
[ Framed-IP-Address ]
[ Framed-IPv6-Prefix ]
[ IP-CAN-Type ]
[ 3GPP-RAT-Type ]
[ RAT-Type ]
CCR for Gx (cont.)
[ Termination-Cause ] [ Offline ]
[ User-Equipment-Info ] *[ TFT-Packet-Filter-Information ]
[ QoS-Information ] *[ Charging-Rule-Report ]
[ QoS-Negotiation ] *[ Application-Detection-Information ]
[ QoS-Upgrade ] *[ Event-Trigger ]
[ Default-EPS-Bearer-QoS ] [ Event-Report-Indication ]
[ Default-QoS-Information ] [ Access-Network-Charging-Address ]
0*2[ AN-GW-Address ] *[ Access-Network-Charging-Identifier-Gx ]
[ AN-GW-Status ] *[ CoA-Information ]
[ 3GPP-SGSN-MCC-MNC ] *[ Usage-Monitoring-Information ]
[ 3GPP-SGSN-Address ] [ Routing-Rule-Install ]
[ 3GPP-SGSN-IPv6-Address ] [ Routing-Rule-Remove ]
[ 3GPP-GGSN-Address ] [ HeNB-Local-IP-Address ]
[ 3GPP-GGSN-IPv6-Address ] [ UE-Local-IP-Address ]
[ 3GPP-Selection-Mode ] [ UDP-Source-Port ]
[ RAI ] [ Logical-Access-ID ]
[ 3GPP-User-Location-Info] [ Physical-Access-ID ]
[ User-Location-Info-Time ] *[ Proxy-Info ]
[ User-CSG-Information ] [ Route-Record ]
[ TWAN-Identifier ] *[ AVP ]
[ 3GPP-MS-TimeZone ]
[ 3GPP-Charging-Characteristics ]
[ Called-Station-Id ]
[ PDN-Connection-ID ]
[ Bearer-Usage ]
[ Online ]
CCA for Gx
<CC-Answer> ::= < Diameter Header: 272, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Origin-Host }
{ Origin-Realm }
[ Result-Code ]
{ CC-Request-Type } *[ QoS-Information ]
{ CC-Request-Number } [ Revalidation-Time ]
*[ Supported-Features ] [ Default-EPS-Bearer-QoS ]
[ Bearer-Control-Mode ] [ Default-QoS-Information ]
*[ Event-Trigger ] [ Bearer-Usage ]
[ Event-Report-Indication ] *[ Usage-Monitoring-Information ]
[ Origin-State-Id ] [ CSG-Information-Reporting ]
*[ Redirect-Host ] [ User-CSG-Information ]
[ Redirect-Host-Usage ] [ Session-Release-Cause ]
[ Redirect-Max-Cache-Time ] [ Error-Message ]
*[ Charging-Rule-Remove ] [ Error-Reporting-Host ]
*[ Charging-Rule-Install ] *[ Failed-AVP ]
[ Charging-Information ] *[ Proxy-Info ]
[ Online ] *[ Route-Record ]
[ Offline ] *[ AVP ]
*[
73
Cancel-Location-Request (CLR)
< Cancel-Location-Request> ::=< Diameter Header: 317, REQ, PXY, 16777251 >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Host }
{ User-Name }
*[Supported-Features ]
{ Cancellation-Type }
[ CLR-Flags ]
*[ AVP ]
*[ Proxy-Info ]
*[ Route-Record ]

Cancel-Location-Answer (CLA)
< Cancel-Location-Answer> ::= < Diameter Header: 317, PXY, 16777251 >
< Session-Id >
[ Result-Code ]
{ Origin-Host }
{ Origin-Realm }
*[ AVP ]
*[ Failed-AVP ]
*[ Proxy-Info ]
*[ Route-Record ]

EPS Detach
?
Command-Code for S6a/S6d
Command-Name Abbreviation Code
Update-Location-Request ULR 316
Update-Location-Answer ULA 316
Cancel-Location-Request CLR 317
Cancel-Location-Answer CLA 317
Authentication-Information-Request AIR 318
Authentication-Information-Answer AIA 318

Insert-Subscriber-Data-Request IDR 319
Insert-Subscriber-Data-Answer IDA 319
Delete-Subscriber-Data-Request DSR 320
Delete-Subscriber-Data-Answer DSA 320
Purge-UE-Request PUR 321
Purge-UE-Answer PUA 321
Reset-Request RSR 322
Reset-Answer RSA 322
Notify-Request NOR 323
Notify-Answer NOA 323

Analysis of Use Cases
Example from 3GPP, Concern
about signaling volume
HSS Home Subscriber Server
Diameter on S6a
Update Location Request
MME MME Mobility Management Entity
Location Update (new Tracking Area)

Inter-MME Tracking
Area Update

Grouping APVs for bulk signaling
(in the order of efficiency)
 Group-ID identifies multiple users, list of
attributes/values applies to all users of the group
Diameter Hdr [Session-ID] Group-ID AVP 1 AVP 2 AVP N
 List of Session-IDs identifies a group of users, list of

attributes/values applies to all users of the group
Diameter Hdr [Session-ID] Session-ID 1 Session-ID K AVP 1 AVP 2 AVP N
 List of Session-IDs identifies multiple users, each

Session-ID has an individual list of AVPs associated
Diameter Hdr [Session-ID] Session-ID 1 AVP 1.1 AVP 1.2 AVP 1.N
Session-ID K AVP K.1 AVP K.2 AVP K.N

References
 ETSI TS 183 060, Resources and Admission Control
Subsystem (RACS); Re interface based on the Diameter
protocol
 3GPP TS 29.272, Mobility Management Entity (MME)
and SGSN related interfaces based on the Diameter
protocol
 3GPP TS 29.816, Study on PCRF Failure and
Restoration
 TD S2-113795, Contribution to 3GPP TSG SA2 WG2
meeting #86, 11-15 July 2011, Core Network Overload
Solution Study
 Scope: Identify and document scenarios, that may result in
signaling overload
 State restoration after reboot, results in burst of re-registrations from mobile
nodes

Diameter in IMS
(VoLTE)
Why do we need VoLTE ?
Why not use VoIP solution like Skype ?

Different approach to Voice in LTE
 CSFB (Circuit Switched Fallback): In this approach,

LTE just provides data services, and when a voice call
is to be initiated or received, it will fall back to the CS
domain. When using this solution, operators just need to
upgrade the MSC instead of deploying the IMS, and therefore, can
provide services quickly. However, the disadvantage is longer call
setup delay.
 SVLTE (Simultaneous Voice and LTE): In this
approach, the handset works simultaneously in the LTE
and CS modes, with the LTE mode providing data services and
the CS mode providing the voice service. This is a solution solely
based on the handset, which does not have special requirements
on the network and does not require the deployment of IMS
either. The disadvantage of this solution is that the phone can
become expensive with high power consumption.

Telstra decided not use VoLTE

VoLTE vs. VOIP
 Why not use VoIP solution like Skype ?
 VoLTE (TAS/MMTEL) supply:
 Emergency services
 Legacy services
 Class services
 Scalability
 Robustness
 Reliability
 (high) Availability

CLASS (Custom Local Area Signaling Services)
• AKA VSC (vertical service code) - developed by AT&T in
the 1960s
• a special code dialed prior to (or instead of) a telephone
number that engages some type of special telephone
service
• Anonymous Call Rejection: start
• Anonymous Call Rejection : cancel
• Busy Number Redial : start
• Busy Number Redial : cancel
• Call Forwarding: start
• Call Forwarding: cancel
• Call Return (incoming)
• Call Waiting disable
• Caller ID Disable

TAS/MMTel features

MMTel Originating Features
 TIP (Terminating Identification Presentation)
 OIR (Originating Identification Restriction)
 Hotlining
 OCB (Outgoing Call Barring)
 Barring of All Outgoing Calls
 Barring of All Outgoing International Calls
 Dialing Plans (Number Analyzer component )
 7,10,11 digit dialing
 0,0+,01+,00 dialing  Call Hold (CH)
 Vanity number support (12+ digits)  Cell ID Validation
 Abbreviated Dialing Codes (ADC)  IR.94 (video support)
commercial and non-commercial  Soft phone (including emergency call)
 N11  System announcements
 VSC  Smart Limits (SLW)
 International Dialing  Postpaid charging
 N-way Conferencing (6-way)  Prepaid

MMTel Terminating Features
 OIP (Originating Identification Presentation)
 TIR (Terminating Identification Restriction)
 Hotlining
 ICB (Incoming Call Barring)
 Barring of all Incoming Calls
 Block List
 DND
 CDIV (Call Diversion)
 Call Hold (CH)
 CFU (Call Forwarding Unconditional)
 Cell ID Validation
 CFNL (CF on Non-Login)
 IR.94 (video support)
 CFB (CF on Busy)
 Soft phone (including emergency call)
 CFNR (CF on Non-Reply)
 System announcements
 CFNRC (CF on Non-Reachable)
 Smart Limits (SLW)
 Call Waiting (CW)
 Postpaid charging
 Routing To Voicemail  Prepaid

HIGH LEVEL CALL FLOW

PSTN
Basic TAS call flow – LTE Originating
This call flow follows the standard IMS origina
SCC-AS is the first application server bein
IMS
TAS SCC-AS
4
ENUM 3 2
5
CSG* S/I-CSCF
6
BGCF
SBC w P-CSCF HSS(IMS)
7
HSS(CSPS)
7
PDN GW/GGSN
PCR
PCEF
PSTN F
GMSC
S-GW
SAE GW
B
3G
3G CSG*
MSC/VLR
EPC MME SGSN
E-UTRAN UTRAN
3G
7
1
A
AT&T Proprietary (Restricted- LTE)

Basic TAS call flow – LTE Originating
 UE A originates a call to UE B. Follow the registration path, UE A sends SIP
INVITE message to P-CSCF and P-CSCF forwards it to S-CSCF.
 S-CSCF checks the iFC for UE A for originating processing. It determines that it
needs to invoke SCC-AS processing first. Then it sends SIP INVITE to SCC-
AS.
 After SCC-AS processing, SCC-AS acts as B2BUA and sends SIP INVITE back
to S-CSCF
 Based on iFC for UE A, TAS is invoked as the 2nd AS for originating
processing. S-CSCF sends SIP INVITE to TAS. After TAS finishes its
processing, it acts as B2BUA and sends the call back to S-CSCF
 Based on iFC for UE A, there is no more AS that needs to be invoked for
originating processing. S-CSCF performs ENUM query.
 ENUM returns with B party’s domain name, S-CSCF looks up the internal
routing table and maps B party’s domain name to the terminating network I-
CSCF domain name. DNS query is performed for S-CSCF to route the request
to terminating network’s I-CSCF. Continue with IMS termination call flow.
 Continue with LTE termination in the call termination part of the call flow.

From PSTN 1. This call flow follows the standard IMS termin
SCC-AS is the last application server being inv
Basic TAS call flow – LTE Terminating
2. Step 4: T-ADS is performed and LTE terminati
IMS 5
TAS SCC-AS
3
4 6
CSG* S/I-CSCF
2 BGCF
1
SBC w P-CSCF HSS(IMS)
7
HSS(CSPS)
7
PDN GW/GGSN
PCR
PCEF
PSTN F
GMSC
S-GW
SAE GW
B
3G
3G CSG*
MSC/VLR
EPC MME SGSN
E-UTRAN UTRAN
3G
7 A
6

1. P-CSCF  S-CSCF : Invite

SDP

2. S-CSCF  P-CSCF : 100 trying

3. S-CSCF  SCC AS : Invite

4 . SCC AS  S-CSCF : 100 trying

VoLTE detailed
services flows

Schematic sequence flow

Simple Originating and terminating flow

Diameter AVPs
AVP Value
Accounting-Record-Type START
Service-Information:
Subscription-Id : Subscription-Id-Type 1 (END_USER_IMSI)
Subscription-Id : Subscription-Id-Data Served User IMSI
IMS-Information: Role-of –Node Originating
IMS-Information: Node-Functionality AS (6)
IMS-Information: Access-Network-Information ‘P-Access-Network-Info’ header from the incoming INVITE ( step
2)
IMS-Information: User-Session-ID ‘Call-ID’ header value of incoming INVITE (step 2)
IMS-Information: Outgoing-Session-ID ‘Call-ID’ header value of outgoing INVITE (step 5)
IMS-Information: Calling-Party-Address Alice’s URIs, set from ’P-Asserted-Identity’ header of the
incoming INVITE. (step 2)
IMS-Information: Called-Party-Address Bob’s URI set in Request-URI of outgoing INVITE (step 5)
IMS-Information: Called-Asserted-Identity Bob’s URI, set from ’P-Asserted-Identity’ header of the received
18x or 200 OK INVITE response. The number of AVPs depends on
the number of ‘P-Asserted-Identity’ headers received in the
INVITE response. ( step 8 or 12)
IMS-Information: Alternate-Charged-Party-Address Should be specified with the value set in ‘CHARGED_NUMBER’

parameter of the served user profile if it is not equal to user’s
MSISDN
IMS-Information : IMS Charging Identifier Contains the ICID found in the ‘P-Charging Vector’ (‘icid-value’
parameter) of the incoming INVITE (step 2)
IMS-Information:IMS-Communication-Service-Identifier ‘ICSI’ parameter from ‘P-Asserted-Service’ header or ‘icsi’ media-

feature tag from ‘Contact’ header if exists in the incoming
INVITE (step 2)
IMS-Information: Number-Portability-Routing-Information ‘rn=’ parameter , if exists, from ‘Request-URI’ header of the
incoming INVITE (step 2)
IMS-Information: Event-Type: SIP-Method INVITE
IMS-Information: Inter-Operator-Identifier : Originating-IOI ‘orig-ioi’ parameter in the incoming INVITE ‘P-Charging –Vector’
(step 2)
IMS-Information: Inter-Operator-Identifier : Terminating-IOI ‘term-ioi’ parameter received in the 200 ok in ‘P-Charging-
Vector’ ( if exists) (step 12)
IMS-Information :Time-Stamps
IMS-Information :Time-Stamps : SIP-Request-Timestamp Time when INVITE request was received (step 2)
IMS-Information :Time-Stamps: SIP-Request-Timestamp-Fraction Milliseconds fraction in relation to SIP-Request-Timestamp

IMS-Information :Time-Stamps : SIP-Response-Timestamp Time when 200 OK received (step 12)
104
The terminating side

How to decide if it’s ORIG or TERM

CFx high level
TAS
Alice
Term
S-CSCF
Alice TAS
Alice
Orig
S-CSCF
Bob TAS
Bob
Term

Diameter AVPs
Step ACR TYPE ACR Details
Number
27 TAS Carol: Role-Of-Node = Terminating
START_RECORD Calling-Party-Address=Alice/Called-Party-Address=Carol
SIP-Request-Timestamp = Timestamp of incoming INVITE ( step 11)
SIP-Response-Timestamp = Timestamp of incoming INVITE response (step 24)
Start-Cell-Site-Identifier= Carol’s P-ANI (step 24) , received in 200 OK INVITE
Regular mobile terminated ACR event
34 TAS Bob(Orig): Role-Of-Node =Originating
Associated-Party-Address=Bob
Subscriber-Role = Originating
Service-Type=CDIV
Service-Mode=CFU
SIP-Request-Timestamp = Timestamp of incoming INVITE ( step 6)
Start-Cell-Site-Identifier = Bob’s P-ANI (step 6)
38 TAS Bob(Term): Role-Of-Node = Terminating
Associated-Party-Address=Bob
Subscriber-Role = Terminating
Service-Type=CDIV
Service-Mode=CFU
Start-Cell-Site-Identifier= P-ANI sent in the outgoing INVITE (step 3)
SIP-Request-Timestamp = Timestamp of outgoing INVITE ( step 3)
54.1 TAS Bob(Term): Role-Of-Node = Terminating
STOP_RECORD Calling-Party-Address=Alice/Called-Party-Address=Carol
Subscriber-Role = Terminating
Service-Type=CDIV
Service-Mode=CFU
Cause-Code=0
Copyright © 2011 LOGTEL Disconnection-Direction=originating 113
Conference
1. INVITE Bob [Call-id=1,To-Tag=1,From-Tag=1] 2. INVITE
3. re-INVITE (Hold) 4. re-INVITE(Hold)
TAS1 16. re-INVITE
(Alice Orig) MRF’s SDP
17. BYE
14. REFER sip:conf=AliceMSISDN@TAS1

Refer-To: <[Bob];method=INVITE>
15. INVITE sip:sip:conf=AliceMSISDN@MRF

Create Conference Leg (Join Bob)
5. INVITE Carol
[Call-id=2,To-Tag=2,From-Tag=2]
6. INVITE
TAS2
7. re-INVITE(Hold) 8.re-INVITE(Hold)
(Alice Orig)
21. re-INVITE
22. BYE MRF’s SDP
20. INVITE sip:sip:conf=AliceMSISDN@MRF

Create Conference Leg (Join Carol)

Refer-To: <[Carol];method=INVITE>
9. INVITE n-way@one.att.com 10. INVITE sip:conf=AliceMSISDN@MRF

TAS3 Create conference
12. 200 OK (Alice Orig)
11. 200 OK
Contact : sip:conf=AliceMSISDN@TAS3;isFocus Conference
Factory
Refer-To: <[Bob];method=INVITE?Replaces=1;to-tag=1;from-tag=1>
Refer-To: <[Carol];method=INVITE?Replaces=2;to-tag=2;from-tag=2>

ADC (as 3rd party VAS AS)

RCS (Rich Communication Suite)
RCS 5.1 provides a framework for discoverable and
interoperable advanced communication services and
detailed specifications for a basic set of advanced
communication services.
RCS 5.1 builds on the fundamentals from RCS Release 1 to 4, RCS-e
(RCS-enhanced) and RCS 5.0

RCS AS
XML Document Management
Server (XDMS) is a functional
element responsible for handling
the management of user XML
documents stored on the network
side, such as presence
authorization rules, static
presence information, contact and
resource lists.
Resource List Server (RLS) Manages publications from one or multiple presence •
handles subscriptions to presence source(s) of a certain presentity. This includes refreshing
lists. It creates and manages presence information, replacing existing presence information
back-end subscriptions to all with newly-published information, or removing presence
resources in the presence list. information.
The list content is retrieved from Manages subscriptions from watchers to presence information •
the XDM Server. and generates notifications about presence information state
changes, retrieving the presence authorization rules from
the XDM Server.

messaging interworking with MMS

Roaming

LTE roaming overview
1. Attachment procedure
2. Authentication procedure
3. Update location procedure
4. Subscriber data retrieval procedure
5. Policy exchange
Roaming border
Visited network Home network
MME PCRF PCRF HSS
1 Attach
2 Authenticate 2 Authenticate
3 Update Location
Subscriber Data 4
Policy exchange 5

Diameter is the key roaming protocol
• S6a Diameter (3GPP TS 23.401)

– AAA interface between visited MME and home HSS
– Transfers subscription, location and authentication data for authenticating user
access to visited EPS
Visited MNO Home MNO

MME HSS
• S9 Diameter interface (TS 23.203)

– Policy interface between the Home PCRF and Visited PCRF
– Transfers QoS policy and charging control information
Visited MNO Home MNO

PCRF PCRF

VoLTE roaming options
• Home routed with data backhaul to home network (existing data model)
• Distributed policy control with policy interfaces
• Visited P-CSCF with policy control in visited network (selected by GSMA IR.92)
• Visited services with IMS core in visited network
Home Routed Distributed Visited Visited

Policy Control P-CSCF Services
Home
network
PCRF H-PCRF PCRF PCRF
V-PCRF
Visited
network eUTRAN eUTRAN eUTRAN eUTRAN

Thank You!!!
…and please fill the evaluation form

DIAMETER

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

DIAMETER

Diunggah oleh

Hak Cipta:

Format Tersedia

Diameter

Worldwide Logtel’s Branches Partners

Copyright © 2011 LOGTEL 2

This documentation is protected by Copyright © 2011 LOGTEL,

Copyright © 2011 LOGTEL 3

Copyright © 2011 LOGTEL 4

It’s all about

Copyright © 2011 LOGTEL 6

Copyright © 2011 LOGTEL

Copyright © 2011 LOGTEL 9

Policy Control Drives Signaling

 Guarantee quality of service for Quality

 Provide subscriber profile,

10 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

 Diameter traffic worldwide

* Informa Telecoms & Media

Copyright © 2011 LOGTEL

 Policy is the top contributor to

 Mobility and Offline Charging

Copyright © 2011 LOGTEL

Copyright © 2011 LOGTEL 13

Copyright © 2011 LOGTEL

 Diameter is upwards compatible with RADIUS, so

Copyright © 2011 LOGTEL

• Usage of Nas-Port-Type and Service-Type vs. defining a

Copyright © 2011 LOGTEL

Copyright © 2011 LOGTEL 18

3003 DIAMETER_REALM_NOT_SERVED The intended realm of the request is not recognized.

3005 DIAMETER_LOOP_DETECTED An agent detected a loop while trying to get the

3007 DIAMETER_APPLICATION_UNSUPPORTED A request was sent for an application that is not

3010 DIAMETER_UNKNOWN_PEER A CER was received from an unknown peer.

Copyright © 2011 LOGTEL 21

A Redirect Agent acts as a centralized configuration

Copyright © 2011 LOGTEL 23

Copyright © 2011 LOGTEL

Copyright © 2011 LOGTEL

Copyright © 2011 LOGTEL

Client Agent Server

There are two types of messages, Requests and

Copyright © 2011 LOGTEL

Copyright © 2011 LOGTEL

Copyright © 2011 LOGTEL

Copyright © 2011 LOGTEL

Copyright © 2011 LOGTEL 32

Copyright © 2011 LOGTEL 33

• Specified in RFC 4006

Copyright © 2011 LOGTEL

Copyright © 2011 LOGTEL

Copyright © 2011 LOGTEL

Copyright © 2011 LOGTEL

Copyright © 2011 LOGTEL

CCR, Session-Id = S-Id1,

CCA, Session-Id = S-Id1

Copyright © 2011 LOGTEL

Copyright © 2011 LOGTEL

• Multiple sub-sessions may be included in a credit control

Copyright © 2011 LOGTEL

Copyright © 2011 LOGTEL

• Server can inform client when a tariff change will occur

Copyright © 2011 LOGTEL

• Session-Id AVP, CC-Request-Number AVP and CC-

Copyright © 2011 LOGTEL

Copyright © 2011 LOGTEL