Diameter For LTE - Architecture, Signaling and Call Scenarios PDF

Diameter
for LTE
Architecture, Signaling and Call scenarios
By: Samuel Dratwa

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

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

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

Agenda – Day 1
 LTE recap
 LTE architecture and components
 Policies and QoS (PCRF/PCEF)
 Roaming and handoff/handover
 IMS recap
 IMS architecture and components
 HL voice flow
 SIP & SDP
 Diameter

Agenda – Day 2 & 3
 Diameter base protocol

 Diameter message flow and message format
 DRA
 Diameter specific interfaces/application
 OCS/OFCS - Rx, Ro, Rf, Gy, Gz (focus on Ro)
 Roaming & Handoff
 Advance challenges
 RCS

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

customer satisfaction
The driving forces
 Addressing the trend of declining ARPU

 Delivery of higher bandwidth services and capacity
 Reducing OPEX & Cost/MB
 Proliferation of emerging devices, with rich mobile
applications and video
 Quad-play (bundle)
 Multiple screen offerings
 Addressing shortage in bandwidth
 Leveraging existing 3G infrastructure
 Regulation
 Re-allocation of older spectrum for 4G technologies
 Open access & net neutrality
Applications & Devices Drive Bandwidth
Feature Phones Smartphones Super Phones Tablet Computers

One
megabyte =
one digital Voice Calls: Voice Calls: Voice Calls: Web Browsing:
book, 45 4-11 MB/Hr 4 -11 MB/Hr 4-11MB/Hr 350MB
seconds of Web Browsing: Net Radio:
music, 20
Web Browsing: Web Browsing:
seconds of 20 MB 30 MB 100 MB 140 MB
medium Email: 20 MB Email: 50 MB Net Radio: YouTube Videos:
quality 70 MB 150 MB
video
YouTube Email: 100 MB
Videos: 50 MB
Email: 50 MB high-end *
80 MB netbooks or
Monthly Total*
laptops model
185 MB about 30% higher
800 MB
1,900 MB (1.9GB)
* Estimated Source: BusinessWeek (February 2010), Data: Internal Alcatel-Lucent Research

NGN Layered Architecture
NGN Planes Planes and functions
Application Plane Application Plane enables the provisioning of

services and provides the control and logic for the
Value Added Service Creation
execution of services
Control Plane Control Plane controls the elements of the network,

establishes and clears media connections
Management Plane
Basic control service
Transport Plane is responsible for the transport of

Transport
Plane media and signaling messages
Packet Based Transport
Management Plane covers network management
ensuring service fulfillment, service assurance
and billing
Access Networks
Access Networks connect customer networks or
terminals with the components of the NGN
network and aggregate the dedicated traffic type

Network topology today
BT – 21cn

Converged network
BT – 21cn

IMT Expected Targets
 IMT- Advanced (IMT-2000 – become 3G)
 high quality mobile services
 user equipment suitable for worldwide use
 user‐friendly applications, services and equipment
 worldwide roaming capability
 Improve wireless performance
 Better signal reception and better coverage
 Increase spectrum efficiency
 More subscribers and more data transfer in the same spectrum
 Flat all-IP network architecture
 High mobility up to 500 Km/H
 enhanced peak data rates to support advanced services and
applications
 100 Mbit/s (UL 50 Mbit/s DL) for high mobility
 1 Gbit/s for low mobility
 Low latency <50ms
Mobile Access Evolution

GSM Voice and Data Call Architecture
Voice Calls Path
Data Calls Path

Packet Data

3GPP Release Concept
High
Speed
Accesses
IP Core
Services
Network
R99 R4 R5 R6 R7 R8 R9 R10
2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011
EPC LTE
HSPA+
UMTS
HSPA
HSPA
LTE
Adv
UL
DL
IMS
Comm
MMTel
IMS
All converge to LTE

HL architecture
and vocabulary

Reduced Network Complexity
Flat, scalable IP based Flat Architecture: 2 nodes architecture

architecture IP based Interfaces
Flat, IP based architecture
Access Core Control
MME IMS HSS
Data
Network
Evolved Node B GateWay

LTE Network Nodes and Interfaces
EPS
From IP point of view the LTE network can be split in three parts:
• Access Network and Transport Network
• Evolved Packet Core
• Applications

Protocol Stacks
UE eNB S-GW PDN-GW
PDCP PDCP GTP-U GTP-U GTP-U/GRE GTP-U/GRE

User Plane
UDP UDP UDP UDP

RLC RLC
IP IP IP IP
MAC MAC L2 L2 L2 L2
PHY PHY L1 L1 L1 L1
Uu S1-U S5/S8
UE eNB MME S-GW P-GW

Control Plane
NAS NAS GTP-Cv2 GTP-Cv2 GTP-Cv2

RRC RRC S1AP S1AP PMIP PMIP
PDCP PDCP SCTP SCTP UDP UDP UDP

RLC RLC IP IP IP IP IP
MAC MAC L2 L2 L2 L2 L2
PHY PHY L1 L1 L1 L1 L1
Uu S1-MME S11 S5/S8

Comparison of UMTS and EPS
UMTS Core Network Evolved Packet Core
GGSN PGW
MSC SGSN SGW MME
Iu-CS Iu-PS S1-U S1-MME
Iur
RNC
Iub
NB NB eNB eNB
X2
NB
eNB
UTRAN eUTRAN
• MSC Mobile Switching Center  eNB evolved NodeB
• NB NodeB
 MME Mobility Management Entity
• RNC Radio Network Controller
• SGSN Serving GPRS Support Node  SGW Serving Gateway
• GGSN Gateway GPRS Support Node  PGW PDN Gateway
Overall Evolved Packet System architecture
RAN Evolved Packet Core

BSC
PCRF
2G Gxc
Gb S16
SGSN Gx
NodeB RNC Rx+
S4 SGW PGW
3G Iu
S5 SGi
S12
S3
eNodeB S1-U MME
LTE Operator
S1-MME S11 Gr/S6d
Services
S6b Internet
S6a Corporate
S10
Non Services
3GPP
S2c
AAA
ePDG
Untrusted Non-3GPP S2b SWx
IP Access
HSS
Trusted Non-3GPP IP S2a
Access
Control plane
User plane
RAN
Radio Access Network

Evolved Node B
 It is the only network element defined as part of

eUTRAN.
 It replaces the old Node B / RNC
combination from 3G.
 It terminates the complete radio interface including
physical layer and controlling.
 It provides all radio management functions
 An eNB can handle several cells
 To enable efficient inter-cell radio management for
cells not attached to the same eNB,
 there is a inter-eNB interface X2 specified.

4G Enabling Technology
 Both WiMAX and LTE use:

 OFDM, OFDMA and SC-FDMA
 Channel dependent scheduling
 Adaptive coding and modulation (ACM)
 Multiple-In-Multiple-Out (MIMO)
antenna processing
 Turbo coding and decoding

OFDM Concept
 We have a high rate (hence, large bandwidth) stream
of modulation symbols Xk (ex. QAM)
 Needs to be transmitted on a frequency selective
fading channel
 Stream Xk is divided into N low rate parallel sub-
streams
 Bandwidth of each sub-stream is N times narrower
 Each sub-stream is carried by one subcarrier
 Received must restore each Xk without interference
from current or previously transmitted sub-streams

Basics of OFDM: Overlapping Yet Orthogonal
 OFDM: Orthogonal Frequency Division Multiplexing

 OFDMA: Orthogonal Frequency Division Multiple Access
 FDM is nothing new: carriers are separated sufficiently in frequency so
that there is minimal overlap to prevent cross-talk
Conventional
FDMA
Frequency
 OFDM: still FDM, but carriers can actually be orthogonal (no cross-talk)
while actually overlapping, if specially designed  saved bandwidth!
saved bandwidth
OFDM
Frequency

OFDM Concept
 Transmitted OFDM Signal
 Received OFDM Signal

OFDMA Concept
 In OFDM one user occupies all subcarriers

all the time (till packet is finished)
 In OFDMA each user occupies few
subcarriers for few OFDM symbols during a
Burst of transmission
 A Burst: few subcarriers during few OFDM
symbols
 Hence the name Orthogonal Frequency
Division Multiplex Access

OFDMA Flexibility
 With OFDMA the user allocation is flexible

 Can change from frame to frame
 Multiple allocations for several applications
 Allocation changes
 In WiMAX every 5 ms
 In LTE every 1 ms
Burst Burst
time
Burst
OFDMA frequency
frequency

Single Carrier FDMA (SC-FDMA)
 A major problem with OFDM and OFDMA is high
peak-to-average power ratio (PAPR)
 Transmitted amplitude with large variation
 Requires a linear amplifier at transmitter
 Linear amplifies consumes high power
 OK at base station
 For mobile station, this consumes battery
 LTE uses a solution for UL: SC-FDMA
 Single carrier transmission

FDD vs. TDD
paired
Unpaired

LTE Frequencies Bands

MIMO
 Signal transmitted from multiple antennas
(Multiple Out)
 Signal received by multiple antennas (Multiple In)
TX RX
M N
antennas antennas
• Receiver combines the received signals and

optimally combine energy from MxN channels
• Two main types of MIMO
 Transmit Diversity (also called Alamouti)
 Spatial Multiplexing
MIMO types
 Transmit diversity:
 Same modulation symbols sent from all Tx M antennas
 Receiver combines the signal from N antennas
 Useful to increase performance against fading
 Spatial multiplexing:
 Different modulation symbols sent from M Tx antennas
 Receiver received the signal from N antennas
 Useful to increase data rate if channel is good
 LTE uses up to 8x8

