copyright © 2011 logtel diameter for lte by: samuel dratwa [email protected]

Copyright © 2011 LOGTEL

Diameter for LTE By: Samuel Dratwa

[email protected]

Copyright © 2011 LOGTEL 2

Logtel’s Activities

Training Consulting Software Development

Logtel’s fields

Telecom Hardware Computer Tech. Skills

Israel Hi Tech Companies Product Training Outsourcing

Worldwide Logtel’s Branches Partners


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.

3


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)

4


What are we selling?

It’s all about customer satisfaction

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

AAA Charging / credit control DB inquiry Signaling (?)

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.

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.

http://en.wikipedia.org/wiki/AAA_protocol

http://en.wikipedia.org/wiki/RADIUS


Mapping SS7 protocols to SIP/Diameter

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

Guarantee quality of service for a video application

Provide subscriber profile, preferences or usage data to a mobile advertiser

Provide customized and dynamic service offerings for subscribers

New Business Models Drive Diameter Signaling

Policy Control Drives Signaling

Quality of

Service

Location

Usage

Preferences

Service Tier

Personal Ads


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

More complex policy rules adding to Diameter growth (i.e., Policy on the Device)

Mobility and Offline Charging other contributors

Future drivers include Service Delivery Applications

CAGR163%179%75%

102%


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 Description3001 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


• 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

Peer Liveness and Disconnection


Typical Diameter Exchanges

A Capabilities Exchange message carries a peer's identity and its capabilities (protocol version number, supported Diameter applications, etc.). A Diameter node only transmits commands to peers that have advertised support for the Diameter application associated with the given command.

Discovery via DNS or Static Configuration

Application-level heartbeat messages are used to proactively detect transport failures. These messages are sent periodically when a peer connection is idle and when a timely response has not been received for an outstanding request.

There are two types of messages, Requests and 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.

Peer Discovery

Peer Discovery

Capabilities Exchange Request

Capabilities Exchange AnswerCapabilities

Exchange Answer

Capabilities Exchange Request

Device Watchdog Request

Device Watchdog Answer

Request

AnswerAnswer

Request

Client ServerAgent


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

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.

TCP or SCTP Transport

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

PCRF

SessionsSessions

TCP or SCTP TransportAF AGW


Failover-Failback Procedure

Client Relay

Relay

Server

1 .Request

4 .Answer

2 .Request T-bit set

3 .Request T-bit set

4 .Answer

5 .Answer

2 .Request

3 .AnswerRequestQueue

RequestQueue

RequestQueue


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

http://tools.ietf.org/html/rfc6733








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


Client ServerCCR, Session-Id = S-Id1, Service-Identifier

CC-Request-Type = EVENT_BASEDRequested-Action = PRICE_ENQUIRY

CCA, Session-Id = S-Id1Cost-Information

CCR, Session-Id = S-Id2, Subscription-Id,CC-Request-Type = EVENT_BASED

Requested-Action = BALANCE_CHECK,Service-Identifier

CCA, Session-Id = S-Id2Check-Balance-Result

CCR, Session-Id = S-Id3, Service-IdentifierCC-Request-Type = EVENT_BASED

Requested-Action = DIRECT_DEBITINGSubscription-Id

CCA, Session-Id = S-Id3Granted-Service-Unit

Event Based Scenario Example


Session Based Scenario Example

CCR, Session-Id = S-Id1, Requested-Service-UnitCC-Request-Type = INITIAL_REQUEST

Subscription-Id

CCA, Session-Id = S-Id1Granted-Service-Unit, Validity-Time

CCR, Session-Id = S-Id1, Requested-Service-Unit,CC-Request-Type = UPDATE_REQUEST

Subscription-Id

CCR, Session-Id = S-Id1 ,CC-Request-Type = TERMINATION_REQUEST

Used-Service-Unit

CCA, Session-Id = S-Id1Cost-Information

CCA, Session-Id = S-Id1Granted-Service-Unit, Validity-Time

Client Server


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


• 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

Tariff-Change


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 domains applying other AAA protocols. As examples the DIAMETER agent may translate MAP into Diameter , CAP into Diameter , Diameter into RADIUS, etc.

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

