7.7.2 Off-network transmission control

23.2813GPPFunctional architecture and information flows to support Mission Critical Video (MCVideo)Release 18Stage 2TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

7.7.2.1 General

The procedure is for providing transmission control to MCVideo UE in an off-network case. Transmission control is performed by using transmission control information flows between the transmission control participant and the transmission control arbitrator. The transmission control arbitrator is a member MCVideo UE of the MCVideo group where the transmission rules are applied.

Off-network transmission control is based on ProSe capabilities as described in clause 7.18.

Transmission control in off-network can be performed in two ways:

– Single arbitrator: transmission participants rely on a single participant designated as transmission arbitrator for the arbitraton of transmission requests.

– Self arbitration: each transmsission participant arbitrates its own transmission based on its view of the topology.

Both of the approaches, as appropriate for the deployment model, can be adopted for MCVideo group using a configurable parameter (as defined in Annex A.4).

In the single arbitrator approach, one MCVideo client assumes the responsibility for arbitration of transmission requests for all group members within range. All requests for transmission are directed to the arbitrator, and the arbitrator checks the configured limits on the simultaneous transmissions, and grants or denies the request. If an MCVideo client is out of range of the current arbitrator, the MCVideo client is allowed to transmit and also become a transmission arbitrator. If there is insufficient capacity to carry an extra transmission i.e. the configured limit for simultaneous transmissions is reached, the MCVideo client may request that an existing transmitting MCVideo client is pre-empted; the pre-emption request is sent to the transmission arbitrator.

In the self arbitration approach, each MCVideo client decides for itself whether there is sufficient capacity to carry the transmission. If it determines that there is insufficient capacity i.e. the configured limit for simultaneous transmissions is reached, and from its perspective another transmitting MCVideo client has a lower priority, the requesting MCVideo client may send an override request directly to this other transmitting MCVideo client, which will either accept the override request and give way, or deny the override request.

In both the single arbitrator approach and the self arbitration approach, if there is insufficient capacity to carry the communication i.e. the configured limit on the simultaneous transmissions is reached, the MCVideo client may report this to the MCVideo user. The MCVideo user may decide to transmit anyway, and instruct the MCVideo client to proceed with the transmission.

NOTE: The ProSe function within the MCVideo client could determine that there is insufficient capacity to carry an MCVideo call requested by the MCVideo client, however interactions between the MCVideo client and the ProSe function are outside the scope of the present document.

Further subclauses apply to one or both of the single arbitrator approach and the self arbitration approach. Applicability is explicitly indicated in each of the relevant subclauses.

7.7.2.2 Information flows for off-network transmission control

7.7.2.2.1 Transmission request

Table 7.7.2.2.1-1 describes the information flow for the transmission request sent by a transmission participant to request for the transmission permission. This information flows is sent in unicast or broadcast.

Table 7.7.2.2.1-1: Transmission request

Information element	Status	Description
MCVideo ID	M	The identity of the MCVideo user requesting the transmission permission
Transmission priority	M	Priority of the request
Source identifier	O	Identifies the communication, e.g. by identifying the media flow within a media multiplex, present only if media multiplexing

7.7.2.2.2 Transmission granted

Table 7.7.2.2.2-1 describes the information flow for the transmission granted sent by the transmission arbitrator, to indicate that a request for transmission is granted and media may be transmitted. This information flows is sent in unicast or broadcast.

Table 7.7.2.2.2-1: Transmission granted

Information element	Status	Description
MCVideo ID	M	Identity of the user whose client is acting as transmission arbitrator
MCVideo ID	M	Identity of the user that has been granted transmission permission
Duration	M	The time for which the granted party is allowed to transmit
Source identifier	O	Identifies the communication, e.g. by identifying the media flow within a media multiplex, present only if media multiplexing
MCVideo ID of subsequent arbitrator	O	Subsequent transmission arbitrator’s identity
Acknowledgement required	O	Indicates if acknowledgement from the transmission participant is required

7.7.2.2.3 Transmission release

Table 7.7.2.2.3-1 describes the information flow for transmission release sent by the transmission participant, to indicate that the media transmission is complete and transmission permission is released. This information flows is sent in unicast or broadcast.

Table 7.7.2.2.3-1: Transmission release

Information element	Status	Description
MCVideo ID	M	Identity of user releasing transmission
Source identifier	O	Identifies the communication, e.g. by identifying the media flow within a media multiplex, present only if media multiplexing

7.7.2.2.4 Transmission rejected

Table 7.7.2.2.4-1 describes the information flow for transmission rejected sent by the transmission arbitrator, to indicate that a request for the transmission is rejected. This information flows is sent in unicast or broadcast.

Table 7.7.2.2.4-1: Transmission rejected

