Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 23.281  Word version:  19.1.0

Top   Top   Up   Prev   Next
1…   5…   6…   7…   7.1.2.3…   7.1.2.3.1.2…   7.1.2.3.2…   7.1.2.4…   7.1.2.5.2…   7.1.3…   7.2…   7.2.2.3…   7.2.2.4…   7.2.3…   7.3…   7.4…   7.4.3…   7.5…   7.5.2.3…   7.6…   7.7…   7.7.1.3…   7.7.1.3.2A…   7.7.1.3.4…   7.7.1.3.6…   7.7.2…   7.7.2.7…   7.7.2.9…   7.8…   7.11…   7.17…   7.19…   7.19.2.8…   7.19.3…   7.19.3.1.4…   7.19.3.2…   7.19.3.2.3…   7.19.3.2.6…   A…

 

7.7.2  Off-network transmission controlp. 148

7.7.2.1  Generalp. 148

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.
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.
Up

7.7.2.2  Information flows for off-network transmission controlp. 149

7.7.2.2.1  Transmission requestp. 149
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.
Information Element Status Description
MCVideo IDMThe identity of the MCVideo user requesting the transmission permission
Transmission priorityMPriority of the request
Source identifierOIdentifies the communication, e.g. by identifying the media flow within a media multiplex, present only if media multiplexing
Up
7.7.2.2.2  Transmission grantedp. 149
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.
Information Element Status Description
MCVideo IDMIdentity of the user whose client is acting as transmission arbitrator
MCVideo IDMIdentity of the user that has been granted transmission permission
DurationMThe time for which the granted party is allowed to transmit
Source identifierOIdentifies the communication, e.g. by identifying the media flow within a media multiplex, present only if media multiplexing
MCVideo ID of subsequent arbitratorOSubsequent transmission arbitrator's identity
Acknowledgement requiredOIndicates if acknowledgement from the transmission participant is required
Up
7.7.2.2.3  Transmission releasep. 150
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.
Information Element Status Description
MCVideo IDMIdentity of user releasing transmission
Source identifierOIdentifies the communication, e.g. by identifying the media flow within a media multiplex, present only if media multiplexing
Up
7.7.2.2.4  Transmission rejectedp. 150
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.
Information Element Status Description
MCVideo IDMIdentity of the user whose client is acting as transmission arbitrator
MCVideo ID of rejected partyMIdentity of user whose transmission request has been rejected
Source identifierOIdentifies the communication, e.g. by identifying the media flow within a media multiplex, present only if media multiplexing
Rejection causeOIndicates the cause for transmission rejection
Acknowledgement requiredOIndicates if acknowledgement from the transmission participant is required
Up
7.7.2.2.5  Transmission revokedp. 150
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.
Information Element Status Description
MCVideo IDMIdentity of the user whose client is acting as transmission arbitrator
MCVideo IDMIdentity of user whose transmission permission has been revoked
Source identifierOIdentifies the communication, e.g. by identifying the media flow within a media multiplex, present only if media multiplexing
Acknowledgement requiredOIndicates if acknowledgement from the transmission participant is required
Up
7.7.2.2.6  Transmission arbitration takenp. 151
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.
Information Element Status Description
MCVideo IDMIdentity of the MCVideo user taking responsibility of transmission arbitration
Source identifierOIdentifies the communication, e.g. by identifying the media flow within a media multiplex, present only if media multiplexing
Permission to request the transmissionOIndicates whether receiving parties are allowed to request the transmission or not (e.g. broadcast call).
Acknowledgement requiredOIndicates if acknowledgement from the transmission participant is required
Up
7.7.2.2.7  Transmission arbitration releasep. 151
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.
Information Element Status Description
MCVideo IDMIdentity of the user whose client is acting as transmission arbitrator
MCVideo IDOIdentity of the user whose client is being delegated transmission arbitrator function
Source identifierOIdentifies the communication, e.g. by identifying the media flow within a media multiplex, present only if media multiplexing
Up

7.7.2.3  Initializing transmission control - single arbitrator approachp. 151

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.
Reproduction of 3GPP TS 23.281, Fig. 7.7.2.3-1: Initializing transmission control, single arbitrator case
Up
Step 1.
MCVideo client 1 sends a transmission request message to the MCVideo group.
Step 2.
MCVideo client 1 does not detect any response to the transmission request.
Step 3a.
MCVideo client 1 sends a transmission arbitration taken message to the MCVideo group.
Step 3b.
MCVideo user may be notified that the video can now be transmitted.
Step 4.
MCVideo client 1 transmits video to the MCVideo group.

7.7.2.3A  Initializing transmission control - self arbitration approachp. 152

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.
Reproduction of 3GPP TS 23.281, Fig. 7.7.2.3a-1: Initializing transmission control, self arbitration case
Up
Step 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.
Step 2.
MCVideo client 1 sends a transmission arbitration taken message to the MCVideo group.
Step 3.
MCVideo client 1 transmits video to the MCVideo group.
Up

7.7.2.4  Transmission permission grantedp. 153

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.
Reproduction of 3GPP TS 23.281, Fig. 7.7.2.4-1: Requesting transmission permission
Up
Step 1.
MCVideo client 2 sends a transmission request message to the MCVideo group.
Step 2.
MCVideo client 1, being the transmission arbitrator, checks if the configured limit of maximum simultaneous transmissions is already reached.
Step 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.
Step 4.
MCVideo user at MCVideo client 2 may be notified that the video can now be transmitted.
Step 5.
MCVideo client 2 transmits video to the MCVideo group.
Up

7.7.2.5  Transmission permission rejectedp. 154

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.
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.
Pre-conditions:
  1. An off-network group communication has been established.
  2. At least one participant is currently transmitting video.
Reproduction of 3GPP TS 23.281, Fig. 7.7.2.5-1: Requesting transmission permission
Up
Step 1.
MCVideo client 2 sends a transmission request message to the MCVideo group.
Step 2.
MCVideo client 1, being the transmission arbitrator, checks if the configured limit of maximum simultaneous transmissions is already reached.
Step 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.
Step 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.
Up

7.7.2.6  Releasing transmission permissionp. 155

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.
Reproduction of 3GPP TS 23.281, Fig. 7.7.2.6-1: Requesting transmission permission
Up
Step 1.
If transmitting, the MCVideo client 2 stops the transmission of the video.
Step 2.
MCVideo client 2 sends a transmission release message to the MCVideo group.

Up   Top   ToC