10 MBMS subchannel control procedure
24.3803GPPMission Critical Push To Talk (MCPTT) media plane controlProtocol specificationRelease 18TS
10.1 General
A participating MCPTT function sending floor control messages and RTP media packets over a MBMS bearer shall support the procedures in the following clauses.
The MBMS bearer can be used for conversations in group calls. Prior to using the MBMS bearer the participating MCPTT function needs to activate the MBMS bearer and announce the MBMS bearer as described in clause 4.1.3.
Floor control messages and RTP media packets received over the MBMS subchannel are used as input to the floor participant state machine in the same way as floor control messages and RTP media packets received over the unicast bearer.
Media plane security procedures for media and floor control messages sent over the MBMS subchannels are specified in clause 13.
The participating MCPTT function can apply Robust header compression (ROHC) (see RFC 5795 [20]) before pushing packets to the BM-SC with MB2-U, or can request the BM-SC to apply ROHC, as described in 3GPP TS 29.468 [6].
10.2 MBMS subchannel control procedure for the participating MCPTT function
10.2.1 General
If the participating MCPTT function supports the MBMS subchannel control procedure, the participating MCPTT function shall support the behaviour implied by the state machine specified in this clause. The specifications are on the reception of floor control messages from the controlling MCPTT function, sending of floor control messages and the allocation/deallocation of a MBMS subchannel for a conversation in a group session.
Figure 10.2.1-1 shows the participating MCPTT function MBMS subchannel control state diagram.
Figure 10.2.1-1: Participating MCPTT function MBMS subchannel control state diagram
If a floor control message or RTP media packet arrives in a state where there are no procedures specified in the clauses below, the participating MCPTT function shall discard the message.
10.2.2 State: ‘Start-stop’
10.2.2.1 General
In this state:
– no instance of the ‘Participating MCPTT function MBMS subchannel control state machine exists;
– a pre-activated MBMS bearer may exist;
– no conversation using a MBMS subchannel control is active but a group session exists where a conversation over the unicast channel may be ongoing; and
– the participating MCPTT function handles floor control messages and RTP media packets as for during normal operations described in clause 6.4.
10.2.2.2 Send Map Group To Bearer message (R: Floor Request or Floor Taken)
Upon receiving a Floor Request message or a Floor Taken message and when the participating MCPTT function decides that an MBMS subchannel shall be used for a conversation in an ongoing group session, the participating MCPTT function needs to determine if the MBMS bearer has sufficient capacity for the new conversation. If the new MBMS bearer has sufficient capacity the participating MCPTT function:
NOTE: The participating MCPTT function can take that decision when receiving the first Floor Request from a floor participant or when receiving a Floor Taken message destined to one of the floor participants served by the participating MCPTT client.
1. shall create an instance of the ‘Participating MCPTT function MBMS subchannel control’ state machine;
2. shall send a Map Group To Bearer message over the general purpose MBMS subchannel. The Map Group To Bearer message:
a. shall include TMGI;
b. shall include the identifier of the media stream; and
c. shall include the MCPTT Group identifier field;
3. shall start timer T15 (Conversation);
4. shall start timer T16 (Unmap Group To Bearer);
5. shall enter the ‘M: A conversation is active’ state;
6. if the Floor Request was received, shall perform actions as described in clause 6.4.2; and
7. if the Floor Taken was received, shall perform the actions described in clause 10.2.3.3.
If the MBMS bearer does not have sufficient capacity for the new conversation the participating MCPTT function:
1. may free capacity for the new conversation by transfering an existing conversation over an MBMS bearer to unicast bearers following the procedure in clause 10.2.3.12; or
2. may use the MBMS bearer for the signaling messages, while using unicast bearers for the media message.
10.2.3 State: ‘M: A conversation is active’
10.2.3.1 General
In this state a MBMS subchannel exists and can be used by a group call.
In this state a conversation is active and Floor Taken, Floor Idle and Floor Release Multi Talker messages and RTP media packets shall be sent over the MBMS subchannel.
In this state timer T15 (Conversation) and timer T16 (Map Group To Bearer re-transmit) are running.
In this state the timer T17 (Unmap Group To Bearer) may be running.
10.2.3.2 Send Floor Idle message (R: Floor Idle)
When a Floor Idle message destined to a floor participant listening to the MBMS subchannel is received, the participating MCPTT function:
1. shall for each received Floor Idle message, check if there is a stored message-sequence-number value associated with the conversation;
2. if a message-sequence-number value associated with the conversation is stored, compared the value of the stored message-sequence-number value with the value in the received Floor Idle message;
a. if the received message-sequence-number value is higher than the stored value:
i. shall replace the stored message-sequence-number value with the received message-sequence-number field;
ii. shall set the acknowledgment bit to ‘0’ as specified in clause 8.2.2, if not already set; and
iii. shall send the received Floor Idle message over the MBMS subchannel; and
b. if the received message-sequence-number value is lower or the same as the stored value, shall discard the received Floor Idle message;
3. if a message-sequence-number value associated with the conversation is not stored (i.e. this is the first floor control message received in the conversation):
a. shall store the received message-sequence-number value and associate the value with the conversation;
b. shall set the acknowledgment bit to ‘0’ as specified in clause 8.2.2, if not already set; and
c. shall send the received Floor Idle message over the MBMS subchannel;
4. if the received Floor Idle message indicates that a Floor Ack message is expected (i.e. the acknowledgment bit is set to ‘1’ as specified in clause 8.2.2), shall send a Floor Ack message towards the controlling MCPTT function. The Floor Ack message:
a. shall include the Message Type field set to ‘5’ (Floor Idle); and
b. shall include the Source field set to ‘1’ (participating MCPTT function is the source);
5. shall restart timer T15 (Conversation); and
6. shall remain in the ‘M: A conversation is active’ state.
10.2.3.3 Send Floor Taken message (R: Floor Taken)
When a Floor Taken message destined to a floor participant listening to the MBMS subchannel is received, the participating MCPTT function:
1. shall for each received Floor Taken message, check if there is a stored message-sequence-number value associated with the conversation;
2. if a message-sequence-number value associated with the conversation is stored, compare the value of the stored message-sequence-number value with the value in the received Floor Taken message;
a. if the received message-sequence-number value is higher than the stored value:
i. shall replace the stored message-sequence-number value with the received message-sequence-number field;
ii. shall set the acknowledgment bit to ‘0’ as specified in clause 8.2.2, if not already set; and
iii. shall send the received Floor Taken message over the MBMS subchannel; and
b. if the received message-sequence-number value is lower or the same as the stored value, shall discard the received Floor Taken message;
3. if a message-sequence-number value associated with the conversation is not stored (i.e. this is the first floor control message received in the conversation):
a. shall store the received message-sequence-number value and associate the value with the conversation;
b. shall set the acknowledgment bit to ‘0’ as specified in clause 8.2.2, if not already set; and
c. shall send the received Floor Taken message over the MBMS subchannel;
4. if the received Floor Taken message indicates that a Floor Ack message is expected (i.e. the acknowledgment bit is set to ‘1’ as specified in clause 8.2.2), shall send a Floor Ack message towards the controlling MCPTT function The Floor Ack message:
a. shall include the Message Type field set to ‘2’ (Floor Taken); and
b. shall include the Source field set to ‘1’ (participating MCPTT function is the source);
5. shall restart timer T15 (Conversation); and
6. shall remain in the ‘M: A conversation is active’ state.
10.2.3.3a Send Floor Release Multi Talker (R: Floor Release Multi Talker)
When a Floor Release Multi Talker message destined to a floor participant listening to the MBMS subchannel is received, the participating MCPTT function:
1. shall for each received Floor Release Multi Talker message, check if there is a stored message-sequence-number value associated with the conversation;
2. if a message-sequence-number value associated with the conversation is stored, compare the value of the stored message-sequence-number value with the value in the received Floor Release Multi Talker message;
a. if the received message-sequence-number value is higher than the stored value:
i. shall replace the stored message-sequence-number value with the received message-sequence-number field; and
ii. shall send the received Floor Release Multi Talker message over the MBMS subchannel; and
b. if the received message-sequence-number value is lower or the same as the stored value, shall discard the received Floor Release Multi Talker message;
3. if a message-sequence-number value associated with the conversation is not stored (i.e. this is the first floor control message received in the conversation):
a. shall store the received message-sequence-number value and associate the value with the conversation; and
b. shall send the received Floor Release Multi Talker message over the MBMS subchannel;
4. shall restart timer T15 (Conversation); and
5. shall remain in the ‘M: A conversation is active’ state.
10.2.3.4 Send any other floor control message (R: Any other message)
When a floor control message other than the Floor Idle and Floor Taken message is received from a floor participant or received from the floor control server, the participating MCPTT function:
1. shall forward the floor control message as specified in clause 6.4;
2. shall restart timer T15 (Conversation); and
3. shall remain in the ‘M: A conversation is active’ state.
10.2.3.5 Send RTP media packet over the MBMS subchannel (R: RTP packet)
When receiving a RTP media packet destined to one of the MCPTT client listening to the MBMS subchannel, the participating MCPTT function:
NOTE: An RTP media packet not destined to an MCPTT client listening to the MBMS subchannel is forwarded to the MCPTT client over the unicast bearer.
1. shall check if the media packet is already sent over the MBMS subchannel or not;
2. if the RTP media packet is already sent over the MBMS subchannel, shall discard the RTP media packet;
3. if the RTP media packet is not already sent over the MBMS sub channel, shall instruct the media distribution function to send the RTP media packet over the MBMS subchannel;
4. shall restart timer T15 (Conversation); and
5. shall remain in the ‘M: A conversation is active’ state.
10.2.3.6 Timer T15 (Conversation) expired
Upon expiry of timer T15 (Conversation), the participating MCPTT function shall:
1. if the application indicates that there is no longer an MCPTT client listening to the MBMS bearer,
a. shall release the instance of the ‘Participating MCPTT function MBMS subchannel management’ state machine used for the conversation; and
b. shall enter the ‘Start-stop’ state; and
2. if the application indicates that there are MCPTT client still listening to the MBMS bearer:
a. shall send the Unmap Group To Bearer message over the MBMS subchannel. The Unmap Group To Bearer message:
i. shall include the MCPTT Group ID field;
b. shall start timer T17 (Unmap Group To Bearer) and initialise counter C17 (Unmap Group To Bearer) to 1; and
c. shall remain in the ‘M: A conversation is active’ state.
10.2.3.7 Timer T16 (Map Group To Bearer) expired
Upon expiry of timer T16 (Map Group To Bearer), the participating MCPTT function:
1. shall send a Map Group To Bearer message over the general purpose MBMS subchannel. The Map Group To Bearer message:
a. shall include a TMGI field;
b. shall include a MBMS Subchannel field; and
c shall include the MCPTT Group identifier field;
2. shall restart timer T16 (Map Group To Bearer); and
3. shall remain in the ‘M: A conversation is active’ state.
10.2.3.8 Timer T17 (Unmap Group To Bearer) expired
Upon expiry of timer T17 (Unmap Group To Bearer) less than the upper limit of counter C17 (Unmap Group To Bearer) times, the participating MCPTT function:
1. shall send the Unmap Group To Bearer message over the MBMS subchannel. The Unmap Group To Bearer message:
a. shall include the MCPTT Group ID field; and
2. shall restart the timer T17 (Map Group To Bearer re-transmit) and increment counter C17 (Unmap Group To Bearer) by 1.
10.2.3.9 Timer T17 (Unmap Group To Bearer) expired Nth time
Upon expiry of timer T17 (Unmap Group To Bearer) by the upper limit of counter C17 (Unmap Group To Bearer), the participating MCPTT function:
1. shall send the Unmap Group To Bearer message over the MBMS subchannel. The Unmap Group To Bearer message:
a. shall include the MCPTT Group ID field; and
2. shall release the instance of the ‘Participating MCPTT function MBMS subchannel management’ state machine used for the conversation.
10.2.3.10 End conversation over the MBMS bearer (End conversation)
Upon receiving an indication from the application and signalling plane that all MCPTT clients now listens to the unicast channel, the participating MCPTT function:
1. shall release the instance of the ‘Participating MCPTT function MBMS subchannel management’ state machine used for the conversation.
10.2.3.11 Group call released
If the control and signalling plane indicates that the group call session is released, the participating MCPTT function:
1. shall send the Unmap Group To Bearer message over the MBMS subchannel. The Unmap Group To Bearer message:
a. shall include the MCPTT Group ID field;
2. shall stop timer T15 (Conversation), timer T16 (Map Group To Bearer) and timer T17 (Unmap Group To Bearer), if running; and
3. shall release the instance of the ‘Participating MCPTT function MBMS subchannel management’ state machine used for the conversation.
10.2.3.12 Move conversation to unicast
If the participating MCPTT server decides that an ongoing conversation over an MBMS bearer shall start using unicast bearers, the participating MCPTT function may send an Application Paging message over the MBMS subchannel associated with this conversation.
NOTE: The Application Paging message can be sent at the same time as the conversation is started using unicast bearers, this will improve the MCPTT access time since the Application Paging message in most cases will reach the client quicker than using normal paging procedures.
10.3 MBMS subchannel control procedure for the MCPTT client
10.3.1 General
An MCPTT client that supports receiving floor control messages and RTP media packets over an MBMS bearer shall support the procedures in the following clauses.
The procedures in the following clauses assume that an MBMS bearer is active and announced as described in clause 4.1.3.
NOTE: The floor control procedures described in clause 6.2 are not impacted due to the use of an MBMS bearer.
10.3.2 Conversation over a pre-activated MBMS bearer is started
When receiving a Map Group To Bearer message over the general purpose MBMS subchannel, the MBMS interface in the MCPTT client:
1. shall associate the TMGI in the TMGI field, the MBMS subchannel for audio and for floor control with the MCPTT group identity in the MCPTT Group ID field.
10.3.3 Receive floor control messages and RTP media packets over a MBMS subchannel
If the MBMS interface receives RTP media packets or floor control messages over the MBMS subchannel, the MBMS interface in the MCPTT client:
1. if there is an association between the TMGI, the MBMS subchannel for audio and for floor control to an ongoing conversation in a group session:
a. shall forward the received floor control messages to the floor participant in the conversation; and
b. if the received RTP media contains a different SSRC value than the SSRC value used by the MCPTT client, shall forward the received RTP packets to the media mixer in the conversation; and
2. if there is no such association:
a. shall ignore the received floor control message or received RTP media packet.
10.3.4 Conversation ended
When receiving the Unmap Group To Bearer message over a MBMS subchannel, the MBMS interface in the MCPTT client:
1. shall remove the association between the TMGI, the MBMS subchannel for audio and for floor control from the conversation in the group session identified by the MCPTT Group ID field, if such an association exists.
10.3.5 Receive Application Paging message
When receiving an Application Paging message over an MBMS subchannel, an MCPTT client in idle mode shall make a service request to enter RRC Connected mode.
10.3.6 Receive MBMS bearer announcement over MBMS bearer
When receiving an MBMS bearer announcement message over an MBMS subchannel, an MCPTT client shall acknowledge this message by sending an MBMS bearer listening status report as as specified in 3GPP TS 24.379 [2] clause 14.2.3.
10.4 Header compression
10.4.1 General
Packet headers can be compressed with ROHC (ref. RFC 5795 [20]) when delivered over MBMS to save network resources.
The participating MCPTT function can apply ROHC before pushing packets to the BM-SC over the MB2-U interface, or can request the BM-SC to apply ROHC, as described in 3GPP TS 29.468 [6].
Header compression is done after media plane encryption and header decompression is done before media plane decryption.
Header compression supported profiles for MCPTT are profile 0x0101 for RTP/UDP/IP compression, specified in RFC 5225 [22], and profile 0x0000 for sending uncompressed packets, specified in RFC 3075 [21]. MBMS subchannels encoded with profile 0x0101 use a distinct CID (ROHC context ID). One common CID may be used for all MBMS subchannels encoded with profile 0x0000.
Before establishing an MBMS bearer with header compression, the participating MCPTT function determines the value for the MAX_CID parameter (clause 5.1.2 in RFC 5795 [20]). If MAX_CID > 15 then the header compressor uses the large CID representation. Else, the header compressor uses the small CID representation.
Only the unidirectional mode of operation (clause 4.4.1 in IETF RFC 3095 [21]) is used for MCPTT over MBMS.
10.4.2 Participating MCPTT function procedure for ROHC
If the participating MCPTT function decides to compress headers for a given MBMS bearer, the participating MCPTT function:
1) shall declare the usage of ROHC within the MBMS bearer announcement, as specified in 3GPP TS 24.379 [2];
2) if the participating MCPTT function asks the BM-SC to apply ROHC (procedure 10.7.3.12.3 of 3GPP TS 23.280 [23]), the participating MCPTT function shall indicate the list of multicast IP and ports to be header compressed with profile 0x0101 when activating or modifying a MBMS bearer (see 3GPP TS 29.468 [6]); and
3) if the participating MCPTT function applies ROHC (procedure 10.7.3.12.2 of 3GPP TS 23.280 [23]), the participating MCPTT function shall compress the packet headers according to RFC 3095 [21] and RFC 5795 [20] for any packet to be delivered to the MBMS bearer, using the unidirectional mode and without ROHC segmentation.
10.4.3 MCPTT client procedure for ROHC
If usage of ROHC is declared within the MBMS bearer announcement, as specified in 3GPP TS 24.379 [2], the MCPTT client:
1) shall decompress the received ROHC packets according to RFC 3095 [21] and RFC 5795 [20]; and2) shall forward the decompressed packets to the media mixer.