Method and system for changing a media session codec before handoff in a wireless network

Methods and systems for a wireless communication device (WCD) to change a media session codec prior to handoff to a new wireless coverage area are presented. In particular, a WCD is served by a first wireless coverage area of a RAN, and is conducting a media session using a first codec. The WCD detects that it is about to be handed off to a second wireless coverage area, and transmits a request to a server to determine the capacity available to the WCD via the second wireless coverage area. If this capacity is less than the capacity request by the first codec, the WCD proactively renegotiates the media session to use a second codec that requires less capacity. The server may take various factors into account when responding to the WCD's query, including the sector loading of the second wireless coverage area, available capacity at a backhaul link between the RAN and a network, and/or a profile of the WCD.

BACKGROUND

In a radio access network (RAN), a wireless communication device (WCD) is typically served by a wireless coverage area, and uses this wireless coverage area to communicate with other networked entities. Normally, a base transceiver station radiates to define one or more such wireless coverage areas. Thus, a RAN may support anywhere from one to dozens or more wireless coverage areas.

The WCD may move from location to location, and the radio characteristics of the air interface between the WCD and the base station may change. In response to these events, the WCD, the RAN, or both, may determine that the WCD would benefit from being assigned to a different wireless coverage area. The process in which the WCD switches from using one wireless coverage area to using another wireless coverage area is called a handoff.

Despite any efforts that the RAN may make to balance load between its wireless coverage areas, it is possible for the WCD to be handed off to a new wireless coverage area that has less capacity than the wireless coverage area to which WCD was previously assigned. This may have a deleterious impact on applications executing on the WCD, especially high bit rate, real time applications, such as interactive or streaming voice, audio, or video. Packets may be dropped, resulting in poor media quality and a frustrating user experience.

OVERVIEW

In order to accommodate the demand for wireless media applications while accounting for the limited capacity of wireless networks, new systems and methods for proactively changing media codecs prior to a handoff are presented.

When a WCD determines that it may be handed off to a new wireless coverage area while it is conducting an ongoing media session, the WCD may attempt to determine whether the capacity provided by the new wireless coverage is sufficient to support the capacity required by the media session. Accordingly, the embodiments herein may provide mechanisms through which the WCD can discover a representation of the new wireless coverage area's capacity. This representation may include measures of available capacity on one or more backhaul links connecting the new wireless coverage area to one or more networks. Since the actual capacity available to the WCD may depend upon both of these factors, it benefits the WCD, as well as other network entities, for the WCD to have an accurate view of the realizable capacity available via the new wireless coverage area and through the appropriate backhaul links.

However, it may also be beneficial to adjust this realizable capacity via the new wireless coverage area by policy considerations. Thus, for example, based on a priority associated with the WCD, a greater or lesser capacity may be reported to the WCD.

Accordingly, in a first embodiment, a WCD that is served by a first wireless coverage area conducts a media session with a remote host. The media session may be interactive or streaming media, such as video, audio, still images, voice, and so on. The WCD uses a first codec to encode and/or decode the media associated with the media session.

At some point in time, for instance upon determining that it is likely to be handed off to a second wireless coverage area, the WCD may transmit a request to a server. Preferably the request seeks to determine the capacity available to the WCD via the second wireless coverage area. This available capacity may be expressed in terms of a bitrate or may use some other metric. The WCD then receives, from the server, a response providing the requested available capacity.

The WCD subsequently determines that this available capacity is insufficient to support the ongoing media session. In response to this determination and prior to the handoff commencing, the WCD proactively renegotiates the parameters of the media session with the remote host to use a second codec. Preferably, the second codec's capacity requirements can be met by the capacity available to the WCD via second wireless coverage area.

A second embodiment is also directed to a system containing a RAN with a first wireless coverage area and a second wireless coverage area. Preferably, the RAN is coupled to a network (such as the Internet or a private network) via a router and a link. In this embodiment, a server receives sector loading information from the second wireless coverage. This sector loading information is indicative of capacity available to WCDs on the second wireless coverage area. The server may also receive, from a router connecting the RAN to a backhaul link, the available capacity of the backhaul link. Additionally, the server may receive, from a WCD being served by the first wireless coverage area, a request seeking to determine the available capacity via the second wireless coverage area. Based in part on the sector loading at the second wireless coverage area and the backhaul capacity of the link between the RAN and the network, the server determines an available capacity and transmits this determined available capacity to the WCD.

