diameter conceps

7/29/2019 Diameter Conceps

1/14

Diameter and SBBC Concepts

Camiant Inc


2/14

Base Protocol and Applications

DIAMETER Base Protocol

NASREQ

Applications

EAP

Applications

Mobile IP V4

Applications

Credit

Control

Applications

Other 3GPP

Cx, Dx, Sh,

Ro, Rf

The Diameter Base Protocol provides

reliable transport and delivery of

messages

The Base Protocol must be used along

with an application

DIAMETER Base Commands


3/14

DIAMETER Base Protocol

NASREQ

Applications

EAP

Applications

Mobile IP V4

Applications

Credit

Control

Applications

Tx

Application

Other 3GPP

Cx, Dx, Sh,

Ro, Rf

Ty

Application

3. Credit-Control Messages

This section defines new Diameter message Command-Code values that

MUST be supported by all Diameter implementations that conform to

this specification. The Command Codes are as follows:

Command-Name Abbrev. Code Reference

---------------------------------------------------------------------------------

Credit-Control-Request CCR 272 3.1

Credit-Control-Answer CCA 272 3.2

3. NAS Messages

This section defines the Diameter message Command-Code [BASE] values

that MUST be supported by all Diameter implementations conforming to

this specification. The Command Codes are as follows:

Command-Name Abbrev. Code Reference

---------------------------------------------------------------------------------------------------------

AA-Request AAR 265 3.1

AA-Answer AAA 265 3.2

Tx, and Ty Applications

In addition to the AVPs defined within the clause 6.4, the Diameter AVPs from the Diameter base application(RFC 3588 [2]) are reused within the Diameter messages of the Tx application. The support of AVPs from the

Diameter Network Access Server Application (NASREQ) [3] is not required from Diameter implementations that

conform to the present document.

Accounting functionality (Accounting Session State Machine, related command codes and AVPs) is not used in the

Tx interface.

The Tx application is defined as an IETF vendor specific Diameter application with application ID 16777222, wherethe vendor is 3GPP. The vendor identifier assigned by IANA to 3GPP (http://www.iana.org/assignments/enterprise-

numbers) is 10415.

Need to define an application ID For Ty


4/14

Diameter Node Types

Some PCRF functions can be associated with a home network for the purpose of representing subscription and homeased application function information. Some PCRF functions can be associated with the network of the Access

Gateway for purpose of enforcement of local policy. In roaming situations where the Access Gateway is located in aisited network, there may be both home and serving network PCRFs. In this case the serving network PCRF may

act as a proxy or redirect agent for communications to/from the Access Gateway and the home PCRF (also see

section 5.3.5).

5.1.2.3 Application Function

Diameter Peers

Diameter peers, the set of Diameter nodes with which a

given Diameter node will directly communicate, may bestatically configured or may be dynamically discovered

using SLPv2 or DNS SRV RRs.

Capabilities Exchange

The first Diameter messages exchanged between two

Diameter peers, after establishing the transport

connection, are Capabilities Exchange messages. A

Capabilities Exchange message carries a peer's identity

and its capabilities (protocol version number, supportedDiameter applications, etc.). A Diameter node only

transmits commands to peers that have advertised

support for the Diameter application associated with the

given command.


5/14

Typical Diameter Exchanges

A Capabilities Exchange message carries a peer's

identity and its capabilities (protocol version number,

supported Diameter applications, etc.). A Diameter node

only transmits commands to peers that have advertised

support for the Diameter application associated with thegiven command.

Discovery via DNS or Static Configuration

Application-level heartbeat messages are used to

proactively detect transport failures. These messages

are sent periodically when a peer connection is idle and

when a timely response has not been received for an

outstanding request.

There are two types of messages, Requests and

Answers.. Every answer message carries a Result-Code

AVP. The data value of the Result-Code AVP is an integer

code indicating whether a particular request was

completed successfully or whether an error occurred.

Peer Discovery

Peer Discovery

Capabilities

Exchange Request

Capabilities

Exchange AnswerCapabilities

Exchange Answer

Capabilities

Exchange Request

Device Watchdog

Request

Device Watchdog

Answer

Request

Answer

Answer

Request

Client ServerAgent


6/14

