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:
Two functions determine the transmission mode on the radio interface:
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.
The eMBMS network is composed of different areas:
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.
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.
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.
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:
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.
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).
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:
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 Associated Delivery sub-function is invoked by the mobile, in connection with the transmission of data for the following cases:
The Key Management function is subdivided into the sub-functions Key Request and Key Distribution (Figure 8.3).
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 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).
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):
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.
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.
The MBSFN reference signal (RS) is only transmitted over the PMCH to perform the coherent demodulation.
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;
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.
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:
Figure 8.7 describes the mapping to resource elements in the case of 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:
The processing associated with the PMCH is summarized in Figure 8.8.
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.
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.
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.
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.
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.
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;
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 .
The PMCH uses a single spatial layer. The set of symbols is mapped in the set
When a single spatial layer is used, no precoding is performed. The set of symbols is mapped in the set
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.
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.
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.
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.
The counting procedure helps the MCE entity to choose the mode of transmission of the MTCH, either the broadcast mode or the unicast mode:
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 |
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.
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.
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.
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.
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.
3.145.125.51