Information element	Status	Description
MCVideo ID	M	Identity of the user whose client is acting as transmission arbitrator
MCVideo ID of rejected party	M	Identity of user whose transmission request has been rejected
Source identifier	O	Identifies the communication, e.g. by identifying the media flow within a media multiplex, present only if media multiplexing
Rejection cause	O	Indicates the cause for transmission rejection
Acknowledgement required	O	Indicates if acknowledgement from the transmission participant is required

7.7.2.2.5 Transmission revoked

Table 7.7.2.2.5-1 describes the information flow for transmission revoked sent by the transmission arbitrator, to indicate that the transmission permission, that was earlier granted, is revoked. This information flows is sent in unicast or broadcast.

Table 7.7.2.2.5-1: Transmission revoked

Information element	Status	Description
MCVideo ID	M	Identity of the user whose client is acting as transmission arbitrator
MCVideo ID	M	Identity of user whose transmission permission has been revoked
Source identifier	O	Identifies the communication, e.g. by identifying the media flow within a media multiplex, present only if media multiplexing
Acknowledgement required	O	Indicates if acknowledgement from the transmission participant is required

7.7.2.2.6 Transmission arbitration taken

Table 7.7.2.2.6-1 describes the information flow for transmission taken sent by the transmission participant, to indicate that the transmission participant has taken the responsibility of transmission arbitration. This information flows is sent in unicast or broadcast.

Table 7.7.2.2.6-1: Transmission arbitration taken

Information element	Status	Description
MCVideo ID	M	Identity of the MCVideo user taking responsibility of transmission arbitration
Source identifier	O	Identifies the communication, e.g. by identifying the media flow within a media multiplex, present only if media multiplexing
Permission to request the transmission	O	Indicates whether receiving parties are allowed to request the transmission or not (e.g. broadcast call).
Acknowledgement required	O	Indicates if acknowledgement from the transmission participant is required

7.7.2.2.7 Transmission arbitration release

Table 7.7.2.2.7-1 describes the information flow for transmission arbitration release sent by the transmission arbitrator, to indicate that the responsibility of transmission arbitration is released. This information flows is sent in unicast or broadcast.

Table 7.7.2.2.7-1: Transmission arbitration release

Information element	Status	Description
MCVideo ID	M	Identity of the user whose client is acting as transmission arbitrator
MCVideo ID	O	Identity of the user whose client is being delegated transmission arbitrator function
Source identifier	O	Identifies the communication, e.g. by identifying the media flow within a media multiplex, present only if media multiplexing

7.7.2.3 Initializing transmission control – single arbitrator approach

This subclause is applicable only in single arbitrator approach.

Figure 7.7.2.3-1 describes procedures for transmission participants when an MCVideo client initializes transmission control. The MCVideo client sends a transmission request to detect presence of a transmission arbitrator. If the MCVideo client does not receive a response to the transmission request, it sends a transmission arbitration taken message and becomes the transmission arbitrator. The MCVideo client may now transmit a video. This procedure applies when either there have been no recent MCVideo transmissions within the MCVideo group and therefore no arbitrator has been selected, or where there have been recent MCVideo transmissions which may still be ongoing, but the arbitrator cannot be reached, e.g. where MCVideo client that wants to transmit video has gone out of range of the arbitrator.

Pre-conditions:

1. An off-network group communication has been established.

2. MCVideo client 1 wishes to transmit video, and has determined that the pre-configured limit on the number of transmissions within the MCVideo group has not been reached.

Figure 7.7.2.3-1: Initializing transmission control, single arbitrator case

1. MCVideo client 1 sends a transmission request message to the MCVideo group.

2. MCVideo client 1 does not detect any response to the transmission request.

3a. MCVideo client 1 sends a transmission arbitration taken message to the MCVideo group.

3b. MCVideo user may be notified that the video can now be transmitted.

4. MCVideo client 1 transmits video to the MCVideo group.

7.7.2.3A Initializing transmission control – self arbitration approach

This subclause is applicable only in self arbitration approach.

Figure 7.7.2.3a-1 describes procedures for transmission participants when an MCVideo client initializes transmission control.

Pre-conditions:

1. An off-network group communication has been established.

2. MCVideo client 1 wishes to transmit video.

Figure 7.7.2.3a-1: Initializing transmission control, self arbitration case

1. The MCVideo client checks whether the pre-configured limit on the number of transmissions within the MCVideo group has been reached and informs the user. If the pre-configured limit on the number of transmissions within the MCVideo group has been reached, the MCVideo user may defer the transmission, or request an override as specified in subclause 7.7.2.8, or decide to continue with the transmission anyway.

NOTE: If the MCVideo user decides to transmit even if the pre-configured limit on the number of transmissions within the MCVideo group has been reached, the MCVideo user decides to accept any consequences of interference.

2. MCVideo client 1 sends a transmission arbitration taken message to the MCVideo group.

