WO2016162732A1

WO2016162732A1 - Method and apparatus for providing current manifest information for broadcasted content delivered via a wireless communication network

Info

Publication number: WO2016162732A1
Application number: PCT/IB2015/052603
Authority: WO
Inventors: Soyeb DALAL; Antonio Ortells HERVAS
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2015-04-09
Filing date: 2015-04-09
Publication date: 2016-10-13

Abstract

According to one or more aspects of the teachings herein, a method and apparatus provide current manifest information for broadcasted content delivered via a wireless communication network, based on the advantageous approach of obtaining initial manifest information for a scheduled broadcast and then obtaining and forwarding updated manifest information in response to the start of the broadcast. For example, a node in the subject wireless communication network is configured to poll or otherwise query a live encoder or other node for updated manifest information, where the live encoder or other node has access to the most recent manifest information available for the broadcast.

Description

METHOD AND APPARATUS FOR PROVIDING CURRENT MANIFEST INFORMATION FOR BROADCASTED CONTENT DELIVERED VIA A WIRELESS

COMMUNICATION NETWORK TECHNICAL FIELD

The present invention generally relates to wireless communication networks, and particularly relates to providing current manifest information for broadcasted content delivered via wireless communication networks.

BACKGROUND

Access to video content, including broadcasted multimedia content, represents an important feature in contemporary communication networks, and the demand for high-quality broadcast content is only expected to increase. Those demands impose significant challenges on network operators, particularly in the context of wireless communication networks, which have lossy radio links of varying quality and limited spectrum resources in which to operate.

The Evolved Multimedia Broadcast Multicast Service, or eMBMS for Long Term Evolution, LTE, networks, is a 3GPP standard that enables mobile networks to offer broadcast/multicast services. Using eMBMS, a provider can multicast a video stream or a file to specific users using LTE networks. Unlike traditional approaches where a user connects to the Internet to fetch a video stream or download an online sports game for example, LTE Broadcast technologies allow a network operator to send the stream over the air for live viewing by potentially large numbers of network subscribers. This approach reduces bandwidth consumption in the network and increases the satisfaction of end users by providing readily accessed, high definition streams for popular events.

MPEG DASH is one of the technologies underlying eMBMS, where "DASH" denotes Dynamic Adaptive Streaming over HTTP, "MPEG" denotes the Motion Picture Experts Group, and "HTTP" denotes the Hyper Text Transfer Protocol. One may refer to the International Standards Organization standards document, ISO/IEC 23009-1, for details regarding DASH. Broadly, however, DASH is a HTTP-based adaptive streaming protocol that relies on a combination of encoded media files and corresponding "manifest files" that identify the various streams and their attributes, including the corresponding Uniform Resource Locators, URLs. The DASH standard refers to the encoded audio/video, AV, streams as the "Media Presentation" and refers to the manifest file as the "Media Presentation File." The Media Presentation Description enables compatible subscriber devices, e.g., smart phones, computers, tablets, etc., to identify and start playback of initial content segments, and to switch between different ones of the available representations. For example, there may be streams of differing resolution or quality and the media player embedded in a given subscriber device may need to fall back to a lower resolution in response to deteriorating radio conditions. Of course, there may be different streams for different languages, etc., all of which is described in the Media Presentation Description.

Media Presentation Descriptions and manifest files in general can be understood as a form of metadata that describes broadcast content in a manner that enables proper play-out of the content by a media player. For an upcoming live broadcast, such data describes everything from the start time, to the duration, to the above-described constituent streams and their URLs. It is known in wireless communication networks to use "Service Announcements" to provide such information in advance, so that subscriber devices will know how to receive the upcoming broadcast.

The manifest information for an upcoming broadcast may change after its initial distribution in a given wireless communication network. However, because the "live encoders" that are responsible for providing the broadcast feed to the network generally are external systems that are not part of the operator' s wireless communication network, there is no ready mechanism for ensuring that network subscribers receive or are even aware of the updated manifest information. A subscriber device in possession of outdated manifest information may not be able to tune into and play-out a broadcast, or at least may not be able to optimize the play- out experience for the device user.

