Southbound Rx Interface

Transcription

1 Overview, page 1 Diameter Adaptor Connectivity, page 1 Protocol Support, page 2 Diameter Connection Establishment, page 2 Diameter Base RFC Compliance, page 2 Rx Protocol Message Formats, page 2 Cisco Rx Protocol Specific Attributes, page 9 Overview MOG provides a Diameter-based southbound Rx interface for interaction with PCRF. The Rx interface supports the modification of the following QoS updates: Default bearer Dedicated bearer Sponsored data MOG includes application ID in Auth-Application-Id AVP and the vendor ID in the Vendor-Id AVP of the Vendor-Specific-Application-Id AVP contained in the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands. MOG creates a new Rx Session whenever a new API session is created for Update QoS API. All the commands on the Rx interface for the Rx Session include the session identifier of the Rx Session. The session-id AVP is populated with the session identifier. Diameter Adaptor Connectivity MOG supports two models for Diameter adaptor connectivity across Rx to PCRFs. 1

2 Protocol Support 1 Direct Connect. MOG establishes peer connections with the PCRFs. The Direct Connect model may be used when a DRA is not required to route the Rx session to a PCRF based on a binding. In this case, the PCRF to which MOG connects can locate the corresponding Gx session record for the UE, provided the Gx session exists in the network. 2 DRA Connect. MOG establishes peer connections with DRAs which route Rx messages to PCRFs based on UE bindings. DRA Connect is the more common model because bindings are typically required to route the Rx message to the same PCRF that handles the Gx sessions for the UE. Protocol Support The Cisco Enhanced Rx Policy Interface is based on the 3GPP Rx protocol. It uses both the Diameter Base (RFC 6733) and NASREQ Diameter Application (RFC 4005) messages. MOG acts as a Diameter client and PCRF acts as a Diameter server. The Diameter Application-ID used for the Cisco Enhanced Rx Policy Interface is , which is the Rx application IDas specified in 3GPP TS v12. Diameter Connection Establishment MOG supports diameter peer connections using TCP as the transport protocol. After establishing the peer connection, MOG and partner peer advertise the support of the appropriate diameter application using the Capability Exchange procedure. MOG advertises support for 3GPP (10415) and Cisco (9) vendor-specific attributes. MOG can be configured to establish multiple peer connections to a partner peer. This is sometimes useful to overcome performance limitations of a single peer connection. Each diameter peer connection will utilize the same IP address, but a different ephemeral port and a different Origin-Host. The value of the Session-Id AVP for each Rx session is unique to MOG. Diameter Base RFC Compliance The Cisco Enhanced Rx Policy Interface complies with RFC 6733 for Diameter Base. Restrictions on Diameter Base RFC Compliance MOG will not use the accounting messages defined in the Diameter Base protocol. The Session-Binding AVP is ignored by MOG. MOG uses the value of Origin-Host AVP received in the latest AAA or RAR as the Destination-Host AVP of the next request. Rx Protocol Message Formats The following sections describe the various messages used by the Rx Policy interface. 2

3 AA-Request (AAR) Note Some AVPs are Cisco vendor-specific AVPs that may appear in the message. Some AVPs are standard V12 AVPs, but are not expected to be exchanged between MOG and the PCRF for the mobility orchestration use cases. The AVPs should still be in the dictionary, and a PCRF is expected to support these other standard AVPs in order to successfully interoperate with other AFs. AA-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 MOG to the PCRF. <AA-Request> ::= < Diameter Header: 265, REQ, PXY > { Auth-Application-Id } { Destination-Realm } [ Destination-Host ] [ IP-Domain-Id ] [ 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 ] [ Dynamic-PCC-Requested-QoS ] [ MPS-Identifier ] [ Rx-Request-Type ] *[ Required-Access-Info ] *[ Route-Record ] 3

4 AA-Answer (AAA) Note 1 MOG identifies the UE to the PCRF via the Subscription-ID AVPs (1 as type IMSI and 1 as type E164) in the AAR message. 2 MOG populates the AF-Application-Identifier AVP have the value Dynamic-QoS i.e hex value of 44796e616d69632d516f53 in case of default bearer and will have the value OTT-Service-1 i.e hex value of 4f54542d d31 in case of dedicated bearer. 3 MOG populates the Application-Service-provider-Identifier AVP used for sponsored data connectivity with value UpdateQoS.<Tenant domain> where <Tenant domain> is the tenant domain of the subscriber who initated the request. For example, if the request is made by a subscriber of domain acme.com, the value is UpdateQoS.acme.com 4 MOG sends Specific-Action AVP in AAR message to arm event Triggers on PCRF: INDICATION_OF_LOSS_OF_BEARER (2) INDICATION_OF_RELEASE_OF_BEARER (4) INDICATION_OF_FAILED_RESOURCES_ALLOCATION (9) INDICATION_OF_SUCCESSFUL_RESOURCES_ALLOCATION (8) USAGE_REPORT (11), in case of Volume received in MOG API request. CUSTOM_DPCC_STATUS_REPORT (200), in case of MOG DPCC CRD configuration present. 5 MOG sends Dedicated-Bearer-QoS AVP in Dynamic-PCC-Requested-QoS AVP of AAR message when Service-Info-Status is FINAL_SERVICE_INFORMATION (0). For example: Dynamic-PCC-Requested-QoS: Dedicated-Bearer-QoS: QoS-Class-Identifier: Interactive (5) Allocation-Retention-Priority: Priority-Level: 3 Pre-emption-Capability: PRE-EMPTION_CAPABILITY_ENABLED (0) Pre-emption-Vulnerability: PRE-EMPTION_VULNERABILITY_DISABLED AA-Answer (AAA) The AAA command indicated by the Command-Code field set to 265 and the 'R' bit cleared in the Command Flags is sent by PCRF in response to an AAR command. 4

