8
LLC Service – Group Communications
8.1. Introduction
The group communication service (GCS) provides a fast and efficient mechanism for distributing the same content to multiple users in a controlled manner.
The eMBMS (evolved Multimedia Broadcast/Multicast Service) network completes the 4G mobile network architecture by introducing:
- – a transport architecture allowing the transmission, for the downstream direction, of IP packets in a multicast bearer;
- – a service architecture comprising two domains:
- - the security domain ensuring the mutual authentication and the key establishment;
- - the application domain ensuring the description and the structuring of the data.
Two functions determine the transmission mode on the radio interface:
- – the MBSFN (MBMS over Single-Frequency Network) function makes it possible to broadcast the same IP packet from several synchronized eNB entities in the physical multicast channel (PMCH), whose transmission characteristics are identical for all mobiles participating at the MBMS session and for a set of cells. The MBSFN function uses the broadcast transmission mode;
- – the SC-PTM (Single-Cell Point-To-Multipoint) function makes it possible to broadcast the same IP packet from a single eNB entity, in the physical downlink shared channel (PDSCH), whose transmission characteristics are specifically defined for each mobile participating at the MBMS session. The SC-PTM function uses the unicast transmission mode.
8.2. Transport architecture
8.2.1. Functional architecture
The eMBMS network provides a point to multipoint data transport service, for which unicast or multicast IP packets are transmitted from a source to multiple destinations (Figure 8.1).
This network operates in a broadcast mode, and IP packets of the MBMS session are propagated in a multicast bearer independently of mobile requests.
Figure 8.1. eMBMS network: transport architecture
The eMBMS network is composed of different areas:
- – the MBMS service area, which determines the set of eNB entities which must transmit the MBMS session;
- – the MBSFN synchronization area, which determines a set of synchronized eNB entities. The synchronization area is a subset of the service area;
- – the MBSFN area, which determines a set of coordinated eNB entities for the simultaneous transmission of an MBMS session. The MBSFN area is a subset of the synchronization area. An eNB entity can belong to several MBSFN areas (up to 8);
- – the MBSFN area reserved cells, which determine the eNB entities which are not involved in the transmission of MBSFN sessions.
8.2.1.1. BM-SC entity
The broadcast/multicast service center (BM-SC) is the entry point of the service stream in the MBMS network.
The BM-SC entity registers the mobile after the authentication procedure.
This entity announces the start of the MBMS session to the mobiles.
It initiates the procedures of starting, modifying and terminating the multicast bearer.
It attributes a temporary mobile group identity (TMGI) to the session.
It defines the quality of service (QoS) parameters associated with the MBMS session.
It transmits data using the SYNC protocol that ensures synchronization of their delivery through a set of eNB entities.
8.2.1.2. MBMS GW entity
The MBMS gateway (GW) can be implemented in specific equipment or be integrated with BM-SC or SGW entities.
The MBMS GW entity allocates an IP multicast address to the bearer for the delivery of data to eNB entities.
This entity is involved in the procedures of starting, modifying and terminating the multicast bearer.
8.2.1.3. MCE
The multi-cell/multicast coordination entity (MCE) determines the operating mode of the radio interface, MBSFN or SC-PTM.
The MCE may be implemented in specific equipment that controls a set of eNB entities or integrated with the eNB entity.
This entity is involved in the procedures of starting, modifying and terminating the multicast bearer.
It allocates the radio resource to the MBMS session and performs admission control.
It defines the modulation scheme and coding applied to the radio interface.
It performs pre-emption of resources according to the allocation and retention priority (ARP).
It initializes the counting procedure of mobiles involved in the MBMS session.
8.2.2. Protocol architecture
The SG-mb interface is the reference point between the BM-SC and MBMS GW entities for signaling via the DIAMETER protocol for starting, modifying or terminating the multicast bearer.
The SGi-mb interface is the reference point between the BM-SC and MBMS GW entities for IP packets corresponding to the MBMS session and SYNC protocol for the synchronization of the eNB entities.
The Sm interface is the reference point between the MBMS GW and MME entities for signaling via the GTPv2-C protocol for starting, modifying or terminating the multicast bearer.
The M3 interface is the reference point between the MME and MCE entities for signaling via the M3-AP protocol for starting, modifying or terminating the multicast bearer.
The M2 interface is the reference point between the MCE and eNB entities for signaling via the M2-AP protocol, for the following functions:
- – starting, modifying or terminating the multicast bearer;
- – counting of terminals subscribed to an MBMS session;
- – configuring the physical channel on the radio interface.
The M1 interface is the reference point between, on the one hand, the MBMS GW entity, and, on the other hand, all eNB entities involved in the distribution of the MBMS session for tunneling traffic, via the GTP-U protocol, corresponding to the IP packet of the MBMS session transmitted in the multicast bearer.
8.3. Service architecture
8.3.1. Functional architecture
An MBMS service can be accessed by an entity which proposes a full service to the end user and authorizes him to enable or disable the service. It is usually associated with a short description presented to the end user.
A unit service entity may contain a plurality of separate media objects or streams, which may be provided on various sessions. A session is associated with a unicast bearer or one or more multicast bearers and a set of parameters specifying how content should be received on the mobile side (Figure 8.2).
The authentication infrastructure can be used to enable the establishment of shared keys. Therefore, the infrastructure can provide the authentication service based on the generic bootstrapping architecture (GBA) using the authentication and key agreement (AKA) (Figure 8.2).
Figure 8.2. eMBMS network: service architecture
8.3.1.1. BSF entity
The bootstrapping server function (BSF) and the mobile entity must mutually authenticate using the AKA mechanism, and establish on the session keys that are then applied between the mobile and the BM-SC entity.
The home subscriber server (HSS) provides the BSF entity with the cryptographic data calculated from a random (RAND) and the key Ki:
- – the seal of the network (AUTN);
- – the seal of the mobile (RES);
- – the integrity key (IK) and the cipher key (CK). The IK and CK are concatenated to constitute the key Ks.
8.3.1.2. BM-SC entity
On mutual authentication, the mobile and the BM-SC entity can execute an application-specific protocol in which message authentication will be based on the session keys generated during the mutual authentication procedure which happens between the mobile and the BSF entity.
The BM-SC entity and the mobile can exchange service and content information on unicast or multicast media from the following functions.
The User Service Discovery/Announcement function provides service description information, which can be provided via the Session and Transmission function or via the Interactive Announcement function (Figure 8.3). This function includes the information needed to initialize the MBMS service.
The Session and Transmission function interacts with the MBMS-GW entity to activate or release the transmission resources (Figure 8.3).
The Session and Transmission function is further subdivided into the sub-functions MBMS Delivery and Associated Delivery.
The MBMS Delivery sub-function structures the data transmitted by the BM-SC entity to the mobile, in IP unicast or multicast packets:
- – the data is optionally protected (encryption and/or integrity check);
- – the data is optionally protected by a forward error correction (FEC).
The Associated Delivery sub-function is invoked by the mobile, in connection with the transmission of data for the following cases:
- – the file repair to complete the missing data;
- – the verification of the delivery of data and collection of statistics.
The Key Management function is subdivided into the sub-functions Key Request and Key Distribution (Figure 8.3).
Figure 8.3. Structure of the BM-SC entity
The Key Request sub-function retrieves a key derived from the key Ks from the BSF entity and deduces the following keys (Figure 8.4):
- – the MBMS Request Key (MRK) used for mutual authentication between the mobile and the BM-SC entity;
- – the MBMS User Key (MUK) transmitted to the sub-function Key Distribution.
The Key Distribution sub-function generates two keys, the MBMS service key (MSK) and the MBMS traffic key (MTK) (Figure 8.4).
The MTK is used to protect the data exchanged between the mobile and the BM-SC entity.
The MSK protects the transmission of the MTK to the mobile (Figure 8.4).
The MUK protects the transmission of the MSK to the mobile (Figure 8.4).
Figure 8.4. Setting up the keys
8.3.2. Protocol architecture
The Ub interface is the reference point between the mobile and the BSF entity, for mutual authentication, via the hypertext transfer protocol (HTTP).
The Ua interface is the reference point between the mobile and the BM-SC entity, for data relating to the following functions (Figure 8.5):
- – User Service Discovery/Announcement, via HTTP or FLUTE (File Delivery over Unidirectional Transport);
- – MBMS Delivery, via the real-time transport protocol (RTP) for voice and video (streaming) or via FLUTE for downloading files;
- – Associated Delivery, via HTTP or FLUTE;
- – Key Request, via HTTP;
- – Key Distribution, via MIKEY (Multimedia Internet KEYing).
The Zh interface is the reference point between the BSF and HSS entities, via DIAMETER, for the transfer of the cryptographic data.
The Zn interface is the reference point between the BSF and BM-SC entities, via DIAMETER, for the recovery of the key Ks_xx_NAF, derived from the key Ks.
Figure 8.5. Protocol architecture of the Ua interface
8.4. Radio interface
In the MBSFN mode, the PMCH transmits the multicast channel (MCH) that multiplexes the multicast control channel (MCCH) and multicast traffic channel (MTCH).
The MCCH is a unidirectional logical channel that is used to transmit RRC (Radio Resource Control) messages for control information associated with IP packets transmitted in the broadcast mode.
The MTCH is a unidirectional logical channel that is used to transmit the IP packets, relating to the MBMS application, to the mobile.
In the SC-PTM mode, the SC-MCCH and SC-MTCH are multiplexed in the downlink shared channel (DL-SCH) which is transmitted in the PDSCH.
8.4.1. MBSFN-RS
The MBSFN reference signal (RS) is only transmitted over the PMCH to perform the coherent demodulation.
8.4.1.1. Sequence generation
The MBSFN-RS is obtained from the following sequence:
where 
is expressed as the number of resource blocks in the frequency domain for the entire bandwidth of the radio channel;
- l is the number of the Orthogonal Frequency-Division Multiplexing (OFDM) symbol of the time slot;
- ns is the time slot number of the time frame;
- c(m) is a pseudo-random sequence that is 31 bits long.
At the start of every OFDM symbol, the initial cinit value of the pseudo-random sequence is obtained with the following formula:
where 
is the identity of the MBSFN.
8.4.1.2. Mapping to resource elements
Figure 8.6 describes the mapping to resource elements in the case of a step of 15 kHz between the sub-carriers.
The MBSFN-RS is mapped, in the time domain, to the resource elements located in the third OFDM symbol of an even slot, and in the first and fifth OFDM symbols of an odd slot.
The MBSFN-RS is mapped, in the frequency domain, to the following resource elements:
- – even-numbered resource elements for the third OFDM symbol of an even slot and for the fifth OFDM symbol of an odd slot;
- – odd-numbered resource elements for the first OFDM symbol of an odd slot.
Figure 8.6. Mapping of the MBSFN-RS: a step of 15 kHz between the sub-carriers
Figure 8.7 describes the mapping to resource elements in the case of a step of 7.5 kHz between the sub-carriers.
Figure 8.7. Mapping of the MBSFN-RS: a step of 7.5 kHz between the sub-carriers
The MBSFN-RS is mapped, in the time domain, to resource elements located in the second OFDM symbol of an even slot, and in the first and the third OFDM symbols of an odd slot.
The MBSFN-RS is mapped, in the frequency domain, to the following resource elements:
- – resource elements whose rank is a multiple of 4 for the second OFDM symbol of an even slot and for the third OFDM symbol of an odd slot;
- – resource elements whose rank has a two sub-carrier shift for the first OFDM symbol of an odd slot.
8.4.2. PMCH
The processing associated with the PMCH is summarized in Figure 8.8.
Figure 8.8. Processing associated with the PMCH
8.4.2.1. Error detection codes
The error detection code is obtained from a cyclic redundancy check (CRC).
The CRC is the remainder when the transport block a0, a1,a2, a3,…, aA–1 is divided by a generator polynomial, whose remainder p0, p1,p2, p3,…, pL–1 constitutes the bits of the CRC.
The concatenation of the transport block 
and of the
24 bits of the cyclic redundancy 
constitute the input structure 
of the segmentation.
8.4.2.2. Segmentation
The maximum size of the block processed by the error correction code is equal to 6144 bits.
If the size of the block 
is above this value, it must be segmented; every segment must have its own CRC, the length of which is equal to 24 bits in order to constitute the sequence 
where r and Kr are respectively the number of segment and the number of bits of the segment.
8.4.2.3. Error correction code
When segmentation is performed over the sequence 
, the error correction code is applied to each segment.
The error correction code is performed by a turbo code made up by a parallel concatenated convolutional code (PCCC) and by a quadratic permutation polynomial (QPP) interleaving (Figure 8.9).
The error correction code produces three sequences 
with i = 0, 1 and 2, and where Dr is the number of bits of the sequence.
The sequence 
is equal to sequence 
The input of the first encoder is the data structure 
The sequence 
is produced at the output of the first encoder.
The input of the second encoder is the output of the QPP interleaving 
. The sequence 
is produced at the output of the second encoder.
Figure 8.9. Turbo code
8.4.2.4. Rate matching
The three sequences issued from the turbo code are interleaved and then stored in a circular memory.
The bits of the circular memory are selected or punctured to constitute the output sequence 
where 
is the number of bits of the sequence.
8.4.2.5. Concatenation
All different sequences 
with 
where C is the number of segments, are concatenated to constitute the sequence 
, where G is the number of bits of the sequence.
8.4.2.6. Scrambling
The sequence of bits 
that designates the number of bits, is scrambled by the sequence 
.
This generates the sequence of bits 
mod 2.
The scrambling sequence is obtained with a 31-bit long pseudo-random sequence.
The initial value cinit of the scrambling sequence is calculated with the following formula:
where nRNTI is the radio network temporary identifier (RNTI), allocated to the mobile during the connection;
is the time slot number of the frame;
is the physical-layer cell identity (PCI).
8.4.2.7. Modulation
The sequence of the symbols d(0),…,d(Msymb −1), issued from the quadrature phase-shift keying (QPSK), the 16-quadrature amplitude modulation (16-QAM) or the 64-QAM, is obtained with the sequence of bits 
.
8.4.2.8. Mapping on the spatial layers
The PMCH uses a single spatial layer. The set of symbols 
is mapped in the set 
8.4.2.9. Precoding
When a single spatial layer is used, no precoding is performed. The set of symbols 
is mapped in the set 
8.4.2.10. Mapping on the resource elements
The PMCH occupies all physical resource blocks (PRBs) in the frequency domain, for the duration of a sub-frame.
The PMCH uses an extended cyclic prefix and a 15 kHz or 7.5 kHz step between the sub-carriers.
The control area allocated to the physical control format indicator channel (PCFICH), the physical HARQ indicator channel (PHICH) and the physical downlink control channel (PDCCH) is limited to two OFDM (Orthogonal Frequency-Division Multiplexing) symbols.
The PDCCH is solely used to supply the resources to the mobile for the uplink direction, over the physical uplink control channel (PUCCH).
The control area uses the cyclic prefix defined in the cell for the non-MBSFN sub-frames.
8.4.3. RRC messages
8.4.3.1. Configuration of frames and sub-frames
The system information block 2 (SIB2) introduces an information element MBSFN-SubframeConfig defining sub-frames assigned to the MBMS (Figure 8.10).
radioframeAllocationPeriod: this field contains the value of the frame allocation periodicity to MBMS.
radioframeAllocationOffset: this parameter contains the value of the offset of the frame allocated to MBMS:
SFN mod radioFrameAllocationPeriod = radioFrameAllocationOffset
subframeAllocation: this parameter defines the sub-frames (among the sub-frames 1, 2, 3, 6, 7, 8) assigned to the MBMS.
Figure 8.10. Allocation of frames and sub-frames to the MBMS
8.4.3.2. MCCH scheduling
The SIB13 provides information relating to the MCCH scheduling from the mcch-Config information element (Figure 8.11).
mcch-RepetitionPeriod: this field defines the repetition period of the MCCH, by number of frames.
mcch-Offset: this field sets the offset value of the frame where the MCCH is located:
SFN mod mcch-RepetitionPeriod = mcch-Offset
mcch-ModificationPeriod: this field defines the period during which there is no modification of the MCCH. The limits of the period without modification will satisfy the following relationship:
SFN mod mcch-ModificationPeriod = 0
The modification is signaled to the mobile by the downlink control information (DCI) in the 1C format, carried by the PDCCH.
sf-AllocInfo: this field defines the sub-frame where the MCCH is located.
signallingMCS: this field defines the modulation and coding scheme (MCS) applied to data relating to the MCCH.
Figure 8.11. MCCH scheduling
8.4.3.3. MTCH scheduling
Table 8.1 provides the transport of the RRC message that defines the scheduling of the MTCH.
Table 8.1. Transport of the RRC message
SRB |
RLC mode |
Logical channel |
Transport channel |
Physical channel |
Not available |
UM |
MCCH |
MCH |
PMCH |
MBSFNAreaConfiguration | ||||
The MBSFNAreaConfiguration message is transmitted by the eNB entity and contains the following information (Figure 8.12).
commonSF-Alloc: this field defines the frames and the sub-frames allocated to each MBSFN area.
commonSF-AllocPeriod: this field defines the periodicity of the allocation pattern of sub-frames common to all MTCHs of the MBSFN area.
PMCH-infolist: this field defines the multiplexing of several MTCHs in each PMCH allocated to an MBSFN area and the MCS applied to the PMCH.
Figure 8.12. MTCH scheduling
8.4.3.4. Counting
The counting procedure helps the MCE entity to choose the mode of transmission of the MTCH, either the broadcast mode or the unicast mode:
- – the unicast mode is most efficient if the number of mobiles subscribed in a program is low. The unicast mode allows the use of the MIMO (Multiple Input Multiple Output) transmission and optimization of the modulation and the coding scheme;
- – the broadcast mode is more efficient if the number of mobiles subscribed in a program is high. The broadcast mode only transmits a single logical channel regardless of the number of mobiles subscribed in the program.
Table 8.2 provides the characteristics of the message transport relating to counting.
The message MBMSCountingRequest is transmitted by the eNB entity and contains a list of programs.
The message MBMSCountingResponse is transmitted by each mobile subscribed to one of the programs.
Table 8.2. Message transport relating to counting
SRB |
RLC mode |
Logical channel |
Transport channel |
Physical channel |
Not available |
UM |
MCCH |
MCH |
PMCH |
MBMSCountingRequest | ||||
SRB1 |
AM |
DCCH |
UL-SCH |
PUSCH |
MBMSCountingResponse | ||||
8.5. Procedures
8.5.1. Mutual authentication
Before starting the communication between the mobile and the BM-SC entity, when the mobile does not know if the entity requires the use of shared keys, the mobile can contact the entity for further instructions.
The mutual authentication procedure is described in Figure 8.13.
Figure 8.13. Mutual authentication
1) The mobile starts the mutual authentication procedure with the BSF entity by sending an HTTP POST request containing its international mobile subscriber identity (IMSI).
2) The BSF entity requests from the HSS entity the cryptographic data (RAND, AUTN, RES, IK, CK) in the message DIAMETER MAR (Multimedia-Authentication-Request).
3) The HSS entity provides the BSF entity with the cryptographic data in the message DIAMETER MAA (Multimedia-Authentication-Answer).
On receipt of the message, the BSF entity generates the keys Ks and Ks_xx_NAF from the keys IK and CK.
4) The BSF entity transmits to the mobile the random (RAND) challenge and the network seal (AUTN) in the message HTTP 401 Unauthorized.
The mobile calculates the cryptographic data from its key Ki and the random (RAND) challenge and compares the calculated network seal with that received.
5) If the result is positive, the mobile sends a new message HTTP POST containing its seal (RES).
On receipt of the message, the BSF entity compares the seals (RES) received from the mobile and the HSS entity.
6) If the result is positive, the BSF entity responds to the mobile with the message HTTP 200 OK containing the lifetime of the key Ks and the bootstrapping transaction identifier (B-TID) built from the RAND challenge and the name of the BSF entity.
8.5.2. Mobile registration
Before the communication between the BM-SC entity and the mobile can begin, they must first agree on the use of shared keys obtained during mutual authentication.
The mobile registration procedure is described in Figure 8.14.
Figure 8.14. Mobile registration
1) The mobile transmits to the BM-SC entity the message HTTP POST containing the identifier B-TID and derives the key Ks to generate the MRK and MUK.
2) The BM-SC entity transmits to the BSF entity the message DIAMETER BIR (Bootstrapping-Info-Request) containing the B-TID.
3) On receipt of this message, the BSF entity derives, from the key Ks, the key Ks_xx_NAF it transmits to the BM-SC entity in the message DIAMETER BIA (Bootstrapping-Info-Answer).
On receipt of this message, the BM-SC entity derives the key Ks_xx_NAF to generate the MRK and MUK.
4), 5) and 6) The mobile and BM-SC entity mutually authenticate with the MRK.
8.5.3. Multicast bearer establishment
The establishment of the multicast bearer initiates the transmission of a new MBMS session, following the execution of the User Service Discovery/Announcement function.
The procedure for establishing the multicast bearer is described in Figure 8.15.
1) The procedure is initiated by the BM-SC entity by sending to the MBMS GW entity the message DIAMETER RAR (Re-Auth-Request) containing the characteristics (TMGI, QoS) of the bearer that must be created and the list of the MME entities.
2) The MBMS GW entity responds to the BM-SC entity with the message DIAMETER RAA (Re-Auth-Answer).
3) The MBMS GW entity initiates the construction of the multicast bearer by sending to the MME entity the message GTPv2-C MBMS SESSION START REQUEST containing the IP multicast address of the bearer to create.
4) The MME entity distributes the M3-AP MBMS SESSION START REQUEST message to the multi-cell/multicast coordination entities (MCE), containing the IP multicast address and the characteristics (TMGI, QoS, TEID) of the bearer to create.
5) Each MCE entity responds to the MME entity with the message M3-AP MBMS SESSION START RESPONSE.
6) The MME entity responds to the MBMS GW entity with the message GTPv2-C MBMS SESSION START RESPONSE.
7) The MCE entity sends to the relevant eNB entities the message M2-AP START SESSION REQUEST containing the IP multicast address and the characteristics (TMGI, QoS, TEID) of the bearer to create.
8) The MCE entity simultaneously sends to the relevant eNB entities the message M2-AP SCHEDULING INFORMATION that defines the characteristics of the MTCH.
9) and 10) The eNB entity responds to both messages received with the messages M2-AP SESSION START RESPONSE and M2-AP SCHEDULING INFORMATION RESPONSE.
The eNB entities send the message IGMP JOIN to the IP transport network in order to receive the multicast stream.
11) The eNB entity transmits the MTCH characteristics to the mobiles in the message RRC MBSFNAreaConfiguration.
Figure 8.15. Multicast bearer establishment