Patent Description:
The disclosure describes managing network traffic, for example, by selecting optimal routes based on application requirements.

According to an aspect of the invention a method as defined in claim <NUM> is provided. Further, an apparatus according to claim <NUM> is provided, as well as a system according to claim <NUM>, and a non-transitory computer-readable storage medium according to claim <NUM>. Dependent claims provide preferred embodiments of the invention.

Some environments may present difficulties for network traffic. For example, a congested network may introduce delays in packet transmissions or may cause packets to be dropped. Further, an increasingly crowded wireless spectrum may cause interference that causes packets to be dropped. This may introduce undesirable network conditions, including latency or jitter that may affect usability. However, there are also increasingly varied media for packet transmission. A user device may have the option of receiving content via Ethernet connections, a local wireless network, a cellular network, a coaxial network, etc. The user experience may be improved and networks may be more effectively utilized by selecting routes from among multiple media or optimizing transmission across those media.

A minimum effective data rate may be determined for transmitting a content item. Based on that minimum data rate, a device may determine whether to transmit the content item via a given medium, select a different medium for transmission, or adjust transmission to compensate for unfavorable network conditions. A device may select a medium based on a method of ranking one or more routes from a content source to a user device. Further, a device may determine a data rate for transmission based on calculating an expected time of transmission that includes time spent performing retransmissions at a given data rate. Transmission adjustments, such as adjusting a modulation parameter based on application requirements, may be performed in response to application requirements, such as requirements for a minimum level of reliability or throughput.

This summary is not intended to identify critical or essential features of the disclosure, but merely to summarize certain features and variations thereof. Other details and features will be described in the sections that follow.

Some features herein are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings, in which like reference numerals refer to similar elements, and in which:.

According to some aspects described herein, systems and methods may manage network performance by efficiently managing transmissions across one or more media. One or more routing devices may determine options for transmitting a content item along a route, as well as application requirements for the content item. Based on the application requirements and network conditions, the one or more routing devices may determine optimal path, medium, and/or other parameters for transmission. In many instances, multiple wired and/or wireless routes may exist for transmitting a content item from a source to a destination. By modifying transmissions to routes based on considerations for latency, bandwidth, and/or interference, the device may optimize the user experience while minimizing negative impacts to the network.

<FIG> illustrates an example information distribution network in which one or more of the various features described herein may be implemented. The illustrated information distribution network is only one example of a network and is not intended to suggest any limitation as to the scope of use or functionality of the disclosure. The illustrated network should not be interpreted as having any dependency or requirement relating to any component or combination of components in an information distribution network.

A network <NUM> may be a telecommunications network, a Multi-Service Operator (MSO) network, a cable television (CATV) network, a cellular network, a wireless network, an optical fiber network, a coaxial cable network, a Hybrid Fiber-Coaxial (HFC) network, or any other type of information distribution network or combination of networks. For example, the network <NUM> may be a cellular broadband network communicating with multiple communications access points, such as a wireless communications tower <NUM>. In another example, the network <NUM> may be a coaxial system comprising a Cable Modem Termination System (CMTS) communicating with numerous gateway interface devices (e.g., a gateway <NUM> in an example home 102a). In another example, the network <NUM> may be a fiber-optic system comprising optical fibers extending from an Optical Line Terminal (OLT) to numerous Optical Network Terminals (ONTs) communicatively coupled with various gateway interface devices. In another example, the network <NUM> may be a Digital Subscriber Line (DSL) system that includes a local office <NUM> communicating with numerous gateway interface devices. In another example, the network <NUM> may be an HFC network in which Internet traffic is routed over both optical and coaxial communication paths to a gateway interface device in or near a user's home. Various aspects of the disclosure may operate on one or more of the networks described herein, or any other network architectures now known or later developed.

The network <NUM> may use a series of interconnected communication links <NUM> (e.g., coaxial cables, optical fibers, wireless links, etc.) to connect a premises <NUM> (e.g., a home or other user environment) to the local office <NUM>. The communication links <NUM> may include any wired communication links, wireless communication links, communications networks, or combinations thereof. For example, portions of the communication links <NUM> may be implemented with fiber-optic cable, while other portions of the communication links <NUM> may be implemented with coaxial cable. The communication links <NUM> may also include various communications components such as splitters, filters, amplifiers, wireless components, switches, routers, and/or other components for communicating data.