SUMMARY

According to one or more aspects of the teachings herein, a method and apparatus provide current manifest information for broadcasted content delivered via a wireless communication network, based on the advantageous approach of obtaining initial manifest information for a scheduled broadcast and then obtaining and forwarding updated manifest information in response to the start of the broadcast. For example, a node in the subject wireless communication network is configured to poll or otherwise query a live encoder or other node for updated manifest information, where the live encoder or other node has access to the most recent manifest information available for the broadcast. In an example embodiment, a method at a network node of a wireless communication network provides current manifest information for broadcasted content delivered via the wireless communication network. In relevant part, the example method includes obtaining an initial manifest file for a scheduled broadcast, and forwarding the initial manifest file for the broadcast, for distribution to one or more subscriber devices associated with the wireless communication network. The method further includes, responsive to a start of the broadcast, checking for manifest updates for the broadcast, and forwarding an updated manifest file for the broadcast, in dependence on said step of checking for manifest updates. For example, the forwarding may be conditioned on the number and/or types of changes in the manifest information.

In another embodiment, a network node is configured for providing current manifest information for broadcasted content delivered via a wireless communication network. The example network node includes one or more communication interfaces, and processing circuitry operatively associated with the one or more communication interfaces. The processing circuitry is configured to obtain an initial manifest file for a scheduled broadcast, and forward the initial manifest file for the broadcast, for distribution to one or more subscriber devices associated with the wireless communication network. Further, the processing circuitry is configured to, responsive to a start of the broadcast, check for manifest updates for the broadcast, and forward an updated manifest file for the broadcast, in dependence on the operation of checking for manifest updates. For example, the processing circuitry may condition its forwarding of any updated manifest files based on the number and/or types of changes in the underlying manifest information.

In yet another embodiment, a network node is configured for providing current manifest information for broadcasted content delivered via a wireless communication network. The example network node includes an obtaining module for obtaining an initial manifest file for a scheduled broadcast, and a forwarding module for forwarding the initial manifest file for the broadcast, for distribution to one or more subscriber devices associated with the wireless communication network. Further, the network node includes a checking module for checking for manifest updates for the broadcast, e.g., in response to a start of the broadcast. The checking module forwards, via the forwarding module, an updated manifest file for the broadcast, in dependence on the operation of checking for manifest updates. For example, the forwarding of the updated manifest file may be conditioned on the number and/or types of changes in the underlying manifest information. Of course, the present invention is not limited to the above features and advantages. Indeed, those skilled in the art will recognize additional features and advantages upon reading the following detailed description, and upon viewing the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

Fig. 1 is a block diagram of one embodiment of a wireless communication network, which includes an embodiment of a node configured for facilitating the delivery of broadcasted content from the network.

Fig. 2 is a logic flow diagram of one embodiment of a method of facilitating the delivery of broadcasted content from a wireless communication network.

Fig. 3 is a block diagram of another embodiment of a node configured for facilitating the delivery of broadcasted content from a wireless communication network.

Fig. 4 is a logic flow diagram of another embodiment of a method of facilitating the delivery of broadcasted content from a wireless communication network.

DETAILED DESCRIPTION

Fig. 1 illustrates one embodiment of a communication network 10 that includes a Radio Access Network, RAN, portion 12, and a Core Network, CN, portion 14. The communication network 10— hereafter, network 10— provides one or more communication services to any number of subscriber devices 16. By way of a non-limiting example, the network 10 comprises cellular communication network, such as a Long Term Evolution, LTE, network based on Third Generation Partnership Project, 3GPP, standards. In this example case, the RAN 12 comprises an Evolved UMTS Terrestrial Radio Access Network or E-UTRAN, and the CN 14 comprises an Evolved Packet Core or EPC. The interested reader may refer to two technical specifications, 3GPP TS 23.401 and TS 36.300, for general information regarding the EPC and the E-UTRAN, respectively.

