Generating and Utilizing Contextual Network Analytics

TECHNICAL FIELD

The present disclosure relates to data networks, and in particular, to systems, methods and apparatuses enabling network management based on contextual quality indicators.

BACKGROUND

The ongoing development of data networks includes improving access to media services and content offerings that emulate, enhance and/or replace services provided by other systems. For example, the surge in data-intensive video traffic signals both an enhancement of and a substitute for conventional broadcast cable access technologies. However, data-intensive traffic can strain existing network infrastructure and frustrate efforts to plan new infrastructure.

According to previously known network management practices a network is generally managed based on bandwidth utilization, with nominal levels of bandwidth allocated to client devices. Bandwidth allocations are often tied to a subscription tier model, where client devices in each tier receive a respective bandwidth allocation for a corresponding cost. Known quality of service (QoS) metrics for such methods are merely based on assessing whether client devices are provided with data throughput levels associated with the subscription tiers. Known QoS metrics do not provide any indication about the perceptual quality or the continuity with which media content is consumed at a client device for a particular subscription tier.

In networks that permit adaptive bit rate (ABR) streaming, metrics such as bandwidth utilization no longer provide meaningful information to network operators. ABR-enabled client devices operate to consume excess bandwidth irrespective of any noticeable gains in the perceptual quality for the ABR-enabled client devices. As such, while bandwidth utilization is often high, it fails to provide an accurate indication of the network capacity to deliver data-intensive traffic at acceptable perceptual quality levels to various subscribers.

In other words, network operators are blind to client-side experience conditions, despite being able to manage bandwidth allocations. As a result, network operators cannot adequately monitor and manage existing network infrastructure, adequately plan new infrastructure deployments, or adequately constrain the operation of ABR-enabled client devices that share network infrastructure resources in order to manage perceptual quality.

BRIEF DESCRIPTION OF THE DRAWINGS

So that the present disclosure can be understood by those of ordinary skill in the art, a more detailed description may be had by reference to aspects of some illustrative implementations, some of which are shown in the accompanying drawings.

FIG. 1A is a block diagram of a data communication environment in accordance with some implementations.

FIG. 1B is a data flow diagram associated with methods of generating contextual quality indicator values in accordance with some implementations.

FIG. 2 is a block diagram of a data link congestion model in accordance with some implementations.

FIG. 3 is a block diagram of an example of a client device in accordance with some implementations.

FIG. 4 is a block diagram of an example of a content server system in accordance with some implementations.

FIG. 5 is a flowchart representation of a method of generating contextual quality indicator values in accordance with some implementations.

FIG. 6 is a flowchart representation of a method of determining network performance characterization values in accordance with some implementations.

FIG. 7 is a flowchart representation of a method of generating shared-resource traffic quality indicator values in accordance with some implementations.

FIG. 8 is a flowchart representation of a method of admission control utilizing contextual quality indicators in accordance with some implementations.

FIG. 9 is a flowchart representation of a method of network management utilizing contextual quality indicators in accordance with some implementations.

FIG. 10 is a block diagram of an example of a network resource management system in accordance with some implementations.

In accordance with common practice various features shown in the drawings may not be drawn to scale, as the dimensions of various features may be arbitrarily expanded or reduced for clarity. Moreover, the drawings may not depict all of the aspects and/or variants of a given system, method or apparatus admitted by the specification. Finally, like reference numerals are used to denote like features throughout the figures.

DESCRIPTION

Numerous details are described herein in order to provide a thorough understanding of the illustrative implementations shown in the accompanying drawings. However, the accompanying drawings merely show some example aspects of the present disclosure and are therefore not to be considered limiting. Those of ordinary skill in the art will appreciate from the present disclosure that other effective aspects and/or variants do not include all of the specific details of the example implementations described herein. Moreover, well-known systems, methods, components, devices and circuits have not been described in exhaustive detail so as not to obscure more pertinent aspects of the description herein.

OVERVIEW

Previously available network management metrics fail to provide an indication of the capacity of a network to deliver data-intensive traffic at various perceptual quality levels. These metrics also fail to enable network management methods that utilize client-side network performance measures associated with the use of delivered media content data. By contrast, various implementations disclosed herein include systems, methods and apparatuses that generate one or more shared-resource traffic quality indicator values. Each shared-resource traffic quality indicator value characterizes at least a portion of a network by assessing network performance characterization values in relation to one or more capacity values of one or more shared network resources (e.g., bandwidth, processor time, memory, etc.). Each network performance characterization value provides a corresponding quantitative characterization of factors influencing quality of experience associated with the use of media content data received by a respective client device. In some implementations, quality of experience is characterized by at least one of a quantitative indication of the quality of media content data (e.g., peak-signal-to-noise ratio, mean opinion score, video quality metric, an encoding rate or the like) and an indication of the continuity with which media content data is used by a respective client device associated with a particular subscription tier. In some implementations, the continuity with which media content data is used refers to how fluidly streaming data is presented to the user. Fluidity can be adversely affected when a playout buffer in a client device does not receive new data at least as fast as data is being taken from the playout buffer. In other words, the playout buffer is underrun and presentation of streaming data may pause as the playout buffer is replenished.

FIG. 1A is a block diagram of a data communication environment 100 in accordance with some implementations. While pertinent features are shown, those of ordinary skill in the art will appreciate from the present disclosure that various other features have not been illustrated for the sake of brevity and so as not to obscure more pertinent aspects of the example implementations disclosed herein. To that end, as a non-limiting example, the data communication environment 100 includes a public network 120 (e.g., a portion of the Internet), a system operator core network 140 (hereinafter “core network 140”), a content server 110, a cache server 130, and headend nodes 150, 160, 170. The data communication environment 100 also includes subscriber gateway devices 181, 182, 183, 184, 185 and a number of client devices 191, 192, 193a, 193b, 194, 195, 196, 197.

In some implementations, the core network 140 includes a private and/or subscription-based network. The core network 140 includes any LAN and/or WAN, such as an intranet, an extranet, a virtual private network, and/or portions of the Internet. In some implementations, the core network 140 provides communication capability between any one of the client devices 191, 192, 193a, 193b, 194, 195, 196, 197 and one or more third party service providers and/or content providers (e.g., content server 110, cache server 130, etc.). In some implementations, the core network 140 provides communication capability between any one of the client devices 191, 192, 193a, 193b, 194, 195, 196, 197 and one or more private content servers, storage devices, gateways and/or service servers (not shown), as well as core network provided services and content. In some implementations, the core network 140 uses HyperText Transport Protocol (HTTP) to transport information using the Transmission Control Protocol/Internet Protocol (TCP/IP). HTTP permits client devices to access various resources available via the core network 140 and/or the public network 120. However, implementations are not limited to the use of any particular protocol. One having ordinary skill in the art should understand that other networks distributing multimedia (e.g., video, graphics, audio, and/or data, or otherwise referred to also herein individually or collectively as media content or simply, content) may also benefit from certain embodiments of adaptive streaming systems and methods, and hence, are contemplated to be within the scope of the disclosure. The term “resource” in this specification refers to information, devices, infrastructure, and services. A resource includes, for example, bandwidth, processor time, data storage, data structures, non-transitory memory, images, video streams, network transactions, and computational objects. In various implementations, the core network 140 includes a combination of computing devices, switches, routers, server systems, enterprise memory, and data connections.