The server may have access to a profile that represents certain characteristics of the WCD, its user, or its applications. Accordingly, the server's determination of available capacity may also take into account some combination of information stored in the profile of the WCD. Of course, other information may be taken into account as well. Thus, the server may respond to the WCD's request with a representation of available capacity that is different from the actual capacity available to the WCD via the second wireless coverage area. In doing so, the operator of the RAN is afforded more options to flexibly manage the capacity of the RAN and any backhaul links between the RAN and other networks.

These and other aspects and advantages will become apparent to those of ordinary skill in the art by reading the following detailed description, with reference where appropriate to the accompanying drawings. Further, it should be understood that the foregoing overview is merely exemplary and is not intended to limit the scope of the invention as claimed.

DESCRIPTION

In accordance with exemplary embodiments, systems and methods for proactively renegotiating a media codec for an ongoing media session are presented. Preferably, a WCD detects an upcoming handoff to a new wireless coverage area and requests, from a server, the capacity available to the WCD via the new wireless coverage area. The WCD receives a response from the server with this available capacity. Then, the WCD renegotiates a new media codec before the handoff occurs, where the capacity requirements of the new media codec are met by the available capacity as returned by the server. The server may take various factors into account when determining the available capacity of the second wireless coverage area.

I. SYSTEM ARCHITECTURE

FIG. 1depicts an exemplary communication system100. In communication system100, a RAN105includes wireless coverage areas112,114,116and base transceiver stations (BTSs)120,122. One or both of these BTSs may radiate to define wireless coverage areas112,114,116. For instance, BTS120may radiate to define a wireless coverage area112, while BTS122radiates to define wireless coverage areas114,116.

For purposes of illustration, only two BTSs and three wireless coverage areas are shown. However, as few as one BTS radiating to define one wireless coverage area, or hundreds of BTSs radiating to define thousands of wireless coverage areas may be supported. Furthermore, each BTS may be communicatively coupled to one or more radio network controllers or base station controllers (not shown), that, among other things, manage the wireless resources associated with each BTS, and route traffic to and from each BTS. Alternatively, a radio network controller or base station controller may be integrated into or combined with BTS120and/or BTS122. Regardless, BTSs120,122may be communicatively coupled to network150via router135and backhaul link140, or via router137and backhaul link142.

It should be understood that backhaul links140and142may not be the only backhaul links connecting RAN105to other network entities. Also, other links, including some not shown, may be referred to as backhaul links. For instance, links between a BTS and a radio network controller may be considered backhaul links, and links between a radio network controller and a router may be considered backhaul links as well. Thus, the term “backhaul link” may refer to any of these links, or any other link, aside from an air interface link, that may be used by network communication involving WCD110.

Wireless coverage areas112,114,116may provide air interface access to WCDs, such as WCD110. The air interface of these wireless coverage areas may include forward links for transmitting information from a BTS to a WCD (in the forward direction) and reverse links for transmitting information from a WCD to a BTS (in the reverse direction). Through the forward and reverse links, a BTS and a WCD may exchange signaling traffic, as well as bearer traffic, such as voice, data, video, or other media.

A WCD in communication system100, such as WCD110, could be a wireless telephone, a wireless personal digital assistant, a wirelessly equipped laptop computer, a wireless router, or another type of mobile or fixed wireless device. Preferably, a WCD is a subscriber device that is manipulated by a human in order to establish circuit-switched or packet-switched voice and/or data calls. However a WCD could also be an automated device without a human interface.

Typically, a WCD is associated with one or more BTSs at a time and uses the wireless coverage areas of these BTSs to communicate with correspondent nodes, such as web servers, gaming servers, short message service (SMS) servers, voice over IP (VoIP) signaling proxies, VoIP bearer gateways, and other WCDs. A WCD may maintain a list of wireless coverage areas in its range as a candidate set or neighbor set. A WCD may also be able to transfer ongoing communication sessions from one BTS to another in a handoff process. Such a handoff process may be initiated or triggered by the WCD, the BTS, or a mutual agreement between the WCD and the BTS.

When a WCD enters a first wireless coverage area, some combination of the first wireless coverage area's serving BTS, radio network controller, base station controller, and the WCD itself, may determine that the first wireless coverage area should offer service to the WCD. If so, the WCD may register with the first wireless coverage area. Typically, this involves the WCD associating itself with the first wireless coverage area, and being assigned forward direction and reverse direction channels for signaling and/or bearer traffic. Once registered, a home location register (HLR), visitor location register (VLR), or both, maintain a record of the WCD's registration status, including an indication that the WCD is registered with the first wireless coverage area. Note that the HLR and the VLR are not shown inFIG. 1.

