Diameter and SBBC Concepts

1. Diameter and SBBC Concepts Camiant Inc

2. Base Protocol and Applications Credit Control Applications Other 3GPP Cx, Dx, Sh, Ro, Rf NASREQ Applications EAP Applications Mobile IP V4 Applications DIAMETER Base Protocol DIAMETER Base Commands • The Diameter Base Protocol provides reliable transport and delivery of messages • The Base Protocol must be used along with an application

3. Tx, and Ty Applications Credit Control Applications Tx Application Ty Application Other 3GPP Cx, Dx, Sh, Ro, Rf NASREQ Applications EAP Applications Mobile IP V4 Applications DIAMETER Base Protocol 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 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 Need to define an application ID For Ty

4. Diameter Node Types Diameter Peers Diameter peers, the set of Diameter nodes with which a given Diameter node will directly communicate, may be statically 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, 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.

5. 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 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. Capabilities Exchange Request Capabilities Exchange Answer Capabilities Exchange Answer Device Watchdog Request 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. Device Watchdog Answer Request Request Answer 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. Answer

6. 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.

7. SBBC Applications

8. SBBC Authorization on Initial Attach Client Agent Server Peer Discovery Peer Discovery Capabilities Exchange Request Capabilities Exchange Request Capabilities Exchange Answer Capabilities Exchange Answer Device Watchdog Request Device Watchdog Answer CC Request CC Request CCAnswer CC Answer • 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 all transaction 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 PCRF optional

9. “Easy” Applications 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? 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?

10. Push/ Pull Applications 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? Network’s 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. Network’s 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. Push and pull for a given transaction can arrive at different times. What timers would be needed? How can the PCRF correlate the IP Classifier from the AF with the TFT from an MS initiated Bearer initiation/modification MS PCRF AF MS PCRF AF MS PCRF AF Subsequent AF sessions may use the same bearer. i.e. AF and bearer session tear down are currently not coordinated Push arrives at PCRF before Pull Push arrives at PCRF after Pull Push arrives at PCRF at the same time as Pull

11. “Independent Push/Pull” Policy and Charging Rules TCP or SCTP Transport Diameter Session IDs created at MS attach • 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 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 Diameter Sub-Session IDs created from AF Push MS 1 Diameter Sub-Session IDs created at bearer creation Diameter Sub-Session IDs created from AF Push MS 2 Diameter Sub-Session IDs created at bearer creation

12. “Independent Push/Pull” Policy and Charging Rules 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 get 512Kbs 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 Subscriber RABs “Pi” Interface Per subscriber R-P interface with IP QoS AF packets 1 2 3 1 2 3 1 2 3 AGW PCRF Diameter Subsessions Diameter Subsessions

13. Application-level Event Sequencing • If Correlation of AF and Bearer are important, the operator can impose application-level event sequencing – i.e. client application logic ensures that push arrives before pull or vice-versa 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 MS PCRF AF 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 MS PCRF AF Subscriber must have use an AF for Video Subscriber must have a Video Bearer to use AF