5 Mission critical MBMS application programming interfaces
23.4793GPPRelease 17Technical Specification Group Services and System AspectsTSUE MBMS APIs for Mission Critical Services
5.1 General
This clause defines the MC MBMS API that enables the MC applications to get access to MBMS capabilities exposed by MC MBMS user agent, corresponding to the function models defined in clause 4. The MC MBMS API supports the use of MBMS transmission for mission critical services as defined in 3GPP TS 23.280 [3], 3GPP TS 23.379 [4], 3GPP TS 23.281 [5] and 3GPP TS 23.282 [6]; and these API functions comply with multicast group communications enabled by GCSE as defined in 3GPP TS 23.468 [2].
5.2 Get MBMS SAI
5.2.1 General
This subclause defines API functions of get MBMS SAI request and get MBMS SAI response.
The get MBMS SAI request is asynchronous API function call and the get MBMS SAI response providing the result is sent via callback mechanism.
The MC application uses this API function call to obtain the MBMS SAI(s) of which the UE is currently located.
5.2.2 Procedures
Figure 5.2.2-1 illustrates the procedure of get MBMS SAI by which the MC application queries the current MBMS SAI(s) that the MC service UE is located.
Pre-conditions:
– The MC application has registered towards the MC MBMS user agent.
Figure 5.2.2-1: Get MBMS SAI procedure
1. The MC application queries the MBMS SAI information from the MC MBMS user agent.
2. The MC MBMS user agent responds with the SAI(s) of which the UE is currently located.
Post-conditions:
– The MC application is able to report the MBMS SAI information.
5.2.3 Information flows
5.2.3.1 Get MBMS SAI request
The get MBMS SAI request does not have input parameters.
5.2.3.2 Get MBMS SAI response
Table 5.2.3.2-1 describes the information flow for the get MBMS SAI response.
Table 5.2.3.2-1: Get MBMS SAI response
|
Information element |
Status |
Description |
|
MBMS SAIs |
M |
A list of MBMS SAIs that are available where the MC service UE is currently located |
|
Result |
M |
Result of the API call (success or failure) |
|
Reason code |
O |
The code for failure |
5.3 MBMS SAI update notification
5.3.1 General
This subclause defines API function of MBMS SAI update notification.
The SAI update notification is a callback function that notifies about the updated MBMS SAI(s) detected by MC MBMS user agent.
The MC application receives the notification when the MBMS SAI(s) of the UE changed.
The subscription for the notification is performed with the registration of the MC application.
5.3.2 Procedures
Figure 5.3.2-1 illustrates the procedure of MBMS SAI update notification by which the MC application is notified about the updated MBMS SAIs upon the occurrence of the MBMS SAI change.
Pre-conditions:
– The MC application has registered towards the MC MBMS user agent.
– The MBMS SAI(s) where the MC service UE is located has changed.
Figure 5.3.2-1: MBMS SAI update notification procedure
1. The MC MBMS user agent detects the MBMS SAI(s) of which the MC service UE resides on has changed.
2. The MC MBMS user agent notifies the MC application about the updated SAI information.
Post-conditions:
– The MC application is able to report the MBMS SAI information.
5.3.3 Information flows
5.3.3.1 MBMS SAI update notification
Table 5.3.3.1-1 describes the information flow for the MBMS SAI update notification.
Table 5.3.3.1-1: MBMS SAI update notification
|
Information element |
Status |
Description |
|
MBMS SAIs |
M |
A list of MBMS SAIs that are available where the MC service UE is currently located |
5.4 Get cell info
5.4.1 General
This subclause defines API functions of get cell info request and get cell info response.
The get cell info request is an asynchronous API function call and the get cell info response providing the result is sent via callback mechanism.
The MC application uses this API function call to obtain the information of the cell where the UE is currently located.
5.4.2 Procedures
Figure 5.4.2-1 illustrates the procedure of get cell info by which the MC application queries the current cell information of the MC service UE.
Pre-conditions:
– The MC application has registered towards the MC MBMS user agent.
Figure 5.4.2-1: Get cell info procedure
1. The MC application queries the cell information from the MC MBMS user agent.
2. The MC MBMS user agent responds with the cell information of which the UE is currently located.
Post-conditions:
– The MC application is able to report the cell location information.
5.4.3 Information flows
5.4.3.1 Get cell info request
The get cell info request does not have input parameters.
5.4.3.2 Get cell info response
Table 5.4.3.2-1 describes the information flow for the get cell info response.
Table 5.4.3.2-1: Get cell info response
|
Information element |
Status |
Description |
|
Cell Info |
M |
ECGI of the cell where the MC service UE is currently located |
|
Result |
M |
Result of the API call (success or failure) |
|
Reason code |
O |
The code for failure |
5.5 Cell update notification
5.5.1 General
This subclause defines API function of cell update notification.
The cell update notification is a callback function that notifies about the updated cell location detected by MC MBMS user agent.
The MC application receives the notification when the cell location of the UE changed.
The subscription for the notification is performed with the registration of the MC application.
5.5.2 Procedures
Figure 5.5.2-1 illustrates the procedure of cell update notification by which the MC application is notified about the updated cell information upon the occurrence of cell change.
Pre-conditions:
– The MC application has registered towards the MC MBMS user agent.
– The cell of the MC service UE has changed.
Figure 5.5.2-1: Cell update notification procedure
1. The MC MBMS user agent detects the cell change on the MC service UE.
2. The MC MBMS user agent notifies the MC application about the updated cell information.
Post-conditions:
– The MC application is able to report the cell information update.
5.5.3 Information flows
5.5.3.1 Cell update notification
Table 5.5.3.1-1 describes the information flow for the cell update notification.
Table 5.5.3.1-1: Cell update notification
|
Information element |
Status |
Description |
|
Cell Info |
M |
ECGI of the cell where the MC service UE is currently located |
5.6 Application registration
5.6.1 General
Registration is required to perform initialization operations for using the MC MBMS API. The purpose of application registration is to allow access of MBMS service on the UE for MC applications. This registration also uniquely identifies each MC application that can access MBMS service on the UE and provides the MC MBMS user agent the call back listeners to receive asynchronous notifications on relevant events.
5.6.2 Procedures
Figure 5.6.2-1 illustrates the procedure for application registration. This procedure allows the MC application to register with the MC MBMS user agent to consume MC services delivered over MBMS. It has two purposes:
a) It identifies the MC application registering with the MC MBMS user agent;
b) It allows the MC application to identify its callback listeners for the MC MBMS user agent to provide asynchronous notifications on relevant events.
NOTE: Since some application development frameworks do not support callback functions, an MC application for these frameworks will not provide callback listeners in this procedure. Instead, the MC application will implement the necessary approach available on these frameworks to receive event notifications from the MC MBMS user agent in place of callback functions. The notifications implemented on these frameworks will include the same information content.
Pre-conditions:
– The MC application has discovered the availability of the MC MBMS API.
Figure 5.6.2-1: Application registration procedure
1. MC application registers to the MC MBMS user agent with the application registration request.
2. MC MBMS user agent registers the application
3. Registration result is notified to the MC application.
Post-conditions:
– If registration is successful, the MC application can proceed with other MC MBMS API interactions with the MC MBMS user agent.
5.6.3 Information flows
5.6.3.1 Application registration request
Table 5.6.3.1-1 describes the information flow for the application registration request.
Table 5.6.3.1-1: Application registration request
|
Information element |
Status |
Description |
|
Application ID |
M |
Provides a unique ID for the application registering with the MC MBMS user agent. |
|
Group communication callback |
O (see NOTE) |
Provides the call back listener. |
|
Application specific context |
O |
Enables the MC MBMS user agent to distinguish different applications. |
|
NOTE: The callback element is optional and only included when the application development framework supports programmatic callback interfaces. If callbacks are not supported on a given application development framework, the same information content as defined on the callback structures is to be provided to the application via the notification callback available with that development framework when the respective condition is met. |
||
5.6.3.2 Application registration response
Table 5.6.3.2-1 describes the information flow for the application registration response.
Table 5.6.3.2-1: Application registration response
|
Information element |
Status |
Description |
|
Response code |
M |
Provides the result of the registration request: success, failure or missing parameters. |
|
Message |
O |
Provides an associated text description of the error message, if registration failed |
5.7 Application deregistration
5.7.1 General
The application deregistration allows the MCA to deregister from the MC-MUA.
5.7.2 Procedures
Figure 5.7.2-1 illustrates the procedure for application deregistration.
Pre-conditions:
– The MC application is registered towards the MC MBMS user agent.
Figure 5.7.2-1: Application deregistration procedure
1. The MC application deregisters. No additional notification from the MC MBMS user agent is expected by the MC application.
2. The MC MBMS user agent interrupts all operations previously requested by the MC application and deletes any parameters and/or internal state associated to this application.
Post-conditions:
– The MC application can no more proceed any API interactions with the MC MBMS user agent till a new execution of the application registration procedure.
5.7.3 Information flows
5.7.3.1 Application deregistration request
There are no information elements within the application deregistration request.
5.8 MBMS bearer registration
5.8.1 General
The MBMS bearer registration is used by the MC application to exchange information about an announced MBMS bearer with the MC MBMS client. The MC MBMS user agent checks the availability of this MBMS bearer and, if required, monitors its quality.
5.8.2 Procedures
Figure 5.8.2-1 illustrates the procedure for MC MBMS bearer registration. This procedure allows the MC application to inform the MC MBMS user agent about an MBMS bearer announced to the MC application.
Pre-conditions:
– The MC application is registered towards the MC MBMS user agent.
– An MC MBMS bearer has been announced to the MC application by the MC service server.
Figure 5.8.2-1: MC MBMS bearer registration procedure
1. The MC application registers a newly announced MBMS bearer to the MC MBMS user agent. The MC application informs the MC MBMS user agent if reception quality evaluation is expected from the MC MBMS user agent.
2. The MC MBMS user agent registers the new MBMS bearer.
NOTE: If the MBMS bearer is announced with a list of alternative TMGIs, the MC application can register the MBMS bearer several times, for each distinct TMGI.
3. The MC MBMS user agent notifies the MC application about the registration result.
Post-conditions:
– If registration is successful, the MC MBMS user agent checks the MBMS bearer presence and executes MC MBMS bearer availability procedure.
5.8.3 Information flows
5.8.3.1 MC MBMS bearer registration request
Table 5.8.3.1-1 describes the information flow for the MC MBMS bearer registration request.
Table 5.8.3.1-1: MC MBMS bearer registration request
|
Information element |
Status |
Description |
|
TMGI |
M |
TMGI information |
|
List of service area identifier |
M |
A list of service area identifier for the applicable MBMS broadcast area |
|
Frequency |
O |
Identification of frequency if multi carrier support is provided |
|
Monitoring reception quality |
O |
This boolean is used to control if the MC MBMS user agent is actively monitoring the MBMS bearer quality or not |
5.8.3.2 MC MBMS bearer registration response
Table 5.8.3.2-1 describes the information flow for the MC MBMS bearer registration response.
Table 5.8.3.2-1: MC MBMS bearer registration response
|
Information element |
Status |
Description |
|
TMGI |
M |
TMGI information |
|
Response code |
M |
Provides the result of the registration request: success, failure or missing parameters |
|
Message |
O |
Additional details |
5.9 MBMS bearer deregistration
5.9.1 General
The MBMS bearer deregistration allows the MC application to deregister an MBMS bearer with the MC MBMS user agent.
5.9.2 Procedures
Figure 5.9.2-1 illustrates the procedure for MC MBMS bearer deregistration. The MC application can execute this procedure when this MBMS bearer has been de-announced.
Pre-conditions:
– The MC application is registered towards the MC MBMS user agent.
– An MBMS bearer has been announced to the MC application and registered within the MC MBMS user agent.
– The MBMS bearer is de-announced by the MC service server towards the MC application.
Figure 5.9.2-1: MC MBMS deregistration procedure
1. The MC application deregisters the MBMS bearer with the MC MBMS user agent. No additional notification from the MC MBMS user agent is expected by the MC application related to this MBMS bearer.
2. The MC MBMS user agent interrupts all operations previously requested by the MC application for this MBMS bearer and deletes any parameters and/or internal state associated to this MBMS bearer.
3. The MC MBMS user agent notifies the MC application about the deregistration result.
Post-conditions:
– The MC application can no more proceed any API interactions with the MC MBMS user agent related to this MBMS bearer, e.g. API interactions for media consumption.
5.9.3 Information flows
5.9.3.1 MC MBMS bearer deregistration request
Table 5.9.3.1-1 describes the information flow for the MC MBMS bearer deregistration request.
Table 5.9.3.1-1: MC MBMS bearer deregistration request
|
Information element |
Status |
Description |
|
TMGI |
M |
TMGI information |
5.9.3.2 MC MBMS bearer deregistration response
Table 5.9.3.2-1 describes the information flow for the MC MBMS bearer deregistration response.
Table 5.9.3.2-1: MC MBMS bearer deregistration response
|
Information element |
Status |
Description |
|
Response code |
M |
Provides the result of the deregistration request: success, failure or missing parameters |
|
Message |
O |
Additional details |
5.10 MBMS bearer notification
5.10.1 General
The MBMS bearer notification is used by the MC MBMS user agent to notify the MC application about events related to the MBMS bearer availability and quality.
5.10.2 Procedures
5.10.2.1 MC MBMS bearer availability
Figure 5.10.2.1-1 illustrates the procedure for MC MBMS bearer availability. This procedure allows the MC MBMS user agent to notify the MBMS application that a registered MBMS bearer is available within the UE location.
Pre-conditions:
– The MC application is registered towards the MC MBMS user agent.
– An MBMS bearer has been announced to the MC application.
– The MC application has registered this MBMS bearer within the MC MBMS user agent
– No MBMS bearer availability notification has been sent since the MBMS bearer registration, or the MBMS bearer availability status has changed.
NOTE: The MC MBMS user agent may additionnally repeat the MBMS bearer availability notification even if the bearer availability status is unchanged. Such behavior is left to implementation.
Figure 5.10.2.1-1: MC MBMS bearer availability procedure
1. The MC MBMS user agent continuously checks if the MBMS bearer is available at the UE location.
2. If the MBMS bearer availability status has changed, the MC MBMS user agent sends a MC MBMS bearer availability notification. If the MBMS bearer is resumed, the MC MBMS bearer availability notification contains the status of MBMS resumption. If the MBMS bearer is suspended, the MC MBMS bearer availability notification contains the status of MBMS suspension.
Post-conditions:
– If the MBMS bearer became available and if MBMS bearer quality evaluation is required by the MC application, as asked during the MBMS registration procedure, the MC MBMS user agent executes the MC MBMS bearer quality evaluation procedure.
– If the MBMS bearer became unavailable, the MBMS bearer quality evaluation procedure, if in execution, is interrupted.
– If the MBMS bearer is resumed, the MC application may send the MBMS suspension report to the MC service server indicating the MBMS resumption.
– If the MBMS bearer is suspended, the MC application may send the MBMS suspension report to the MC service server indicating the MBMS suspension.
5.10.2.2 MC MBMS bearer quality evaluation
Figure 5.10.2.2-1 illustrates the procedure for MC MBMS bearer quality evaluation. This procedure allows the MC MBMS user agent to notify the MBMS application about the evaluated quality of the MBMS bearer.
Pre-conditions:
– The MC application is registered towards the MC MBMS user agent.
– An MBMS bearer has been announced to the MC application by the MC service server.
– The MC application has registered this MBMS bearer within the MC MBMS user agent and required quality evaluation.
– The MBMS bearer is available at the UE location.
Figure 5.10.2.2-1: MC MBMS bearer quality evaluation procedure
1. The MC MBMS user agent continuously evaluates reception for the MBMS bearer.
2. When reception quality evaluation is done and
– No notification for the reception quality evaluation has been done since the last MC MBMS bearer availability notification for this given MBMS bearer; or
– The reception quality evaluation or reception quality level is different to the last reception quality notification.
Then, the MC MBMS user agent notifies the MC application about the reception quality.
Note: The need for a hysteresis within the MC MBMS user agent, to avoid sending too frequent reception quality evaluation notifications is left to implementation.
Post-conditions:
– The MC MBMS user agent keeps executing the MC MBMS bearer quality evaluation procedure.
5.10.3 Information flows
5.10.3.1 MC MBMS bearer availability
Table 5.10.3.1-1 describes the information flow for the MC MBMS bearer availability notification. This information flow is used for notification about MBMS bearer availability and unavailability.
Table 5.10.3.1-1: MC MBMS bearer event notification
|
Information element |
Status |
Description |
|
TMGI |
M |
TMGI information |
|
Event code |
M |
Code providing the nature of the event |
|
Message |
O |
Additional details |
Table 5.10.3.1-2 provides the list of events identified by the event code IE, sent by MC MBMS bearer availability notifications.
Table 5.10.3.1-2: Event list
|
Event |
Description |
|
Available |
The MBMS bearer is available |
|
Resumed |
The MBMS bearer is resumed after suspension. |
|
Unavailable |
The MBMS bearer is unavailable |
|
Suspended |
The MBMS bearer is suspended |
5.10.3.2 MC MBMS bearer quality evaluation
Table 5.10.3.2-1 describes the information flow for the MC MBMS bearer quality evaluation. This information flow is used for notification about MBMS bearer reception quality.
Table 5.10.3.2-1: MC MBMS bearer quality evaluation
|
Information element |
Status |
Description |
|
TMGI |
M |
TMGI information |
|
Reception quality evaluation |
M |
Indicates if the reception quality for the MBMS bearer is evaluated good or bad (binary evaluation). |
|
Reception quality level |
O |
Level of reception quality (see NOTE) |
|
Message |
O |
Additional details |
|
NOTE: The set of discrete quality levels helps enable the make-before-break procedure (subclause 5.3.3.2 of 23.468 [2]) by the application. How these levels are derived is implementation specific. |
||
5.11 Open media
5.11.1 General
This subclause specifies the open media to start the reception of a given media delivered over an MBMS subchannel.
With this API function, header decompression and FEC decoding can be performed by the MC MBMS user agent or by the MC application.
This API function allows two methods to return the media from the MC MBMS user agent to the MC application: by providing them on a local network interface or by returning them with a callback mechanism.
NOTE: This specification does not specify wether the local network interface for returning the media is managed by the MC MBMS user agent or by the lower layer of the UE (modem).
5.11.2 Procedures
The procedure specified in figure 5.11.2-1 allows the consumption of a media delivered over MBMS.
Pre-conditions:
– The MC application is registered towards the MC MBMS user agent
– A MBMS bearer has been announced to the MC application through the MBMS procedures specified in 3GPP TS 23.280 [3] and registered toward the MC MBMS user agent.
– This MBMS bearer is available within the UE location.
– The MC application has received a MapGroupToBearer message (see 3GPP TS 23.379 [4], table 10.10.1.1-1 for MCPTT and 3GPP TS 23.281 [5], table 7.10.1.2-1 for MCVideo).
Figure 5.11.2-1: Open media procedure
1. The MC application asks to access to the communication with the open media request, by indicating the TMGI of the MBMS bearer and a list of media description information. If the MC application requests FEC decoding and/or header decompression, relevant FEC and ROHC information are included within the open media request; if the MC application wants the media packets to be returned by callback, the MC application provides a callback listener.
2. The MC MBMS user agent checks if the MBMS bearer of the media is available and starts its reception.
NOTE: The MBMS bearer may transport several media, e.g. application control signalling, media. The MBMS bearer reception may already be started if another media transported by this MBMS bearer has been opened.
3. When the media is available, the MC MBMS user agent sends an open media response to the MC application, including a description of the required media (which can be with or without FEC decoding). If packets are returned to the MC application through a local network interface, this network interface name is included in the response.
4. The MC MBMS user agent makes the media streams available to the MC application according to the configured method for returning media with a help of a local network interface, or by returning the media packets to the callback listener provided in step 1.
Post-conditions:
– The MC application can consume the required media, until interruption if the MBMS bearer becomes unavailable, or until it closes the media with the close media procedure.
5.11.3 Information flows
5.11.3.1 Open media request
Table 5.11.3.1-1 describes the information flow for the open media request.
Table 5.11.3.1-1: Open media request
|
Information element |
Status |
Description |
|
TMGI |
M |
TMGI information of the announced MBMS bearer |
|
Media description |
O |
Describes the multicast IP adresses and ports of the requested media. (e.g. the MBMS subchannel). |
|
FEC information |
O |
FEC information if the MC application requests the MC MBMS user agent to perform the FEC decoding. |
|
ROHC information |
O |
ROHC information for the requested media. Indicates if header decompression by the MC MBMS user agent is requested. |
|
Callback |
O |
Dedicated callback listener where to return the received media packets. If this IE is not present, the media packets are returned over a local network interface. |
5.11.3.2 Open media response
Table 5.11.3.2-1 describes the information flow for the open media response.
Table 5.11.3.2-1: Open media response
|
Information element |
Status |
Description |
|
Media identifier |
M |
Identifier from the open media request |
|
Response code |
M |
Indicates if the open media request was successful, otherwise an error code |
|
Message |
O |
Additional details |
|
Media description |
O |
Description of opened media, including the multicast IP address and port of the media, after FEC decoding |
|
Network interface |
O |
The local network interface, identified by the name of a network interface card, where the given media can be consumed by the MC application, if packet are forwarded to the MC application over a local network interface according the configured method for media reception |
5.12 Close media
5.12.1 General
This subclause specifies the close media invoked by the MC application to stop the reception of a given media.
5.12.2 Procedures
Figure 5.12.2-1 illustrates the procedure for close media.
Pre-conditions:
– The MC application is consuming a media, after having called the open media procedure.
– The MC application has received a UnMapGroupToBearer message (see 3GPP TS 23.379 [6], table 10.10.1.2 -1 for MCPTT and 3GPP TS 23.281 [4], table 7.10.1.3-1 for MCVideo).
Figure 5.12.2-1: Close media procedure
1. The MC application asks the MC MBMS user agent to stop the reception of media streams with the close media request.
2. The MC MBMS user agent stops the possible header decompression and FEC decoding.
3. The MC MBMS user agent notifies the MC application that the media has been closed.
Post-conditions:
– The closed media streams are no more available to the MC application.
– If no other media from this MBMS bearer are opened, the MC MBMS user agent can end the reception of this MBMS bearer.
5.12.3 Information flows
5.12.3.1 Close media request
Table 5.12.3.1-1 describes the information flow for the close media request.
Table 5.12.3.1-1: Close media request
|
Information element |
Status |
Description |
|
Media identifier |
M |
Identifier from the open media request |
5.12.3.2 Close media response
Table 5.12.3.2-1 describes the information flow for the close media response.
Table 5.12.3.2-1: Close media response
|
Information element |
Status |
Description |
|
Media identifier |
M |
Identifier from the open media request |
|
Response code |
M |
Indicates if the close media request was successful, otherwise an error code |
|
Message |
O |
Additional details. |
5.13 Retrieve capability
5.13.1 General
This subclause defines API function of retrieve capability.
The retrieve capability request is an API function call and retrieve capability response is returned with a list of capabilities.
The MC application uses this API function call to query what capabilities (e.g. FEC and ROHC) are supported by the MC MBMS user agent.
5.13.2 Procedures
Figure 5.13.2-1 illustrates the procedure of retrieve capability.
Pre-conditions:
– The MC application has registered towards the MC MBMS user agent.
Figure 5.13.2-1: Retrieve capability procedure
1. The MC application sends a request to query the capabilities of the MC MBMS user agent.
2. A retrieve capability response is returned with a list of available capabilities.
Post-conditions:
– The MC application can further decide whether or not to use these capabilities of the MC MBMS user agent for subsequent communication.
5.13.3 Information flows
5.13.3.1 Retrieve capability request
The retrieve capability request does not have input parameters.
5.13.3.2 Retrieve capability response
Table 5.13.3.2-1 describes the information flow for the retrieve capability response.
Table 5.13.3.2-1: Retrieve capability response
|
Information element |
Status |
Description |
|
FEC |
M |
FEC capability of the MC MBMS user agent |
|
ROHC |
M |
ROHC capability of the MC MBMS user agent |
Annex A (informative):
Change history
|
Change history |
|||||||
|
Date |
Meeting |
TDoc |
CR |
Rev |
Cat |
Subject/Comment |
New version |
|
2018-07 |
– |
– |
– |
– |
– |
Initial version |
0.0.0 |
|
2018-07 |
SA6#25 |
Implementation of the following p-CRs approved by SA6: S6-181118, S6-181149, S6-181150, S6-181283, S6-181284 |
0.1.0 |
||||
|
2018-10 |
SA6#26 |
Implementation of the following p-CRs approved by SA6: S6-181366, S6-181456, S6-181537, S6-181539, S6-181540, S6-181561, S6-181572 |
0.2.0 |
||||
|
2018-12 |
SA6#27 |
Implementation of the following p-CR approved by SA6: S6-181750 |
0.3.0 |
||||
|
2018-12 |
SA#82 |
SP-181144 |
Presentation for information at SA#82 |
1.0.0 |
|||
|
2019-01 |
SA6#28 |
Implementation of the following p-CRs approved by SA6: S6-190088, S6-190179, S6-190180, S6-190226, S6-190278 |
1.1.0 |
||||
|
2019-03 |
SA#83 |
SP-190060 |
Presentation for approval at SA#83 |
2.0.0 |
|||
|
2019-03 |
SA#83 |
SP-190060 |
MCC Editorial update for publication after TSG SA approval (SA#83) |
16.0.0 |
|||
|
2022-03 |
Promotion of spec to Rel-17 |
17.0.0 |
|||||