05 FN4243XEN80GLA0 App Gx Rx Interface

7/23/2019 05 FN4243XEN80GLA0 App Gx Rx Interface

http://slidepdf.com/reader/full/05-fn4243xen80gla0-app-gx-rx-interface 1/72

Appendix - Gx and Rx Interface

FN4243XEN80GLA0 © Nokia Solutions and Networks 2015.

1

Contents

1 Diameter Base Protocol Overview 3

1.1

Basic Terms 4

1.2 Diameter Message Structure 8

1.3 Diameter Base Protocol Messages 12

1.4 AVP - Attribute-Value-Pair 16

1.5

Error Handling 21

2 Gx Interface 25

2.1 Basic Terms 26

2.2 Gx Protocol 28

2.3 Messages 28

2.4 Gx specific Experimental-Result-Code AVP values 37

2.5 Timers at Gx Interface 40

2.6 Gx specific Diameter AVPs 42

2.7 Signaling Flow over Gx Interface 45

3 Rx Interface 53

3.1 Basic Terms 54

3.2 Rx Protocol 56

3.3 Messages 56

3.4

Rx specific Experimental-Result-Code AVP values 69

3.5 Signaling Flow over Rx Interface 70





FN4243XEN80GLA0

© Nokia Solutions and Networks 2015.

2





3

1 Diameter Base Protocol Overview




FN4243XEN80GLA0


4

1.1 Basic Terms

The Diameter Base protocol is defined in RFC 3588. It is intended to provide an Authentication, Authorization and Accounting (AAA) framework for differentapplications. The Diameter Base protocol provides the minimum requirements

needed for an AAA protocol.

Main components of the Diameter Base protocol:

A Diameter Client is a device that performs access control. It generates Diametermessages to request authentication, authorization, and accounting services for the

user.

A Diameter server performs authentication and/or authorization of the user.

Generates answer message.

A Diameter node may act as a client for certain requests while acting as a server forothers.

Relay Agents are Diameter agents that accept requests and route messages toother Diameter nodes based on information found in the messages (e.g., Destination-Realm). Relays modify Diameter messages by inserting and removing routinginformation, but do not modify any other portion of a message.

In the example provided in Figure 1, peer connection A is established between theClient and its local Relay. Peer connection B is established between the Relay andthe Server. User session X is ranging from the Client via the Relay to the Server.

Proxy Agents are similarly to relays. They route Diameter messages using theDiameter Routing Table. However, they differ since they modify messages byimplementation of policy enforcement. Proxies maintain the state of their downstreampeers (e.g. access devices).

Redirect Agents do not relay messages, and only return an answer with theinformation necessary for Diameter agents to communicate directly. They do notmodify messages. Since redirect agents do not receive answer messages, theycannot maintain session state.

The Diameter Base protocol is a peer-to-peer protocol. Any node can initiate arequest.

A connection is a transport level connection between two peers, used to send andreceive Diameter messages.

A session is a logical concept at the application layer, and is shared between theDiameter Client and the Diameter Server. It is identified via the Session-Id AVP

(Attribute-Value-Pair). The Session-Id is globally unique and is meant to uniquelyidentify a user session without reference to any other information.





5

Request

Answer

User Session

Peer connection A Peer connection B

Request

Answer

RFC 3588

Client Relay Server

Diameter Base Protocol: basic terms

The Diameter Base protocol is a peer-to-peer protocol

Connection: transport level connection between two peers

Session: logical concept at the application layer; shared between the Client and the Server

Client: performs access control; generates Diameter messages to request

authentication, authorization, and accounting services for the user.

Server: performs authentication, authorization and accounting of the user; generate

Diameter answer message.

Relay Agent: accept requests and route messages to other Diameter

Fig. 1




FN4243XEN80GLA0


6

The life cycle of the session starts when the Diameter Client issues the first requestto the Server - AAR (Authentication-Authorization-Request). This request contains aSession-Id AVP, which is used in all subsequent messages. Diameter Server must

reply with AAA (Authentication-Authorization-Answer) message. A session is terminated by sending a STR (Session-Termination-Request) messageto the Diameter server, to notify it that the session is no longer active. The Diameterserver that receives a STR message must clean up all resources associated with this

Session-Id and send back a STA (Session-Termination-Answer). In this way, sessionis moved to the Idle State.

In order to provide well defined transport behavior, Diameter Base runs over reliabletransport (TCP, SCTP).

The Diameter Base protocol is designed to be extensible. Diameter Applications canextend the base protocol by:

adding new Diameter messagesadding new AVPs (attribute-value pairs) information element in a Diameter message

or

defying new AVP value for an existing AVP.

An AVP is used to carry protocol specific data.

Additionally, it is possible to modify specific procedure, like error handling orunrecognized information handling. Unless otherwise specified, the procedures areunmodified.

The reuse of existing AVP values, AVPs and Diameter applications is stronglyrecommended. Reuse simplifies standardization and implementation and avoids

potential interoperability issues. It is expected that command codes are reused; newcommand codes can only be created by IETF Consensus. In order to allocate a new AVP value, to create a new AVP or a new application, a request must be sent toIANA.

Each Diameter application must have Application Identifier, assigned by IANA. Thebase protocol does not require an Application Identifier since its support ismandatory. During the capabilities exchange, Diameter nodes inform their peers ofsupported Application. Furthermore, all Diameter messages contain an ApplicationIdentifier. In this context, a Diameter Application means a protocol.

Example:The Gq application

Application ID:16777222.Vendor is 3GPP and vendor identifier assigned by IANA to 3GPP is 10415.

The Gx application. Application ID:16777238.Vendor is 3GPP and vendor identifier assigned by IANA to 3GPP is 10415.





7

• Gq application: Application ID:16777222, 3GPP Gq

Vendor: 3GPP, vendor identifier: 10415

• Gx application: Application ID: is16777238, Policy and Charging Control .Vendor: 3GPP, vendor identifier: 10415

• Gy application:

Application ID:4, Diameter Charging Control Application (DCCA)Vendor: 3GPP, vendor identifier: 10415

• Rx application: Application ID:16777236Vendor: 3GPP, vendor identifier: 10415

Application Identifier

Fig. 2




FN4243XEN80GLA0


8

1.2 Diameter Message Structure

The communication between 2 Diameter Agents is done via message-exchange.Messages are always in pairs, one is a Command Code Request (from Client toServer), and the next is an Answer.

A Diameter Message consists of a Header (20 octets long), called the DiameterHeader , followed by a changeable number of AVPs. This message structure is the

same in all Diameter applications.

The Header is 20 octets long.

The Header is followed by one or more Attribute-Value-Pairs (AVPs). An AVP isused to encapsulate protocol-specific data. It is possible, for a new application, to

create a new AVP or define a new AVP value. Of course, new applications shouldattempt to reuse AVPs defined in existing applications always when possible.

In order to create a new AVP, a request must be sent to IANA, with a specification forthis AVP. The request must include the commands that would make use of this AVP.

Example:

Session-Id

Origin-Host

Origin-Realm

Result-Code





9

Diameter Header:

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Version | Message Length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| command flags | Command-Code |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Application-ID |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Hop-by-Hop Identifier |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| End-to-End Identifier |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

AVP1

AVP2. . . .

Diameter Message Structure

Fig. 3




FN4243XEN80GLA0


10

1.2.1 Diameter Header

Version

The Version field MUST be set to 1 to indicate Diameter Version 1

Message Length

The Message Length field is three octets and indicates the length of the Diametermessage including the header fields.

Command-Code

The Command-Code field is three octets, and is used to identify Diametercommands. Every Diameter message MUST contain a command code in its header's

Command-Code field, which is used to determine the action that is to be taken for aparticular message. Both the request and the answer for a given command share thesame command code.

Command Flags

The Command Flags field consists of eight bits.:

R P E T r r r r

R(equest) or REQ

If set, the message is a request. if cleared, the message is an answer.

P(roxiable) or PRXIf set, the message MAY be proxied, relayed or redirected. If cleared, themessage MUST be locally processed.

E(rror) or ERR

If set, the message contains a protocol error. This bit MUST NOT be set in therequest messages.

T(Potentially re-transmitted message)

This flag is set after a link failover procedure, to aid the removal of duplicaterequests. It is set when resending requests not yet acknowledged, as an

indication of a possible duplicate due to a link failure. This bit MUST be cleared

when sending a request for the first timer(eserved)

These flag bits are reserved for future use, and MUST be set to zero, and ignored

by the receiver.





11

Application-ID

The Application-ID is four octets and is used to identify a specific Diameter

Application (the meaning of application is protocol!) to which the message isapplicable. The application can be an authentication application, an accountingapplication or a vendor specific application.

There are standards-track application ids and vendor specific application ids. IANAhas assigned the range 0x00000001 to 0x00ffffff for standards-track applications; and0x01000000 - 0xfffffffe for vendor specific applications.

The following values are allocated for standard Applications:

- Diameter Common Messages: 0

- NASREQ: 1 [NASREQ]

- Mobile-IP: 2 [DIAMMIP]

- Diameter Base Accounting: 3

Some Identifiers for Vendor-Specific Application:

Gq protocol: the Application-Id 16777222, vendor is 3GPP (10415)

Gx protocol: the Application-Id=16777238, vendor is 3GPP (10415)

Gy protocol: the Application-Id=4, vendor is 3GPP (10415)

Hop-by-Hop Identifier

The Hop-by-Hop Identifier is an unsigned 32-bit integer field and aids in matchingrequests and replies. The sender of an Answer message must ensure that the Hop-

