ADAPTIVE BIT RATE CONTROL IN A COMMUNICATION NETWORK

TECHNICAL FIELD

The present invention relates to delivering streaming content, such as video-on-demand (VoD) content, and particularly relates to delivering streaming content via a radio access network (RAN).

BACKGROUND

Adaptive Bit Rate (ABR) technology encodes each video stream into multiple representations, also referred to as“representation levels”. In context of video content, the different representation levels correspond to different bitrates and resolutions. The

representations are packaged into segments, e.g., with each segment containing 2-10 seconds worth of video playback, and the segments comprising a selected representation level are streamed to the video player of a client device, for playout.

The video player selects a given representation level in view of, e.g., user preferences, device capabilities, and communication link capabilities. At least that latter variable represents significant dynamic variability in the wireless context. For example, a tablet, computer, smartphone, or other video playback device may connect to the content server via a wireless network, such as a cellular Radio Access Network (RAN). The playback device may

automatically negotiate for the highest representation level it is capable of handling under the prevailing radio and network conditions and then renegotiate higher or lower representation levels in response to changing radio or network conditions.

Here, the phrase“radio conditions” refers to the particulars of the communication link between the playback device and the RAN, whereas the term“network conditions” alludes to broader conditions in the RAN, such as the“loading” level of the RAN, at least in the cell or network area relevant to serving the playback device. While the playback device may or may not have direct knowledge of the network conditions, it nonetheless experiences the effects of network loading or congestion, e.g., by failing to receive streaming content at an appropriate delivery rate, which can be discerned at the playback device via monitoring of the receive buffer status.

When the playback device experiences problems at the current representation level, it may automatically fall back to a lower representation level, with the fall back requiring renegotiation signaling between the playback device and the content server. Further, the playback device must flush its buffers of content at the old representation level and reset certain aspects of its decoding processes. Thus, while fall back offers a mechanism for continuing the content stream under worsening radio or network conditions, it is recognized herein that falling back imposes signaling and other burdens, and can have deleterious effects on the user experience.

SUMMARY

Methods and apparatus described by way of example in this document select between different versions of a content stream, e.g., on a per segment basis, for wireless delivery to a client device. Advantageously, both versions have the same representation level but have different transmission bandwidth requirements. As an example, the representation level is a video resolution and one version of the content stream has higher video quality at the defined resolution but generally requires more transmission bandwidth than the other version. A control node having access to both versions dynamically selects which version to send for delivery to a client device via a Radio Access Network (RAN) supporting wireless delivery to the client device, in dependence on monitoring RAN performance. Among other things, dynamic version selection on the network side reduces the need for the client device to reselect to a lower representation level responsive to decreases in the available transmission bandwidth in the RAN.

An example network node includes communication circuitry configured for

communicating with one or more other nodes in a RAN, and with one or more other nodes operative as content sources. The example network node further includes processing circuitry that is operatively associated with the communication circuitry. The processing circuitry is configured to monitor a performance of the RAN with respect to delivering a content stream to a client device via the RAN, and to receive a request from the client device, requesting a segment of the content stream at a defined representation level. Further, the processing circuitry is configured to send a first or second version of the segment to the RAN for the client device, in dependence on the monitored performance, the first and second versions being at the defined representation level but having different transmission bandwidth requirements. Such operations may be ongoing, e.g., carried out over many segments of the content stream.

In another example, a method of operation in a network node includes monitoring a performance of a RAN, with respect to delivering a content stream to a client device via the RAN, receiving a request from the client device, requesting a segment of the content stream at a defined representation level, and sending a first or second version of the segment to the RAN or the client device, in dependence on the monitored performance. As before, the first and second versions of the content segment are at the same defined representation level, but they have different transmission bandwidth requirements.

For example, the content stream is a video stream, the defined representation level is a defined resolution, and, for the same video resolution, one version of the segment is higher quality than the other but requires greater transmission bandwidth than the other version. By way of example, the term“higher quality” denotes additional or enhanced information content, such as further refinement layers in a layer-encoded video stream, lower coding rates, etc.

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

Figure 1 is a block diagram of one embodiment of a communication network.