MIMO Radio Channel
 Multiple antennas at both the base station and terminal can

significantly increase data rates with sufficient multipath
 Reduce noise
 Reduce handoffs and disconnecting

Radio Challenges
Delay
Sprea
d
Path
Loss
Rayleigh
Fading

So, What will be the bandwidth ?

EPC
Evolved Packet Core

EPC Network Nodes
Serving Gateway
• Manages the user data path (SAE bearers) within EPC
• It connects via the S1-U interface towards eNB and receives
uplink packet data from here and transmits downlink packet
data on it.
• The serving gateway has packet data anchoring function
within EPC.
• It relays the packet data within EPC via the S5/S8 interface HSS
to or from the PDN gateway. AAA
• A serving gateway is controlled by one or more MMEs via
PCRF
S11 interface.
Packet Data Network Gateway

• The PDN gateway provides the connection between EPC and MME PDN
a number of external data networks.
• PDN Gateway is comparable to GGSN in 2G/3G networks. SGW PGW
• Mobility anchor for mobility between 3GPP access systems
and non-3GPP access systems. SAE GW
• Policy Enforcement (PCEF)
• Per User based Packet Filtering (i.e. deep packet inspection)
• Charging & Lawful Interception support
• IP Address Allocation for UE
• Packet screening (firewall functionality)

Roaming in LTE
• Roaming for home routed traffic is the similar scenario used at the moment in 3G data networks
• Subscriber traffic is routed from Visited PLMN to Home PLMN via the GRX provider
• The S8 interface is the reference point between visited S-GW and home P-GW
• S8-GTP is a natural choice for roaming as many operators are using GTP for roaming in 2G/3G

None 3GPP access architecture
HSS
SWx
S6a PCRF
Gxc Rx
Gx
Operator's IP
SGi Services
3GPP Serving PDN (e.g. IMS, PSS
Access Gateway Gateway etc.)
S5
S6b
S2b
Gxb
SWm
S2a ePDG 3GPP AAA
Server
HPLMN SWn
Non-3GPP Gxa
Networks SWu
Trusted Untrusted
Non-3GPP IP Non-3GPP IP
Access Access SWa
STa
UE

MME - Mobility Management Entity
 It is a pure signaling entity inside the EPC;
P-GW & S-GW selection
 Idle mode UE tracking and paging procedure including
retransmissions (The basic principle is identical to location or
routing areas from 2G/3G)
 MME handles attaches and detaches to the SAE system, as well
as tracking area updates
 Bearer activation/deactivation process and choice of the SGW for
a UE at the initial attach and at time of intra-LTE handover
involving Core Network (CN) node relocation
 NAS signaling & security - The Non-Access Stratum (NAS)
signaling terminates at the MME and it is also responsible for
generation and allocation of temporary identities to UEs
 Interface towards the HSS which stores the subscription relevant
information and the currently assigned MME in its permanent
data base.
HSS & PCRF
Home Subscriber Server
• Permanent and central subscriber
database
• Stores mobility and service data for every
subscriber
HSS
• Contains the Authentication Center (AuC) AAA
functionality. PCRF
MME PDN
SGW PGW
Policy and Charging Rule Function
SAE GW
• The PCRF major functionality is the Quality
of Service (QoS) coordination

Basic Evolved Packet System Architecture
 Architecture supports eUTRAN and legacy 2G/3G

accesses as well
 PtP link is established between the UE and the P-GW
 User-plane traffic always tunneled over the transport
network.
 User-plane addressing independent of transport
network addressing and IP versions.
S1-MME MME S11
PDN / IP
LTE-Uu S1-U S5/S8 SGi
UE eNodeB S-GW P-GW Services
Dual-Stack EPS Bearer

PDN Connection
 A PDN Connection is an association between an UE and a PDN,
represented by one IPv4 address and/or one /64 IPv6 prefix
 A PDN is identified by an APN and a PDN is accessed via a PDN-
GW
 A PDN is responsible for the IP address/prefix management.
 On an UE a PDN Connection is equivalent (or visible to an IP
stack) as a virtual network interface.
 Pre-Release-8 “equivalent” for a PDN Connection is the PDP
Context (used in GPRS).
APN points to a
specific PDN-GW and
“names” the PDN..
Operator SGi
S5/S8
UE Core & RAN PDN-
Point-to-point connection GW PDN
UE sees the PDN

PDN-GW is UE’s mobility
Connection as an interface
anchor for the Addresses/prefixes
with an address/prefix that
address/prefix.. belong to a PND..
belongs to the PDN..

EPS Bearer Model
• A logical concept of a bearer has been defined as an
aggregate of one or more IP flows related to one or more
services.
• The EPS bearer is between the UE and the PDN-GW, and
used to transport IP (v4 and/or v6) packets
• The UE performs the binding of the UL IP flows and the
PDN-GW performs the binding of the DL IP flows

Access Point Name concept
 UEs and network use APNs to identify a network (e.g.
internet, corporate intra-network, etc) and to some extent
the associated services in that network. Example
“internet.example.com”
 APNs are piggybacked on the administration of the DNS
namespace. Release-8 uses extensively S-NAPTR, where
are pre-Release-8 was just A/AAAA.
 During the connection (bearer) setup, APNs are used (by
SGSN/MME) to discover the gateway (GGSN/PDN-GW) that
provides the IP connectivity to the network identifier by
the APN, supported protocols, topological location
collocation propertied of gateways.

Access Point Name concept cont’d
 UE would just request an APN e.g. for

$ORIGIN epc.mnc123.mcc345.3gppnetwork.org.
“internet” or request nothing.. ...
internet.apn
 MME either figures out the “default” APN IN NAPTR 10 1 "a" "x-3gpp-pgw:x-s5-gtp" ""
topoff.b1.gw1.nodes
for the UE/subscriber.. or IN NAPTR 20 2 "a" "x-3gpp-pgw:x-s5-pmip” ""
topoff.b1.gw2.nodes
 ..MME would substitute a full domain ...
name of the APN received from the UE topoff.b1.gw1.nodes IN A 192.0.2.113

IN A 192.0.2.114
 MME would then: IN
IN
AAAA 2001:db8:0:c:0:0:0:0
AAAA 2001:db8:0:d:0:0:0:0
 Query a NAPTR for the domain topoff.b2.gw2.nodes IN
IN
A 192.0.2.143
A 192.0.2.144
 Select the NAPTR which matches the IN AAAA 2001:db8:0:2a:0:0:0:0
...
required protocols and such..
 Query A/AAAA for both SGW and PDN-GW
 Push the “selected” PDN-GW address to
“selected“ PGW
DNS
S11
MME
PDN- PDN / IP
UE eNodeB SGW
S5/S8 SGi
GW Services

Address Management
 IPv4 Address Configuration.
 Two methods: DHCPv4 or within the EPS bearer setup signaling
(the common way)
 DHCP is optional on both the UE and the P-GW
 IPv6 Address Configuration.
 One method: Stateless Address Autoconfiguration after the bearer
setup.
 A single /64 prefix is only supported

EPS Bearer Types
 IPv4 only bearer.

 The bearer is configured with one IPv4 address.
 The link is “IPv4 only”.
 IPv6 only bearer.
 The bearer is configured with one /64 prefix.
 The link is “IPv6 only”.
 IPv4v6 bearer.
 The bearer is configured with both IPv4 address and one
/64 prefix.
 New bearer type since Release-8.
 The link is “dual-stack”.
 V4v6 bearer type is the default in Rel-8 and beyond
 Rel 9 has also introduced the DS PDP context type for
UTRAN and EDGE

PDN Connection Establishment
UE eNodeB MME SGW PDN-GW HSS/AAA

1. Attach request
1)
1)
2. Auth/AuthZ phase
3. Create Session Request
Authentication and Authorization 2) 4. Create Session Response
5. Initial context setup
3)
3)
request/Attach accept
6. Radio bearer reconfig
4)
4) 7. Initial context setup
5)
Address/ response
6) RB Setup prefix 8. Direct transfer
allocation
8)
7) 9. Attach complete
9) 10. UE starts sending UL data
UL Data 10) 11. Modify bearer request
11) 12. Modify response
12) 13. DL data transmission starts
13) DL Data

Dual-Stack Approach for IP Access
 Networks prior to Release-8
 Dual-stack connectivity possible by opening two parallel PDP
Contexts of types IPv4 and IPv6.
 Shows up as two separate interfaces to the IP stack.
 Networks from Release-8 onwards.
 A single IPv4v6 PDN Connection in addition to having separate v4
and v6 PDN connections.
 Shows up as one interface with both IPv4 and IPv6 addresses to the
IP stack (with v4v6 type).

QoS - PCC
PCRF/PCEF

PCC - Policy and Charging Control architecture

LTE QoS Framework
 The traffic running between a particular client

application and a service can be differentiated into
separate service data flows (SDFs)
 SDFs mapped to the same bearer receive a
common QoS treatment

LTE bearer
 A bearer is assigned a scalar value referred

to as a QoS class identifier (QCI)
 Guaranteed bit rate (GBR)
 Non-guaranteed bit rate (non-GBR)
 A non-GBR bearer is referred to as the default bearer,
which is also used to establish IP connectivity, similar
to the initial SF in WiMAX
58

QoS attributes
 QoS class identifier (QCI)
 A scalar representing a set of packet forwarding
treatments
 Allocation and retention priority (ARP)
 A parameter used by call admission control and overload
control
 Maximum bit rate (MBR)
 Guaranteed bit rate (GBE)
 Aggregate MBR (AMBR)
 The total amount of bit rate of a group of non-GBR
bearers
59

LTE standardized QCI characteristics
60