The local office <NUM> may include an interface <NUM>, which may be a computing device configured to manage communications between devices on the network of the communication links <NUM> and backend devices, such as a server. For example, the interface <NUM> may be a CMTS. The termination system may be as specified in a standard, such as, in an example of an HFC-type network, the Data Over Cable Service Interface Specification (DOCSIS) standard, published by Cable Television Laboratories, Inc. The termination system may be configured to transmit data over one or more downstream channels or frequencies to be received by various devices, such as modems in the premises <NUM>, and to receive upstream communications from those modems on one or more upstream frequencies.

The local office <NUM> may include one or more network interfaces <NUM> for communicating with one or more external networks <NUM>. The local office <NUM> may include a variety of servers that may be configured to perform various functions. The local office <NUM> may include a push server <NUM> for generating push notifications to deliver data, instructions, or both to devices that are configured to detect such notifications. The local office <NUM> may include a content server <NUM> configured to provide content (e.g., media content) to devices. The local office <NUM> may also include an application server <NUM>.

The gateway <NUM> may be any computing device for communicating with the modem <NUM> to allow one or more other devices in the example home 102a to communicate with the local office <NUM>, the one or more external networks <NUM>, and/or other devices communicatively coupled thereto. The gateway <NUM> may include local network interfaces to provide communication signals to client devices in or near the example home 102a, such as a television <NUM>, a set-top box <NUM>, a personal computer <NUM>, a laptop computer <NUM>, a wireless device <NUM> (e.g., a wireless laptop, a tablet computer, a mobile phone, a portable gaming device a vehicular computing system, a mobile computing system, a navigation system, an entertainment system in an automobile, marine vessel, aircraft, etc.), or any other device. In some instances, the gateway <NUM> may be a wireless router and/or hotspot, which may be configured to provide service to one household and/or other users.

<FIG> illustrates general hardware elements that can be used to implement any of the various computing devices, servers, encoders, caches, and/or software discussed herein. A device <NUM> may include a processor <NUM>, which may execute instructions of a computer program to perform any of the functions and steps described herein. The instructions may be stored in any type of computer-readable medium or memory to configure the operation of the processor <NUM>. For example, instructions may be stored in a Read-Only Memory (ROM) <NUM>, a Random Access Memory (RAM) <NUM>, a removable media <NUM>, such as a Universal Serial Bus (USB) drive, Compact Disk (CD) or Digital Versatile Disk (DVD), hard drive, and/or any other desired electronic storage medium. Instructions may also be stored in a hard drive <NUM>, which may be an internal or external hard drive.

The device <NUM> may include one or more output devices, such as a display <NUM> (e.g., an integrated or external display, monitor, and/or television), and may include a device controller <NUM>, such as a video processor. In some embodiments, the device <NUM> may include an input device <NUM>, such as a remote control, keyboard, mouse, touch screen, microphone, motion sensing input device, and/or any other input device.

The device <NUM> may also include one or more network interfaces, such as a network Input/Output (I/O) interface <NUM> to communicate with a network <NUM>. The network interface may be a wired interface, wireless interface, or a combination of the two. In some embodiments, the network I/O interface <NUM> may include a cable modem, and the network <NUM> may include the communication links <NUM> shown in <FIG>; the one or more external networks <NUM>; an in-home network; a provider's wireless, coaxial, fiber, or hybrid fiber/coaxial distribution system (e.g., a DOCSIS network); and/or any other desired network.

<FIG> illustrates an example device arrangement in a network upon which one or more methods described herein may operate. A management server <NUM> may comprise a computing device <NUM> which may be configured to manage downstream devices. For example, a management server <NUM> may be a load balancing server that analyzes and instructs downstream routing devices in order to effectively manage bandwidth. In some instances, the management server <NUM> may determine which content server <NUM> will service a request for a content item on a given route to a requesting device <NUM>. The management server <NUM> may receive a request to transmit a content item to the requesting device <NUM>. For example, a user on a requesting device <NUM> (e.g., a computer, set-top box, mobile device, etc.) may trigger a request for a content item (e.g., a movie, web page, song, data file, multiplayer gaming data, etc.) from a content server <NUM> and/or a management server <NUM>. In some instances, after receiving the request, the management server <NUM> may select a content server <NUM> and/or a route through devices <NUM>-<NUM> in order to efficiently deliver the content item. In other instances, a content server <NUM> may respond to the request directly. The management server may reside in the local office <NUM>, and/or on the external network <NUM>. Though <FIG> depicts an example device arrangement, numerous variations may be possible. For example, a management server <NUM> may sit downstream from the content server <NUM>, and/or additional routing devices may exist between a management server <NUM> and a content server <NUM>.