Of particular interest herein, the network 10 provides multi-cast / broadcast multimedia services, referred to as MB MS in general, and as Evolved or eMBMS in the LTE context. For example, the network 10 may broadcast various content available from a content provider network 18. To that end, a network node 20 is configured for certain MBMS-related operations, according to the teachings herein. The network node 20 comprises, for example, a Broadcast Management Center or BMC, which also may be referred to as an EMBM or "ERICSSON Mobile Broadcast Manager". The BMC is configured to manage broadcast content delivery, i.e., manage the planning, configuration, scheduling, provisioning, monitoring and archiving of content broadcasted via the network 10.

In an example embodiment, the network node 20 comprises one or more communication interfaces 22, and processing circuitry 24 that is operatively associated with the communication interface(s) 22. Physically, or at least functionally, the processing circuitry 24 includes a manifest file processing circuit 26 that is configured to carry out the processing operations disclosed herein. In an example implementation, the communication interface or interfaces 22 comprises physical-layer interface circuits, e.g., a data network interface, and associated protocol processors, which configure the network node 20 to communicate with one or more other nodes in the network 10. Correspondingly, the processing circuitry 24, including the manifest file processing circuit 26, comprises one or more digital processing circuits, such as one or more microprocessors, Digital Signal Processors or DSPs, Application Specific Integrated Circuits or ASICs, Field Programmable Gate Arrays or FPGAs, or other digital processing circuitry.

In at least one embodiment, the processing circuitry 24 includes or is interfaced with a non-transitory computer-readable medium, referred to here as "storage 28". The storage 28 comprises, for example, one or more types of memory circuits and/or storage devices. By way of example, the storage 28 comprises a mix of long-term storage devices or circuits, and further includes working memory for program execution. Note that the term "non-transitory" as used here does not necessarily mean permanent or unchanging storage, but does denote storage of at least some persistence. Correspondingly, the processing circuitry 24 is specially adapted to carry out the operations described herein, based on its execution of computer program instructions comprising a computer program 30, as stored in the storage 28. The storage 28 also may store configuration data 32.

In the context of broadcasting management or support, the network node 20 interfaces with, for example, a Broadcast Delivery Center or BDC 40. The BDC 40 may also be referred to as a Broadcast Multicast Service Center or BMSC. The BDC 40 is configured to handle eMBMS sessions— session start and stop— and to deliver user plane media to a MBMS Gateway node 42, referred to more simply as the MBMS-GW 42. In turn, the MBMS-GW 42 performs MBMS Session Control Signaling for starting and stopping MBMS sessions towards the RAN 12 via a Mobility Management Entity, MME, 44. The MME 44 transmits session control messages towards multiple radio network nodes involved in broadcasting the particular broadcast content at issue. In this example, the radio network nodes are shown as eNBs/MCEs 46, where "eNB" denotes evolved NodeB, which is an LTE radio base station, and where "MCE" denotes Multicast Coordination Entity. Each eNB/MCE 46 uses the Session Control Signaling it receives from the MME 44 to initiate configuration of radio resources to be used for broadcast transmissions. In order to ensure Single Frequency Network or "SFN" operation for such broadcasts, identical time-aligned signals are transmitted over multiple cells in the RAN 12, which increases the achievable data rates. Each eNB/MCE 46 joins an Internet Protocol, IP, Multicast group in order to receive IP Multicast packets from the MBMS-GW 42, where the IP Multicast packets contain MBMS user data for a given broadcast.

The data comprising the actual broadcast content comes from, for example, a live encoder or other provider network node 50 included in the content provider network 18. The provider network node 50 encodes content for broadcasting by the network 10 from any number of sources, including content from one or more content stores 52 and/or from any number of other "feeds", such as Content Delivery Network or CDN feeds, satellite feeds, various live event feeds, etc.

Using the above framework as a non-limiting example, the network node 20 is configured for providing current manifest information for broadcasted content delivered via the network 10. In that role, the processing circuitry 24 is configured to obtain an initial manifest file for a scheduled broadcast, forward the initial manifest file for the broadcast, for distribution to one or more subscriber devices 16 associated with the wireless communication network 10. Further, responsive to a start of the broadcast, the processing circuitry 24 is configured to check for manifest updates for the broadcast, and forward an updated manifest file for the broadcast, in dependence on the operation of checking for manifest updates.