Buffer Status Reporting
 The buffer status reporting mechanism informs the

UL packet scheduler about the amount of buffered
data at the UE
 A periodic BSR trigger does not cause a service request
(SR) transmission from the UE
 Otherwise, the SR is transmitted via a random access
procedure
 Short format can be used to report on one radio bearer group
 Long format one can be used for four groups
61

OCS Online Charging
System
Online Charging
Functions
MSC CAP
Account Balance
SGSN CAP Management
Function
Rc
Account Recharging
Rr
P-GW / PCEF Ro Session Server
Based
Charging
Function
WLAN Ro
IMS Gateway
IMS CSCF ISC Ro
Function Charging Operator's
Ga Gateway Bo Post- Processing
Function System
IMS AS Ro
IMS MRFC Ro
Sy PCRF
MMS Relay /
Ro
Server Event
Based Rating Function
Charging
GMLC Ro Function
Re
Tariff
MBMS Server Ro Info
PoC Server Ro
SMS Node Ro

IMS

Converged network
BT – 21cn

The Dream Carrier Network
HD TV Business, Voice/Video
Telephony Voice
Services TVoD, VoD ERP gateway
Business
Video Video Services
Source Source
Business
Access Carrier
Network
Mobile
Access Residential
Internet
Triple-Play
Access
Networks
The Dream Carrier Network

- All traffic converges into one network
- Connectivity to Services, Applications, Other Sites, The Internet
- With the necessary Quality of Service and Security
NGN Layered Architecture
NGN Planes Planes and functions
Application Plane Application Plane enables the provisioning of

services and provides the control and logic for the
Value Added Service Creation
execution of services
Control Plane Control Plane controls the elements of the network,

establishes and clears media connections
Management Plane
Basic control service
Transport Plane is responsible for the transport of

Transport
Plane media and signaling messages
Packet Based Transport
Management Plane covers network management
ensuring service fulfillment, service assurance
and billing
Access Networks
Access Networks connect customer networks or
terminals with the components of the NGN
network and aggregate the dedicated traffic type

IMS Architecture
Services plane Application Application Application

(Application Layer) Server Server Server
Session Control Plane Session Control Centralized

(Session and DB Layer) Databases
DB
Media Control Plane

(Media Control Media Control
& Gateway Layer) & Gateways
Network Plane
(Access and Transport)
Wireline Wireless 2G/3G PSTN
Broadband Broadband Mobile
Res./ Enterprise

IMS components
and protocols

IMS Network Elements
Home Subscriber Server Application Servers

• Centralized DB Push-to-talk•
Media Resource Function Controller
Pooling of Media servers (e.g. conference)•
• HLR successor Instant messaging•
• User profile Telephony AS•
• Filter criteria (sent to S-CSCF) 3rd party or IMS Vendor•
• Which applications
• Which conditions Home Network
UA/UE
SIP
DNS AS
AS P-CSCF
ENUM
HSS AS Media Gateway
Diameter Control Function
SIP Interfaces to PSTN/PLMN by•
Converting SIP <-> ISUP •
SIP SIP MRFC
UA/UE P-CSCF I-CSCF S-CSCF Interworking RTP to circuit •
SIP / Ut H.248 control of MGW •
MS MS
SIP
SIP
SIP
SIP
PCRF BGCF MGCF
ISUP
Call Session SIP
H.248 SS7
Control Function
SIP registration • RTP TDM PSTN
SIP session setup• MGW
Proxy CSCF Serving CSCF

Visited Registrar•
1st contact point for UA•
Network Session control•
QoS•
Application Interface•
Routes to S-CSCF•
Interrogating CSCF
Entry point for incoming calls• Breakout Gateway Control Function
Determines S-CSCF for Subscribers• Selects network (MGCF or other BGCF)•
Hides network topology• in which PSTN/ PLMN breakout is to occur
69
3GPP Reference Model
HLR/AuC* C SMS-GMSC
MSC EIR SMS-SC
TE MT GERAN HSS* SMS-IWMSC
R Um
Gb, Iu Rx+ (Rx/Gq)
Gr
Gs Gf PCRF AF
Gd Gx+ (Go/Gx)
Gc Gmb BM-SC
Iu Gi Gi
Gn/Gp PDN
TE MT UTRAN SGSN GGSN
R Uu Mb
Gn Ga Billing Ga
System* GyMb IMS-
SGSN MRFP MGW
OCS* Wi
UE Gm CGF*
P-CSCF CSCF
Mw
HLR/A Cx Dx
CDF uC* HSS* SLF
D/Gr Wx
WfWf
Intranet/ Dw
Wd
3GPP AAA 3GPP AAA
Internet OCS*
Wa Proxy Server
Wa Wo Wy
Wm
WLAN WLAN Access Wg
Network WAG PDG
UE Ww Wp Note: * Elements duplicated for picture
Wn Wz layout purposes only, they belong to the
same logical entity in the architecture
Wu Billing
Traffic and signalling CGF* baseline
System*
Signalling ** is a reference point currently missing

An Example of an IMS Call
Network X Network Y
AS
AS
S-CSCF
S-CSCF
HSS
HSS I-CSCF
P-CSCF
P-CSCF
GGSN UMTS
Packet
Core
DSL/Cable Modem
SGSN
DSLAM/CMTS
RNC
User B
User A

IMS Service Routing – the IFCs
• In comparison to IETF SIP Routing
Home B
HSS IMS AS HSS IMS AS
Home A
7 2
1 5 9 where the originator of SIP request may
6 8 specify a preferred path in the Route
S-CSCF I-CSCF S-CSCF
header, in IMS the P-CSCF removes
this path and ensures that IMS SIP
Routing is followed.
4 10
• SIP requests in IMS architecture are
Visited B
always routed to the Home S-CSCF, in
Visited A
both the originating and terminating

P-CSCF P-CSCF network.
• The S-CSCF uses subscriber’s
Service Profile (downloaded during
3 11 registration), to link-in the SIP AS’
which will process the SIP request.
• The Initial Filter Criteria (IFC) within
the Subscriber Profile provide a simple
service logic to decide which AS shall
be linked-in. These rules are of static
IMS Service Routing = Service Profile nature i.e. they do not change on a
based Routing frequent basis.

Filter Criteria (FC)
 A Filter Criteria triggers one or more SPTs
 Send the request to one specific AS
 Application Server Subscription Information: the set of Filter
Criteria stored in a service profile of a user
73

<IMSSubscription>
<PrivateID>IMPI1@homedomain.com</PrivateID> ^1
<ServiceProfile> 1~n
<PublicIdentity> 1~n
<BarringIndication>1</BarringIndication> ^1
<Identity> sip:IMPU1@homedomain.com </Identity> ^1
</PublicIdentity>
<InitialFilterCriteria> 0~n
”” <Priority>0</Priority> ^1
<TriggerPoint> 0~1
<ConditionTypeCNF>1</ConditionTypeCNF> ^1
<SPI> 1~n
<ConditionNegated>0</ConditionNegated>
<Group>0</Group>
<Method>INVITE</Method>
</SPI>
<SPI>
<Group>0</Group>
<Method>MESSAGE</Method>
</SPI>
<SPI>
<Group>1</Group>
<SIPHeader>
<Header>From</Header>
<Content>”joe”</Content>
</SIPHeader>
</SPI>
</TriggerPoint>
<ApplicationServer> ^1
<ServerName>sip:AS1@homedomain.com</ServerName> ^1
<DefaultHandling>0</DefaultHandling> ^1
</ApplicationServer>
</InitialFilterCriteria> 74
</ServiceProfile>
</IMSSubscription>
Application Triggering Architecture
Application Server
Service Logic
Service Platform Trigger Points
HSS
SIP Interface
iFC sFC SIP
S-CSCF
S
SIP Filter Criteria SIP
P
T

Service Orchestration Model
SIP-AS SIP-AS SIP-AS
HSS S-CSCF
SIP-AS SIP-AS SIP-AS

I-CSCF
HSS S-CSCF
• The application server decides whether to remain

I-CSCF
linked-in for the whole session by adding its
address to the Record-Route SIP header.
• Application Servers are unaware of the existence
of other AS', and whether these will be linked-in. • If during call handling procedure an AS retargets
• No service or session state will be passed the SIP request by changing the Request URI,
between application servers unless they use subsequent filter analysis in the S-CSCF is stopped
proprietary extensions i.e. are co-designed. and the S-CSCF forwards the request towards the
new target without linking-in the other AS’ specified
• Response messages are routed to the AS’s in the by IFC.
reverse order

SCIM vs. Service Broker
Camel
AS AS OSA AS Services
AS AS AS AS
OSA API CAP
SCIM OSA SCS IM SSF

Service Broker Service Broker
ISC MAP
ISC ISC Sh Si
Cx
Sh S-CSCF HSS S-CSCF
• The Service Capability Interaction Manager • The Service Broker architecture has been
(SCIM) orchestrates service delivery among introduced as WI in IMS Release 8.
application servers. • The objective is to provide a coherent and
• Underspecified in TS 23.002, the SCIM has consistent IP multimedia service experience
become a sort of “magic box” that would solve when multiple applications are invoked.
all issues related to service orchestration. • The work is handled by 3GPP SA2
• Possible types of SCIM: (Architecture) group in TR 23.810. So far, just
the some high level deployment scenarios
• AS Internal SCIM (figure above) and some uses cases have been defined.
• SIP Broker SCIM / Service Broker SCIM • Can be centralised, distributed or hybrid (as
• Legacy SCIM in the figure above).

Real-time allocation of network resources
1. User requests mobile video