A content server <NUM> may hold content items for delivery to a requesting device <NUM>. In some instances, the content server <NUM> may store a copy of content delivery on demand. There may also be multiple content servers <NUM> in the network, each storing copies so that multiple requests for the same and/or differing content may be serviced faster. The content server <NUM> may receive a request for a content item. The content server <NUM>, in response to the request and/or an instruction from the management server <NUM>, may then transmit the content item to the requesting device <NUM> via the devices <NUM>-<NUM>. In some instances, the content server <NUM> may receive the request for the content item from the requesting device <NUM> and pass the request on to the management server <NUM> for the management server <NUM> to manage the delivery of the content item. The content server <NUM> may be a content server <NUM>, or may reside on the external network <NUM>.

A first routing device <NUM> may be an intermediary routing device between the content server <NUM> and the requesting device <NUM>. In some instances, additional intermediary routing devices, such as a second routing device <NUM>, may be downstream (i.e., closer to the requesting device <NUM>). The intermediary routing devices, collectively, are referred to herein as intermediary routing devices <NUM>. The intermediary routing devices may receive a content item at one device (such as from the content server <NUM> and at the first routing device <NUM>), pass the content item along internally (such as from the first routing device <NUM> and to the second routing device <NUM>), and then pass the content item on to the requesting device <NUM> (such as from the second routing device <NUM> and to the client gateway <NUM>). The routing devices that comprise the intermediary routing devices <NUM> may be programmed according to one or more methods described herein, either independently or collectively. In some instances, each routing device of the intermediary routing devices <NUM> may receive individual instructions. In other instances, a single set of instructions may be given for a plurality of routing devices in the intermediary routing devices <NUM>. The intermediary routing devices may exist on the external network <NUM>, in the local office <NUM>, and/or along the communication links <NUM>.

The client gateway <NUM> may bridge a local network with a larger provider-operated network. In some instances, the client gateway <NUM> may be a gateway <NUM> and/or an interface <NUM>. The client gateway may receive a request from a requesting device <NUM> and submit the request, using an external network connection, to a content server <NUM> or a management server <NUM>. In some instances, the client gateway <NUM> may pass the request along intermediary routing devices <NUM>. The client gateway <NUM> may also receive the content item from the external network and deliver it to the requesting device <NUM>. In some embodiments, there may be no client gateway <NUM>, and the requesting device <NUM> may interface directly with the external network. In other embodiments, the client gateway <NUM> may be contained in or may be attached to the requesting device <NUM>.

The requesting device <NUM> may be a device that initiates a request for a content item. The requesting device <NUM> may be a computing device <NUM>. The requesting device <NUM> may be a laptop computer, desktop computer, set top box, entertainment console, tablet, mobile device, server, workstation, and/or any device that may request content items from an upstream server. The requesting device <NUM> may initiate a request for a content item automatically or in response to input from a user. After initiating the request, the requesting device <NUM> may receive the requested content item from the content server <NUM>.

<FIG> shows an example environment with alternative routing paths upon which one or more methods described herein may operate. A content source <NUM> may serve as a source for content requested by and/or transmitted to a user device <NUM>. In some embodiments, a content source <NUM> may be a content server <NUM>, and/or a user device <NUM> may be a requesting device <NUM>. The content source <NUM> may connect to the user device <NUM> through one or more devices, such as an access point <NUM>. The access point <NUM> may be an intermediary routing device <NUM> or a client gateway <NUM>.

In other embodiments, <FIG> may depict a local network. A content source <NUM> may be a client gateway <NUM>, and the user device <NUM> may be a requesting device <NUM>. A request for a content item from a requesting device <NUM> may be passed through the client gateway <NUM>. The content source <NUM> may send a request to an external network to retrieve a content item from the external network, before passing the content item on from the content source <NUM> to the user device <NUM>. The content source <NUM> thus may be the source of the content item entering the local network, though it may obtain the content item from some other device in an external network. The access point <NUM> may be a routing device within the local network that may provide connections from the content source <NUM> to the user device <NUM>.

Multiple pathways may exist for routing content items from a content source <NUM> to the user device <NUM>. In some instances, traffic may pass through an intermediary device, such as the access point <NUM>. Different connection types (e.g., "media") may be used for routing traffic from the content source <NUM> to the access point <NUM>. For example, fiber optic connections, Ethernet connections, Multimedia over Coax Alliance (e.g., "MOCA") connections, and/or any other connection (including wireless connections) may be used to connect a content source <NUM> to an access point <NUM>.