by-Hop Identifier field contains the same value that was found in the correspondingrequest. The Hop-by-Hop identifier is normally a monotonically increasing number,whose start value was randomly generated. An answer message that is received withan unknown Hop-by-Hop Identifier MUST be discarded.

End-to-End Identifier

The End-to-End Identifier is an unsigned 32-bit integer field and is used to detectduplicate messages. Senders of request messages MUST insert a unique identifieron each message. The same End-to-End identifier of the request is used in the

answer. Duplicate requests should cause the same answer to be transmitted.

Duplicate answer messages should be discarded.




FN4243XEN80GLA0


12

1.3 Diameter Base Protocol Messages

Every message must contain one Command Code and Command Flags. EachRequest/Answer pair gets the same Command Code value. According to the flagfield (R bit) the request or the answer is identified.

Error-Flag:

If set in an Answer message, the originating Request contained a

protocol error;

ERR

Request-Flag:

If set, the message is a Request

else, the message is an Answer

REQ

MeaningCmd Flag

282DPRDisconnect-Peer-Request

282DPADisconnect-Peer-Answer

275STASession-Termination-Answer

275STRSession-Termination-Request

258RAARe-Auth-Answer

258RARRe-Auth-Request

280DWADevice-Watchdog-Answer

280DWRDevice-Watchdog-Request

257CEACapabilities-Exchange-Answer

257CERCapabilities-Exchange-Requeest

271 ACA Accounting-Answer

271 ACR Accounting-Request

274 ASA Abort-Session-Answer

274 ASR Abort-Session-Request

CodeAbbreviationCommand-Name

Fig. 4





13

Example:

Device-Watchdog-Request (DWR) Command

The Device-Watchdog-Request (DWR) is sent to a peer when no traffic has beenexchanged between them. Upon detection of a transport failure, this message mustnot be sent.

Command Code 280;

REQ - set

Device-Watchdog-Answer (DWA) Command

DWA is sent as a response to the Device-Watchdog-Request message.

Command Code 280

Device-Watchdog-Request (DWR) Command

Message Format

<DWR> ::= < Diameter Header: 280, REQ >

{ Origin-Host }

{ Origin-Realm }

[ Origin-State-Id ]

Device-Watchdog-ANSWER (DWA) Command

Message Format

<DWA> ::= < Diameter Header: 280 >

{ Result-Code }

{ Origin-Host }

{ Origin-Realm }

[ Error-Message ]* [ Failed-AVP ]

[ Original-State-Id ]

Fig. 5




FN4243XEN80GLA0


14

1.3.1 Timers at Diameter Base protocol level

Watchdog timer

Watchdog timer is applicable for all the diameter interfaces defined in PCS-5000system. Timer is a configurable value (PCS_ServiceConfigParams, Gx-Interface, Gy-Interface…). The duration of the watchdog interval is in seconds. On expiry of the

timer, PCS-5000 sends a watchdog request to check the health of the diameterconnection.

Default value: 6 sec.

Range: 0-30 sec.

Watchdog Failure Handling

Diameter retries for 6 times before initiating any disconnect procedures. In case ofPCS-5000 failing to get DWA, then will initiate a Disconnect-peer-request towards theGGSN, if TCP connection exists. Otherwise, all the peer information will be deletedand PCS-5000 shifts back to the listening mode for new connections.





15

GWPCS-5000

DWR (Device-Watchdog-Request )

DWA (Device-Watchdog-Request Answer)

DWR/DWA handling

DWR(Device-Watchdog-Request )

On getting Watchdog Answer,Watchdog Timer is started


Fig. 6

GWPCS-5000



DWR/DWA failure handling


On getting Watchdog Answer,

Watchdog Timer is started

DPR (Disconnect-Peer-Request )

DPA (Disconnect-Peer-Answer)

In case of PCS-5000 failing to

get DWA and if TCP connection

exists, PCS-5000 will initiate a

Disconnect-peer-request

Fig. 7




FN4243XEN80GLA0


16

1.4 AVP - Attribute-Value-Pair

AVPs carry specific details for the request and reply. Some AVPs may be listed morethan once. AVP consists of a Header, called AVP Header, followed by AVP Data

AVP Header

AVP Header consists of:

AVP Code

AVP Length

AVP Flags

Vendor Id

AVP Code

The AVP Code, combined with the Vendor-Id field, identifies the attribute uniquely. AVP numbers 1 through 255 are reserved for backward compatibility with RADIUS,without setting the Vendor-Id field. AVP numbers 256 and above are used for

Diameter. They are allocated by IANA.

AVP Flags

The AVP Flags field informs the receiver how each attribute must be handled.

V - Vendor-Specific bit indicates whether the optional Vendor-ID field is present in

the AVP header. When set, the AVP Code belongs to the specific vendor codeaddress space.

M - Mandatory bit indicates that support of the AVP is required. If an AVP with the'M' bit set is received by a Diameter agent and either the AVP or its value isunrecognized, the message must be rejected.

AVPs with the 'M' bit cleared are informational only and a receiver that receives amessage with such an AVP that is not supported, or whose value is not supported,may simply ignore this AVP.

P- Protected bit indicates the need for encryption for end-to-end security.

r - Reserved bit, unused and should be set to 0.





17

AVP Length

The AVP Length field consists of three octets. It and indicates the number of octets inthis AVP including the AVP Code, AVP Length, AVP Flags, Vendor-ID field (if

present) and the AVP data. If a message is received with an invalid attribute length,the message should be rejected.

Vendor-ID

The Vendor-ID field is present if the 'V' bit is set in the AVP Flags field. The optionalfour-octet Vendor-ID field contains the IANA assigned value. Any vendor wishing toimplement a vendor-specific Diameter AVP MUST use his own Vendor-ID along with

his privately managed AVP address space.

AVP Header

Byte 1 2 3 4

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| AVP Code |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|V M P r r r r r| AVP Length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Vendor-ID (opt) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Data ...

Lenght of AVP Header: 8 bytes without Vendor-ID or

12 bytes with Vendor-ID

Fig. 8

.




FN4243XEN80GLA0


18

1.4.1 AVP Data Formats

The Data field is length of several octets and contains information specific to the

Attribute. The format and length of the Data field is determined by the AVP Code and AVP Length fields. The format of the Data field must be one of the base data types ora data type derived from the base data types.

Some Basic AVP Data Formats

OctetString

The data contains arbitrary data of variable length. AVP Values of this type that are

not a multiple of four-octets in length is followed by the necessary padding so that the

next AVP (if any) will start on a 32-bit boundary. Each AVP of type OctetString MUSTbe padded to align on a 32-bit boundary, while other AVP types align naturally. Anumber of zero-valued bytes are added to the end of the AVP Data field till a wordboundary is reached. The length of the padding is not reflected in the AVP Lengthfield.

Unsigned32

32 bit unsigned value. The AVP Length field must be set to 12 (16 if the 'V' bit isenabled).

Integer32

32 bit signed value, in network byte order. The AVP Length field must be set to 12

(16 if the 'V' bit is enabled).Grouped

The Data field is specified as a sequence of AVPs. Each of these AVPs is presentedwith their headers and AVP Data. The AVP Length field is set to 8 (12 if the 'V' bit is

enabled) plus the total length of all included AVPs, including their headers and AVPData. Thus the AVP length field of an AVP of type Grouped is always a multiple of 4.

It is possible to include an AVP with a Grouped type within a Grouped type, that is, tonest them. If any of the AVPs encapsulated within a Grouped AVP has the 'M'(mandatory) bit set, the Grouped AVP itself MUST also include the 'M' bit set.

Some Derived AVP Data Formats

UTF8String

The UTF8String format is derived from the OctetString AVP Base Format. This is ahuman readable string represented using the ISO/IEC IS 10646-1 character set,encoded as an OctetString using the UTF-8 [UFT8] transformation format describedin RFC 2279.





19

DiameterIdentity

The DiameterIdentity (DiamIdent) format is derived from the OctetString AVP BaseFormat. The DiameterIdentity value is used to uniquely identify a Diameter node for

purposes of duplicate connection and routing loop detection. The contents of thestring MUST be the FQDN of the Diameter node.

Enumerated

Enumerated is derived from the Integer32. For AVPs of type Enumerated anapplication may require a new value to communicate some service-specificinformation. In order to allocate a new AVP value, a request must be sent to IANA,

along with an explanation of the new AVP value.

IPFilterRule

The Address format is derived from the OctetString AVP Base Format. It represents,for example a 32-bit (IPv4) or 128-bit (IPv6) address, most significant octet first. Thefirst two octets of the Address AVP represent the AddressType, which contains an Address Family. The AddressType is used to discriminate the content and format ofthe remaining octets.

Some AVP Data Formats

Basic AVP Data Formats:

•OctetString

•Unsigned32

•Integer32

•Grouped

Derived AVP Data Formats

•UTF8String

•DiameterIdentity

•Enumerated

•IPFilterRule

Fig. 9




FN4243XEN80GLA0


20

Examples:

Auth-Application-Id

The Auth-Application-Id AVP (AVP Code 258) is of type Unsigned32 and is used inorder to advertise support of the Authentication and Authorization portion of anapplication

Auth-Application-Id (AppId) l:0xc (12 bytes) (12 padded bytes)AVP Code: Auth-Application-Id (258)AVP Flags: 0x40 (Mandatory)AVP Length: 12Application ID: 3GPP Gq 16777222 (0x01000006)

Origin-Host

The Origin-Host AVP (AVP Code 264) is of type DiameterIdentity, and MUST bepresent in all Diameter messages. This AVP identifies the endpoint that originatedthe Diameter message. Relay agents MUST NOT modify this AVP. The value of theOrigin-Host AVP is guaranteed to be unique within a single host.