Figure 2 is a block diagram of one embodiment of a Radio Access Network (RAN). Figure 3 is a logic flow diagram of one embodiment of a method of operation at a network node, such as the control node introduced in Figure 1.

Figure 4 is a block diagram of one embodiment of a network node, such as the control node introduced in Figure 1.

Figure 5 is block diagram of another embodiment of a communication network.

DETAIFED DESCRIPTION

Figure 1 illustrates a communication network 10 that provides communication services to a client device 12, which is denoted as“CD 12” in the diagram. By way of example, the communication network 10 couples the client device 12 to one or more external networks 14, such as the Internet. The external network(s) 14 provide the client device 12 with access to a plethora of communication services, such as streaming services available from an origin content source 16. By way of example, the origin content source 16 provides movies, television shows, or other video content for delivery to the client device 12 via the communication network 10.

Although not an implementation limitation, the communication network 10 in one or more of example embodiments comprises a Third Generation Partnership Project (3 GPP) cellular communication network. Correspondingly, the client device 12 shall be understood as broadly connoting essentially any wireless communication apparatus having the requisite wireless communication circuitry and associated processing functionality necessary for connecting to the communication network 10 via one or more of the involved Radio Access Technologies (RATs), along with further processing circuitry and user interface circuitry and equipment for receiving and playing back one or more types of content streams.

The illustrated communication network 10 includes a Radio Access Network (RAN) 20 and an associated Core Network (CN) 22. The CN 22 includes a network node 30 that is referred to herein as the“control node 30”, along with a multi-version content source 32, e.g., a configured computer server or the like. Of course, those having ordinary skill in the art will appreciate that the depiction of the CN 22 is simplified to focus the discussion. In actual implementation, the CN 22 includes other nodes, such as mobility management notes, packet gateway notes, etc., to support the routing of user traffic to and from the client device 12 and any number of other devices connected to the communication network 10.

In at least one embodiment, the multi- version content source 32 is configured to receive a content stream, denoted as“CS” in the illustration, which may be provided by an external content provider, such as NETFLIX. The diagram assumes that the content stream is provided to the multi- version content source 32 at a defined representation level, such as may have been initially negotiated between the client device 12 in the origin content source 16 that provides the content stream. The client device and/or the origin content source 16 may renegotiate the representation level during streaming and that the operations of interest herein may be applied to any given representation level currently in use.

For the current representation level in use for the content stream, the multi- version content source 32 generates first and second versions, denoted as“VI of CS” and“V2 of CS” in the diagram. Although the two versions are at the same representation level, they have different transmission bandwidth requirements. Here, the term“transmission bandwidth requirement” refers to the transmission bandwidth required for transmitting content segments according to the required timing. While the number of bits required to represent a given content segment may vary as a function of the complexity of the content encoded within the segment, for the two content stream versions contemplated here, one version of the content stream is larger than the other version of the content stream. In the video context, one version is encoded for higher video quality than the other version, although the representation levels are the same. Higher-quality encoding may include fewer predictive frames, lower coding or compression rates, additional video enhancement layers, etc.

To better understand the content stream in the respective versions of the content stream, it may be helpful to consider an example implementation based on Adaptive Bit Rate (ABR) and coding. Standard ABR implementations use a Constant Bit Rate (CBR) encoding, regardless of image complexity. Consequently, for a defined representation level of a video stream, each segment has the same constant bitrate, irrespective of the complexity of the encoded video content included in the segment.

In contrast, ERICSSON AB has developed two versions of optimized ABR, for improved quality with same bandwidth and reduced bandwidth for the same quality. That is, for the same representation level, ABR encoding/re-coding produces two versions of the content stream. The multi- version encoding/re-coding uses a Variable Bit Rate (VBR) allocation in ABR content streams, in a manner that is transparent to the playback devices and to the delivery network. A first version is optimized or otherwise“tuned” for video quality, while a second version is optimized or otherwise“tuned” for bandwidth reduction. For the second version, the VBR encoding tunes the bandwidth consumption to only what is needed for the targeted quality, with image bitrate being defined by the instant content complexity, to reclaim bandwidth when complexity is low. Of course, it shall be understood that one version has higher quality than the other version, or that one version has lower transmission bandwidth requirements than the other version, in relative terms.