The access point <NUM> may have further media for relaying content items from the content source <NUM> to the user device <NUM>. For example, the access point <NUM> may have a wireless network interface (WiFi), Ethernet connections, MOCA connections, and/or other connections to the user device <NUM>. In some instances, traffic received by the access point <NUM> via one medium may be output via another. For example, a content item received over an Ethernet connection may be output via a WiFi connection.

In some instances, content items transmitted from a content source <NUM> to a user device <NUM> may bypass an access point <NUM>. For example, a user device <NUM> may receive a content item via a WiFi connection to the content source <NUM>. In another example, the user device <NUM> may receive the content item from the content source <NUM> via a cellular network connection.

<FIG> presents only one of many possible device arrangements. For example, in many instances, multiple intermediary devices may exist, such as routing devices between the content source <NUM> and the access point <NUM> and/or routing devices within a cellular network connecting the content source <NUM> and the user device <NUM>. More or fewer connections may exist. For example, a cellular network may be used to connect the content source <NUM> to the access point <NUM>, and only an Ethernet connection may exist between the access point <NUM> and the user device <NUM>. In another example, many access points <NUM> may exist in parallel, offering alternative routes between the content source <NUM> and the user device <NUM>. While only one illustrated example is given, many such variations may be compatible with the systems and methods described herein.

<FIG> shows an example method for optimizing the transmission of a content item. A device (such as a content source <NUM>, access point <NUM>, user device <NUM>, or combination thereof) may determine a minimum data rate value for transmitting a content item, and perform further steps as required based on that determination. In some instances, the data rate value may comprise a Modulation and Coding Scheme (e.g., "MCS") value. The MCS value may correspond to a number of spatial streams, a modulation type, a coding method, and/or a transmission frequency range. This may have the advantage of meeting application requirements for transmission while minimizing the impact of transmission upon the network.

At step <NUM>, the device may receive a request to transmit a content item. The request may be a packet from a user device <NUM> requesting that the system supply a content item from a storage location (e.g., digital storage of a content source <NUM>). For example, the device may receive a data packet requesting that a video file be delivered to a network address corresponding to the user device <NUM>.

At step <NUM>, the device may determine the capabilities of one or more routing devices on the network. The device may first determine what media for transmission exist, what capabilities those media may have, or the capabilities of devices that make use of those media. For example, the device may determine that a content source <NUM> is connected via a <NUM> Gb/sec fiber optic connection and a <NUM> Mb/sec Ethernet connection to an access point <NUM>. The device may further determine that the access point <NUM> may be connected via an 800Mb/sec <NUM>. 11ac connection and a <NUM> Gb/sec Ethernet connection to a user device <NUM>. The device may also determine that the access point <NUM> may only be able to output a total of <NUM> Gb/sec from all combined outputs. In some instances, the device may determine capabilities for an aggregated a plurality of media. For example, the device may determine that a combination of an <NUM>. 11ac connection from a content source <NUM> to a user device <NUM> and an Ethernet connection from the content source <NUM> and the user device <NUM> may have an effective combined bandwidth of <NUM> Gb/sec. The device may determine any other applicable characteristics of such media or devices (e.g., transcoding ability, current bandwidth available, power draw, etc.).