As the WCD continues to move, it may leave the first wireless coverage area and enter a second wireless coverage area. In this case, the WCD may be handed off from the first wireless coverage area to the second wireless coverage area. The WCD may then register with the second wireless coverage area, and the WCD's record in the HLR and/or VLR may be updated accordingly.

Server130may be a standalone component or may be integrated with other components, such as a radio network controller, base station controller, or BTS. Server130preferably maintains representations of at least some wireless coverage areas in RAN105, at least some BTSs in RAN105, backhaul link140, backhaul link142, and potentially other components as well. These representations preferably include an indication of the load on, or the load generated by, each of these components. These loads may be representations of bit rates, packet rates, processor utilization, memory utilization, link utilization, or some other measurement. Server130may also maintain representations of at least some WCDs served by RAN105, including profiles associated with these WCDs.

For example, server130may contain a representation of the loads in each of wireless coverage area112,114,116, as well as the loads on BTS120, BTS122, backhaul link140, and backhaul link142. Server130may be configured to periodically, upon request, or from time to time, receive representations of these loads from BTS120, BTS122, and/or routers135and137, respectively. Furthermore, server130may contain a representation of the profiles of the various WCDs served by RAN105, such as WCD110.

Server130may be a computing device containing a processor and a memory, and supporting a general purpose operating system, such as MICROSOFT WINDOWS® or Linux. Alternatively, server130may be an embedded system, and may support a real-time operating system. Preferably, server130comprises one or more each of input devices, output devices, and network interfaces. For example, server130may support input via a keyboard, keypad, mouse, touchscreen, and so on. Server130may also support output via a screen, a monitor, a printer or some other device. Server130may include network interfaces, such as various types of wireline or wireless transceivers. Via these interfaces, server130may receive loading information from BTS120, BTS122, and routers135and137. Furthermore, via these interfaces server130may receive a request from a WCD, such as WCD110, seeking to determine an available capacity via one or more wireless coverage areas. Server130may respond to this request with an indication of such an available capacity, where the available capacity in the indication is based on the load on the wireless coverage area(s) and perhaps other factors.

Routers135and137may be off-the-shelf or custom routers, firewalls, or switches. Accordingly, these routers may be arranged to route packets between various components of communication system100, such as BTS120, BTS122, server130, backhaul link140, and backhaul link142. The routing may occur based information in the packets. This information in the packets may be associated with one or more layers of the open systems interconnection (OSI) protocol stack.

For example, routers135and137may route packets based on some combination of layer two, layer three, and layer four information. Thus, they may examine source and/or destination addresses of datalink, network, and transport protocol headers contained within packets in order to determine how to process these packets. Of course, routers135and137may also use additional information in the packets, and/or stored policy, in making this determination.

Routers135and137may also support the Internet Engineering Task Force (IETF) Simple Network Management Protocol (SNMP). SNMP is defined in IETF Requests For Comments (RFCs) 1901, 2576, 2578-2580, and 3410-3418, which are incorporated by reference in their entirety herein. Accordingly, routers135and137may support one or more Management Information Base (MIB) objects that provide access to data representing a load on backhaul links140and142. This load may be in the form of bits per second of traffic, packets per second of traffic, a percentage of utilized capacity, or some other metric. Furthermore, the load may be represented as a smoothed average of measurements, such as an average percentage of utilized capacity calculated over a number of measurements taken over a period of time.

Regardless of its exact representation, this information is preferably available via SNMP. For instance, server130may query one or more MIB objects on router135and/or router137, and in response router135and/or router137may transmit a representation of the load on backhaul links140and/or142, respectively, to server130. Alternatively, these routers may transmit the representation of the load to server130using an SNMP trap message. However, the routers need not support an SNMP interface to report the load on the backhaul links. Other protocols, standard or proprietary, may be used to accomplish the same purpose.

Backhaul links140and142may be wireline links, such as a type of Ethernet, SONET, or T-carrier. Alternatively, backhaul links140and142may be wireless links, such as a satellite, microwave, or similar point-to-point links. Preferably, backhaul links140and142connect RAN105to network150, where network150is the Internet or a private IP network. But, in full generality, these backhaul links may connect any two or more component through which WCD110might communicate. Furthermore, these backhaul links may contain multiple physical or logical links or connections between RAN105and network150.