In any case, in at least one embodiment the multi- version content source 32 receives a content stream at a defined representation level and generates first and second versions of the content stream, with one version having a generally higher quality than the other version, and with one version having generally lower transmission bandwidth requirements than the other version. It should also be understood that such operations in one or more embodiments applied to cached or pre-fetched content. That is, the multi- version content source 32 stores, or has access to, previously generated and stored versions of a given content stream for each of one or more available representation levels.

The network node 30— control node 30— operates as an edge-node in the diagram, controlling the delivery of a content stream to a client device 12 through the RAN 20. In an example embodiment, the control node 30 includes communication circuitry 40 that is configured for communicating with one or more other nodes in the RAN 20, and with one or more other nodes operative as content sources. For example, the communication circuitry 40 includes communication interface circuits and associated protocol processors configured for communicating with a RAN node 34 in the RAN 20, and further includes communication interface circuits and associated protocol processors configured for communicating with the multi-version content source 32 in the CN 22. By way of example, the RAN node 34 is a radio base station— e.g., and eNB in an FTE-based RAN or a gNB in a 5G-based RAN. Alternatively, the RAN node 34 may be a Radio Network Controller (RNC), or may be some other node associated with delivering the content stream to the client device 12 via the wireless link.

The control node 30 in the illustrated example further includes processing circuitry 42 that is operatively associated with the communication circuitry 40 and configured to monitor a performance of the RAN 20 with respect to delivering a content stream to a client device 12 via the RAN 20, receive a request from the client device 12, requesting a segment of the content stream at a defined representation level, and send a first or second version (VI or V2) of the segment to the RAN 20 for the client device 12, in dependence on the monitored performance— i.e., the monitored RAN communication performance. Here, the first and second versions are at the defined representation level but have different transmission bandwidth requirements. In the video context, the content stream is a video stream that comprises segments of video content, and the one version has a higher video quality than the other version and one version has a lower transmission bandwidth requirement than the other version.

The processing circuitry 42 in an example embodiment is configured to receive successive requests from the client device 12, requesting successive segments of the content stream at the defined representation level, and is configured to send the first or second version of each successive segment in dependence on the monitored performance for a time relevant to the sending of each successive segment. The processing circuitry 42 in at least one implementation, is configured to dynamically decide on a per segment basis whether an available bandwidth in the RAN 20, as indicated by the monitored performance, is sufficient to support delivery to the client device 12 of the version of the segment having the higher transmission bandwidth requirements.

As noted, the content stream is a video stream, for example. In the video stream context, the defined representation level is a defined video resolution. Thus, given video content may be available in one or more resolutions, and, for a given resolution being streamed to the client device 12, the control node dynamically chooses between delivering first or second versions of the involved content segments, in dependence on a monitored performance of the RAN 20.

In a corresponding example, the first and second versions are respective adaptive bit rate video segments. The first version is coded for a lower transmission bandwidth requirement at the defined representation level, as compared to the second version, and the second version is coded for a higher video quality at the defined representation level, as compared to the first version. Here,“first” and“second” do not connote encoding orders or priorities, and instead operate as labels for conveniently referring to the different versions of the content. The processing circuitry 42 in an example embodiment is configured to monitor the performance of the RAN 20 by monitoring one or more transmission parameters on an ongoing basis. Here, the transmission parameter(s) in question vary in dependence on a bandwidth available in the RAN 20 for delivering the content stream to the client device 12, and the processing circuitry 42 is configured to send the first or second version of the segment based on choosing the version having the lower transmission bandwidth requirements, if the available bandwidth is deemed insufficient for delivering the version having the higher transmission bandwidth requirements. By way of example, the one or more transmission parameters comprise at least one of: a Transmission Control Protocol (TCP) congestion parameter associated with delivering the content stream to the client device 12 via the RAN 20, a parameter associated with delivering the content stream to the client device 12 via the RAN 20 using a Quick User Datagram Protocol Internet Connection (QUIC) delivery mechanism, a Round Trip Time (RTT) parameter associated with delivering the content stream to the client device 12 via the RAN 20, and a throughput parameter associated with delivering the content stream to the client device 12 via the RAN 20.