5 Re-Auth-Request (RAR) <AA-Answer> ::= < Diameter Header: 265, PXY > { Auth-Application-Id } [ 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 ] *[ Redirect-Host ] [ Redirect-Host-Usage ] [ Redirect-Max-Cache-Time ] Note 1 Origin Host AVP received in the message is stored and used to populate the Destination Host AVP in the next outgoing message for the Rx Session. 2 An AAA with a Result-Code AVP value of 2001 (DIAMETER_SUCCESS) does not reflect the success or failure of the requested action of the Rx AAR. It indicates that the PCRF was able to initiate the action as indicated by the AAR. For example, the PCRF was able to find a corresponding Gx session and send a Gx RAR to the PGW to boost APN-AMBR or set up a dedicated bearer. If the AAA indicates success (Result-Code = 2001), an Rx RAR may be sent after the PCRF completes the Gx (or Sd) interaction with indication of the results of the AAR request. If the AAA is sent with a Result-Code AVP indicating an error or failure (i.e. 30xx, 40xx, 50xx) then the PCRF was not able to initiate the action indicated by the AAR. If the AAR was the first request for this Rx session, then MOG removes the Rx session from its session database and does not send an STR. Re-Auth-Request (RAR) 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 PCRF to MOG. This command is used to indicate the results of a previous AAR or to notify MOG of some event. 5

6 Re-Auth-Answer (RAA) <RA-Request> ::= < Diameter Header: 258, REQ, PXY > { 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 ] [ 3GPP-User-Location-Info ] [ User-Location-Info-Time ] [ 3GPP-MS-TimeZone ] [ 3GPP-SGSN-MCC-MNC ] *[ Class ] *[ Route-Record ] Note 1 Origin Host AVP received in the message is stored and used to populate the Destination Host AVP in the next outgoing message for the Rx session. 2 For sponsored-data with a volume or time threshold, the volume or time usage is reported to MOG in the Sponsored-Connectivity-Data AVP when the threshold is breached. 3 Specific-Action AVP received in the message may contain CUSTOM_DPCC_STATUS_REPORT (200) in case MOG armed the event in AAR message. In this case, Dynamic-PCC-Parameter AVP will have Status-Report in Parameter-Name and Parameter-Value AVPs received from PCRF. For example: Specific-Action: CUSTOM_DPCC_STATUS_REPORT (200) Dynamic-PCC-Result: Result-Code: DIAMETER_SUCCESS (2001) Dynamic-PCC-Parameter: Parameter-Name: QoS-Class-Identifier Parameter-Value: 0 Dynamic-PCC-Parameter: Parameter-Name: Allocation-Retention-Priority Parameter-Value: 0 Dynamic-PCC-Parameter: Parameter-Name: APN-Aggregate-Max-Bitrate-DL Parameter-Value: 0 Dynamic-PCC-Parameter: Parameter-Name: APN-Aggregate-Max-Bitrate-UL Parameter-Value: 0 Parameter-Value 0 is success, 1 is failure and 2 is ignored 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 from MOG to PCRF in response to an RAR. 6

7 Session-Termination-Request (STR) <RA-Answer> ::= < Diameter Header: 258, PXY > [ Result-Code ] [ Experimental-Result ] *[ Media-Component-Description ] [ Service-URN ] *[ Class ] [ Error-Message ] [ Error-Reporting-Host ] *[ Redirect-Host ] [ Redirect-Host-Usage ] [ Redirect-Max-Cache-Time ] *[ Failed-AVP ] 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 MOG to the PCRF. <ST-Request> ::= < Diameter Header: 275, REQ, PXY > { Destination-Realm } { Auth-Application-Id } { Termination-Cause } [ Destination-Host ] *[ Required-Access-Info ] *[ Class ] *[ Route-Record ] Note Destination Host AVP is populated with the value received in the Origin Host AVP from PCRF in AAA or RAR. Sesson-Termination-Answer (STA) The STA command indicated by the Command-Code field set to 275 and the 'R' bit cleared in the Command Flags is sent by PCRF in response to an STR command. 7