For example, the processing circuitry 24 is configured to check for manifest updates by performing at least a first check in conjunction with the start of the broadcast, and it may be further configured to check for manifest updates by periodically checking for updates during the broadcast. In this context, the processing circuitry 24 is configured to detect the start of the broadcast explicitly or implicitly, such as start time detection or the detection of actual broadcast data or control signaling. In either case, as explained earlier, the initial manifest file and the updated manifest files, if any, each comprises information for identifying and playing one or more content streams comprising the broadcast.

The broadcast is a Dynamic Adaptive Streaming over HTTP, DASH, broadcast, for example. In such cases, the initial manifest file and any updated manifest file each comprises an extensible Markup Language, XML, file providing Media Presentation Description information for the DASH broadcast.

In at least some embodiments where the network node 20 comprises a BMC node, the processing circuitry 24 is configured to forward the initial manifest file and the updated manifest file by forwarding Service Announcement Bundles to the BDC 40, for delivery to the MBMS- GW 42.

In a working example, the provider network node 50 is a live encoder and thus maintains the most current manifest file for a given broadcast, e.g., a live event that is upcoming, or one that is in the process of being broadcasted. Thus, for such cases, the processing circuitry 24 is configured to check for manifest updates for a given broadcast by evaluating current manifest file information, as obtained from the provider network node 50. The processing circuitry 24 is configured, for example, to obtain the current manifest file information from the provider network node 50 on a recurring basis during the broadcast.

In at least one embodiment, the processing circuitry 24 is configured to evaluate the current manifest file information by determining whether the most current manifest file differs from a previously most current manifest file. The determination is based on, for example, the processing circuitry 24 comparing a characteristic value of the most current manifest file with a like characteristic value of the previously most current manifest file. Non-limiting examples of characteristic values include any one or more of: file size, file creation or modification date, or other timestamp information, file checksum, etc.

Here, it will be appreciated that the network node 20 considers the manifest information most recently obtained from provider network node 50 for any given broadcast as being the most recent manifest information available for the broadcast, and it uses the previously most recent manifest information it had for the broadcast as the basis for comparison— although it may compare multiple older iterations of manifest file information to the most recent or current manifest file information.

In at least one embodiment, the processing circuitry 24 is configured to evaluate the current manifest file information by determining whether the most current manifest file differs from a previously most current manifest file and further determining whether the most current manifest file differs in any critical way from the previously most current manifest file.

Correspondingly, the processing circuitry 24 in such embodiments is configured to condition, or at least delay, forwarding the most current manifest file in dependence on whether the most current manifest file is determined to include at least one critical difference. A critical change comprises, for example, a change in the scheduled start time of the broadcast, or changes in the URLs and/or encoded stream structure comprising the broadcast, as such information is critical to any subscriber device 16 being able to receive, decode and play-out the broadcast.

This approach reflects the fact that there may be some changes in manifest file information that will not prevent a subscriber device 16 from being able to use an older version of the manifest file information for successful decoding and play-out of the broadcast. Further, even where there are changes directly related to play-out, not all such changes are necessarily critical to forward to the interested subscriber devices 16 immediately. For example, a change in the scheduled end time of broadcast does not necessarily need to be immediately signaled.

Broadly, then, the processing circuitry 24 in one or more embodiments is configured to forward any given updated manifest file, in dependence on the operation of checking for manifest updates. In particular, the dependent forwarding comprises determining that a most current manifest file for the broadcast differs from a previously most current manifest file, and at least conditionally forwarding the most current manifest file, for distribution to the one or more subscriber devices 16. The processing circuitry 24 may be configured to forward the newest manifest file information unconditionally, or may be configured to forward updated manifest file information conditionally, such as when certain types of changes are detected, or at certain times.