In addition to monitoring the transmission parameter(s) as a form of implicit feedback from the RAN 20 regarding the available bandwidth, or as an alternative to implicit monitoring, the processing circuitry 42 may be configured to monitor the performance of the RAN 20 based on receiving explicit feedback from the RAN 20 on an ongoing basis. The explicit feedback directly or indirectly indicates a bandwidth available in the RAN 20 for delivering the content stream to the client device 12, and the processing circuitry 42 is configured to send the first or second version of a requested segment based on choosing the version having the lower transmission bandwidth requirements, if the available bandwidth is deemed insufficient for delivering the version having the higher transmission bandwidth requirements.

At least in cases where the first and second versions of a content segment requested by the client device 12 are not pre-cached at the network node 30, the processing circuitry 42 is configured to request the first and second versions of the content segment from a content source node, e.g., the multi-version content source 32. In further example details, the first version of a content segment is a bandwidth-optimized version and the second version is a quality-optimized version. Correspondingly, the processing circuitry 42 is configured to check whether an observed or indicated performance of the RAN 20 with respect to delivering one or more prior segments of the content stream is sufficient for delivering the quality-optimized version of the segment and, if so, send the quality-optimized version, and otherwise send the bandwidth-optimized version. As for the above“configurations” of the control node 30, the processing circuitry 42 comprises fixed circuitry, programmed circuitry, or some combination of both. In one or more embodiments, the processing circuitry 42 comprises digital processing circuitry that is programmatically configured based on execution of stored computer program instructions. For example, the control node 30 includes storage 44, which stores one or more computer programs 46 comprising such computer program instructions, and which may further store one or more supporting items of configuration data 48. The storage 44 comprises or includes a non-transitory computer-readable medium storing the computer program(s) 46, for execution by one or more microprocessors or other digital processors included in the processing circuitry 42. Such execution“specially adapts” the processing circuitry 42 to perform the processing described herein.

Thus, the processing circuitry 42 comprises one or more microprocessor-based circuits, DSP-based circuits, FPGA-based circuits, ASIC-based circuits, etc. Correspondingly, the storage 44 may comprise a mix of memory types or storage devices. For example, the storage 44 may include FLASH memory or a Solid State Disk (SSD) for non-volatile storage of program instructions, provisioning data, etc., and may include SRAM or DRAM for use as working memory for program execution, data processing, etc., during live operation.

Further, while Figure 1 depicts the control node 30 as part of the CN 22, one or more other contemplated embodiments involve implementation of the control node 30 as part of the RAN 20, such as suggested in Figure 2. In either case, there may be more than one control node 30 implemented in the network 10. For example, there may be different control nodes 30 for different geographic or logical areas of the network 10.

Figure 3 depicts an example method 300 of operation in a network node, such as may be carried out by the network node 30. The method 300 includes monitoring (Block 302) a performance of a RAN 20, with respect to delivering a content stream to a client device 12 via the RAN 20, receiving (Block 304) a request from the client device 12, requesting a segment of the content stream at a defined representation level, and sending (Block 306) a first or second version of the segment to the RAN 20 for the client device 12, in dependence on the monitored performance. As before, the first and second versions are both at the same defined representation level but have different transmission bandwidth requirements.

The method 300 may be performed in an order different than that suggested by the logic flow diagram, and it may be performed for more than one client device 12 being served the same or different content streams. As regards a given client device 12 and a given content stream, one or more steps or operations shown in Figure 3 may be performed on a background or ongoing basis, e.g., the method 300 may include tracking RAN performance over some running window, to allow version control decisions to be made on filtered parameters.

Further, receiving (Block 304) a request from a client device 12 may comprise receiving successive requests, and requesting successive segments of a content stream at a defined representation level. Here, the method 300 would include sending the first or second version of each successive segment in dependence on the monitored performance for a time relevant to the delivery of each successive segment. Such operations allow the network node 30 to change which segment version is selected for delivery to the client device 12 responsive to dynamic changes in the radio link to the client device 12 and/or changing loading conditions in the RAN 20.