Diameter Transport and Session-ID

A Diameter message pertaining to a specific user session includes a Session-Id AVP, the value of

which is constant throughout the life of a session. The value of the Session-Id AVP is a globally

and eternally unique text string, intended to uniquely identify a user session without reference to

any other information.

The Diameter client initiating the session creates the Session-Id. The Session-Id begins with the

originator's Diameter Identity string and is followed by any sequence guaranteeing both topological

and temporal uniqueness.

TCP or SCTP Transport

Each Diameter process running on a host generates, or is configured with, a Diameter Identity.

The Diameter Identity is a URI-syntax string with substrings representing the host's fully qualified

domain name (FQDN), one of the ports used to listen for incoming connections, the transport usedto listen for incoming connections (i.e. TCP or SCTP), the AAA protocol (i.e. Diameter), and the

transport security (i.e. none or TLS).

The following is an example of a valid Diameter host identity:

aaa://host.abc.com:1812;transport=tcp;protocol=diameter

PCRF

SessionsSessions

TCP or SCTP TransportAF AGW


7/14

SBBC Applications


8/14

SBBC Authorization on Initial Attach

Peer Discovery

Peer Discovery


Request

Capabilities

Exchange AnswerCapabilities

Exchange Answer


Request

Device Watchdog

Request

Device Watchdog

Answer

CC Request

CCAnswer

CC Answer

CC Request

Client ServerAgent

On MS Attach a Diameter Session is established between the AGW and the

PCRF on behalf of the MS (With Diameter CCR and CCA messages using Ty

Application ID with CCR Request Type set to INITIAL REQUEST)

This Session lasts for as long as the Mobile is attached and is used for alltransaction between the AGW and PCRF including:

Authorization of Bear establishment/modification

Notification of Loss or release of bearer

AND all transactions between the PCRF and the AGW including

PCRF initiated Push for QoS

PCRF initiated removal of resources

PCRF initiated Opening or Closing of Gates

AGW PCRFoptional


9/14

5.2.1 Ty Diameter messages

Ty Messages are carried within the Diameter Application(s) described in the sub-clauses below. These Applications

are defined as vendor specific Diameter applications. The vendor identifier assigned by IANA to 3GPP is 10415.

The association between the PDS session and the Diameter Credit Control sessions shall be done in a one-to-one

asis (i.e. 1 PDS session = 1 DCC session), and each service instance shall map to a Diameter sub-session (i.e. 1

service instance = 1 DCC sub-session). The release of the last service instance shall be indicated by the release ofthe whole DCC session, whereas release of a single service instance, with others remaining, shall be indicated by the

release of the sub-session corresponding to that service instance.

Easy Applications

Simple Bearer Authorization at the PCRF

e.g. no IMS or AF present. (Note Changes to the

Diagram.) Each bearer uses a Diameter sub-session ID

How does the PCRF know that no AF initiated Push is

coming for this bearer?

Simple AF initiated Push of IP QoS

For example on a EV-DO Rel 0, PCRF pushes, IP

level Policing, Shaping, and/or Queueing commands

along with a classifier determined from the AF. Note

Changes to the Diagram. Each Push uses a Diameter

sub-session ID

How does the PCRF know that no MS initiated Pull

is coming for this session?


10/14

Push/ Pull Applications

Current

Network

SupportsPull e.g.

Rev A no

fallback

Handset

supports

pull

Application

Client

requestsPull

PDSN

allows Pull

PCRF

receives

Pull tomatch

Push

MS 1 X X X X YES

MS 2 X X X NO

MS 3 X X X NO

MS.n NO

Networks contain a varied mixture of

terminals and clients. It virtually

impossible to determine whether it is

reasonable to expect a for a given IPclassifier at a given time.

How does the PCRF know that no AF

initiated Push is coming for this

bearer?

How does the PCRF know that no MS

initiated Pull is coming for this

session?

How can the PCRF correlate the IP

Classifier from the AF with the TFT

from an MS initiated Bearer

initiation/modification

Subsequent AF sessions may use the

same bearer. i.e. AF and bearer session

tear down are currently not coordinated

AF MS MSPCRF PCRF PCRFAF AFMS

Push arrives at

PCRF before