As shown in FIG. 1A, in some implementations, the core network 140 includes a gateway node 141 that provides an interface for data communication external to the core network 140 (e.g., to the public network 120, the content server 110, the cache server 130, etc.). In some implementations, the gateway node 141 is provided as a single entity (e.g., a server, a virtual machine, etc.). In some implementations, the gateway node 141 is implemented as a distributed system including a suitable combination of software, data structures, virtual machines, computing devices, servers, switches and routers. For the sake of brevity and convenience of explanation, the gateway node 141 is described herein as a single entity.

The core network 140 also includes a network administration node 142 or the like, which is arranged to monitor and/or manage headend nodes. Similar to the gateway node 141, the network administration node 142 is illustrated as single entity (e.g., a server, virtual machine, etc.) in FIG. 1A. In various implementations, however, the network administration node 142 is provided as a distributed system including a suitable combination of software, data structures, virtual machines, computing devices, servers, switches and routers. Merely for the sake of brevity and convenience of explanation, the network administration node 142 is described herein as a single entity.

In some implementations, the network administration node 142 includes at least one of an analytics module 143 and a resource management module 144. As described below with reference to FIGS. 5-7, the analytics module 143 is provided to generate one or more shared-resource traffic quality indicator values. As described below with reference to FIGS. 8 and 9, the resource management module 144 is configured to determine whether a portion of a network has capacity to deliver data-intensive traffic at various perceptual quality levels (i.e., quality-based network capacity). In some implementations, the resource management module 144 is configured to use one or more shared-resource traffic quality indicator values in order to determine quality-based network capacity. The analytics module 143 and the resource management module 144 are not limited to implementation in or proximate to the network administration node 142. In various implementations, modules similar to one or both are included in headend nodes or other bottleneck points. For example, in some implementations, modules similar to one or both are included in one or more of a mobile network, a mobile packet core, a WiF access point, a cable modem and a residential gateway device.

Each headend node 150, 160, 170 is coupled to the network administration node 142 and/or one or more other portions of the core network 140. In some implementations, the headend nodes 150, 160, 170 are capable of data communication using the public network 120 and/or other private networks (not shown). Those of ordinary skill in the art will appreciate that a headend node is typically configured to deliver cable TV, cable modem services and/or various other data services to subscriber client devices. To that end, a headend node includes a suitable combination of software, data structures, virtual machines, routers, switches and high-availability servers. For example, the headend node 150 includes a cable modem termination server (CMTS) 151 that is used to service an allocation of bandwidth shared by a number of client devices. The CMTS 151 includes a suitable combination of hardware, software and firmware for terminating one or more data channels associated with a number of client devices within the shared allocation of bandwidth. In some implementations, the headend node 150 includes at least one of an analytics module 153 and a resource management module (RMM) 154. As described below with reference to FIG. 2, the analytics module 153 is configured to generate one or more shared-resource traffic quality indicator values associated with the traffic on bandwidth available through and managed by the headend node 150. In some implementations, the resource management module 154 is configured to determine whether a portion of the network has capacity to deliver data-intensive traffic at various perceptual quality levels to client devices sharing bandwidth (or other resources) available through the headend node 150. Further, while the analytics module 153 and the resource management module 154 are shown as distinct modules, in some implementations, some or all of the functions of each are incorporated into a CMTS or the like. Similar to the headend node 150, the headend node 160 includes a CMTS 161, an analytics module 163 and a resource management module (RMM) 164; and, the headend node 170 includes a CMTS 171, an analytics module 173 and a resource management module (RMM) 174.

Client devices access network resources, services and content offerings from a respective headend node through subscriber gateway devices. For example, as shown in FIG. 1A, the subscriber gateway devices 181, 182, 183 are coupled to the headend node 150, and thus share bandwidth (and/or other resources) provided by the headend node 150. Similarly, the subscriber gateway device 184 is coupled to the headend node 160, and the subscriber gateway device 185 is coupled to the headend node 170. In various implementations, a subscriber gateway device includes, without limitation, devices such as cable modems (CM), wireless access points, and Ethernet modems.

Each subscriber gateway device 181, 182, 183, 184, 185 is accessible by and services a number of client devices. For example, the client device 191 is coupled to the subscriber gateway device 181, the client device 195 is coupled to the subscriber gateway device 183, the client device 196 is coupled to the subscriber gateway device 184, and the client device 197 is coupled to the subscriber gateway device 185. The subscriber gateway device 182 delivers service and/or content to PC 192, smartphone 194, and an IP set-top box (STB) 193a, which in turn is coupled to TV 193b. So the bandwidth allocated to the subscriber gateway device 182 is shared by three devices in the example shown. The bandwidth allocated to the subscriber gateway device 182 is also a portion of the available bandwidth provided by the headend node 150. The headend node 150 also provides bandwidth allocations to the subscriber gateway devices 181, 183, which service respective client devices 191, 195. Thus, in this example, the total bandwidth available from the headend node 150 is ultimately shared by five client devices 191, 192, 193a/b, 194 and 195. Those of ordinary skill in the art will appreciate from the present disclosure that, in various implementations, a headend node can be connected to any number and combination of gateway nodes and client devices, and FIG. 1A is merely an example provided to discuss aspects of various implementations.

Referring again to FIG. 1A, the content server 110 is configured to store and provide media content data. To that end, the content server 110 typically includes a non-transitory memory 111, a processor 115, an input-output (I/O) interface 116, and a network interface 117. The network interface 117 is configured to enable communication with other devices and systems, and for example, without limitation includes a modulator/demodulator (modem for communication with another device, system, or network), a radio frequency transceiver or another type of transceiver, a telephone interface, a bridge, a router, etc. In some implementations, the I/O interface 116 includes input devices, such as but not limited to, a keyboard, mouse, scanner, microphone, etc. The I/O interface 116 may also include output devices, such but not limited to, a display, speakers, etc.