At step <NUM>, the device may determine application requirements. In some instances, the device may determine application requirements by detecting a quality of service ("QoS") parameter for the content item (such as a QoS parameter associated with DSCP, <NUM>. The QoS parameter may indicate the requirements for transmitting the content item. For example, a QoS parameter may indicate that the content item should be transmitted with minimum latency. In another example, a QoS parameter may indicate that the content item should be transmitted using maximum bandwidth (e.g., maximum rate of transfer). The QoS parameter may indicate a combination of requirements. For example, the QoS parameter may indicate a maximum allowable latency for a content item and a minimum allowable bandwidth.

Application requirements may also be inferred for a content item. The device may use one or more properties of the content item to determine a type for the content item. One property may be a transmission or destination port for the content item. For example, the device may determine that the content item is directed at a particular User Datagram Protocol ("UDP") port that is associated with online gaming. In another example, the device may determine that the content item is directed at a particular Transmission Control Protocol ("TCP") port associated with VoIP traffic. The device, based on the type, may determine characteristics for transmission. For example, the device may associate a predetermined maximum latency and minimum bandwidth for a content item with a VoIP type. In another example, the device may associate another predetermined maximum latency and minimum bandwidth for a content item with a gaming type.

At step <NUM>, the device may determine a minimum data rate value for transmitting the content item. As data rates increase, a transmission may require more resources or spectrum in order to handle the transmission. Increased data rates may also raise packet error rates, requiring more retransmissions. For example, in a wireless transmission, a higher MCS value may require additional channels and/or antennas, which may also increase the chances of collisions. In wired networks, higher data rates may take up more available bandwidth, such as by requiring more spectrum or channels in a multiplexed environment. By determining the minimum data rate value for the transmission, the device may determine a value that meets the application requirements while minimizing potentially harmful effects to the medium for transmission and/or network.

At step <NUM>, the device may determine whether the minimum data rate value exceeds the capabilities for a default route on the network. Using a method known in the art or described herein, a route may be established for transmitting the content item. The device may have determined the capabilities of one or more media corresponding to the route in step <NUM>. If the minimum data rate value falls within the capabilities of the one or more media, then the one or more routing devices may be capable of transmitting the content item across the one or more media and the content item may be transmitted in step <NUM>. If the minimum data rate value exceeds capabilities, the device may check to see if an alternative medium for transmission is available in step <NUM>.

At step <NUM>, the device may transmit the content item using the minimum data rate value. For example, the device may transmit a VoIP transmission using a relatively small MCS value that reduces latency in an environment with frequent packet collisions while maintaining a minimum level of bandwidth necessary to maintain the VoIP transmission. In another example, a small MCS value may introduce latency due to the time to transmission, so the device may transmit with a larger MCS value. In some instances, a wireless transmission may only utilize a portion of a channel (such as a lower band in a dual-band channel) to transmit the data, which may have the advantage of reducing collisions. In some instances, the portion utilized may be a portion furthest from another channel being utilized by another device. For example, if the device is utilizing channel <NUM>, and another device is utilizing channel <NUM>, but no device is utilizing channel <NUM>, then the device may utilize the lower half of channel <NUM> in order to reduce the impact of collisions and/or crosstalk with communications on channel <NUM>. In another example, the device may only transmit in a portion of the frequency range for a channel to avoid interference.

At step <NUM>, the device may determine if other media for transmission are available. Though the default route may have been found incapable of handling the transmission in step <NUM>, some other medium for transmission may exist. For example, a virtual reality streaming video transmission may require 300Mb/sec for transmission. A default route may comprise a MOCA connection from the content source <NUM> to the access point <NUM>, and an Ethernet connection from the access point <NUM> to the user device <NUM>. However, the MOCA connection may only be capable of 250Mb/sec. In some instances, capabilities may be determined for a time window. For example, a capability for a MOCA connection may be determined every <NUM> minutes due to fluctuations in MOCA capabilities due to interference. Instead, the device may determine at step <NUM> that a wireless <NUM>. 11ad connection from the content source <NUM> to the user device <NUM> may exist, and may be capable of 500Mb/sec. The device may then proceed to route the content item through the better medium in step <NUM>. In other instances, no better medium may be available, so the device may attempt to adjust application requirements in step <NUM>.

At step <NUM>, the device may route using another medium. A preferred medium may be incapable of handling a transmission within requirements. For example, a MOCA connection may be preferred due to its relative stability as compared to wireless transmissions, but the wireless connection may have added bandwidth necessary to meet requirements. The device may then use the minimum data rate value determined in step <NUM>, and route the content item through the other medium in order to meet the application requirements.

At step <NUM>, the device may attempt to adjust application requirements for transmission. In some instances, no medium may be capable of handling the stated application requirements. For instance, no medium may have the bandwidth needed for application requirements corresponding to a high-definition video stream. In another instance, any route may introduce a delay that fails to meet application requirements corresponding to a video call. However, it may be possible to negotiate with an application to change application requirements. The device may communicate with the user device <NUM> and/or an application requesting the content item to change requirements. For example, the device may request that the video streaming quality be reduced. An application on the user device <NUM> may then instead request a standard definition video feed. Regardless of whether the requirements are adjusted, the device may transmit the content item according to its capability in step <NUM>.

At step <NUM>, the device may transmit the content item according to its capability. Whether or not requirements were adjusted, the device may attempt to deliver the content item to the user device <NUM> using the minimum data rate value determined in step <NUM>. This may result in impacted performance or user experience if application requirements are not being met. In some instances, an option may be presented to a user to delay or cancel transmission if requirements cannot be met.

<FIG> shows an example system for transmission management consistent with one or more methods described herein. Transmissions corresponding to different applications may be processed by one or more modules in order to determine optimal transmission characteristics. In some instances, these modules may be hardware and/or software layers operating on a wireless router <NUM>. For example, two applications, a first application <NUM> and a second application <NUM>, may wish to transmit data. The first application <NUM> may comprise a file download transmission, which requires that every packet be received reliably. The second transmission may comprise a UDP transmission with minimum speed requirements, such as a video call.

The system may comprise various modules for transmission management. Requirement determination module <NUM> may analyze packets to determine a course of action. The requirement determination module <NUM> may determine a course of action based on QOS parameters and/or an associated application for the transmission. For example, the requirement determination module <NUM> may determine that a transmission corresponds to the first application <NUM> or the second application <NUM> based on packet header information. Each application may have associated requirements. For example, file downloads associated with the first application <NUM> may require as few packets be dropped as possible. In another example, UDP transmissions associated with the second application <NUM> may require that a minimum throughput is reached, and that as few packets are dropped as possible after exceeding the minimum throughput.

A parameter selection module <NUM> may determine optimal parameters for the transmission based on requirements determined by the requirement determination module <NUM>. A reliability parameter may specify that high reliability for a transmission is preferred. For example, an MCS value may be selected that is slower, but more reliable, for the first application <NUM>. In another example, an MCS value may be selected that is faster, but less reliable, for the second application <NUM>. If a transmission aggregates packets, such as a packet for application <NUM> and a packet for application <NUM>, the most stringent requirements may be used. For example, if the first application requires an MCS value of <NUM> and the second application <NUM> requires an MCS value of <NUM>, an MCS value of <NUM> may be used for the aggregated transmission. These parameters may then be applied by a transmission characteristic configuration module <NUM>. For example, the transmission characteristic configuration module <NUM> may assign a header value indicating a desired MCS value for transmission. In another instance, the transmission characteristic configuration module <NUM> may configure one or more antennas on the wireless router <NUM> for transmitting the data associated with the first application or the second application.

After configuration, the transmission may be performed by the wireless router <NUM>. In some instances, the wireless router <NUM> may be an access point <NUM>. For example, the transmission may be made via a wireless transmission, which may be a multiple-input multiple-output transmission ("MIMO"), using the configured MCS value for associated antenna(s). In another example, the transmission may be made via a wired transmission, such as via transmission over MOCA or wired Ethernet.

<FIG> shows an example method for selecting a route for transmission of a content item. A device (such as a content source <NUM>, access point <NUM>, user device <NUM>, or combination thereof) may determine a particular route for transmitting a content item. Multiple, alternative media for transmitting a content item may exist within a network. By selecting the media most appropriate for the content item, network performance may be optimized.

At step <NUM>, the device may determine optimal transmission characteristics for the content item. In some instances, the device may detect a quality of service ("QoS") parameter for the content item (such as a QoS parameter associated with DSCP, <NUM>. The QoS parameter may indicate the requirements for transmitting the content item. For example, a QoS parameter may indicate that the content item should be transmitted with minimum latency. In another example, a QoS parameter may indicate that the content item should be transmitted using maximum bandwidth (e.g., maximum rate of transfer). The QoS parameter may indicate a combination of requirements. For example, the QoS parameter may indicate a maximum allowable latency for a content item and a minimum allowable bandwidth.

Application requirements may also be inferred for a content item. The device may use one or more properties of the content item to determine a type for the content item. One property may be a transmission and/or destination port for the content item. For example, the device may determine that the content item is directed at a particular UDP port that is associated with online gaming. In another example, the device may determine that the content item is directed at a particular TCP port associated with VoIP traffic. The device, based on the type, may determine characteristics for transmission. For example, the device may associate a predetermined maximum latency and minimum bandwidth for a content item with a VoIP type. In another example, the device may associate another predetermined maximum latency and minimum bandwidth for a content item with a gaming type.

At step <NUM>, the device may determine performance characteristics for each route. For example, a content source <NUM> may be connected to an access point <NUM> via a fiber optic connection and an Ethernet connection. The fiber optic connection may be capable of <NUM> Gb/sec, with a latency of <NUM>, the Ethernet connection may be capable of <NUM> GB/sec with a latency of <NUM>. The content source <NUM> may also be directly connected to a user device <NUM> via a MOCA connection with a bandwidth of 100MB/sec and a latency of <NUM>. The access point may be connected to the user device <NUM> via an Ethernet connection with a bandwidth of <NUM> Gb/sec and a latency of <NUM>.

At step <NUM>, the device may rank the routes based on their characteristics. Different combinations of media may be appropriate for different performance characteristics. For example, a gaming service may require <NUM> MB/s, but may want the lowest latency possible. The MOCA connection of 100MB/sec meets the bandwidth requirement while only having a latency of <NUM>. If the Ethernet connections were used, it would have a bandwidth of <NUM> GB/sec, but would have a total latency of <NUM>. The fiber optic connection may have an even higher latency of <NUM>. Thus, the device may rank the MOCA connection as the best route for the low bandwidth, low latency requirements of the gaming service.

In another example, a virtual-reality streaming video service may require a minimum <NUM> MB/sec of bandwidth and require a latency below <NUM>. The MOCA connection, with a bandwidth of 100MB/sec, may be insufficient for transmission. Thus, the device may rank the pure Ethernet connection, with <NUM> Gb/sec of bandwidth and a latency of <NUM>, first, and the fiber-Ethernet connection, with <NUM> Gb/sec of bandwidth and a latency of <NUM>, second.

Other factors may be considered in the ranking. For instance, some applications may be impacted by dropped packets. For example, a VoIP call may not allow for retransmissions, so dropped packets may degrade audio quality. A first route for a VoIP call may be a WiFi connection with high bandwidth and low latency, but frequently lost packets. A second route may be a MOCA connection with lower bandwidth, higher latency, but far fewer dropped packets relative to the WiFi connection. If the MOCA connection still meets the bandwidth and latency requirements for the VoIP call, the device may rank the MOCA connection higher because it has fewer lost packets. Therefore, packet loss may be one of many other factors considered in order to rank routes.

At step <NUM>, the device may select the desired route for transmission based on the ranking from step <NUM>. The route that is ranked as the best suited for transmission, based on the optimal transmission characteristics for the content item, may be selected for transmitting the content item in step <NUM>.

At step <NUM>, the device may transmit the content item via the selected route.

<FIG> shows an example method for determining the best link speed for transmitting a content item based at least in part on packet retransmissions. A device (such as a content source <NUM>, access point <NUM>, user device <NUM>, or combination thereof) may determine a data rate for transmitting a content item. Though a faster data rate for transmission may be available, a content item may require retransmission of some packets if they are lost in transmission. In many instances, such as transmission via a wireless protocol, increased data rates may result in increased retransmissions. These retransmissions may occupy transmission time and lower the effective transmission rate. Thus, in some instances, a higher effective transmission rate may be achieved by lowering the data rate below the highest possible data rate and also lowering the resultant number of retransmissions.

At step <NUM>, the device may determine application requirements. In some instances, the device may detect a QoS parameter for the content item (such as a QoS parameter associated with DSCP, <NUM>. The QoS parameter may indicate the requirements for transmitting the content item. For example, a QoS parameter may indicate that the content item should be transmitted with minimum latency. In another example, a QoS parameter may indicate that the content item should be transmitted using maximum bandwidth (e.g., maximum rate of transfer). The QoS parameter may indicate a combination of requirements. For example, the QoS parameter may indicate a maximum allowable latency for a content item and a minimum allowable bandwidth.

At step <NUM>, the device may adjust based on the protocol selected for transmission. Some protocols, such as TCP, may retransmit a packet that is lost in transmission. Thus, all packets lost may result in a retransmission. Other protocols, such as UDP, do not retransmit lost packets. The requirements for a transmission that requires a small number of dropped packets, but uses UDP, may be adjusted to compensate for the fact that all dropped packets are lost. This may require that any requirements for dropped packets be strictly enforced. If retransmissions are allowed, however, dropped packets may be acceptable so long as bandwidth exists for retransmission. For these instances, a requirement that packets not be dropped may be eliminated, and dropped packets may be instead later considered as they impact bandwidth requirements through retransmission.

At step <NUM>, the device may select a default data rate for the transmission. In some instances, the default link speed may be the fastest possible data rate. The default link speed may be determined based on hardware capabilities and/or the operating environment according to known methods.

At step <NUM>, the device may determine an expected number of retransmissions based on the default link speed. The expected number of retransmissions may be determined based on an expected number of retransmissions for a given speed and/or operating environment. In some instances, the expected number of retransmissions may be determined based on the number of retransmissions that have occurred at the selected data rate historically for the device. For example, the device may determine that 300Mb/sec transmissions have had a <NUM>% retransmission rate over the past <NUM> hours. In other instances, the expected number of retransmissions may be determined based on a table of values indicating the expected number of retransmissions based on the data rate and an interference level detected by the device on the medium for transmission. For example, a table may indicate that a <NUM> Mb/sec transmission with a <NUM> dB signal-to-noise ratio (SNR) has a <NUM>% retransmission rate.

At step <NUM>, the device may determine the expected time for transmission at the default (currently selected) data rate. The expected time for transmission may be a function of the inverse of the data rate plus the time taken to conduct retransmissions. One algorithm for calculating the time of transmission is as follows:
<MAT> wherein:
<MAT>
<MAT>
and Z =Total Time for Transmission.

At step <NUM>, the device may determine the expected number of retransmissions for the content item at a data rate lower than the currently selected rate. The device may determine a data rate at a step below the currently selected data rate (initially, the default data rate). For example, if the currently selected data rate is 300Mb/sec, the device may determine the expected number of retransmissions for a data rate of <NUM> Mb/sec. The amount lowered may be based on considerations for the efficiency of the algorithm (larger jumps may reduce iterations of the method) and transmission capabilities (only certain transmission speeds may be supported for transmission). The expected number of retransmissions may then be determined according to the method as described in step <NUM>.

At step <NUM>, the device may determine the time for transmission at the lower data rate. The expected time for transmission may be determined using an algorithm such as described in step <NUM>.

At step <NUM>, the device may determine if the lower data rate is more efficient than the selected data rate. Though the data rate is lower, the time for transmission may be shorter due to a reduced number of retransmissions. If this is the case, the device may proceed to determine if an even lower data rate would be faster at step <NUM>. If the lower data rate does take longer to transmit, the device may determine that the currently selected data rate is the relatively "best" data rate and transmit the content item at step <NUM>.

In some examples, the device may also determine if the lower data rate is better based on the application requirements. A lower data rate may have a longer expected time for transmission, but may require fewer retransmissions. If a protocol for a content item does not allow for retransmissions, and dropped packets are undesirable, the lower data rate may be better because it may cause fewer dropped packets. A minimum bandwidth may also be required for transmission, regardless of retransmissions. For example, streaming video may require high bandwidth and may not allow retransmissions, but may be tolerant of dropped packets. Thus, a higher data rate may be desired, even though it may produce a substantial number of dropped packets.

At step <NUM>, the device may select the lower data rate. Since the lower data rate was more efficient than the previously selected, faster data rate, the device may be able to assume that a data rate that is at least as slow as the lower data rate should be used. The device may then select the lower data rate as the new selected data rate, and repeat steps <NUM> through <NUM> against an even lower data rate to determine if the even lower data rate would be even more efficient than the lower data rate. Thus, the device may iteratively lower the data rate in steps <NUM> through <NUM> until the most efficient data rate is found.

At step <NUM>, the device may transmit the content item at the selected data rate. This may be the data rate determined to have the shortest expected time for transmission according to steps <NUM> through <NUM>.

The methods and features recited herein may be implemented through any number of computer readable media that are able to store computer readable instructions. Examples of computer readable media that may be used include RAM, ROM, Electrically Erasable Programmable Read-Only Memory (EEPROM), flash memory or other memory technology, CD-ROM, DVD, or other optical disk storage, magnetic cassettes, magnetic tape, magnetic storage, and the like.

Additionally or alternatively, in at least some embodiments, the methods and features recited herein may be implemented through one or more Integrated Circuits (ICs). An IC may, for example, be a microprocessor that accesses programming instructions or other data stored in a ROM. In some embodiments, a ROM may store program instructions that cause an IC to perform operations according to one or more of the methods described herein. In some embodiments, one or more of the methods described herein may be hardwired into an IC. For example, an IC may comprise an Application Specific Integrated Circuit (ASIC) having gates and/or other logic dedicated to the calculations and other operations described herein. In still other embodiments, an IC may perform some operations based on execution of programming instructions read from ROM or RAM, with other operations hardwired into gates or other logic. Further, an IC may be configured to output image data to a display buffer.

Claim 1:
A method for managing content transmission based on data rates, characterized by:
determining, by a computing device, based on a first data rate, and based on a first expected number of packet retransmissions at the first data rate, a first expected time of transmission of a content item;
determining, by the computing device, based on a second data rate that is lower than the first data rate, and based on a second expected number of packet retransmissions at the second data rate, a second expected time of transmission for the content item;
determining, by the computing device and based on a comparison of the first expected time and the second expected time, to transmit the content item at the second data rate; and
transmitting, by the computing device and based on the second data rate, the content item.