Professional Documents
Culture Documents
Camiant Inc
NASREQ Applications
EAP Applications
Mobile IP V4 Applications
Command-Name
Abbrev.
Code
Reference
Command-Name
Abbrev.
Code
Reference
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, where the vendor is 3GPP. The vendor identifier assigned by IANA to 3GPP (http://www.iana.org/assignments/enterprisenumbers) is 10415.
Some PCRF functions can be associated with a home network for the purpose of representing subscription and home based 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 a visited 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
Agent
Server
Discovery via DNS or Static Configuration A Capabilities Exchange message carries a peer's identity and its capabilities (protocol version number, supported Diameter applications, etc.). A Diameter node only transmits commands to peers that have advertised support for the Diameter application associated with the given command. 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.
Sessions
AF
PCRF
AGW
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.
SBBC Applications
AGW
Client
optional
Agent
PCRF
Server
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
CC Request CC Request
CCAnswer CC Answer
Easy Applications
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 basis (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 of the 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.
How does the PCRF know that no MS initiated Pull is coming for this session? How does the PCRF know that no AF initiated Push is coming for this bearer? Networks contain a varied mixture of terminals and clients. It virtually impossible to determine whether it is reasonable to expect a for a given IP classifier at a given time. 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
X X
X X X
X X X
Push and pull for a given transaction can arrive at different times. What timers would be needed? MS
PCRF
AF
MS
PCRF
AF
MS
PCRF
AF
MS 1
MS 2
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 can be used for application-level, access-network independent, admission control and charging rules can also push an IP-level enforcement envelope for bearers, e.g silver subscriber get 512 K for video streaming. IP QoS primitive can include per subscriber, per flow policing, shaping, and queuing
IP QoS gates
1 2 3
1 2 3
AGW
Diameter Subsessions
PCRF can use information on bearers for admission control of IP QoS and vice-versa
PCRF
Diameter Subsessions
MS
PCRF
AF
MS
PCRF
AF
UE-1
AGW
Ty
1. INVITE
PCRF
Tx
AF
(P-CSCF)
UE-2
4. Auth Request
6. Re-Auth Resp 7. Auth Response 8. 183 Progress (A1) 9. PRACK 10. PRACK 11. 200 OK (prack) 12. 200 OK (prack) 13. RAN QoS Request Bearer Establishment 14. Auth Request
RAN-QoS Gates created (opened)
15. Auth Resp 16. RAN QoS Resp 17. RAN QoS Request
RAN-QoS Gates created (opened)
18. Auth Request 19. Auth Resp 20. RAN QoS Resp 21. UPDATE 22. UPDATE 23. 200 OK (update) 24. 200 OK (update) 26. Auth Request 27. Re-Auth
(Open Gates)
Bearer Establishment
(open gates)