For example, sending (Block 306) the first or second version of each successive segment in dependence on the monitored performance for the time relevant to the delivery of each successive segment comprises dynamically deciding on a per segment basis whether an available bandwidth in the RAN 20, as indicated by the monitored performance, is sufficient to support delivery of the version of the segment having the higher transmission bandwidth requirement. And, as previously noted, the content stream in question may be a video stream, in which case the defined representation level is a defined video resolution. Correspondingly, the first and second versions of each content segment are respective adaptive bit rate video segments, with the first version coded for a lower transmission bandwidth requirement at the defined representation level, as compared to the second version, and with the second version coded for a higher video quality at the defined representation level, as compared to the first version.

The monitoring step (Block 302) of the method 300 comprises, for example, monitoring one or more transmission parameters on an ongoing basis. The transmission parameter(s) vary in dependence on a bandwidth available in the RAN 20 for delivering the content stream to the client device 12. Correspondingly, the step of sending (Block 306) the first or second version of a segment of a content stream comprises choosing the version having the lower transmission bandwidth requirements, if the available bandwidth is deemed insufficient for delivering the version having the higher transmission bandwidth requirements. Non-limiting examples of such transmission parameters include at least one of: a Transmission Control Protocol (TCP) congestion parameter associated with delivering the content stream to the client device 12 via the RAN 20, a parameter associated with delivering the content stream to the client device 12 via the RAN 20 using a Quick User Datagram Protocol Internet Connection (QUIC) delivery

mechanism, a Round Trip Time (RTT) parameter associated with delivering the content stream to the client device 12 via the RAN 20, and a throughput parameter associated with delivering the content stream to the client device 12 via the RAN 20.

In other embodiments or at different instances, the method 300 uses explicit feedback from the RAN 20 for performance monitoring. Thus, the monitoring step (Block 302) in one or more embodiments comprises or includes receiving explicit feedback from the RAN 20 on an ongoing basis. The explicit feedback directly or indirectly indicates a bandwidth available in the RAN 20 for delivering the content stream to the client device 12. Correspondingly, sending (Block 306) the first or second version of the segment comprises choosing the version having the lower transmission bandwidth requirements, if the available bandwidth is deemed insufficient for delivering the version having the higher transmission bandwidth requirements.

Figure 4 illustrates another embodiment of the control node 30, such as may be implemented via computer processing. The control node 30 comprises a monitoring module 400 that is configured to monitor a performance of a RAN 20, with respect to delivering a content stream to a client device 12 via the RAN 20, and one or more communication modules 402 that are configured to receive a request from the client device 12, requesting a segment of the content stream at a defined representation level, and send 306 a first or second version of the segment to the RAN 20 for the client device 12. The control node 30 includes a decision module 404 that decides whether the first or second version should be sent, in dependence on the monitored performance. Here, the first and second versions of the content segment are at the same defined representation level but have different transmission bandwidth requirements.

Figure 5 illustrates a further example communication network 500, which may be a more detailed example of the network 10 introduced in Figure 1. It shall be understood that the various entities illustrated in Figure 5 are realized in various processing circuitry, e.g., in one or more servers or computer systems adapted for the requisite processing and having corresponding inter node communication interfaces.

The network 500 includes an edge delivery node 501 that operates as a version of the above-described control node 30. The edge delivery node 501 delivers selected versions of requested content to a client device 12 through a RAN 20, which includes one or more forms of the RAN node 34. The network 500 also includes or is associated with an optimized ABR encoder 502, which may be a version or form of the earlier-described multi-version content source 32. Still further, the network 500 includes a live packager 504, a multi-version content (MC) sender 506, a video-on-demand (VOD) ingestor 508, an optimized ABR transcoder and packager 510, a content origin entity 512, a core delivery entity 514. Figure 5 provides for live content streaming, or VOD streaming, or both. In either case, the content stream of interest is encoded in two versions, one targeting quality and one targeting reduced transmission bandwidth (at least as compared to the version targeting quality). Such versions may be produced or otherwise be available for each of two or more different representation levels, e.g., resolutions, of the content stream in question. For either VOD or live content streams, the edge delivery node 501 receives the two segments of the same