It should be appreciated that the elements inFIG. 1are exemplary, and in preferred embodiments of this invention more or fewer elements may be included in communication system100, and the elements may be arranged differently or omitted altogether. For example, there may be multiple routers, each with multiple backhaul links, that communicate with server130.

Furthermore, elements of communication system100may comprise multiple physical or logical devices or components, or may be combined into fewer physical or logical components than are shown inFIG. 1. Moreover, WCD110, wireless coverage areas112,114,116, and BTS120,122, may operate in accordance to various types of wireless protocols, such as Code Division Multiple Access (CDMA), Worldwide Interoperability for Microwave Access (WIMAX®), Universal Mobile Telecommunications System (UMTS®), Long Term Evolution (LTE®), IDEN®, 802.11 (Wifi), or other protocols now known or later developed.

II. EXAMPLE MESSAGE FLOWS

The embodiments herein involve media sessions between WCDs and remote hosts, for example, a media session between a WCD and a remote host. Preferably, the media session is logically decomposed into a control plane and a bearer plane. The control plane involves protocols that establish, manage and tear down the session, while the bearer plane involves the actual media (audio, video, and so on) that the media session transports.

One control plane protocol is the Session Initiation Protocol (SIP), which is defined in IETF RFC 3261 and incorporated by reference in its entirety herein. Another such control plane protocol is the Real Time Streaming Protocol (RTSP), which is defined in IETF RFC 2326 and also incorporated by reference in its entirety herein. Yet another control plane protocol is H.323, which is defined in the International Telecommunications Union (ITU) Recommendation H.323, and is also incorporated by reference in its entirety herein.

Control plane protocol or protocols preferably allow negotiation of one more bearer plane media codecs between the WCD and remote host. Example voice codecs include G.711, G.723.1, and G.729, defined in ITU Recommendations G.711, G.723.1, and G.729, respectively, all of which are incorporated by reference in their entirety herein. Example audio codecs include the Moving Picture Experts Group (MPEG) Layer 3 (MP3), and example video codecs include MPEG Layer 4 (MPEG-4). However, the embodiments described herein are not limited to just these codecs.

Each type of codec may support multiple bit rates. For instance, the MPEG-4 codec may support bit rates of 768, 384, and 192 kilobits per second. The same video media can be encoded using these different bit rates by adjusting the parameters of the encoding. These parameters may include sampling rate, resolution, and color depth, just to name a few. Audio codecs may vary their sampling rate and supported frequency range, for example, to produce different bit rates. Thus, even though a designation, such as MP3 or MPEG-4, may be referred to as a “codec,” such a designation may actually refer to a family of different codecs.

In general, the higher the bit rate of a codec, the higher the quality of the media produced by the codec. Thus, it is usually advantageous to the WCD and the remote host to engage in a media session using the highest bit rate codec that the network(s) and link(s) between them can support. But, network and link conditions may fluctuate over time. Thus, the WCD and the remote host may adapt to these conditions by switching to a lower or higher bit rate codec while in an ongoing media session. Accordingly, the control plane protocol or protocols also preferably allow mid-session re-negotiation of such a codec.

SIP, for example, uses an INVITE message to initiate a session between two or more devices, as well as to renegotiate session parameters after the session has been established. The INVITE message may specify information related to the identification of the devices, authentication information, and session options. One type of session option may be a media codec. However, an INVITE message may also specify other types of information and other session options.

Using SIP, the WCD may transmit an INVITE message to the remote host in order to establish a media session with the remote host using the first codec. Later, after bearer traffic using the first codec is passing between the WCD and the remote host, the WCD may determine that it should use a lower bit rate codec. This determination may be made according to the methods described below. Accordingly, the WCD may transmit another SIP INVITE message to the remote host. This second INVITE message preferably specifies a different codec than the codec that was specified in the initial INVITE message, or the INVITE message may specify the same codec that was specified in the initial INVITE message, but instruct he remote host to use different parameters. The act of transmitting a mid-session SIP INVITE message is sometimes referred to as transmitting a re-INVITE message. Presumably, the remote host supports the codec specified in the second INVITE and the codec used in the media session is changed accordingly.