service, which is directed to
the policy engine
2. Policy engine intelligently IMS Service Complex
interacts with network to Service Request
reserve bandwidth
Policies
3. Video delivered to mobile
user with assured quality Video Stream
Access IP Network
GGSN/
PDSN RCEP
Policy and QoS requests handled by a Policy Decision Function

SIP and SDP

SIP Philosophy
• Internet Standard
• IETF - http://www.ietf.org
• Reuse Internet addressing (URLs, DNS, proxies)
• Utilizes rich Internet feature set
• Reuse HTTP coding
• Text based
• Makes no assumptions about underlying protocol:
• TCP, UDP, X.25, frame, ATM, etc.
 Support of multicast

SIP Architecture
• A signaling protocol
 The setup, modification, and tear-down of multimedia sessions
• SIP + SDP
 Describe the session characteristics
• Separate signaling and media streams

SIP Network Entities
 Clients
 User agent clients
 Application programs sending SIP requests
 Servers
 Responds to clients’ requests
 Clients and servers may be in the same
platform
 Proxy
 Acts as both clients and servers

SIP end devices
• User Agent (user application)

• UA Client (originates calls)
• UA Server (listens for incoming calls)
• Types of UAs:
• Softphone, hardphones, webphones
• Messaging clients
• Automat: PSTN gateways, media servers
(voicemail)

Four types of servers
 A user agent server

 Accept SIP requests and contacts the user
 The user responds → an SIP response
 A SIP device
 E.g., an SIP-enabled telephone
 A registrar
 Accepts SIP REGISTER requests
 Indicating the user is at a particular address
 Typically combined with a proxy or redirect server
 Proxy server
 Redirect server

Proxy servers
 Handle requests or forward requests to other servers
 Can be used for call forwarding

Redirect servers
 Map the destination address to zero or more new addresses
 Do not initiate any SIP requests

SIP Call Establishment
 It (is) was simple
 A number of interim responses

SIP Headers
• Via contains the address at which the originator is expecting to receive responses to this request.
• To contains a display name and a SIP URI towards which the request was originally directed.
• Display names are described in RFC 2822
• From also contains a display name and a SIP URI that indicate the originator of the request.
The From also contains a tag parameter which is used for identification purposes.
• Call-ID contains a globally unique identifier for this call.
• CSeq or Command Sequence contains an integer and a method name. The CSeq number is
incremented for each new request within a dialog and is a traditional sequence number.
• Contact contains a SIP URI that represents a direct route to the originator usually composed of
a username at a fully qualified domain name (FQDN). While an FQDN is preferred, many end
systems do not have registered domain names, so IP addresses are permitted. The Contact
header field tells other elements where to send future requests.
• Max-Forwards serves to limit the number of hops a request can make on the way to its
destination. It consists of an integer that is decremented by one at each hop.
• Content-Type contains a description of the message body.
• Content-Length contains an octet (byte) count of the message body.
* Mandatory

SDP Messages
v= (protocol version) Mandatory
o= (owner/creator and session identifier). Mandatory
s= (session name) Mandatory
t= (time the session is active) Mandatory
i=* (session information)
u=* (URI of description)
e=* (email address)
p=* (phone number)
c=* (connection information - not required if included in all media)
b=* (bandwidth information)
z=* (time zone adjustments)
k=* (encryption key)
a=* (zero or more session attribute lines)
r=* (zero or more repeat times)Media description
m= (media name and transport address) Mandatory
i=* (media title)
c=* (connection information - optional if included at session-level)
b=* (bandwidth information)
a=* (zero or more media attribute lines)
Normal SIP Invite
INVITE sip:01150259917040@67.135.76.4 SIP/2.0
Via: SIP/2.0/UDP 69.7.163.154:5060;branch=z9hG4bK400fc6e6
From: "8069664170" <sip:8069664170@69.7.163.154>;tag=as42e2ecf6
To: <sip:01150259917040@67.135.76.4>
Contact: <sip:8069664170@69.7.163.154>
Call-ID: 2485823e63b290b47c042f20764d990a@69.7.163.154
CSeq: 102 INVITE
User-Agent: MatrixSwitch
Date: Thu, 22 Dec 2005 18:38:28 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Content-Type: application/sdp
Content-Length: 268
v=0
o=root 14040 14040 IN IP4 69.7.163.154
s=session
c=IN IP4 69.7.163.154
t=0 0
m=audio 26784 RTP/AVP 0 8 18 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=fmtp:18 annexb=no - - - -
Breakdown of the Invite Message – INVITE Request
INVITE sip:01150259917040@67.135.76.4 SIP/2.0

To: <sip:01150259917040@67.135.76.4>
Contact: <sip:8069664170@69.7.163.154>
Call-ID: 2485823e63b290b47c042f20764d990a@69.7.163.154
CSeq: 102 INVITE Called Number Destination (Qwest) IP
Date: Thu, 22 Dec 2005 18:38:28 GMT
Signaling Address
Content-Length: 268
v=0
o=root 14040 14040 IN IP4 69.7.163.154
s=session
c=IN IP4 69.7.163.154
t=0 0
m=audio 26784 RTP/AVP 0 8 18 101
a=rtpmap:18 G729/8000
a=fmtp:101 0-16
Request Method

Breakdown of the Invite Message – Via Header
INVITE sip:01150259917040@67.135.76.4 SIP/2.0
To: <sip:01150259917040@67.135.76.4>
Contact: <sip:8069664170@69.7.163.154>
Call-ID: 2485823e63b290b47c042f20764d990a@69.7.163.154
CSeq: 102 INVITE
User-Agent: MatrixSwitch Signaling Port
Date: Thu, 22 Dec 2005 18:38:28 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER Number of the
Content-Length: 268
Source IP Address
v=0
o=root 14040 14040 IN IP4 69.7.163.154
s=session
c=IN IP4 69.7.163.154
t=0 0
m=audio 26784 RTP/AVP 0 8 18 101
Source IP Address
a=rtpmap:18 G729/8000
a=fmtp:101 0-16
The Via Header is used for

Via Header translation rules and Session
Agent matches.
This is a
Mandatory
Header
Breakdown of the Invite Message – From Header
INVITE sip:01150259917040@67.135.76.4 SIP/2.0
To: <sip:01150259917040@67.135.76.4>
Contact: <sip:8069664170@69.7.163.154>
Call-ID: 2485823e63b290b47c042f20764d990a@69.7.163.154
CSeq: 102 INVITE
Date: Thu, 22 Dec 2005 18:38:28 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER From Address
Content-Length: 268
This is used to make a
v=0 Maps to the ISUP
o=root 14040 14040 IN IP4 69.7.163.154
match in the Local-
s=session Generic Name Policy.
c=IN IP4 69.7.163.154
t=0 0
m=audio 26784 RTP/AVP 0 8 18 101
Maps to the ISUP
a=rtpmap:18 G729/8000 Calling Party Number
a=fmtp:101 0-16
From Header
This is a
Mandatory
Header

Breakdown of the Invite Message – To Header
INVITE sip:01150259917040@67.135.76.4 SIP/2.0
To: <sip:01150259917040@67.135.76.4>
Contact: <sip:8069664170@69.7.163.154>
Call-ID: 2485823e63b290b47c042f20764d990a@69.7.163.154
CSeq: 102 INVITE
Date: Thu, 22 Dec 2005 18:38:28 GMT
Destination Number
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER Destination (Qwest)
Content-Length: 268 IP Signaling
v=0
Address
o=root 14040 14040 IN IP4 69.7.163.154
s=session
c=IN IP4 69.7.163.154
t=0 0
m=audio 26784 RTP/AVP 0 8 18 101
a=rtpmap:18 G729/8000
a=fmtp:101 0-16
To Header
This is a
Mandatory
Header

Breakdown of the Invite Message – Contact Header
INVITE sip:01150259917040@67.135.76.4 SIP/2.0
To: <sip:01150259917040@67.135.76.4>
Contact: <sip:8069664170@69.7.163.154>
Call-ID: 2485823e63b290b47c042f20764d990a@69.7.163.154
CSeq: 102 INVITE
Date: Thu, 22 Dec 2005 18:38:28 GMT
Content-Type: application/sdp Contact Address
Content-Length: 268
v=0
This is used to
o=root 14040 14040 IN IP4 69.7.163.154
s=session
send the reply
c=IN IP4 69.7.163.154 back to the sender.
t=0 0
m=audio 26784 RTP/AVP 0 8 18 101
a=rtpmap:18 G729/8000
a=fmtp:101 0-16
Contact Header

Breakdown of the Invite Message – Call-ID Header
INVITE sip:01150259917040@67.135.76.4 SIP/2.0
To: <sip:01150259917040@67.135.76.4>
Contact: <sip:8069664170@69.7.163.154>
Call-ID: 2485823e63b290b47c042f20764d990a@69.7.163.154
CSeq: 102 INVITE
Date: Thu, 22 Dec 2005 18:38:28 GMT
Content-Length: 268
v=0
o=root 14040 14040 IN IP4 69.7.163.154
s=session
c=IN IP4 69.7.163.154 Call-ID Header
t=0 0
m=audio 26784 RTP/AVP 0 8 18 101
This is a Mandatory
a=rtpmap:18 G729/8000
Header
a=fmtp:101 0-16

Breakdown of the Invite Message – CSeq Header
INVITE sip:01150259917040@67.135.76.4 SIP/2.0
To: <sip:01150259917040@67.135.76.4>
Contact: <sip:8069664170@69.7.163.154>
Call-ID: 2485823e63b290b47c042f20764d990a@69.7.163.154
CSeq: 102 INVITE
Date: Thu, 22 Dec 2005 18:38:28 GMT
Content-Length: 268
v=0
o=root 14040 14040 IN IP4 69.7.163.154
s=session
c=IN IP4 69.7.163.154
t=0 0
m=audio 26784 RTP/AVP 0 8 18 101
a=rtpmap:18 G729/8000
a=fmtp:101 0-16
Command Sequence
Header
This is a Mandatory
Header

