copyright © 2011 logtel diameter for lte by: samuel dratwa [email protected]
TRANSCRIPT
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
Copyright © 2011 LOGTEL
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
Copyright © 2011 LOGTEL
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
Copyright © 2011 LOGTEL 5
What are we selling?
It’s all about customer satisfaction
customer satisfaction !
Copyright © 2011 LOGTEL 6
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
Copyright © 2011 LOGTEL
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.
Copyright © 2011 LOGTEL 9
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
Copyright © 2011 LOGTEL
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
Copyright © 2011 LOGTEL
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%
Copyright © 2011 LOGTEL 13
Diameter Protocol
Copyright © 2011 LOGTEL
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.
Copyright © 2011 LOGTEL 15
Copyright © 2011 LOGTEL
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
Copyright © 2011 LOGTEL
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
Copyright © 2011 LOGTEL 18
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)
Copyright © 2011 LOGTEL 19
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.
Copyright © 2011 LOGTEL 20
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.
Copyright © 2011 LOGTEL 21
Proxy Agent
Copyright © 2011 LOGTEL 22
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.
Copyright © 2011 LOGTEL 23
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.
Copyright © 2011 LOGTEL
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
Copyright © 2011 LOGTEL
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
Copyright © 2011 LOGTEL
• 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
Copyright © 2011 LOGTEL
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
Copyright © 2011 LOGTEL
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 ]
Copyright © 2011 LOGTEL
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
Copyright © 2011 LOGTEL
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
Copyright © 2011 LOGTEL
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
Copyright © 2011 LOGTEL 32
Diameter applications
Copyright © 2011 LOGTEL 33
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
Copyright © 2011 LOGTEL
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
Copyright © 2011 LOGTEL
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
Copyright © 2011 LOGTEL
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
Copyright © 2011 LOGTEL
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
Copyright © 2011 LOGTEL
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
Copyright © 2011 LOGTEL
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
Copyright © 2011 LOGTEL
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
Copyright © 2011 LOGTEL
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
Copyright © 2011 LOGTEL
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
Copyright © 2011 LOGTEL
• 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
Copyright © 2011 LOGTEL
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
Copyright © 2011 LOGTEL
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
Copyright © 2011 LOGTEL
End of Tutorial
Thank You
Copyright © 2011 LOGTEL 47
DRA
Copyright © 2011 LOGTEL 48
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.
Copyright © 2011 LOGTEL 49
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
Copyright © 2011 LOGTEL
Copyright © 2011 LOGTEL
Copyright © 2011 LOGTEL 53
Comparison of Diameter and RADIUS
Copyright © 2011 LOGTEL 54
Diameter in EPC/EPS
Copyright © 2011 LOGTEL 55
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.
Copyright © 2011 LOGTEL 56
EPS Architecture
Copyright © 2011 LOGTEL 57
EPS Architecture with DRA
Copyright © 2011 LOGTEL 58
PCC in an IMS Voice Call
Copyright © 2011 LOGTEL 59
EPS initial attach
Copyright © 2011 LOGTEL 60
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 ]
Copyright © 2011 LOGTEL 61
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 ]
Copyright © 2011 LOGTEL 62
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 ]
Copyright © 2011 LOGTEL 63
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 ]
Copyright © 2011 LOGTEL 64
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
Copyright © 2011 LOGTEL 65
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 ]
Copyright © 2011 LOGTEL 66
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
Copyright © 2011 LOGTEL 67
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 ]
Copyright © 2011 LOGTEL 68
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 ]
Copyright © 2011 LOGTEL 69
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 ]
Copyright © 2011 LOGTEL 70
EPS initial attach (cont.)
Copyright © 2011 LOGTEL 71
(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 ]
Copyright © 2011 LOGTEL 72
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 ]
Copyright © 2011 LOGTEL 73
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 ]
Copyright © 2011 LOGTEL 74
Copyright © 2011 LOGTEL 75
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 ]
Copyright © 2011 LOGTEL 76
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 ]
Copyright © 2011 LOGTEL 77
EPS Detach
?
Copyright © 2011 LOGTEL 78
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
Copyright © 2011 LOGTEL
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
Copyright © 2011 LOGTEL
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
Copyright © 2011 LOGTEL
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
Copyright © 2011 LOGTEL 82
Diameter in IMS(VoLTE)
Copyright © 2011 LOGTEL
Why do we need VoLTE?
Why not use VoIP solution like Skype?
Copyright © 2011 LOGTEL
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
Copyright © 2011 LOGTEL 85
Telstra decided not use VoLTE
Copyright © 2011 LOGTEL
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
Copyright © 2011 LOGTEL
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
Copyright © 2011 LOGTEL
TAS/MMTel features
Copyright © 2011 LOGTEL
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
Copyright © 2011 LOGTEL
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
Copyright © 2011 LOGTEL
HIGH LEVEL CALL FLOW
Copyright © 2011 LOGTEL
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
Copyright © 2011 LOGTEL
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.
Copyright © 2011 LOGTEL
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
Copyright © 2011 LOGTEL
1 .P-CSCF S-CSCF : Invite
Copyright © 2011 LOGTEL
SDP
Copyright © 2011 LOGTEL
2 .S-CSCF P-CSCF : 100 trying
Copyright © 2011 LOGTEL
3 .S-CSCF SCC AS : Invite
Copyright © 2011 LOGTEL
4 . SCC AS S-CSCF : 100 trying
Copyright © 2011 LOGTEL 101
VoLTE detailed services flows
Copyright © 2011 LOGTEL
Schematic sequence flow
Copyright © 2011 LOGTEL 103
Simple Originating and terminating flow
Copyright © 2011 LOGTEL 104
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)
Copyright © 2011 LOGTEL 105
The terminating side
Copyright © 2011 LOGTEL
How to decide if it’s ORIG or TERM
Copyright © 2011 LOGTEL
CFx high level
S-CSCFAlice
TAS
Alice
Term
TAS
Alice
Orig
TAS
Bob
Term
S-CSCFBob
Copyright © 2011 LOGTEL
Copyright © 2011 LOGTEL
Copyright © 2011 LOGTEL
Copyright © 2011 LOGTEL
Copyright © 2011 LOGTEL
Copyright © 2011 LOGTEL 113
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
Copyright © 2011 LOGTEL
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)
Copyright © 2011 LOGTEL 115
ADC (as 3rd party VAS AS)
Copyright © 2011 LOGTEL
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
Copyright © 2011 LOGTEL
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.
Copyright © 2011 LOGTEL 118
Copyright © 2011 LOGTEL
messaging interworking with MMS
119
Copyright © 2011 LOGTEL 120
Roaming
Copyright © 2011 LOGTEL
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
Copyright © 2011 LOGTEL
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
Copyright © 2011 LOGTEL 123
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
Copyright © 2011 LOGTEL
Thank You!!!
…and please fill the evaluation form
124