Relative Time based MBSFN Content synchronization

Transcription

1 2013 Sixth International Workshop on Selected Topics in Mobile and Wireless Computing Relative Time based MBSFN Content synchronization JunHyuk Song, Ishwinder Singh, Rick Phung,HanSeokKim, JaeJin Lim, DaejoongKim Samsung Electronics junhyuk.song, hs365.kim, daejoong, Qualcomm Technologies Inc. Aritsu Inc. rick Abstract In LTE, enhanced MBMS (embms) allows the combining of MBMS transmission from tightly synchronized cells, in a technique known as Multimedia Broadcast Single Frequency Network (MBSFN). In MBSFN transmission, all enodebs in a given MBSFN area must have the radio frames transmitted with the same physical symbol timing. With use of the Extended Cyclic Prefix and the Synchronization Protocol(SYNC) running between the BM- SC (Broadcast/Multicast Service Center) and enb(enodeb), it is possible to synchronize content transmission from multiple enbs. The synchronization protocol layer in BM- SC shall set Time Stamp value that indicates the relative time value of the synchronization sequence. This paper investigates how enodeb can ensure synchronized MBSFN content transmission with the use of common relative time reference. Keywords: LTE, embms, SYNC. I. INTRODUCTION The introduction of the smart phones have made Internet access ubiquitous on mobile devices. Nowadays more users surf the web and watch multimedia content using mobile devices than ever before. According to a Cisco Visual Networking Index (VNI) Global Mobile Data Traffic Forecast for 2011 to 2016 [1], mobile video traffic would make up for more than 50% of all mobile data traffic. The mobile entertainment market is expected to grow exponentially in the next four years. However, due to the very nature of Unicast transmission namely, the inefficient bidirectional point to point transmission between each of the users and the network, most of the cellular operators have very limited streaming service options. This led to the development of the Broadcast/Multicast service over cellular network. In LTE, enhanced MBMS (embms) defines two broadcast transmission schemes: Single-cell transmission and Multicast Broadcast Single Frequency Network transmission (MBSFN). MBSFN allows combining of MBMS transmissions from tightly time-synchronized cells by using the same radio configuration in each of the cells with use of Extended Cyclic Prefix. In order to achieve MBSFN transmission in LTE, Multi-cell/Multicast Coordination Entity (MCE), as well as the time synchronization protocol running between enb and BM-SC (Broadcast Multicast Service Center) is introduced. The Synchronization protocol is an additional layer above the Transport protocol to synchronize the delivery of embms content from multiple enbs by reordering and detecting lost SYNC packets. The real challenge, however is that the physical symbols are required to be aligned among enbs located in the same MBSFN area. The MBSFN area as defined in TS [2], is an area in which cells transmit the same Multimedia content with same radio configuration controlled by a single MCE. Like other data traffic types in the IP network, the backhaul traffic in LTE is very likely to experience packet delay, jitter and packet loss. If any radio frame contains slightly time delayed data in the same MBSFN area, it acts as an interference to the UE. The physical symbol level synchronization for embms is left to the enb implementation, although the requirement is explicitly specified in [2]. Thus, in order to transmit identical radio frames simultaneously, the enbs must be configured with the same RLC/MAC/PHY configuration (assuming the same embms service), and have their radio frame timing synchronized. This paper considers that enb and BM-SC do not share any common Absolute time reference. Instead, we propose that they share a common Relative time reference to schedule MCH (Multicast Channel). This is in contrast with past work [3], which had only considered the use of absolute time reference. The main result of this paper connects MCCH (Multicast Control Channel) modification period to the temporal point where physical symbol level synchronization is taking place. We show that with the given MCCH modification period, and the newly proposed Reference SFN (R SFN) synchronization algorithm provides an efficient signaling method for temporal SFN (System Frame Number) alignment among multiple enbs. II. EMBMS OVERVIEW In this section, we briefly introduce embms architecture and its related functions [2]. As depicted in Fig 1, MBSFN requires new network entities to enable MBSFN transmission: BM-SC, MBMS Gateway, and MCE. BM-SC acts as a proxy /13/$ IEEE 285