Breakdown of the Invite Message – User-Agent Header
INVITE sip:01150259917040@67.135.76.4 SIP/2.0
To: <sip:01150259917040@67.135.76.4>
Contact: <sip:8069664170@69.7.163.154>
Call-ID: 2485823e63b290b47c042f20764d990a@69.7.163.154
CSeq: 102 INVITE
Date: Thu, 22 Dec 2005 18:38:28 GMT
Content-Length: 268
v=0
o=root 14040 14040 IN IP4 69.7.163.154
s=session
c=IN IP4 69.7.163.154
t=0 0
m=audio 26784 RTP/AVP 0 8 18 101
a=rtpmap:18 G729/8000
a=fmtp:101 0-16
User-Agent
Header

Breakdown of the Invite Message – Date Header
INVITE sip:01150259917040@67.135.76.4 SIP/2.0
To: <sip:01150259917040@67.135.76.4>
Contact: <sip:8069664170@69.7.163.154>
Call-ID: 2485823e63b290b47c042f20764d990a@69.7.163.154
CSeq: 102 INVITE
Date: Thu, 22 Dec 2005 18:38:28 GMT
Content-Length: 268
v=0
o=root 14040 14040 IN IP4 69.7.163.154
s=session
c=IN IP4 69.7.163.154
t=0 0
m=audio 26784 RTP/AVP 0 8 18 101
a=rtpmap:18 G729/8000
a=fmtp:101 0-16
Date
Header

Breakdown of the Invite Message – Allow Header
INVITE sip:01150259917040@67.135.76.4 SIP/2.0
To: <sip:01150259917040@67.135.76.4>
Contact: <sip:8069664170@69.7.163.154>
Call-ID: 2485823e63b290b47c042f20764d990a@69.7.163.154
CSeq: 102 INVITE
Date: Thu, 22 Dec 2005 18:38:28 GMT
Content-Length: 268
v=0
o=root 14040 14040 IN IP4 69.7.163.154
s=session
c=IN IP4 69.7.163.154
t=0 0
m=audio 26784 RTP/AVP 0 8 18 101
a=rtpmap:18 G729/8000
a=fmtp:101 0-16
Allow
Header

Breakdown of the Invite Message – Content-Type Header
INVITE sip:01150259917040@67.135.76.4 SIP/2.0
To: <sip:01150259917040@67.135.76.4>
Contact: <sip:8069664170@69.7.163.154>
Call-ID: 2485823e63b290b47c042f20764d990a@69.7.163.154
CSeq: 102 INVITE
Date: Thu, 22 Dec 2005 18:38:28 GMT
Content-Length: 268
v=0
o=root 14040 14040 IN IP4 69.7.163.154
s=session
c=IN IP4 69.7.163.154
t=0 0
m=audio 26784 RTP/AVP 0 8 18 101
a=rtpmap:8 PCMA/8000 Content-Type
a=rtpmap:18 G729/8000
Header
a=fmtp:101 0-16
a=fmtp:18 annexb=no - - - - This is a
Mandatory
Header

Breakdown of the Invite Message – Content-Length Header
INVITE sip:01150259917040@67.135.76.4 SIP/2.0
To: <sip:01150259917040@67.135.76.4>
Contact: <sip:8069664170@69.7.163.154>
Call-ID: 2485823e63b290b47c042f20764d990a@69.7.163.154
CSeq: 102 INVITE
Date: Thu, 22 Dec 2005 18:38:28 GMT
Content-Length: 268
v=0
o=root 14040 14040 IN IP4 69.7.163.154
s=session
c=IN IP4 69.7.163.154
t=0 0
m=audio 26784 RTP/AVP 0 8 18 101
a=rtpmap:8 PCMA/8000 Content-Length
a=rtpmap:18 G729/8000
Header
a=fmtp:101 0-16

Breakdown of the Invite Message – SDP Messages
INVITE sip:01150259917040@67.135.76.4 SIP/2.0

To: <sip:01150259917040@67.135.76.4>
Contact: <sip:8069664170@69.7.163.154>
Call-ID: 2485823e63b290b47c042f20764d990a@69.7.163.154
CSeq: 102 INVITE
Date: Thu, 22 Dec 2005 18:38:28 GMT
Content-Length: 268
v=0
o=root 14040 14040 IN IP4 69.7.163.154
s=session
c=IN IP4 69.7.163.154
t=0 0
m=audio 26784 RTP/AVP 0 8 18 101
This is the SDP
information within
a=rtpmap:18 G729/8000 the Invite
a=fmtp:101 0-16

Breakdown of the Invite Message – SDP Messages
INVITE sip:01150259917040@67.135.76.4 SIP/2.0

To: <sip:01150259917040@67.135.76.4>
Contact: <sip:8069664170@69.7.163.154>
Call-ID: 2485823e63b290b47c042f20764d990a@69.7.163.154
CSeq: 102 INVITE
Date: Thu, 22 Dec 2005 18:38:28 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER Protocol Version Mandatory
Content-Length: 268
v=0 Owner Mandatory

o=root 14040 14040 IN IP4 69.7.163.154
s=session Session Name Mandatory
c=IN IP4 69.7.163.154 IP address for RTP
t=0 0
m=audio 26784 RTP/AVP 0 8 18 101 Time the session is
a=rtpmap:0 PCMU/8000 active Mandatory
a=rtpmap:18 G729/8000
a=fmtp:101 0-16

Breakdown of the Invite Message – SDP Media Message
INVITE sip:01150259917040@67.135.76.4 SIP/2.0

To: <sip:01150259917040@67.135.76.4>
Contact: <sip:8069664170@69.7.163.154>
Call-ID: 2485823e63b290b47c042f20764d990a@69.7.163.154
CSeq: 102 INVITE
Date: Thu, 22 Dec 2005 18:38:28 GMT m=Media Name
Content-Type: application/sdp Mandatory
Content-Length: 268
Port for
v=0
RTP
o=root 14040 14040 IN IP4 69.7.163.154
s=session
c=IN IP4 69.7.163.154
t=0 0
m=audio 26784 RTP/AVP 0 8 18 101
a=rtpmap:18 G729/8000
a=fmtp:101 0-16
101 = Telephone Event
18 = G.729
8 = G.711 ALaw
0 = G.711 MuLaw

Breakdown of the Invite Message – SDP Media Attributes
INVITE sip:01150259917040@67.135.76.4 SIP/2.0
To: <sip:01150259917040@67.135.76.4>
Contact: <sip:8069664170@69.7.163.154>
Call-ID: 2485823e63b290b47c042f20764d990a@69.7.163.154
CSeq: 102 INVITE
Date: Thu, 22 Dec 2005 18:38:28 GMT
Content-Length: 268
v=0
o=root 14040 14040 IN IP4 69.7.163.154
s=session
c=IN IP4 69.7.163.154 Codecs
t=0 0
18 = G.729
m=audio 26784 RTP/AVP 0 8 18 101
a=rtpmap:0 PCMU/8000 8 = G.711 ALaw
a=rtpmap:8 PCMA/8000 0 = G.711 MuLaw
a=rtpmap:18 G729/8000
DTMF via RFC 2833 is shown as a
a=fmtp:101 0-16
Telephone Event (101) with values 0-16
This is how G.729A (without silence
suppression) is designated

Example of an Invite With Caller ID Blocked
INVITE sip:2128507797@67.130.192.6:5060 SIP/2.0 Called Number
f:Anonymous
<sip:PrivateNumber@localhost1>;tag=38fb29dc743e09a87fa0f40ce1e92906 Generic Name
t:<sip:2128507797@localhost2>
i:3dd342b75e489191fc70a4d658ded835-43ba8cf2@67.133.234.161 No Calling Party Number will be
CSeq:19718 INVITE present in the ISUP IAM
v:SIP/2.0/UDP
67.133.234.161:5060;branch=z9hG4bK844bec9bcb061c035deaefe92fe1007e-0
Max-Forwards:70
Allow:INVITE,BYE,ACK,CANCEL,PRACK,REFER,OPTIONS,REGISTER,NOTIFY
c:application/sdp
Remote-Party-ID: <sip:6099448955@192.168.201.25>;party=calling;id-
type=subscriber;privacy=full
P-Asserted-Identity: sip:6099448955@192.168.201.25 DOES NOT MAP TO CHARGE
Privacy: id; user NUMBER (CGN)
Anonymity: uri
Proxy-Require:privacy
m:<sip:0-c0a8c94b13c419202d5d@67.133.234.161:5060;transport=udp>
l:124
v=0
o=- 108600 10860000 IN IP4 67.133.234.140
s=-
c=IN IP4 67.133.234.140
t=0 0
m=audio 53016 RTP/AVP 0 8
a=ptime:20