The step of renegotiating the media session's codec may involve more communication than just the WCD transmitting a SIP INVITE. In response to the SIP INVITE, the remote host may transmit a SIP 200 OK message to the WCD, and the WCD may then transmit a SIP ACK message to the remote host. Of course, the WCD and the remote host may transmit other SIP messages as well during this step.

FIG. 2is directed to a WCD proactively renegotiating a media codec in response to the WCD determining that it is about to be handed off to a wireless coverage area that may not have capacity to support the bit rate required by the codec that the WCD is currently using. InFIG. 2, message flow200includes WCD110, server130, and remote host205. Preferably, WCD110is engaged in a media session with remote host205. This media session may be an interactive or non-interactive voice, audio, or video session, or may contain some combination of voice, audio, or video communication.

At step210of message flow200, WCD110is served by a first wireless coverage area. At step220, WCD110conducts an ongoing media session with remote host205. Preferably, the media session uses a first codec on its bearer plane and uses SIP on its control plane. At step230, WCD110detects an upcoming handoff to a second wireless coverage area.

There are a number of ways that WCD110can detect an upcoming handoff. Typically, a WCD will receive pilot signals of more than one wireless coverage area. Among other information, these pilot signals provide the WCD with an indication of the signal strength of each wireless coverage area. If the WCD or the RAN determines that (1) the signal strength of the first wireless coverage area, as received and measured by the WCD, is too low, and (2) the signal strength of the second wireless coverage area, as received and measured by the WCD, is sufficient for the WCD to be effectively served, then the WCD may determine that it is likely to be handed off to the second wireless coverage area.

Note that even if WCD110detects an upcoming handoff to a new wireless coverage area, this handoff may or may not be imminent. For instance, the WCD may be leaving the range of the first wireless coverage area and entering the range of the second wireless coverage area. In such a case, the handoff to the second wireless coverage area may be imminent. On the other hand, the WCD may be on the border of the first and second wireless coverage areas. The WCD may detect an upcoming handoff from the first wireless coverage area to the second wireless coverage area, but then the WCD may move away from the border and into the center of the first wireless coverage area. In such a case, the WCD would probably not be handed off to the second wireless coverage area, even though the WCD detected an upcoming handoff.

WCD110may also maintain a pre-handoff threshold value. In this case, when WCD110determines that a quality of the coverage that it is receiving from the first wireless coverage area is below the pre-handoff threshold value, then WCD110may presume that a handoff is likely. Such qualities of coverage could include, but are not limited to, a wireless coverage area's pilot signal strength as received by WCD110, or the bit error rate or frame error rate of information as received by WCD110.

At step240, WCD110transmits a request to server130. The request is preferably generated by a dedicated application executing on WCD110. This application may use IP to carry the request to server130. However, the request may be generated by an application that also performs other tasks on WCD110, or may be generated by the operating system of WCD110.

Regardless, the request may query server130for a capacity that is available to WCD110via the second wireless coverage area. In doing so, WCD110seeks to determine if the second wireless coverage area, to which WCD110will likely be handed off, has enough capacity to support the media session using the first codec. The request may query server130for capacities available to WCD110from other wireless coverage areas as well. For example, WCD110may ask server130for capacities available to it via all of the wireless coverage areas in the candidate set or neighbor set of WCD110. Doing so allows WCD110to determine these respective capacities with a single message rather than with multiple messages.

Furthermore, in a RAN where there are multiple candidate wireless coverage areas to which WCD110could be handed off, WCD110might not be certain to which candidate wireless coverage area it may ultimately be handed off. Thus, knowing the capacity available via all such candidate wireless coverage areas allows WCD110, for example, to renegotiate its media codec to adapt to the lowest capacity available across all of these candidates.

Step240may occur, as depicted inFIG. 2, after WCD110detects an upcoming handoff to the second wireless coverage area. In fact, step240may occur in response to this detecting. However, step240could also occur at a different point in message flow200. For instance, step240may occur based on a change in membership to the candidate set or neighbor set of WCD110, may occur periodically, or may occur in response to other events.

Regardless of when and why step240occurs, at step250, server130determines the capacity available to WCD110via the second wireless coverage area. This capacity may be reported as a bit rate, as a packet rate, as a percentage of utilized or available capacity, or as some other metric. Such a metric may represent available capacity or may be information from which WCD110can derive a measurement or estimate of available capacity. At step260, server130transmits an indication of this available capacity to WCD110.