Origin-Host (DiameterIdentity) l:0x29 (41 bytes) (44 padded bytes)AVP Code: Origin-Host (264)AVP Flags: 0x40 (Mandatory)AVP Length: 41

Identity: virtual.cscf1-imscore.imscore.ims

Session-Id

The Session-Id AVP (AVP Code 263) is of type UTF8String and is used to identify aspecific session. All messages pertaining to a specific session must include only oneSession-Id AVP and the same value must be used throughout the life of a session.The Session-Id must uniquely identify a user session without reference to any otherinformation. The Session-Id includes a mandatory portion and an implementation-defined portion.

The Session-Id is created by the Diameter application initiating the session, which inmost cases is done by the client.

Session-Id (UTF8String) l:0x49 (73 bytes) (76 padded bytes)AVP Code: Session-Id (263)AVP Flags: 0x40 (Mandatory)AVP Length: 73UTF8String:

ims2.umts.pcscf1;0;0;7b3527e1d3a45c6bfc3472e4cbac0cdd^IMS_PCSCF05





21

1.5 Error Handling

1.5.1 Result codes at Diameter Base protocolEvery response command in Diameter carries a Result-Code AVP. The receiver ofthe command can use this AVP in the message to check how the previous command

was processed.

Two different types of errors in Diameter protocol are possible:

protocol errors: occur at the base protocol level (e.g.:DIAMETER_UNABLE_TO_DELIVER

application errors: occur due to a problem with a function specified in a Diameterapplication (e.g.: DIAMETER_MISSING_AVP)

The Result-Code AVP (AVP Code 268) is of type Unsigned32 and indicates whethera particular request was completed successfully or whether an error occurred. AllDiameter answer messages must include one Result-Code AVP. A non-successful

Result-Code AVP contains a non 2xxx value.

Result-Code AVP values that are used to report protocol errors must only be present

in answer messages whose 'E' bit is set. Result-Code AVP is set to the appropriateprotocol error value.

Diameter provides the following classes of errors, all identified by the thousands digitin the decimal notation:

1xxx (Informational)

2xxx (Success)

3xxx (Protocol Errors)

4xxx (Transient Failures)

5xxx (Permanent Failure)




FN4243XEN80GLA0


22

Success

DIAMETER_SUCCESS 2001

DIAMETER_LIMITED_SUCCESS 2002

Protocol Errors

DIAMETER_COMMAND_UNSUPPORTED 3001

DIAMETER_UNABLE_TO_DELIVER 3002

DIAMETER_REALM_NOT_SERVED 3003

DIAMETER_TOO_BUSY 3004

DIAMETER_LOOP_DETECTED 3005

DIAMETER_REDIRECT_INDICATION 3006

DIAMETER_APPLICATION_UNSUPPORTED 3007

DIAMETER_INVALID_HDR_BITS 3008

DIAMETER_INVALID_AVP_BITS 3009

DIAMETER_UNKNOWN_PEER 3010

DIAMETER_COMMAND_UNSUPPORTED 3001

DIAMETER_INVALID_HDR_BITS 3008

DIAMETER_INVALID_AVP_BITS 3009

DIAMETER_UNKNOWN_PEER 3010

Transient Failures

DIAMETER_AUTHENTICATION_REJECTED 4001

DIAMETER_OUT_OF_SPACE 4002

ELECTION_LOST 4003

Permanent Failures

DIAMETER_AVP_UNSUPPORTED 5001

DIAMETER_UNKNOWN_SESSION_ID 5002

DIAMETER_AUTHORIZATION_REJECTED 5003

DIAMETER_INVALID_AVP_VALUE 5004

DIAMETER_MISSING_AVP 5005

DIAMETER_RESOURCES_EXCEEDED 5006

DIAMETER_CONTRADICTING_AVPS 5007

DIAMETER_AVP_NOT_ALLOWED 5008

DIAMETER_AVP_OCCURS_TOO_MANY_TIMES 5009

DIAMETER_NO_COMMON_APPLICATION 5010

DIAMETER_UNSUPPORTED_VERSION 5011

DIAMETER_UNABLE_TO_COMPLY 5012

DIAMETER_INVALID_BIT_IN_HEADER 5013

DIAMETER_INVALID_AVP_LENGTH 5014

DIAMETER_INVALID_MESSAGE_LENGTH 5015

DIAMETER_INVALID_AVP_BIT_COMBO 5016

DIAMETER_NO_COMMON_SECURITY 5017





23

1.5.2 Experimental-Result AVP

The Experimental-Result AVP (AVP Code 297) is of type Grouped. It indicates

whether a particular vendor-specific request was completed successfully or whetheran error occurred.

Experimental-Result ::= < AVP Header: 297 >

{ Vendor-Id }

{ Experimental-Result-Code }

The Vendor-Id AVP identifies the vendor responsible for the assignment of the resultcode which follows. All Diameter answer messages defined in vendor-specific

applications MUST include either one Result-Code AVP or one Experimental-Result

AVP.The Experimental-Result-Code AVP (AVP Code 298) is of type Unsigned32 andcontains a vendor-assigned value representing the result of processing the request.

It is recommended that vendor-specific result codes follow the same conventionsgiven for the Result-Code AVP regarding the different types of result codes and thehandling of errors (for non 2xxx values).




FN4243XEN80GLA0


24





25

2 Gx Interface




FN4243XEN80GLA0


26

2.1 Basic Terms

Gx reference pointThe Gx reference point is located between the Policy and Charging Rules Function(PCRF) and the Policy and Charging Enforcement Function (PCEF). The Gx

reference point is used for provisioning and removal of Policy and Charging Control(PCC) rules from the PCRF to the PCEF and the transmission of traffic plane eventsfrom the PCEF to the PCRF. The Gx reference point can be used for charging

control, policy control or both by applying AVPs relevant to the application.Gx reference point is specified in:

the stage 2 specifications, functional requirements:3GPP TS 23.203 - Policy and charging control architecture and

the stage 3 specifications, Technical specification:3GPP TS 29.212 - Policy and Charging Control over Gx interface

PCRFThe PCRF is a functional element that is responsible for policy control decision andflow based charging control.The PCC Rule decisions may be based on one or more of the following:

Information received from the AF via the Rx reference point, e.g. the session,media and subscriber related information.

Information obtained from the PCEF via the Gx reference point, e.g. IP-CAN

bearer attributes, request type and subscriber related information. Information obtained from the SPR via the Sp reference point, e.g. subscriber and

service related data.

Own PCRF pre-configured information.

The PCRF shall report events to the AF via the Rx reference point.The PCRF shall inform the PCEF through the use of PCC rules on the treatment ofeach service data flow that is under PCC control, in accordance with the PCRF policydecision.

PCEF

The PCEF is the functional element that performs policy enforcement and flow basedcharging functionalities. This function is located at the Gateway (e.g. GGSN in the

GPRS case). It provides control over the user plane traffic handling at the Gatewayand its QoS, and provides service data flow detection and counting as well as onlineand offline charging interactions.If requested by the PCRF, the PCEF shall report to the PCRF when the status of therelated service data flow changes. This procedure can be used to monitor an IP-CANbearer dedicated for AF signaling traffic.





27

Request and Provisioning of PCC rulesThe PCRF shall indicate, via the Gx reference point, PCC rules to be applied at thePCEF. This may be done by using one of the following procedures:

PULL procedure (Provisioning solicited by the PCEF): In response to a request forPCC rules being made by the PCEF (CC-Request), the PCRF shall provision PCC

rules in the CC-Answer.

PUSH procedure (Unsolicited provisioning): The PCRF may decide to provisionPCC rules without obtaining a request from the PCEF, e.g. in response toinformation provided to the PCRF via the Rx reference point, or in response to aninternal trigger within the PCRF. To provision PCC rules without a request from thePCEF, the PCRF shall include these PCC rules in an RA-Request (Re-Auth-

Request) message.

The PCEF shall select a PCC rule for each received downlink and uplink IP packet

within an IP CAN session

Policy Control 3GPP Reference Architecture

PCEF

Rx

Sp

Gy

Gz

Gx

SPR

OCS

UE

OFCS

AF

PCRF

AF: Aplication Function

PCRF: Policy and ChargingRule Function

SPR: Subscription Profile Repository

OCS: Online Charging SystemOFCS: Offline Charging SystemUE: User Equipment

BBERF: Bearer Binding and

Reporting Function

Access

TransportNetvork

Gy

PULL (CCR)

PUSH (RAR)

PULL (CCR)

BBERF

Gxx

Fig. 10




FN4243XEN80GLA0


28

2.2 Gx Protocol

The Gx application is defined as a vendor specific Diameter application, where thevendor is 3GPP and the Application-ID for the Gx Application in the present releaseis 16777238. The vendor identifier assigned by IANA to is 10415.

With regard to the Diameter protocol defined over the Gx interface, the PCRF acts asa Diameter server, in the sense that it is the network element that handles PCC Rulerequests for a particular realm. The PCEF acts as the Diameter client, in the sense

that is the network element requesting PCC rules in the transport plane networkresources

2.3 MessagesExisting Diameter command codes from the Diameter base protocol RFC 3588 [5]and the Diameter Credit Control Application RFC 4006 [9] are used with the Gxspecific AVPs.

A Gx specific Auth-Application id is used together with the command code to identifythe Gx messages.

Diameter messages supported by PCS:

Message from PCS to PCS

Diameter Base Messages

Capabilities-Exchange-Request (CER) X

Capabilities-Exchange-Answer (CEA) X

Device-Watchdog-Request (DWR) X X

Device-Watchdog-Answer (DWA) X X

Disconnect-Peer-Request (DPR) X X

Disconnect-Peer-Answer (DPA) X X

Gx Messages

Credit-Control-Request (CCR) X

Credit-Control-Answer (CCA) X

Re-Auth-Request (RAR) X

Re-Auth-Answer(RAA) X





29

2.3.1 CC-Request (CCR) Command

The CCR command, indicated by the Command-Code field set to 272 and the 'R' bit

set in the Command Flags field, is sent by the PCEF to the PCRF in order to requestPCC rules for a bearer. The CCR command is also sent by the PCEF to the PCRF inorder to indicate bearer or PCC rule related events or the termination of the IP CANbearer and/or session.

Message Format:<CC-Request> ::= < Diameter Header: 272, REQ, PXY >

< Session-Id >{ Auth-Application-Id }{ Origin-Host }

{ Origin-Realm }{ Destination-Realm }{ CC-Request-Type }

{ CC-Request-Number }[ Destination-Host ][ Origin-State-Id ]

*[ Subscription-Id ]*[ Supported-Features ][ Network-Request-Support ]*[ Packet-Filter-Information ][ Packet-Filter-Operation ]

[ Bearer-Identifier ][ Bearer-Operation ][ Framed-IP-Address ][ Framed-IPv6-Prefix ]

[ IP-CAN-Type ][ 3GPP-RAT-Type ][ RAT-Type ][ Termination-Cause ][ User-Equipment-Info ][ QoS-Information ][ QoS-Negotiation ]

[ QoS-Upgrade ][ Default-EPS-Bearer-QoS ]

0*2[ AN-GW-Address ][ 3GPP-SGSN-MCC-MNC ][ 3GPP-SGSN-Address ][ 3GPP-SGSN-IPv6-Address ][ RAI ][ 3GPP-User-Location-Info][ 3GPP-MS-TimeZone ][ Called-Station-Id ][ PDN-Connection-ID ]

[ Bearer-Usage ][ Online ]




FN4243XEN80GLA0


30

[ Offline ]*[ TFT-Packet-Filter-Information ]

*[ Charging-Rule-Report]

*[ Event-Trigger][ Event-Report-Indication][ Access-Network-Charging-Address ]*[ Access-Network-Charging-Identifier-Gx ]*[ CoA-Information ]*[ Usage-Monitoring-Information ][ Routing-Rule-Install ][ Routing-Rule-Remove ][ Logical-Access-ID ]

[ Physical-Access-ID ]*[ Proxy-Info ]

*[ Route-Record ]*[ AVP ]

Example: CCR message:

AVP Explanation Example

< Session-Id > Type: UTF8String.Uniquely identifies a session

300005411

Origin-Host (264M) Type: Diameter Identity.The endpoint that originated the

Diameter message.

blrm2490nb

Origin-Realm (296M) Type: Diameter Identity.Realm of the originator of a Diameter

message

nsn.com

Destination-Realm(283M) Type: Diameter Identity. siemens.com

CC-Request-Type(416M) Type: EnumeratedThe type of the request (initial,update, termination)

INITIAL_REQUESTUDATE_REQUESRTERMINATION_REQUEST

CC-Request-Number(415M) Type: Unsigned32Identifies this request within onesession.

0

Destination-Host (264M) Type: Diameter Identity.

Subscription-Id(443) Type: GroupedThe identification of the subscription

(IMSI, MSISDN, etc.)

1. END_USER_E164

2. 498912341234

or/and

1. END_USER_IMSI

2. 1721111234541001

Bearer-Control-Mode(1023) Type: Enumerated

UE_ONLY (0), NW_ONLY (1),

UE_NW (2)

UE_ONLY (UE shallrequest any additional

bearer establishment)

Bearer-Identifier(1020) The bearer identifier of an IP CANbearer shall be unique within the

corresponding IP CAN session.

313233





31

Bearer-Operation(1021) Type: Enumerated

Indicates the bearer event that causesa request for PCC rules

TERMINATION (0)

ESTABLISHMENT(1)

MODIFICATION(2)

Framed-IP-Address(8) The valid routable IPv4 address thatis applicable for the IP Flows towardsthe UE at the PCEF. The PCRF shalluse this address to identify the correct

IP-CAN session (session binding).

127.0.3.54

IP-CAN-Type(1027) the type of Connectivity AccessNetwork in which the user is conn.

3GPP (0)

RAT-Type(1032) the type of the radio access

technology

WLAN (0)

User-Equipment-Info(458) Type: Grouped

User-Equipment-Info-Type(459)

User-Equipment-Info-Value(460)

1. IMEISV

2. 78797773

QoS-Information(1016) Type: Grouped

[ QoS-Class-Identifier ]

[ Max-Requested-Bandwidth-UL ][ Max-Requested-Bandwidth-DL ][ Guaranteed-Bitrate-UL ][ Guaranteed-Bitrate-DL ][ Bearer-Identifier ][ Allocation-Retention-Priority ][ APN-Aggregate-Max-Bitrate-UL ][ APN-Aggregate-Max-Bitrate-DL ]

* [ AVP ]

1. 00000001

2. 123456

3. 123456

4. 00003039

5. 00003039

6. 313233

Reason-Info(18)

GPRS: 3GPP-SGSN MCC-

MNC

GPRS: MCC and the MNC of theSGSN

111121

Optional-Capability(6)

GPRS: 3GPP-SGSNAddress

GPRS: IPv4 address of the SGSN 127-10.10.10

RAI(909) Routing Area Identity of the SGSNwhere the UE is registered

12345

Called-Station-Id(30) PDN identifier (APN) 31

Bearer-Usage(1000) Type EnumeratedIndicate how the bearer is being used.GENERAL (0)

IMS_SIGNALLING (1)

GENERAL (0)

Event-Trigger(1006) When sent from the PCRF to thePCEF the Event-Trigger AVPindicates an event that shall cause a

re-request of PCC rules

SGSN CHANGE (0)




FN4243XEN80GLA0


32

2.3.2 CC-Answer (CCA) Command

The CCA command, indicated by the Command-Code field set to 272 and the 'R' bit

cleared in the Command Flags field, is sent by the PCRF to the PCEF in response tothe CCR command. It is used to provision PCC rules and event triggers for thebearer/session and to provide the selected bearer control mode for the IP-CANsession. If the PCRF performs the bearer binding, PCC rules will be provisioned at

bearer level. The primary and secondary CCF and/or primary and secondary OCSaddresses may be included in the initial provisioning.

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

< Session-Id >

{ Auth-Application-Id }{ Origin-Host }{ Origin-Realm }

[ Result-Code ][ Experimental-Result ]{ CC-Request-Type }

{ CC-Request-Number }*[ Supported-Features ][ Bearer-Control-Mode ]*[ Event-Trigger ][ Event-Report-Indication ]

[ Origin-State-Id ]*[ Redirect-Host ][ Redirect-Host-Usage ][ Redirect-Max-Cache-Time ]

*[ Charging-Rule-Remove ]*[ Charging-Rule-Install ][ Charging-Information ][ Online ][ Offline ]*[ QoS-Information ][ Revalidation-Time ]

[ Default-EPS-Bearer-QoS ][ Bearer-Usage ]

*[ Usage-Monitoring-Information ]*[ CSG-Information-Reporting ][ User-CSG-Information ][ Error-Message ][ Error-Reporting-Host ]*[ Failed-AVP ]*[ Proxy-Info ]*[ Route-Record ]*[ AVP ]





33

Example: CCA message:


300005411

Result-Code(268) DIAMETER_SUCCESS (2001)

Origin-Host (264M) Type: Diameter Identity.The endpoint that originated the

Diameter message.

pcs23-ims

Origin-Realm (296M) Type: Diameter Identity.Realm of the originator of a Diameter

message

local_realm

CC-Request-Type(416M)

Type: EnumeratedThe type of the request (initial, update,termination)

INITIAL_REQUESTUDATE_REQUESRTERMINATION_REQUEST

CC-Request-

Number(415M)

Type: Unsigned32

Identifies this request within onesession.

0

Event-Trigger(1006) When sent from the PCRF to thePCEF the Event-Trigger AVP indicatesan event that shall cause a re-request

of PCC rules

NO_EVENT_TRIGGERS (14)

Charging-Rule-Install(1001)

Type: Grouped

*[ Charging-Rule-Definition ]*[ Charging-Rule-Name ]*[ Charging-Rule-Base-Name ][ Bearer-Identifier ][ Rule-Activation-Time ]

[ Rule-Deactivation-Time ][ Resource-Allocation-Notification ][ Charging-Correlation-Indicator ]

1. *[ AVP ]

Charging-Rule-Remove(1002)

Type: Grouped

*[ Charging-Rule-Name ]*[ Charging-Rule-Base-Name ]*[ AVP ]

QoS-Information Type: Grouped



* [ AVP ]

Online (1009) Type: Enumerated

Indicates the default charging methodfor online. The default charging method

provided by the PCRF shall takeprecedence over any pre-configured

default charging method at the PCEF

ENABLE_ONLINE (1)




FN4243XEN80GLA0


34

2.3.3 Re-Auth-Request (RAR) Command

The RAR command, indicated by the Command-Code field set to 258 and the 'R' bit

set in the Command Flags field, is sent by the PCRF to the PCEF in order toprovision PCC rules using the PUSH procedure initiate the provision of unsolicitedPCC rules. It is used to provision PCC rules and event triggers for the session. If thePCRF performs the bearer binding, PCC rules will be provisioned at bearer level.

Message Format:<RA-Request> ::= < Diameter Header: 258, REQ, PXY >

< Session-Id >{ Auth-Application-Id }

{ Origin-Host }{ Origin-Realm }

{ Destination-Realm }{ Destination-Host }{ Re-Auth-Request-Type }[ Session-Release-Cause ][ Origin-State-Id ]*[ Event-Trigger ][ Event-Report-Indication ]

*[ Charging-Rule-Remove ]*[ Charging-Rule-Install ][ Default-EPS-Bearer-QoS ]*[ QoS-Information ]

[ Revalidation-Time ]*[ Usage-Monitoring-Information ]*[ Proxy-Info ]*[ Route-Record ]*[ AVP]

NOTENOTE: If the RAR command is received by the PCEF without providing any

operation on PCC rules or any QoS information, the PCEF will respond with a CCR

command requesting PCC rules.





35

Example: RAR message

AVP Explanation Example


300005411

Origin-Host(264M)

Type: Diameter Identity.The endpoint that originated the

Diameter message.

blrm2490nb

Origin-Realm(296M)

Type: Diameter Identity.Realm of the originator of a Diameter

message

nsn.com

Destination-

Realm(283M)

Type: Diameter Identity. siemens.com

Destination-Host

(264M)

Type: Diameter Identity.

Charging-Rule-Remove(1002)

Type: Grouped

*[ Charging-Rule-Name ]*[ Charging-Rule-Base-Name ]*[ AVP ]

. . . . . . .

Charging-Rule-Install

Type: Grouped

*[ Charging-Rule-Definition ]*[ Charging-Rule-Name ]*[ Charging-Rule-Base-Name ][ Bearer-Identifier ]

[ Rule-Activation-Time ][ Rule-Deactivation-Time ][ Resource-Allocation-Notification ][ Charging-Correlation-Indicator ]

*[ AVP ]

QoS-Information Type: Grouped



* [ AVP ]




FN4243XEN80GLA0


36

2.3.4 Re-Auth-Answer (RAA) Command

The RAA command, indicated by the Command-Code field set to 258 and the 'R' bit

cleared in the Command Flags field, is sent by the PCEF to the PCRF in response tothe RAR command.

Message Format:

<RA-Answer> ::= < Diameter Header: 258, PXY >< Session-Id >{ Origin-Host }{ Origin-Realm }[ Result-Code ][ Experimental-Result ]

[ Origin-State-Id ][ IP-CAN-Type ][ RAT-Type ]

0*2 [ AN-GW-Address ][ 3GPP-SGSN-MCC-MNC ][ 3GPP-SGSN-Address ]

[ 3GPP-SGSN-IPv6-Address ][ RAI ][ 3GPP-User-Location-Info ][ 3GPP-MS-TimeZone ]

* [ Charging-Rule-Report]

[ Error-Message ][ Error-Reporting-Host ]

* [ Failed-AVP ]* [ Proxy-Info ]

* [ AVP ]





37

2.4 Gx specific Experimental-Result-Code AVP values

Result codes Name

5140 DIAMETER_ERROR_INITIAL_PARAMETERS

5141 DIAMETER_ERROR_TRIGGER_EVENT

5142 DIAMETER_PCC_RULE_EVENT

5143 DIAMETER_ERROR_BEARER_NOT_AUTHORIZED

5144 DIAMETER_ERROR_TRAFFIC_MAPPING_INFO_REJECTED

5147 DIAMETER_ERROR_CONFLICTING_REQUEST

4141DIAMETER_PCC_BEARER_EVENT

Additionally, Result-Code AVP values defined in Diameter BASE RFC 3588 areapplicable too.




FN4243XEN80GLA0


38

2.4.1 Event triggers at Gx Interface

When event trigger is sent from the PCRF to the PCEF the Event-Trigger AVP

indicates an event that shall cause a re-request of PCC rules. When sent from thePCEF to the PCRF the Event-Trigger AVP indicates that the corresponding event hasoccurred at the gateway.

Example:

Event Trigger Name Code

SGSN_CHANGE 0

QOS_CHANGE 1

RAT_CHANGE 2

TFT_CHANGE 3

PLMN_CHANGE 4

LOSS_OF_BEARER 5

RECOVERY_OF_BEARER 6

IP-CAN_CHANGE 7`

QOS_CHANGE_EXCEEDING_AUTHORIZATION 11

RAI_CHANGE 12

USER_LOCATION_CHANGE 13

NO_EVENT_TRIGGERS 14

OUT_OF_CREDIT 15

REVALIDATION_TIMEOUT 17

USAGE_REPORT 26

In the PCS_GeneralConfigParams.xml file operator can specify set of default eventtriggers.





39

Event Triger

Charging Information

Fig. 11




FN4243XEN80GLA0


40

2.5 Timers at Gx Interface

Answer timerThe timer is initiated by the PCS-5000 as protection against non-receipt of responsesfor any session based scenarios. Answer Timer is a configurable value(PCS_GeneralConfigParams, Gx-Interface, Answer-Timer_ms). The value of thetimer is configured in milliseconds.

Default value: 2000.

Range: 500-65535

Example: after RAR message, RAA is not received.

Session Release Delay Timer

The timer is initiated by the PCS-5000 in case of any diameter connection gettingdisconnected with the peer. PCS waits for the configured duration, before terminatingall the sessions related to the peer.

If the reconnection is successful before the timer expires, all the sessions aremaintained in the PCS-5000 for the peer.

The value should be grater then the maximum Gx reconnection time configured onthe PCEF (GGSN).

Timer is a configurable value (PCS_GeneralConfigParams, Gx-Interface, Session-

Release-Delay-Timer_ms).

The value of the timer is configured in milliseconds.

Default value: 30000.

Range: 500-65535





41

PCEF PCS-5000

RAR (Re-Authorisation-Request )

RAA (Re-Authorisation- Answer)

Answer Timer

When timer expires, PCS will

Initiate termination of this

session.

Fig. 12

PCEF PCS-5000

DPR/DPA

Session Release Delay Timer

When timer expires, PCS willInitiate termination of allSessions related to the peer.

PCEF PCS-5000

DPR/DPA

All sessions are maintaned,The timer is stopped.

Gx conn. reastablished

Fig. 13




FN4243XEN80GLA0


42

2.6 Gx specific Diameter AVPs

AVPs

AVP Flag rules (note 1)

Attribute Name AVPCode

Clausedefined

Value Type(note 2)

Must May Should not

Mustnot

MayEncr.

Acc. type Applicability(notes3, 9)

Access-Network-Charging-Identifier-Gx

1022 5.3.22 Grouped M,V P Y All CC

Allocation-Retention-Priority 1034 5.3.32 Grouped V P M Y All BothRel8

AN-GW-Address 1050 5.3.49 Address V P M Y All BothRel8

APN-Aggregate-Max-Bitrate-DL 1040 5.3.39 Unsigned32 V P M Y All PCRel8

APN-Aggregate-Max-Bitrate-UL 1041 5.3.40 Unsigned32 V P M Y All PCRel8

Bearer-Control-Mode 1023 5.3.23 Enumerated M,V P Y 3GPP-GPRS3GPP-EPS3GPP2Non-3GPP-EPS(NOTE 6)

PC

Bearer-Identifier 1020 5.3.20 OctetString M,V P Y 3GPP-GPRS BothBearer-Operation 1021 5.3.21 Enumerated M,V P Y 3GPP-GPRS Both

Bearer-Usage 1000 5.3.1 Enumerated M,V P Y 3GPP-GPRS3GPP-EPS

Both

Charging-Rule-Install 1001 5.3.2 Grouped M,V P Y All BothCharging-Rule-Remove 1002 5.3.3 Grouped M,V P Y All Both

Charging-Rule-Definition 1003 5.3.4 Grouped M,V P Y All Both

Charging-Rule-Base-Name 1004 5.3.5 UTF8String M,V P Y All Both

Charging-Rule-Name 1005 5.3.6 OctetString M,V P Y All BothCharging-Rule-Report 1018 5.3.18 Grouped M,V P Y All Both

Charging-Correlation-Indicator 1073 5.3.67 Enumerated V P M Y All CCRel8

CoA-IP-Address 1035 5.3.33 Address V P M Y All(NOTE 8)

BothRel8

CoA-Information 1039 5.3.37 Grouped V P M Y All(NOTE 8)

BothRel8

CSG-Information-Reporting 1071 5.3.64 Enumerated V P M Y 3GPP-GPRS3GPP-EPS

CCRel9

Default-EPS-Bearer-QoS 1049 5.3.48 Grouped V P M Y All(NOTE 5)

PCRel8

Event-Report-Indication 1033 5.3.30 Grouped V P M Y All BothRel8

Event-Trigger 1006 5.3.7 Enumerated M,V P Y All Both

Flow-Direction 1080 5.3.65 Enumerated V P M Y All BothRel9

Flow-Information 1058 5.3.53 Grouped V P M Y All Both

Flow-Label 1057 5.3.52 OctetString V P M Y All BothIP-CAN-Type 1027 5.3.27 Enumerated M,V P Y All Both

Guaranteed-Bitrate-DL 1025 5.3.25 Unsigned32 M,V P Y All PC

Guaranteed-Bitrate-UL 1026 5.3.26 Unsigned32 M,V P Y All PC

Metering-Method 1007 5.3.8 Enumerated M,V P Y All CCMonitoring-Key 1066 5.3.59 OctetString V P M Y All Both

Rel9





43

Network-Request-Support 1024 5.3.24 Enumerated M,V P Y 3GPP-GPRS3GPP-EPS3GPP2 Non-3GPP-EPS(NOTE 6)

PC

Offline 1008 5.3.9 Enumerated M,V P Y All CCOnline 1009 5.3.10 Enumerated M,V P Y All CCPacket-Filter-Content 1059 5.3.54 IPFilterRule V P M Y All

(NOTE 5)BothRel8

Packet-Filter-Identifier 1060 5.3.55 OctetString V P M Y All(NOTE 5)

BothRel8

Packet-Filter-Information 1061 5.3.56 Grouped V P M Y All(NOTE 5)

BothRel8

Packet-Filter-Operation 1062 5.3.57 Enumerated V P M Y All(NOTE 5)

BothRel8

Packet-Filter-Usage 1072 5.3.66 Enumerated V P M Y All BothRel9

PDN-Connection-ID 1065 5.3.58 OctetString V P Y All(NOTE 7)

BothRel9

Precedence 1010 5.3.11 Unsigned32 M,V P Y All BothPre-emption-Capability 1047 5.3.46 Enumerated V P M Y 3GPP- EPS,

3GPP-GPRSBothRel8

Pre-emption-Vulnerability 1048 5.3.47 Enumerated V P M Y 3GPP- EPS,3GPP-GPRS

BothRel8

Priority-Level 1046 5.3.45 Unsigned32 V P M Y All BothRel8

Reporting-Level 1011 5.3.12 Enumerated M,V P Y All CC

Routing-Filter 1078 5.3.72 Grouped V P M Y 3GPP-EPS ,Non-3GPP-EPS

BothIFOM

Routing-IP-Address 1079 5.3.73 Address V P M Y 3GPP-EPS,Non-3GPP-EPS

BothIFOM

Routing-Rule-Definition 1076 5.3.70 Grouped V P M Y 3GPP-EPS,Non-3GPP-EPS

BothIFOM

Routing-Rule-Identifier 1077 5.3.71 OctetString V P M Y 3GPP-EPS ,Non-3GPP-EPS

BothIFOM

Routing-Rule-Install 1081 5.3.68 Grouped V P M Y 3GPP-EPS,Non-3GPP-EPS

BothIFOM

Routing-Rule-Remove 1075 5.3.69 Grouped V P M Y 3GPP-EPS ,Non-3GPP-EPS

BothIFOM

PCC-Rule-Status 1019 5.3.19 Enumerated M,V P Y All Both

Session-Release-Cause 1045 5.3.44 Enumerated M,V P Y All Both

QoS-Class-Identifier 1028 5.3.17 Enumerated M,V P Y All BothQoS-Information 1016 5.3.16 Grouped M.V P Y All Both

QoS-Negotiation 1029 5.3.28 Enumerated M,V P Y 3GPP-GPRS PC

QoS-Upgrade 1030 5.3.29 Enumerated M.V P Y 3GPP-GPRS PC

Resource-Allocation-Notification

1063 5.3.50 Enumerated V P M Y All BothRel8

Rule-Failure-Code 1031 5.3.38 Enumerated M.V P Y All Both

Security-Parameter-Index 1056 5.3.51 OctetString V P M Y All BothTFT-Filter 1012 5.3.13 IPFilterRule M,V P Y 3GPP-GPRS Both

TFT-Packet-Filter-Information 1013 5.3.14 Grouped M,V P Y 3GPP-GPRS Both

ToS-Traffic-Class 1014 5.3.15 OctetString M,V P Y All Both

Tunnel-Header-Filter 1036 5.3.34 IPFilterRule V P M Y All(NOTE 8)

BothRel8

Tunnel-Header-Length 1037 5.3.35 Unsigned32 V P M Y All(NOTE 8)

BothRel8




FN4243XEN80GLA0


44

Tunnel-Information 1038 5.3.36 Grouped V P M Y All(NOTE 8)

BothRel8

RAT-Type 1032 5.3.31 Enumerated V P M Y All(NOTE 4)

BothRel8

Revalidation-Time 1042 5.3.41 Time M,V P Y All BothRule-Activation-Time 1043 5.3.42 Time M,V P Y All Both

Usage-Monitoring-Information 1067 5.3.60 Grouped V P M Y All BothRel9

Rule-Deactivation-Time 1044 5.3.43 Time M,V P Y All Both

Usage-Monitoring-Level 1068 5.3.61 Enumerated V P M Y All BothRel9

Usage-Monitoring-Report 1069 5.3.62 Enumerated V P M Y All BothRel9

Usage-Monitoring-Support 1070 5.3.63 Enumerated V P M Y All BothRel9

NOTE 1: The AVP header bit denoted as 'M', indicates whether support of the AVP is required. The AVP header bitdenoted as 'V', indicates whether the optional Vendor-ID field is present in the AVP header. For furtherdetails, see RFC 3588 [4].

NOTE 2: The value types are defined in RFC 3588 [4].NOTE 3: AVPs marked with "CC" are applicable to charging control, AVPs marked with "PC" are applicable to policy

control and AVPs marked with "Both" are applicable to both charging control and policy control.NOTE 4: RAT-Type AVP applies to 3GPP, Non-3GPP-EPS, and 3GPP2 access types.NOTE 5: This AVP does not apply to 3GPP-GPRS access type.NOTE 6: The 3GPP2 usage is defined in 3GPP2 X.S0062 [30]. Non-3GPP-EPS usage applies to GTP based S2b,NOTE 7: This AVP only applies to case 2b as defined in 3GPP TS 29.213 [8].NOTE 8: This AVP only applies to case 2a as defined in 3GPP TS 29.213 [8].NOTE 9: AVPs marked with "Rel8", "Rel9" or "IFOM" are applicable as described in clause 5.4.1.





45

2.7 Signaling Flow over Gx Interface

2.7.1 IP-CAN Session Establishment

1. The GW receives an Establish IP-CAN (IP Connectivity Access Network SessionRequest). After this step, UE has been assigned an IP address

2. The GW informs the PCRF of the establishment of the IP-CAN Session bysending a CCR. CC-Request-Type AVP is set to the value INITIAL_REQUEST.

The GW provides following information: UE identity information and/or the UE IPaddress types of IP-CAN, QoS.

3. The PCRF stores the information received in the Diameter CCR.

4. If the PCRF requires subscription-related information and does not have it, thePCRF sends a request to the SPR in order to receive the information.

5. The SPR replies with the subscription related information containing theinformation about the allowed service(s), QoS information and PCC Rulesinformation.

6. The PCRF selects PCC Rule(s) to be installed:The PCRF decides whether service flows described in the PCC Rules are to beenabled or disabled. If it is enabled, derives an authorized QoS.

Selected PCC Rules are stored.

7. The PCC Rules are provisioned by the PCRF to the GW using Diameter CCA.

8. The GW installs the received PCC Rules. The GW also enforces the authorizedQoS and enables or disables service flow according to the flow status of the

corresponding PCC Rules.

9. The GW sends a response to the Establish IP-CAN Session Request.For GPRS, the GGSN accepts the PDP Context Request based on the results ofthe authorization policy decision enforcement. If the requested QoS parametersdo not correspond to the authorized QoS, the GGSN adjusts (downgrades/upgrades) the requested QoS parameters to the authorized values.




FN4243XEN80GLA0


46

GW PCRF SPR

3. Store Information

6. PCC Rules Decision

(Policy Decision)

Store PCC Rules

8. Install PCC Rules(Policy enforcement)

1. Establish IP CAN

Session Request

2. CCR

4. Profile Request

5. Profile Response

7. CCA

9. Establish IP CAN

Session Response

IP-CAN Session

Establishment

Fig. 14





47

2.7.2 IP-CAN Session Termination - UE-Initiated

1. The GW receives a Remove IP-CAN Session Request.

2. The GW sends a Diameter CCR message to the PCRF, indicating the IP-CANSession termination. The GW requests the termination of the session using theCC-Request-Type AVP set to the value TERMINATION_REQUEST.

3. The PCRF stores the information received in the Diameter CCR.

4. If the PCRF requires subscription-related information and does not have it, thePCRF sends a request to the SPR in order to receive the information.

5. The SPR replies with the subscription related information.

6. The PCRF performs policy evaluation

7. Result of policy evaluation can be update of SPR. Then PCRF sends Update

Request. SPR sends as response8. Update Response.

9. The PCRF acknowledges the session termination by sending a Diameter CCAmessage.

10. The GW sends a response to the Remove IP-CAN Session Request.:

Similar is when the initiator for the session termination is GW. Messages betweenPCRF and GW are the same.




FN4243XEN80GLA0


48

IP-CAN Session

Termination

UE Initiated GW PCRF

1. Remove IP CAN

Session Request

2. CCR

10. Remove IP CAN

Session Response

3. Store Information

6. Policy Evaluation

4. Profile Request

5. Profil e Response

SPR

7. Update Request

8. Update Response

9. CCA

Fig. 15





49

2.7.3 IP-CAN Session Termination - PCRF initiated

1. The PCRF detects that the termination of an IP-CAN Session is required.

2. The PCRF sends a Diameter RAR to request that the GW removes all PCCRules previously installed for the IP CAN session and deactivates all PCC rulespreviously activated for the IP CAN session.

3. The GW removes the identified PCC Rules.

4. The GW sends RAA to acknowledge the RAR.

5. The GW sends a Remove IP-CAN Session Request that request the deactivation

of the IP-CAN Session.

6. The GW receives a response to the Remove IP-CAN Session Request.

7. The GW sends a Diameter CCR message to the PCRF. CC-Request-Type AVP

set to the value TERMINATION_REQUEST.8. The PCRF identifies AF sessions that are bound to IP flows of the removed IP-

CAN Session.

9. The PCRF acknowledges the session termination by sending a Diameter CCAmessage.

Not in the diagram:

Like in previous case, after CCR, PCRF will perform Policy Evaluation. Result ofpolicy evaluation can be update of SPR. Then PCRF sends Update Request andSPR sends as response Update Response.




FN4243XEN80GLA0


50

IP-CAN Session

TerminationPCRF initiatedGW PCRF

2.RAR

9. CCA

1. External/Internal

Trigger

4.RAA

7. CCR

3. Remove PCC Rules

5. Remove IP-CAN

Session Request

6. . Remove IP-CANSession Response

Fig. 16





51

2.7.4 IP-CAN Session Modification

1. The PCRF receives an internal or external trigger (e.g. from AF) to re-evaluate

PCC Rules and policy decision for an IP-CAN Session.

2. The PCRF selects the PCC Rule(s) to be installed, modified or removed for theIP-CAN Session.

3. The PCRF stores the updated PCC Rules.

4. The PCRF sends a Diameter RAR to request that the GW installs, modifies orremoves PCC Rules and updates the policy decision.

5. The GW installs, modifies or removes the identified PCC Rules. The GW alsoenforces the authorized QoS and enables or disables service flow according tothe flow status of the corresponding PCC Rules.

6. The GW sends RAA to acknowledge the RAR. The PCEF informs the PCRFabout the outcome of the PCC rule operation

7. For GPRS, the GGSN initiates the procedure to Create/Update or TerminatePDP Context Request message to the SGSN.

8. The GW sends the notifications needed to the PCRF. The notification is made byusing a CCR messages with the needed AVPs.

9. The PCRF stores the information coming in the notification and acknowledgesthe CCR with a CCA command.




FN4243XEN80GLA0


52

GW PCRF

8. CCR

9. CCA

7. PDP context

signalling

1. Trigger

2. PCC Rules Decison,

(Policy Decision)

3. Store PCC Rules

4. RAR

5. Instalation, Modification or

Removal of PCC Rules

(Policy Enforcement)

6. RAA

IP-CAN Session

Modification

Fig. 17





53

3 Rx Interface




FN4243XEN80GLA0


54

3.1 Basic Terms

Rx reference pointThe Rx reference point is located between the PCRF and the AF. The Rx referencepoint is used to exchange application level session information between the Policyand Charging Rules Function (PCRF) and the Application Function (AF).

Rx reference point is specified in:

3GPP TS 29.214 - Policy and Charging Control over Rx reference point

Application Function (AF) is element offering application(s) that require the Policyand Charging Control of traffic plane resources The AF use the Rx reference point toprovide session information to the PCRF.

One example of an application function is the P-CSCF.

PCRFThe PCRF is a functional element that is responsible for policy control decision andflow based charging control.The PCC Rule decisions may be based on one or more of the following:

Information received from the AF via the Rx reference point, e.g. the session,

media and subscriber related information.

Information obtained from the PCEF via the Gx reference point, e.g. IP-CANbearer attributes, request type and subscriber related information.

Information obtained from the SPR via the Sp reference point, e.g. subscriber andservice related data.

Own PCRF pre-configured information.

The PCRF shall report events to the AF via the Rx reference point.The PCRF shall inform the PCEF through the use of PCC rules on the treatment ofeach service data flow that is under PCC control, in accordance with the PCRF policydecision.





55

Policy Control 3GPP Reference Architecture

PCEF

Rx

Sp

Gy

Gz

Gx

SPR

OCS

UE

OFCS

AF

PCRF

AF: Aplication Function

PCRF: Policy and Charging

Rule Function

SPR: Subscription Profile Repository

OCS: Online Charging System

OFCS: Offline Charging System

UE: User Equipment

BBERF: Bearer Binding and

Reporting Function

Access

Transport

Netvork

Gy

BBERF

Gxx

Fig. 18




FN4243XEN80GLA0


56

3.2 Rx Protocol

The Rx application is defined as a vendor specific Diameter application, where thevendor is 3GPP and the Application-ID is 16777236. The vendor identifierassigned by IANA to is 10415.

With regard to the Diameter protocol defined over the Rx interface, the PCRF acts asa Diameter server, in the sense that it is the network element that handles PCC Rulerequests for a particular realm. The AF acts as the Diameter client, in the sense that

is the network element requesting PCC rules in the transport plane networkresources

3.3 MessagesExisting Diameter command codes from the Diameter base protocol RFC 3588 [5]and the NASREQ Diameter application (RFC 4005 [12]) are used with the Rx specific AVPs.

An Rx specific Auth-Application id is used together with the command code to identifythe Rx messages.

Diameter messages supported by PCS:

Message from PCS to PCS

Diameter Base MessagesCapabilities-Exchange-Request (CER) X

Capabilities-Exchange-Answer (CEA) X

Device-Watchdog-Request (DWR) X X

Device-Watchdog-Answer (DWA) X X

Disconnect-Peer-Request (DPR) X X

Disconnect-Peer-Answer (DPA) X X

Rx Messages

Authentication-Authorization-Request (AAR) X

Authentication-Authorization-Request (AAA) X

Re-Auth-Request (RAR) X

Re-Auth-Answer(RAA) X

Session-Termination-Request (STR) X

Session-Termination-Answer (STA) X

Abort-Session-Request (ASR) X

Abort-Session-Answer (ASA) X





57

3.3.1 Authentication-Authorization-Request (AAR)

The AAR command, indicated by the Command-Code field set to 265 and the 'R' bit

set in the Command Flags field, is sent by an AF to the PCRF in order to provide itwith the Session Information.

Message Format:<AA-Request> ::= < Diameter Header: 265, REQ, PXY >

< Session-Id >{ Auth-Application-Id }{ Origin-Host }

{ Origin-Realm }

{ Destination-Realm }[ Destination-Host ]

[ AF-Application-Identifier ]*[ Media-Component-Description ][ Service-Info-Status ][ AF-Charging-Identifier ][ SIP-Forking-Indication ]*[ Specific-Action ]*[ Subscription-Id ]*[ Supported-Features ][ Reservation-Priority ]

[ Framed-IP-Address ][ Framed-IPv6-Prefix ][ Called-Station-Id ][ Service-URN ][ Sponsored-Connectivity-Data ][ MPS-Identifier ][ Origin-State-Id ]*[ Proxy-Info ]*[ Route-Record ]

*[ AVP ]




FN4243XEN80GLA0


58

AVP (code & bits) Type and content;

< Session-Id >

(AVP Code 263)

UTF8String. Used to identify a specific session; must begin

with the sender's identity.

Auth-Application-Id Unsigned32. Must contain the Rx application identifier(16777236).

{ Origin-Host }

(AVP Code 264)Diameter Identity. The host name of the system where themessage originated.

{ Origin-Realm }

(AVP Code 296) Diameter Identity. The PCS5000 domain name.

{ Destination-Realm }


[ Destination-Host ]

(AVP Code 293) Diameter Identity. The hosts name of the system whereexactly the destination of the message is.

[AF-Application-Identifier ]

(AVP code 504)OctetString. Identifies the particular service that the AFservice session belongs to

*[ Media-Component-Description ]

(AVP code 517)

Grouped. Contains service information for a single mediacomponent within an AF session or the AF signaling

information

[Service-Info-Status ]

(AVP code 527)

Enumerated. Indicates the status of the service informationthat the AF is providing to the PCRF. If the Service-Info-Status AVP is not provided in the AA request, the value FINAL

SERVICE INFORMATION shall be assumed

[ AF-Charging-Identifier ]

(AVP code 505)

OctetString. Contains the AF Charging Identifier that is sent bythe AF. This information may be used for charging correlation

with bearer layer

[ SIP-Forking-Indication ] (AVP code523) Enumerated, and describes if several SIP dialogues are

related to one Diameter session

*[ Specific-Action ]

(AVP code 513)Enumerated

*[ Subscription-ID ]The identification of the subscription (IMSI, MSISDN, etc.)

[ Reservation-Priority ]Vendor-id: ETSI (13019) [15]..

[ Framed-IP-Address ] The valid routable IPv4 address that is applicable for the IPFlows towards the UE at the PCEF. The PCRF shall use thisaddress to identify the correct IP-CAN session (session

binding).

[ Service-URN ]

(AVP code 525)OctetString. Indicates that an AF session is used for

emergency traffic.





59

3.3.2 Authentication-Authorization- Answer (AAA)

The AAA command, indicated by the Command-Code field set to 265 and the 'R' bitcleared in the Command Flags field, is sent by the PCRF to the AF in response to the AAR command.

Message Format:<AA-Answer> ::= < Diameter Header: 265, PXY >

< Session-Id >{ Auth-Application-Id }{ Origin-Host }{ Origin-Realm }[ Result-Code ]

[ Experimental-Result ]*[ Access-Network-Charging-Identifier ]

[ Access-Network-Charging-Address ][ Acceptable-Service-Info ][ IP-CAN-Type ][ RAT-Type ]*[ Flows ]*[ Supported-Features ]*[ Class ][ Error-Message ][ Error-Reporting-Host ]

*[ Failed-AVP ][ Origin-State-Id ]*[ Redirect-Host ][ Redirect-Host-Usage ][ Redirect-Max-Cache-Time ]*[ Proxy-Info ]*[ AVP ]




FN4243XEN80GLA0


60

AVP (code & bits) Type and content

< Session-Id >

(AVP Code 263)UTF8String. Used to identify a specific session; must begin


Auth-Application-Id Unsigned32. Must contain the Rx application identifier(16777236).

{ Origin-Host }


{ Origin-Realm }


[ Result-Code ]

[ Experimental-Result ]

(AVP Code 298)

Unsigned32. Contains a vendor-assigned value representingthe result of processing a request. The Vendor-ID AVP shall be

set to 3GPP (10415)

[ Access-Network-Charging-Identifier ]

(AVP Code 502) is of type Grouped

[ Access-Network-Charging- Address ]

(AVP Code 501) Address

[ IP-CAN-Type ] IP-CAN type of the user

[ 3GPP-RAT-Type ] Indicate which Radio Access Technology is currently serving

the UE.





61

3.3.3 Re-Auth-Request (RAR)

The RAR command, indicated by the Command-Code field set to 258 and the 'R' bitset in the Command Flags field, is sent by the PCRF to the AF in order to indicate anRx specific action.

Message Format:<RA-Request> ::= < Diameter Header: 258, REQ, PXY >

< Session-Id >{ Origin-Host }{ Origin-Realm }{ Destination-Realm }{ Destination-Host }{ Auth-Application-Id }

{ Specific-Action }*[ Access-Network-Charging-Identifier ][ Access-Network-Charging-Address ]*[ Flows ]*[ Subscription-Id ][ Abort-Cause ][ IP-CAN-Type ][ RAT-Type ][ Sponsored-Connectivity-Data ][ Origin-State-Id ]*[ Class ]*[ Proxy-Info ]*[ Route-Record ]

*[ AVP ]




FN4243XEN80GLA0


62


< Session-Id >

(AVP Code 263)UTF8String. Used to identify a specific session; must begin with the

sender's identity.

{ Origin-Host }

(AVP Code 264)

Diameter Identity. The host name of the system where the message

originated.

{ Origin-Realm }





(AVP Code 293)Diameter Identity. The hosts name of the system where exactly thedestination of the message is.

Auth-Application-Id (AVP code 504) is of type OctetString, and it contains information thatidentifies the particular service that the AF service session belongs to

{ Specific-Action }

(AVP code 513) Enumerated

*[ Flows ]

(AVP code 510)Grouped. Indicates IP flows via their flow identifiers

*[ Access-Network-Charging-Identifier ]

(AVP Code 502) Grouped

[ Access-Network-

Charging-Address ]

(AVP Code 502) Address

[ Abort-Cause ]

(AVP code 500)

The Session-Abort-Cause AVP is of type Enumerated, anddetermines the cause of an abort session request (ASR) or of a RAR

indicating a PDP context release

[ IP-CAN-Type ] IP-CAN type of the user

[ 3GPP-RAT-Type ]Indicate which Radio Access Technology is currently serving the UE.





63

3.3.4 Re-Auth-Answer (RAA)

The RAA command, indicated by the Command-Code field set to 258 and the 'R' bit

cleared in the Command Flags field, is sent by the AF to the PCRF in response to the

RAR command.

Message Format:<RA-Answer> ::= < Diameter Header: 258, PXY >

< Session-Id >{ Origin-Host }

{ Origin-Realm }[ Result-Code ][ Experimental-Result ]

*[ Media-Component-Description ][ Service-URN ][ Origin-State-Id ]*[ Class ][ Error-Message ][ Error-Reporting-Host ]

*[ Redirect-Host ][ Redirect-Host-Usage ][ Redirect-Max-Cache-Time ]*[ Failed-AVP ]*[ Proxy-Info ]




FN4243XEN80GLA0


64


< Session-Id >

(AVP Code 263)UTF8String. Used to identify a specific session; must begin


{ Origin-Host }

(AVP Code 264)

Diameter Identity. The host name of the system where the

message originated.

{ Origin-Realm }


[ Result-Code ]


(AVP Code 298)

Unsigned32. Contains a vendor-assigned valuerepresenting the result of processing a request. The

Vendor-ID AVP shall be set to 3GPP (10415)

*[ Media-Component-Description ]

(AVP code 517)

Grouped. Contains service information for a single media

component within an AF session or the AF signalinginformation

[ Service-URN ]

(AVP code 525)OctetString. Indicates that an AF session is used foremergency traffic





65

3.3.5 Session-Termination-Request (STR)

The STR command, indicated by the Command-Code field set to 275 and the 'R' bit

set in the Command Flags field, is sent by the AF to inform the PCRF that anestablished session shall be terminated.

Message Format:<ST-Request> ::= < Diameter Header: 275, REQ, PXY >

< Session-Id >{ Origin-Host }{ Origin-Realm }{ Destination-Realm }

{ Auth-Application-Id }{ Termination-Cause }[ Destination-Host ]*[ Class ][ Origin-State-Id ]

*[ Proxy-Info ]*[ Route-Record ]*[ AVP ]


< Session-Id >(AVP Code 263)

UTF8String. Used to identify a specific session; must beginwith the sender's identity.

{ Origin-Host }


{ Origin-Realm }




{ Auth-Application-Id }

(AVP code 504) OctetString. Contains information that identifies the particularservice that the AF service session belongs to

{ Termination-Cause }

[Destination-Host ]

(AVP Code 293)Diameter Identity. The hosts name of the system whereexactly the destination of the message is.




FN4243XEN80GLA0


66

3.3.6 Session-Termination-Answer (STA)

The STA command, indicated by the Command-Code field set to 275 and the 'R' bit

cleared in the Command Flags field, is sent by the PCRF to the AF in response to theSTR command.

Message Format:<ST-Answer> ::= < Diameter Header: 275, PXY >

< Session-Id >{ Origin-Host }{ Origin-Realm }[ Result-Code ][ Error-Message ]

[ Error-Reporting-Host ]* [ Failed-AVP ][ Sponsored-Connectivity-Data ][ Origin-State-Id ]

*[ Class ]*[ Redirect-Host ][ Redirect-Host-Usage ]

[ Redirect-Max-Cache-Time ]*[ Proxy-Info ]*[ AVP ]


< Session-Id >

(AVP Code 263)UTF8String. Used to identify a specific session; must beginwith the sender's identity.

{ Origin-Host }


{ Origin-Realm }


[ Result-Code ]


(AVP Code 298)

Unsigned32. Contains a vendor-assigned value representingthe result of processing a request. The Vendor-ID AVP shall

be set to 3GPP (10415)





67

3.3.7 Abort-Session-Request (ASR)

The ASR command, indicated by the Command-Code field set to 274 and the 'R' bit

set in the Command Flags field, is sent by the PCRF to inform the AF that bearer forthe established session is no longer available.

Message Format:<AS-Request> ::= < Diameter Header: 274, REQ, PXY >

< Session-Id >{ Origin-Host }{ Origin-Realm }{ Destination-Realm }{ Destination-Host }

{ Auth-Application-Id }{ Abort-Cause }[ Origin-State-Id ]*[ Proxy-Info ]

*[ Route-Record ]*[ AVP ]


< Session-Id >

(AVP Code 263)UTF8String. Used to identify a specific session; must

begin with the sender's identity.{ Origin-Host }

(AVP Code 264)Diameter Identity. The host name of the system wherethe message originated.

{ Origin-Realm }





(AVP Code 293)Diameter Identity. The hosts name of the system whereexactly the destination of the message is.

Auth-Application-Id(AVP code 504)

Octet String. Contains information that identifies theparticular service that the AF service session belongs to

[ Abort-Cause ]

(AVP code 500)

Enumerated. Determines the cause of an abort sessionrequest (ASR) or of a RAR indicating a PDP context

release




FN4243XEN80GLA0


68

3.3.8 Abort-Session-Answer (ASA)

The ASA command, indicated by the Command-Code field set to 274 and the 'R' bit

cleared in the Command Flags field, is sent by the AF to the PCRF in response to the ASR command.

Message Format:<AS-Answer> ::= < Diameter Header: 274, PXY >

< Session-Id >{ Origin-Host }{ Origin-Realm }[ Result-Code ][ Origin-State-Id ]

[ Error-Message ][ Error-Reporting-Host ]*[ Failed-AVP ]*[ Redirect-Host ]

[ Redirect-Host-Usage ][ Redirect-Max-Cache-Time ]*[ Proxy-Info ]

*[ AVP ]


< Session-Id >

(AVP Code 263)UTF8String. Used to identify a specific session; must

begin with the sender's identity.

{ Origin-Host }

(AVP Code 264)

Diameter Identity. The host name of the system where

the message originated.

{ Origin-Realm }


[ Result-Code ]


(AVP Code 298)

Unsigned32. Contains a vendor-assigned valuerepresenting the result of processing a request. The

Vendor-ID AVP shall be set to 3GPP (10415)





69

3.4 Rx specific Experimental-Result-Code AVP values

Result codes Name

5061 INVALID_SERVICE_INFORMATION

5062 FILTER_RESTRICTIONS

5063 REQUESTED_SERVICE_NOT_AUTHORIZED

5064 DUPLICATED_AF_SESSION

5065 IP-CAN_SESSION_NOT_AVAILABLE

5066 UNAUTHORIZED_NON_EMERGENCY_SESSION

5067 UNAUTHORIZED_SPONSORED_DATA_CONNECTIVITY

Additionally, Result-Code AVP values defined in Diameter BASE RFC 3588 areapplicable too.




FN4243XEN80GLA0


70

3.5 Signaling Flow over Rx Interface

GW PCRF P-CSCF

2. Define service

information

3. Rx AAR

4. Store Session Information

7. Identify affected Session

Store Session Information

Session Setup

Session Modification

1. Trigger

5. Rx AAA

6. Rx AAR

8. Rx AAA

Fig. 19





71

GW PCRF P-CSCF

Session

Termination

3. Rx STR

4. Identify IP- CAN sessions

5. Rx STA

Fig. 20

05 FN4243XEN80GLA0 App Gx Rx Interface

Documents

Transcript of 05 FN4243XEN80GLA0 App Gx Rx Interface