For example, in one embodiment, the processing circuitry 24 forwards the most current manifest file only in response to determining that at least one change between the most current manifest file and the previously most current manifest file is deemed to be a critical change. The changes that are deemed to be critical may be determined according to stored configuration information 32 identifying the type or types of changes deemed to be critical.

In another embodiment, or for certain other types of manifest file information changes, the processing circuitry 24 is configured to determine that an updated manifest file is available for a broadcast and sends the updated manifest file on a deferred basis, based on performing at least one of the following deferral operations: defer forwarding of the updated manifest file until one or more other updated manifest files are available for a corresponding one or more other broadcasts that are being facilitated by the network node 20, and batch the forwarding of the updated manifest file and the one or more other updated manifest files; defer forwarding of the updated manifest file until a threshold number of changes is detected with respect to the initial manifest file or a previously updated manifest file; and defer forwarding of the updated manifest file until a critical change is detected with respect to the initial manifest file or a previously updated manifest file.

Thus, the processing circuitry 24 may forward updated manifest file information to the network 10 as soon as it is detected as being available, or it may control the forwarding for any one or more reasons, such as to improve signaling efficiencies. That is, for any given broadcast, the processing circuitry 24 may allow some number of non-critical changes to accumulate and then forward the most recent manifest file available once some threshold number of changes has occurred. Of course, it may immediately send any detected critical change, and the processing circuitry 24 also may attempt to batch together updated manifest file information for more than one broadcast, such as allowing manifest information updates to accumulate for one broadcast until there are one or more manifest information updates detected for another broadcast. This approach allows the processing circuitry 24 to forward updated manifest information for more than one broadcast in a Service Announcement bundle, which it sends to the BDC 40.

Fig. 2 illustrates a method 200 that is implemented by the network 10, e.g., by the network node 20 described above, or by another entity or arrangement of processing circuitry within the network 10. The method 200 provides current manifest information for broadcasted content delivered via the network 10 and it includes obtaining (Block 202) an initial manifest file for a scheduled broadcast, and forwarding (Block 204) the initial manifest file for the broadcast, for distribution to one or more subscriber devices 16 associated with the wireless communication network 10.

Further, responsive to a start of the broadcast (YES from Block 206), the method 200 includes checking (Block 208) for manifest updates for the broadcast, and forwarding (Block 210) an updated manifest file for the broadcast, in dependence on said step of checking for manifest updates. As noted, the forwarding may be conditioned on the type of changes observed between the most current manifest information and the previously most current manifest information, or on the overall number of changes observed between the most current manifest information and one or more previous versions of the manifest information.

In the context of the method 200, the network node 20 can be understood as comprising means for obtaining an initial manifest file for a scheduled broadcast, and means for forwarding the initial manifest file for the broadcast, for distribution to one or more subscriber devices 16 associated with the wireless communication network 10. Still further, the network node 20 includes means responsive to a start of the broadcast, for checking for manifest updates for the broadcast, and forwarding an updated manifest file for the broadcast, in dependence on said step of checking for manifest updates. In an example implementation, these means comprise the one or more communication interfaces 22 and the processing circuitry 24 seen in Fig. 1.

It will be appreciated that a number of arrangements are contemplated for the processing circuitry 24. In at least one embodiment, such as seen in Fig. 3, the processing circuitry 24 comprises a number of functional and/or physical modules, e.g., as may be implemented using computer processing circuitry configured according to the execution of computer program instructions embodying the manifest file information processing disclosed herein.

In an example implementation, the network node 20 includes an obtaining module 60 for obtaining an initial manifest file for a scheduled broadcast, and a forwarding module 62 for forwarding the initial manifest file for the broadcast, for distribution to one or more subscriber devices 16 associated with the network 10. Further, the processing circuitry 24 includes a checking module 64 that, in response to a start of the broadcast, checks for manifest updates for the broadcast, and forwards, via the forwarding module 62, an updated manifest file for the broadcast, in dependence on checking for manifest updates. Note that the storage 28 includes, for example, a buffer 66 or other memory for storing manifest information, e.g., for comparing the previously most current manifest information, as obtained in an immediately prior retrieval, with the most recent manifest information, as obtained in the current retrieval.