Example of G.711
INVITE sip:2125332600@67.130.192.6:5060 SIP/2.0
f:"Kevin Hyden"<sip:6142591566@67.130.192.6:5060>;tag=f0af9415bfb610da4ba208f2cf39fe8e
m:<sip:0-c0a8c94a13c419202d5d@67.133.234.161:5060;transport=udp>
t:<sip:2125332600@67.130.192.6:5060>
i:9a22036f405d74b3853c437f3f3a598f-43ba8745@67.133.234.161
CSeq:45023 INVITE
v:SIP/2.0/UDP 67.133.234.161:5060;branch=z9hG4bKcee1d96ac551c44bc1efe13065f6ff3a-0
Max-Forwards:70
Allow:INVITE,BYE,ACK,CANCEL,PRACK,REFER,OPTIONS,REGISTER,NOTIFY
c:application/sdp
Remote-Party-ID: <sip:6142591566@192.168.201.23>;party=calling;id-type=subscriber;privacy=off
Anonymity: uri
Proxy-Require:privacy
l:124
v=0
o=- 132000 13200000 IN IP4 67.133.234.140
s=-
c=IN IP4 67.133.234.140
t=0 0 G.711 a-Law (PCMU)
m=audio 40294 RTP/AVP 0 8
a=ptime:20 G.711 Mu-Law (PCMU)
Packet Size (this not codec dependent)

Note that the Packet Size is not always specified,
and is defaulted to 20ms unless otherwise noted.

SIP Registrar
SIP registrar keeps track of

users’ whereabouts.
Location Database This registration example
establishes presence of
Jiri @ 195.37.78.173
user with address jiri@iptel.org

for one hour and binds this
REGISTER sip:iptel.org SIP/2.0
#2
From: sip:jiri@iptel.org
address to user’s current
To: sip:jiri@iptel.org location 195.37.78.173.
Contact: sip:195.37.78.173 #1
Expires: 3600
#3 SIP/2.0 200 OK
SIP Registrar
(domain iptel.org)
Basic SIP Call-Flow (Proxy Mode)
SIP Proxy looks up next hops for requests
to served users in location database and
forwards the requests there.
Location Database
#0
jiri@195.37.78.173
DNS SRV Query ? iptel.org #2 #3
Reply: IP Address of iptel.org SIP Server
INVITE sip:jiri@195.37.78.173
jiri
INVITE sip:jiri@iptel.org From: sip:Caller@sip.com;tag=12
From: sip:Caller@sip.com;tag=12 To: sip: jiri@iptel.org #4
To: sip: jiri@iptel.org #1 Call-ID: 345678@sip.com
Call-ID: 345678@sip.com
OK 200 OK 200 #5
#6
From: sip:Caller@sip.com;tag=12 From: sip:Caller@sip.com;tag=12
To: sip: jiri@iptel.org;tag=34 Proxy To: sip: jiri@iptel.org;tag=34
Call-ID: 345678@sip.com Call-ID: 345678@sip.com
#7 ACK sip:jiri@195.37.78.173
Caller@sip.com sip:jiri@195.37.78.173
Media streams #8
Ability to Try Multiple Destinations:
Forking
 A proxy may fork a request to multiple destinations either in parallel (“reach me
everywhere”) or serially (“forward no reply”).
 A proxy can cancel pending parallel searches after a successful response is
received.
 A proxy can iterate through redirection responses (“recursive forking”).
 The first “OK” is taken.
#1 INVITE
#2 Trying
#3 INVITE
#4 Ringing
#5 CANCEL
#6 OK
#7 INVITE

Stateful vs. Stateless
Proxy Operational Mode (cont.)
 SIP Proxies may operate either in stateful or stateless

mode; which of the modes is used depends on
implementation or configuration.
 stateless mode:
 Usage: good for heavy-load scenarios -- works well for example if
they act as application-layer load distributors.
 Behavior:
 proxies just receive messages, perform routing logic, send messages
out and forget anything they knew;
 they should cache results of SIP routing logic as it is not able to
distinguish between retransmissions and new requests -- and would
result in new execution of SIP routing logic for every retransmission

Stateful vs. Stateless
Proxy Operational Mode (cont.)
 stateful mode:
 Usage: good for implementing some services (e.g.,
“forward on no reply”)
 Behavior:
 proxies maintain state during entire transaction; they remember
outgoing requests as well as incoming requests that generated
them until transaction is over; they do not keep state during the
whole call
 a forking proxy should be stateful
 reduce retransmission time by acting on behalf of sender closer
to destination

SIP (RFC3261) Methods
• INVITE - initiates sessions

 session description included in message body
 re-INVITEs used to change session state
• ACK - confirms session establishment
 can only be used with INVITE
• CANCEL - cancels a pending INVITE
• BYE - terminates sessions
• REGISTER - binds a permanent address to
current location; may convey user data (CPL
scripts)
• OPTIONS - capability inquiry
SIP Extension Methods
• SUBSCRIBE instant messaging and

presence
• NOTIFY (RFC3265, RFC3428)
• MESSAGE
• REFER call transfer (RFC3515)
• PRACK provisional reliable responses
acknowledgement (RFC3262)
• INFO mid-call signaling (RFC 2976)

SIP Response Codes
• Borrowed from HTTP: xyz explanatory text
• Receivers need to understand response class (“x”)
• x80 and higher codes avoid conflicts with future
HTTP response codes
• 1yz Informational
 100 Trying
 180 Ringing (ringing tone played locally)
 181 Call is Being Forwarded
• 2yz Success
 200 ok
• 3yz Redirection
 300 Multiple Choices
 301 Moved Permanently
 302 Moved Temporarily

SIP Response Codes (cont.)
 4yz Client error
 400 Bad Request
 401 Unauthorized
 482 Loop Detected
 486 Busy Here
 5yz Server failure
 500 Server Internal Error
 6yz Global Failure
 600 Busy Everywhere

“One number” service

Bearer opening
HSS
Ro
OCS AS
Ro Ro
Gy
Ro SIP
MME PCRF
Sy CSCF
SIP
SGW PGW
PDN
S1-U S5 PCEF
Layer 1-3 bearer Signaling (run on layer 3 bearer) Application bearer

LTE PCRF roaming information
Roaming border
Visited network Home network
MME PCRF PCRF HSS
1 Attach
2 Authenticate 2 Authenticate
3 Update Location
Subscriber Data 4
Policy exchange 5


BSC
PCRF
2G Gxc
Gb S16
SGSN Gx
NodeB RNC Rx+
S4 SGW PGW
3G Iu
S5 SGi
S12
S3
eNodeB S1-U MME
LTE Operator
S1-MME S11 Gr/S6d
Services
S6b Internet
S6a Corporate
S10
Non Services
3GPP
S2c
AAA
ePDG
IP Access
HSS
Access
Control plane
User plane
7 levels of handoff
 eNB
 MME
 Inter LTE
 Inter 3GPP
 Full IP
 CSFB
 Untrusted Wi-Fi
122

LTE Tracking Area
 Tracking area (TA) is similar to Location/routing area in 2G/3G

 Tracking Area Identity = MCC (Mobile Country Code), MNC (Mobile Network
Code) and TAC (Tracking Area Code)
 When UE is in Idle, MME knows UE location with Tracking Area accuracy
MME
Tracking area 2
Tracking area 1
Tracking area update

PS Handover
124

CSFB
125

126

127

128

LTE Access: VoLTE user to VoLTE user
Terminating IMS network Originating IMS network
IMS HSS(IMS)/DRA
SCC-AS TAS
TAS SCC-AS
ENUM
9
8 5 3 2
7
6 4
S/I-CSCF S/I-CSCF
SBC w P-CSCF SBC w P-CSCF

13
HSS(EPC)
11 12
PDN GW/GGSN PDN GW/GGSN
PCR PCR
PCEF PCEF
F F
S-GW S-GW
SAE GW SAE GW
13
EP MME EP MME
C C
E-UTRAN E-UTRAN
13 7
10 1
B A
Page
Copyright © 129
2011 LOGTEL Min Lu
1. 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.
2. 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
3. Based on iFC for UE A, TAS is invoked as the 2nd AS for originating processing. S-CSCF sends SIP INVITE to
TAS for originating feature processing.
4. 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 the record showing the same home domain.
5. S-CSCF routes the call to the I-CSCF.I-CSCF performs HSS-IMS query. If a S-CSCF is already assigned to the UE B,
HSS-IMS will return S-CSCF for UE B. If not, I-CSCF will select S-CSCF for UE A’s terminating processing based on S-
CSCF’s capability set.
6. I-CSCF sends SIP INVITE to UE B’s S-CSCF.
7. Based on B party’s terminating iFC, S-CSCF sends SIP INVITE to TAS to execute any terminating features.
8. After TAS finishes the processing and sends calls back to S-CSCF, S-CSCF determines that SCC-AS needs to be accessed
as the 2nd /last AS for UE A. S-CSCF sends SIP INVITE to SCC-AS
9. SCC-AS performs T-ADS by querying HSS-CSPS and determines that UE B is in LTE P3 VOIP capable RAN and PS bearer
needs to be used.
10. SCC-AS sends the call back to the S-CSCF. S-CSCF determines that all terminating processing for UE B has finished, it
starts to terminate the call to the terminating party. Based on the registered Contact information (in initial/Re
registration message), S-CSCF sends SIP INVITE to the P-CSCF/SBC.P-CSCF send SIP INVITE to the terminating UE B
based on registered Contact information.
11. After UE B is answered, dedicate bearer is set up at B party EPC/RAN network. At the same time UE B’s P-CSCF
subscribes the EPC dedicate bearer events from UE B’s PCRF.
12. And the dedicate bearer is also set up at A party EPC/RAN network. At the same time UE A’s P-CSCF subscribes the EPC
dedicate bearer events from UE A’s PCRF.
13. the bearer path is set up between UE A and SBC for A, SBC for B and UE B
(Note: detailed call flows for EPC bearer set up is not included here)
Page
Copyright © 130
2011 LOGTEL
131

Why do we need VoLTE ?
Why not use VoIP solution like Skype ?

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

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

Telstra decided not use VoLTE

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

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

TAS/MMTel features

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

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

HIGH LEVEL CALL FLOW