At step270, WCD110determines that this available capacity is insufficient to support the ongoing media session using the first codec. Accordingly, at step280, WCD110initiates a re-negotiation of the media session. Preferably, WCD110transmits a SIP INVITE to remote host205. This SIP INVITE contains at least an indication that WCD110is seeking to use a second codec for the ongoing media session. In particular, this second codec may require less capacity than the first codec. For example, suppose that the media session is an MPEG-4 streaming video session and the first codec (and MPEG-4 codec) requires 768 kilobits per second. If, at step270, WCD110determines that the available capacity is only 512 kilobits per second, then WCD110may seek to renegotiate the MPEG-4 streaming video session to use a second codec (another MPEG-4 codec) that requires only 384 kilobits per second. Of course, a WCD may renegotiate a media session to use a codec from a different codec family (e.g., going from using an MPEG-4 codec to a non-MPEG-4 codec or vice versa).

At step290, this renegotiation is complete, and WCD110may be handed off to the second wireless coverage area. By proactively renegotiating the codec used by the media session prior to the handoff, WCD110avoids using a codec with a bit rate that cannot be supported by the second wireless coverage area. Thus, the media session is less likely to experience dropped packets and impaired quality due to network congestion. While using a lower bit rate codec at WCD110may reduce the quality of the media session as experienced by a user of WCD110to some extent, doing so limits the negative impact that the media session will have on the user of WCD110and other users. For instance, assume that WCD110is sharing the second wireless coverage with ten other WCDs and attempts to utilize more capacity than is available. Not only may WCD110experience packet loss and a degraded quality for its media session, it may also cause network congestion in the second wireless coverage area, at the BTS that defines the second wireless coverage area, or further downstream. This congestion could result in reducing the effective data rates of at least some of the other ten WCDs.

Once WCD110has been served by the second wireless coverage area for some time, WCD110may determine that it is about to be handed off again. This second handoff may be to a third wireless coverage area or back to the first wireless coverage area. For sake of discussion, assume that WCD110determines that it is about to be handed off to a third wireless coverage area. This third wireless coverage area may either be the first wireless coverage area or a different wireless coverage area. In response to the determination, WCD110may transmit a second request to server130, seeking to determine the capacity available to it via the third wireless coverage area. Subsequently, WCD110may receive, from server130, an indication of the requested available capacity. Alternatively, this request and response may occur before WCD110determines that it is about to be handed off, and/or in response to some other event.

Regardless, WCD110may determine that the capacity available to it via the third wireless coverage area is at least as much as the capacity required by the first codec. For instance, if the first codec requires 768 kilobits per second and WCD110may determine that the capacity available exceeds this rate. Accordingly, WCD110may, after being handed off to the third wireless coverage area, renegotiate the media session to use the first codec. In this way, WCD110reverts to using a higher bit rate codec when network conditions are amenable to the use of the higher bit rate codec.

Alternatively, WCD110may renegotiate the media session to use a third codec that requires a different bit rate than the first codec. For instance, WCD110may determine that the capacity available to it via the third wireless coverage area is such that WCD110should use a third codec with a bit rate between that of the first code and the second codec. On the other hand, WCD110may determine that the available capacity allows WCD110to use a third codec with a bit rate greater than that of the first codec.

FIG. 3is directed to a server receiving information from various network components representing available capacities at the components, and using this information to determine a capacity available to a WCD via a wireless coverage area. The message flow inFIG. 3illustrates how a server, such as server130, may determine a capacity available to a WCD via a wireless coverage area.

At step310, server130receives sector loading information from BTS120, BTS122, or both. Preferably, this sector loading information includes a representation of the sector loading at the second wireless coverage area. The sector loading of a wireless coverage area can be represented in various ways. It may take the form of a number of communication sessions currently supported at the wireless coverage area, or an aggregate data rate of all such communication sessions. Furthermore, such a number of communication sessions or data rate may be represented as an absolute value, such as a count of the communication sessions or the total bits per second used by the communication sessions. Or, the number of communication sessions or data rate may be represented as a relative percentage of used capacity. (For instance, if the wireless coverage area can support at most 30 communication sessions and currently supports15communication sessions, a BTS could report the sector loading of the wireless coverage area as 50%.)

Alternatively or additionally, a representation of sector loading may be based on measurements performed by one or more WCDs served by the wireless coverage area. For instance, each WCD served by a wireless coverage area may report a bit error rate or frame error rate that it has observed when communicating via the wireless coverage area. The WCDs may report this information to the BTS that radiates to define the wireless coverage area, and then the BTS may subsequently provide this information to server130.

