A.6 MBMS subchannel control signalling flows

24.3803GPPMission Critical Push To Talk (MCPTT) media plane controlProtocol specificationRelease 18TS

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

A.6.1 General

The following clauses describe examples of how an MBMS bearer is managed during group call.

The following signalling flows are provided:

– announcing MBMS subchannels (clause A.6.2);

– initiating a conversation and requesting floor, originating side (clause A.6.3); and

– releasing floor and ending a conversation (clause A.6.4).

A.6.2 Announcing MBMS subchannels

This clause contains an example message flow illustrating how the participating MCPTT function announces MBMS subchannels.

The pre-requisites to the flow are:

1. The MCPTT client participates in an ongoing group session. The group session can be either a chat group session or a pre-arranged group session.

2. There is no conversation ongoing, i.e. the floor is idle.

3. The group session has a small number of participants that depending on the availability of MBMS subchannels can use a MBMS subchannel or the unicast bearer when in an MBMS service area.

Figure A.6.2-1 shows the message flow.

Figure A.6.2-1: Announcing MBMS subchannels

The steps of the message flow are as follows:

1. A group session is ongoing. This can be a chat group or a pre-arranged group. The MCPTT session identity for this group is 12345@controller1.mcptt-op.net.

2. The participating MCPTT function pre-activates MBMS bearers. The trigger for doing this is implementation dependent but can be a result of received location reports from MCPTT clients served by the participating MCPTT function.

3-5. The participating MCPTT functions sends a SIP MESSAGE request to a selected number of MCPTT clients. This can happen exactly after a pre-activated MBMS bearer is created or when an MCPTT client registers or an MCPTT user affiliates to a group. The SIP MESSAGE request contains:

a. the "application/vnd.3gpp.mcptt-mbms-usage-info" MIME body with:

i. a reference to media line in the "application/sdp" MIME body where the general purpose MBMS subchannels are defined in the <SDP-ref> element; and

ii. one or more <announcement> elements where each announcement contains:

A. TMGI in the <TMGI> element identifying the announcement;

B. QCI in the <QCI> element;

C. if multiple carrier are supported, frequency in the <frequency> element;

D. a list of MBMS service areas in the <mbms-service-areas> element;

b. an "application/sdp" MIME body with:

i. one "a=audio …" media line containing the relevant media-line attributes. Where:

A. the IP address is set the unspecified address (0.0.0.0), if IPv4, or to a domain name within the ".invalid" DNS top-level domain; and

B the port number is set to "9".

i. one "a=application …" media line to be used as the general purpose MBMS subchannel; and

ii. optionally, one or more "a=application …" media lines to be used as the MBMS subchannel for floor control.

6-8. The MCPTT client acknowledges the SIP MESSAGE request by means of the SIP 200 (OK) response.

9. The MCPTT client moves into an MBMS service area where the announced MBMS bearer is available.

10-12. The MCPTT client sends a SIP MESSAGE request containing the "application/vnd.3gpp.mcptt-mbms-usage-info" MIME body containing:

a. the <mbms-listening-status> element set to the value "listening"; and

b. the <general-purpose> set to "true".

13-15. The participating MCPTT function acknowledges the SIP MESSAGE request by means of the SIP 200 (OK) response.

16. The participating MCPTT server receives a Floor Request message from one of the served MCPTT clients or a Floor Taken message from the controlling MCPTT function indicating that a conversation is started in the group session.

17. The participating MCPTT function decides to use one of the MBMS subchannels in the pre-activated MBMS bearer for the conversation in the group session.

18. The participating MCPTT function sends the Map Group to Bearer messages over the general purpose MBMS subchannel, the Map Group To Bearer message contains:

a. the TMGI in the TMGI field;

b. the MCPTT Group Identity field in the MCPTT Group ID field;

c. the MBMS Subchannel field containing:

i. the TMGI,

ii. a reference to which media line to be used for audio; and

ii. optionally, a reference to the media line specifying the "m=application …". If this reference is absent, floor control messages are sent over the MBMS subchannel used for audio.

19-21. The MCPTT client sends a SIP MESSAGE request containing the "application/vnd.3gpp.mcptt-mbms-usage-info" MIME body containing:

a. the <mbms-listening-status> element set to the value "listening";

b. the <mcptt-session-id> set to 12345@controller1.mcptt-op.net; and

c. the TMGI;

22. The MCPTT client starts listen to the MBMS subchannel(s) indicated in the Map Group To Bearer message. Note that RTP media packets can now be received over both the MBMS subchannel and the unicast channel (the same applies for floor control messages) and the MCPTT client needs to ignore duplicated RTP media packets and floor control messages.

23-25. The participating MCPTT function acknowledge with a 200 (OK) response to the SIP MESSAGE request.

26. When the MCPTT client receives the SIP 200 (OK) response the MCPTT client stops listen to the unicast bearer.

A.6.3 Initiating a conversation and requesting floor, originating side