Control amount of traffic to/from Clients and Servers

Detect and Route around congestion and failures

Orderly discard (based on Message Priority) of traffic from Client if needed

Facilitate Wi-Fi Offload using Analytics and other key indicators (i.e., Subscriber profile)

Diameter Signaling and Control Network Resiliency

A robust Diameter signaling and control architecture must Diameter

Server

Diameter Client

Diameter Client

DSR

Diameter Client: MME, PGW, CSCF, AS, etcDiameter Server: HSS, PCRF, OCS, OFCS, etc

DiameterServer

RAN

Diameter Client

Prevent Failure, Avoid Outage, Assure Recovery


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 >[ Vendor-Specific-Application-Id ][ Result-Code ][ Experimental-Result ] { Auth-Session-State }{ 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 >[ Vendor-Specific-Application-Id ]{ Auth-Session-State }{ Origin-Host }{ Origin-Realm }[ Destination-Host ]{ Destination-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 >[ Vendor-Specific-Application-Id ][ Result-Code ][ Experimental-Result ] [ Error-Diagnostic ] { Auth-Session-State }{ 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 >[ Vendor-Specific-Application-Id ]{ Auth-Session-State }{ Origin-Host }{ Origin-Realm }[ Destination-Host ]{ Destination-Realm }{ User-Name }*[ Supported-Features ][ Terminal-Information ]{ RAT-Type }{ ULR-Flags }[UE-SRVCC-Capability ]{ Visited-PLMN-Id }[ SGSN-Number ] [ 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 ]*[ AVP ]*[ Proxy-Info ]*[ Route-Record ]


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 >[ Vendor-Specific-Application-Id ]{ Auth-Session-State }{ Origin-Host }{ Origin-Realm }{ Destination-Host }{ Destination-Realm }{ User-Name }*[ Supported-Features]{ Subscription-Data}[ IDR- Flags ]*[ AVP ]*[ Proxy-Info ]*[ Route-Record ]


Subscription-Data AVP

Subscription-Data ::= <AVP header: 1400 10415>[ Subscriber-Status ][ MSISDN ] [ A-MSISDN ][ STN-SR ] [ ICS-Indicator ][ Network-Access-Mode ][ Operator-Determined-Barring ][ HPLMN-ODB ]*10[ Regional-Subscription-Zone-Code][ Access-Restriction-Data ][ APN-OI-Replacement ][ LCS-Info ][ Teleservice-List ]*[ Call-Barring-Info ]

[ 3GPP-Charging-Characteristics ] [ AMBR ][ APN-Configuration-Profile ][ RAT-Frequency-Selection-Priority-ID ][ Trace-Data][ GPRS-Subscription-Data ]*[ CSG-Subscription-Data ] [ Roaming-Restricted-Due-To-Unsupported-Feature ] [ Subscribed-Periodic-RAU-TAU-Timer ] [ MPS-Priority ] [ VPLMN-LIPA-Allowed ] [ Relay-Node-Indicator ] [ MDT-User-Consent ] [Subscribed-VSRVCC ] [Subscription-Data-Flags ]*[ AVP ]


Insert-Subscriber-Data-Answer (IDA)< Insert-Subscriber-Data-Answer> ::= < Diameter Header: 319, PXY, 16777251 >

< Session-Id >[ 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 ][ 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 } { Destination-Realm } { CC-Request-Type } { CC-Request-Number } [ Credit-Management-Status ] [ Destination-Host ] [ Origin-State-Id ]*[ Subscription-Id ]*[ Supported-Features ] [ 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 ]

[ Termination-Cause ] [ User-Equipment-Info ] [ QoS-Information ] [ QoS-Negotiation ] [ QoS-Upgrade ] [ Default-EPS-Bearer-QoS ] [ Default-QoS-Information ]

0*2[ AN-GW-Address ] [ AN-GW-Status ] [ 3GPP-SGSN-MCC-MNC ] [ 3GPP-SGSN-Address ] [ 3GPP-SGSN-IPv6-Address ] [ 3GPP-GGSN-Address ] [ 3GPP-GGSN-IPv6-Address ] [ 3GPP-Selection-Mode ] [ RAI ] [ 3GPP-User-Location-Info] [ User-Location-Info-Time ] [ User-CSG-Information ] [ TWAN-Identifier ] [ 3GPP-MS-TimeZone ] [ 3GPP-Charging-Characteristics ] [ Called-Station-Id ] [ PDN-Connection-ID ] [ Bearer-Usage ] [ Online ] [ Offline ]*[ TFT-Packet-Filter-Information ]*[ Charging-Rule-Report ] *[ Application-Detection-Information ]*[ Event-Trigger ] [ Event-Report-Indication ] [ Access-Network-Charging-Address ]*[ Access-Network-Charging-Identifier-Gx ]*[ CoA-Information ]*[ Usage-Monitoring-Information ]

[ Routing-Rule-Install ] [ Routing-Rule-Remove ] [ HeNB-Local-IP-Address ] [ UE-Local-IP-Address ] [ UDP-Source-Port ] [ Logical-Access-ID ] [ Physical-Access-ID ]*[ Proxy-Info ]*[ Route-Record ]*[ AVP ]


CCR for Gx (cont.)[ Termination-Cause ][ User-Equipment-Info ][ QoS-Information ] [ QoS-Negotiation ][ QoS-Upgrade ][ Default-EPS-Bearer-QoS ] [ Default-QoS-Information ]0*2[ AN-GW-Address ][ AN-GW-Status ][ 3GPP-SGSN-MCC-MNC ][ 3GPP-SGSN-Address ][ 3GPP-SGSN-IPv6-Address ] [ 3GPP-GGSN-Address ][ 3GPP-GGSN-IPv6-Address ][ 3GPP-Selection-Mode ][ RAI ][ 3GPP-User-Location-Info][ User-Location-Info-Time ][ User-CSG-Information ][ TWAN-Identifier ][ 3GPP-MS-TimeZone ][ 3GPP-Charging-Characteristics ][ Called-Station-Id ][ PDN-Connection-ID ][ Bearer-Usage ] [ Online ]

[ Offline ]

*[ TFT-Packet-Filter-Information ]

*[ Charging-Rule-Report ]

*[ Application-Detection-Information ]

*[ Event-Trigger ]

[ Event-Report-Indication ]

[ Access-Network-Charging-Address ]

*[ Access-Network-Charging-Identifier-Gx ]

*[ CoA-Information ]

*[ Usage-Monitoring-Information ]

[ Routing-Rule-Install ]

[ Routing-Rule-Remove ]

[ HeNB-Local-IP-Address ]

[ UE-Local-IP-Address ]

[ UDP-Source-Port ]

[ Logical-Access-ID ]

[ Physical-Access-ID ]

*[ Proxy-Info ]

*[ Route-Record ]

*[ AVP ]

[ Offline ]*[ TFT-Packet-Filter-Information ]*[ Charging-Rule-Report ] *[ Application-Detection-Information ]*[ Event-Trigger ] [ Event-Report-Indication ] [ Access-Network-Charging-Address ]*[ Access-Network-Charging-Identifier-Gx ]*[ CoA-Information ]*[ Usage-Monitoring-Information ] [ Routing-Rule-Install ] [ Routing-Rule-Remove ] [ HeNB-Local-IP-Address ] [ UE-Local-IP-Address ] [ UDP-Source-Port ] [ Logical-Access-ID ] [ Physical-Access-ID ]*[ Proxy-Info ][ Route-Record ]*[ AVP ]


CCA for Gx

<CC-Answer> ::= < Diameter Header: 272, PXY >

< Session-Id > { Auth-Application-Id } { Origin-Host } { Origin-Realm } [ Result-Code ] [ Experimental-Result ] { CC-Request-Type } { CC-Request-Number }*[ Supported-Features ] [ Bearer-Control-Mode ]*[ Event-Trigger ] [ Event-Report-Indication ] [ Origin-State-Id ]*[ Redirect-Host ] [ Redirect-Host-Usage ] [ Redirect-Max-Cache-Time ]*[ Charging-Rule-Remove ]*[ Charging-Rule-Install ] [ Charging-Information ] [ Online ] [ Offline ]

*[ QoS-Information ]

[ Revalidation-Time ]

[ Default-EPS-Bearer-QoS ]

[ Default-QoS-Information ]

[ Bearer-Usage ]

*[ Usage-Monitoring-Information ]

*[ CSG-Information-Reporting ]

[ User-CSG-Information ]

[ Session-Release-Cause ]

[ Error-Message ]

[ Error-Reporting-Host ]

*[ Failed-AVP ]

*[ Proxy-Info ]

*[ Route-Record ]

*[ AVP ]

*[ QoS-Information ] [ Revalidation-Time ] [ Default-EPS-Bearer-QoS ] [ Default-QoS-Information ] [ Bearer-Usage ]*[ Usage-Monitoring-Information ] [ CSG-Information-Reporting ] [ User-CSG-Information ] [ Session-Release-Cause ] [ Error-Message ] [ Error-Reporting-Host ]*[ Failed-AVP ]*[ Proxy-Info ]*[ Route-Record ]*[ AVP ]


Cancel-Location-Request (CLR)

< Cancel-Location-Request> ::=< Diameter Header: 317, REQ, PXY, 16777251 >

< Session-Id >[ 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 ]


Cancel-Location-Answer (CLA)

< Cancel-Location-Answer> ::= < Diameter Header: 317, PXY, 16777251 >

< Session-Id >[ Vendor-Specific-Application-Id ]*[ Supported-Features ][ Result-Code ][ Experimental-Result ] { Auth-Session-State }{ Origin-Host }{ Origin-Realm }*[ AVP ]*[ Failed-AVP ]*[ Proxy-Info ]*[ Route-Record ]


EPS Detach

?


Command-Code for S6a/S6dCommand-Name Abbreviatio

nCode

Update-Location-Request ULR 316Update-Location-Answer ULA 316Cancel-Location-Request CLR 317Cancel-Location-Answer CLA 317Authentication-Information-Request AIR 318

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


Analysis of Use CasesExample from 3GPP, Concern about signaling volume

MME

Home Subscriber Server

Mobility Management Entity

HSS

Location Update (new Tracking Area)

Update Location RequestDiameter on S6a

MME

Inter-MME TrackingArea 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

List of Session-IDs identifies a group of users, list of attributes/values applies to all users of the group

List of Session-IDs identifies multiple users, each Session-ID has an individual list of AVPs associated

Diameter Hdr [Session-ID] AVP 1Group-ID AVP 2 AVP N

Diameter Hdr [ Session-ID] AVP 1Session-ID 1 AVP 2 AVP NSession-ID K

Diameter Hdr [ Session-ID] AVP 1.1Session-ID 1

AVP K.1Session-ID K

AVP 1.2 AVP 1.N

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.

84


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

87


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 Vanity number support (12+ digits) Abbreviated Dialing Codes (ADC)

commercial and non-commercial N11 VSC International Dialing

N-way Conferencing (6-way)

Call Hold (CH) Cell ID Validation IR.94 (video support) Soft phone (including emergency

call) System announcements Smart Limits (SLW) Postpaid charging 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)

CFU (Call Forwarding Unconditional) CFNL (CF on Non-Login) CFB (CF on Busy) CFNR (CF on Non-Reply) CFNRC (CF on Non-Reachable)

Call Waiting (CW) Routing To Voicemail

Call Hold (CH) Cell ID Validation IR.94 (video support) Soft phone (including emergency

call) System announcements Smart Limits (SLW) Postpaid charging Prepaid


HIGH LEVEL CALL FLOW


Basic TAS call flow – LTE Originating

Min LuPage 12AT&T Proprietary (Restricted- LTE)

Only for use by authorized individuals within the AT&T companies and not for general distribution.

LTE Access: UE Origination Call Flow to PSTN This call flow follows the standard IMS origination call flow.

SCC-AS is the first application server being invoked.

UTRAN

3G MSC/VLR

GMSC

S/I -CSCF

TAS

SBC w P-CSCF

SCC-AS

IMS

S-GW

MME

PCRF

EPC

E-UTRAN

HSS(IMS)

HSS(CSPS)

PSTN

BGCF

CSG*

PCEF

PDN GW/GGSN

3G SGSN

SAE GW

3G

CSG*

A

B

ENUM

1

34

5

6

2

7

7

7


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.


Basic TAS call flow – LTE Terminating

AT&T Proprietary (Restricted- LTE) Only for use by authorized individuals within the AT&T companies and not for general distribution.

Page 21 Min Lu

LTE Access: I CS UE Termination Call Flow From PSTN 1. This call flow follows the standard IMS termination call flow.

SCC-AS is the last application server being invoked.

2. Step 4: T-ADS is performed and LTE termination is used.

UTRAN

3G MSC/VLR

GMSC

S/I -CSCF

TAS

SBC w P-CSCF

SCC-AS

IMS

S-GW

MME

PCRF

EPC

E-UTRAN

HSS(IMS)

HSS(CSPS)

PSTN

BGCF

CSG*

PCEF

PDN GW/GGSN

3G SGSN

SAE GW

3G

CSG*

A

B

6

43

1

6

7

7

7

5

2


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 AVPsAVP Value

Accounting-Record-Type STARTService-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)

IMS-Information :Time-Stamps: SIP-Response-Timestamp-Fraction Milliseconds fraction in relation to SIP-Response-Timestamp

IMS-Information : SDP-Session-Description v=0 IMS-Information : SDP-Session-Description o=Bob 2890844526 2890842807 IN IP4 10.47.16.5 IMS-Information : SDP-Session-Description s=- IMS-Information : SDP-Session-Description i=A Seminar on the session description protocol IMS-Information : SDP-Session-Description c=IN IP4 10.47.16.5 IMS-Information : SDP-Session-Description b=CT:1024 IMS-Information: SDP-Session-Description t=2854678930 2854679000 IMS-Information: SDP-Session-Description a=sendrecv IMS-Information: SDP-Media-Component: SDP-Media-Name m=audio 49170 RTP/AVP 0

Bob’s SDP received in the step 12

IMS-Information: SDP-Media-Component: SDP-Media-Description i=audio media

IMS-Information: SDP-Media-Component: SDP-Media-Description b=CT:1000

IMS-Information: SDP-Media-Component: SDP-Media-Description k=prompt

IMS-Information: SDP-Media-Component: SDP-Type 1 ( SDP answer) IMS-Information: SDP-Media-Component: SDP-Media-Name m=video 51372 RTP/AVP 99 90

Bob’s SDP received in the step 12

IMS-Information: SDP-Media-Component: SDP-Media-Description i=video media

IMS-Information: SDP-Media-Component: SDP-Media-Description a=rtpmap:90 h263-1998/90000

IMS-Information: SDP-Media-Component: SDP-Type 0 ( SDP offer) MMTEL-Information: Subscriber-Role 0 (originating)


The terminating side


How to decide if it’s ORIG or TERM


CFx high level

S-CSCFAlice

TAS

Alice

Term

TAS

Alice

Orig

TAS

Bob

Term

S-CSCFBob


Step Number

ACR TYPE ACR Details

27 TAS Carol: START_RECORD

Role-Of-Node = Terminating 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): START_RECORD