Whether implemented via the above arrangement of processing modules or using another arrangement, Fig. 4 illustrates another embodiment of a method 400 of providing updated manifest file information to subscriber devices 16 operating in a network 10. Here, it will be appreciated that the subscriber devices 16 are, in general, not logically connected to the provider network 18 and are therefore not in a position to automatically receive updated manifest file information. The method 400 may be considered as a more detailed version of the method 200 described above.

A broadcast service is scheduled (Block 402), and the network node 20 retrieves the corresponding manifest information (Block 404) and determines whether the checksum of the manifest file differs from the most recent version known to the network node 20 (Block 406).

Note that for the initial retrieval of the manifest information, there is no previous version against which to compare, so the comparison at issue in Block 406 will be understood as occurring after the initial manifest information is retrieved and stored at the network node 20. For example, in advance of the broadcast start, the network node 20 retrieves initial manifest information and stores it for comparing to later manifest information that is retrieved upon or after the actual start of the broadcast.

Thus, assuming that the network node 20 retrieved initial manifest information before the start of a given broadcast, and retrieves manifest information for that broadcast in Block 404, at the start of the broadcast, or subsequent to the start, then the comparison of checksums at Block 406 will be understood as comparing the most current information with the previously obtained information. If the checksums differ, the processing circuitry 24 concludes that the most current manifest information differs from the previous information and it retrieves one or more segments of manifest file information (Block 408) and forwards or otherwise "pushes" those changes down to the subscriber devices 16 (Block 410), e.g., by sending the updated manifest information to the BDC 40.

Assuming the broadcast service has not terminated (NO from Block 412), the network node 20 waits for some defined period (Block 414), e.g., 'W seconds, where N is some number of seconds deemed to be a suitable waiting interval. Here, "suitable" means that the waiting interval strikes a balance between signaling overhead and quickly detecting manifest information changes for a broadcast that is underway. Non-limiting example periods include one second or five seconds.

After expiration of the waiting period, the network node 20 queries the provider network 18 for the latest manifest information for the broadcast and the process repeats, e.g., the checksum of the newest information is compared to the checksum of the prior information, etc.

Equivalently, the provider network 18 is adapted to respond to such queries more efficiently, e.g., by sending a flag or other logical indicator that indicates whether or not the manifest information has changed since a last query by the network node 20. Thus, rather than comparing a checksum in Block 406, such processing may comprises evaluating the flag or other indicator returned from the provider network 18, to determine whether the indicator indicates that updated manifest information is available, which can then be retrieved by the network node 20. Of course, the network node 20 in general may determine whether updated manifest information is available for any given broadcast based on either actively querying the provider network 18, or based on receiving "pings" or other incoming signaling initiated from the provider network 18.

Notably, modifications and other embodiments of the disclosed invention(s) will come to mind to one skilled in the art having the benefit of the teachings presented in the foregoing descriptions and the associated drawings. Therefore, it is to be understood that the invention(s) is/are not to be limited to the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of this disclosure. Although specific terms may be employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.

Claims

CLAIMS What is claimed is:

1. A method (200) at a network node (20) of a wireless communication network (10), for providing current manifest information for broadcasted content delivered via the wireless communication network (10), said method comprising:

obtaining (202) an initial manifest file for a scheduled broadcast;

forwarding (204) the initial manifest file for the broadcast, for distribution to one or more subscriber devices (16) associated with the wireless communication network (10); and

responsive to a start of the broadcast (206):

checking (208) for manifest updates for the broadcast; and

forwarding (210) an updated manifest file for the broadcast, in dependence on said step of checking for manifest updates.

2. The method (200) of claim 1 , wherein checking (208) for manifest updates comprises performing at least a first check in conjunction with the start of the broadcast.

3. The method (200) of claim 1 or 2, wherein checking (208) for manifest updates comprises periodically checking for updates during the broadcast.

4. The method (200) of any of claims 1-3, further comprising detecting the start of the broadcast explicitly or implicitly.

