7 Protocol Specification and Implementation for MC Service
29.2833GPPDiameter data management applicationsRelease 17TS
7.1 General
7.1.1 Use of Diameter base protocol
The Diameter base protocol as specified in IETF RFC 6733 [23] shall apply except as modified by the defined support of the methods and the defined support of the commands and AVPs, result and error codes as specified in this specification. Unless otherwise specified, the procedures (including error handling and unrecognised information handling) shall be used unmodified.
7.1.2 Securing Diameter Messages
For secure transport of Diameter messages, see 3GPP TS 33.210 [4].
7.1.3 Accounting functionality
Accounting functionality (Accounting Session State Machine, related command codes and AVPs) shall not be used on the MCPTT-2, MCVideo-2, MCData-2 and CSC-13 interfaces.
7.1.4 Use of sessions
Between an MC Service Server and the corresponding MC Service User Database or between the Configuration Management Server and the MC Services User Database(s), Diameter sessions shall be implicitly terminated. An implicitly terminated session is one for which the server does not maintain state information. The client shall not send any re-authorization or session termination requests to the server.
The Diameter base protocol as specified in IETF RFC 6733 [23] includes the Auth-Session-State AVP as the mechanism for the implementation of implicitly terminated sessions.
The client (server) shall include in its requests (responses) the Auth-Session-State AVP set to the value NO_STATE_MAINTAINED (1), as described in IETF RFC 6733 [23]. As a consequence, the server shall not maintain any state information about this session and the client shall not send any session termination request. Neither the Authorization-Lifetime AVP nor the Session-Timeout AVP shall be present in requests or responses.
7.1.5 Transport protocol
Diameter messages over the MCPTT-2, MCVideo-2, MCData-2 and CSC-13 interfaces shall make use of SCTP IETF RFC 4960 [5].
7.1.6 Routing considerations
This clause specifies the use of the Diameter routing AVPs Destination-Realm and Destination-Host.
The Destination-Realm AVP shall contain the network domain name of the MC Service provider’s domain. The network domain name is either known by the sending MC Service Server or the Configuration Management Server or is derived from information received at the signalling layer.
If an MC Service Server or the Configuration Management Server knows the address/name of the MC Service User Database in charge of a given MC Service User, both the Destination-Realm and Destination-Host AVPs shall be present in the request.
If an MC Service Server or the Configuration Management Server knows only the network domain name, the Destination-Realm AVP shall be present and the command shall be routed to the next Diameter node. When multiple and separately addressable MC Service User Databases have been deployed by the MC service provider/network operator, the next Diameter node is either a Diameter Proxy Agent or a Diameter Redirect Agent responsible for the determination of the destination MC Service User Database (as described in clause 7.1.10). When the next Diameter node is a Diameter Agent Proxy, the Diameter Proxy Agent, based on the result of this determination, shall modify the Destination-Realm AVP and Destination-Host AVP of the request appropriately. The Diameter Proxy Agent shall then append a Route-Record AVP to the request and shall send the request to the destination MC Service User Database. Consequently, the Destination-Host AVP is declared as optional in the ABNF for all requests initiated by an MC Service User Database.
When the response is routed back to a Diameter Proxy Agent, the Diameter Proxy Agent shall send the response back to the MC Service Server or the Configuration Management Server without modifying the Origin-Realm AVP and Origin-Host AVP. The response shall contain the Origin-Realm AVP set to the realm and the Origin-Host AVP set to the FQDN of the MC Service User Database that have sent the response. The MC Service Server shall then store the MC Service User Database realm and identity for each MC Service ID for sending further requests for the same MC Service User.
Requests initiated by the MC Service User Database towards an MC Service Server shall include both Destination-Host and Destination-Realm AVPs. The MC Service User Database obtains the Destination-Host AVP to use in requests towards an MC Service Server or the Configuration Management Server, from the Origin-Host AVP received in previous requests from the MC Service Server or the Configuration Management Server.
Consequently, the Destination-Realm AVP and Destination-Host AVP are declared as mandatory in the ABNF for all requests initiated by the MC Service User Database.
Consequently, the Destination-Realm AVP is declared as mandatory and the Destination-Host AVP is declared as optional in the ABNF for all requests initiated by an MC Service Server.
If the Vendor-Specific-Application-ID AVP is received in any of the commands defined in this specification, it shall be ignored by the receiving node, and it shall not be used for routing purposes.
7.1.7 Advertising Application Support
The MC Service User Database and the MC Service Server or the Configuration Management Server shall advertise support of the Diameter Data Management Application by including the value of the application identifier in the Auth-Application-Id AVP within the Vendor-Specific-Application-Id grouped AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands.
The vendor identifier value of 3GPP (10415) shall be included in the Supported-Vendor-Id AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands, and in the Vendor-Id AVP within the Vendor-Specific-Application-Id grouped AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands.
The Vendor-Id AVP included in Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands that is not included in the Vendor-Specific-Application-Id AVPs as described above shall indicate the manufacturer of the Diameter node as per IETF RFC 6733 [23].
7.1.8 Diameter Application Identifier
The Diameter Data Management application protocol shall be defined as an IETF vendor specific Diameter application, where the vendor is 3GPP. The vendor identifier assigned by IANA to 3GPP (http://www.iana.org/assignments/enterprise-numbers) is 10415.
The Diameter application identifier assigned to the Diameter Data Management application is 16777351 (allocated by IANA).
7.1.9 Use of the Supported-Features AVP
When new functionality is introduced on the MCPTT-2, MCVideo-2, MCData-2 or CSC-13 interfaces, it should be defined as optional. If backwards incompatible changes cannot be avoided, the new functionality shall be introduced as a new feature and support advertised with the Supported-Features AVP. The usage of the Supported-Features AVP on the MCPTT-2, MCVideo-2, MCData-2 and CSC-13 interfaces is consistent with the procedures for the dynamic discovery of supported features as defined in clause 7.2 of 3GPP TS 29.229 [6].
When extending the application by adding new AVPs for a feature, the new AVPs shall have the M bit cleared and the AVP shall not be defined mandatory in the command ABNF.
As defined in 3GPP TS 29.229 [6], the Supported-Features AVP is of type grouped and contains the Vendor-Id, Feature-List-ID and Feature-List AVPs. On the all reference points as specified in this specification, the Supported-Features AVP is used to identify features that have been defined by 3GPP and hence, for features defined in this document, the Vendor-Id AVP shall contain the vendor ID of 3GPP (10415). If there are multiple feature lists defined for the reference point, the Feature-List-ID AVP shall differentiate those lists from one another.
7.1.10 MC Service ID to MC Service User Database resolution
The MC Service ID to MC Service User Database resolution mechanism enables an MC Service Server or the Configuration Management Server to find the identity of the MC Service User Database that holds the MC Service related data for a given MC Service ID when multiple and separately addressable MC Service User Databases have been deployed by the MC service provider/network operator. The resolution mechanism is not required in networks that utilise a single MC Service User Database per MC Service or when an MC Service Server is configured to use pre-defined MC Service User Database.
The resolution mechanism shall use a Diameter Proxy Agent or a Diameter Redirect Agent.
The Diameter Proxy Agent or Diameter Redirect Agent shall be used to determine the MC Service User Database identity.
In networks where the use of the MC Service ID to MCPTT User Database resolution mechanism is required and the MC Server Server is not configured to use a predefined MC Service User Database, each MC Service Server shall be configured with the pre-configured address/name of a Diameter Proxy Agent or Diameter Redirect Agent to enable use of these resolution mechanisms.
To get the MC Service User Database identity, the MC Service Server or the Configuration Management Server shall send the Data Management Application request normally destined to the MC Service User Database to the pre-configured Diameter Proxy Agent or Diameter Redirect Agent.
The Diameter Proxy Agent shall determine the MC Service User Database identity based on the provided user identity and – if the Diameter load control mechanism is supported (see IETF RFC 8583 [17]) – optionally also based on previously received load values from Load AVPs of type HOST. The Diameter Proxy Agent shall then forward the Data Management Application request directly to the determined MC Service User Database. The MC Service Server shall determine the MC Service User Database identity from the response to the Data Management Application request received from the MC Service User Database. The MC Service Server and the Configuration Management Server should store the MC Service User Database identity/name/Realm and shall use it in further Data Management Application requests associated to the same MC Service ID.
The Diameter Redirect Agent shall determine the MC Service User Database address and shall send to the MC Service Server or the Configuration Management Server a notification of redirection towards the MC Service User Database, in response to the request. Multiple MC Service User Database identities may be included in the response, as specified in IETF RFC 6733 [23]. In such a case, the MC Service Server or the Configuration Management Server shall send the Request to the first MC Service User Database identity in the ordered list received in the Response from the Diameter Redirect Agent. If the MC Service Server or the Configuration Management Server does not receive a successful response to the Request, the MC Service Server or the Configuration Management Server shall send a Request to the next MC Service User Database identity in the ordered list. This procedure shall be repeated until a successful response from an MC Service User Database is received.
7.2 Commands
7.2.1 Introduction
This clause defines the Command code values and related ABNF for each command described in this specification.
7.2.2 Command-Code values
This clause defines Command-Code values for the Diameter Data Management application used over the MCPTT-2, MCVideo-2, MCData-2 and CSC-13 interfaces as allocated by IANA.
Every command is defined by means of the ABNF syntax IETF RFC 5234 [7], according to the Command Code Format (CCF) specification defined in IETF RFC 6733 [23]. In the case, the definition and use of an AVP is not specified in this document, the guidelines in IETF RFC 6733 [23] shall apply.
The Vendor-Specific-Application-Id AVP shall not be included in any command sent by Diameter nodes supporting applications defined in this specification. If the Vendor-Specific-Application-Id AVP is received in any of the commands defined in this specification, it shall be ignored by the receiving node.
NOTE: The Vendor-Specific-Application-Id is included as an optional AVP in all Command Code Format specifications defined in this specification in order to overcome potential interoperability issues with intermediate Diameter agents non-compliant with IETF RFC 6733 [23].
The following Command Codes are defined in this specification:
Table 7.2.2-1: Command-Code values
|
Command-Name |
Abbreviation |
Code |
Clause |
|
Data-Pull-Request |
DPR |
8388728 |
7.2.3 |
|
Data-Pull-Answer |
DPA |
8388728 |
7.2.4 |
|
Data-Update-Request |
DUR |
8388729 |
7.2.5 |
|
Data-Update-Answer |
DUA |
8388729 |
7.2.6 |
|
Notification-Data-Request |
NDR |
8388730 |
7.2.7 |
|
notification-Data-Answer |
NDA |
8388730 |
7.2.8 |
7.2.3 Data-Pull-Request (DPR) Command
The Data-Pull-Request (DPR) command, indicated by the Command-Code field set to 8388728 and the ‘R’ bit set in the Command Flags field, is sent by a Diameter client to a Diameter server in order to request user data.
Message Format
< Data-Pull-Request > ::= < Diameter Header: 8388728, REQ, PXY, 16777351 >
< Session-Id >
[ DRMP ]
[ Vendor-Specific-Application-Id ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ Destination-Host ]
{ Destination-Realm }
*[ Supported-Features ]
[ User-Identifier ]
*[ Data-Identification ]
[ DPR-Flags ]
[ User-Data-Id ]
[ OC-Supported-Features ]
*[ AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
7.2.4 Data-Pull-Answer (DPA) Command
The Data-Pull-Answer (DPA) command, indicated by the Command-Code field set to 8388728 and the ‘R’ bit cleared in the Command Flags field, is sent by a server in response to the Data-Pull-Request command. The Experimental-Result AVP may contain one of the values defined in clause 7.4.
Message Format
< Data-Pull-Answer > ::= < Diameter Header: 8388728, PXY, 16777351 >
< Session-Id >
DRMP ]
[ Vendor-Specific-Application-Id ]
[ Result-Code ]
[ Experimental-Result ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
*[ Supported-Features ]
*[ Data ]
*[ Data-Identification ]
[ DPA-Flags]
[ OC-Supported-Features ]
[ OC-OLR ]
*[ Load ]
*[ AVP ]
[ Failed-AVP ]
*[ Proxy-Info ]
[ Route-Record ]
7.2.5 Data-Update-Request (DUR) Command
The Data-Update-Request (DUR) command, indicated by the Command-Code field set to 8388729 and the ‘R’ bit set in the Command Flags field, is sent by a Diameter client to a Diameter server in order to update user data in the server.
Message Format
< Data-Update-Request > ::= < Diameter Header: 8388729, REQ, PXY, 16777351 >
< Session-Id >
[ DRMP ]
[ Vendor-Specific-Application-Id ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ Destination-Host ]
{ Destination-Realm }
*[ Supported-Features ]
[ User-Identifier ]
[ Data ]
[ DUR-Flags ]
[ OC-Supported-Features ]
*[ AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
7.2.6 Data-Update-Answer (DUA) Command
The Data-Update-Answer (DUA) command, indicated by the Command-Code field set to 8388729 and the ‘R’ bit cleared in the Command Flags field, is sent by a server in response to the Data-Update-Request command. The Experimental-Result AVP may contain one of the values defined in clause 7.4.
Message Format
< Data-Update-Answer > ::=< Diameter Header: 8388729, PXY, 16777351 >
< Session-Id >
[ DRMP ]
[ Vendor-Specific-Application-Id ]
[ Result-Code ]
[ Experimental-Result ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
*[ Data-Identification ]
*[ MC-Service-User-Profile-Data ]
[ DUA-Flags ]
*[ Supported-Features ]
[ OC-Supported-Features ]
[ OC-OLR ]
*[ Load ]
*[ AVP ]
[ Failed-AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
7.2.7 Notification-Data-Request (PDR) Command
The Notification-Data-Request (PDR) command, indicated by the Command-Code field set to 8388730 and the ‘R’ bit set in the Command Flags field, is sent by a Diameter server to a Diameter client in order to notify changes in the user data stored in the server.
Message Format
< Notification-Data-Request > ::= < Diameter Header: 8388730, REQ, PXY, 16777351 >
< Session-Id >
[ DRMP ]
[ Vendor-Specific-Application-Id ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Host }
{ Destination-Realm }
*[ Supported-Features ]
[ User-Identifier ]
[ Data ]
[ NDR-Flags ]
*[ AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
7.2.8 Notification-Data-Answer (PDA) Command
The Notification-Data-Answer (PDA) command, indicated by the Command-Code field set to 8388730 and the ‘R’ bit cleared in the Command Flags field, is sent by a client in response to the Push-Data-Request command. The Experimental-Result AVP may contain one of the values defined in clause 7.4.
Message Format
< Notification-Data-Answer > ::=< Diameter Header: 8388730, PXY, 16777351 >
< Session-Id >
[ DRMP ]
[ Vendor-Specific-Application-Id ]
[ Result-Code ]
[ Experimental-Result ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
*[ Data-Identification ]
[ NDA-Flags ]
*[ Supported-Features ]
*[ AVP ]
[ Failed-AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
7.3 AVPs
7.3.1 General
The following table (table 7.3.1-1) specifies the Diameter AVPs defined for the MCPTT-2, MCVideo-2, MCData-2 and CSC-13 interfaces, their AVP Code values, types, possible flag values and whether or not the AVP may be encrypted. The Vendor-ID header of all AVPs defined in this specification shall be set to 3GPP (10415).
For all AVPs which contain bit masks and are of the type Unsigned32 e.g., DPR-Flags, bit 0 shall be the least significant bit. For example, to get the value of bit 0, a bit mask of 0x0001 shall be used.
Table 7.3.1-1: MCPTT-2, MCVideo-2, MCData-2 and CSC-13 specific Diameter AVPs
|
AVP Flag rules |
||||||||
|---|---|---|---|---|---|---|---|---|
|
Attribute Name |
AVP Code |
Clause defined |
Value Type |
Must |
May |
Should not |
Must not |
May Encr. |
|
MCPTT-ID |
4500 |
7.3.2 |
UTF8String |
M, V |
No |
|||
|
Data-Identification |
4501 |
7.3.3 |
Grouped |
M, V |
No |
|||
|
Data-Identification-Prefix |
4502 |
7.3.11 |
Unsigned32 |
M,V |
No |
|||
|
Data-Identification-Flags |
4503 |
7.3.12 |
Unsigned64 |
M,V |
No |
|||
|
DPR-Flags |
4504 |
7.3.13 |
Unsigned32 |
M,V |
No |
|||
|
DPA-Flags |
4505 |
7.3.14 |
Unsigned32 |
M,V |
No |
|||
|
DUR-Flags |
4506 |
7.3.15 |
Unsigned32 |
M,V |
No |
|||
|
DUA-Flags |
4507 |
7.3.16 |
Unsigned32 |
M,V |
No |
|||
|
NDR-Flags |
4508 |
7.3.17 |
Unsigned32 |
M,V |
No |
|||
|
NDA-Flags |
4509 |
7.3.18 |
Unsigned32 |
M,V |
No |
|||
|
User-Data-Id |
4510 |
7.3.19 |
Unsigned32 |
M,V |
No |
|||
|
MC-Service-User-Profile-Data |
4511 |
7.3.20 |
Grouped |
M,V |
No |
|||
|
Sequence-Number |
4512 |
7.3.21 |
Unsigned32 |
M,V |
No |
|||
|
Data |
4513 |
7.3.22 |
Grouped |
M,V |
No |
|||
|
MCVideo-ID |
4514 |
7.3.24 |
UTF8String |
V |
M |
No |
||
|
MCData-ID |
4515 |
7.3.25 |
UTF8String |
V |
M |
No |
||
|
NOTE 1: The AVP header bit denoted as "M", indicates whether support of the AVP is required. The AVP header bit denoted as "V" indicates whether the optional Vendor-ID field is present in the AVP header. For further details, see IETF RFC 6733 [23]. NOTE 2: If the M-bit is set for an AVP and the receiver does not understand the AVP, it shall return a rejection. If the M-bit is not set for an AVP, the receiver shall not return a rejection, whether or not it understands the AVP. If the receiver understands the AVP but the M-bit value does not match with the definition in this table, the receiver shall ignore the M-bit. |
||||||||
The following table (table 7.3.1-2) specifies the Diameter AVPs re-used by the MCPTT-2, MCVideo-2, MCData-2 and CSC-13 interfaces from existing Diameter Applications, including a reference to their respective specifications and when needed, a short description of their use within MCPTT-2, MCVideo-2, MCData-2 and CSC-13 interfaces.
Any other AVPs from existing Diameter Applications, except for the AVPs from Diameter base protocol defined in IETF RFC 6733 [23], do not need to be supported. The AVPs from Diameter base protocol defined in IETF RFC 6733 [23] are not included in table 7.3.1-2.
Table 7.3.1-2: MCPTT-2 and CSC-13 re-used Diameter AVPs
|
Attribute Name |
Reference |
Comments |
M-bit |
|---|---|---|---|
|
Supported-Features |
3GPP TS 29.229 [6] |
||
|
DRMP |
IETF RFC 7844[8] |
Must set |
|
|
Feature-List-ID |
3GPP TS 29.229 [6] |
||
|
Feature-List |
3GPP TS 29.229 [6] |
See clause 7.3.10 |
|
|
Feature-Id |
3GPP TS 29.229 [6] |
||
|
User-Data |
3GPP TS 29.329 [9] |
||
|
User-Identifier |
3GPP TS 29.336 [10] |
See clause 7.3.8 |
|
|
OC-Supported-Features |
IETF RFC 7683 [11] |
See clause 7.3.6 |
Must set |
|
OC-OLR |
IETF RFC 7683 [11] |
See clause 7.3.5 |
Must set |
|
Load |
IETF RFC 8583 [17] |
See clause 7.3.23 |
Must not set |
|
NOTE 1: The M-bit settings for re-used AVPs override those of the defining specifications that are referenced. Values include: "Must set", "Must not set". If the M-bit setting is blank, then the defining specification applies. NOTE 2: If the M-bit is set for an AVP and the receiver does not understand the AVP, it shall return a rejection. If the M-bit is not set for an AVP, the receiver shall not return a rejection, whether or not it understands the AVP. If the receiver understands the AVP but the M-bit value does not match with the definition in this table, the receiver shall ignore the M-bit. |
|||
7.3.2 MCPTT-ID
The MCPTT-ID AVP is of type UTF8String, and it shall contain an URI as defined in IETF RFC 3986 [15]. For more information see 3GPP TS 23.379 [18].
7.3.3 Data-Identification
The Data-Identification AVP is of type Grouped. It shall contain the Data-Identification-Prefix AVP and the Data-Identification-Flags AVP. AVP format
Data-Identification ::= < AVP header: 4501 10415 >
{ Data-Identification-Prefix}
{ Data-Identification-Flags }
*[AVP]
7.3.4 DRMP
The DRMP AVP is of type Enumerated and it is defined in IETF RFC 7944 [8]. This AVP allows the MC Service User Database and the MC Service Server to indicate the relative priority of Diameter messages. The DRMP AVP may be used to set the DSCP marking for transport of the associated Diameter message.
7.3.5 OC-OLR
The OC-OLR AVP is of type Grouped and it is defined in IETF RFC 7683 [11]. This AVP is used to support Diameter overload control mechanism.
7.3.6 OC-Supported-Features
The OC-Supported-Features AVP is of type Grouped and it is defined in IETF RFC 7683 [11]. This AVP is used to support Diameter overload control mechanism.
7.3.7 User-Data
The User-Data AVP is of type OctetString and it contains an XML document. This AVP is defined in the 3GPP TS 29.329 [9].
When the requested data managed by the MC Service User Database is an MCPTT User Profile, this AVP contains an XML document conformant to the XML schema defined in clause 8.3 in the 3GPP TS 24.484 [22]. This XML schema describes the MCPTT User Profile data exchanged between the MC Service User Database and the MCPTT Server in the DPR/DPA and NDR/NDA and between the MCPTT User Database and the Configuration Management Server in DPR/DPA, NDR/NDA and DUR/DUA operations.
When the requested data managed by the MC Service User Database is an MCVideo User Profile, this AVP contains an XML document conformant to the XML schema defined in clause 9.3 in the 3GPP TS 24.484 [22]. This XML schema describes the MCVideo User Profile data exchanged between the MCVideo User Database and the MCVideo Server in the DPR/DPA and NDR/NDA and between the MCVideo User Database and the Configuration Management Server in DPR/DPA, NDR/NDA and DUR/DUA operations.
When the requested data managed by the MC Service User Database is an MCData User Profile, this AVP contains an XML document conformant to the XML schema defined in clause 10.3 in the 3GPP TS 24.484 [22]. This XML schema describes the MCData User Profile data exchanged between the MCData User Database and the MCData Server in the DPR/DPA and NDR/NDA and between the MCData User Database and the Configuration Management Server in DPR/DPA, NDR/NDA and DUR/DUA operations.
7.3.8 User-Identifier
The User-Identifier AVP is of type Grouped. It shall contain the identifier used to identify the MC Service User in the MC Service User Database. This AVP is defined in the 3GPP TS 29.336 [10] and is extended to contain either an MCPTT ID, an MCVideo ID or an MCData ID.
AVP format:
User-Identifier ::= <AVP header: 3102 10415>
[ MCPTT-ID ]
[ MCVideo-ID ]
[ MCData-ID ]
*[AVP]
7.3.9 Feature-List-ID AVP
The syntax of this AVP is defined in 3GPP TS 29.229 [10]. For this release, the Feature-List-ID AVP value shall be set to 1.
7.3.10 Feature-List AVP
The syntax of this AVP is defined in 3GPP TS 29.229 [6]. A null value indicates that there is no feature used by the application.
NOTE: There is no feature defined for this release.
7.3.11 Data-Identification-Prefix
The Data-Identification-Prefix AVP is of type Unsigned32 and identifies a unique set of data identification flags, in order to ensure further extensibility when all Data-Identification-Flags are assigned.
Each Data-Identification-Flags defined is assigned a unique Data-Identification-Prefix AVP value.
7.3.12 Data-Identification-Flags
The Data-Identification-Flags AVP is of type Unsigned64 and it contains a bit mask.
The meaning of the bits when the Data-Identification-Prefix value is 1 is defined in table 7.3.12-1:
Table 7.3.12-1: Data-Identification-Flags
|
bit |
name |
Description |
|
0 |
MCPTT User Profile |
This bit, when set, indicates that the requested data are MCPTT User Profile data. |
|
1 |
MCVideo User Profile |
This bit, when set, indicates that the requested data are MCVideo User Profile data. |
|
2 |
MCData User Profile |
This bit, when set, indicates that the requested data are MCData User Profile data. |
|
NOTE: Bits not defined in this table shall be cleared by the sending entity and discarded by the receiving entity. |
||
7.3.13 DPR-Flags
The DPR-Flags AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits shall be as defined in table 7.3.13-1:
Table 7.3.13-1: DPR-Flags
|
Bit |
Name |
Description |
|
0 |
Subscription to notifications |
This bit, when set, indicates that the requesting node subscribes to the notifications service for any change in the requested data. |
|
NOTE: Bits not defined in this table shall be cleared by the sending entity and discarded by the receiving entity. |
||
7.3.14 DPA-Flags
The DPA-Flags AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits shall be as defined in table 7.3.14-1:
Table 7.3.14-1: DPA-Flags
|
Bit |
Name |
Description |
|
0 |
Notification service status |
This bit, when set, indicates that the service of notifications is active. |
|
NOTE: Bits not defined in this table shall be cleared by the sending entity and discarded by the receiving entity. |
||
7.3.15 DUR-Flags
The DUR-Flags AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits shall be as defined in table 7.3.15-1:
Table 7.3.15-1: DUR-Flags
|
Bit |
Name |
Description |
|
0 |
Atomicity |
This bit, when set, indicates that atomicity is required for operations on multiple data. |
|
NOTE: Bits not defined in this table shall be cleared by the sending entity and discarded by the receiving entity. |
||
7.3.16 DUA-Flags
The DUA-Flags AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits shall be as defined in table 7.3.16-1:
Table 7.3.16-1: DUA-Flags
|
Bit |
Name |
Description |
|
0 |
||
|
NOTE: Bits not defined in this table shall be cleared by the sending entity and discarded by the receiving entity. |
||
NOTE: There is no bit defined for this release.
7.3.17 NDR-Flags
The NDR-Flags AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits shall be as defined in table 7.3.17-1:
Table 7.3.17-1: NDR-Flags
|
Bit |
Name |
Description |
|
0 |
||
|
NOTE: Bits not defined in this table shall be cleared by the sending entity and discarded by the receiving entity. |
||
NOTE: There is no bit defined for this release.
7.3.18 NDA-Flags
The NDA-Flags AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits shall be as defined in table 7.3.18-1:
Table 7.3.18-1: NDA-Flags
|
Bit |
Name |
Description |
|
0 |
||
|
NOTE: Bits not defined in this table shall be cleared by the sending entity and discarded by the receiving entity. |
||
NOTE: There is no bit defined for this release.
7.3.19 User-Data-Id
The User-Data-Id AVP is of type Unsigned32 and it shall contain the unique identifier of a given MC Service User Profile defined for an MC Service User.
7.3.20 MC-Service-User-Profile-Data
The MC-Service-User-Profile-Data AVP is of type Grouped. It may contain an MC Service User Profile data, a Sequence Number and a User Data Id identifying a specific XML document.
AVP format:
MC-Service-User-Profile-Data ::= <AVP header: 4511 10415>
[ User-Data ]
[ Sequence-Number ]
[ User-Data-Id ]
*[AVP]
7.3.21 Sequence-Number
The Sequence-Number AVP is of type Unsigned32. This AVP contains a number associated to an MC Service User Profile. This AVP is defined in the 3GPP TS 29.329 [9].
7.3.22 Data
The Data AVP is of type Grouped. It contains one or several AVPs containing the data to be returned.
AVP format:
Data ::= <AVP header: 4513 10415>
*[ MC-Service-User-Profile-Data ]
*[ AVP ]
7.3.23 Load
The Load AVP is of type Grouped and it is defined in IETF RFC 8583 [17]. This AVP is used to support the Diameter load control mechanism.
7.3.24 MCVideo-ID
The MCVideo-ID AVP is of type UTF8String, and it shall contain an URI as defined in IETF RFC 3986 [15]. For more information see 3GPP TS 23.281 [19].
7.3.25 MCData-ID
The MCData-ID AVP is of type UTF8String, and it shall contain an URI as defined in IETF RFC 3986 [15]. For more information see 3GPP TS 23.282 [20].
7.4 Result-Code and Experimental-Result-Code Values
7.4.1 Introduction
This clause defines Result-Code and Experimental-Result-Code values that shall be supported by all Diameter implementations that conform to this specification.
7.4.2 Success
7.4.2.1 General
Result codes that fall within the Success category shall be used to inform a peer that a request has been successfully completed. The Result-Code AVP values defined in Diameter base protocol IETF RFC 6733 [23] shall be applied.
7.4.3 Permanent Failures
7.4.3.1 General
Errors that fall within the Permanent Failures category shall be used to inform the peer that the request has failed, and should not be attempted again. The Result-Code AVP values defined in Diameter base protocol IETF RFC 6733 [23] shall be applied. When one of the result codes defined here is included in a response, it shall be inside an Experimental-Result-Code AVP and the Result-Code AVP shall be absent.
7.4.3.2 DIAMETER_ERROR_USER_UNKNOWN (5001)
This result code shall be sent by the MC Service User Database to indicate that the MC Service User identified by the User Identifier received in the request is unknown. This error code is defined in 3GPP TS 29.229 [6].
7.4.3.3 DIAMETER_ERROR_USER_DATA_NOT_RECOGNIZED (5100)
The data received by the MC Service Server or the Configuration Management Server is not supported or recognized. This error code is defined in 3GPP TS 29.329 [9].
7.4.3.4 DIAMETER_ERROR_OPERATION_NOT_ALLOWED (5101)
The requested operation is not allowed for the user. This error code is defined in 3GPP TS 29.329 [9].
7.4.3.5 DIAMETER_ERROR_USER_DATA_CANNOT_BE_READ (5102)
The requested user data is not allowed to be read. This error code is defined in 3GPP TS 29.329 [9].
7.4.3.6 DIAMETER_ERROR_USER_DATA_CANNOT_BE_MODIFIED (5103)
The requested user data is not allowed to be modified. This error code is defined in 3GPP TS 29.329 [9].
7.4.3.7 DIAMETER_ERROR_USER_DATA_CANNOT_BE_NOTIFIED (5104)
The requested user data is not allowed to be notified on changes. This error code is defined in 3GPP TS 29.329 [9].
7.4.3.8 DIAMETER_ERROR_TOO_MUCH_DATA (5008)
The size of the data pushed to the receiving entity exceeds its capacity. This error code is defined in 3GPP TS 29.229 [6].
7.4.3.9 DIAMETER_ERROR_DATA OUT_OF_SYNC (5105)
The request to update the user profile at the MC Service User Database could not be completed because the requested update is based on an out-of-date version of the user profile i.e. the Sequence Number in the Data Update Request message does not match with the immediate successor of the associated Sequence Number stored for that user profile at the MC Service User Database. This error code is defined in 3GPP TS 29.329 [9].
7.4.3.10 DIAMETER_ERROR_FEATURE_UNSUPPORTED (5011)
A request application message was received indicating that the origin host requests that the command pair would be handled using a feature which is not supported by the destination host. This error code is defined in 3GPP TS 29.229 [6].
7.4.3.11 DIAMETER_ERROR_NO_SUBSCRIPTION_TO_DATA (5107)
The MCPTT Server received a notification of changes of some information to which it is not subscribed. This error code is defined in 3GPP TS 29.329 [9].
7.4.3.12 DIAMETER_ERROR_ UNKNOWN _DATA (5670)
The requested data received by the MC Service User Database does not exist.
7.4.3.13 DIAMETER_ERROR_REQUIRED_KEY_NOT_PROVIDED (5671)
One or more access keys are missing in the request to be able to update the requested data.
7.4.4 Transient Failures
7.4.4.1 General
Errors that fall within the transient failures category are those used to inform a peer that the request could not be satisfied at the time that it was received. The request may be able to be satisfied in the future.
7.4.4.2 DIAMETER_USER_DATA_NOT_AVAILABLE (4100)
The requested user data is not available at this time to satisfy the requested operation. This error code is defined in 3GPP TS 29.329 [9].
7.4.4.3 DIAMETER_PRIOR_UPDATE_IN_PROGRESS (4101)
The request to update the repository data at the MC Service User Database could not be completed because the related repository data is currently being updated by another entity. This error code is defined in 3GPP TS 29.329 [9].
Annex A (normative):
Diameter overload control mechanism