representation and delivers to one of the involved client device 12, based on a monitored performance of the RAN 20.

Advantageously, such operations are transparent to the client device 12, with the client device 12 requesting a content segment and receiving one or the other version of the requested segment in dependence on the monitored performance of the RAN 20. That is, the client device 12 does not make version-specific requests and need not know about the different versions. Instead, the client device 12 merely makes content segment requests directed to the

representation level currently being served to the client device 12.

The edge delivery node 501 interacts with the RAN 20 and/or uses internal heuristics based on transport layer metrics to predict the RAN bandwidth available for delivering a requested content segment to the client device 12. In at least some embodiments, the edge delivery node 501 selects, as a default choice, the quality-optimized content segments for delivery to the client device 12 via the RAN 20, and then changes its selection over to the bandwidth-optimized content segments in response to the monitored RAN performance falling below some threshold.

For example, the edge delivery node 501 may monitor RAN performance indirectly, such as by monitoring for buffer underflow events at the client device 12, where the client device 12 experiences buffer underflow as a consequence of the requested content segments being delivered to it at a rate high enough to support uninterrupted playout at the client device 12. Buffer underflows may arise with deteriorating radio conditions on the radio link between the client device 12 and the RAN 20 and/or may arise as a consequence of RAN congestion, at least in the portion of the RAN 20 involved in delivering the content stream to the client device 12. In either scenario, the occurrence of buffer underflow events at the client device 12 may be understood as an implicit indication that the bandwidth currently available in the RAN 20 for delivering the content stream to the client device 12 is insufficient for the quality-optimized version of the content segments. Dynamic selection between the two versions of content segments by the edge delivery node 501 reduces the probability that the client device 12 will switch to a lower resolution of the content stream— i.e., reduces the number of instances in which the client device 12 will switch to a less demanding representation level.

In one or more embodiments, the edge delivery node 501 uses or otherwise depends on optimized ABR that encodes live MPEG2-Transport Stream (TS) content streams into multi bitrate ABR representations. Each representation level is encoded into a quality-optimized version (referred to as Optimized ABR vl) and into a bandwidth-optimized version (referred to as Optimized ABR v2), resulting in a dual- version stream representation for each representation level of the original content stream.

In Figure 5, the optimized ABR encoder 502 performs such encoding based on receiving live content streams in the MPEG2-TS format, and it provides the resulting multi- version content streams to the live packager 504. In turn, the live packager 504 generates dual- version segments of the content stream for each representation level. The URL of the dual segments of the same representation is the same except for their version number (vl or v2), which is indicated in the URL as a query parameter. The live packager 504 also generates the manifest containing the URLs of the generated segments without any indication of their version, i.e. URLs that do not include any version. The version information is used within the network 500 for version selection as described herein, but is stripped by the edge delivery node 501 for delivery of the content segments to the client device 12— i.e., the versioning is transparent to the client device 12.

The dual- version content segments of live content streams generated from the live packager 504 are pushed to edge delivery with multicast ABR (MABR). Each representation and each version of the representation is allocated a group address, for example. For instance, a given live stream is sent on six group addresses, if the corresponding original MPEG-TS live stream is encoded at three representation levels and two versions of each representation level are produced. The live content segments as well as the manifest are pushed to the content origin entity 512 for unicast ABR streaming of live content, i.e., pulling the appropriate version of live content segments from the content origin entity 512, instead of pushing with MABR. That is, live content can be delivered either as unicast end to end via the nodes 502, 504, 512, 514, and 501, or for efficiency reasons, at least some live content can be delivered using MABR in the core, with unicast at the network edge.

The edge delivery node 501 stores the dual- version content segments for a short time, e.g. three times the segment length in seconds. When the edge delivery node 501 receives a GET request from a client device 12 for a content segment from a particular representation of a content stream, it first checks the bandwidth available to the client device 12 and sends the quality-optimized version of the requested content segment if there is enough bandwidth for the delivery, and otherwise sends the bandwidth-optimized version of the requested content segment.