5. The method (200) of any of claims 1-4, wherein the initial manifest file and the updated manifest file each comprises information for identifying and playing one or more content streams comprising the broadcast.

6. The method (200) of any of claims 1-5, wherein the broadcast is a Dynamic Adaptive Streaming over HTTP, DASH, broadcast, and wherein the initial manifest file and the updated manifest file each comprises an extensible Markup Language, XML, file providing Media Presentation Description information for the DASH broadcast.

7. The method (200) of any of claims 1-6, wherein the network node (20) comprises a Broadcast Management Center, BMC, node, and wherein forwarding (204, 210) the initial manifest file and the updated manifest file comprises forwarding Service Announcement Bundles to a Broadcast Delivery Center, BDC, node (40), for delivery to a Multimedia Broadcast Multicast Service Gateway, MBMS-GW, node (42) residing in a Core Network, CN, portion (14) of the wireless communication network (10).

8. The method (200) of any of claims 1-7, wherein checking (208) for manifest updates comprises evaluating current manifest file information, as obtained from a provider network node (50) that maintains a most current manifest file for the broadcast.

9. The method (200) of claim 8, wherein the method (200) includes the network node (20) obtaining the current manifest file information from the provider network node (50) on a recurring basis during the broadcast.

10. The method (200) of claim 8 or 9, wherein evaluating the current manifest file information comprises determining whether the most current manifest file differs from a previously most current manifest file, based on comparing a characteristic value of the most current manifest file with a like characteristic value of the previously most current manifest file.

11. The method (200) of any of claims 8-10, wherein evaluating the current manifest file information comprises determining whether the most current manifest file differs from a previously most current manifest file and further determining whether the most current manifest file differs in any critical way from the previously most current manifest file, and wherein forwarding (210) the updated manifest file comprises conditioning, or at least delaying, the forwarding of the most current manifest file in dependence on whether the most current manifest file is determined to include at least one critical difference.

12. The method (200) of any of claims 1-11, wherein forwarding (210) the updated manifest file comprises, in response to determining that a most current manifest file for the broadcast differs from a previously most current manifest file for the broadcast, at least conditionally forwarding the most current manifest file, for distribution to the one or more subscriber devices (16).

13. The method (200) of claim 12, wherein at least conditionally forwarding the most current manifest file comprises forwarding the most current manifest file only in response to determining that at least one change between the most current manifest file and the previously most current manifest file is deemed to be a critical change, according to stored configuration information (32) identifying types of changes deemed to be critical.

14. The method (200) of any of claims 1-13, wherein forwarding (210) the updated manifest file comprises determining that an updated manifest file is available for the broadcast and sending the updated manifest file on a deferred basis, based on performing at least one of the following deferral operations:

deferring forwarding of the updated manifest file until one or more other updated

manifest files are available for a corresponding one or more other broadcasts that are being facilitated by the network node (20), and batching the forwarding of the updated manifest file and the one or more other updated manifest files;

deferring forwarding of any updated manifest file until a threshold number of changes is detected with respect to the initial manifest file or a previous updated manifest file; and

deferring forwarding of the updated manifest file until a critical change is detected with respect to the initial manifest file or a previous updated manifest file.

15. A network node (20) configured for providing current manifest information for broadcasted content delivered via a wireless communication network (10), said network node (20) comprising:

one or more communication interfaces (22); and

processing circuitry (24) operatively associated with the one or more communication interfaces (22) and configured to:

obtain an initial manifest file for a scheduled broadcast;

forward the initial manifest file for the broadcast, for distribution to one or more subscriber devices (16) associated with the wireless communication network (10); and

responsive to a start of the broadcast:

check for manifest updates for the broadcast; and

forward an updated manifest file for the broadcast, in dependence on the operation of checking for manifest updates.

16. The network node (20) of claim 15, wherein the processing circuitry (24) is configured to check for manifest updates by performing at least a first check in conjunction with the start of the broadcast.

17. The network node (20) of claim 15 or 16, wherein the processing circuitry (24) is configured to check for manifest updates by periodically checking for updates during the broadcast.

