ATIS 0200011-2014 Multicast Delivery of Content to Mobile End User Devices.pdf

《ATIS 0200011-2014 Multicast Delivery of Content to Mobile End User Devices.pdf》由会员分享，可在线阅读，更多相关《ATIS 0200011-2014 Multicast Delivery of Content to Mobile End User Devices.pdf（18页珍藏版）》请在麦多课文档分享上搜索。

1、 ATIS-0200011 Technical Report on Multicast Delivery of Content to Mobile End User Devices Alliance for Telecommunications Industry Solutions Approved February 2014 Abstract This document extends previous ATIS work on multicast-based content delivery methods to mobile End User devices. Three Use Cas

2、es describe potential situations where such devices can receive multicast-based broadcasts of specific live events/video content via the 3GPP Evolved Multimedia Broadcast Multicast System (eMBMS). Delivery processes, assumptions, Content Delivery Network interconnection implications, and supporting

3、requirements are also provided. ATIS-0200011 ii Foreword The Alliance for Telecommunication Industry Solutions (ATIS) serves the public through improved understanding between providers, customers, and manufacturers. The ATIS Cloud Services Forum (CSF) facilitates the adoption and advancement of clou

4、d services from a network and IT perspective. Drawing upon business use cases that leverage cloud services potential, the Forum addresses industry priorities and develops implementable solutions for this evolving marketplace. CSF is working to ensure that cloud services as offered by service provide

5、rs are quickly operationalized to facilitate the delivery of interoperable, secure, and managed services. The mandatory requirements are designated by the word shall and recommendations by the word should. Where both a mandatory requirement and a recommendation are specified for the same criterion,

6、the recommendation represents a goal currently identifiable as having distinct compatibility or performance advantages. The word may denotes a optional capability that could augment the standard. The standard is fully functional without the incorporation of this optional capability. Suggestions for

7、improvement of this document are welcome. They should be sent to the Alliance for Telecommunications Industry Solutions, CSF, 1200 G Street NW, Suite 500, Washington, DC 20005. At the time it approved this document, CSF, which is responsible for the development of this Standard, had the following me