2 Fig. 1. embms Centralized MCE architecture Fig. 2. Channel Structure content server. It also manages the embms subscriptions, service announcement, sessions control, SYNC protocol, MBMS security, point to point retransmission, and AL-FEC (Application Level Forward Error Correction). MBMS gateway is responsible for multicast IP address allocation and session management. The MBMS gateway receives MBMS content from BM-SC and then forwards MBMS service traffic to the enbs over IP multicast network. The MCE, acting as a MBMS scheduler, allocates radio resources, performs session admission control, and manages the MBMS services. Therefore, the scheduling of MBSFN transmission is performed through a MCE. When MCE receives a Session Start request from MME, it runs Session Admission Control function to determine radio resource availability. Only if there are enough radio resources available will the MCE allocate the required radio frames. Besides the function of the new entities, enbs will also need to support some embms related MAC and PHY layer features, including 15 khz sub-carrier spacing, Extended CP, MBSFN Reference signal, PMCH Physical channel, MCH Transport channel, MTCH/MCCH Logical channels, SIB2 and SIB 13 System information, PDCCH with M-RNTI (MBMS Radio Network Temporary Identifier), RLC-UM mode, SYNC protocol, and M2AP (M2 Application Part) Interface [8]. In embms system, a single enb is served by a single MCE at a time, although enb can receive MBMS IP multicast packets from multiple MBMS gateways in IP multicast Routing Tree. A. MBMS channel description The logical, transport, and physical channels associated with embms are depicted in Fig 2. LTE embms requires implementation of two new logical channels, Multicast Traffic Channel (MTCH) and Multicast Control Channel (MCCH). Both the MCCH and the MTCH logical channels are multiplexed to the Multicast Channel (MCH) transport channel. The enb performs MAC-level multiplexing for different MTCHs to be transmitted on a single MCH. Multiple embms services can therefore be transmitted using a single MCH (because up to 29 MTCHs can be multiplexed on one MCH instance), provided that they use the same MBSFN area. At the Physical Layer up to 15 MCH channels per MBSFN area can be time multiplexed to a Physical Multicast Channel (PMCH) within Common Scheduling Allocation Period (CSAP) interval. B. MBSFN transmission The delay spread is generated by different multipaths between the transmitter and the receiver when those paths have different delays. It causes Intersymbol Interference (ISI), which can cause an irreducible error floor. However, when the multiple paths of the signals with different delays are received by the UE, the receiver may be able to combine them as a single signal with different path delays. It is possible, if and only if, the signals are from tightly time synchronized cells, and are received within the CP (Cyclic Prefix) at the beginning of the symbol. In MBSFN operation, given the CP length of 16.7μs ensures the signals arrive within the CP, the UE Receiver treats these different signals as multi-path components of a Single Cell transmission. The use of the Extended CP ensures that the signals remain within the CP at the UE, and thus, reducing intercell interference by using additional symbols for Extended CP. The gain from MBSFN operation is significant especially at the cell edge, where the signals from edge cells causes ISI [4]. C. MBMS synchronization protocol SYNC protocol defined in 3GPP TS specification ensures the ordered delivery of the MBMS content from BM- SC to enb. If there is a delay in transmission of MBMS service PDUs from any enbs in a MBSFN Area, it will act as an interference. SYNC protocol defines a train of SYNC sequences in a SYNC period. Each SYNC PDU contains a time stamp that indicates the start time of the SYNC sequence. The SYNC period provides the time reference for the indication of the start time of each SYNC sequence. The value range of the SYNC period is units of 10ms which is 600 seconds. In Fig 3 example, it shows how SYNC sequences are repeated in one SYNC period boundary. BM-SC receives the first packet at 10:01:00 in Hours:minutes:seconds UTC time format. Fig. 3. SYNC Period III. MBSFN CONTENT SYNCHRONIZATION There are generally two methods of achieving physical symbol level synchronization among enbs: (1) Using synchronized backhaul protocol with Absolute time based timestamp. 286