This clause shows the signalling flow when an MCPTT client starts a conversation in an ongoing group session using a pre-activated MBMS bearer.

Figure A.6.3-1 shows the signalling flow.

NOTE: The arrows and boxes with dotted lines represent events sent over the MBMS bearer.

Figure A.6.3-1: Initiating a conversation and requesting floor

The MCPTT clients 1 to 4 participate in a group session. All MCPTT clients are served by the same participating MCPTT function. The MCPTT clients 1 to 3 are within an area where an MBMS bearer is available. The MCPTT client 4 is outside this area and can only use a unicast bearer.

A MBMS subchannel exists and associated with a general purpose media plane control channel which can be used to deliver MBMS subchannel control messages of any group in this MBMS service area.

The steps of the flow are as follows:

1. A group session is ongoing. At the moment none of the group members has the permission to send media.

2. The participating MCPTT function activates and announces an MBMS bearer as described in clause A.6.2. The pre-activated MBMS bearer is not yet associated with a particular group with participants served by this participating MCPTT function.

3. The user at the MCPTT client 1 presses the PTT button.

4-5. The floor participant 1 sends a Floor Request as specified in clause 6.2. The Floor Request is forwarded by the participating MCPTT function to the controlling MCPTT function.

6. When the participating MCPTT function receives the Floor Request message the participating MCPTT function determines that the previously activated and announced MBMS bearer can be used for this conversation and sends the Map Group to Bearer message over the general purpose MBMS subchannel to inform about the start of the conversation. The Map Group to Bearer message includes the TMGI, the MBMS subchannel for audio and floor control and the MCPTT group identifier in the activated MBMS bearer used for the conversation. The participating MCPTT function enters the ‘M: A conversation is active’ state. On receipt of the Map Group to Bearer message the MBMS interface in the MCPTT client 1, 2 and 3 associates the conversation with the TMGI, the MBMS subchannel for audio and floor control with the MCPTT group identifier in the Map Group to Bearer message.

7-8. On receipt of the Floor Request message, the floor control server function grants the floor participant 1 to send media by sending the Floor Granted message. The participating MCPTT function forwards the message to the floor participant 1 over the unicast bearer.

9-16. The floor control server sends the Floor Taken message towards all participants. The participating MCPTT functions sends one Floor Taken message over the MBMS subchannel associated with this group as declared in step 6 and discards the remaining Floor Taken messages with the exception of the Floor Taken messages towards participants not listening to the MBMS bearer, in this example, the floor participant 4.

NOTE: The participating MCPTT function uses the message-sequence-number field to determine if a Floor Taken message is already sent over the MBMS floor control bearer or not.

17. The floor control continues as described in clause A.5.2.

18. When the Floor Granted message is received in the floor participant 1, the floor participant 1 requests the MCPTT client to start encoding voice and send RTP media packets. The MCPTT client 1 starts encoding voice from the MCPTT user and sends RTP media packets over the unicast bearer towards the participating MCPTT function. The participating MCPTT function forwards the RTP media packets towards the controlling MCPTT function.

19-24. The controlling MCPTT function distributes the RTP media packets to all MCPTT clients. The participating MCPTT function sends one media stream over the MBMS subchannel associated with this group. If an MCPTT client is not listening to the MBMS bearer, in this example the MCPTT client 4, the participating MCPTT function forwards the RTP media packets to MCPTT client 1 over the unicast bearer.

As long as the conversation is active and the MBMS subchannel for this group is available any of the MCPTT users can request floor and the Floor Taken, Floor Idle and RTP packets are sent over the MBMS bearer.

A.6.4 Releasing floor and ending a conversation

This clause describes how the participant 1 releases the floor and how the participating MCPTT function decides to end the conversation.

Figure A.6.4-1 shows the signalling flow.

NOTE: The arrows and boxes with dotted lines represent events sent over the MBMS bearer.

Figure A.6.4-1: Releasing floor and ending a conversation

The steps of the flow are:

1. The MCPTT clients 1 to 4 participate in a group session. All MCPTT clients are served by the same participating MCPTT function. The MCPTT clients 1 to 3 are within an area where a MBMS subchannel is used for the conversation. The MCPTT client 4 is outside this area and can only use a unicast bearer. At the moment the participant at MCPTT client 1 has the floor. The conversation over the MBMS bearer started as described in clause A.6.4.

2. The MCPTT user at the MCPTT client 1 releases the PTT button. The MCPTT client 1 indicates to the floor participant 1 that the PTT button is released.

3-4. The floor participant 1 sends the Floor Release message over the unicast bearer. The participating MCPTT function forwards the message to the controlling MCPTT function.

5-13. The floor control server sends the Floor Idle message to all participants. The participating MCPTT function sends the first received Floor Idle message destined to an MCPTT client using the MBMS subchannel mentioned in step 1. Any other Floor Idle messages destined to an MCPTT client listening to the MBMS bearer are discarded. Any Floor Idle message destined to an MCPTT client outside the MBMS bearer coverage, in this case the MCPTT client 4, is forwarded over the unicast bearer to the floor participant.