3. MCVideo client 1 transmits video to the MCVideo group.

7.7.2.4 Transmission permission granted

This subclause is applicable only in single arbitrator approach.

Figure 7.7.2.4-1 describes procedures for transmission participants when an MCVideo client requests for transmission permission.

The MCVideo client has detected presence of a transmission arbitrator e.g., by receiving responses to transmission arbitration control message. The MCVideo client sends a transmission request and waits for a response. The MCVideo client upon receiving a transmission granted message may transmit a video.

Pre-conditions:

1. An off-network group communication has been established.

2. At least one participant is currently transmitting video.

Figure 7.7.2.4-1: Requesting transmission permission

1. MCVideo client 2 sends a transmission request message to the MCVideo group.

2. MCVideo client 1, being the transmission arbitrator, checks if the configured limit of maximum simultaneous transmissions is already reached.

3. If the maximum simultaneous transmissions limit is not reached, MCVideo client 1 sends a transmission granted message to the MCVideo group. Transmission granted message indicates MCVideo client 2 as the intended recipient.

4. MCVideo user at MCVideo client 2 may be notified that the video can now be transmitted.

5. MCVideo client 2 transmits video to the MCVideo group.

7.7.2.5 Transmission permission rejected

This subclause is applicable only in single arbitrator approach.

Figure 7.7.2.5-1 describes procedures for transmission participants when an MCVideo client requests for transmission permission.

Pre-conditions:

1. An off-network group communication has been established.

2. At least one participant is currently transmitting video.

Figure 7.7.2.5-1: Requesting transmission permission

1. MCVideo client 2 sends a transmission request message to the MCVideo group.

2. MCVideo client 1, being the transmission arbitrator, checks if the configured limit of maximum simultaneous transmissions is already reached.

3. If the maximum simultaneous transmissions limit has reached, MCVideo client 1 sends a transmission rejected message to the MCVideo group. Transmission denied message indicates MCVideo client 2 as the intended recipient. The transmission rejected message may include a rejection cause which indicates that the configured maximum transmissions limit has been reached.

4. MCVideo user at MCVideo client 2 may be notified that the video cannot be transmitted right now.

Following step 4, the MCVideo user at MCVideo client 2 may decide to transmit anyway, for example if the user knows the topology of the off-network MCVideo group and locations of the MCVideo group members and needs to transmit video to other local MCVideo group members despite causing a potential conflict with one or more other existing MCVideo transmissions within the MCVideo group. In this case, the MCVideo client follows the procedure in subclause 7.7.2.3.

7.7.2.6 Releasing transmission permission

This subclause is applicable in both the single arbitrator and self arbitration approaches.

Figure 7.7.2.6-1 describes procedures for transmission participants when an MCVideo client releases transmission permission.

The MCVideo client has detected presence of a transmission arbitrator e.g., by receiving responses to transmission arbitration control message. The MCVideo client stops the video transmission and sends a transmission release request.

Pre-conditions:

1. An off-network group communication has been established.

2. MCVideo client has requested transmission permission and may have received transmission permission.

Figure 7.7.2.6-1: Requesting transmission permission

1. If transmitting, the MCVideo client 2 stops the transmission of the video.

2. MCVideo client 2 sends a transmission release message to the MCVideo group.

NOTE: The transmission arbitrator does not respond to a pending (not granted or denied) transmission request if a transmission release notification is received from the MCVideo client.

7.7.2.7 Transmission override

This subclause is applicable in the single arbitrator in the approach.

Figure 7.7.2.7-1 describes procedures for transmission participants when an MCVideo client authorized to override, requests for transmission permission.

Pre-conditions:

1. An off-network group communication has been established.

2. Maximum simultaneous transmissions limit has been reached.

Figure 7.7.2.7-1: Transmission override

1. MCVideo client 2 sends a transmission request message to the MCVideo group.

2. As the configured limit of maximum simultaneous transmissions is already reached, MCVideo client 1, being the transmission arbitrator, checks the override policy.

3. If MCVideo client 2 is authorized to override (based on e.g., transmission priority), MCVideo client 1 sends a transmission revoked message to the MCVideo group. Transmission revoked message indicates the MCVideo client from which the permission is revoked, as the intended recipient.

4. MCVideo client 3 stops transmission of video and MCVideo user at MCVideo client 3 may be notified that the transmission permission has been revoked.

5. MCVideo client 1 sends a transmission granted message to the MCVideo group. Transmission granted message indicates MCVideo client 2 as the intended recipient.

6. MCVideo user at MCVideo client 2 may be notified that the video can now be transmitted.

7. MCVideo client 2 transmits video to the MCVideo group.

7.7.2.8 Transmission override (revoke self)

This subclause is applicable in the single arbitrator approach.