Here, the“bandwidth available to the client device 12” may be checked directly or indirectly, and it may be a predictive value, e.g., one based on the most recent assessment of RAN conditions, or based on a running assessment of RAN conditions. The edge delivery node 501 monitors, for example, one or more transmission parameters associated with ongoing content stream delivery to the client device 12, such as congestion-related parameters, buffer level feedback from the client device 12, etc., to infer the available bandwidth in the RAN 20 for delivering a currently-requested content segment to the client device 12. Additionally, or alternatively, the edge delivery node 501 may receive explicit feedback from the RAN 20 (suggested by the“RAN INTERACTION” label in the diagram), indicating RAN conditions.

As for VOD content, high-resolution VOD content may be ingested by the network 500 via the VOD ingestor entity 508, which provides the VOD content to the optimized ABR transcoder and packager 510. The entity 510 transcodes and packages the VOD content into multibit rate and multi- version representations in the same way as described previously for the live streams input to the optimized ABR encoder 502. Thus, the entity 510 generates dual version content segments for each representation level of a given VOD content stream, where the URLs of the two versions of the same representation are the same except for their version number (vl or v2). Thus, at least as between the involved entities within the network 500, either the quality-optimized or the bandwidth optimized version of a given content stream may be requested for the current representation level, based on indicating the version number in the URL. However, versioning information may be stripped for delivery to the client device 12.

The packager 510 also generates the manifest containing the URLs of the generated segments without any indication of their version. The VOD segments as well as the manifest are pushed to content origin entity 512, for unicast ABR streaming to the client device 12 via the edge delivery node 501, which couples to the content origin entity 512 through a core delivery entity 514. The core delivery entity 514, for example, provides a level of content caching.

As described above, when the edge delivery node 501 receives a GET request (a URL) from a client device 12 for a content segment at a particular representation level, it fetches the dual versions of the requested content segment from the content origin entity 512, if those segments are not precached/prepositioned at the edge delivery node 501. The edge delivery node 501 then checks the bandwidth available to the client device 12 and sends the quality-optimized version of the requested content segment if there is enough bandwidth for the delivery, and otherwise sends the bandwidth-optimized version of the requested content segment. Here, saying that there is“enough” or“not enough” bandwidth available in the RAN 20 for delivery of the quality-optimized version to the client device 12 may constitute a simple threshold comparison by the edge delivery node 501. For example, any one or more of monitored delays or round-trip-times, monitored buffer levels, monitored congestion window sizes, or the like, may be compared to a corresponding“go” or“no-go” threshold. Taking monitored congestion level as a specific example, if the parameter or parameters monitored as an indication of RAN congestion exceed a threshold value or values corresponding to a congestion level deemed too high, then the edge delivery node 501 would conclude that there is not enough bandwidth to deliver the quality-optimized version of the requested content segment on a timely basis.

The edge delivery node 501, or the corresponding control node 30 introduced in Figure 1, is configured in one or more embodiments to intelligently manage its dual- version content storage. For example, in a video context, the size of a given content segment depends on the involved image complexity. That is, as a rule, simpler or more uniform video content encodes at a higher compression ratio than more complex video content. While the quality-optimized version of a content segment will in general be larger than the bandwidth-optimized version of the same content segment, the degree or extent of the size difference depends on the underlying complexity of the encoded video content. When image complexity is low, there may not be a significant difference in the sizes of the two versions.

At least one embodiment of the edge delivery node 501 includes processing circuitry that is configured to evaluate the size difference between quality-optimized and bandwidth-optimized versions of the same content segment, and keep only version if the size difference is less than a defined threshold value, e.g., ten percent. For example, the edge delivery node 501 retains only the quality-optimized version of the content segment. Of course, such retention decisions are made for each segment, thus, for a given content stream representation level, the edge delivery node 501 may store some content segments in dual version form and store others in single version form. The overall effect of such processing reduces the amount of memory or storage required to cache or buffer dual- version content at the edge delivery node 501.

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.