14. The conversation ends. The conversation timer expires and the participating MCPTT server decides to end the conversation on this MBMS subchannel.

The conversation timer is a relative long timer and needed to avoid that inactive group sessions are unnecessarily occupying the MBMS subchannel. The MBMS subchannel can then be reused by other conversations in other group sessions.

15. The participating MCPTT function sends the Unmap Group to Bearer message over the MBMS subchannel. The MBMS interfaces in the MCPTT clients 1, 2 and 3 removes the association between the TMGI, the MBMS subchannel for audio and for floor control and the MCPTT group identity.

16. The participating MCPTT function continues to retransmit the Unmap Group to Bearer message until all MCPTT clients has moved to unicast. When all MCPTT client is listening to the unicast bearer, the participating MCPTT function enter the ‘M: No conversation is active’ state.

Annex B (informative):
Media encapsulation for end-to-end distribution using MBMS bearers

Table B-1 shows specific header field values of the media plane packet from the originating MCPTT client, starting with the codec payload to the MCPTT server, from where it is distributed in downlink via IP multicast over MBMS to the terminating MCPTT clients. Each line represents a logical or physical "Entity" which handles the incoming packet (or generated packet for the first line) and passes it to the next "Entity" via the interface "Reference Point" indicated in this line. Additional entries of the line represent specific parts of the packet when it is put to the "Reference Point" by the "Entity". The rightmost column is the inner part of the packet. The parameters indicated in a column indicate the value of specific information elements set by the "Entity" in the header encapsulating all the parts to the right of the column.

All shown IP addresses (as s= for the source address and as d= as the destination address) can be IPv4 or IPv6 and are considered routable as necessary and distinct from each other within the same domain if they have different designations: it is up to the implementations to handle local IP addresses, perform NAT or use additional tunnelling. UDP ports of different designations correspond to potentially different port numbers. The UDP port numbers are designated as capital letter within squared brackets.

The unicast IP address IP₁ and the sending UDP port [A] of the originator UE are as specified in the SDP during the most recent setup for the SIP session which precedes the MBMS distribution of MCPTT traffic. The multicast IP address IP_5m and the associated receiving UDP port [H] used for the distribution of media packets are provided to the terminating MCPTT clients via MCPTT signalling.

The SSRC is set to a value that uniquely identifies the originating MCPTT client during the (S)RTP session, in accordance to IETF RFC 3550 [3] and IETF RFC 3711 [8].

The inner IP header, inner UDP port and (S) RTP header may be compressed with ROHC as specified in clause 10.4.

Table B-1 Media encapsulation for end-to-end distribution using downlink MBMS bearers

System	Entity	Reference Points		Media encapsulation for transmission (unicast uplink / MBMS downlink)
				outer IP header	outer UDP port			inner IP header	inner UDP port	(S)RTP	Payload
Originating	Codec		<internal>								Codec payload
	MCPTT client (IP₁)		Unicast uplink (Uu-> S1-U -> S5 -> SGi)					s= IP₁ d= IP₂	[A] [B]	SSRC= unique id	(as above)
	MCPTT function (participating) (IP₂)		MCPTT-3					s= IP₂ d= IP₃	[C] [D]	(as above)	(as above)
Controlling	MCPTT function (controlling) (IP₃)		MCPTT-3					s= IP₃ d= IP₄	[E] [F]	(as above)	(as above)
Terminating	MCPTT function (participating) (IP₄)		MB2-U (NOTE 1)	s= IP₄ d= IP₆	[I] [J]			s= IP₄ d= IP_5m	[G] [H]	(as above)	(as above)
	BM-SC (IP₆)		SGimb	s= IP₆ d= IP₈	[K] [L]		SYNC header (NOTE 4)	(as above)	(as above)	(as above)	(as above)
	MBMS-GW (IP₈)		M1	s= IP₈ d=IP_7m	[M] [N]	GTP-U (NOTE 5)	(as above)	(as above)	(as above)	(as above)	(as above)
	eNB (IP_7m) (NOTE 2)		Uu downlink (MBMS)					(as above)	(as above)	(as above)	(as above)
	MCPTT client (IP_5m) (NOTE 3)		<internal>							(as above)	(as above)
	Codec										(as above)
NOTE 1: IP₆ and [J] are provided to the participating MCPTT function by the BM-SC over MB2-C reference point during the MBMS bearer activation procedure. NOTE 2: IP_7m is given to eNBs when they are informed that the activated MBMS Bearer will be transmitted by them. Then the eNBs join this IP multicast address. NOTE 3: The terminating MCPTT client starts listening for traffic on IP_5m and [H] when the group/media stream is mapped to this multicast IP address and port number respectively, via MCPTT signalling (Map Group To Bearer message). NOTE 4: Specified in 3GPP TS 25.446 [9]. NOTE 5: Specified in 3GPP TS 29.281 [10].

Annex C (Informative):
Floor control state machine transitions tables