Editor’s note: transmission override in the self arbitration approach is FFS.

Figure 7.7.2.8-1 describes procedures for transmission participants when an MCVideo client authorized to override, requests for transmission permission.

Pre-conditions:

1. An off-network group communication has been established.

2. Maximum simultaneous transmissions limit has been reached.

Figure 7.7.2.8-1: Transmission override

1. MCVideo client 2 sends a transmission request message to the MCVideo group.

2. As the configured limit of maximum simultaneous transmissions is already reached, MCVideo client 1, being a transmission arbitrator, checks the override policy.

3. If MCVideo client 2 is authorized to override (based on e.g., transmission priority), MCVideo client 1 may send a transmission revoked message to the MCVideo group. Transmission revoked message indicates the MCVideo client 1, the current arbitrator, whose permission is revoked.

4. MCVideo client 1 stops transmission of video and MCVideo user at MCVideo client 1 may be notified that the transmission permission has been revoked.

5. MCVideo client 1 sends a transmission granted message to the MCVideo group. The transmission granted message indicates MCVideo client 2 as the intended recipient and MCVideo client 2 as the subsequent transmission arbitrator.

6a. MCVideo client 2 sends a transmission arbitration taken message to the MCVideo group.

6b. MCVideo user at MCVideo client 2 may be notified that the video can now be transmitted.

NOTE: Step 6a and step 6b can occur in any order.

7. MCVideo client 1, upon receiving the transmission arbitration taken message releases transmission arbitration.

8. MCVideo client 2 transmits video to the MCVideo group.

7.7.2.9 Transmission arbitration release

7.7.2.9.1 Transmission arbitration release

This subclause is applicable only in single arbitrator approach.

Figure 7.7.2.9.1-1 describes procedures for an MCVideo client to release transmission arbitration. There is no other MCVideo client to which transmission arbitration can be delegated.

Pre-conditions:

1. An off-network group communication has been established.

2. Only MCVideo client 1 is transmitting a video.

Figure 7.7.2.9.1-1: Transmission arbitration release without delegation

1. MCVideo client 1 sends a transmission release message to the MCVideo group.

2. MCVideo client 1 stops transmission of the video.

7.7.2.9.2 Transmission arbitration release with delegation

This subclause is applicable only in single arbitrator approach.

Figure 7.7.2.9.2-1 describes procedures for an MCVideo client to release transmission arbitration. There are other MCVideo clients currently transmitting to which transmission arbitration can be delegated.

Pre-conditions:

1. An off-network group communication has been established.

2. At least one more MCVideo client is transmitting video other than the current transmission arbitrator.

Figure 7.7.2.9.2-1: Transmission arbitration release with delegation

1. MCVideo client 1 stops video transmission but does not release transmission arbitration.

2. MCVideo client 1 sends a transmission arbitration release message. The transmission arbitration release message indicates a MCVideo client which is currently transmitting video, MCVideo client 2, as the subsequent transmission arbitrator. The MCVideo client 1 waits for a confirmation before releasing transmission arbitration.

3. MCVideo client 1 detects no response from MCVideo client 2.

4. MCVideo client 1 sends another transmission arbitration release message. The transmission arbitration release message indicates another MCVideo client which is currently transmitting video, MCVideo client 3, as the subsequent transmission arbitrator. The MCVideo client 1 waits for a confirmation before releasing transmission arbitration.

5. MCVideo client 3 sends a transmission arbitration taken message to the MCVideo group.

6. MCVideo client 1, upon receiving the transmission arbitration taken message releases transmission arbitration.

7.7.2.10 Simultaneous transmission requests

This subclause is applicable in both the single arbitrator and self arbitration approaches.

Figure 7.7.2.10-1 describes procedures for transmission participants when simultaneous transmission requests are generated when more than one MCVideo client initializes transmission control.

Figure 7.7.2.10-1 shows the expected behaviour if simultaneous transmission requests are generated in the following scenarios:

– a single arbitrator approach is used but there is currently no arbitrator; or

– self arbitration is used.

Pre-conditions:

1. An off-network group communication has been established.

2. MCVideo client 1 has higher transmission priority than MCVideo client 2.

Figure 7.7.2.10-1: Simultaneous transmission requests

1a. The MCVideo client 1 sends the transmission request message to the MCVideo group.

1b. The MCVideo client 2 sends the transmission request message to the MCVideo group.

NOTE: Step 1a and 1b happen in parallel

2. On receiving a transmission request message, while waiting for a response to the sent transmission request message, the MCVideo client compares its transmission priority with the transmission priority indicated in the received transmission request message.

3. On determining that it has higher transmission priority than the received transmission request message(s), and no response to the sent transmission request message is received, the MCVideo client 1 sends the transmission arbitration taken message to the MCVideo group.

4. MCVideo user may be notified that the video can now be transmitted.