3 (2) Using synchronized backhaul protocol with Relative time based time stamp. In this section, we describe how MB- SFN content synchronization can be achieved among multiple enbs. Fig. 4. Absolute timestamp A. Absolute time based MBSFN content synchronization Recently several methods have been proposed to use synchronized backhaul protocol to align MBSFN physical resource blocks in a MBSFN area. Those approaches set SYNC time stamp by shared Absolute reference time to assist the enb in determining the MBSFN transmission timing [3]. The BM-SC sets the time stamp of all SYNC packets based on absolute reference time with consideration of the propagation and processing delay from the BM-SC to the furthermost enb. Thus enb and BM-SC share the common absolute time reference with use of the GPS, SyncE [5], or IEEE 1588v2 [6]. Fig 4 illustrates a GPS Absolute Time based synchronization example, and it shows that the enb and BM-SC receive the same Time of the Day in seconds from the GPS signal. Thus every even seconds they are resynchronized. This approach can provide guaranteed common reference time between enb and the BM-SC, however the main drawback of this approach is the accessibility of GPS receiver in EPC (Evolved Packet Core). Typically BM-SC is an Application server located in the Core network and enb is part of the Radio Access Network (RAN). This Network Topology may require separate Time reference source at different Network entities. The absolute time reference requirement in core network may prove as a physical deployment limitation in some scenarios. Operators may require additional logistics to acquire and manage space for GPS antenna accessibility towards having absolute time reference for different network entities. Therefore, the absolute time reference based schemes may have deployment limitations in certain commercial embms deployment scenarios. B. Relative time based MBSFN content synchronization Unlike the Absolute reference time based MBSFN Content synchronization solution, the Relative time based MBSFN Content synchronization does not require the same Absolute time reference between enb and the BM-SC. The time stamp only indicates the relative time to start transmission from the reference time. Finding the common time reference and its actual transmission time among enbs is left to enb implementation and may be proprietary to the Infrastructurevendors. BM-SC should be able to estimate the propagation and the processing delay, and set the time stamp as a delay parameter. Upon reception of new chunk of data from DASH [7] encoder, BM-SC shall increase the time stamp of SYNC sequence by the length of the synchronization sequence. Each time stamp only denotes a single synchronization sequence length. If the Time stamp is set to 32, for example, it means SYNC PDUs should complete its transmission within 320 ms period from the reference time. The reference time to start MBSFN transmission among multiple enbs is set by the MCE, and it is then signaled to the enb. We give details of how to determine the Reference transmission time in Section IV. IV. REFERENCE SFN ESTIMATION In LTE, 10 ms system clock has numbers between 0 and 1023 and these numbers are called System Frame Number (SFN). The estimation of the exact SFN, when MBSFN transmission should take place from the relative time is quite challenging. It requires tight physical symbol level synchronization, coordination between enb and MCE, and interworking between RLC and MAC scheduler. In this paper, we define the Reference SFN, denoted as R SFN. Itisthe SFN where MCH scheduling begins for MBSFN transmission for each PMCH. R SFN is synchronized with reasonable margin at physical symbol level among enbs in the same MBSFN area. This section starts with a brief description of the MCCH modification procedure, the embms session start call procedure, the reference SFN algorithm, and a description of the MBSFN MAC scheduling. We do not address the RLC and MAC specific implementation details in this paper. A. MCCH modification Procedures When the network changes its embms session information, such as adding a new embms session, the MCCH information should be updated accordingly. System information normally changes only at specific radio frames whose System Frame Number is given by SFN mod N = 0,whereN is configurable and defines the period between two radio frames at which a change may occur, also known as the MCCH modification period. Prior to performing a change of the system information, the E-UTRAN notifies the UEs by means of a notification over the PDCCH. A UE interested in receiving MBMS service acquires the new MCCH information immediately from the start of the next modification period. These MCCH modification processes are illustrated in Fig 5. One interesting fact to note here is that MCCH modification period is required to be synchronized among all enbs in a given MBSFN area. Moreover MCE may be located in the Access network where the time synchronization is relatively easier compared to BM-SC located in EPC. The relative time based MBSFN Content synchronization sets the R SFN 287