At step320, server130receives a representation of available capacity of backhaul link140. This representation may also take the form of an absolute or a relative measurement. For example, the measurement could take the form of a number of available bits per second or a percentage of available capacity on backhaul link140and/or backhaul link142.

The messages received by server130in steps310and320may be received by server130periodically or aperiodically. Alternatively or additionally, server130, or some other entity, may request the sector loading of a wireless coverage area from a BTS and/or request an available capacity of backhaul link140and/or backhaul link142.

By considering the available capacity of a backhaul link along with the sector loading of a wireless coverage area, a more accurate representation of the actual capacity available to a WCD served by the wireless coverage area may be formed. In some high speed wireless networks, there may be more capacity available to the WCD in the wireless coverage area than on the backhaul link. This may be the case because a large number of WCDs from multiple wireless coverage areas may share the backhaul link. Thus, if server130only considered the capacity available via the wireless coverage area, it might overestimate the actual end-to-end network capacity available to a WCD. However, server130considering only the available capacity of a wireless coverage area is within the scope of the embodiments herein.

At step330, server130receives a request from WCD110for the capacity available to it via the second wireless coverage area. Presumably, WCD110is currently served by a first wireless coverage area, is conducting a media session with a remote host, and has determined that it will likely be handed off to the second wireless coverage area. Thus, WCD110may be requesting the capacity available to it via the second wireless coverage area in order to determine whether this available capacity is sufficient for its ongoing media session.

At step340, server130determines such an available capacity. To do so, server130may consider any information on hand, including the information it may have received in steps310and320. Furthermore, server130may also take an identity of WCD110into account when making this determination.

For instance, server130may store, or have access to, a profile for WCD110. Among other things, this profile may contain the identity of WCD110and/or its current user, and various parameters that represent the relative priority of WCD110, its current user, and/or its current communication session(s). This priority may be a simple relative ranking (e.g., “high,” “medium,” or “low”) or a more complex representation. As an example, the representation of priority may conform to the IETF differentiated services codepoint specification described in IETF RFC 2475, which is incorporated in its entirety herein.

Regardless of the exact representation of the priority in the profile, server130may compare the priority to a threshold value, and adjust the value of available capacity that it reports to WCD110based on the outcome of this comparison. Thus, if a profile indicates that WCD110, its current user, or its current session has a high priority (i.e., above the threshold value), server130may report the available capacity to be a higher value. On the other hand, if the profile indicates that WCD110, its current user, or its current session has a low priority (i.e., below the threshold value), server130may report the available capacity to be a lower value. Thus, server130may report an available capacity to WCD110that may be different from the actual unused capacity present on a path including a wireless coverage area and a backhaul link.

Consequently, the determination made at step340may include consideration of the capacity available to WCD110via the second wireless coverage area, the available capacity on backhaul link140and/or backhaul link142, and a profile of WCD110. For instance, assume that the second wireless coverage area has 2 megabits per second of available capacity, and is only connected to one backhaul link. Assume further that this backhaul link has 3 megabits per second of available capacity, and the profile of WCD110indicates a high priority. Then, server130may determine that the capacity available to WCD110via the second wireless coverage area is 2 megabits per second. In doing so, server130may calculate the minimum of the wireless coverage area capacity and the backhaul link capacity to determine the available capacity. Server130then may decide that it should provide the entire 2 megabits per second as available capacity to WCD110, since the profile of WCD110indicates that WCD110has a high priority. Accordingly, server130may report that the maximum achievable end-to-end bit rate for WCD110is 2 megabits per second.

On the other hand, if the second wireless coverage area has 2 megabits per second of available capacity, backhaul link140has 3 megabits per second of available capacity, and the profile of WCD110indicates a low priority, then server130may determine that the capacity available to WCD110via the second wireless coverage area is 1 megabit per second. In doing so, server130may calculate the minimum of the wireless coverage area capacity and the backhaul link capacity to determine an available capacity of 2 megabits per second. Server130then may decide that it should report a lower available capacity to WCD110, since the profile of WCD110indicates that WCD110has a low priority. Of course, these two determinations of available capacity are merely illustrative, and server130could make many other determinations of available capacity in accordance with the embodiments herein.

