1 Gx Interface Overview
This document describes the standard 3GPP Gx interface used between a Policy and Charging Enforcement Function (PCEF) client and the SAPC.
This document also describes the Ericsson Gx+ interface used between an Ericsson PCEF (for example EPG) and the SAPC.
3GPP Gx is built over the Diameter Base Protocol RFC. The SAPC supports 3GPP Gx Rel9 onwards.
For detailed support about 3GPP Release versions of 3GPP TS 29.212, refer to the corresponding Statement of Compliance documents.
It also describes the Ericsson proprietary AVP extensions (Ericsson Gx+ interface) that can be used between an Ericsson PCEF and the SAPC.
1.1 Document Content Conventions
This document contains the specific details supported by the SAPC implementation.
This document does not repeat information that can be found in 3GPP Technical Specifications or Diameter Base Protocol RFC.
For detailed information about Statement of Compliance towards different 3GPP Release versions (for example Rel13, Rel14 and so on), see the corresponding SoCs documents.
Each message is described with the list of parameters (AVPs) exchanged between the Diameter peers.
- For incoming messages received in the SAPC,
this document only indicates the AVPs that the SAPC reads to perform
the corresponding business logic or evaluation inside policy conditions.
The SAPC can receive other AVPs (but does not use them) that can be found in 3GPP Technical Specifications, but are not stated in this document. This is possible because the SAPC uses a dictionary that specifies the format of messages and AVPs. The SAPC behaves in the following way (standard Diameter Base Protocol behavior):
- If the SAPC receives in a message an AVP with M bit set to 1, and that AVP is not included in the dictionary, the SAPC rejects the message indicating DIAMETER_AVP_UNSUPPORTED.
- If the SAPC receives in a message an AVP defined in the dictionary, but with different values in the flag bits, the SAPC rejects the message indicating DIAMETER_INVALID_AVP_BITS.
- If the SAPC receives in a message an AVP with M bit set to 0, ant that AVP is not defined in the dictionary, the SAPC does not reject the message, but ignores the AVP value.
- For outgoing messages (and AVPs) sent by the SAPC, this document indicates only the AVPs that the SAPC fills.
- Note:
- When the SAPC does not support a message or AVP for all 3GPP Release versions, it is explicitly indicated in this document.
2 Gx Interface Message Exchange
For an example of the Gx Diameter message exchange in the communication between a PCEF and the SAPC, see Figure 1:
3 Diameter Base Protocol Messages
3.1 Gx Capability Negotiation
The following table lists the AVPs that the SAPC supports in a CER message.
|
AVP Name |
AVP Code |
Comment |
Reference |
|---|---|---|---|
|
* [ Acct-Application-Id ] |
259 |
- |
RFC 6733 |
|
* [ Auth-Application-Id ] |
258 |
- |
RFC 6733 |
|
[ Firmware-Revision ] |
367 |
- |
RFC 6733 |
|
1* { Host-IP-Address } |
257 |
- |
RFC 6733 |
|
{ Origin-Host } |
264 |
- |
RFC 6733 |
|
{ Origin-Realm } |
296 |
- |
RFC 6733 |
|
{ Product-Name } |
269 |
- |
RFC 6733 |
|
* [ Supported-Vendor-Id ] |
265 |
- |
RFC 6733 |
|
{ Vendor-Id } |
266 |
- |
RFC 6733 |
|
*[ Vendor-Specific- Application-Id ] |
260 |
- |
RFC 6733 |
Table 2 lists the AVPs that the SAPC sends in a CEA message.
|
AVP Name |
AVP Code |
Comment |
Reference |
|---|---|---|---|
|
*[ Auth-Application-Id ] |
258 |
RFC 6733 | |
|
[ Error-Message ] |
281 |
- |
RFC 6733 |
|
[ Failed-AVP ] |
279 |
RFC 6733 | |
|
[ Firmware-Revision ] |
267 |
- |
RFC 6733 |
|
1*{ Host-IP-Address } |
257 |
- |
RFC 6733 |
|
{ Origin-Host } |
264 |
- |
RFC 6733 |
|
{ Origin-Realm } |
296 |
- |
RFC 6733 |
|
{ Product-Name } |
269 |
- |
RFC 6733 |
|
{ Result-Code } |
268 |
- |
RFC 6733 |
|
*[ Supported-Vendor-Id ] |
265 |
According to configuration, the SAPC sends the values assigned to other supported vendors different from the vendor device (Ericsson):
|
RFC 6733 |
|
{ Vendor-Id } |
266 |
The SAPC sets it to value 193 (Ericsson). |
RFC 6733 |
|
*[ Vendor-Specific- Application-Id ] |
260 |
According to configuration, the SAPC sends the following AVP values: |
RFC 6733 |
3.2 Device Watchdog
Table 3 lists the AVPs that the SAPC can receive or send in a DWR message.
|
AVP Name |
AVP Code |
Comment |
Reference |
|---|---|---|---|
|
{ Origin-Host } |
264 |
- |
RFC 6733 |
|
{ Origin-Realm } |
296 |
- |
RFC 6733 |
|
[ Origin-State-Id ] |
278 |
- |
RFC 6733 |
Table 4 lists the AVPs that the SAPC can receive or send in a DWA message.
|
AVP Name |
AVP Code |
Comment |
Reference |
|---|---|---|---|
|
[ Error-Message ] |
281 |
- |
RFC 6733 |
|
[ Failed-AVP ] |
279 |
- |
RFC 6733 |
|
{ Origin-Host } |
264 |
- |
RFC 6733 |
|
{ Origin-Realm } |
296 |
- |
RFC 6733 |
|
[ Origin-State-Id ] |
278 |
- |
RFC 6733 |
3.3 Disconnect Peer
Table 5 lists the AVPs that the SAPC supports in a DPR message.
|
AVP Name |
AVP Code |
Comment |
Reference |
|---|---|---|---|
|
{ Origin-Host } |
264 |
- |
RFC 6733 |
|
{ Origin-Realm } |
296 |
- |
RFC 6733 |
|
{ Disconnect-Cause } |
273 |
- |
RFC 6733 |
Table 6 lists the AVPs that the SAPC supports in a DPA message.
|
AVP Name |
AVP Code |
Comment |
Reference |
|---|---|---|---|
|
[ Error-Message ] |
281 |
- |
RFC 6733 |
|
[ Failed-AVP ] |
279 |
- |
RFC 6733 |
|
{ Origin-Host } |
264 |
- |
RFC 6733 |
|
{ Origin-Realm } |
296 |
- |
RFC 6733 |
|
{ Result-Code } |
268 |
- |
RFC 6733 |
4 Gx Interface Controls and AVP Relations
The SAPC supports several policy control functions. The SAPC can execute such policy control functions based on:
- Configuration of the corresponding control (enabled or not) in the SAPC
- The values received in the Supported-Features AVP
- For Ericsson Gx+, the value received in the Gx-Capability-List AVP (Section 8.2) for the control
The SAPC sends such control related information through the Gx interface that is applicable to the requesting PCEF only when the SAPC gets values to return. For more information on the AVPs, see Table 7.
Table 7 summarizes the AVPs that are included in the SAPC Gx interface messages for every control function.
|
Control |
Related AVPs |
|
IP-CAN Session Access Control |
If the trigger is the reception of a CCR:
If the trigger is an internal reauthorization, and the session terminates, the SAPC sends a RAR containing Session-Release-Cause = UE_SUBSCRIPTION_REASON. |
|
Service Access Control |
Charging-Rule-Authorization AVP Charging-Rule-Install AVP, including: Charging-Rule-Definition AVP (for preconfigured or dynamic services). The charging information is included depending on the Service Charging Control. Bearer-Identifier AVP Charging-Rule-Remove AVP, including: Related to ToD, and when the PCEF is the time controller: |
|
Bearer QoS Control |
QoS-Information AVP Default-EPS-Bearer-QoS AVP |
|
Subscriber Charging Control |
3GPP-Charging-Characteristics AVP Charging-Information AVP |
|
Service Charging Control |
Charging-Rule-Install AVP, including: |
|
Usage Reporting |
Usage-Monitoring-Information AVP |
|
Content Filtering Control |
Content-Filtering-Profile-Id AVP |
(1) In the SAPC, in 3GPP accesses, it is mandatory to receive
a QoS-Information or Default-EPS-Bearer-QoS AVP in the CCR Initial message.
5 Gx Interface Message Format
5.1 Gx Credit-Control-Request (CCR)
Table 8 lists the AVPs that the SAPC supports in a CCR message.
|
AVP Name |
AVP Code |
Comment |
Reference |
|---|---|---|---|
|
< Session-Id > |
263 |
- |
RFC 6733 |
|
[ 3GPP-Charging-Characteristics ] |
13 |
3GPP-Charging-Characteristics AVP is of type UTF8String and is defined according to 3GPP TS 29 061 (Reference [3]) and transformed into a Diameter AVP. |
|
|
[ 3GPP-MS-TimeZone ] |
23 |
- |
|
|
[ 3GPP-SGSN-MCC-MNC ] |
18 |
- |
|
|
[ 3GPP-SGSN-Address ] |
6 |
- |
|
|
[ 3GPP-SGSN-IPv6-Address ] |
15 |
- |
|
|
[ 3GPP-User-Location-Info ] |
22 |
- |
|
|
0*2[ AN-GW-Address ] |
1050 |
- |
|
|
[ AN-Trusted ] |
1503 |
- |
|
|
*[ Application-Detection-Information ](1) |
1098 |
The SAPC supports the following AVPs:
|
|
|
{ Auth-Application-Id } |
258 |
- |
|
|
[ Bearer-Identifier ] |
1020 |
- |
|
|
[ Bearer-Operation ] |
1021 |
- |
|
|
[ Bearer-Usage ] |
1000 |
- |
|
|
[ Called-Station-Id ] |
30 |
- |
See RFC 4005 |
|
{ CC-Request-Number } |
415 |
- |
RFC 4006 |
|
{ CC-Request-Type } |
416 |
- |
RFC 4006 |
|
*[ Charging-Rule-Report ] |
1018 |
See Section 6.3 |
|
|
[ Default-EPS-Bearer-QoS ] |
1049 |
See Section 6.5 |
|
|
{ Destination-Realm } |
283 |
- |
RFC 6733 |
|
[ Destination-Host ] |
293 |
- |
RFC 6733 |
|
*[ Event-Trigger ] |
1006 |
The SAPC supports the following values:
|
|
|
[ Framed-IP-Address ](2) |
8 |
The SAPC identifies the subscriber IP-CAN session using Framed-IP-Address AVP together with Called-Station-Id AVP and Subscription-Id AVP. |
RFC 4005 |
|
[ Framed-IPv6-Prefix ] |
97 |
The SAPC identifies the subscriber IP-CAN session using Framed-IPv6-Prefix AVP together with Called-Station-Id AVP and Subscription-Id AVP. |
RFC 4005 |
|
[ IP-CAN-Type ] |
1027 |
The SAPC supports the following values:
|
|
|
[ Network-Request-Support ] |
1024 |
- |
|
|
{ Origin-Host } |
264 |
- |
RFC 6733 |
|
{ Origin-Realm } |
296 |
- |
RFC 6733 |
|
[ Origin-State-Id ] |
278 |
- |
RFC 6733 |
|
[ Presence-Reporting-Area-Information ] |
2822 |
See Section 6.7 |
|
|
[ QoS-Information ] |
1016 |
See Section 6.4. |
|
|
[ QoS-Negotiation ] |
1029 |
- |
|
|
[ QoS-Upgrade ] |
1030 |
- |
|
|
[ RAI ] |
909 |
- |
|
|
[ RAT-Type ] |
1032 |
- |
|
|
*[ Subscription-Id ] |
443 |
If the SAPC receives several instances of this AVP, it uses:
For IP-CAN sessions restricted to IMS emergency services, Subscription-Id AVP is optional in the CCR INITIAL message. If Subscription-Id AVP is not received, the CCR INITIAL message must include the IMEISV within the User-Equipment-Info AVP. |
RFC 4006 |
|
*[ Supported-Features ] |
628 |
See Section 6.1. |
TS 29.229 |
|
[ TWAN-Identifier ] |
29 |
- |
|
|
[ TDF-Information ] |
1087 |
See Section 6.8. |
|
|
[ TCP-Source-Port ] |
2843 |
- |
|
|
[ UDP-Source-Port ] |
2806 |
- |
|
|
[ UE-Local-IP-Address ] |
2805 |
- |
|
|
*[ Usage-Monitoring-Information ] |
1067 |
- |
|
|
[ User-Equipment-Info ] |
458 |
- |
RFC 4006 |
|
[ User-Location-Info-Time ] |
2812 |
(1) If the CCR-U includes the Flow-Information AVPs, then it should also include the TDF-Application-Instance-Identifier AVP. If that situation happens, no error is returned, because the SAPC does
not use the contents of the Flow-Information AVPs.
(2) Framed-IP-Address (or Framed-IPv6-Prefix) and Subscription-Id AVPs are mandatory to be received for the SAPC in
CCR INITIAL message. Otherwise, the SAPC returns Result-Code AVP set to DIAMETER_MISSING_AVP.
(3) When both Framed-IP-Address and Framed-IPv6-Prefix AVPs are received,
an IPv4v6 dual stack IP-CAN session is created.
Once there are ongoing Gx sessions in the SAPC, and the first CCR is received, do not change the value sent in the Origin-Host AVP for the subsequent CCR messages. Otherwise, the SAPC can answer these CCR messages with an UNABLE_TO_COMPLY (5012) error that can lead to service outage.
5.2 Gx Credit-Control-Answer (CCA)
Table 9 lists the AVPs that the SAPC sends in a CCA message.
|
AVP Name |
AVP Code |
Comment |
Reference |
|---|---|---|---|
|
< Session-Id > |
263 |
- |
RFC 6733 |
|
{ Auth-Application-Id } |
258 |
- |
|
|
[ Bearer-Control-Mode ] |
1023 |
For CCA Initial, the SAPC sets its value to:
For CCA updates, the SAPC include this AVP only if Network-Request-Support AVP was received in the CCR, and sets its value to: |
|
|
{ CC-Request-Number } |
415 |
||
|
{ CC-Request-Type } |
416 |
||
|
[ Charging-Information ] |
618 |
- |
TS 29.229 |
|
*[ Charging-Rule-Install ] |
1001 |
See Section 6.2. |
|
|
*[ Charging-Rule-Remove ] |
1002 |
- |
|
|
[ Default-EPS-Bearer-QoS ] |
1049 |
See Section 6.5. |
|
|
*[ Event-Trigger ] |
1006 |
The SAPC includes this AVP in the CCA Initial and CCA Update messages. The SAPC provides a new complete list of applicable event triggers for adding new event triggers or removing provisioned event triggers. If the SAPC does not include the Event-Trigger AVP in the CCA message, the previously provisioned event triggers are still applicable. If the SAPC includes the value NO_EVENT_TRIGGERS (14) in the CCA message, the previously provisioned event triggers are removed. See eventTriggers. |
|
|
[ Experimental-Result ] |
297 |
- |
RFC 6733 |
|
[ Failed-AVP ] |
279 |
- |
RFC 6733 |
|
[ Offline ] |
1008 |
- |
|
|
[ Online ] |
1009 |
- |
|
|
{ Origin-Host } |
264 |
- |
RFC 6733 |
|
{ Origin-Realm } |
296 |
- |
RFC 6733 |
|
[ Presence-Reporting-Area-Information ] |
2822 |
See Section 6.7 |
|
|
[ Origin-State-Id ] |
278 |
The SAPC increments its value in standalone mode after restart. In geographical redundancy, the SAPC does not increment its value unless both peers are down. This MUST never happen, as the SAPC does a transparent switch-over (the Diameter peer always sees an operative SAPC, the one in active state). |
RFC 6733 |
|
[ QoS-Information ] |
1016 |
See Section 6.4. |
|
|
[ Result-Code ] |
268 |
- |
RFC 6733 |
|
[ Revalidation-Time ] |
1042 |
- |
|
|
*[ Supported-Features ] |
628 |
- |
TS 29.229 |
|
*[ Usage-Monitoring-Information ] |
1067 |
See Section 6.6. |
5.3 Gx Re-Authorization-Request (RAR)
Table 10 lists the AVPs that the SAPC sends in a RAR message.
|
AVP Name |
AVP Code |
Comment |
Reference |
|---|---|---|---|
|
< Session-Id > |
263 |
- |
RFC 6733 |
|
{ Auth-Application-Id } |
258 |
- |
|
|
*[ Charging-Rule-Install ] |
1001 |
See Section 6.2. |
|
|
*[ Charging-Rule-Remove ] |
1002 |
- |
|
|
[ Default-EPS-Bearer-QoS ] |
1049 |
See Section 6.5. |
|
|
*[ Event-Trigger ] |
1006 |
The SAPC provides a new complete list of applicable event triggers for adding new event triggers or removing provisioned event triggers. If the SAPC does not include the Event-Trigger AVP in the RAR message, the previously provisioned event triggers are still applicable. If the SAPC includes the value NO_EVENT_TRIGGERS (14) in the RAR message, the previously provisioned event triggers are removed. See eventTriggers. |
|
|
{ Destination-Host } |
293 |
- |
RFC 6733 |
|
{ Destination-Realm } |
283 |
- |
RFC 6733 |
|
{ Origin-Host } |
264 |
- |
RFC 6733 |
|
{ Origin-Realm } |
296 |
- |
RFC 6733 |
|
[ Origin-State-Id ] |
278 |
The SAPC increments its value in standalone mode after restart. In geographical redundancy, the SAPC does not increment its value unless both peers are down. This MUST never happen, as the SAPC does a transparent switch-over (the Diameter peer always sees an operative SAPC, the one in active state). |
RFC 6733 |
|
[ QoS-Information ] |
1016 |
See Section 6.4. |
|
|
{ Re-Auth-Request-Type } |
285 |
The SAPC supports the following values:
|
RFC 6733 |
|
[ Revalidation-Time ] |
1042 |
- |
|
|
[ Session-Release-Cause ] |
1045 |
The SAPC supports the following values:
|
|
|
*[ Usage-Monitoring-Information ] |
1067 |
See Section 6.6. |
5.4 Gx Re-Authorization-Answer (RAA)
The SAPC does not read any AVPs received in RAA answers, except the AVPs shown in Table 11:
|
AVP Name |
AVP Code |
Comment |
Reference |
|---|---|---|---|
|
0*2[ AN-GW-Address ] |
1050 |
- |
|
|
[ AN-Trusted ] |
1503 |
- |
|
|
[ Experimental-Result ] |
297 |
The SAPC supports the following value within Experimental-Result-Code AVP:
|
|
|
[ IP-CAN-Type ] |
1027 |
See Table 8. |
|
|
[ NetLoc-Access-Support ] |
2824 |
It is present when NetLoc is requested by the AF, but the IP-CAN session does not support NetLoc. |
|
|
[ RAT-Type ] |
1032 |
- |
|
|
[ Result-Code ] |
268 |
The SAPC supports the following values:
|
RFC 6733 |
6 Gx Interface AVPs
The following subsections contain information about AVPs, that owing to space reasons, cannot be explained in the message tables of Section 5.
6.1 Gx Supported-Features
Depending on the information received from the PCEF in the Feature-List AVP within the Supported-Features AVP, the SAPC decides the release feature used in Gx, according to Table 12.
- Note:
- The SAPC includes the Supported-Features AVP only when the Result-Code AVP value is 2001 (SUCCESS). The SAPC does not send a Supported-Features AVP if the Result-Code AVP value is different from 2001 (SUCCESS).
|
Feature |
Received and sent Features-List AVP bit values, inside Supported-Features AVP with Feature-List-ID 1 |
|---|---|
|
If the SAPC receives bit 23 = 1 in CCR command and the PRA function is enabled, the SAPC answers CCA including bit 23 = 1. | |
|
Pending Transaction |
If the SAPC receives bit 16 = 1 in CCR command, it answers CCA including bit 16 = 1. |
|
NetLoc-Untrusted-WLAN |
If the SAPC receives bit 30 = 1 in CCR command and the NetLoc function is enabled, the SAPC answers CCA including bit 30 = 1. It requires that the SAPC also receives bit 10 = 1. |
|
NetLoc |
If the SAPC receives bit 10 = 1 in CCR command and the NetLoc function is enabled, the SAPC answers CCA including bit 10 = 1. |
|
If the SAPC receives bit 6 = 1 in CCR command and the ADC Rule function is enabled, the SAPC answers CCA including bit 6 = 1. | |
|
ProvAFsignalFlow |
If the SAPC receives bit 2 = 1 in CCR command and the dynamic policy control function is enabled, the SAPC answers CCA including bit 2 = 1. |
|
Gx Rel10 onwards |
If the SAPC receives from the PCEF in CCR command: Supported-Features
{ Vendor-Id = 10415 }
{ Feature-List-ID = 1 }
{ Feature-List
bit 0 = x (any value)
bit 1 = x (any value)
bit 3 = 1
rest of bits = x (any value)}the SAPC answers CCA including: Supported-Features
{ Vendor-Id = 10415 }
{ Feature-List-ID = 1 }
{ Feature-List
bit 0 = x (same value than received in CCR)
bit 1 = x (same value than received in CCR)
bit 3 = 1
rest of bits = 0 }
|
|
Gx Rel9 |
If the SAPC receives from the PCEF in CCR command: Supported-Features
{ Vendor-Id = 10415 }
{ Feature-List-ID = 1 }
{ Feature-List
bit 0 = x (any value)
bit 1 = 1
bit 3 = 0
rest of bits = x (any value)}the SAPC answers CCA including: Supported-Features
{ Vendor-Id = 10415 }
{ Feature-List-ID = 1 }
{ Feature-List
bit 0 = x (same value than received in CCR)
bit 1 = 1
bit 3 = 0
rest of bits = 0 }
|
|
Gx Rel8 |
If the SAPC receives from the PCEF in CCR command: Supported-Features
{ Vendor-Id = 10415 }
{ Feature-List-ID = 1 }
{ Feature-List
bit 0 = 1
bit 1 = 0
bit 3 = 0
rest of bits = x (any value)}the SAPC answers CCA with Result-Code AVP set to DIAMETER_INVALID_AVP_VALUE, and including Supported-Features AVP inside Failed-AVP AVP. |
|
Gx Rel7 |
If the SAPC receives from a PCEF a Gx message without Supported-Features AVP, the SAPC responds with Result-Code AVP set to DIAMETER_MISSING_AVP, including Supported-Features AVP inside Failed-AVP AVP. |
|
Feature |
Received and sent Features-List AVP bit values, inside Supported-Features AVP with Feature-List-ID 2 |
|---|---|
|
Extended-BW-NR |
If the SAPC receives bit 7 = 1 in CCR command and the extended bit rates over Gx function is licensed, the SAPC answers CCA including bit 7 = 1. |
6.2 Charging-Rule-Install AVP
|
AVP Name |
AVP Code |
Comment |
Reference |
|---|---|---|---|
|
[ Bearer-Identifier ] |
1020 |
The SAPC includes Bearer-Identifier AVP only for UE_ONLY bearer control mode, and if it was received from the PCEF. |
|
|
*[ Charging-Rule-Base-Name ] |
1004 |
- |
|
|
*[ Charging-Rule-Definition ] |
1003 |
The Charging-Rule-Install AVP can contain several Charging-Rule-Definition AVPs that define PCC rules for service data flows that use IPv4, IPv6 or both. The flows for a PCC rule are sent in one or several Flow-Information AVPs inside the same Charging-Rule-Definition AVP, according to the PCC rule information configured in the SAPC. For PCC rules derived from AF, the SAPC includes several Charging-Rule-Definition AVPs (one per media subcomponent) inside a Charging-Rule-Install AVP. See Section 6.2.1. |
|
|
*[ Charging-Rule-Name ] |
1005 |
- |
|
|
[ Resource-Allocation- Notification ] |
1063 |
The SAPC supports the following values:
|
|
|
[ Rule-Activation-Time ] |
1043 |
- |
|
|
[ Rule-Deactivation-Time ] |
1044 |
- |
6.2.1 Charging-Rule-Definition AVP
|
AVP Name |
AVP Code |
Comment |
Reference |
|---|---|---|---|
|
[ AF-Charging-Identifier ] |
505 |
- |
|
|
[ AF-Signalling-Protocol ] |
529 |
- |
|
|
{ Charging-Rule-Name } |
1005 |
- |
|
|
*[ Flow-Information ] |
1058 |
The SAPC sends the following AVPs:
|
|
|
[ Flow-Status ] |
511 |
The SAPC sets it to ENABLED for preconfigured PCC rules. The SAPC sends the value received from Rx interface for dynamic PCC rules. |
|
|
*[ Flows ] |
510 |
- |
|
|
[ Metering-Method ] |
1007 |
It is configured in the SAPC at service level. |
|
|
[ Mute-Notification ](1) |
2809 |
- |
|
|
[ Offline ] |
1008 |
It is set in the SAPC at service level. |
|
|
[ Online ] |
1009 |
It is set in the SAPC at service level. |
|
|
[ Precedence ] |
1010 |
See Section 6.2.1.2. |
|
|
[ QoS-Information ] |
1016 |
It can be set in the SAPC at service level or derived from AF information. |
|
|
[ Rating-Group ] |
432 |
It is set in the SAPC at service level. |
RFC 4006 |
|
[ Redirect-Information ] |
1085 |
The SAPC sends the following AVPs: [Redirect-Support] [Redirect-Address-Type] [Redirect-Server-Address] |
|
|
*[ Required-Access-Info ] |
536 |
The SAPC sets this AVP only when the AF requests the SAPC to report Access Network Information. |
|
|
[ Reporting-Level ] |
1011 |
The SAPC supports the following values:
It is configured in the SAPC at service level. |
|
|
[ Service-Identifier ] |
439 |
It is configured in the SAPC at service level. |
RFC 4006 |
|
[ TDF-Application-Identifier ](2) |
1088 |
- |
(1) The reported value in the Mute-Notification AVP towards the PCEF does
not change during the life time of the PCC rule.
(2) The SAPC sends either Flow-Information AVPs or
TDF-Application-Identifier AVP in the same Charging-Rule-Definition
AVP.
6.2.1.1 Flow-Description AVP
The Flow-Description AVP is used to describe a single IP flow.
The values returned by the SAPC in this AVP depend on a combination of what is configured in the SAPC at service level and what it is received in the incoming CCR.
- The values returned by the SAPC in the Flow-Description AVP are:
- Direction: 'out'.
- Source address taken from the configured address.
- Source port taken from the configured ports.
- Destination address is completed with the IP address of the UE (Framed-IP-Address AVP for IPv4 scenarios, or from Framed-IPv6-Prefix AVP for IPv6 scenarios). However, this does not happen for IP flows received in the Flow-Description AVP through the Rx interface that is downloaded transparently over the Gx interface.
- Destination port taken from the configured ports.
6.2.1.2 Precedence AVP
The SAPC uses the following mechanism to calculate the value of this AVP:
|
bit 7 |
bit 6 |
bit 5 |
bit 4 |
bit 3 |
bit 2 |
bit 1 |
bit 0 |
|
Configurable for preconfigured PCC rules |
Dynamic part | ||||||
The dynamic part is calculated for preconfigured and dynamic PCC rules depending on the completeness of downlink filters.
6.3 Charging-Rule-Report AVP
|
AVP Name |
AVP Code |
Comment |
Reference |
|---|---|---|---|
|
[ Bearer-Identifier ] |
1020 |
- |
|
|
*[ Charging-Rule-Base-Name ] |
1004 |
- |
|
|
*[ Charging-Rule-Name ] |
1005 |
- |
|
|
[ PCC-Rule-Status ] |
1019 |
The SAPC supports the following values:
|
|
|
[ Rule-Failure-Code ] |
1031 |
The SAPC supports the following values:
|
(1) On reception of a service
data flow deactivation due to PS to CS handover, the SAPC informs
the AF with Abort-Cause=PS_TO_CS_HANDOVER. For any other rule
code value, SAPC sends to AF Abort-Cause=BEARER_RELEASE
6.4 QoS-Information AVP
The SAPC can receive the requested (negotiated) QoS in the network from the PCEF, included in the QoS-Information AVP in a CCR message.
Whenever the SAPC calculates an authorized QoS, its value is always included in the QoS-Information AVP in CCA or RAR commands.
|
AVP Name |
AVP Code |
Comment |
Reference |
|---|---|---|---|
|
[ Allocation-Retention-Priority ] |
1034 |
- |
|
|
[ APN-Aggregate-Max-Bitrate-DL ] |
1040 |
- |
|
|
[ APN-Aggregate-Max-Bitrate-UL ] |
1041 |
- |
|
|
[ Bearer-Identifier ] |
1020 |
The SAPC includes Bearer-Identifier AVP, if it was received from the PCEF in the CCR messages. |
|
|
[ Extended-APN-AMBR-DL ] |
2848 |
The SAPC includes Extended-APN-AMBR-DL AVP instead of APN-Aggregate-Max-Bitrate-DL if the bandwidth value sent to the PCEF is higher than 232-1 bps. |
|
|
[ Extended-APN-AMBR-UL ] |
2849 |
The SAPC includes Extended-APN-AMBR-UL AVP instead of APN-Aggregate-Max-Bitrate-UL if the bandwidth value to be sent to the PCEF is higher than 232-1 bps. |
|
|
[ Extended-GBR-DL ] |
2850 |
The SAPC includes Extended-GBR-DL AVP instead of Guaranteed-Bitrate-DL if the bandwidth value sent to the PCEF is higher than 232-1 bps. |
|
|
[ Extended-GBR-UL ] |
2851 |
The SAPC includes Extended-GBR-UL AVP instead of Guaranteed-Bitrate-UL if the bandwidth value sent to the PCEF is higher than 232-1 bps. |
|
|
[ Extended-Max-Requested-BW-DL ] |
554 |
The SAPC includes Extended-Max-Requested-BW-DL AVP instead of Max-Requested-Bandwidth-DL if the bandwidth value sent to the PCEF is higher than 232-1 bps. |
|
|
[ Extended-Max-Requested-BW-UL ] |
555 |
The SAPC includes Extended-Max-Requested-BW-UL AVP instead of Max-Requested-Bandwidth-UL if the bandwidth value sent to the PCEF is higher than 232-1 bps. |
|
|
[ Guaranteed-Bitrate-DL ] |
1025 |
- |
|
|
[ Guaranteed-Bitrate-UL ] |
1026 |
- |
|
|
[ Max-Requested-Bandwidth-DL ] |
515 |
- |
|
|
[ Max-Requested-Bandwidth-UL ] |
516 |
- |
|
|
{ QoS-Class-Identifier } |
1028 |
- |
- Note:
- The SAPC includes Max-Requested-Bandwidth-DL and Max-Requested-Bandwidth-UL AVPs in
the QoS-Information AVP, if these AVPs
are received from the PCEF in the CCR messages.
The SAPC includes APN-Aggregate-Max-Bitrate-DL / Extended-APN-AMBR-DL and APN-Aggregate-Max-Bitrate-UL / Extended-APN-AMBR-UL AVPs in the QoS-Information AVP, if these AVPs are received from the PCEF in the CCR messages.
6.5 Default-EPS-Bearer-QoS AVP
Whenever the SAPC calculates an authorized QoS, its value is always included in the Default-EPS-Bearer-QoS AVP in CCA commands.
|
AVP Name |
AVP Code |
Comment |
Reference |
|---|---|---|---|
|
[ Allocation-Retention-Priority ] |
1034 |
The SAPC supports the following AVPs:
|
|
|
[ QoS-Class-Identifier ] |
1028 |
- |
6.6 Usage-Monitoring-Information AVP
|
AVP Name |
AVP Code |
Comment |
Reference |
|---|---|---|---|
|
[ Monitoring-Key ] |
1066 |
- |
|
|
[ Used-Service-Unit ] |
446 |
The SAPC supports the following AVPs:
|
RFC 4006 |
|
AVP Name |
AVP Code |
Comment |
Reference |
|---|---|---|---|
|
[ Granted-Service-Unit ] |
431 |
The SAPC supports the following AVPs:
|
RFC 4006 |
|
[ Monitoring-Key ] |
1066 |
- |
|
|
[ Usage-Monitoring-Level ] |
1068 |
The SAPC supports the following values:
|
|
|
[ Usage-Monitoring-Report ] |
1069 |
The SAPC supports the following values:
|
|
|
[ Usage-Monitoring-Support ] |
1070 |
The SAPC supports the following values:
|
6.7 Presence-Reporting-Area-Information AVP
The Presence-Reporting-Area-Information AVP is only valid for the CCR-Update and CCA-Initial messages. The Presence-Reporting-Area-Information AVP includes the following AVPs as shown in Table 22.
|
AVP Name |
AVP Code |
Comment |
Reference |
|---|---|---|---|
|
[ Presence-Reporting-Area-Identifier ] |
2821 |
Only valid for CCR-Update and CCA-Initial message. |
|
|
[ Presence-Reporting-Area-Status ] |
2823 |
Only valid for CCR-Update message. The SAPC supports the following values:
|
|
|
[ Presence-Reporting-Area-Elements-List ] |
2820 |
Only valid for CCA-Initial message. |
6.8 TDF-Information AVP
The TDF-Information AVP is only valid for the CCR-Initial messages. This AVP contains information about the TDF that handles application detection and reports for that IP-CAN session.
The TDF-Information AVP includes the following AVPs as shown in Table 23:
|
AVP Name |
AVP Code |
Comment |
Reference |
|---|---|---|---|
|
[ TDF-Destination-Host ](1) |
1089 |
Only valid with the TDF-Destination-Realm AVP. |
|
|
[ TDF-Destination-Realm ](2) |
1090 |
Only valid with the TDF-Destination-Host AVP. |
|
|
[ TDF-IP-Address ] |
1091 |
The address type can be IPv4 or IPv6. |
(1) If the TDF-Destination-Host AVP is received
in a CCR-Initial message, the TDF-Destination-Realm AVP is mandatory to be received. Otherwise, the SAPC returns a Result-Code AVP set to DIAMETER_MISSING_AVP.
(2) If the TDF-Destination-Realm AVP is received
in a CCR-Initial message, the TDF-Destination-Host AVP is mandatory to be received. Otherwise, the SAPC returns a Result-Code AVP set to DIAMETER_MISSING_AVP.
7 Ericsson Gx+ Message Format
This section contains the Ericsson added value AVPs that can be used in the Ericsson Gx+ interface, in addition to the standard information covered in Section 5.
7.1 Ericsson Gx+ Credit-Control-Request (CCR)
Table 24 lists the Ericsson added AVPs that the SAPC supports in a CCR.
|
AVP Name |
AVP Code |
Description |
Reference |
|---|---|---|---|
|
[ 3GPP-Charging-Characteristics ] |
13 |
3GPP-Charging-Characteristics AVP is of type UTF8String and is defined according to 3GPP TS 29 061 (Reference [3]) and transformed into a Diameter AVP. |
|
|
[ Gx-Capability-List ] |
1060 |
Gx-Capability-List AVP is of type Unsigned32. It can be included in the CCR initial for the IP-CAN session by the PCEF indicating the Ericsson offered proprietary capabilities. This negotiated Gx capability list is applicable for the lifetime of the IP-CAN session (and it is ignored if received again). If this negotiation is not present, the SAPC works in standard 3GPP Gx mode. Each bit, numbered 0-31 starting from the least significant bit, is used to indicate a separate function. The least significant bit is designated as bit 0. |
See Section 8.2 |
|
[ Rule-Space-Suggestion ] |
290 |
Rule-Space-Suggestion AVP is of type OctetString. It can be included in the initial CCR. |
|
|
[ Rule-Space-Decision ] |
291 |
Rule-Space-Decision AVP is of type OctetString and can be included in initial CCR/CCA. If the Rule-Space-Decision AVP is received in the CCR, the SAPC does not change it, and does not include Rule-Space-Decision AVP in the CCA. |
7.2 Ericsson Gx+ Credit-Control-Answer (CCA)
Table 25 lists the Ericsson added AVPs that the SAPC can send in a CCA.
|
AVP Name |
AVP Code |
Description |
Reference |
|---|---|---|---|
|
[ 3GPP-Charging-Characteristics ] |
13 |
The SAPC returns this AVP in CCA (2 octets value), if configured in the SAPC at subscriber level and the capability Charging characteristics retrieval is negotiated. |
|
|
[ Charging-Rule-Authorization ] |
1055 |
See Section 8.1. | |
|
[ Content-Filtering-Profile-Id ] |
1138 |
The Content-Filtering-Profile-Id AVP is of type Unsigned 32. It is used to select a local content filtering profile identifier in the Ericsson PCEF. The SAPC uses the special value 0xFFFFFFFF to indicate to the PCEF to remove the previously downloaded value. The SAPC includes it in CCA Initial message, if provisioned in the SAPC at subscriber level and the capability Content Filtering is negotiated. The SAPC includes it in CCA Update, only if its value is different than the value previously sent. |
|
|
[ Customer-Id ] |
1146 |
It contains the customer identifier of the PDP context (used for HTTP Header Enrichment) and is primarily intended to replace the MSISDN as the user identity sent out to applications on the Internet. This AVP is an Ericsson proprietary addition, but it is not negotiated in the Gx-Capability-List. It is only sent in CCA initial, if configured in the SAPC at subscriber level. It contains an ASCII value of variable length, between 1-25 octets, and cannot include special characters. |
|
|
[ Gx-Capability-List ] |
1060 |
- |
See Section 8.2. |
|
[ Rule-Space-Decision ] |
291 |
If the Rule-Space-Suggestion AVP is included in the CCR, this indicates to the SAPC can override this suggestion by including the Rule-Space-Decision AVP in the CCA initial. |
7.3 Ericsson Gx+ Re-Auth-Request (RAR)
Table 26 lists the Ericsson added AVPs that the SAPC can send in a RAR.
|
AVP Name |
AVP Code |
Description |
Reference |
|---|---|---|---|
|
[ Charging-Rule-Authorization ] |
1055 |
See Section 8.1. | |
|
[ Content-Filtering-Profile-Id ] |
1138 |
See avp-ContentFilter. The SAPC only includes it in RAR message, if there is a change compared to the value that sent to the PCEF in a previous CCA or RAR message. |
8 Ericsson Gx+ AVPs
The following subsections contain information for AVPs, that owing to space reasons, cannot be explained in the message tables of Section 7.
8.1 Charging-Rule-Authorization
The Charging-Rule-Authorization AVP is of type Grouped. It groups the AVPs that are required to define the authorization state for the current and next time period for the associated Charging-Rule-Names and Charging-Rule-Base-Names.
It is only applicable for static PCC rules.
The Charging-Rule-Authorization AVP is shared in the same Charging-Rule-Install for those Charging-Rule-Names or Charging-Rule-Base-Names that have the same Authorization-State.
The Charging-Rule-Authorization AVP has the following ABNF grammar:
AVP Format:
Charging-Rule-Authorization ::= < AVP Header: 1055,Vendor Id:193 >
{ Authorization-State }
[ Authorization-State-Change-Time ]
[ Next-Authorization-State ]
[ One-Time-Redirect-Control ]
8.1.1 Authorization-State AVP
The authorization state for current and next periods of time is included in Charging-Rule-Install AVP by inserting the Charging-Rule-Authorization AVP (only for static PCC rules).
The Authorization-State AVP (AVP code 1056) is of type Enumerated and specifies the authorization state and reason for non-authorization for the Charging-Rule-Names and Charging-Rule-Base-Names provided in the Charging-Rule-Install AVP.
It is only used for static PCC rules if capabilities enabling enhanced service authorization control or One Time Redirect are negotiated.
The SAPC supports the following values:
|
AUTHORIZED |
0 |
|
DENIED_CALENDAR_TIME |
1 |
|
DENIED_ROAMING |
2 |
|
DENIED_QUALITY_OF_SERVICE |
3 |
|
DENIED_BLACKLISTED |
4 |
|
DENIED_TERMINAL |
5 |
|
DENIED_OPERATOR_REASON_ONE |
6 |
|
DENIED_OPERATOR_REASON_TWO |
7 |
|
DENIED_OPERATOR_REASON_THREE |
8 |
|
DENIED_OPERATOR_REASON_FOUR |
9 |
|
DENIED_OPERATOR_REASON_FIVE |
10 |
|
DENIED_UNKNOWN_REASON |
11 |
|
DENIED_USAGE_CONTROL |
12 |
8.1.2 One-Time-Redirect-Control AVP
The One-Time-Redirect-Control AVP (AVP code 1193) is of type enumerated. It specifies if the one-time redirect is active or not for the charging rules and charging rule base names provided in the Charging-Rule-Install AVP.
It is only used for static PCC rules if One-Time-Redirect capability is enabled.
The SAPC includes this AVP in the Charging-Rule-Authorization AVP only in case that the Authorization-State is Authorized (0) and One Time Redirect capability is negotiated.
The SAPC provides the One-Time-Redirect-Control AVP only when there is a change regarding the previously provided information for the IP-CAN session (previous CCA).
The One-Time Redirect is deactivated by providing the One-Time-Redirect-Control AVP with the value One-Time Redirect Inactive.
The following values are defined:
|
One-Time-Redirect inactive |
0 |
|
One-Time-Redirect active |
1 |
8.2 Gx-Capability-List AVP
The Gx-Capability-List AVP is of type Unsigned32. It can be included in the initial CCR for the IP-CAN session by the PCEF indicating the Ericsson offered proprietary capabilities.
This negotiated Gx capability list is applicable for the lifetime of the IP-CAN session (and it is ignored if received again).
If this negotiation is not present, the SAPC works in standard 3GPP Gx mode.
Each bit, numbered 0-31 starting from the least significant bit, is used to indicate a separate function. The least significant bit is designated as bit 0.
Table 27 indicates the possible values for the supported capabilities:
|
Feature bit |
Feature |
Description |
|---|---|---|
|
0 |
Enhanced service authorization control |
If set, use of non-authorization codes is possible |
|
1 |
Not used |
- |
|
2 |
Not used |
- |
|
3 |
Rule Space negotiation |
Rule Space negotiation is possible. |
|
4 |
Charging Characteristics retrieval |
If set, the SAPC is able to retrieve the Charging Characteristics specified for the subscriber and return it to the PCEF. |
|
5 |
Not used |
Set to 0 |
|
6 |
Not used |
Set to 0 |
|
7 |
Not used |
Set to 0 |
|
8 |
Not used |
Set to 0 |
|
9 |
Not used |
Set to 0 |
|
10-11 |
Reserved for future use |
Set to 0. |
|
12 |
Support of Content Filtering Profile Id |
Set to 1 if Content Filtering Profile Id is supported. |
|
13 |
Reserved for future use |
Set to 0. |
|
14 |
- |
Not used for backward compatibility reasons |
|
15 |
Reserved for future use |
Reserved bits are set to zero for forward compatibility reasons |
|
16 |
One-Time-Redirect |
If set, One-Time-Redirect is enabled. |
|
17-31 |
Reserved for future use |
Reserved bits are set to zero for forward compatibility reasons |
The SAPC includes this AVP in the Ericsson Gx+ initial CCA messages. The bit for each capability is set to 1 whenever that capability was set to 1 by the Ericsson PCEF. The corresponding control is configured in the SAPC for that PCEF (only for capabilities linked to a control).
9 Gx Error Handling
When the SAPC detects an error at protocol or application level, it returns a response including the Result-Code AVP with an error code specifying the error.
9.1 Gx Protocol Errors
The SAPC handles the following Diameter Base Protocol error types:
|
Diameter Result Code |
Value |
Description |
|---|---|---|
|
DIAMETER_SUCCESS |
2001 |
A request is successfully completed. |
|
DIAMETER_COMMAND_UNSUPPORTED |
3001 |
A request contains a Command-Code that the SAPC does not recognize or support. |
|
DIAMETER_TOO_BUSY |
3004 |
A request is received when the SAPC is overloaded. |
|
DIAMETER_APPLICATION_UNSUPPORTED |
3007 |
A request is received for an unsupported application. |
|
DIAMETER_INVALID_HDR_BITS |
3008 |
A request is received with a Diameter header whose bits are set to an invalid combination or to a value that is inconsistent with the Command-Code definition. |
|
DIAMETER_INVALID_AVP_BITS |
3009 |
A request is received with an AVP whose flag bits are set to an unrecognized value or are inconsistent with the AVPs definition. |
|
DIAMETER_UNKNOWN_PEER |
3010 |
A CER message is received from an unknown peer. |
9.2 Gx Application Errors
The SAPC handles the following Gx Interface Application errors:
|
Diameter Result Code |
Value |
Description |
|---|---|---|
|
DIAMETER_OUT_OF_SPACE |
4002 |
A Diameter node received the request but was unable to commit it to stable storage due to a temporary lack of space. |
|
ELECTION_LOST |
4003 |
The peer has determined that it has lost the election process and has therefore disconnected the transport connection. |
|
DIAMETER_AVP_UNSUPPORTED |
5001 |
A request is received with an AVP that is not recognized or supported (not included in the SAPC Diameter dictionary) and was marked with the Mandatory bit. A Diameter message with this error must contain a Failed-AVP AVP containing the AVPs that caused the failure. |
|
DIAMETER_UNKNOWN_SESSION_ID |
5002 |
Returned if the session does not exist for the UE IP address at session modification/termination. |
|
DIAMETER_INVALID_AVP_VALUE |
5004 |
A request is received with an AVP with an invalid value in its data portion. A Diameter message with this error must contain a Failed-AVP AVP containing the AVPs that caused the failure. |
|
DIAMETER_MISSING_AVP |
5005 |
When a request is received including an AVP that is not required to process that request, that AVP is ignored and the request is processed as usual. On the contrary, when a request does not include an AVP that is required to process such request, the SAPC returns a response including Result-Code DIAMETER_MISSING_AVP and the Failed-AVP AVP. |
|
DIAMETER_CONTRADICTING_AVPS |
5007 |
A request is received with AVPs that are contradicted each other. A Diameter message with this error must contain a Failed-AVP AVP containing the AVPs that caused the failure. |
|
DIAMETER_AVP_NOT_ALLOWED |
5008 |
A request is received with an AVP that must not be present. A Diameter message with this error must contain a Failed-AVP AVP with a copy of the offending AVP. |
|
DIAMETER_AVP_OCCURS_TOO_MANY_TIMES |
5009 |
A request is received with an AVP that appears more often than permitted in the message definition. A Diameter message with this error must contain a Failed-AVP AVP with a copy of the first instance of the offending AVP that exceeded the maximum number of occurrences. |
|
DIAMETER_NO_COMMON_APPLICATION |
5010 |
A CER message is received and there are no common applications supported between the SAPC and the peer. |
|
DIAMETER_UNSUPPORTED_VERSION |
5011 |
A request is received with an unsupported version number. |
|
DIAMETER_UNABLE_TO_COMPLY |
5012 |
This error is returned when the SAPC receives a request and detects an internal error which does not allow to continue processing a request. |
|
DIAMATER_INVALID_BIT_IN_HEADER |
5013 |
A request is received with an unrecognized bit in the Diameter header is set to one. |
|
DIAMETER_INVALID_AVP_LENGTH |
5014 |
A request is received containing an AVP with an invalid length. A Diameter message with this error must contain a Failed-AVP AVP containing the offending AVP. |
|
DIAMETER_INVALID_MESSAGE_LENGTH |
5015 |
A request is received with an invalid message length. |
|
DIAMETER_INVALID_AVP_BIT_COMBO |
5016 |
A request is received with an AVP which is not allowed to have the received value in the AVP Flags field. A Diameter message with this error must contain a Failed-AVP AVP containing the offending AVP. |
|
DIAMETER_NO_COMMON_SECURITY |
5017 |
This error is returned when a CER message is received, and there are no common security mechanisms supported between the peers. A CEA MUST be returned with the Result-Code AVP set to DIAMETER_NO_COMMON_SECURITY. |
|
Result Code |
Value |
Description |
|---|---|---|
|
DIAMETER_AUTHORIZATION_REJECTED |
5003 |
A request is received for which the subscriber could not be authorized, owing to IP-CAN Session Access Control. |
|
DIAMETER_USER_UNKNOWN |
5030 |
This error is returned when the subscriber specified in the Subscription-Id AVP is not known in the SAPC at session activation or modification |
|
Result Code |
Value |
Description |
|---|---|---|
|
DIAMETER_PENDING_TRANSACTION |
4144 |
Received if the PCEF cannot determine that Gx RAR message can be safely handled without creating a state mismatch. |
|
DIAMETER_ERROR_INITIAL_PARAMETERS |
5140 |
This error is returned when the SAPC receives a CCR INITIAL for an emergency IP-CAN session establishment where: |
Reference List
| Standard References |
|---|
| [1] Cx and Dx Interfaces Based on the Diameter Protocol; Protocol Details, 3GPP TS 29.229. |
| [2] E-UTRAN – eHRPD Connectivity and Interworking: Core Network Aspects, 3GPP2 X.S0057. |
| [3] Interworking between the Public Land Mobile Network (PLMN) Supporting Packet Based Services and Packet Data Networks (PDN), 3GPP TS 29.061 V6.7.0. |
| [4] Policy and Charging Control Reference Points, 3GPP TS 29.212. |
| Online References |
|---|
| [5] Diameter Base Protocol, IETF RFC 6733. |
| [6] Diameter Credit-Control Application, IETF RFC 4006. |
| [7] Diameter Network Access Server Application, IETF RFC 4005. |

Contents