4 Fig. 5. MCCH Modification Period to the beginning of the MCCH modification period. Upon receiving SYNC packets from the BM-SC, enb checks the included time stamp in order to align R SFN and wait for the next available MCH scheduling period for the transmission. The waiting time for each enb may be different depending on the backhaul delay. Thus 512 RF(5120 ms) modification period which is approximately 5 seconds gives enough time for enbs to synchronize while buffering embms packets from the BM-SC. B. Session Start Procedure When embms Service start is impending, BM-SC sends a Session Start Request message to MCE through MBMS- GW and MME (Fig 6). It is to indicate the start of the embms service and to provide the session parameters, such as QoS, estimated session duration, and estimated remaining time before the session start (MinTimeToDataTransfer). Then, MCE begins to allocate radio resources per the requested GBR (Guaranteed Bit Rate) by scheduling Common Subframe Allocation (CSA) patterns, MCH Subframe Allocation (MSA) patterns, Modulation & Coding Scheme (MCS) for both Traffic and Signaling channels. This radio configuration information is sent to enb over MBMS SCHEDULING INFORMATION and M2 MBMS SESSION START message [8]. These messages shall be sent to every enb belonging to the same MBSFN area in a time synchronized manner. Fig. 6. C. Reference SFN Algorithm Reference SFN Algorithm Input Output embms session start callflow MinTimeToDataTransfer: τ Delay offset: Θ n Current SFN SFN n MCCH modification period μ Reference SFN R SFN n 1. Compute Θ= (t1 t0)+(t3 t2) 2 2. Select Θ n = MAX{Θ 1,...Θ n } 3. Compute R SFN n = 4. Return (R SFN n ) SFNn +Θn+τ μ When the scheduled embms session is broadcasted, BM- SC must communicate its start time of the transmission in advance to the involved embms network entities. This is because it requires some time to allocate radio resources and synchronize considerably many enbs. This process is a time critical operation, and it must complete within a given MinTimeToDataTransfer time from BM-SC. (Note: Theoretically there could be up to M2 connections between enb and MCE, and only constraints are MCE s processing capacity, backhaul and SCTP (Stream Control Transmission Protocol) [9] connection processing delay. Therefore when MCE computes the Reference SFN in advance, it must take MinTimeToDataTransfer time into consideration. MinTimeTo- DataTransfer is the minimum time between the transmission of the MBMS SESSION START REQUEST to the MCE and the actual start of the data transfer. By reading the contents of M3 Session Start message from BM-SC through MME, MCE can obtain the MinTimeToDataTransfer. Assuming that every enb in the same Synchronization area [2] have a synchronized radio frame timing, MCE can keep track of the same SFN as enb within a small tolerance. To synchronize its R SFN with remotely located enb, MCE may compute the transmission delay offset. In general, it might be necessary to perform the sampling at large number of times to compute relative frequencies, and use these as estimates of the round trip time delay offset. Assume that t 0 is the time of the request packet transmission, t 1 is the time of the request packet reception, t 2 is the time of the response packet transmission and t 3 is the time of the response packet reception. Then (1) yields the approximated transmission Delay offset. Θ= (t 1 t 0 )+(t 3 t 2 ) (1) 2 By sampling physically furthermost located enb and finding its maximum, Θ n (2), we can determine the MBSFN area coverage. Note: It is possible to tune the MBSFN area coverage more or less aggressively and, therefore trade-off immediate video play with slightly time delayed video play for larger service coverage and vice versa. Θ n = MAX{Θ 1,...Θ n } (2) Let s denote MinTimeToDataTransfer as τ and MCCH Modification Period as μ. Assume that MCE keeps track of the SFN timing of enb with marginal delay offset Θ n,we can denote estimated SFN as SFN n +Θ n. R SFN n = SFN n +Θ n + τ (3) μ 288

5 In (3), SFN n +Θ n + τ denotes the minimum change of SFN caused by the session preparation delay. Its granularity is mostly determined by τ whichisdeterminedbythetraffic type. Now dividing by μ and ceiling it, we can set R SFN within the duration of MCCH modification period boundary which is synchronized among every enb in a MBSFN area. MCE shall send the computed R SFN n to enbs in the MCCH Update Time parameter of the M2 Session Start message. D. Synchronized MCH Scheduling Procedure By reading the contents of M2 Session start message, enb can easily compute next MCCH modification period and the MBSFN transmission SFN by computing (R SFN MCCH Modification P eriod + SY NC Time Stamp). Fig 7 is an example of MCH scheduling of MBMS during 640 ms with the given Reference SFN, When embms session begins, the traffic is encapsulated in SYNC PDUs and transmitted to enb from the BM-SC. The SYNC Frame handler in enb buffers the SYNC PDUs and reorders the packets according to packet number and SYNC Time stamp in SYNC header so that data associated with each sequence is transmitted consecutively. When the reordering of each SYNC sequence and checksum check are complete, SYNC PDUs are sent to RLC with SYNC time stamp. The RLC buffers SYNC PDUs until the right moment, when Reference SFN and MSP (MCH Scheduling Period) are elapsed. In other words, data transmission takes place when the expected transmission SFN comes up within the next available MSP. This is because the Physical Multicast Channel, PMCH can only be transmitted during the pattern of radio frames which satisfy (4), and MAC defines the allocated subframes for the PMCH scheduled during the MSP. SYNC sequence in that particular time frame, and continue to transmit from the next SYNC sequence. V. TEST RESULTS This section provides the Test results of Relative Time based MBSFN Content synchronization presented in the previous paragraphs. We tested with 15 PMCHs that were open sequentially between two enbs, which were connected to the same MCE and keep track of the RLC/MAC scheduling processes. The parameters used in our Lab tests are presented in Table I. TABLE I LAB TEST SETTINGS Parameter Value 3gpp spec. Release 9 Access Technology TDD Carrier Frequency 2.6 GHz Cellular Layout 6 cell sites System Bandwidth 20 MHz Extended Cyclic prefix Duration 16.7μs PDCCH Symbol Length 2 Data MCS 13 Signaling MCS 7 GBR 1.5 Mbps MCCH Modification Period 512 RF Common SF Alloc Period 64 RF MCH Scheduling Period 640 ms Allocated subframe number 3, 4, 8, 9 Video Encoding H.264 AVC Transport Coding DASH/FLUTE Video Title Big Buck Bunny Table II. shows the sample of RLC log that we captured during the Test. It shows that RLC kept track of MCH scheduling period window between lower boundary (highlighted in red) and upper boundary (highlighted in magenta), and flushed its buffer accordingly. Yellow highlighted 1536 is the Reference SFN, Green highlighted 64 is the SYNC PDU time stamp, and 1431 is the current system time. Fig. 7. Time synchronized MCH scheduling TABLE II RLC DATA LOG SAMPLE DROP[0][ ]-[ ] DROP[0][ ]-[ ] DROP[0][ ]-[ ] SFN mod RF AP = Offset (4) where, the Radio Frame Allocation Period (RFAP) can be a range of values 1, 2, 4, 8, 16, or 32, and offset can be a value between 0 through 7. It is important for RLC to keep track of SYNC Time stamp and Reference SFN alignment through the end of the session. This is because in case of a missing SYNC PDU in the SYNC sequence, RLC should mute that Figure 8, shows lower boundary and upper boundary of RLC SYNC windows per each MCH. Each boundary is exactly separated by MSP, in this case 640 ms. Thelower boundary is computed from Reference SFN and the SYNC PDU Time stamp and upper boundary is computed from lower boundary plus MSP duration. The initial Test results showed a fluctuating bit rate of Multimedia traffic that lead to a large segment of video traffic being dropped at the end 289

6 10ms System SFN Lower SYNC boundary Upper SYNC boundary RLC buffer flushing boundary ms time clock Fig. 8. Fig. 9. RLC buffer SYNC boundary embms video clip of MCH Scheduling Period. This was because of the bursty Traffic characteristics [10] of DASH encoded H.264 Media. To mitigate the effect of the fluctuating bit rate, we enforced BM-SC Link buffering for MPEG DASH data segments. With link buffering enabled, BM-SC transmitted SYNC sequences at a constant bit rate. After smoothening out the Traffic pattern from BM-SC, the Test results showed the RLC/MAC scheduling per MCH to be working as per the proposed Reference SFN algorithm. Approximately 1% Packet loss was observed due to RLC Fragmentation across MSP boundaries. Figure 9, illustrates the reception of a video clip using embms Service. We visually evaluated the overall quality of the video clip and in the start of each session, approximately 3 5 seconds of Video lag time was observed. This was due to 512 RF (5120 ms) MCCH modification period since the enbs must synchronize Reference SFN with MCCH modification period in the beginning of the session. Besides that, the overall quality of the embms Service was observed to be as good as Unicast Service, since the embms session was GBR traffic and there was no FLUTE [11] packet loss detected. VI. CONCLUSION The main improvement brought by the use of MBSFN in embms is the improved Spectral Efficiency by reducing ISI. This achievement is expected to act as a catalyst for wide deployment of embms. In this paper, we proposed Relative Reference Time based MBSFN Content synchronization, and we evaluated the shortcomings of the Absolute Reference Time approach. The Relative Reference Time based MBSFN Content Synchronization scheme does not require Absolute Time Reference source between the BM-SC and the enb and thus removes the requirement of maintaining separate Time alignment sources at the enb and the BM-SC. Moreover in a Commercial embms deployment, Radio Access Network (RAN) and BM-SC might be provided by Infrastructurevendors which may lead to possible Interoperability issues. The Relative Reference Time based approach will likely lead to a more cost effective and simpler deployment solution with a very minimal performance impact when compared to Absolute Time based MBSFN Content synchronization approach. The step that follows this work could be the MBMS operation on demand which is currently Rel.12 Work item [12]. This feature anticipates the user interest for the specific content, and allows switching back and forth between Unicast and Broadcast modes of Transmission. Additionally, we propose that shorter MCCH modification period should be considered. Our research found that use of the shorter MCCH modification period, such as 256 RF, 128 RF, and 64 RF, is possible and should be specified in the 3GPP specifications. With the current specifications, in the worst case scenario, RLC might buffer SYNC packets for the complete 512 RF MCCH Modification period. The shorter MCCH modification period would reduce the initial video lag time, in case of on demand embms service. REFERENCES [1] Cisco Visual Networking Index (VNI) Global Mobile Data Traffic Forecast for 2011 to 2016, Feb ns705/ns827/white paper c pdf [2] 3GPP TS V Technical Specification Group Services and System Aspects; Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-URTAN); Overall description; Dec [3] H Wang, H Vandervelde, S Kim, LTE MBMS SYNC Protocol for support Synchronization of Content, IEEE Preceeding of ICCTA2009 [4] 3GPP R , Spectral efficiency comparison of possible MBMS transmission schemes: Additional Results, 2007 [5] ITU-T G.8262 : Timing characteristics of a synchronous Ethernet equipment slave clock. International Telecommunication Union. July [6] IEEE 1588 Systems. National Institute of Standards and Technology (NIST) [7] 3GPP TS V Transparent end-to-end Packet-switched Streaming Service (PSS); Progressive Download and Dynamic Adaptive Streaming over HTTP (3GP-DASH) Dec 2011 [8] 3GPP TS V Technical Specification Group Services and System Aspects; M2 Application Protocol (M2AP) Dec 2011 [9] IETF, RFC 4960 Stream Control Transmission Protocol Sept 2007 [10] G. Van der Auwera, P.T. David, and M. Reisslein, Traffic Characteristics of H.264/AVC Variable Bit Rate Video, Arizona State University, Technical Report, March [11] IETF, RFC 6726 File Delivery over Unidirectional Transport Sept 2012 [12] 3GPP MBMS operation on demand work item description htm 290