Role-Of-Node =Originating Calling-Party-Address=Alice/Called-Party-Address=Carol Associated-Party-Address=Bob Subscriber-Role = Originating Service-Type=CDIV Service-Mode=CFU SIP-Request-Timestamp = Timestamp of incoming INVITE ( step 6) SIP-Response-Timestamp = Timestamp of incoming INVITE response (step 31) Start-Cell-Site-Identifier = Bob’s P-ANI (step 6)

38 TAS Bob(Term): START_RECORD

Role-Of-Node = Terminating Calling-Party-Address=Alice/Called-Party-Address=Carol 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) SIP-Response-Timestamp = Timestamp of incoming INVITE response (step 37)

54.1 TAS Bob(Term): STOP_RECORD

Role-Of-Node = Terminating Calling-Party-Address=Alice/Called-Party-Address=Carol Subscriber-Role = Terminating Service-Type=CDIV Service-Mode=CFU Cause-Code=0 Disconnection-Direction=originating SIP-Request-Timestamp = Timestamp of incoming BYE ( step 52) End-Cell-Site-Identifier = [blank]

61 TAS Bob(Orig): STOP_RECORD

Role-Of-Node = Originating Calling-Party-Address=Alice/Called-Party-Address=Carol Subscriber-Role = Originating Disconnection-Direction=originating Service-Type=CDIV Service-Mode=CFU Cause-Code=0 SIP-Request-Timestamp = Timestamp of incoming BYE ( step 56) End-Cell-Site-Identifier = [blank]