Pull

Push arrives at

PCRF after PullPush arrives at

PCRF at the sametime as Pull

Push and pull for a given transaction can arrive at

different times. What timers would be needed?

Networks contain a varied mixture of

terminals and clients. It virtually

impossible to determine whether it is

reasonable to expect a for a given IPclassifier at a given time.


11/14

Independent Push/Pull Policy and Charging Rules

Diameter Session IDs created

at MS attach

TCP or SCTP Transport

MS 1

MS 2

Diameter Sub-Session IDs

created at bearer creation


created from AF Push

Diameter session Created at MS Attach

Independent Sub-sessions created for bearer creation and AF Push AF Push with Bearer Pull will use 2 Gates and the Policy Decision Rules are evaluated 2

times- once for the IP Push, and once for the Bearer Pull

IP QoS gates

can be used for application-level, access-network independent, admission control andcharging rules

can also push an IP-level enforcement envelope for bearers, e.g silver subscriber get 512 Kfor video streaming.

IP QoS primitive can include per subscriber, per flow policing, shaping, and queuing


created at bearer creation


created from AF Push


12/14

Independent Push/Pull Policy and Charging Rules

AF packets

Pi

Interface

Per subscriber R-P

interface with IP QoS

Subscriber

RABs

PCRF

AGW

DiameterSubsessions DiameterSubsessions

1

2

3

1

2

3

1

2

3

3 Subscriber running identical

applications from different

handsets, clients, and

locations

Application 2 has no AF.

PCRF and AGW have

separate policies and gates

for bearers and IP QoS..

IP QoS on R-P interface

represents application rules

e.g. Silver subscriber get512Kbs for Video

e.g. Subscriber 1 and 2 have

different IP QoS for

application 3

But IP QoS may be smaller or

greater than authorized RABs

PCRF and AGW may try to

correlate bearer and IP QoS

as part of the policy rules but

correlation is not required.

PCRF can use information on

bearers for admission control

of IP QoS and vice-versa


13/14

If Correlation of AF and Bearer are important, the operator can

impose application-level event sequencing i.e. client applicationlogic ensures that push arrives before pull or vice-versa

AF MSPCRF PCRF AFMS Push must arrive at PCRF

before Pull:

Push Policy:

If: IP_port is VIDEO and

subscriber-tier is VIDEO-

ENABLED

Then: Create gate

Else: Reject gate

Pull policy:

If Bearer_TFT is VIDEO

subscriber has IP_Gate

with port = VIDEO

Then: Create Gate

Else: Reject Gate

Push must arrive at PCRF

After Pull:

Pull policy:

If Bearer_TFT is for VIDEO

and subscriber-tier is

VIDEO-ENABLED

Then: Create Gate

Else: Reject Gate

Push Policy:

If: IP_port is for VIDEO and

subscriber has a Bearer_

Gate with port = VIDEO

Then: Create gate

Else: Reject gate

Application-level Event Sequencing

Subscriber must have

use an AF for Video

Subscriber must have a

Video Bearer to use AF


14/14

UE-1

1. INVITE

UE-2

2. INVITE

4. Auth Request3. 183 Progress

13. RAN QoS Request

14. Auth Request

Bearer

Establishment

Bearer

Establishment

9. PRACK10. PRACK

16. RAN QoS Resp

12. 200 OK (prack)

11. 200 OK (prack)

AF(P-CSCF)

PCRFAGW

8. 183 Progress (A1)

7. Auth Response

5. Re-Auth(create gates)

6. Re-Auth Resp

TxTy

15. Auth Resp

17. RAN QoS Request

20. RAN QoS Resp

18. Auth Request

19. Auth Resp

IP-QoS Gates

created (closed)

21. UPDATE22. UPDATE

24. 200 OK (update)23. 200 OK (update)

RAN-QoS Gates created

(opened)

RAN-QoS Gates created

(opened)

Client rings

(180 not shown)

Client answers25. 200 OK (invite)26. Auth Request

(Open Gates)

28. Re-Auth Resp

27. Re-Auth(open gates)

29. Auth Response

30. 200 OK (invite)31. ACK

32. ACK

IP-QoS Gates are opened

diameter conceps

Documents