FIG. 4 is a block diagram of an example implementation of the content server system 110 of FIG. 1A in accordance with some implementations. While certain specific features are illustrated, those skilled in the art will appreciate from the present disclosure that various other features have not been illustrated for the sake of brevity, and so as not to obscure more pertinent aspects of the implementations disclosed herein. To that end, as a non-limiting example, in some implementations the content server system 110 includes one or more processing units (CPU's) 115, a network interface 117, a memory 111, and a local I/O interface 116. The memory 111 includes an operating system 410, which includes implementations of procedures for handling various basic system services and for performing hardware dependent tasks.

With reference to FIGS. 1A and 4, the memory 111 includes instructions 112 (421 in FIG. 4), a manifest 113 and encoded media content data 114. With reference to FIG. 1A, in some implementations, the instructions 112 enable the selection of one or more encoding rate representations and/or one or more temporal segments of a media content data item in response to a request from a client device. With reference to FIG. 4, in some implementations the content server 110 also includes a segment selection module 420. The segment selection module 420 includes instructions 421 and heuristics and metadata 421. In some implementations, the instructions 421 in combination with the heuristics and metadata 421 enable the selection of one or more encoding rate representations and/or one or more temporal segments of a media content data item in response to a request from a client device. In some implementations, the encoded media content data 114 includes multiple representations of each of one or more media content data items. For example, as shown in FIG. 4, the encoded media content data 114 includes data representing two movies, namely Movie A and Movie B, as example media content data items. Those of ordinary skill in the art will appreciate that various other types of media content data include without limitation sports video, newscasts, music and concert videos, and various other types of TV programs, audio files and video games. The encoded content 114 includes multiple representations 431-1, 431-2, . . . , 431-n of Movie A, that are each encoded at a different bit rate than the other representations. Similarly, one of many representations of Movie B, indicated by 432-1, is also illustrated in furtherance of the example. In some implementations, a representation of a media content data item is divided into one or temporal segments. In some implementations, the manifest 113 includes metadata associated with each of the encoding rate representations and/or the temporal segments of the one or more media content data items. For example, the manifest includes at least one of a respective encoding rate indicator, a quality level indicator, and a duration indicator for each representation of the one or more media content data items. In some implementations, a quality level indicator is explicitly indicated (e.g., as opposed to being inferred from bit rate), with the explicit indication corresponding to a perceptual playback quality metric such as mean square error (MSE), peak signal-to-noise ratio (PSNR), mean opinion score (MOS), relative degradation, or other well-known quality metrics.

The cache server 130 is configured to provide replicas of at least some of the media content data and associated metadata stored and provided by the content server 110. In various implementations, the cache server 130 is similarly configured to the content server 110, and includes, without limitation, a processor 135, a non-transitory memory 131, a network interface 137, and I/O interface 136. In some implementations, a request for media content data item from a client device is initially directed to or redirected to the cache server 130, when the cache server 130 is closer to the client device than the content server 100. The cache server 130 can also be used to supplement the content server 110 during time of excessive traffic.

Although FIG. 1A illustrates a number of discrete elements, FIG. 1A is intended to highlight various aspects of a network rather than to serve as a schematic strictly indicative of various network implementations. Thus, in various implementations, a network includes a subset or superset of the elements illustrated in FIG. 1A. As such, a combination of elements could be implemented by a single element and some singular elements could be implemented by one or more elements. The number of elements and how various features and functions are allocated can vary between implementations, and may depend in part on the amount of traffic a network is configured to handle during various usage periods (e.g., peak, average, low, etc.).

In operation, various encoding rate representations of media content data items can be provided to client devices (e.g., client device 191) in a number of ways. For example, in ABR-enabled systems, a media content item (e.g., a particular movie, sportscast, etc.) is typically sub-divided into temporal segments (e.g., 2-10 seconds long) that are each encoded at respective bit rates. To that end, multiple representations of each segment are stored and made available by the content server 110 to client devices. The encoding bit rate of each segment representation at least in part characterizes the perceptual quality of the segment representation. Since each representation of a segment is encoded at a different bit rate, each representation has a different amount of data, and thus uses a different combination of bandwidth and time for transmission. Additionally, a variety of storage structures can be used for ABR media content data, such as directories with individual files for each segment, standardized file formats, and/or custom packaging schemes. In some implementations, the structure of the media content data, along with associated metadata associated with each segment, is contained in a separate structure, referred to as a manifest (e.g., manifest data 113 in FIGS. 1 and 4).

An ABR-enabled client device selects and transmits a request (e.g., a HTTP GET command) for a specific representation of a segment from the content server 110. The selection decision is based on various parameters including the bandwidth allocated to the client device and the amount of data currently residing in a playout buffer of the client device. In accordance with previously known ABR client device methods, there is a general bias towards enabling a client device to consume as much bandwidth as is available to the client device. As a result, an ABR-enabled client device typically operates to select representations of segments with high encoding rates so that the client device consumes the bandwidth allocated to it based on an associated subscription tier. The typical ABR-enabled client device is also biased towards consuming bandwidth in excess of the allocation provided under the associated subscription tier.

Such previously known ABR methods are provided to increase utilization of bandwidth and/or other resources. A drawback of these methods is that they do not consider or determine whether actual quality of experience improvements, if any, achieved by an ABR-enabled client device justify the bias towards consuming available bandwidth. For example, a client device may select a 10 Mbps representation of a video stream segment over a 6 Mbps representation of the same video stream segment. However, depending on the content of the video stream segment (e.g., a movie scene with fast moving action versus a scene with mainly dialogue and little movement), the end user may not perceive an appreciable difference in playback quality. Without such an appreciable difference, the additional 4 Mbps bandwidth (or equivalently time) used to receive the 10 Mbps segment representation is misused, and could be utilized more productively. The cumulative impact on a link with a number of ABR-enable clients creates a management blind-spot for network operators attempting to determine the actual capacity of a link to handle data-intensive traffic at various perceptual quality levels.

FIG. 1B is a data flow diagram associated with FIG. 1A in accordance with some implementations. As described in greater detail below, FIG. 1B illustrates the origination and/or flow of perception metrics {p_i} and/or network performance characterization values {NPC(t_i, c_i, x_i)} from client devices 191, 192, 193a/b, 194 and 195 through to components of the headend node 150. In some implementations, the headend node 150, as described below with reference to FIG. 10, includes an analytics module 1040. The analytics module 1040 includes a network performance characterization (NPC) module 1041 and a shared-resource traffic quality indicator (STQ) module 1046, which are also described in greater detail below.

FIG. 2 is a block diagram of a data link congestion model 200 that illustrates the issues described above. The data link congestion model 200 shown in FIG. 2 is similar to an adapted from the data communication environment 100 provided in FIG. 1A. Elements common to FIGS. 1 and 2 include common reference numbers, and only the differences between FIGS. 1 and 2 are described herein for the sake of brevity. To that end, the congestion model 200 includes a link 250 providing a shared allocation of bandwidth between the gateway node 141 and headend node 150. The headend node 150 is ultimately coupled to the five client devices 191, 192, 193a/b, 194 and 195 as illustrated in FIG. 1A. Thus, in this example and in FIG. 1A, the total bandwidth available through the headend node 150 on link 250 is ultimately shared by the five client devices 191, 192, 193a/b, 194 and 195.

The congestion model 200 in FIG. 2 also includes first and second media content data items 210, 220 stored at M video servers (not shown). The first media content data item 210 includes a first set of segment representations 211a,b,c, a second set of segment representations 212a,b,c, a third set of segment representations 213a,b,c, and a fourth set of segment representations 214a,b,c. The first set of segment representations 211a,b,c includes segment representations for a first temporal segment of the first media content data item 210. Similarly, the second, third and fourth sets of segment representations (212a,b,c, 213a,b,c, 214a,b,c) are for respective second, third and fourth temporal segments of the first media content data item 210. The second media content data item 220 includes a first set of segment representations 221aa,b,c, a second set of segment representations 222a,b,c, a third set of segment representations 223a,b,c, and a fourth set of segment representations 224a,b,c. The first, second, third and fourth sets of segment representations (221a,b,c, 222a,b,c, 223a,b,c, 224a,b,c) are for respective first, second, third and fourth temporal segments of the second media content data item 220.

In operation, the five client devices 191, 192, 193a/b, 194 and 195 are each able to select segment representations. In some implementations, a client device selects a temporal segment based on a respective portion of the bandwidth on link 250 allocated to the client device. For example, as shown in FIG. 2, the client device 191 selects segment representation 214a, corresponding to the highest encoding rate available for the fourth temporal segment of the first media content data item 210. The client device 194 selects segment representation 213b, corresponding to the middle encoding rate available for the third temporal segment of the first media content data item 210. And, the client device 195 selects segment representation 221c, corresponding to the middle encoding rate available for the third temporal segment of the second media content data item 220. Additionally, in ABR-enabled implementations, a client device is able to exceed the bandwidth allocated to it when other portions of the bandwidth on link 250 are underutilized, and thus select segment representations with higher encoding rates that are normally supported by the bandwidth nominally allocation to the client device.

Client devices generally include any suitable computing device, such as a computer, a laptop computer, a tablet device, a netbook, an internet kiosk, a personal digital assistant, a mobile phone, a smartphone, a gaming device, a computer server, etc. In some implementations, each client device includes one or more processors, one or more types of memory, a display and/or other user interface components such as a keyboard, a touch screen display, a mouse, a track-pad, a digital camera and/or any number of supplemental devices to add functionality. As an example, FIG. 3, a block diagram of a configuration of a client device 300 in accordance with some implementations. While pertinent features are illustrated, those of ordinary skill in the art will appreciate from the present disclosure that various other features have not been illustrated for the sake of brevity and so as not to obscure more pertinent aspects of the example implementations disclosed herein.

In some implementations, the client device includes a suitable combination of hardware, software and firmware configured to provide at least some of protocol processing, modulation, demodulation, data buffering, power control, routing, switching, clock recovery, amplification, decoding, and error control. In some implementations, at least a portion of the control module and at least a portion of the plurality of optical communication devices are provided on a first substrate. For example, the client device 300 includes a communication interface 302. In some implementations, the communication interface 302 is suitable for communication over, among others, an IP network, a coaxial cable network, an HFC network, and/or wireless network. The communication interface 302 is coupled to a demultiplexer (demux) 304. The demux 304 is configured to parse the metadata (e.g., in the packet header or in the manifest) of segment representations and the body or payload data of the same. Metadata includes, for example, timestamp information, packet identifiers, program numbers, quality level, and/or other information useful for decoding and utilizing a received segment representation. The segment data and metadata information is provided to a media engine 306 as explained further below.

Although client device 300 is described in the context of various internet video streaming implementations, such as IPTV and VoD, the client device 300 may comprise additional and/or different components in various other implementations. For instance, in some implementations, the client device 300 includes a tuner system (e.g., radio frequency tuning, not shown) coupled to communication interface 302. In some implementations, a tuner system includes one or more tuners for receiving transport streams received via communication interface 302. Additionally and/or alternatively, in some implementations, a demodulator is employed to demodulate the received carrier signal and the demux 304 is configured to parse the transport stream packets of one or more defined carrier frequencies.

As shown in FIG. 3, the demux 304 is coupled to a bus 305 and to media engine 306 (i.e. an audio/video (A/V) processing or decoding device). The media engine 306 includes decoding logic including, for example, at least one of an audio decoder 308 and a video decoder 310. The media engine 306 also includes buffer management functionality to facilitate a determination as to current buffer level within the client device 300. The media engine 306 is further coupled to bus 305 and to a media memory 312. The media memory 312 includes one or more buffers (e.g. playout buffers) for temporarily storing compressed and/or reconstructed pictures and/or audio frames. In some implementations, the buffers of media memory 312 and/or other buffers (e.g., network buffers) reside in other memory devices, or distributed among media memory 312 and memory 322.

In some implementations, the client device 300 includes additional components coupled to bus 305. For example, the client device 300 also includes a receiver 314 configured to receive user input. In some implementations, the client device 300 includes a processor 316 for executing and managing operations of the client device 300. In some implementations, the client device 300 includes a clock circuit 318 comprising phase and/or frequency locked-loop circuitry (or software, or combination of hardware and software) configured to synchronize clock information received in an audio, video, or A/V stream to facilitate decoding operations and to clock the output of reconstructed audiovisual content.

In some implementations, the client device 300 also includes a storage device 320 (and associated control logic) provided to temporarily store buffered content and/or to more permanently store recorded content. The memory 322 includes at least one of volatile and/or non-volatile memory, and is configured to store executable instructions or computer code associated with an operating system (O/S) 324, one or more applications 326 (e.g., an interactive programming guide (IPG) 328, a video-on-demand (VoD) app 330, a WatchTV app 332 (associated with broadcast network TV), HTTP logic 334, among other applications such as pay-per-view, music, personal video recording (PVR), driver software, etc. In some implementations, profile selection logic includes HTTP client functionality, and may generate requests for segment representation from a content server (e.g., content server 110).

The client device 300 may be further configured with display and output logic 336, as indicated above that may include graphics and video processing pipelines, among other circuitry to process the decoded pictures and associated audio and provide for presentation (e.g., display) on, or associated with, a display device or other media device. A communications port 338 (or ports) may further be included in the client device 300 for receiving information from and transmitting information to other devices. For instance, communication port 338 may feature USB (Universal Serial Bus), Ethernet, IEEE-1394, serial, and/or parallel ports, etc. In addition, communications port 338 may be configured for home networks (e.g., HPNA/MoCA, etc.). The client device 300 may also include an analog video input port for receiving analog video signals.

FIG. 5 is a flowchart representation of a method 500 of generating contextual quality indicator values for at least a portion of a network according to some implementations. In some implementations, the method 500 is performed by an analytics module associated with a network administration node (e.g., network administration node 142) and/or a resource bottleneck node (e.g., headend node 150, gateway 182, etc.). Briefly, the method 500 includes determining network performance characterization values for client devices sharing a network resource, and using the determined network performance characterization values to generate one or more shared-resource traffic quality indicators. In some implementations, the one or more shared-resource traffic quality indicators characterize the capacity of a network to deliver data-intensive traffic at various perceptual quality levels to a number of client devices.

To that end, as represented by block 5-1, the method 500 includes selecting at least a portion of a network within which to determine the plurality of network performance characterization values and generate the one or more shared-resource traffic quality indicator values. For example, with reference to FIG. 1A, the analytics module 143 selects portion of the network administered by the headend nodes 150 and 160, and excludes the portion administered by the headend node 170. In another example, the analytics module 153 selects the bandwidth provided through the headend node 150, and/or selects individually or in combination portions of bandwidth allocated to one or more client devices {c_i} through the respective gateway devices 181, 182, 183.

As represented by block 5-2, the method 500 includes selecting an observation window t_iduring which to determine the plurality of network performance characterization values and generate the one or more shared-resource traffic quality indicator values. As represented by block 5-3, the method 500 includes identifying one or more client devices {c_i}, that share a resource on the selected portion of the network, using one or more contextual indicator values x_i. In some implementations, a contextual indicator value xi includes geographic data (e.g., service-area groupings, distribution of infrastructure assets, etc.), content-type data (e.g., TV show identifiers, etc.) and subscriber data (e.g., income levels, usage data, etc.). For example, with reference to FIGS. 1A, 1B and 2, the analytics module 153 identifies the five client devices 191, 192, 193a/b, 194 and 195 that share bandwidth available through the headend node 150. In another example, the analytics module 153 identifies client devices 191, 193a/b, and 195 because each is receiving the same video stream during an observation window t_i.

As represented by block 5-4, the method 500 includes determining a number of network performance characterization values {NPC(t_i, c_i, x_i)} for the identified client devices {c_i}. For example, with reference to FIG. 1B, NPC values (i.e., NPC₁, NPC₂, NPC₃, NPC₄, NPC₅) are determined for the five client devices 191, 192, 193a/b, 194 and 195. In some implementations, a network performance characterization value NPC(t_i, c_i, x_i) provides a corresponding quantitative characterization of a quality of experience associated with the use of media content data on a respective client device c_i. In some implementations, quality of experience is characterized by at least one of an indication of the perceptual quality of media content data (e.g., using a peak-signal-to-noise ratio value, mean opinion score, video quality metric, or the like) and an indication of the continuity with which media content data is processed and played by a respective client device associated with a particular subscription tier. Each perception metric p_iquantitatively characterizes a factor that directly or indirectly impacts quality of experience associated with the use of media content data by a respective client device, including perceptual quality of the media content data and continuity with which media content data is used. As represented by block 5-4a, for example, determining a number of network performance characterization values {NPC(t_i, c_i, x_i)} includes requesting and receiving at least one perception metric p_ifrom at least some of the identified client devices {c_i}. For example, with reference to FIG. 1B, corresponding sets of perception metrics {p₁}, {p₂}, {p₃}, {p₄}, {p₅} are requested and received from the five client devices 191, 192, 193a/b, 194 and 195. Additionally and/or alternatively, receiving one or more perception metrics includes receiving the one or more perception metrics from one of a network device, an administration module and/or a non-transitory memory location. In another example, as represented by block 5-4b, determining a number of network performance characterization values {NPC(t_i, c_i, x_i)} includes generating one or more perception metrics {p_i} by monitoring network traffic. For example, in some implementations, an analytics module or the like inspects packets to and/or from the identified client devices {c_i} in order to generate one or more perception metrics {p_i}. As represented by block 5-4c, determining a number of network performance characterization values {NPC(t_i, c_i, x_i) } includes aggregating two or more perception metrics {p_i} in order to produce a corresponding network performance characterization value NPC(t_i, c_i, x_i). In some implementations, as an example, with reference to FIG. 1B, the corresponding NPC values are NPC₁, NPC₂, NPC₃, NPC₄, NPC₅requested and received from the five client devices 191, 192, 193a/b, 194 and 195. Additionally and/or alternatively, with further reference to FIG. 1B, the corresponding NPC values NPC₁, NPC₂, NPC₃, NPC₄, NPC₅are determined by the NPC module 1041 using corresponding sets of perception metrics {p₁}, {p₂}, {p₃}, {p₄}, {p₅} that are requested and received from the five client devices 191, 192, 193a/b, 194 and 195. A more detailed example of determining network performance characterization values is described below with reference to FIG. 6.

As represented by block 5-5, the method 500 includes generating one or more shared-resource traffic quality indicator values {STQ(t_i, NPC)} based on at least some of the network performance characterization values {NPC(t_i, c_i, x_i)}. Each shared-resource traffic quality indicator value characterizes a portion of a network by assessing network performance characterization values in relation to capacity values of one or more shared network resources (e.g., bandwidth, processor time, memory, etc.). Accordingly, as represented by block 5-5a, the method 500 includes selecting at least some of the network performance characterization values {NPC(t_i, c_i, x_i)}. That is, in some implementations generating the one or more shared-resource traffic quality indicator values includes using one or more contextual indicator values in order to select network performance characterization values. As represented by block 5-5b, the method 500 includes assessing the selected network performance characterization values with respect to capacity values of one or more shared network resources in order to generate the one or more shared-resource traffic quality indicator values, {STQ(t_i, NPC)}. For example, with reference to FIG. 1B, the STQ module 1047 is configured to determine at least one STQ value from the NPC values NPC₁, NPC₂, NPC₃, NPC₄, NPC₅, provided by the NPC module 1041. A more detailed example of generating shared-resource traffic quality indicator values is described below with reference to FIG. 7.

FIG. 6 is a flowchart representation of a method 600 of determining network performance characterization values {NPC(t_i, c_i, x_i)} according to some implementations. In some implementations, the method 600 is performed by an analytics module as described above with reference to FIG. 5. Briefly, the method 600 includes generating a corresponding network performance characterization value NPC(t_i, c_i, x_i) for a client device c_iusing one or more perception metrics {p_i} characterizing factors that impact the quality of experience associated with the use of media content data on the client device c_i. To that end, as represented by block 6-1, the method 600 includes selecting an observation window t_iduring which network performance characterization values {NPC(t_i, c_i, x_i)} are determined. As represented by block 6-2, the method 600 includes selecting at least a portion of a network. As represented by block 6-3, the method 600 includes selecting one or more client devices {c_i} that share a resource on the selected portion of the network based on one or more contextual indicator values x_i—as described above with reference to FIG. 5. As represented by block 6-4, the method 600 includes performing deep packet inspection of data packets sent to and/or from the selected client devices {c_i} in order to determine bandwidth utilization values associated with the client devices. Additionally and/or alternatively, the method 600 also includes requesting from client devices data associated with perceptual quality, such as for example, information about device capabilities, user playback preferences, playout buffer level indicators, etc.

As represented by block 6-5, the method 600 includes generating one or more perception metrics {p_i} for each client device from data gathered by deep packet inspection and/or from communication with the client devices. For example, in some implementations, a perception metric includes a relative performance indicator associated with a performance criterion. Performance criteria include, without limitation, playback preference level, playback capability, degradation tolerance, one or more degradation policies, buffer level criteria, and a bandwidth utilization criteria. In other words, a perception metric, associated with a respective client device, is also associated with at least one of playback preference level, playback capability, degradation tolerance, one or more degradation policies, a buffer level criterion, and a bandwidth utilization criterion associated with the respective client device. As an example, as represented by block 6-5a, generating a perception metric p_iincludes calculating a playback preference level indicator value. The playback preference level indicator value characterizes how closely a client device is able achieve a predetermined playback preference level based on current network conditions (e.g., resource allocations). In some implementations, the playback preference level indicator value is produced by a function of the ratio between a predetermined playback preference level for a client device and the actual playback level achieved by the client device based on the network conditions when the determination is made. In some implementations, as represented by block 6-5b, generating a perception metric p_iincludes calculating a playback capability indicator value. The playback capability indicator value characterizes utilization of the playback capabilities of a client device based on current network conditions. In some implementations, the playback capability indicator value is produced by a function of the utilization of the playback capability of the device based on the network conditions when the determination is made. For example, based on the network conditions, a client device may be restricted to playing back a video stream at 720p even though the client device is capable of playing back a video stream at 1080p. In some implementations, as represented by block 6-5c, generating a perception metric p_iincludes calculating a degradation tolerance indicator value, which characterizes the degradation of media content data as experienced at a client device. In some implementations, the degradation tolerance indicator value is produced by a function of the ratio between a predetermined degradation tolerance level and the actual degradation experienced at the client device. Similarly, in some implementations, as represented by block 6-5d, generating a perception metric p_iincludes calculating one or more degradation indicator values based on one or more degradation policies associated with a subscription tier model. Degradation polices define how perceptual quality of media content data playback is permitted to degrade for a client device in a particular subscription tier under various network conditions. In some implementations, as represented by block 6-5e, generating a perception metric p_iincludes obtaining a buffer level indicator value. The buffer level indicator value characterizes the utilization of a playout buffer in a client device. In some implementations, the buffer level indicator value provides an indication of the unavailable capacity or available capacity of the playout buffer. In some implementations, the buffer level indicator value approximates the time remaining before the playout buffer is empty. In some implementations, the buffer level indicator value provides at least one of an underflow indicator and overflow indicator. In some implementations, as represented by block 6-5f, generating a perception metric p_iincludes calculating a bandwidth utilization indicator value, which characterizes how much of the bandwidth a client device is using relative to a corresponding bandwidth allocation provided in accordance with a subscription tier.

As represented by block 6-6, the method 600 includes aggregating one or more perception metrics {p_i} in order to produce a network performance characterization value NPC(t_i, c_i, x_i) for a client device. For example, as represented by block 6-6a, in some implementations, aggregating includes generating a weighted combination (e.g., weighted sum, weighted average, etc.) of one or more perception metrics {p_i} associated with the client device. In another example, as represented by block 6-6b, in some implementations, aggregating includes generating a normalized combination (e.g., normalized sum, normalized average, etc.) of one or more perception metrics {p_i} associated with the client device.

FIG. 7 is a flowchart representation of a method 700 of generating one or more shared-resource traffic quality indicator values according to some implementations. In some implementations, the method 700 is performed by an analytics module as described above with reference to FIG. 5. Briefly, the method 700 includes generating one or more shared-resource traffic quality indicator values {STQ(t_i, NPC)} using a function of an aggregation of network performance characterization values NPC(t_i, c_i, x_i) and capacity values of one or more shared resources (e.g., bandwidth, processor time, memory, etc.). To that end, as represented by block 7-1, the method 700 includes selecting an observation window t_i. As represented by block 7-2, the method 700 includes obtaining a filter based on contextual indicator values x_i. In other words, one or more contextual indicator values x_iare used to create a selection filter, which is used to select one or more network performance characterization values NPC(t_i, c_i, x_i) associated with a shared resource. For example, as represented by block 7-2a, the method 700 includes retrieving contextual indicator values x_ifrom a non-transitory memory or computer readable medium. In some implementations, as represented by block 7-2b, the method 700 includes receiving contextual indicator values x_ifrom a module, system, or device. As represented by block 7-2c, the method 700 includes generating the selection filter from the contextual indicator values x_i. As represented by block 7-3, the method 700 includes using the selection filter to obtain network performance characterization values NPC(t_i, c_i, x_i). In some implementations, obtaining the network performance characterization values NPC(t_i, c_i, x_i) includes one of reading the values from a non-transitory memory or the like, receiving the values from module, system or device, and instructing one of a module, system or device to generate the values in response to a request.

As represented by block 7-4, the method 700 includes aggregating the selected network performance characterization values NPC(t_i, c_i, x_i) in order to produce one or more shared-resource traffic quality indicator values {STQ(t_i, NPC)}. For example, as represented by block, 7-4a, in some implementations, aggregating includes generating a weighted combination (e.g., weighted sum, weighted average, etc.) of the selected network performance characterization values NPC(t_i, c_i, x_i). In another example, as represented by block 7-4b, in some implementations, aggregating includes generating a normalized combination (e.g., normalized sum, normalized average, etc.) of the selected network performance characterization values NPC(t_i, c_i, x_i).

FIG. 8 is a flowchart representation of a method 800 of admission control utilizing contextual quality indicators in accordance with some implementations. In some implementations, the method 800 is performed by a resource management module associated with a network administration node or module (e.g., network administration node 142) and/or a resource bottleneck node (e.g., headend node 150, gateway 182, etc.). Briefly, the method 800 includes determining whether or not to grant an additional client device access to a shared network resource (e.g., bandwidth, processor time, memory, etc.) by evaluating the potential perceptual quality degradation that would be experienced by client devices that are currently using the shared network resource.

To that end, as represented by block 8-1, the method 800 includes selecting a shared network resource to evaluate. As represented by block 8-2, the method 800 includes identifying one or more client devices {c_i} that are currently utilizing the shared network resource. As represented by block 8-3, the method 800 includes generating a time distribution of network performance characterization values {NPC(t_i, c_i, x_i)} for the identified client devices {c_i}. In some implementations, the time distribution includes one or more statistics that characterize joint utilization of the shared network resource that are representative of predictive indicators. As represented by block 8-4, the method 800 includes obtaining subscriber policy limits or the like for the identified client devices {c_i}. In some implementations, subscriber policy limits include the various levels of service that define a subscription tier model. For example, service levels define priority tiers, data throughput ranges, data throughput floors and/or ceilings, and degradation policies associated with the subscription tier model. As represented by block 8-5, the method 800 includes generating a time distribution of one or more shared-resource traffic quality indicator values {STQ(t_i, NPC) } associated with the identified client devices (e.g., as described above with reference to FIG. 7), where each generated time distribution is representative of a predictive indicator.

As represented by block 8-6, the method 800 includes generating a degradation value using the subscriber policy limits and the previously generated time distributions. For example, in some implementations, a degradation value provides a criterion that defines an acceptable or unacceptable amount of degradation for the identified client devices {c_i} that are currently using the shared network resource. In another example, a degradation value defines a range of allowable degradation for one or more of the identified client devices {c_i} currently sharing the shared network resource. As represented by block 8-7, the method 800 includes modeling the addition of a new client device. That is, the method includes determining the impact on the identified client devices {c_i} of allowing a new client device to use a portion of the shared network resource. In some implementations, modeling includes determining the impact for a number of use cases in which the new client device is provided various allocation levels associated with various perceptual quality levels. Subsequently, as represented by block 8-9, the method 800 includes determining whether or not the identified client devices can tolerate the degradation caused by potentially allocating a portion of the shared network resource to the new client device. If the degradation value does not breach a criterion (“No” path from block 8-8), as represented by block 8-9, the method 800 includes allocating a portion of the shared network resource to the new client device (i.e., permitting admission). On the other hand, if the degradation value breaches a criterion (“Yes” path from block 8-8), the method 800 includes denying admission to the new client device so that the identified client devices {c_i} are not adversely impacted.

FIG. 9 is a flowchart representation of a method of network management utilizing contextual quality indicators in accordance with some implementations. In some implementations, the method 900 is performed by a resource management module associated with a network administration node (e.g., network administration node 142) and/or a resource bottleneck node (e.g., headend node 150, gateway 182, etc.). Briefly, the method 900 includes determining whether or not to reduce the number of client devices using a shared network resource by evaluating perceptual quality performance experienced by the client devices that are currently using the shared network resource.

To that end, as represented by block 9-1, the method 900 includes selecting a shared network resource to evaluate. As represented by block 9-2, the method 900 includes identifying one or more client devices {c_i} that are currently jointly using the shared network resource. As represented by block 9-3, the method 900 includes obtaining subscriber policy limits or the like for the identified client devices {c_i}. As represented by block 9-4, the method 900 includes identifies one or more priority tiers associated with the identified client devices {c_i}. In some implementations, the one or more priority tiers define which client devices and/or groups of client devices are superior and/or inferior to other client devices within a subscription tier model. In some implementations, the one or more priority tiers define relative performance degradation policies between client devices in the same or different tiers.

As represented by block 9-5, the method 900 includes obtaining one or more network performance characterization values {NPC(t_i, C_i, x_i)} for at least one identified priority tier. Additionally and/or alternatively, the method includes obtaining one or more shared-resource traffic quality indicator values {STQ(t_i, NPC)} associated with the identified client devices. As represented by block 9-6, the method 900 includes determining whether or not one of the network performance characterization values {NPC(t_i, c_i, x_i)} fails to satisfy a performance criterion. Additionally and/or alternatively, in some implementations, the method includes similarly evaluating one or more shared-resource traffic quality indicator values {STQ(t_i, NPC)} associated with the identified client devices.

If the network performance characterization values satisfy the performance criterion (“No” path from block 9-6), as represented by block 9-7, the method 900 includes permitting the identified client devices {c_i} continued access to the shared network resource. On the other hand, if one of the network performance characterization values {NPC(t_i, c₁, x_i)} fails to satisfy the performance criterion (“Yes” path from block 9-6), as represented by block 9-8, the method 900 includes disallowing or removing at least one of the identified client devices from continuing to use the shared network resource. In some implementations, the at least one client device that is subsequently denied service has the lowest relative priority as defined by the one or more priority tiers. In some implementations, the at least one client device that is subsequently denied service is selected on the basis of previous service ejections, so that client devices in the same priority tier are treated in manner that ensures a close association of performance penalties.

FIG. 10 is a block diagram of an example of a network resource management system 1000 in accordance with some implementations. While certain specific features are illustrated, those skilled in the art will appreciate from the present disclosure that various other features have not been illustrated for the sake of brevity, and so as not to obscure more pertinent aspects of the implementations disclosed herein. To that end, as a non-limiting example, in some implementations the network resource management system 1000 includes one or more processing units (CPU's) 1002, a network interface 1003, a memory 1010, a local I/O interface 1005, and one or more communication buses 1004 for interconnecting these and various other components.

In some implementations, the communication buses 1009 include circuitry that interconnects and controls communications between system components. The memory 1010 includes high-speed random access memory, such as DRAM, SRAM, DDR RAM or other random access solid state memory devices; and may include non-volatile memory, such as one or more magnetic disk storage devices, optical disk storage devices, flash memory devices, or other non-volatile solid state storage devices. The memory 1010 optionally includes one or more storage devices remotely located from the CPU(s) 1002. The memory 1010 comprises a non-transitory computer readable storage medium. Moreover, in some implementations, the memory 1010 or the non-transitory computer readable storage medium of the memory 1010 stores the following programs, modules and data structures, or a subset thereof including an optional operating system 1011, network resource data 1020, subscriber/user profile data 1030, an analytics module 1040, a resource management module 1050, and contextual data values 1060.

The operating system 1011 includes procedures for handling various basic system services and for performing hardware dependent tasks.

In some implementations, the network resource data 1020 includes data associated with one or more shared network resources (e.g., bandwidth, processor time, memory, etc.). For example, as shown in FIG. 10, in some implementations, the network resource data 1020 includes link capacity data 1021, processor capacity data 1022, and memory capacity data 1023. In some implementations, the subscriber/user profile data 1030 includes data associated with one or more subscribers and/or subscriber client devices 1031-a, 1031b, . . . , 1031-n. For example, as shown in FIG. 10, in some implementations, the subscriber/user profile data 1030 includes subscriber policy limits or the like for various client devices. In some implementations, subscriber policy limits include the various levels of service that define a subscription tier model. For example, service levels define priority tiers, data throughput ranges, data throughput floors or ceilings, and degradation policies associated with the subscription tier model. In some implementations, the contextual data values 1060 include geographic data (e.g., service-area groupings, distribution of infrastructure assets, etc.), content-type data (e.g., TV show identifiers, etc.) and subscriber data (e.g., income levels, usage data, etc.).

In some implementations, the analytics module 1040 is configured to generate contextual quality of experience metrics, such as network performance characterization values {NPC(t_i, c_i, x_i) } and shared-resource traffic quality indicator values {STQ(t_i, NPC) }. As shown in FIG. 10, the analytics module 1040 includes a network performance characterization (NPC) module 1041 and a shared-resource traffic quality indicator (STQ) module 1046.

The NPC module 1041 is configured to determine network performance characterization values {NPC(t_i, c_i, x_i)} for client devices {c_i} using one or more perception metrics {p_i} characterizing factors that impact the quality of experience associated with the use of media content data on each client device c_i. To that end, the NPC module 1041 includes a packet analysis module 1042, a perception metric module 1043, and an aggregation module 1045. In some implementations, the packet analysis module 1042 is configured to at least one of monitor network traffic to and/or from client devices {c_i} in order to generate perception metrics {p_i}, and request and receive at least one perception metric p_ifrom at least some of the identified client devices {c_i}. To that end, the packet analysis module 1042 include instructions 1042a. In some implementations, perception metric module 1043 is used to generate and/or store one or more perception metrics {p_i} for each of one or more client devices. For example, as shown in FIG. 10, the perception metric module 1043 include N perception metrics 1043-1a, 1043-1b, . . . , 1043-1n for a client device c_i. In some implementations, as described above with reference to FIG. 6, the aggregation module 1045 is configured to combine one or more perception metrics {p_i} in order to produce a corresponding network performance characterization value NPC(t_i, c_i, x_i). To that end, the aggregation module 1045 includes instructions 1045-a and heuristics and metadata 1045-b.

The STQ module 1046 is configured to generate shared-resource traffic quality indicator values {STQ(t_i, NPC)} using a function of an aggregation of network performance characterization values NPC(t_i, c_i, x_i) and capacity values of one or more shared resources (e.g., bandwidth, processor time, memory, etc.). To that end, the STQ module 1046 includes a filter module 1047, an aggregation module 1048, and an assessment module 1049. The filter module 1047 is configured to use one or more contextual indicator values xi in order to create a selection filter, and subsequently select one or more network performance characterization values {NPC(t_i, c_i, x_i) } associated with a shared resource. To that end, the filter module 1047 includes instructions 1047a and heuristics and metadata 1047b. The aggregation module 1048 is configured to generate a weighted combination (e.g., weighted sum, weighted average, etc.) of the selected network performance characterization values {NPC(t_i, c_i, x_i) }. To that end, the aggregation module 1048 includes instructions 1048a and heuristics and metadata 1048b. The assessment module 1049 is configured to assess aggregated network performance characterization values {NPC(t_i, c_i, x_i)} in relation to one or more capacity values of one or more shared network resources (e.g., bandwidth, processor time, memory, etc.) in order to produce shared-resource traffic quality indicator values {STQ(t_i, NPC)}. To that end, the assessment module 1049 includes instructions 1049a and heuristics and metadata 1049b.

In some implementations, the resource management module 1050 is configured to determine whether a portion of a network, such as a shared network resource, has capacity to deliver data-intensive traffic at various perceptual quality levels (i.e., quality-based network capacity). In some implementations, the resource management module 1050 is configured to use one or more shared-resource traffic quality indicator values in order to determine quality-based network capacity. Accordingly, the resource management module 1050 includes various heuristics and metadata 1053. In some implementations, the resource management module 1050 is configured to determine whether or not to grant an additional client device access to a shared network resource (e.g., bandwidth, processor time, memory, etc.) by evaluating the potential perceptual quality degradation that would be experienced by client devices that are currently using the shared network resource. To that end, the resource management module 1050 includes admission instructions 1051 that are executable by the CPU(s) 1002. In some implementations, the resource management module 1050 is configured to determine whether or not to reduce the number of client devices using a shared network resource by evaluating perceptual quality performance experienced by the client devices that are currently using the shared network resource. To that end, the resource management module 1050 includes de-admission instructions 1052 that are executable by the CPU(s) 1002.

In some implementations, a device and/or a circuit having one or more features described herein can be included in any number of communication devices. Such a device and/or a circuit can be implemented directly in the communication device, in a modular form as described herein, or in some combination thereof. In some embodiments, such a communication device can include, for example, a cellular phone, a smart-phone, a hand-held wireless device with or without phone functionality, a tablet, a router, a switch, an access point, a base station, a server, etc. That is, those skilled in the art will also appreciate from the present disclosure that in various implementations the network resource management system 1000 is included in various devices, such as a computer, a laptop computer, a tablet device, a netbook, an internet kiosk, a personal digital assistant, an optical modem, a base station, a repeater, a wireless router, a mobile phone, a smartphone, a gaming device, a computer server, or any other computing device. In various implementations, such devices include one or more processors, one or more types of memory, a display and/or other user interface components such as a keyboard, a touch screen display, a mouse, a track-pad, a digital camera and/or any number of supplemental devices to add functionality.

While various aspects of implementations within the scope of the appended claims are described above, it should be apparent that the various features of implementations described above may be embodied in a wide variety of forms and that any specific structure and/or function described above is merely illustrative. Based on the present disclosure one skilled in the art should appreciate that an aspect described herein may be implemented independently of any other aspects and that two or more of these aspects may be combined in various ways. For example, an apparatus may be implemented and/or a method may be practiced using any number of the aspects set forth herein. In addition, such an apparatus may be implemented and/or such a method may be practiced using other structure and/or functionality in addition to or other than one or more of the aspects set forth herein. In another example, various portions of the disclosed methods may be practiced and/or performed in various sequences and/or combinations, including simultaneously.

It will also be understood that, although the terms “first,” “second,” etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first contact could be termed a second contact, and, similarly, a second contact could be termed a first contact, which changing the meaning of the description, so long as all occurrences of the “first contact” are renamed consistently and all occurrences of the second contact are renamed consistently. The first contact and the second contact are both contacts, but they are not the same contact.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the claims. As used in the description of the embodiments and the appended claims, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that the term “and/or” as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

As used herein, the term “if” may be construed to mean “when” or “upon” or “in response to determining” or “in accordance with a determination” or “in response to detecting,” that a stated condition precedent is true, depending on the context. Similarly, the phrase “if it is determined [that a stated condition precedent is true]” or “if [a stated condition precedent is true]” or “when [a stated condition precedent is true]” may be construed to mean “upon determining” or “in response to determining” or “in accordance with a determination” or “upon detecting” or “in response to detecting” that the stated condition precedent is true, depending on the context.

Generating and Utilizing Contextual Network Analytics

Information

Publication Number

Date Filed

Date Published

Inventors

Original Assignees

CPC

International Classifications

Abstract

Description

Claims