8、mbers: O. Lima, CSF Chair (Ericsson) D. Druta, CSF Vice Chair (AT Architecture and Functional Description (Release 11), 2012.5RFC6064 IETF RFC 6064, SDP and RTSP Extensions Defined for 3GPP Packet-Switched Streaming Service and Multimedia Broadcast/Multicast Service, 2011.62.2 Informative References

9、 Inf-FCCPaper “Mobile Broadband: The Benefits of Additional Spectrum”, FCC Staff Technical Paper, 2010.73 Definitions For a list of common communications terms and definitions, please visit the ATIS Telecom Glossary, which is located at . There are no new definitions in this document. 4 Acronyms acc

10、ordingly, vendor deployments have focused exclusively on eMBMS in LTE networks. While not strictly multicast as defined for a wired network10, eMBMS very naturally extends delivery of multicast content. It is actually a simultaneous broadcast, on the same cellular frequency, of a stream of content f

11、rom multiple cellular antennas (actually eNodeBs) covering a geographic area defined by the SP: o The geographic area is defined by a pre-determined grouping of eNodeBs into a Single Frequency Network (SFN). o Each eNodeB in the SFN broadcasts the same content at the same time on the same frequency.

12、 o Each EU mobile device in the SFN simultaneously obtains signals from one or more eNodeBs in the SFN. If multiple signals are received, the EU device combines these signals constructively to realize a high quality signal. The wireless access SPs Operations, Administration, the remaining resources

13、are allocated to unicast sessions. 10The multicast tree ends at the edge of the wireless packet core and the radio portion of the network. 11Contiguous eNodeBs are preferred but not mandated for planning purposes. ATIS-0200011 9 Figure 5.2 depicts the reception of the broadcasted content in an SFN b

14、y a mobile EU device. The EU device receives signals from all eNodeBs in the SFN at different times due to propagation delays given that the device is at different distances from each eNodeB. Figure 5.2 - Broadcast of Content in an SFN The signals from all eNodeBs received within a pre-specified tim

15、e interval are constructively combined to achieve good quality. The same process holds true for unlimited mobile EU devices in the SFN, thus offering significant radio bandwidth savings when compared to unicast distribution of the same content in the SFN. 5.4 Content Request Signaling Impact of Mobi

16、lity Network Elements Although many functional entities are involved in the delivery of multicast content to mobile devices, an essential element is the BM-SC. This functional entity is responsible for MBMS service provisioning and delivery. It is the entry point for content to be sent to mobile dev

17、ices, authorizing and initiating the MBMS service (policy on whether content will be sent in multicast or unicast), as well as scheduling and delivering MBMS transmissions to the EU mobile device. It should also be noted that both signaling and media are going through the BM-SC.12The process for del

18、ivering content to a mobile device has some additional steps to those described for wired devices in A-0200010. There are three essential attributes that need to be delivered to the EU mobile device: Source, Group tuple. Broadcast Session Frequency. 12Refer to 3GPP-23.246 for more details on how mul

19、ticast content is delivered to mobile devices in a 3GPP based network. ATIS-0200011 10 Session Descriptor This is a relevant description of the content in question. Critically, it associates the S,G and Session Frequency with the content being delivered. There are different forms of this descriptor,

20、 some standardized RFC6064, others potentially proprietary. It could also be a textual description of the content (e.g., Super Bowl or BCS Championship Game) along with the mapping between the content and the associated S,G and Session Frequency attributes. These three attributes have to be delivere

21、d to the End User mobile device. The possibility exists for multiple broadcast sessions occurring simultaneously. The three attributes enable the mobile device to “tune in” to the broadcast requested by the End User. There is a strict 1:1 association between the Session Descriptor and the Session Fr

22、equency/S,G attribute pair. The process for initiating the delivery of these attributes is summarized briefly as follows: The Broadcast Multicast Service Center (BM-SC) prepares session details in a User Service Description (USD). At a minimum, these details must include the Source, Group informatio

23、n as specified in A-0200010. Other optional but relevant information such as backup delivery methods, broadcast content Session Descriptor (see above), and the frequency of the session broadcast can also be included in the USD. The USD is typically broadcasted via an eMBMS broadcast channel to mobil

24、e devices identified in the area (see section 6). EU mobile devices constantly monitor/listen for broadcast USDs while in an SFN. There are also other methods to load the USD onto the device, such as unicast or direct loading onto the EU device. If the Session Descriptor is not included on the USD,

25、then the EU device needs to obtain this descriptor via other means. One alternative is to “Request” information about the impending event via an advertised website and download the appropriate manifest file as described in A-200010. The manifest file should contain the Session Descriptor along with

26、other relevant information. The USD information is stored (cached) by the mobile device middleware. The middleware needs the mapping between the Session Descriptor and the Session Frequency/S,G attribute pair in order to correctly identify the desired broadcast signal (there could be multiple broadc

27、asts occurring simultaneously) when the session commences. The middleware processes the received information as follows: o If the USD includes the session descriptor, then the middleware obtains the mapping directly from the USD. o If the USD does not include the session descriptor, then the middlew

28、are obtains the mapping from the manifest file. When the EU device requests session delivery, the middleware decodes the broadcast signal via the Session Descriptor Session Frequency/S,G mapping if it is in progress or caches the request until the scheduled session start time. All sessions not reque

29、sted by the EU are ignored. 6 Content Delivery to Mobile Devices Use Cases Given that the focus is on CDN interconnection, as stated in A-0200010, the terms “Service Provider” and “CDN Provider” are synonymous. Simply put, a Service Provider acts in the role of a CDN Provider by delivering content f

30、rom a Content Provider to End Users, who may subscribe to other Service Providers/CDN Providers. It should also be noted that delivery of content via multicast to mobile devices may require separate licenses depending on the region or country. This is important, since unicast and multicast-based del

31、ivery methods are not necessarily handled the same way in terms of a countrys regulatory rules. The Use Cases are presented from the perspective of the targeted location of the delivered content: Localized Events - Concerts or sporting events generate a highly concentrated level of interest for the

32、event content over a small area around the event location. Regional/National Content Distribution - Other types of content require distribution to several thousands of End Users over a large possibly region spanning several countries. ATIS-0200011 11 6.1 Local Event- Live Streaming Increasingly, cer

33、tain types of live events (concerts, sporting events such as the Super Bowl) have the capacity to draw large crowds, many of whom wish to watch portions of the event on live TV on their mobile devices. Service Providers have become aware of this phenomenon and are engaging in plans to provide live m

34、ulticast/broadcasts (via eMBMS) of the event in question in areas in and around the event site. 6.1.1 Assumptions The assumptions for providing this service are as follows: The SP has developed a high degree of probability that large numbers of EUs with mobile devices will be present during the even

35、t and will plan on using those devices to “watch” live streaming of the event. The SP wireless network is enabled with LTE technology. The SP has sufficient confidence that the vast majority of EUs have mobile devices enabled with eMBMS capability such that broadcasts of the multicast service make s

36、ense. 6.1.2 Content Delivery Process The service delivery process is as follows: The SP pre-configures the number and size of individual Single Frequency Network (SFN) zones around the local event area that provide sufficient coverage to the eMBMS broadcast. Information such as the available locatio

37、ns of LTE network nodes (e.g., eNodeB) is utilized for this purpose. The SP ensures multicast capability is available for delivering the content from the source to the nodes in the pre-configured SFNs. Backup delivery capabilities are also pre-configured by the SP: o Pre-configuration of Automated M

38、ulticast Tunnels (AMT) over wired portions of the network as needed. o Unicast backup delivery process setup over the wired portion of the network in case the multicast process develops a glitch. o Unicast delivery over AMT tunnels over the radio portion of the network in case the broadcast process

39、develops a glitch. The SP “advertises” intent for delivery of live event coverage primarily to localized areas surrounding the event location. This advertisement includes information indicating “how” an EU with a mobile device can “request” the content delivery. As described above (section 5.4), the

40、 relevant session attributes are prepared for delivery to the EU mobile devices either solely in a USD or in a combination of the USD and manifest file. The SP broadcasts the USD to EU devices in the area. If appropriate, the relevant manifest files are assumed to be received by the devices via the

41、advertised websites. Middleware in the mobile devices store and process this information. The middleware also tracks all possible changes to event schedules as appropriate. The network then initiates a multicast/eMBMS broadcast at the specified time and the middleware decodes the broadcast stream fo

42、r viewing the content. Note that there may be EU devices that are not enabled for eMBMS present in the event and these EUs may also desire to receive the live content feed. For such devices, the manifest file needs to have information such that an AMT is setup at the time of content delivery between

43、 the EU device and an appropriate eNodeB. The content delivery then proceeds as a multicast stream from the source to the eNodeB and then through the established AMT tunnel over the radio portion of the network to the EU device. The presence of Wi-Fi service at the event would significantly boost th

44、e delivery efficiency. ATIS-0200011 12 The above description assumes that the EUs are all customers of the originating SP. However, given the likely ubiquitous nature of most wireless SPs, it is highly probable that there will be a significant number of EUs that subscribe to other SPs present at the

45、 local event. Currently, there is no way for EUs/subscribers of other SPs to “roam” into the SFN of the originating SP and receive the broadcast even if the EU devices are enabled with eMBMS capability. The main reason for this is that the broadcast frequency set by the originating SP is part of the

46、 unique set of frequencies allocated to that SP. Other SPs operate their wireless networks over uniquely different frequency ranges. In addition there is the possibility that each SP might have some differences in their protocols. The only possibility for EUs/subscribers of other SPs to receive the

47、live event content is if the other SP forms a CDN-I arrangement with the originating SP. This can be assumed to be an overall CDN-I arrangement as part of a federation of SPs joining together to facilitate delivery of content to and from each others networks. The process for enabling eMBMS broadcast

48、s in CDN-I federation arrangements (see section 6.1.3) is one more step that needs to supplement the established CDN-I requirements in A-0200010. 6.1.3 CDN Interconnection - Broadcast to Multiple SP End Users The CDN-I process for facilitating a multicast/eMBMS broadcast to EUs/subscribers of multip

49、le SPs is depicted in the figure below. Figure 6.1 - CDN-I Setup for Delivery to Multiple SP End Users ATIS-0200011 13 The CDN-I agreements/requirements established in A-0200010 need to include the eMBMS broadcast possibility to EUs with mobile devices. The Use Cases for delivering content via multicast across CDNs in A-0200010 applies over here. The specifics for setup and delivery of content by multiple CDN Providers are described as follows: Prior to the event time, two SPs/CDN Providers13d