6 Procedure Descriptions for MC Services
29.2833GPPDiameter data management applicationsRelease 17TS
6.1 Introduction
This clause describes the procedures invoked between MC Service Server(s) and the MC Service User Database(s), i.e.:
– between the MCPTT Server and the MCPTT User Database over the MCPTT-2 reference point;
– between the MCVideo Server and the MCVideo User Database over the MCVideo-2 reference point;
– between the MCData Server and the MCData User Database over the MCData-2 reference point.
This clause describes the procedures invoked between the Configuration Management Server and the MC Service User Database over the CSC-13 reference point.
In the tables that describe the Information Elements transported by each command, each Information Element is marked as (M) Mandatory, (C) Conditional or (O) Optional in the "Cat." column. For the correct handling of the Information Element according to the category type, see the description detailed in clause 6 of the 3GPP TS 29.228 [14].
6.2 MC Service User data handling procedures
6.2.1 Data Pull
6.2.1.1 General
This procedure is used between the MC Service Server or the Configuration Management Server and the MC Service User Database.
The procedure is invoked by the MC Service Server or the Configuration Management Server and is used:
– To obtain information for a specific MC Service ID from the MC Service User Database;
– To subscribe to notifications from the MC Service User Database for when particular information associated with a specific MC Service ID is updated.
This procedure is mapped to the commands Data-Pull-Request/Answer in the Diameter application specified in clause 7.2.3/7.2.4. The tables 6.2.1-1 and 6.2.1-2 detail the involved information elements.
Table 6.2.1-1: Data Pull Request
|
Information element name |
Mapping to Diameter AVP |
Cat. |
Description |
|
MC Service ID |
User-Identifier (See 7.3.8) |
M |
This information element contains the MC Service ID of the MC Service user for whom the data is required. See 3GPP TS 23.280 [21]. See clause 7.3.8 for the content of this AVP. |
|
Requested Data |
Data-Identification (See 7.3.3) |
M |
This information element indicates the requested information. The set of valid values are defined in clause 7.3.3. |
|
DPR Flags |
DPR-Flags (See 7.3.13) |
O |
This information element contains one or several flags that define different command behaviours. The set of valid values are defined in clause 7.3.13. |
|
User Data ID |
User-Data-Id |
O |
This information element contain the unique identifier of a given MC Service User Profile defined for an MC Service User. |
Table 6.2.1-2: Data Pull Response
|
Information element name |
Mapping to Diameter AVP |
Cat. |
Description |
|
Result |
Result-Code / Experimental_Result (See 7.4) |
M |
Result of the request. Result-Code AVP shall be used for errors defined in the Diameter base protocol (see IETF RFC 6733 [23]). Experimental-Result AVP shall be used for Data Management application errors. This is a grouped AVP which contains the 3GPP Vendor ID in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP. |
|
Returned Data |
Data (See 7.3.22) |
C |
This information element shall contain the requested data that is successfully returned. This information element shall be present when all requested data exist in the MC Service User Database, the requesting entity has permissions to read them and they are all successfully read. Otherwise, it shall be absent. |
|
Failed Requested Data |
Data-Identification (See 7.3.3) |
C |
This information element indicates the requested data that cannot be retrieved by the requesting entity, when the corresponding error only applies to some of the requested data. The set of valid values are defined in 7.3.3. This information element shall be present when the Experimental-Result-Code AVP is set to "DIAMETER_ERROR_USER_DATA_CANNOT_BE_READ" or "DIAMETER_ERROR_UNKNOWN_DATA" and more than one data was requested. Otherwise, it may be absent. |
|
DPA Flags |
DPA-Flags (See 7.3.14) |
O |
This information element contains one or several flags that define different command behaviours. The set of valid values are defined in clause 7.3.14. |
6.2.1.2 Detailed behaviour of the requesting entity
The MC Service Server or the Configuration Management Server shall make use of this procedure to retrieve from the MC Service User Database the MC Service User Profile associated with an MC Service ID i.e. the user ID of a MC user within a specific MC Service. The request shall include the MC Service ID (e.g. MCPTT ID for MCPTT service) and the requested data. The MC Service Server or the Configuration Management Server may set the "Subscription to notifications" flag in the DPR-Flags to subscribe to the service of notifications for any change for the requested data is requested. Otherwise, the "Subscription to notifications" flag in the DPR-Flags shall be cleared.
The MC Service Server or the Configuration Management Server may make use of this procedure to unsubscribe to the notifications service for a given MC user within a specific MC Service. The request shall include the MC Service ID identifying the MC user within a specific MC Service. The "Subscription to notifications" flag shall be cleared in the DPR-Flags to unsubscribe to the service of notifications for any change for the requested data.
When receiving the Data Pull response with the Result Code set to "DIAMETER_SUCCESS" with the requested MC Service User data, the MC Service Server or the Configuration Management Server should store the received data if the subscription to the notifications service was requested and the "Notifications service status" flag is set by the MC Service User Database in the DPA-Flags AVP.
6.2.1.3 Detailed behaviour of the MC Service User Database
The MC Service User Database may prioritise the received request message according to priority level received within the DRMP AVP.
Upon reception of the Data Pull Request, the MC Service User Database shall check whether the MC Service ID for whom data is asked exists in the MC Service User Database. If not, Experimental-Result-Code shall be set to "DIAMETER_ERROR_USER_UNKNOWN" in the Data Pull Response.
The MC Service User Database shall check whether the requested data exist. If one or more requested data are not recognized or supported by the MC Service User Database, the MC Service User Database shall set the Experimental-Result-Code to "DIAMETER_ERROR_UNKNOWN_DATA" in the Data Pull Response and the Failed Requested Data information element shall be included, indicating the requested data that are not recognized or supported by the MC Service User Database, if more than one data was requested.
The MC Service User Database shall check the Requesting Node permissions list (see clause 6.3) to determine whether the requested data are allowed to be retrieved by the requesting node by checking the combination of the identity of the node sending the request (identified by the Origin-Host AVP included in the request) and the supplied requested data. If one or more requested data are not allowed to be retrieved, Experimental-Result-Code shall be set to "DIAMETER_ERROR_USER_DATA_CANNOT_BE_READ" in the Data Pull Response and the Failed Requested Data information element shall be included, indicating the requested data that are not allowed to be read, if more than one data was requested.
The MC Service User Database shall check whether the requested data are currently being updated by another entity. If there is an update of the data in progress, the MC Service User Database may delay the Data Pull Response until the update has been completed. The MC Service User Database shall ensure that the data returned is not corrupted due to the race condition. If the MC Service User Database is not able to delay the Data Pull Response (e.g. due to timeout), the Experimental-Result-Code shall be set to "DIAMETER_USER_DATA_NOT_AVAILABLE" in the Data Pull Response.
If the "Subscription to notifications" flag in the DPR-Flags was set in the request to subscribe to the service of notifications for any change in the requested data associated with the MC Service ID, the MC Service User Database shall check the Requesting Node permissions list (see clause 6.3) to determine whether the requested data are allowed to be subscribed to notifications by the requesting node by checking the combination of the identity of the node sending the request (identified by the Origin-Host AVP included in the request) and the supplied requested data. If one or more requested data are not allowed to be subscribed to notifications, the "Notifications service status" flag in the DPA-Flags AVP in the Data Pull Response shall be clear. Otherwise, the MC Service User Database shall associate the requesting node identity (identified by the Origin-Host AVP included in the Data Pull Request) with the list of entities that need to be notified when the data requested in the request are modified and the "Notifications service status" flag shall be set in the DPA-Flags AVP in the Data Pull Response.
If the "Subscription to notifications" flag in the DPR-Flags was cleared in the request and a subscription for the data exist in the MCPTT User Database, the MC Service User Database shall remove the requesting node identity (identified by the Origin-Host AVP included in the Data Pull Request) from the list of entities that need to be notified for the requested data indicated in the request and shall clear the "Notifications service status" flag in the DPA-Flags AVP in the Data Pull Response.
If there is an error in any of the above steps then the MC Service User Database shall stop processing and shall return the error code specified in the respective step. Or if the MC Service User Database cannot fulfil the received request for reasons not stated in the above steps, e.g. due to a database error, it shall stop processing the request and set Result-Code to "DIAMETER_UNABLE_TO_COMPLY". Otherwise, the MC Service User Database shall set the Result-Code to "DIAMETER_SUCCESS" in the Data Pull Response and shall include the requested data.
6.2.2 Data Update
6.2.2.1 General
This procedure is used between the Configuration Management Server and the MC Service User Database. The procedure is invoked by the Configuration Management Server and is used:
– To update information for a specific MC Service ID stored into the MC Service User Database.
NOTE: This procedure cannot be used to create or delete an MC Service ID contained in the MC Service User Database. An MC Service user shall be created with at least one MC Service User Profile.
This procedure is mapped to the commands Data-Update-Request/Answer in the Diameter application specified in the clause 7.2.5 and 7.2.6. The tables 6.2.2-1 and 6.2.2-2 detail the involved information elements.
Table 6.2.2-1: Data Update Request
|
Information element name |
Mapping to Diameter AVP |
Cat. |
Description |
|
MC Service ID |
User-Identifier (See 7.3.8) |
M |
This information element contains the MC Service ID of the MC service user for whom the data is required. See 3GPP TS 23.280 [21]. See clause 7.3.8 for the content of this AVP. |
|
Data To Update |
Data (See 7.3.22) |
M |
This information element shall contain the data to be updated. |
|
DUR Flags |
DUR-Flags (See 7.3.15) |
O |
This information element contains one or several flags that define different command behaviours. The set of valid values are defined in clause 7.3.15. |
Table 6.2.2-2: Data Update Response
|
Information element name |
Mapping to Diameter AVP |
Cat. |
Description |
|
Result |
Result-Code / Experimental-Result (See 7.4) |
M |
Result of the update of data in the MC Service User Database. Result-Code AVP shall be used for errors defined in the Diameter base protocol (see IETF RFC 6733 [23]). Experimental-Result AVP shall be used for Data Management application errors. This is a grouped AVP which contains the 3GPP Vendor ID in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP. |
|
MC Service User Profile Data |
MC-Service-User-Profile-Data (See 7.3.20) |
C |
This information shall contain the User-Data-Id associated with an MC Service User Profile that has not been successfully updated if more than one MC Service User Profile is associated with the same MC Service User. This information may also include the Sequence number associated with this MC Service User Profile Data. This information element shall be present if data requested to be updated are MC Service User Profile data and the Result-Code AVP is set to "DIAMETER_LIMITED_SUCCESS" or the Experimental-Result-Code AVP is set to "DIAMETER_ERROR_UNKNOWN_DATA", "DIAMETER_ERROR_USER_DATA_CANNOT_BE_MODIFIED" or "DIAMETER_ERROR_PRIOR_UPDATE_IN_PROGRESS". Otherwise, it shall be absent. |
|
Failed Requested Data |
Data-Identification (See 7.3.3) |
C |
This information element indicates the data that have not been successfully updated. The set of valid values are defined in 7.3.3. This information element shall be present if the Result-Code AVP is set to "DIAMETER_LIMITED_SUCCESS" or the Experimental-Result-Code AVP is set to "DIAMETER_ERROR_UNKNOWN_DATA", "DIAMETER_ERROR_USER_DATA_CANNOT_BE_MODIFIED" or "DIAMETER_ERROR_PRIOR_UPDATE_IN_PROGRESS". Otherwise, it may be absent. |
|
DUA Flags |
DUA-Flags (See 7.3.16) |
O |
This information element contains one or several flags that define different command behaviours. The set of valid values are defined in clause 7.3.16. |
6.2.2.2 Detailed behaviour of the Configuration Management Server
The Configuration Management Server shall make use of this procedure to update data associated to an MC Service ID (i.e. the user ID of a MC user within a specific MC Service) stored into the MC Service User Database. The request shall include the MC Service ID identifying the MC user within a specific MC Service (e.g. MCPTT ID for MCPTT service) and the data requested to be updated.
When data requested to be updated are the MC Service User Profile data, the request shall include the MC Service User Profile data and the Sequence Number associated with the MC Service User Profile. The request may also include the User Data Id if more than one MC Service User Profile is associated with the same MC Service User. Multiple MC Service User Profiles for the same MC Service can be updated and, in this case, each MC Service User Profile data shall contain a Sequence Number and the User Data Id. Each updated MC Service User Profile data shall be associated with a Sequence Number of n+1 where n is the original Sequence Number associated with the MC Service User Profile before modification. If n was equal to 65535, the new associated Sequence Number shall be equal to 1.
When more than one data is requested to be updated, the Configuration Management Server may set the "Atomicity" flag in the DUR-Flags to indicate that all the requested data shall be updated by the MC Service User Database or none of them shall be updated if at least one data element cannot be updated.
When receiving "DIAMETER_LIMITED_SUCCESS" in the Data Update Response, including the indication of the requested data that have not been successfully updated, the Configuration Management Server may reattempt to update the affected data.
When receiving "DIAMETER_ERROR_DATA_OUT_OF_SYNC" in the Data Update Response when attempting to update an MC Service User Profile, the Configuration Management Server may attempt to resolve the inconsistency between the version of the MC Service User Profile that it holds and the version stored at the MC Service User Database. It may execute a Data Pull to retrieve the current version of the data from the MCPTT User Database or it may wait to receive a subsequent Notification request from the MC Service User Database for the affected MC Service User Profile.
When receiving "DIAMETER_ERROR_PRIOR_UPDATE_IN_PROGRESS" in the Data Update Response, the configuration Management Server may wait to receive a subsequent Notification request from the MC Service User Database for the affected MC Service User Profile or it may reattempt to update the data.
6.2.2.3 Detailed behaviour of the MC Service User Database
The MC Service User Database may prioritise the received request message according to priority level received within the DRMP AVP.
Upon reception of the Data Update Request, the MC Service User Database shall check whether the MC Service ID for whom data is asked exists in the MC Service User Database. If not, Experimental-Result-Code shall be set to "DIAMETER_ERROR_USER_UNKNOWN" in the Data Update Response.
The MC Service User Database shall check whether the requested data exist. If any of the requested data is not available into the MC Service User Database, the MCPTT User Database shall set the Experimental-Result-Code to "DIAMETER_ERROR_UNKNOWN_DATA" in the Data Update Response and the Failed Requested Data information element shall be included, indicating the requested data that are unknown to the MC Service User Database, if more than one data was requested.
The MC Service User Database shall check the Requesting Node permissions list (see clause 6.3) to determine whether the requested user data is allowed to be updated by this requesting node by checking the combination of the identity of the node sending the request (identified by the Origin-Host AVP included in the request) and the supplied requested data. If any of the requested data is not allowed to be updated, Experimental-Result-Code shall be set to "DIAMETER_ERROR_USER_DATA_CANNOT_BE_MODIFIED" in the Data Update Response and the Failed Requested Data information element shall be included, indicating the requested data that are not allowed to be modified, if more than one data was requested.
The MC Service User Database shall check whether the data that is requested to be updated by the requesting node is currently being updated by another entity. If there is an update of any requested data in progress, Experimental-Result-Code shall be set to "DIAMETER_ERROR_PRIOR_UPDATE_IN_PROGRESS" in the Data Update Response and the Failed Requested Data information element shall be included, indicating the requested data that are being updated by another entity, if more than one data was requested.
If the updated data are MC Service User Profile data, the MC Service User Database shall identify the MC Service User Profile to update using the User Data Id (if multiple MC Service User Profiles exist for the same MC Service) and check the Sequence Number contained in the MC Service User Profile data included in the request. If either:
– the Sequence Number is equal to 0;
– or (Sequence_Number_in_Data_Update – 1) is not equal to (Sequence_Number_In_MC_Service_User_Database modulo 65535);
then, the Experimental-Result-Code shall be set to "DIAMETER_ERROR_DATA_OUT_OF_SYNC" in the Data Update Response.
If there is more data than the MCPTT User Database is prepared to accept then Experimental-Result-Code shall be set to "DIAMETER_ERROR_TOO_MUCH_DATA" and the new data shall be discarded.
If the data requested to be updated are the MC Service User Profile data and if the MC Service User Profile and/or the Sequence Number and/or the User Data Id (if multiple MC Service User Profiles exist for the same MC Service) is not present in the request, then Experimental-Result-Code shall be set to "DIAMETER_ERROR_REQUIRED_KEY_NOT_PROVIDED", the Failed Requested Data information element shall be included indicating the requested data that causes the error (if more than one data was requested) and the operation shall be ignored by the MC Service User Database.
If multiple data have to be updated, the steps above shall be repeated for each data element. The MC Service User Database shall check if the "Atomicity" flag in set in the DUR-Flags:
– If set and the MC Service User Database does not support atomic operation, the MC Service User Database shall set the Result-Code to "DIAMETER_ERROR_ATOMICITY_NOT_SUPPORTED" in the Data Update Response and no data shall be updated.
– If set and the MC Service User Database supports atomic update operation, if one of the updates fails, the MC Service User Database shall keep or restore all the stored data as they were before receiving the Data Update request and the MC Service User Database shall send the Data Update Response with the Result-Code or Experimental-Result set to value appropriate to the encountered error case. Otherwise, if all updated are successful, the requested operation shall take place and the MC Service User Database shall return the Result-Code AVP set to "DIAMETER_SUCCESS" in the Data Update Response
– If not set, the Data Update may be partially successful if it is successful for the update of only a part of the data instances in the request. In such a case, the MC Service User Database shall set the Result-Code to "DIAMETER_LIMITED_SUCCESS" in the Data Update Response. This Data Update Response indicates the data that have not been successfully updated. If the requested update was for more than one MC Service User Profile, the MC Service User Database shall include in the Data Update Response the User-Data-Id of the MC Service User Profile(s) that has/have not been successfully updated.
The successfully updated data stored at the MC Service User Database shall trigger the sending of notifications to any other entities that are subscribed to Notifications for updates to the modified data for that MC Service ID (see 6.2.3).
If the updated data are MC Service User Profile, the Sequence Number received in the Data Update request shall be associated with the updated MC Service User Profile data, optionally identified by the User-Data-Id in the request.
If there is an error in any of the above steps then the MC Service User Database shall stop processing and shall return the error code specified in the respective step (see clause 7.4 for an explanation of the error codes).
If the MC Service User Database cannot fulfil the received request for reasons not stated in the above steps, e.g. due to database error, it shall stop processing the request and set Result-Code to "DIAMETER_UNABLE_TO_COMPLY" in the Data Update Response.
6.2.3 Data Notification
6.2.3.1 General
This procedure is used between the MC Service User Database and the MC Service Server or the Configuration Management Server. The procedure is invoked by the MC Service User Database and is used:
– To inform the MC Service Server or the Configuration Management Server of changes in particular information associated with an MC Service ID stored in the MC Service User Database to which the MC Service Server or the Configuration Management Server has previously subscribed to receive Notifications for, using the Data Pull request (see 6.2.1).
This procedure is mapped to the commands Notification-Data-Request/Answer in the Diameter application specified in the clause 7.2.7 and 7.2.8. The tables 6.2.3-1 and 6.2.3-2 detail the involved information elements.
Table 6.2.3-1: Data Notification Request
|
Information element name |
Mapping to Diameter AVP |
Cat. |
Description |
|
MC Service ID |
User-Identifier (See 7.3.8) |
M |
This information element contains the MC Service ID of the MC Service user for whom the data is required. See 3GPP TS 23.280 [21]. See clause 7.3.8 for the content of this AVP. |
|
Returned Data |
Data (See 7.3.22) |
M |
This information element shall contain the data to which the requesting entity is subscribed to notification of change. |
|
NDR Flags |
NDR-Flags (See 7.3.17) |
O |
This information element contains one or several flags that define different command behaviours. The set of valid values are defined in clause 7.3.13. |
Table 6.2.3-2: Data Notification Response
|
Information element name |
Mapping to Diameter AVP |
Cat. |
Description |
|
Result |
Result-Code / Experimental-Result (See 7.4) |
M |
Result of the request. Result-Code AVP shall be used for errors defined in the Diameter base protocol (see IETF RFC 6733 [23]). Experimental-Result AVP shall be used for Data Management application errors. This is a grouped AVP which contains the 3GPP Vendor ID in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP. |
|
Failed Requested Data |
Data-Identification (See 7.3.3) |
C |
This information element indicates the requested information that the receiving entity is not able to process. The set of valid values are defined in 7.3.3. This information element shall be present when the Experimental-Result-Code AVP is set to "DIAMETER_ERROR_NO_SUBSCRIPTION_TO_DATA", or "DIAMETER_ERROR_USER_DATA_NOT_RECOGNIZED". Otherwise, it may be absent. |
|
NDA Flags |
NDA-Flags (See 7.3.18) |
O |
This information element contains one or several flags that define different command behaviours. The set of valid values are defined in clause 7.3.18. |
6.2.3.2 Detailed behaviour of the MCPTT User Database
The MC Service User Database shall make use of this procedure to update information associated with an MC Service ID for which a MC Service Server or a Configuration Management Server has previously subscribed to receive Notifications for. The request shall include the MC Service ID identifying the MC user within a specific MC Service (e.g. MCPTT ID for MCPTT service) and the modified data.
If the notification is sent to modify an MC Service User Profile, the request shall include the MC Service User Profile data, including the Sequence number and the User Data Id (required if more than one MC Service User Profile exists for the same MC Service).
When receiving the Notification response with the Experimental-Result-Code set to "DIAMETER_ERROR_NO_SUBSCRIPTION_TO_DATA", "DIAMETER_ERROR_USER_UNKNOWN", "DIAMETER_ERROR_TOO_MUCH_DATA" or "DIAMETER_ERROR_USER_DATA_NOT_RECOGNIZED", the MCPTT User Database shall remove the responding entity from the list of entities that need to be notified of any change in information associated with the MC Service ID included in the request.
6.2.3.3 Detailed behaviour of the receiving entity
The MC Service Server or the Configuration Management Server may prioritise the received request message according to priority level received within the DRMP AVP.
Upon reception of the Notification Request, the receiving entity shall check whether the MC Service ID for which the Notification Request is received is served by the receiving entity. If not, the Experimental-Result-Code shall be set to "DIAMETER_ERROR_USER_UNKNOWN" in the Notification Data Response.
The receiving entity shall check whether the modified data are recognized or supported by the receiving entity. If not, the Experimental-Result-Code shall be set to "DIAMETER_ERROR_USER_DATA_NOT_RECOGNIZED" in the Notification Response. This Notification Data Response shall indicate the data that are not recognized or supported by the receiving entity, if more than one data was requested.
The receiving entity shall check whether it has subscribed to notifications for the modified data that are received. If not, the Experimental-Result-Code shall be set to "DIAMETER_ERROR_NO_SUBSCRIPTION_TO_DATA" in the Notification Data Response. This Notification Data Response shall indicate the data for which the notification service has not been subscribed, if more than one data was requested.
If there is more data than the receiving entity is prepared to accept then Experimental-Result-Code shall be set to "DIAMETER_ERROR_TOO_MUCH_DATA" and the new data shall be discarded. This Notification Data Response may indicate the data that have not been successfully updated
If the notification includes multiple data that are modified, the steps above shall be repeated for each data element. If an error occurs, the receiving entity shall stop processing and shall return the Result-Code or Experimental-Result-Code set to value specified in the respective step (see clause 7.4 for an explanation of the error codes). The Notification Data Response may indicate the requested data that have not been successfully processed.
Otherwise, the requested operation shall take place and the receiving entity shall return the Result-Code AVP set to "DIAMETER_SUCCESS" in the Notification Response. If the receiving entity locally stores the data for which it has received the notification, the received data shall be updated. In this case, if the modified data are MC Service User Profile data, each modified MC Service User Profile shall be associated with the corresponding Sequence Number received in the Notification request.
6.3 Requesting entity permissions list
6.3.1 General
Some of the individual elements identified by the Requested Data information element may be requested by the MC Service Server or the Configuration Management Server from the MC Service User Database using the Data Pull operation (see clause 6.2.1) or may be updated at the MC Service User Database by the Configuration Management Server using the Data Update operation (see clause 6.2.2). The MC Service Server or the Configuration Management Server may also request the MC Service User Database to be notified of changes to specific elements identified by Requested Data information element using the "Subscription to notifications" flag in the DPR-Flags of the Data Pull operation (see clause 6.2.1). The MC Service User Database will only allow these operations to take place if the Requested Data information element is permitted to be included in the specific command requested by the MC Service Server or the Configuration Management Server.
To manage whether an MC Service Server or a Configuration Management Server may request each requested data element with a specific operation, the MC Service User Database shall maintain a list of Requesting Entity permissions (the "Requesting Entity Permissions List"). Requesting entity permissions are identified by the requesting entity identity and the requested data with the possible permissions associated with each requested data for Data Pull and Data Update operations or any combination of these permissions. The permissions shall apply to all MC Service Users served by the MC Service User Database. When an MC Service Server or a Configuration Management Server requests Data Pull or Data Update, the MC Service User Database shall check permissions and return an error result if the MC Service Server or the Configuration Management Server does not have the required permission. If the Requesting Entity permissions change in a later stage, the MC Service User Database shall update the "Requesting Entity Permission List" accordingly.
Table 6.3-1, Table 6.3-2 and Table 6.3-3 define the requested data, access key and requesting entity permissions for the operation(s) on data accessible via the MCPTT-2, MCVideo-2, MCData-2 or CSC-13 interface, i.e. the listed operation(s) in the Operations column are the only ones allowed to be used with this requested data value. It is a matter of operator policy to further restrict the requesting entity permission rights defined in table 6.3-1, table 6.3-2 or table 6.3-3.
An access key between square brackets is considered as optional, while when more than one access key is separated by logical OR and included between brackets, it means that one (and only one) of these access keys is mandatory.
Table 6.3.1-1: Data accessible via MCPTT-2 or CSC-13 interface
|
Bit. |
Data element |
Defined in |
Access key |
Operations |
|
0 |
MCPTT User Profile |
7.3.3 |
Requested Data + MCPTT ID |
Data Pull (Read) Data Pull (Subscription to Notification) |
|
MCPTT ID |
Data Update (NOTE 1) |
|||
|
NOTE 1: In this release, Data update operations are only allowed for Configuration Management Servers |
||||
Table 6.3.1-2: Data accessible via MCVideo-2 or CSC-13 interface
|
Bit. |
Data element |
Defined in |
Access key |
Operations |
|
1 |
MCVideo User Profile |
7.3.3 |
Requested Data + MCVideo ID |
Data Pull (Read) Data Pull (Subscription to Notification) |
|
MCVideo ID |
Data Update (NOTE 1) |
|||
|
NOTE 1: In this release, Data update operations are only allowed for Configuration Management Servers |
||||
Table 6.3.1-3: Data accessible via MCData-2 or CSC-13 interface
|
Bit. |
Data element |
Defined in |
Access key |
Operations |
|
2 |
MCData User Profile |
7.3.3 |
Requested Data + MCData ID |
Data Pull (Read) Data Pull (Subscription to Notification) |
|
MCData ID |
Data Update (NOTE 1) |
|||
|
NOTE 1: In this release, Data update operations are only allowed for Configuration Management Servers |
||||