8 Abort-Sesson-Request (ASR) <ST-Answer> ::= < Diameter Header: 275, PXY > [ Result-Code ] [ Error-Message ] [ Error-Reporting-Host ] *[ Failed-AVP ] [ Sponsored-Connectivity-Data ] [ 3GPP-User-Location-Info ] [ User-Location-Info-Time ] [ 3GPP-MS-TimeZone ] [ 3GPP-SGSN-MCC-MNC ] *[ Class ] *[ Redirect-Host ] [ Redirect-Host-Usage ] [ Redirect-Max-Cache-Time ] Note 1 For sponsored-data with a volume or time threshold, the volume or time usage is reported to the MOG in the Sponsored-Connectivity-Data AVP. Abort-Sesson-Request (ASR) The Abort-Session-Request (ASR) command, indicated by the Command-Code set to 274 and the 'R' bit set in the Command Flags field, is sent by PCRF to request MOG to terminate the Rx session identified by the Session-Id AVP. The MOG sends an Rx STR command to the PCRF in order to terminate the Rx session. Message Format <AS-Request> ::= < Diameter Header: 274, REQ, PXY > { Destination-Realm } { Destination-Host } { Auth-Application-Id } [ User-Name ] *[ Route-Record ] Abort-Sesson-Answer (ASA) The Abort-Session-Answer (ASR) command, indicated by the Command-Code set to 274 and the 'R' bit cleared in the Command Flags field, is sent by MOG in response to an ASR command. 8

9 Cisco Rx Protocol Specific Attributes Message Format <AS-Answer> ::= < Diameter Header: 274, PXY > { Result-Code } [ User-Name ] [ Error-Message ] [ Error-Reporting-Host ] * [ Failed-AVP ] * [ Redirect-Host ] [ Redirect-Host-Usage ] [ Redirect-Max-Cache-Time ] * [ Proxy-Info ] * [ AVP ] Cisco Rx Protocol Specific Attributes The Cisco enhanced Rx protocol uses the AVPs defined in the 3GPP Rx specification. Please refer to 3GPP TS for detailed description of such AVPs. Cisco Vendor Id (9) is used for the following Cisco AVPs AVP Name Vendor-ID AVP Code AVP Flag (Must) AVP Flag (Must Not) AVP Type Dynamic-PCC-Request-QoS V M,P Grouped Intention V M,P Enumerated Dynamic-PCC-Requested-QoS AVP The Dynamic-PCC-Requested-QoS AVP is a grouped AVP used to request modification of the default/dedicated bearer QoS. Dynamic-PCC-Requested-QoS ::= < AVP Header: > [ APN-Aggregate-Max-Bitrate- UL ] [ APN-Aggregate-Max-Bitrate-DL ] [ Default-EPS-Bearer-QoS ] [ Dedicated-EPS-Bearer-QoS ] [ Intention ] [ Dynamic-PCC-Parameter ] Default-EPS-Bearer-QoS ::= < AVP Header: 1049 > [ QoS-Class-Identifier ] [ Allocation-Retention-Priority ] Dedicated-Bearer-QoS ::= < AVP Header: > [ QoS-Class-Identifier ] [ Allocation-Retention-Priority ] Allocation-Retention-Priority ::= < AVP Header: 1034 > [ Priority-Level ] [ Pre-emption-Capability ] [ Pre-emption-Vulnerability ] Intention ::= < AVP Header: > Dynamic-PCC-Parameter::= < AVP Header: > [Parameter-Name] [Parameter-Value] 9

10 Dynamic-PCC-Result Note If both the Predefined-QoS-Name and other attributes are specified in the Dynamic-PCC-Requested-QoS grouped AVP, the requested QoS is the QoS as defined in the Predefined-QoS-Name with overrides of the values of the individual attributes. If Service-Info-Status is PRELIMINARY SERVICE INFORMATION (1), Default-EPS-Bearer-QoS AVP is present in Dynamic-PCC-Requested-QoS AVP of AAR message and if Service-Info-Status is FINAL SERVICE INFORMATION (0), Dedicated-Bearer-QoS AVP is present in Dynamic-PCC-Requested-QoS AVP of AAR message. Dynamic-PCC-Result The Dynamic-PCC-Result AVP is a grouped AVP used to see the result of the default/dedicated bearer QoS modification. Dynamic-PCC-Result ::= < AVP Header: > [ Result-Code ] [ Error-Message ] [ Default-EPS-Bearer-QoS] [ APN-Aggregate-Max-Bitrate-UL ] [ APN-Aggregate-Max-Bitrate-DL ] [ Dynamic-PCC-Parameter ] Default-EPS-Bearer-QoS ::= < AVP Header: 1049 > [ QoS-Class-Identifier ] [ Allocation-Retention-Priority ] Allocation-Retention-Priority ::= < AVP Header: 1034 > [ Priority-Level ] [ Pre-emption-Capability ] [ Pre-emption-Vulnerability ] Dynamic-PCC-Parameter::= < AVP Header: > [Parameter-Name] [Parameter-Value] 10