74 TAS Carol(Term): STOP_RECORD

Role-Of-Node = Terminating Calling-Party-Address=Alice/Called-Party-Address=Carol Cause-Code=0 Disconnection-Direction=originating SIP-Request-Timestamp = Timestamp of incoming BYE ( step 65) End-Cell-Site-Identifier = [blank]

Diameter AVPs


Conference

TAS1(Alice Orig)

TAS2(Alice Orig)

TAS3(Alice Orig)Conference

Factory

1. INVITE Bob ]Call-id=1,To-Tag=1,From-Tag=1[

9. INVITE [email protected]

3. re-INVITE (Hold)

17. BYE

2. INVITE

4. re-INVITE(Hold)

5. INVITE Carol]Call-id=2,To-Tag=2,From-Tag=2[

6. INVITE

12. 200 OK Contact : sip:conf=AliceMSISDN@TAS3;isFocus

13. REFER sip:conf=AliceMSISDN@TAS3Refer-To: <]Bob[;method=INVITE?Replaces=1;to-tag=1;from-tag=1>

10. INVITE sip:conf=AliceMSISDN@MRFCreate conference

11. 200 OK

14. REFER sip:conf=AliceMSISDN@TAS1Refer-To: <]Bob[;method=INVITE>

15. INVITE sip:sip:conf=AliceMSISDN@MRFCreate Conference Leg (Join Bob)

16. re-INVITEMRF’s SDP

18. REFER sip:conf=AliceMSISDN@TAS3Refer-To: <]Carol[;method=INVITE?Replaces=2;to-tag=2;from-tag=2>

19. REFER sip:conf=AliceMSISDN@TAS2Refer-To: <]Carol[;method=INVITE>

21. re-INVITE MRF’s SDP

20. INVITE sip:sip:conf=AliceMSISDN@MRFCreate Conference Leg (Join Carol)

22. BYE

7. re-INVITE(Hold) 8.re-INVITE(Hold)


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

116


RCS AS

117

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( handles subscriptions to

presence lists. It creates and manages back-end subscriptions

to all resources in the presence list. The list content is retrieved

from the XDM Server.

•Manages publications from one or multiple presence source(s) of a certain presentity. This includes refreshing

presence information, replacing existing presence information with newly-published information, or removing presence

information.•Manages subscriptions from watchers to presence

information and generates notifications about presence information state changes, retrieving the presence

authorization rules from the XDM Server.


messaging interworking with MMS

119


Roaming


LTE roaming overview

1. Attachment procedure

2. Authentication procedure

3. Update location procedure

4. Subscriber data retrieval procedure

5. Policy exchange

Home network

1 Attach

2 Authenticate 2

3

Visited network

HSSMME

Roaming border

Authenticate

Update Location

4Subscriber Data

5Policy exchange

PCRF PCRF


Visited MNO

MME HSS

Home MNO

Visited MNO

PCRF

Home MNO

PCRF

• 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

• S9 Diameter interface (TS 23.203(

– Policy interface between the Home PCRF and Visited PCRF

– Transfers QoS policy and charging control information

Diameter is the key roaming protocol


Homenetwork

Visitednetwork eUTRAN

Home Routed

PCRF

eUTRAN

H-PCRF

V-PCRF

DistributedPolicy Control

eUTRAN

PCRF

VisitedP-CSCF

eUTRAN

PCRF

VisitedServices

• 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

VoLTE roaming options


Thank You!!!

…and please fill the evaluation form

124

copyright © 2011 logtel diameter for lte by: samuel dratwa [email protected]

Documents

role of diameter

logtel rapid diameter

growth diameter traffic

usage diameter message

written permission of

logtel mapping ss7 protocols

informa telecoms media

usage data