At step350, server130transmits the determined available capacity to WCD110. In this transmission, server130could encode the determined available capacity in various formats, such as a bit rate, a relative bit rate, an index or reference number representing a bit rate, or some other format. Thus, server130informs WCD110of the maximum capacity that it should attempt to use while served by the second wireless coverage area.

III. EXAMPLE FLOW CHARTS

FIGS. 4-6are flow charts illustrating methods in accordance with preferred embodiments.FIGS. 4 and 5depict methods that could be performed by a WCD, such as WCD110.FIG. 6depicts a method that could be performed by a server, such as server130. It should be understood that for each method depicted inFIGS. 4-6, more or fewer steps may be used, and the steps may occur in a different order. Furthermore, the methods depicted in these figures may be combined, in whole or in part, and still be within the scope of the preferred embodiments.

FIG. 4depicts method400for proactively renegotiating a media session to use a lower bit rate codec prior to handoff to a new wireless coverage area. At step410, a WCD is conducting a media session with a remote host. The WCD is served by a first wireless coverage area, and the media session uses a first codec. The media session may support audio, video, multimedia or some combination of thereof. At step420, it is determined that the WCD will be handed off from the first wireless coverage area to a second wireless coverage area. Accordingly, at step430, the WCD transmits a first request to a server, seeking to determine a capacity available to the WCD via the second wireless coverage area. In response to the first request, the WCD receives, in step440, a first indication of the capacity available to it via the second wireless coverage area.

At step450, the WCD determines that this available capacity is less than the capacity required by the first codec. Thus, at step460, before the WCD is handed off, the WCD proactively renegotiates the media session to use a second codec. This renegotiation may be triggered by the WCD transmitting a SIP INVITE message to the remote host, where the SIP INVITE indicates that the second codec is to be used for the media session. Preferably, the capacity required by the second codec is less than or equal to capacity available to the WCD via the second wireless coverage area.

FIG. 5depicts a method500that continues from where method400left off. At step510, the WCD detects an upcoming handoff from the second wireless coverage area to a third wireless coverage area. As a result, at step520, the WCD transmits a second request to the server, seeking to determine the capacity available to the WCD via the third wireless coverage area. At step530, the WCD receives, from the server, a response containing a second indication of capacity available to the WCD via the third wireless coverage area.

At step540, the WCD determines that this available capacity is more than the capacity required by the first codec. Thus, the WCD can once again use the first codec once the WCD is handed off to the third wireless coverage area. It may be advantageous for the WCD to switch from using the second codec to using the first codec because the first codec may provide for a higher quality media session. Accordingly, at step550, after the WCD is handed off to the third wireless coverage area, the WCD renegotiates the media session to use the first codec. This renegotiation may be triggered by the WCD transmitting a SIP INVITE message to the remote host, where the SIP INVITE indicates that the first codec is to be used for the media session.

FIG. 6depicts method600for a server to determine a capacity available to a WCD via a wireless coverage area. At step610, the server receives, from a BTS, a sector loading of a second wireless coverage area. Preferably, the BTS radiates to define the second wireless coverage area, and the sector loading is represented by an absolute or relative measure of the unused capacity of the second wireless coverage area. The BTS may be an element of a RAN, the RAN containing one or more such BTSs, as well as other elements. At step620, the server receives, from a router, an available capacity of a backhaul link between the RAN and a network. Preferably, the available capacity on the backhaul link is represented by an absolute or relative unused capacity of the backhaul link. Steps610and620may occur periodically or may be triggered by some event, such as a request from the server. Furthermore, if the RAN comprises multiple BTSs and/or routers, the server may receive available capacities from each of these BTSs and/or routers.

At step630, the server receives, from a WCD, a request seeking to determine a capacity available to the WCD via the second wireless coverage area. At step640, the server determines this available capacity. In doing so, the server may take into account information received from the BTS that defines the second wireless coverage area, as well as any routers connecting the BTS to backhaul links. Furthermore, the server may also take into account information related to the identity of the WCD, its current user, and/or its current communication sessions. At step650, the server transmits the determined available capacity to the WCD.

In this way, the server is able to effectively manage the resources and capacity of the wireless coverage areas and the backhaul links. As a result, an operator of the RAN is able to allocate capacity to WCDs based on the relative priority of those WCDs, their users, or their applications. Doing so potentially improves the user experience of all users accessing the RAN and therefore increases these users' satisfaction with the operator's service.