18. The network node (20) of any of claims 15-17, wherein the processing circuitry (24) is configured to detect the start of the broadcast explicitly or implicitly.

19. The network node (20) of any of claims 15-18, wherein the initial manifest file and the updated manifest file each comprises information for identifying and playing one or more content streams comprising the broadcast.

20. The network node (20) of any of claims 15-19, wherein the broadcast is a Dynamic Adaptive Streaming over HTTP, DASH, broadcast, and wherein the initial manifest file and the updated manifest file each comprises an extensible Markup Language, XML, file providing Media Presentation Description information for the DASH broadcast.

21. The network node (20) of any of claims 15-20, wherein the network node (20) comprises a Broadcast Management Center, BMC, node, and wherein the processing circuitry (24) is configured to forward the initial manifest file and the updated manifest file by forwarding Service Announcement Bundles to a Broadcast Delivery Center, BDC, node (40), for delivery to a Multimedia Broadcast Multicast Service Gateway, MBMS-GW, node (42) residing in a Core Network, CN, portion (14) of the wireless communication network (10).

22. The network node (20) of any of claims 15-21, wherein the processing circuitry (24) is configured to check for manifest updates for the broadcast by evaluating current manifest file information, as obtained from a provider network node (50) that maintains a most current manifest file for the broadcast.

23. The network node (20) of claim 22, wherein the processing circuitry (24) is configured to obtain the current manifest file information from the provider network node (50) on a recurring basis during the broadcast.

24. The network node (20) of claim 22 or 23, wherein the processing circuitry (24) is configured to evaluate the current manifest file information by determining whether the most current manifest file differs from a previously most current manifest file, based on comparing a characteristic value of the most current manifest file with a like characteristic value of the previously most current manifest file.

25. The network node (20) of any of claims 22-24, wherein the processing circuitry (24) is configured to evaluate the current manifest file information by determining whether the most current manifest file differs from a previously most current manifest file and further determining whether the most current manifest file differs in any critical way from the previously most current manifest file, and to condition, or at least delay, forwarding the most current manifest file in dependence on whether the most current manifest file is determined to include at least one critical difference.

26. The network node (20) of any of claims 15-25, wherein the processing circuitry (24) is configured to forward the updated manifest file, in dependence on the operation of checking for manifest updates, by, in response to determining that a most current manifest file for the broadcast differs from a previously most current manifest file, at least conditionally forwarding the most current manifest file, for distribution to the one or more subscriber devices (16).

27. The network node (20) of claim 26, wherein the processing circuitry (24) is configured to at least conditionally forward the most current manifest file by forwarding the most current manifest file only in response to determining that at least one change between the most current manifest file and the previously most current manifest file is deemed to be a critical change, according to stored configuration information (32) identifying types of changes deemed to be critical.

28. The network node (20) of any of claims 15-27, wherein the processing circuitry (24) is configured to forward the updated manifest file, in dependence on the operation of checking for manifest updates, by determining that an updated manifest file is available for the broadcast and sending the updated manifest file on a deferred basis, based on performing at least one of the following deferral operations:

defer forwarding of the updated manifest file until one or more other updated manifest files are available for a corresponding one or more other broadcasts that are being facilitated by the network node (20), and batch the forwarding of the updated manifest file and the one or more other updated manifest files; defer forwarding of the updated manifest file until a threshold number of changes is detected with respect to the initial manifest file or a previous updated manifest file; and

defer forwarding of the updated manifest file until a critical change is detected with respect to the initial manifest file or a previous updated manifest file.

29. A network node (20) configured for providing current manifest information for broadcasted content delivered via a wireless communication network (10), said network node (20) comprising:

an obtaining module for obtaining an initial manifest file for a scheduled broadcast; a forwarding module for forwarding the initial manifest file for the broadcast, for

distribution to one or more subscriber devices (16) associated with the wireless communication network (10); and

a checking module for, responsive to a start of the broadcast, checking for manifest updates for the broadcast, and forwarding, via the forwarding module, an updated manifest file for the broadcast, in dependence on checking for manifest updates.