Terminating IMS network Originating IMS network
IMS HSS(IMS)/DRA
SCC-AS TAS
TAS SCC-AS
ENUM
9
8 5 3 2
7
6 4
S/I-CSCF S/I-CSCF
SBC w P-CSCF SBC w P-CSCF

13
HSS(EPC)
11 12
PDN GW/GGSN PDN GW/GGSN
PCR PCR
PCEF PCEF
F F
S-GW S-GW
SAE GW SAE GW
13
EP MME EP MME
C C
E-UTRAN E-UTRAN
13 7
10 1
B A
Page
Copyright © 141
2011 LOGTEL Min Lu
1. 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.
2. 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
3. Based on iFC for UE A, TAS is invoked as the 2nd AS for originating processing. S-CSCF sends SIP INVITE to
TAS for originating feature processing.
4. 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 the record showing the same home domain.
5. S-CSCF routes the call to the I-CSCF.I-CSCF performs HSS-IMS query. If a S-CSCF is already assigned to the UE B,
HSS-IMS will return S-CSCF for UE B. If not, I-CSCF will select S-CSCF for UE A’s terminating processing based on S-
CSCF’s capability set.
6. I-CSCF sends SIP INVITE to UE B’s S-CSCF.
7. Based on B party’s terminating iFC, S-CSCF sends SIP INVITE to TAS to execute any terminating features.
8. After TAS finishes the processing and sends calls back to S-CSCF, S-CSCF determines that SCC-AS needs to be accessed
as the 2nd /last AS for UE A. S-CSCF sends SIP INVITE to SCC-AS
9. SCC-AS performs T-ADS by querying HSS-CSPS and determines that UE B is in LTE P3 VOIP capable RAN and PS bearer
needs to be used.
10. SCC-AS sends the call back to the S-CSCF. S-CSCF determines that all terminating processing for UE B has finished, it
starts to terminate the call to the terminating party. Based on the registered Contact information (in initial/Re
registration message), S-CSCF sends SIP INVITE to the P-CSCF/SBC.P-CSCF send SIP INVITE to the terminating UE B
based on registered Contact information.
11. After UE B is answered, dedicate bearer is set up at B party EPC/RAN network. At the same time UE B’s P-CSCF
subscribes the EPC dedicate bearer events from UE B’s PCRF.
12. And the dedicate bearer is also set up at A party EPC/RAN network. At the same time UE A’s P-CSCF subscribes the EPC
dedicate bearer events from UE A’s PCRF.
13. the bearer path is set up between UE A and SBC for A, SBC for B and UE B
(Note: detailed call flows for EPC bearer set up is not included here)
Page
Copyright © 142
2011 LOGTEL
PSTN
Basic TAS call flow – LTE Originating
This call flow follows the standard IMS origina
SCC-AS is the first application server bein
IMS
TAS SCC-AS
4
ENUM 3 2
5
CSG* S/I-CSCF
6
BGCF
SBC w P-CSCF HSS(IMS)
7
HSS(CSPS)
7
PDN GW/GGSN
PCR
PCEF
PSTN F
GMSC
S-GW
SAE GW
B
3G
3G CSG*
MSC/VLR
EPC MME SGSN
E-UTRAN UTRAN
3G
7 A
1
AT&T Proprietary (Restricted- LTE)

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

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

1. P-CSCF  S-CSCF : Invite

SDP

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

3. S-CSCF  SCC AS : Invite

4 . SCC AS  S-CSCF : 100 trying

Diameter usage

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

Mapping SS7 protocols to SIP/Diameter

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

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

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

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

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

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

other contributors
 Future drivers include Service
Delivery Applications

Diameter Protocol

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

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

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

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

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

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

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 ]

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

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

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

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

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

Diameter applications

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

Credit Control Application Overview
• Specified in RFC 4006

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

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

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

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

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

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

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

Cost-Information

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

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

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

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

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

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

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

Optimizing Diameter Network architecture
using Diameter Relay Agents
A fully meshed Diameter network is regarded as quite complex in administration and configuration •
To optimize the network architecture Diameter Relay Agents are introduced •
Diameter Relay Agent is used to forward protocol messages to appropriate Diameter •
Server.
DRA plays similar role as STP in SS7 networks •

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

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

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

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

Diameter in EPC/EPS

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

PCC in an IMS Voice Call

EPS initial attach

message format definitions
<AVP> indicates a mandatory AVP with a fixed position in

the message.
{AVP} indicates a mandatory AVP in the message.
[AVP] indicates an optional AVP in the message.
*AVP indicates that multiple occurrences of an AVP is
possible.

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

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

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

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

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

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

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

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

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

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

Schematic sequence flow

Simple Originating and terminating flow

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

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

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

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

How to decide if it’s ORIG or TERM

Originating State Machine Flow (INVITE request)

Originating State Machine Flow (INVITE response)

Terminating State Machine Flow (INVITE request)

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

Diameter AVPs
Step ACR TYPE ACR Details
Number
27 TAS Carol: Role-Of-Node = Terminating
START_RECORD Calling-Party-Address=Alice/Called-Party-Address=Carol
SIP-Request-Timestamp = Timestamp of incoming INVITE ( step 11)
SIP-Response-Timestamp = Timestamp of incoming INVITE response (step 24)
Start-Cell-Site-Identifier= Carol’s P-ANI (step 24) , received in 200 OK INVITE
Regular mobile terminated ACR event
34 TAS Bob(Orig): Role-Of-Node =Originating
Associated-Party-Address=Bob
Subscriber-Role = Originating
Service-Type=CDIV
Service-Mode=CFU
SIP-Request-Timestamp = Timestamp of incoming INVITE ( step 6)
Start-Cell-Site-Identifier = Bob’s P-ANI (step 6)
38 TAS Bob(Term): Role-Of-Node = Terminating
Associated-Party-Address=Bob
Subscriber-Role = Terminating
Service-Type=CDIV
Service-Mode=CFU
Start-Cell-Site-Identifier= P-ANI sent in the outgoing INVITE (step 3)
SIP-Request-Timestamp = Timestamp of outgoing INVITE ( step 3)
54.1 TAS Bob(Term): Role-Of-Node = Terminating
STOP_RECORD Calling-Party-Address=Alice/Called-Party-Address=Carol
Subscriber-Role = Terminating
Service-Type=CDIV
Service-Mode=CFU
Cause-Code=0
Copyright © 2011 LOGTEL Disconnection-Direction=originating 231
MRF – SIP message flow

Conference
1. INVITE Bob [Call-id=1,To-Tag=1,From-Tag=1] 2. INVITE
3. re-INVITE (Hold) 4. re-INVITE(Hold)
TAS1
(Alice Orig) 16. re-INVITE
17. BYE MRF’s SDP
14. REFER sip:conf=AliceMSISDN@TAS1

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

Create Conference Leg (Join Carol)

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

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

ADC (as 3rd party VAS AS)

SMS over LTE
 SMS over a generic IP CAN

 SMS as VAS AS
 SMS as SIP Message method
 SMS as MSRP
 RCS

SMS over a generic IP CAN
SME
SC
CGF / CDF SMS-GMSC / SMS-IWMSC C / S6c HSS
Rf E / Gd / Gdd / SGd
Sh
OCS Ro IP-SM-GW
J / S6c
ISC
IMS Core
S-CSCF Cx
Mw
P-CSCF
Gm
UE

Rich Communications - GSMA
Don’t lose out to OTT – stay competitive and innovate with APIs

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

Rich Communication Suite
end-user values for Individuals
› Easy, simple and fun

text/voice/video communication
› Enriched address book with

photos and taglines, always up-
to-date by on-line sync
› The promise of RCS –

one global community, reach all
friends no matter what operator
or device they use
“I want to interact and

communicate easily with my close ›“I want to share my everyday
friends no matter were I am or experience with my friends”
what device I use”
RCS Evolution

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

Standalone messaging
 RCS 5.1 standalone messaging includes support for the
following specific features:
 supporting both text and multi-media messaging, it does not make
a distinction between text and multimedia messages.
 message delivery includes both 1-to-1 and group messaging
including support for “reply-to-all” functionality.
 Imposes no limitations on the message size and media types.
However, the maximum message size can be controlled by Service
Providers.
 Capabilities for both broadband access and mobile access terminals.
 It can store a message exchange both in the local and central
message storages and to present a conversational view of the
exchanged messages.
 Provides message delivery and display notifications.

What happen when no reception device is connoted ?
Messaging interworking with SMS

messaging interworking with MMS

Start a Group Chat from the Chat application

Roaming

Roaming in LTE
• Roaming for home routed traffic is the similar scenario used at the moment in 3G data networks
• Subscriber traffic is routed from Visited PLMN to Home PLMN via the GRX provider
• The S8 interface is the reference point between visited S-GW and home P-GW
• S8-GTP is a natural choice for roaming as many operators are using GTP for roaming in 2G/3G


BSC
PCRF
2G Gxc
Gb S16
SGSN Gx
NodeB RNC Rx+
S4 SGW PGW
3G Iu
S5 SGi
S12
S3
eNodeB S1-U MME
LTE Operator
S1-MME S11 Gr/S6d
Services
S6b Internet
S6a Corporate
S10
Non Services
3GPP
S2c
AAA
ePDG
IP Access
HSS
Access
Control plane
User plane
LTE roaming overview
1. Attachment procedure
2. Authentication procedure
3. Update location procedure
4. Subscriber data retrieval procedure
5. Policy exchange
Roaming border
Visited network Home network
MME PCRF PCRF HSS
1 Attach
2 Authenticate 2 Authenticate
3 Update Location
Subscriber Data 4
Policy exchange 5

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

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

