MCPTT is a 3GPP-related technology that provides half-duplex communication between users of a MCPTT group. MCPTT is intended to provide secure and reliable communication for government and private actors such as police, fire fighters, and ambulance personnel for whom the availability of communication is Mission-Critical.
MCPTT enables multicast distribution of media and floor control messages to User Equipments (UEs) using a Multimedia Broadcast and Multicast Service (MBMS) bearer. It also enables direct unicast communication to each individual UE.
FIG. 1 is a block diagram illustrating an example context in which multicast distribution may occur. More specifically, FIG. 1 illustrates an MCPTT on-network architecture 100 implementing MBMS as presented in FIG. 5.2.7-1 of 3GPP TS 23.179 V13.5.0.
Referring to FIG. 1, MCPTT on-network architecture 100 comprises an MCPTT client located in a UE 105, an MCPTT server 110 shown bundled with a Group Communication Service Application Server (GCS AS), and an Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (E-UTRAN) 115 located between UE 105 and MCPTT server 110. E-UTRAN 115 provides communication between UE 105 and MCPTT server 110 via a unicast path 120 and an MBMS path 125. In general, communication may be conducted between the various features of architecture 100 via interfaces as illustrated in FIG. 1 and described in 3GPP TS 23.179.
FIG. 2A is a signal diagram illustrating a conventional method 200A for performing multicast distribution, and FIG. 2B is a flowchart illustrating method 200B, which is a simplified version of the method 200A. These methods could be performed e.g. in a context such as that illustrated in FIG. 1.
Referring to apparatus features in FIG. 2A, three UEs 205A-C comprise MCPTT clients, and they communicate with an MCPTT server 210 through unicast connections prior to activation of an MBMS bearer. Once the MBMS bearer is activated, the UEs receive multicast messages from MCPTT server 210.
MCPTT server 210 may transport media and floor control messages of several sessions via one MBMS bearer, and different UEs can participate in one or more of those sessions. For instance, in the example of FIG. 2, MCPTT server 210 uses a single MBMS bearer to transport media and floor control messages for a session X for an MCPTT group G1. MCPTT server 210 uses unicast bearers to transport media and floor control messages for a session Y for an MCPTT group G2, and for a session Z for MCPTT group G3. UE 205A participates in session X, UE 205B participates in session Y and UE 205C participates in session X and Z.
Referring to signaling features in FIG. 2A, in steps 0a, 0b, 0c and 0d, media and floor control messages of sessions X, Y and Z are distributed between UEs 205A-C and MCPTT server 210. As indicated above, UE 205A participates in session X for MCPTT group G1, UE B participates in session Y for MCPTT group G2 and UE C participates in session X for MCPTT group G1 and Z for MCPTT group G3.
In step 1, MCPTT server 210 activates an MBMS bearer. Thereafter, in steps 2a, 2b and 2c, MCPTT server 210 announces the MBMS bearer, using unicast Session Initiation Protocol (SIP) signaling, to the UEs using a SIP message request sent in accord with 3GPP TS 24.379 subclause 14.2.2.2. The SIP signaling includes media parameters and internet protocol (IP) address and port for the MBMS general purpose MBMS subchannel, media parameters for transport of media and floor control messages (excluding destination multicast IP addresses and ports) via MBMS bearer, and Temporary Mobile Group Identity (TMGI).
In steps 3a, 3b, 3c, when each UE detects that the MBMS bearer identified by the TMGI is available, each UE informs the MCPTT server 210, using unicast SIP signaling, about the availability of the MBMS bearer in the location of the UE by sending a SIP message request containing an MBMS bearer listening status set to “listening” in accord with 3GPP TS 24.379 subclause 14.3.3.2. Then, the UE starts receiving messages on the MBMS general purpose MBMS subchannel of the MBMS bearer.
In step 4, MCPTT server 210 decides to send media of session X via the activated MBMS bearer. Thereafter, in step 5, MCPTT server 210 sends a Map Group To Bearer message via MBMS bearer and indicates that session of MCPTT Group G1 will be sent via MBMS bearer using particular MBMS subchannels with indicated IP addresses and indicated ports for media and floor control messages.
In steps 6a and 6c, based on reception of the “Map Group To Bearer” message, UEs 205A and 205C start listening for media and floor control messages received via the MBMS bearer on the IP addresses and ports as indicated in the Map Group To Bearer message. UE 205B receives the “Map Group To Bearer” message too, but because it relates to MCPTT Group G1 where UE 205B does not participate, UE 205B ignores the Map Group To Bearer message.
In steps 7a-e, media and floor control messages of session X are distributed between UE 205A, UE 205C and MCPTT server 210. In uplink, the media and floor control messages still use unicast. In downlink, the media and floor control messages interesting to both UE A and UE C are sent via MBMS bearer on the IP addresses and ports as indicated in the Map Group To Bearer message in step 6a, 6c. In downlink, the floor control messages interesting to UE A only and UE C only are sent via unicast.
In steps 7x and 7y, media and floor control messages of sessions Y and Z are distributed between UE 205B, UE 205C and MCPTT server 210. They are unchanged (i.e. they still use unicast transport) as MCPTT Group G2 and MCPTT Group G3 were not indicated in the “Map Group To Bearer” message in steps 6a and 6c. 
Referring to FIG. 2B, method 200B comprises steps S205-S230, which are simplified or distilled versions of the steps in method 200A. In step S205, MCPTT server 210 activates an MBMS bearer. Thereafter, in step S210, MCPTT server 210 announces the MBMS bearer, using unicast Session Initiation Protocol (SIP) signaling, to UEs 205A-C using a SIP MESSAGE request sent in accord with 3GPP TS 24.379 subclause 14.2.2.2.
In step S215, each UE informs the MCPTT server, using unicast SIP signaling, about availability of the MBMS bearer in location of the UE. It does so by sending a SIP message request containing MBMS bearer listening status in accord with 3GPP TS 24.379 subclause 14.3.3.2.
In step S220, when a sufficient number of UEs report availability of the MBMS bearer at a given location, MCPTT server sends a “Map Group To Bearer” message via the MBMS bearer (steps 4 & 5 of FIG. 2A), starts sending media and (some types of) floor control messages using MBMS bearer (i.e. using multicast), and stops sending media and (some types of) floor control messages using unicast to the UEs which informed the MCPTT server about availability of the MBMS bearer. When a UE receives this message, the UE starts receiving and rendering the media and floor control messages via the MBMS bearer (i.e. using multicast).
In step S225, as each UE moves, it may move to a location where the MBMS bearer is no longer available. In such case, the UE informs the MCPTT server, using unicast SIP signaling, about non-availability of the MBMS bearer in location of the UE.
In step S230, when the amount of UEs reporting availability of the MBMS bearer at a given location gets low, MCPTT server sends an “Unmap Group To Bearer” message via the MBMS bearer, stops sending media and (some types of) floor control messages using MBMS bearer (i.e. using multicast), and starts sending media and floor control messages using unicast to all the UEs. The UEs starts receiving the media and floor control messages using unicast.
In the methods illustrated in FIGS. 2A and 2B, the “Map Group To Bearer” message and “Unmap Group To Bearer” message each contain MCPTT Group identifier (ID), which is supposed to not be disclosed to other unauthorized UEs in accord with TS 33.179. These constraints are described in further detail in 3GPP TS 24.379 subclause 14 and 3GPP TS 24.380 subclause 4.1.3.