MME HSS
• S9 Diameter interface (TS 23.203)

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

PCRF PCRF

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

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

Handoff

LTE to 3G Handover: Part 1
3, 4 & 5 executed in parallel
Originating IMS network

IMS
TAS SCC-AS
S/I-CSCF Target CS
Terminating CS R-URI: STN-SR

IWF SBC w P-CSCF
3
network
4
3G
PDN GW/GGSN CSG
PCR
3G PCEF GMSC
F
3G MSC/VLR/CS
SGSN G S-GW
3G MSC/VLR
SAE GW
MME
UTRAN 3G EP 2
C UTRAN
1 STN-SR
E-UTRAN
5
B
Page
Copyright © 257
2011 LOGTEL
LTE to 3G Handover: Part 2

IMS
TAS SCC-AS
7 X
6
S/I-CSCF
Target CS
Terminating CS IWF SBC w P-CSCF
network
8
9
X X
PDN GW/GGSN
3G
CSG
PCR
3G PCEF GMSC
F
3G MSC/VLR/CS
SGSN G S-GW
3G MSC/VLR
SAE GW
MME
UTRAN 3G EP
C UTRAN
E-UTRAN
Page
Copyright © 258
2011 LOGTEL
LTE to 3G Handover: End State

IMS
TAS SCC-AS
S/I-CSCF
Target CS
Terminating CS IWF SBC w P-CSCF
network
3G
PDN GW/GGSN CSG
PCR
3G PCEF GMSC
F
3G MSC/VLR/CS
SGSN G S-GW
3G MSC/VLR
SAE GW
MME
UTRAN 3G EP
C UTRAN
E-UTRAN
Page
Copyright © 259
2011 LOGTEL
0. VoLTE UE A on LTE is on active session with 3G UE B. There is an ongoing IP Bearer between the UE
A and the remote end UE B. The media is anchored at ATGW .
1. UE A sends the measurement reports to E-UTRAN and the source E-UTRAN decides to trigger a
SRVCC handover to CS access.
2. MME sends session transfer request to MSC. MSC acknowledges the request.
3. The MSC Server initiates Access Transfer message SIP INVITE to ATCF.
4. The ATCF receives the Access Transfer message (SIP INVITE) and correlates the transferred session
using the C-MSISDN. The ATCF sends an Access Transfer response (SIP 200 OK) to the MSC Server
with media information allocated by the ATGW during session establish procedure. The media path is
switched to CS when receiving SDP information.MSC responds the 200OK by sending ACK.
5. In parallel with step 3, at RAN site, UE is switched to 3G RAN and attached to MSC.
6. Then the ATCF re-establishes the communication with the SCC AS and updates the SCC AS that the
transfer has taken place by sending a new SIP INVITE request to ATU-STI for SCC-AS.
7. The Access Transfer Update creates a new dialogue between the ATCF and SCC AS. The SCC AS
correlates the new dialog with the remote dialog (e.g., using the C-MSISDN). As there is no update in
the session description, no remote end update will be performed. The SCC AS sends 200OK
confirmation response to the ATCF. ATCF responds with ACK.
8. In parallel, after SCC-AS finishes access transfer for the active voice call, the Source Access Leg is
released by SCC-AS sending SIP BYE message towards the PS access leg.
9. The previous PS connection between UE and SBC is torn down.
10.After MSC finishes access transfer procedure, MSC performs Location Update to HLR and download
subscriber profile to VLR.
At the end, the bearer is set up between UE A to MSC (CS), MSC to SBC/ATCF/ATGW(PS),
SBC/ATCF/ATGW tp remote IWF to remote MSC/CSG(PS), and MSC to UE (CS).

Advance issues

TCP or UDP
 UDP is faster
 TCP is reliable
 Why not use always UDP ?

 We have PRAC for reliability

HSS usage
 There will be only one (?) !

Law Enforcement
 The Communications Assistance for Law Enforcement Act
(CALEA) is a United States wiretapping law passed in 1994,
during the presidency of Bill Clinton.

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

Inter-MME Tracking
Area Update

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

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

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

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


BSC
PCRF
2G Gxc
Gb S16
SGSN Gx
NodeB RNC Rx+
S4 SGW PGW
3G Iu
S5 SGi
S12
S3
eNodeB S1-U MME
LTE Operator
S1-MME S11 Gr/S6d
Services
S6b Internet
S6a Corporate
S10
Non Services
3GPP
S2c
AAA
ePDG
IP Access
HSS
Access
Control plane
User plane
None 3GPP access architecture
HSS
SWx
S6a PCRF
Gxc Rx
Gx
Operator's IP
SGi Services
3GPP Serving PDN (e.g. IMS, PSS
Access Gateway Gateway etc.)
S5
S6b
S2b
Gxb
SWm
S2a ePDG 3GPP AAA
Server
HPLMN SWn
Non-3GPP Gxa
Networks SWu
Trusted Untrusted
Non-3GPP IP Non-3GPP IP
Access Access SWa
STa
UE

Day 3

OFDMA Flexibility
 With OFDMA the user allocation is flexible

 Can change from frame to frame
 Multiple allocations for several applications
 Allocation changes
 In WiMAX every 5 ms
 In LTE every 1 ms
Burst Burst
time
Burst
OFDMA frequency
frequency

So, What will be the bandwidth ?

Dynamic and Semi-Persistent Scheduling

Home/Single Network
IMS Core
MMTel / RCS
Ut Ut Application Mr’ MRF
Servers
Sh
I
S Mr
Cx
C
HSS Cx P-CSCF Mw I/S-CSCF

Sh
Rx
S6a
DRA ENUM
UE S6a
Rx
IMS UA
Gx
ENUM
PCRF
Server
LTE-Uu
Gx
MME
UE S1-MME
LTE-Uu Sec- S11
IMS UA GW
S1-U
eNodeB S-GW S5 P-GW SGi

Roaming
IMS Core
Ut MMTel / RCS
Application Mr’ MRF
Ut
Servers
Sh
I
Mr
Cx S
C
HSS P-CSCF Mw I/S-CSCF Mx IBCF/TrGw
S6a Sh
S6a Cx
ENUM
Rx Rx
Ici/Izi
SGi
UE MME H-PCRF S9 Diameter Agent ENUM
ENUM
LTE-Uu Server IPX
IMS UA S1-MME Gx
Sec- S11
GW Gx
S1-U ENUM
eNodeB S-GW S5 P-GW
Ici/Izi
HPLMN
Diameter App ID = 0
VPLMN
IBCF/TRGW
S6a
Diameter Agent
S9
Mx
P-CSCF/
MME V-PCRF Rx Rx IMS-ALG/
IMS-AGW
S1-MME Gx
Sec- S11
UE GW Gx
LTE-Uu
IMS UA
S1-U
S-GW S5 P-GW SGi
eNodeB

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

Diameter For LTE - Architecture, Signaling and Call Scenarios PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Diameter For LTE - Architecture, Signaling and Call Scenarios PDF

Uploaded by

Copyright:

Available Formats

Diameter

By: Samuel Dratwa

Copyright © 2011 LOGTEL 2

This documentation is protected by Copyright © 2011 LOGTEL,

Copyright © 2011 LOGTEL 3

Copyright © 2011 LOGTEL 4

 Diameter base protocol

Copyright © 2011 LOGTEL 5

It’s all about

 Addressing the trend of declining ARPU

Feature Phones Smartphones Super Phones Tablet Computers

Copyright © 2011 LOGTEL 8

NGN Planes Planes and functions

Application Plane Application Plane enables the provisioning of

Control Plane Control Plane controls the elements of the network,

Transport Plane is responsible for the transport of

Copyright © 2011 LOGTEL

Copyright © 2011 LOGTEL 10

Copyright © 2011 LOGTEL 11

Copyright © 2011 LOGTEL 13

Voice Calls Path

Data Calls Path

Copyright © 2011 LOGTEL

Copyright © 2011 LOGTEL 16

Copyright © 2011 LOGTEL 18

Flat, scalable IP based Flat Architecture: 2 nodes architecture

Flat, IP based architecture

Access Core Control

MME IMS HSS

Copyright © 2011 LOGTEL

Copyright © 2011 LOGTEL

PDCP PDCP GTP-U GTP-U GTP-U/GRE GTP-U/GRE

UDP UDP UDP UDP

UE eNB MME S-GW P-GW

NAS NAS GTP-Cv2 GTP-Cv2 GTP-Cv2

PDCP PDCP SCTP SCTP UDP UDP UDP

Uu S1-MME S11 S5/S8

Copyright © 2011 LOGTEL

MSC SGSN SGW MME

Iu-CS Iu-PS S1-U S1-MME

RAN Evolved Packet Core

Copyright © 2011 LOGTEL 24

 It is the only network element defined as part of

Copyright © 2011 LOGTEL 25

 Both WiMAX and LTE use:

Copyright © 2011 LOGTEL 26

Copyright © 2011 LOGTEL 27

 OFDM: Orthogonal Frequency Division Multiplexing

Copyright © 2011 LOGTEL 28

 Received OFDM Signal

Copyright © 2011 LOGTEL 29

 In OFDM one user occupies all subcarriers

Copyright © 2011 LOGTEL 30

 With OFDMA the user allocation is flexible

Copyright © 2011 LOGTEL 31

Copyright © 2011 LOGTEL 32

Copyright © 2011 LOGTEL 33

Copyright © 2011 LOGTEL 34

• Receiver combines the received signals and

Copyright © 2011 LOGTEL 36

 Multiple antennas at both the base station and terminal can

Copyright © 2011 LOGTEL

Copyright © 2011 LOGTEL 38