Patent Description:
A mobile or cellular telephone system is an example of a communication system that is capable of transmitting and receiving data between end user equipment or applications and network equipment. Transmitted and received data may be in the form of data packets. Transmitted data packets may be in a variety of formats and include a variety of different types of data, including voice data, binary data, video data, and the like.

In a communication system, such as a mobile or cellular telephone communication system, various methods are used to establish the rate of communication or bitrate at which data packets are transferred between a user's mobile device, such as a mobile telephone, and the rest of the system. For example, if Adaptive MultiRate (AMR) or Adaptive MultiRate - Wideband (AMR-WB) transmission is used, at call set-up a mode set is negotiated through the Session Description Protocol (SDP). The Session Description Protocol parameter "mode-set" takes a value that represents a subset of bitrates that can be used during a call. The value is selected from the set {<NUM>,. , <NUM>} for Adaptive MultiRate transmissions and from the set {<NUM>,. , <NUM>} for Adaptive MultiRate - Wideband transmissions. The value to be used may be selected, for example, based on detected signal strength between the mobile device and the rest of the network at the time of call set-up. When a sender encodes speech it must use one of the bitrates in the mode set. The mode used to encode is then indicated to the receiver in a Codec Mode Indication (CMI) field of the Real-time Transport Protocol payload.

For Long Term Evolution (LTE), the relevant specification in terms of codec rate adaptation is 3GPP TS <NUM>, which specifies the Multimedia Telephony Services over IP Multimedia Subsystem (MTSI). Included in this specification are several means of adaptation. For example, bit rate, number of frames per packet, and amount of redundant frames per packet, may all be adapted according to requests from the receiver of the encoded media. These requests are generally included in the RTP Control Protocol Application Defined (RTCP APP) packets.

Problems arise in a communication system when demands on the network system to process data packets for transmission through the system in a timely manner exceed network capacity. In such situations the network is said to be experiencing congestion. A typical response to such congestion is for the network simply to drop packets received from, or to be transmitted to, a user application or equipment, and that cannot be processed by the network in a timely manner.

Explicit Congestion Notification (ECN) is a method for the network to indicate to user applications that the network is experiencing congestion. In response to receiving such a notification, a user application or equipment can reduce its sending rate, in order to avoid packets being dropped. For example, Explicit Congestion Notification may be implemented by marking two bits in the Internet Protocol (IP) header of a packet as '<NUM>,' indicating that congestion is being experienced by a network element processing the packet. Via a feedback mechanism, the sender of the packet is notified of the congestion, and can then reduce its sending rate.

Until recently, it has not been specified how to apply Explicit Congestion Notification to User Datagram Protocol (UDP) traffic. The User Datagram Protocol itself does not contain a feedback mechanism. However, most real-time applications, such as voice, video, real-time text, and the like, use Real-timeTransport Protocol (RTP) over User Datagram Protocol, which does have a feedback mechanism, namely RTP Control Protocol (RTCP). It has been proposed to use Explicit Congestion Notification with Real-time Transport Protocol. In this proposal, the receiver of Internet Protocol packets that are marked "Congestion Experienced" communicates this information to the sender through the RTP Control Protocol feedback packets. The sender can then reduce its bitrate in order to reduce congestion. For Adaptive MultiRate (AMR) or Adaptive MultiRate - Wideband (AMR-WB) transmissions, the sender can change its transmission mode to reduce congestion.

As an alternative, the receiver of packets marked "Congestion Experienced" may use the Codec Mode Request (CMR) field in the Real-time Transport Protocol payload to request that the sender reduce its bitrate. This has the advantage that additional RTP Control Protocol traffic is not created, when the network is already congested, in order to communicate which packets were marked "Congestion Experienced" to the sender. It has the disadvantage that it cannot be used to control bitrates when data packet flow is unidirectional. For codecs that do not have a Codec Mode Request field in the Real-time Transport Protocol payload, and for other media types, it is possible that a Temporary Maximum Media Stream Bit Rate Request (TMMBR) may be used to request the sender to reduce its bitrate. <CIT>discloses an egress node for a network domain. <CIT> relates to a method for accelerating resolution of network congestion. <CIT> relates to a codec that detects congestion in a packet network.

It would be advantageous to have a method and apparatus that takes into account at least some of the issues discussed above, as well as possibly other issues. Accordingly, there is provided a method, a computer-readable medium, and a receiver according to the claims.

For a better understanding of the various embodiments described herein, and to show more clearly how they may be carried into effect, reference will now be made, by way of example only, to the accompanying drawings, which show at least one illustrative embodiment and in which:.

It will be appreciated that for simplicity and clarity of illustration, where considered appropriate, reference numerals may be repeated among the figures to indicate corresponding or analogous elements. In addition, numerous specific details are set forth in order to provide a thorough understanding of the embodiments described herein. However, it will be understood by those of ordinary skill in the art that the embodiments described herein may be practiced without these specific details. In other instances, well-known methods, procedures and components have not been described in detail so as not to obscure the embodiments described herein. Also, the description is not to be considered as limiting the scope of the embodiments described herein.

The different embodiments disclosed herein recognize and take into account a number of different considerations. For example, the disclosed embodiments recognize and take into account that current communication system specifications do not describe how a sender's bitrate is to be reduced when packets marked to indicate that congestion is being experienced are observed. Consider, for example, the scenario where an Adaptive MultiRate speech codec and the default Adaptive MultiRate mode set for a Multimedia Telephony Service for IP Multimedia Subsystem corresponding to bitrates of <NUM> kbps, <NUM> kbps, <NUM> kbps, and <NUM> kbps is used. If the sender is currently using the <NUM> kbps bitrate, and packets marked "Congestion Experienced" are observed, current specifications do not specify how the sender is to respond. In this case, response options include jumping immediately all the way down to <NUM> kbps or stepping down to the next lowest rate in the mode set and then stepping down again if packets marked "Congestion Experienced" continue to be observed. The disclosed embodiments recognize and take into account that current specifications do not specify how the bitrate should be adapted back up if congestion eases. Furthermore, the disclosed embodiments recognize and take into account that current specifications do not specify how user priority and emergency calls should be handled in the context of a system or method for adapting the bitrate in response to an explicit congestion notification.

The disclosed embodiments recognize and take into account that current solutions for Explicit Congestion Notification employ only an on/off or binary indication of congestion. Either data packets are marked to indicate that congestion is experienced or they are not. The disclosed embodiments recognize and take into account that a mechanism is needed for codec selection and adaptation in communication systems that employ binary "Congestion Experienced" marking for Explicit Congestion Notification.

The disclosed embodiments recognize and take into account that Internet Protocol traffic in a UTRAN or EUTRAN network can be very dynamic. Congestion detection and binary "Congestion Experienced" marking of data packets based on that detection can be very noisy and may be prone to oscillation. This may result in very unstable codec adaptation based network congestion control using Explicit Congestion Notification. Frequent and unnecessary adaptation could have a negative impact on perceived quality by a user.

The embodiments disclosed herein provide a system and method for rate adaptation in a communication system when a receiving terminal receives data packets with "Congestion Experienced" marked or unmarked. In accordance with disclosed embodiments, congestion is indicated as detected by the transmission of marked packets and congestion is indicated as cleared by the transmission of unmarked packets. Based upon the marked or unmarked packets detected, a receiver of the data packets determines a rate reduction or increase based on sequences provided by the network or configured on the receiver. If a rate adaptation is determined to be required, the receiver may send a codec rate change request with the determined rate to the sender.

Embodiments disclosed herein are particularly adapted to a mechanism for Explicit Congestion Notification based codec adaptation using binary "Congestion Experienced" marking in a UMTS Terrestrial Radio Access Network (UTRAN) or an Evolved UTRAN (E-UTRAN). For Long Term Evolution (LTE), the relevant specification in terms of codec rate adaptation is 3GPP TS <NUM>, which specifies the Multimedia Telephony Services over IP Multimedia Subsystem (MTSI). Illustrative embodiments are applicable also to other communication systems and radio or fixed networks.

Turning first to <FIG>, a wireless communication system is depicted in accordance with an illustrative embodiment. Wireless communication system <NUM> includes wireless network <NUM>. Wireless network <NUM> may comprise a single network or multiple networks forming a network of networks. Wireless network <NUM> provides for wireless communication by user equipment <NUM>, <NUM>, and <NUM> via wireless communication channels <NUM>, <NUM>, and <NUM> established between user equipment <NUM>, <NUM>, and <NUM> and wireless network <NUM>. As will be discussed in more detail below, examples of user equipment <NUM>, <NUM>, and <NUM> include mobile wireless communication devices including pagers, cellular phones, cellular smart-phones, wireless organizers, personal digital assistants, computers, laptops, handheld wireless communication devices, wirelessly enabled notebook computers and the like. Although only three user equipment <NUM>, <NUM>, and <NUM> are shown by example in <FIG>, wireless network <NUM> may support use of much larger numbers of user equipment of various different types.

Wireless communication channels <NUM>, <NUM>, and <NUM> are established dynamically between user equipment <NUM>, <NUM>, and <NUM> and individual nodes <NUM>, <NUM>, and <NUM> of wireless network <NUM>. Channels <NUM>, <NUM>, and <NUM> may be established, for example, at the time that a call to or from one of user equipment <NUM>, <NUM>, and <NUM> is initiated. Certain characteristics of communication channels <NUM>, <NUM>, and <NUM> are established at call set-up. For example, such characteristics may include the codec that is to be employed by the communication channel <NUM>, <NUM>, or <NUM> during the call. For example, the codec to be used may be selected based on factors such as the signal strength or signal quality between user equipment <NUM>, <NUM>, and <NUM> and a corresponding one of nodes <NUM>, <NUM>, or <NUM> of network <NUM> at call set-up. Although only three nodes <NUM>, <NUM>, and <NUM> are shown by example in <FIG>, wireless network <NUM> may include many more such nodes.

Network <NUM> operates to transfer data packets between user equipment <NUM>, <NUM>, and <NUM> using network nodes <NUM>, <NUM>, and <NUM>. Network <NUM> also may operate to transfer data packets between user equipment <NUM>, <NUM>, and <NUM> and other networks, such as conventional public switched telephone network (PSTN) <NUM>, or other public or private networks <NUM>, such as the Internet. This transfer of data packets to and from other networks <NUM> and <NUM> also uses network nodes <NUM>, <NUM>, and <NUM>. As data packet traffic through one or more of nodes <NUM>, <NUM>, and <NUM> increases, the capacity of network <NUM> to process and transfer packets in a timely manner to and from user equipment <NUM>, <NUM>, and <NUM> may be exceeded. In this case, network <NUM>, or one or more network nodes <NUM>, <NUM>, or <NUM>, is said to be congested. The embodiments disclosed herein provide an improved system and method for responding intelligently and more effectively when such network congestion occurs.

Referring now to <FIG>, a block diagram of an implementation of wireless network <NUM> in which illustrative embodiments may be implemented is presented. Wireless network <NUM> may be, for example, a Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (UTRAN). However, illustrative embodiments may be implemented in other similar or different communication networks, such as wireless networks using Long Term Evolution (LTE) technology. Illustrative embodiments also may be implemented in wireless networks configured in accordance with General Packet Radio Service (GPRS) and Global Systems for Mobile (GSM) technologies.

Wireless network <NUM> includes node <NUM>. In this example, node <NUM> is an example of one of nodes <NUM>, <NUM>, or <NUM> of <FIG>. As mentioned above, in practice, wireless network <NUM> comprises one or more of nodes <NUM>. For example, node <NUM> may be implemented as a Node B in a UMTS Terrestrial Radio Access Network or as the evolved Node B (eNodeB) in a Long Term Evolution network.

Node <NUM> may be referred to as a base transceiver station. Node <NUM> includes one or more radio frequency transmitters <NUM> and receivers <NUM> coupled to one or more antennas <NUM>. Transmitters <NUM> and receivers <NUM> are used by node <NUM> to communicate directly with mobile devices, such as user equipment <NUM>, via wireless communication channel <NUM>. Node <NUM> provides wireless network coverage for a particular coverage area, commonly referred to as a "cell". Node <NUM> also includes one or more processing systems <NUM>, such as computer data processing systems, for implementing the functionality provided by node <NUM>.

Node <NUM> is coupled to, and controlled by, radio network controller <NUM>. Multiple nodes <NUM> may be coupled to radio network controller <NUM> in network <NUM> in accordance with an illustrative embodiment. Radio network controller <NUM> is responsible for controlling all nodes <NUM> that are connected to it. Radio network controller <NUM> carries out radio resource management, such as the management of radio channels and some mobility management functions. Radio network controller <NUM> may be the point where encryption is done before user data is sent to and from user equipment <NUM>.

Radio network controller <NUM> connects to core network <NUM>. Multiple radio network controllers <NUM> may be coupled to core network <NUM>. A main function of core network <NUM> is to provide for the routing of data packets between user equipment on network <NUM> and between user equipment on network <NUM> and users on other networks, such as public switched telephone network <NUM> and other public or private networks <NUM>, such as the Internet. Functions provided by core network <NUM> in a UMTS network may be implemented, for example, by a media gateway and a Serving General Packet Radio Service (GPRS) Support Node (SGSN). A media gateway is a translation device or service that converts digital media streams between disparate telecommunications networks. Media gateways enable multimedia communications across networks over multiple transport protocols, such as Asynchronous Transfer Mode (ATM) and Internet Protocol (IP). An SGSN is responsible for the delivery of data packets from and to mobile user equipment within its geographical service area. Its tasks may include packet routing and transfer, mobility management, logical link management, and authentication and charging functions. In a Long Term Evolution (LTE) network, similar functions may be provided in core network <NUM> by, for example, a mobility management entity (MME), a serving gateway (SGW) and a packet data network (PDN) gateway (PGW).

The list of components presented with respect to <FIG> is not meant to be an exhaustive list of the components of a wireless network, but rather a list of components that are commonly used in communications through wireless network <NUM>.

User equipment <NUM> is a two-way communication device with advanced data communication capabilities, including the capability to communicate with other user equipment or computer systems through a network of transceiver stations or nodes as described above. User equipment <NUM> may also have the capability to allow voice communication. Depending on the functionality provided by user equipment <NUM>, it may be referred to as a data messaging device, a two-way pager, a cellular telephone with data messaging capabilities, a wireless Internet appliance, or a data communication device, with or without telephony capabilities.

Shown in <FIG> is a block diagram of an illustrative embodiment of user equipment <NUM>. In this example, user equipment <NUM> is an example of user equipment <NUM> in <FIG> and <FIG>. User equipment <NUM> includes a number of components such as main processor <NUM> that controls the overall operation of user equipment <NUM>. Communication functions, including data and voice communications, are performed through communication subsystem <NUM>. Communication subsystem <NUM> receives messages from and sends messages to wireless network <NUM>, described above. In this illustrative embodiment of user equipment <NUM>, communication subsystem <NUM> may be configured in accordance with Universal Mobile Telecommunications System (UMTS) technology using the UMTS Terrestrial Radio Access Network (UTRAN) or Long Term Evolution (LTE) technology using Evolved UTRAN (E-UTRAN). Alternatively, communication subsystem <NUM> may be configured in accordance with the Global System for Mobile Communication (GSM) and General Packet Radio Services (GPRS) standards. New standards are still being defined, but it is believed that they will have similarities to the network behavior described herein, and it will also be understood by persons skilled in the art that the embodiments described herein are intended to use any other suitable standards that are developed in the future.

The wireless link connecting communication subsystem <NUM> with wireless network <NUM> represents one or more different radio frequency (RF) channels, operating according to defined protocols specified for the particular communication technologies being employed. With newer network protocols, these channels are capable of supporting both circuit switched voice communications and packet switched data communications.

Other wireless networks also may be associated with user equipment <NUM> in various implementations. The different types of wireless networks that may be employed include, for example, data-centric wireless networks, voice-centric wireless networks, and dual-mode networks that can support both voice and data communications over the same physical base stations. Combined dual-mode networks include, but are not limited to, Code Division Multiple Access (CDMA) or CDMA2000 networks, GSM/GPRS networks, as mentioned above, third-generation (<NUM>) networks like EDGE and UMTS, and Long Term Evolution (LTE) networks. Some other examples of data-centric networks include WiFi <NUM>, Mobitex™ and DataTAC™ network communication systems. Examples of other voice-centric data networks include Personal Communication Systems (PCS) networks like GSM and Time Division Multiple Access (TDMA) systems.

Main processor <NUM> interacts with additional subsystems, such as random access memory (RAM) <NUM>, flash memory <NUM>, display <NUM>, auxiliary input/output (I/O) subsystem <NUM>, data port <NUM>, keyboard <NUM>, speaker <NUM>, microphone <NUM>, short-range communications <NUM>, and other device subsystems <NUM>.

Some of the subsystems of user equipment <NUM> perform communication-related functions, whereas other subsystems may provide "resident" or on-device functions. By way of example, display <NUM> and keyboard <NUM> may be used for both communication-related functions, such as entering a text message for transmission over network <NUM>, and device-resident functions, such as a calculator or task list.

User equipment <NUM> can send and receive communication signals over wireless network <NUM> after required network registration or activation procedures have been completed. Network access is associated with a subscriber or user of user equipment <NUM>. To identify a subscriber, user equipment <NUM> requires a Subscriber Identity Module (SIM) or a Removable User Identity Module (RUIM) card <NUM> to be inserted into SIM/RUIM interface <NUM> in order to communicate with a network. SIM or RUIM card <NUM> is one type of a conventional "smart card" that can be used to identify a subscriber of user equipment <NUM> and to personalize user equipment <NUM>, among other things. SIM or RUIM card <NUM> includes a processor and memory for storing information.

Without card <NUM>, user equipment <NUM> is not fully operational for communication with wireless network <NUM>. By inserting SIM or RUIM card <NUM> into SIM/RUIM interface <NUM>, a subscriber can access all subscribed services. Services may include web browsing and messaging such as e-mail, voice mail, Short Message Service (SMS), and Multimedia Messaging Services (MMS). More advanced services may include point of sale, field service and sales force automation. Once SIM or RUIM card <NUM> is inserted into SIM/RUIM interface <NUM>, it is coupled to main processor <NUM>. In order to identify the subscriber, SIM or RUIM card <NUM> can include user parameters, such as an International Mobile Subscriber Identity (IMSI). An advantage of using SIM or RUIM card <NUM> is that a subscriber is not necessarily bound by any single physical user equipment. SIM or RUIM card <NUM> may store additional subscriber information for user equipment as well, including datebook or calendar information and recent call information. Alternatively, user identification information can also be programmed into flash memory <NUM>.

User equipment <NUM> is a battery-powered device and includes battery interface <NUM> for receiving one or more rechargeable batteries <NUM>. In at least some embodiments, battery <NUM> may be a smart battery with an embedded microprocessor. Battery interface <NUM> is coupled to a regulator (not shown), which assists battery <NUM> in providing power V+ to user equipment <NUM>. Although current technology makes use of battery <NUM>, future technologies, such as micro fuel cells, may provide the power to user equipment <NUM>.

User equipment <NUM> also includes operating system <NUM> and other programs <NUM>. Programs <NUM> are described in more detail below. Operating system <NUM> and programs <NUM> may be implemented as software components that are run by main processor <NUM>. Operating system <NUM> and programs <NUM> typically are stored as program code on a media readable by a processor, such as main processor <NUM>. Such readable storage media may include a persistent storage device, such as flash memory <NUM>, which may alternatively be a read-only memory (ROM) or similar storage element. Those skilled in the art will appreciate that portions of operating system <NUM> and programs <NUM>, such as specific device applications, or parts thereof, may be loaded temporarily into a volatile storage device, such as RAM <NUM>. Other software components also may be included, as is well known to those skilled in the art.

Programs <NUM> that control basic device operations, including data and voice communication applications, normally will be installed on user equipment <NUM> during its manufacture. Other programs <NUM> include message application <NUM>. Message application <NUM> can be any suitable software program that allows a user of user equipment <NUM> to send and receive electronic messages. Various alternatives exist for message application <NUM>, as is well known to those skilled in the art. Messages that have been sent or received by the user are typically stored in flash memory <NUM> of user equipment <NUM>, or some other suitable storage element in user equipment <NUM>. In at least some embodiments, some of the sent and received messages may be stored remotely from user equipment <NUM>, such as in a data store of an associated host system that user equipment <NUM> communicates with.

Programs <NUM> may further include device state module <NUM>, personal information manager (PIM) <NUM>, and other suitable modules. Device state module <NUM> provides persistence, i.e., device state module <NUM> ensures that important device data is stored in persistent memory, such as flash memory <NUM>, so that the data is not lost when user equipment <NUM> is turned off or loses power.

PIM <NUM> includes functionality for organizing and managing data items of interest to the user, such as, but not limited to, e-mail, contacts, calendar events, voice mails, appointments, and task items. A PIM application has the ability to send and receive data items via wireless network <NUM>. PIM data items may be seamlessly integrated, synchronized, and updated via wireless network <NUM> with the user equipment subscriber's corresponding data items stored or associated with a host computer system. This functionality creates a mirrored host computer on user equipment <NUM> with respect to such items. This can be particularly advantageous when the host computer system is the user equipment subscriber's office computer system.

User equipment <NUM> also includes connect module <NUM>, and IT policy module <NUM>. Connect module <NUM> implements the communication protocols that are required for user equipment <NUM> to communicate with the wireless infrastructure and any host system, such as an enterprise system, that user equipment <NUM> is authorized to interface with.

Connect module <NUM> includes a set of APIs that can be integrated with user equipment <NUM> to allow user equipment <NUM> to use any number of services associated with an enterprise system. Connect module <NUM> allows user equipment <NUM> to establish an end-to-end secure, authenticated communication pipe with the host system. A subset of applications for which access is provided by connect module <NUM> can be used to pass IT policy commands from the host system to user equipment <NUM>. This can be done in a wireless or wired manner. These instructions can then be passed to IT policy module <NUM> to modify the configuration of user equipment <NUM>. Alternatively, in some cases, the IT policy update can also be done over a wired connection.

IT policy module <NUM> receives IT policy data that encodes the IT policy. IT policy module <NUM> then ensures that the IT policy data is authenticated by user equipment <NUM>. The IT policy data can then be stored in flash memory <NUM> in its native form. After IT policy data is stored, a global notification can be sent by IT policy module <NUM> to all of the applications residing on user equipment <NUM>. Applications for which the IT policy may be applicable then respond by reading the IT policy data to look for IT policy rules that are applicable. After the IT policy rules have been applied to the applicable applications or configuration files, IT policy module <NUM> sends an acknowledgement back to the host system to indicate that the IT policy data was received and successfully applied.

In accordance with a disclosed embodiment, congestion response module <NUM> may be provided to adapt the bitrate of user equipment <NUM> in response to receiving packets marked "Congestion Experienced" or unmarked packets, using one or more rate adaptation sequences provided by network <NUM> or configured on user equipment <NUM>, as will be described in more detail below. Congestion response module <NUM> may include one or more stand alone modules, or may be implemented, in whole or in part, as part of another module, such as connect module <NUM>.

Other types of programs or software applications also may be installed on user equipment <NUM>. These software applications may be third party applications, which are added after the manufacture of user equipment <NUM>. Examples of third party applications include games, calculators, utilities, etc..

Additional applications can be loaded onto user equipment <NUM> through at least one of wireless network <NUM>, auxiliary I/O subsystem <NUM>, data port <NUM>, short-range communications subsystem <NUM>, or any other suitable device subsystem <NUM>. This flexibility in application installation increases the functionality of user equipment <NUM> and may provide enhanced on-device functions, communication-related functions, or both. For example, secure communication applications may enable electronic commerce functions and other such financial transactions to be performed using user equipment <NUM>.

Data port <NUM> enables a subscriber to set preferences through an external device or software application and extends the capabilities of user equipment <NUM> by providing for information or software downloads to user equipment <NUM> other than through a wireless communication network. The alternate download path may, for example, be used to load an encryption key onto user equipment <NUM> through a direct and thus reliable and trusted connection to provide secure device communication.

Data port <NUM> can be any suitable port that enables data communication between user equipment <NUM> and another computing device. Data port <NUM> can be a serial or a parallel port. In some instances, data port <NUM> can be a USB port that includes data lines for data transfer and a supply line that can provide a charging current to charge battery <NUM> of user equipment <NUM>.

Short-range communications subsystem <NUM> provides for communication between user equipment <NUM> and different systems or devices, without the use of wireless network <NUM>. For example, subsystem <NUM> may include an infrared device and associated circuits and components for short-range communication. Examples of short-range communication standards include standards developed by the Infrared Data Association (IrDA), Bluetooth, and the <NUM> family of standards developed by IEEE.

In use, a received signal, such as a text message, an e-mail message, or web page download, will be processed by communication subsystem <NUM> and input to main processor <NUM>. Main processor <NUM> will then process the received signal for output to display <NUM> or alternatively to auxiliary I/O subsystem <NUM>. A subscriber may also compose data items, such as e-mail messages, for example, using keyboard <NUM> in conjunction with display <NUM> and possibly auxiliary I/O subsystem <NUM>. Auxiliary subsystem <NUM> may include devices such as a touch screen, mouse, track ball, infrared fingerprint detector, or a roller wheel with dynamic button pressing capability. Keyboard <NUM> preferably is an alphanumeric keyboard or telephone-type keypad. However, other types of keyboards also may be used. A composed item may be transmitted over wireless network <NUM> through communication subsystem <NUM>.

For voice communications, the overall operation of user equipment <NUM> is substantially similar, except that the received signals are output to speaker <NUM>, and signals for transmission are generated by microphone <NUM>. Alternative voice or audio I/O subsystems, such as a voice message recording subsystem, can also be implemented on user equipment <NUM>. Although voice or audio signal output is accomplished primarily through speaker <NUM>, display <NUM> can also be used to provide additional information, such as the identity of a calling party, duration of a voice call, or other voice call related information.

Referring now to <FIG>, a block diagram of communication subsystem component <NUM> of user equipment <NUM> of <FIG> is shown. Communication subsystem <NUM> includes receiver <NUM> and transmitter <NUM>, as well as associated components, such as one or more embedded or internal antenna elements <NUM> and <NUM>, local oscillators (LOs) <NUM>, and a processing module, such as a digital signal processor (DSP) <NUM>. The particular design of communication subsystem <NUM> is dependent upon the communication network <NUM> with which user equipment <NUM> is intended to operate. Thus, it should be understood that the design illustrated in <FIG> serves only as one example.

Signals received by antenna <NUM> through wireless network <NUM> are input to receiver <NUM>, which may perform such common receiver functions as signal amplification, frequency down conversion, filtering, channel selection, and analog-to-digital (A/D) conversion. A/D conversion of a received signal allows more complex communication functions, such as demodulation and decoding, to be performed in DSP <NUM>. In a similar manner, signals to be transmitted are processed, including modulation and encoding, by DSP <NUM>. These DSP-processed signals are input to transmitter <NUM> for digital-to-analog (D/A) conversion, frequency up conversion, filtering, amplification and transmission over wireless network <NUM> via antenna <NUM>. DSP <NUM> not only processes communication signals, but also provides for receiver and transmitter control. For example, gains applied to communication signals in receiver <NUM> and transmitter <NUM> may be adaptively controlled through automatic gain control algorithms implemented in DSP <NUM>.

The wireless link between user equipment <NUM> and wireless network <NUM> can contain one or more different channels, typically different RF channels, and associated protocols used between user equipment <NUM> and wireless network <NUM>. An RF channel is a limited resource that must be conserved, typically due to limits in overall bandwidth and limited battery power of user equipment <NUM>.

When user equipment <NUM> is fully operational, transmitter <NUM> typically is keyed or turned on only when it is transmitting to wireless network <NUM> and is otherwise turned off to conserve resources. Similarly, receiver <NUM> is periodically turned off to conserve power until it is needed to receive signals or information during designated time periods.

One or more of the disclosed embodiments may be applied to types of communications and standards other than those described above with respect to <FIG>. For example, without limitation, the different illustrative embodiments may be implemented using LTE Advanced. Additionally, the wireless networks illustrated may take the form of or include <NUM> networks.

Turning now to <FIG>, a diagram of data processing system <NUM> is depicted in accordance with an illustrative embodiment. In this example, data processing system <NUM> is an example of one implementation of processing system <NUM> in node <NUM> in <FIG>. Data processing system <NUM>, or portions thereof, also may be used to implement one or more functions of user equipment <NUM> as illustrated in <FIG>. In this illustrative example, data processing system <NUM> includes communications fabric <NUM>, which provides communications between processor unit <NUM>, memory <NUM>, persistent storage <NUM>, communications unit <NUM>, input/output (I/O) unit <NUM>, and display <NUM>.

Processor unit <NUM> serves to execute instructions for software that may be loaded into memory <NUM>. Processor unit <NUM> may be a set of one or more processors or may be a multi-processor core, depending on the particular implementation. Further, processor unit <NUM> may be implemented using one or more heterogeneous processor systems, in which a main processor is present with secondary processors on a single chip. As another illustrative example, processor unit <NUM> may be a symmetric multi-processor system containing multiple processors of the same type.

Memory <NUM> and persistent storage <NUM> are examples of storage devices <NUM>. A storage device is any piece of hardware that is capable of storing information, such as, for example, without limitation, data, program code in functional form, and/or other suitable information either on a temporary basis and/or a permanent basis. Memory <NUM>, in these examples, may be, for example, a random access memory, or any other suitable volatile or non-volatile storage device. Persistent storage <NUM> may take various forms, depending on the particular implementation. For example, persistent storage <NUM> may contain one or more components or devices. For example, persistent storage <NUM> may be a hard drive, a flash memory, a rewritable optical disk, a rewritable magnetic tape, or some combination of the above. The media used by persistent storage <NUM> may be removable.

Communications unit <NUM>, in these examples, provides for communication with other data processing systems or devices. In these examples, communications unit <NUM> is a network interface card. Communications unit <NUM> may provide communications through the use of either or both physical and wireless communications links.

Input/output unit <NUM> allows for the input and output of data with other devices that may be connected to data processing system <NUM>. For example, input/output unit <NUM> may provide a connection for user input through a keyboard, a mouse, and/or some other suitable input device. Further, input/output unit <NUM> may send output to a printer. Display <NUM> provides a mechanism to display information to a user.

Instructions for the operating system, applications, and/or programs may be located in storage devices <NUM>, which are in communication with processor unit <NUM> through communications fabric <NUM>. In these illustrative examples, the instructions are in a functional form on persistent storage <NUM>. These instructions may be loaded into memory <NUM> in order to be run by processor unit <NUM>. The processes of the different embodiments may be performed by processor unit <NUM> using computer implemented instructions, which may be located in a memory, such as memory <NUM>.

These instructions are referred to as program code, computer usable program code, or computer readable program code that may be read and run by a processor in processor unit <NUM>. The program code, in the different embodiments, may be embodied on different physical or computer readable storage media, such as memory <NUM> or persistent storage <NUM>.

Program code <NUM> is located in a functional form on computer readable media <NUM> that is selectively removable and may be loaded onto or transferred to data processing system <NUM> to be run by processor unit <NUM>. Program code <NUM> and computer readable media <NUM> form computer program product <NUM>. In one example, computer readable media <NUM> may be computer readable storage media <NUM> or computer readable signal media <NUM>. Computer readable storage media <NUM> may include, for example, an optical or magnetic disc that is inserted or placed into a drive or other device that is part of persistent storage <NUM> for transfer onto a storage device, such as a hard drive, that is part of persistent storage <NUM>. Computer readable storage media <NUM> also may take the form of a persistent storage, such as a hard drive, a thumb drive, or a flash memory that is connected to data processing system <NUM>. In some instances, computer readable storage media <NUM> may not be removable from data processing system <NUM>.

Alternatively, program code <NUM> may be transferred to data processing system <NUM> using computer readable signal media <NUM>. Computer readable signal media <NUM> may be, for example, a propagated data signal containing program code <NUM>. For example, computer readable signal media <NUM> may be an electro-magnetic signal, an optical signal, and/or any other suitable type of signal. These signals may be transmitted over communications links, such as wireless communications links, an optical fiber cable, a coaxial cable, a wire, and/or any other suitable type of communications link. In other words, the communications link and/or the connection may be physical or wireless in the illustrative examples.

In some illustrative embodiments, program code <NUM> may be downloaded over a network to persistent storage <NUM> from another device or data processing system through computer readable signal media <NUM> for use within data processing system <NUM>. For instance, program code stored in a computer readable storage media in a server data processing system may be downloaded over a network from the server to data processing system <NUM>. The data processing system providing program code <NUM> may be a server computer, a client computer, or some other device capable of storing and transmitting program code <NUM>.

The different components illustrated for data processing system <NUM> are not meant to provide architectural limitations to the manner in which different embodiments may be implemented. The different illustrative embodiments may be implemented in a data processing system including components in addition to or in place of those illustrated for data processing system <NUM>. Other components shown in <FIG> can be varied from the illustrative examples shown. The different embodiments may be implemented using any hardware device or system capable of executing program code. As one example, data processing system <NUM> may include organic components integrated with inorganic components and/or may be comprised entirely of organic components excluding a human being. For example, a storage device may be comprised of an organic semiconductor.

As another example, a storage device in data processing system <NUM> is any hardware apparatus that may store data. Memory <NUM>, persistent storage <NUM>, and computer readable media <NUM> are examples of storage devices in a tangible form.

In another example, a bus system may be used to implement communications fabric <NUM> and may be comprised of one or more buses, such as a system bus or an input/output bus. Of course, the bus system may be implemented using any suitable type of architecture that provides for a transfer of data between different components or devices attached to the bus system. Additionally, communications unit <NUM> may include one or more devices used to transmit and receive data, such as a modem or a network adapter. Further, a memory may be, for example, memory <NUM> or a cache such as found in an interface and memory controller hub that may be present in communications fabric <NUM>.

The illustrations of hardware components in <FIG> are not meant to imply physical or architectural limitations to the manner in which different illustrative embodiments may be implemented. Other components in addition to or in place of the ones illustrated may be used. Some components may be unnecessary in some illustrative embodiments. Also, the blocks are presented to illustrate some functional components. One or more of these blocks may be combined or divided into different blocks when implemented in different illustrative embodiments.

Turning now to <FIG>, a block diagram illustrating communication environment <NUM> is depicted in accordance with an illustrative embodiment. Communication network <NUM> of <FIG> is an example of one implementation of communication environment <NUM> of <FIG>. Communication environment <NUM> includes one or more networks <NUM> in association with user equipment <NUM>. Wireless network <NUM> in <FIG> is an example of one implementation of network <NUM> in <FIG>. User equipment <NUM> in <FIG> and user equipment <NUM> in <FIG> are examples of user equipment <NUM> in <FIG>. As discussed above, user equipment <NUM> may include a variety of devices, such as mobile wireless communication devices including pagers, cellular phones, cellular smart-phones, wireless organizers, personal digital assistants, computers, laptops, handheld wireless communication devices, wirelessly enabled notebook computers and the like. In operation, user equipment <NUM> is in communication with network <NUM> via wireless communication channel <NUM> in the manner described above. Thus, network <NUM> and user equipment <NUM> exchange data packets via wireless channel <NUM>.

Network <NUM> includes one or more network nodes <NUM>. Wireless network node <NUM> of <FIG> is one example of node <NUM> of <FIG>. Node <NUM> may comprise a base transceiver station, as described above. Generically, node <NUM> may include any equipment, device, group of devices, or functionality that sends, receives, or otherwise processes data packets as they pass through network <NUM>. Thus, node <NUM> may itself comprise user equipment, as described above, which is a part of or in communication with network <NUM>.

In accordance with an illustrative embodiment, node <NUM> includes a module for performing a function of congestion detection <NUM>. Any system or method currently known, or which becomes known, for detecting congestion on network <NUM> may be employed to implement this function. Congestion detection <NUM> preferably may include continually estimating a level of congestion at node <NUM> or at any other location in network <NUM> that may affect processing by network <NUM> of data packets to be delivered to or received from user equipment <NUM>. Congestion may be considered detected when a current level of congestion is greater than a selected threshold. Congestion is not detected when the current level of congestion is less than selected threshold.

The congestion estimate within node <NUM>, or another network element, may be a combined measure with many different measurements as inputs, such as one or more of radio related measurements of signal power, interference, or other radio related measurements, as well as other measurements, such as the amount of queued data to be processed in node <NUM>, queuing delays, or other measurements. Modifications to the congestion estimation, or to the determination of whether or not congestion is considered detected, may be used. Such modifications may include one or more of filtering of the congestion estimate, application of hysteresis at the congestion threshold, or other modifications. The congestion estimation method and the selected threshold employed for congestion detection <NUM> may vary depending on the specific network node <NUM> or other element in which congestion detection <NUM> is implemented or for which congestion is to be determined.

In accordance with an illustrative embodiment, network node <NUM> includes a module for performing a function of data packet marking <NUM>. Data packet marking <NUM> includes marking data packets to be transmitted to user equipment <NUM>. Data packets are marked with a marker indicating "Congestion Experienced" if congestion is considered detected. Data packets are not marked if congestion is not detected.

Packet marking indicating "Congestion Experienced" may include the use of markings currently used or as proposed for Explicit Congestion Notification. Such marking includes marking two bits in the Internet Protocol (IP) header of a packet as '<NUM>'. Marking a packet "Congestion Experienced" in accordance with an illustrative embodiment may employ other marking schemes, dependent upon the types of data and packets to be transmitted, and may include marking in the header and/or in other portions of a data packet.

Node <NUM> includes structures and functionality to transmit data packets <NUM>, including marked and unmarked packets, via wireless communication channel <NUM>, to user equipment <NUM> in a normal manner. Similarly, user equipment <NUM> includes structures and functionality to receive the data packets <NUM> transmitted from network <NUM> in a normal manner.

In accordance with an illustrative embodiment, transmissions of data packets between network <NUM> and user equipment <NUM> may be at one or more adaptable codec rates <NUM>. In accordance with an illustrative embodiment, a sender, such as node <NUM>, and a receiver, such as user equipment <NUM>, are built or adapted and configured to support multiple codec rates <NUM>. Multiple codec rates <NUM> also may be referred to as a mode set. Examples of multiple codec rates <NUM> include the Adaptive MultiRate codec rates of <NUM> kbps, <NUM> kbps, <NUM> kbps, etc..

In accordance with an illustrative embodiment, user equipment <NUM> includes congestion response module <NUM>. Functions of congestion response module <NUM> may be implemented in software, firmware, or the like, such as in software running on the main processor or another processor provided in user equipment <NUM>. Functions of congestion response module <NUM> include functions to detect marked data packets <NUM> received by user equipment <NUM> and functions to implement codec rate adaptation sequences <NUM> in response to detected marked and unmarked data packets received by user equipment <NUM>. As will be discussed in more detail below, codec rate adaptation sequences <NUM> may include codec rate reduction sequence <NUM> and codec rate increase sequence <NUM>.

In accordance with an illustrative embodiment, when there is no congestion, and absent any constraints unrelated to Explicit Congestion Notification, the highest codec rate in a mode set established between a sender and receiver is assumed to be used by the sender. When the receiver, such as user equipment <NUM>, receives packets marked "Congestion Experienced", indicating congestion in network <NUM>, the receiver decides to which lower rate codec in the mode set to adapt to. This rate adaptation in response to congestion is defined by codec rate reduction sequence <NUM>. When congestion is cleared, unmarked data packets will be received and detected by the receiver. If one or more higher codec rates are available, the receiver decides to which higher rate codec to adapt to, or to remain at the current codec rate. This rate adaptation in response to clearing congestion is defined by codec rate increase sequence <NUM>.

Codec rate adaptation sequences <NUM>, including codec rate reduction sequence <NUM> and codec rate increase sequence <NUM>, may include system level configuration parameters that are provided by network <NUM>. Network provided codec rate adaptation sequences <NUM> may be static or dynamic. For example, codec rate adaptation sequence <NUM> parameters may be stored statically in a Home Subscriber System (HSS) as part of network <NUM>. Alternatively, codec rate adaptation sequence <NUM> parameters may be determined dynamically at a packet data network (PDN) gateway (PGW) on network <NUM>, for example, according to expected congestion and handling requirements and capacity. Codec rate adaptation sequences <NUM> from network <NUM> may be stored in network sender and receiver endpoints, such as user equipment <NUM>, as known parameters for a given user equipment <NUM>. Codec rate adaptation sequences <NUM> may be sent to the endpoints on attach or Tracking Area Update (TAU)/Routing Area Update (RAU)/Location Area Update (LAU) responses. For static codec rate adaptation sequences <NUM>, sequence parameters may be sent to the endpoints just once for a call or for multiple calls. Codec rate adaptation sequence <NUM> parameters may be delivered from network <NUM> to a receiving terminal, such as user equipment <NUM>, via system messages. For example, codec rate adaptation sequence <NUM> parameters may be delivered to user equipment <NUM> using user equipment attachment, user equipment service request, and handover procedures.

As an alternative to, or in addition to, rate adaptation sequences <NUM> provided by network <NUM>, endpoint senders and receivers, such as user equipment <NUM>, may be configured with preferred codec rate adaptation sequences <NUM>. In this case, the endpoints may adapt the codec rates according to the configuration in the manner described herein. If a receiver, such as user equipment <NUM>, with configured codec rate adaptation sequences <NUM> also receives codec rate adaptation sequences <NUM> from network <NUM>, an operational determination may be made to determine which of the two codec rate adaptation sequences <NUM>, from network <NUM> or configured on receiver <NUM>, will take precedence. In this case, network <NUM> may inform receiver <NUM> of the precedence or the precedence may be configured on receiver <NUM>. One or more of the codec rate adaptation sequences <NUM> or the precedence information configured on receiver <NUM> may be provided by an Open Mobile Alliance (OMA) Device Management (DM) object under operational policy.

If a codec rate adaptation sequence <NUM>, such as codec rate reduction sequence <NUM> or codec rate increase sequence <NUM>, is not specified by network <NUM> or configured on user equipment <NUM>, a default codec rate adaptation sequence <NUM> may be used. The default codec rate adaptation sequence <NUM> may follow the order of the codec rates in the codec set negotiated between user equipment <NUM> and network <NUM> at call setup. For example, if the negotiated codec rate set is (<NUM> kbps, <NUM> kbps, <NUM> kbps), then the default codec rate reduction sequence <NUM> may be (<NUM> kbps, <NUM> kbps, <NUM> kbps) and the default codec rate increase sequence <NUM> may be (<NUM> kbps, <NUM> kbps, <NUM> kbps).

Codec rate parameter values for the codec rate adaptation sequences <NUM> may be indicated as scalar values. For example, codec rate adaptation sequence <NUM> rate parameter values <NUM>, <NUM>, and <NUM> may indicate corresponding mode set bitrates of <NUM> kbps, <NUM> kbps, and <NUM> kbps, respectively. Optionally, codec rate adaptation sequence <NUM> may indicate real codec rates for adaptation directly.

Codec rate reduction sequence <NUM> and codec rate increase sequence <NUM> may use the same set of rates for their respective rate adaptation sequences, but in a reverse direction or order. For example, if codec rate increase sequence <NUM> uses the sequence (<NUM> kbps, <NUM> kbps, <NUM> kbps) for increasing the codec rate in response to congestion clearing, then codec rate reduction sequence <NUM> may use the sequence (<NUM> kbps, <NUM> kbps, <NUM> kbps) for decreasing the codec rate in response to congestion detection.

Alternatively, two different sets of rates may be configured for the codec rate reduction sequence <NUM> and for the codec rate increase sequence <NUM>, one set of rates for reducing the codec rate in response to detecting congestion and a different set of codec rates for increasing the codec rate in response to congestion clearing. For example, the codec rate reduction sequence <NUM> might be (<NUM> kbps, <NUM> kbps) with the codec rate increase sequence <NUM> being (<NUM> kbps, <NUM> kbps, <NUM> kbps). In this example, when congestion is detected, the rate steps down in one step from <NUM> kbps to <NUM> kbps. However, when congestion is cleared, the codec rate steps up in two steps, from <NUM> kbps to <NUM> kbps and from <NUM> kbps to <NUM> kbps.

In accordance with an illustrative embodiment, if a data packet marked "Congestion Experienced" is received by a receiving terminal, such as by user equipment <NUM>, then the codec rate is reduced by one step within the set of the negotiated or specified codec rates or one step according to codec rate reduction sequence <NUM>. Codec rate reduction may be implemented by user equipment <NUM> by generating and sending to node <NUM> an appropriate codec rate change request <NUM>. At this point, codec rate reduction inhibit timer <NUM>, provided in user equipment <NUM>, is started. While codec rate reduction inhibit timer <NUM> is running, the codec rate will not be reduced further, even if another marked data packet is received during this time.

The length of time that codec rate reduction inhibit timer <NUM> runs after being started is referred to herein as codec rate reduction inhibit time <NUM>. Codec rate reduction inhibit time <NUM> preferably should be set to a value that is longer than the round trip time between the two endpoints in communication, such as between node <NUM> and user equipment <NUM>, plus some additional observation time. Setting of rate reduction inhibit time <NUM> thus should allow sufficient time for the receiver to request the reduced codec rate from the sender, for the sender to switch to the reduced rate, and then for the network element, such as node <NUM>, that was experiencing congestion and marking data packets "Congestion Experienced" to observe that congestion has been cleared and to stop marking packets. Any appropriate or desired length of time may be used for codec rate reduction inhibit time <NUM> in accordance with illustrative embodiments. In accordance with illustrative embodiments, codec rate reduction inhibit time <NUM> may be configurable <NUM> or fixed <NUM>. Codec rate reduction inhibit time <NUM> may be dynamically provided by network <NUM>, such as via a Non Access Stratum (NAS) or a call setup message.

If a rate reduction does not relieve congestion on network <NUM>, node <NUM> may continue to mark data packets in order to trigger a further reduction in the codec rate. If the receiving terminal receives a data packet marked "Congestion Experienced" after the codec rate reduction inhibit timer <NUM> times out, the receiving terminal may initiate the next lower rate codec adaptation, such as in accordance with codec rate reduction sequence <NUM>, if the current codec rate is not the lowest in the mode set.

If a congestion condition on network <NUM> has not improved for some time period after network <NUM> has triggered a codec rate reduction, by marking data packets "Congestion Experienced" to indicate to receivers to initiate codec rate reduction for congestion control, then network <NUM> may determine that it is necessary to notify the receivers of the need for continued codec rate reduction. Network <NUM> may notify receivers, such as user equipment <NUM>, of the need for continued codec rate reduction to reduce network congestion by sending specific notifications on codec rate adaptation continuation to the receivers. Thus, in accordance with an illustrative embodiment, node <NUM> may include a module or function for providing codec rate adaptation continuation notification <NUM>.

Upon receiving a codec rate adaptation continuation notification, a receiver, such as user equipment <NUM>, may adapt to the next lower rate codec rate, if the current codec rate is not the lowest one. In certain special situations, such as when network <NUM> is heavily congested, the codec rate adaptation continuation notification may notify the receiver to initiate immediately the lowest codec rate. Thus, a codec rate adaptation continuation notification message sent by network <NUM>, such as by node <NUM>, for example, via broadcasting or specific message to network endpoints, such as user equipment <NUM>, may include a codec rate adaptation continuation notification type indicator that may take on one of two values, to indicate either a codec rate adaptation to the next lower codec rate or a codec rate adaptation to the lowest codec rate.

Other than sending codec rate adaptation continuation notifications to receivers, such as user equipment <NUM>, for the receivers to initiate continued codec rate reductions to senders, such as node <NUM>, codec rate adaptation continuation notifications can be sent by network <NUM> to senders, such as node <NUM>, directly. In this manner, senders may be notified directly to reduce the sending codec rate, without initiation from receivers. This may speed up congestion control in some cases.

In accordance with illustrative embodiments, use of codec rate adaptation continuation notifications to reduce congestion may be inclusive or exclusive with codec rate adaptation for congestion reduction using "Congestion Experienced" marking of data packets as described above. In cases where continued codec rate adaptation in accordance with illustrative embodiments is insufficient to clear a congestion condition, network <NUM> may employ other types of mechanisms for congestion control, such as dropping packets or services.

In accordance with an illustrative embodiment, when a codec rate is reduced in response to user equipment <NUM> receiving a data packet marked "Congestion Experienced", codec rate increase timer <NUM>, provided in user equipment <NUM>, may be started. Codec rate increase timer <NUM> is adapted to time codec rate increase time <NUM>. Codec rate increase time <NUM> typically may be much longer than codec rate reduction inhibit time <NUM>. For example, codec rate increase time <NUM> may be selected to be ten seconds or more. Any other appropriate or desired length of time may be used for codec rate increase time <NUM> in accordance with an illustrative embodiment. Using a longer time period for codec rate increase time <NUM> is preferable, because increasing the codec rate after congestion is cleared is much less critical than timely codec rate reduction for congestion control. Use of a longer codec rate increase time <NUM> can also reduce the potential for codec adaptation oscillation between codec rate reduction and increase. At least a portion of codec rate increase time <NUM> may be random <NUM>. Use of a random element in codec rate increase time <NUM> also helps to prevent oscillation between codec rate reduction and increase that might result if many user devices supported by a network node simultaneously request codec rate increases as their individual codec rate increase times simultaneously expire.

In accordance with an illustrative embodiment, when codec rate increase timer <NUM> expires, the codec rate may be increased by one step within the set of negotiated codec rates or increased one step according to codec rate increase sequence <NUM>. A codec rate increase may be implemented by user equipment <NUM> by generating and sending to node <NUM> an appropriate codec rate change request <NUM>. When a data packet marked "Congestion Experienced" is received while codec rate increase timer <NUM> is running, then the receiver, such as user equipment <NUM>, will reduce the codec rate, in the manner described above, and codec rate increase timer <NUM> will restart <NUM>. In addition, codec rate increase timer <NUM> will restart <NUM> when codec rate increase timer <NUM> expires, in order to allow for the codec rate to increase again when codec rate increase timer <NUM> expires. In this manner, illustrative embodiments provide a mechanism whereby the codec rate can gradually step back up to its highest value, absent any other constraints.

In accordance with illustrative embodiments, codec rate reduction inhibit timer <NUM> and codec rate increase timer <NUM> may operate independently. Alternatively, codec rate increase timer <NUM> may not be reset <NUM> while codec rate reduction inhibit timer <NUM> is running. However, because codec rate reduction inhibit time <NUM> is likely to be very short in comparison to codec rate increase time <NUM>, there is likely to be very little difference in performance between the two options.

In accordance with an alternative illustrative embodiment, data packets marked "Congestion Experienced" that are received by user equipment <NUM> may be ignored for purposes of restarting codec rate increase timer <NUM> while codec rate increase timer <NUM> is running. In this case, codec rate increase timer <NUM> is not restarted when marked packets are received while codec rate increase timer <NUM> is running. In this alternative embodiment, when codec rate increase timer <NUM> expires, user equipment <NUM> checks whether or not marked packets were received while codec rate increase timer <NUM> was running. If no marked packets were received while codec rate increase timer <NUM> was running, then the codec rate may be increased and codec rate increase timer <NUM> may be restarted. However, if marked packets were received while codec rate increase timer <NUM> was running, then codec rate increase timer <NUM> is restarted without increasing the codec rate. In this case, the next possible time when the codec rate can be increased is at the next expiration of codec rate increase timer <NUM>. As compared with the approach of restarting codec rate increase timer <NUM> whenever marked packets are received while codec rate increase timer <NUM> is running, as described above, this alternative approach may be simpler. However, in cases where a marked packet is received just after codec rate increase timer <NUM> is started, and no other marked packets are received while codec rate increase timer <NUM> is running, this alternative approach has the effect of almost doubling the time to increase the codec rate, because user equipment <NUM> must wait for almost two entire codec rate increase time periods to expire before increasing the codec rate.

Explicit Congestion Notification based codec adaptation for congestion control as disclosed herein may not be desirable for priority users and priority or emergency services, except in catastrophic situations. Thus, in accordance with an illustrative embodiment, user equipment <NUM> may include appropriate functionality to provide for priority/emergency handling <NUM>.

Emergency services usually are carried over emergency bearers, such as connections established with either an emergency attach or an emergency Public Data Network (PDN) connection establishment. Thus, network <NUM> may not enable Explicit Congestion Notification as described herein for emergency bearers and priority/emergency handling <NUM> for user equipment <NUM> may include knowing that codec rate adaptation as described herein will not be applied on emergency bearers.

In accordance with an illustrative embodiment, under normal operation, priority/emergency handling <NUM> provides that codec rate adaptation as described herein will not be applied to priority users and priority/emergency services. However, if a catastrophic condition occurs, massive numbers of simultaneous service requests, such as emergency calls, may be made to the system. In accordance with an illustrative embodiment, priority/emergency handling <NUM> may provide for applying codec rate adaptation as disclosed herein to such emergency calls if the number of such emergency calls exceeds a specific threshold number or the percentage of all calls that are emergency calls exceeds a threshold percentage. Handling of emergency calls when such catastrophic conditions occur may be realized by network <NUM> by marking data packets "Congestion Experienced" in the packet delivery for emergency services when a catastrophic condition occurs and otherwise not marking such data packets.

In accordance with an illustrative embodiment, priority/emergency handling <NUM> may provide that very high priority user equipment <NUM>, by a very special user, need not implement codec rate reduction as described herein per policy control rule and/or authorization by the Home Public Land Mobile Network (HPLMN) operator. Very high priority user equipment may not be allowed to ignore codec rate reduction by a Visited Public Land Mobile Network (VPLMN) operator.

The illustration of <FIG> is not meant to imply physical or architectural limitations to the manner in which different embodiments may be implemented. Other components in addition and/or in place of the ones illustrated may be used. Some components may be unnecessary in some embodiments. Also, the blocks are presented to illustrate some functional components. One or more of these blocks may be combined and/or divided into different blocks when implemented in different advantageous embodiments.

An example of codec rate reduction in accordance with an illustrative embodiment is illustrated in <FIG>. The example presented in <FIG> illustrates codec rate reduction in accordance with an illustrative embodiment when congestion in the downlink direction, from network to user equipment, is detected within a network node. Initially, data packets from a sender peer Multimedia Telephony Services for IP Multimedia Subsystem (MTSI) client <NUM> are delivered via network <NUM> and network node <NUM>, such as an eNodeB network node, to an MTSI client in user equipment (UE) <NUM> at a rate of <NUM> kbps. Congestion is not initially experienced, so data packets are not marked "Congestion Experienced" (CE) by node <NUM>. At some point in time, congestion is detected in the node <NUM>. In response to detecting congestion, node <NUM> begins to mark data packets "Congestion Experienced". Such a marked packet is received by user equipment <NUM>. In response to receiving a marked packet, user equipment <NUM> reduces the codec rate by one step <NUM>. Codec rate reduction by user equipment <NUM> includes sending a packet with a Codec Mode Request (CMR) <NUM> requesting a rate change to <NUM> kbps back through node <NUM> and network <NUM> to client <NUM>. At the same time as requesting the rate change, user equipment <NUM> starts codec rate reduction inhibit time <NUM> and codec rate increase time <NUM> running.

As congestion continues to be detected in node <NUM> data packets continue to be marked. However, as long as codec rate reduction inhibit time <NUM> is running, marked packets received by user equipment <NUM> do not result in further rate reductions. Eventually, the requested rate change is received by client <NUM>, and the transmission rate is reduced to <NUM> kbps, as requested by user equipment <NUM>. Packets continue to be marked by node <NUM> until, eventually, the reduced codec rate results in clearing the congestion in node <NUM>. Node <NUM> detects this relief in congestion <NUM>, and thus stops marking packets at this point. At the point in time where codec rate inhibit time <NUM> expires <NUM>, the congestion has been cleared, packets are not being marked by node <NUM>, and thus no further codec rate reduction is initiated by user equipment <NUM>.

An example of codec rate increase in accordance with an illustrative embodiment is illustrated in <FIG>. The example presented in <FIG> illustrates codec rate increase in accordance with an illustrative embodiment in the downlink direction, from network to user equipment, when there is no congestion detected within a network node. Initially, data packets from a sender peer Multimedia Telephony Services for IP Multimedia Subsystem (MTSI) client <NUM> are delivered via network <NUM> and network node <NUM>, such as an eNodeB network node, to an MTSI client in user equipment (UE) <NUM> at a rate of <NUM> kbps. Congestion is not detected in node <NUM>, so data packets are not marked "Congestion Experienced" (CE) by node <NUM>. A codec rate increase timer is running as a result of an earlier rate reduction <NUM>. As long as the codec rate increase timer is running, client <NUM> does not attempt to increase the codec rate, even though data packets received by client <NUM> are not marked, indicating no congestion.

Eventually, the codec rate increase timer expires <NUM>. In response to the codec rate increase timer expiring, user equipment <NUM> increases the codec rate by one step <NUM>. The codec rate increase by user equipment <NUM> includes sending a packet with a Codec Mode Request (CMR) <NUM>, requesting a rate increase to <NUM> kbps, back to client <NUM> via node <NUM> and network <NUM>. At the same time as requesting the rate increase, user equipment <NUM> restarts the codec rate increase timer <NUM>. Eventually, the rate increase request from user equipment <NUM> is received by client <NUM>, and client <NUM> increases the transmission rate to <NUM> kbps <NUM>, as requested. The increased codec rate does not result in congestion, so data packets continue not to be marked.

Eventually, the restarted codec rate increase timer expires <NUM>. In response to the codec rate increase timer expiring again, user equipment <NUM> increases the codec rate by another step <NUM>. This codec rate increase by user equipment <NUM> includes sending a packet with a Codec Mode Request (CMR) <NUM>, requesting a rate increase to <NUM> kbps, back to client <NUM> via node <NUM> and network <NUM>. At the same time as requesting the rate increase, user equipment <NUM> restarts the codec rate increase timer <NUM>. Eventually, the rate increase request from user equipment <NUM> is received by client <NUM>, and client <NUM> increases the transmission rate to <NUM> kbps <NUM>, as requested. The further increased codec rate does not result in congestion, so data packets continue not to be marked.

The flowchart of <FIG> illustrates an example method <NUM> for codec rate reduction in accordance with an illustrative embodiment. Method <NUM> may be implemented, for example, in user equipment, such as in user equipment <NUM> of <FIG>. Received data packets are examined, preferably continuously, to determine when a packet marked "Congestion Experienced" is detected (step <NUM>). When a marked packet is detected, the rate is reduced, if possible (step <NUM>). For example, step <NUM> may include reducing the codec rate by one step within a set of the negotiated or specified codec rates or one step according to a codec rate reduction sequence. It may not be possible to reduce the codec rate if the codec rate is already at the lowest rate. Step <NUM> may include generating and sending an appropriate codec rate change request from user equipment to the network. The codec rate reduction inhibit timer is started (step <NUM>), preferably at substantially the same time or simultaneously with step <NUM>. Steps <NUM> and <NUM> may be performed in any order. Until the codec rate reduction inhibit timer expires, no further action is taken to reduce the rate, even if another marked data packet is received during this time. When it is determined that the codec rate reduction inhibit timer has expired (step <NUM>), the method returns to step <NUM> to look for marked data packets indicating that further rate reduction is required.

The flowchart of <FIG> illustrates an example method <NUM> for codec rate increase in accordance with an illustrative embodiment. Method <NUM> may be implemented, for example, in user equipment, such as in user equipment <NUM> of <FIG>. Method <NUM> begins by starting a codec rate increase timer (step <NUM>). It is determined whether a packet marked "Congestion Experienced" is received during the time that the codec rate increase timer is running (step <NUM>). If a marked packet is received during the time that the codec rate increase timer is running, the codec rate increase timer is restarted, by returning to step <NUM>. It is determined when the codec rate increase timer expires (step <NUM>). When the codec rate increase time expires, it is determined whether the current rate is the highest rate (step <NUM>). If it is determined that the current rate is the highest rate, then no further rate increase is possible, and the codec rate increase timer is restarted by returning to step <NUM>. If it is determined that the current rate is not the highest rate, then the codec rate is increased (step <NUM>). Step <NUM> may include increasing the codec rate by one step within a set of negotiated codec rates or by one step according to a codec rate increase sequence. Step <NUM> may include generating and sending from user equipment an appropriate codec rate change request. The codec rate increase timer is restarted after increasing the rate, by returning to step <NUM>.

The flowchart of <FIG> illustrates an example of another method <NUM> for codec rate increase in accordance with an illustrative embodiment. Method <NUM> may be implemented, for example, in user equipment, such as in user equipment <NUM> of <FIG>. Method <NUM> begins by starting a codec rate increase timer (step <NUM>). It is determined when codec rate increase timer expires (step <NUM>). When codec rate increase timer is determined to have expired, it is determined whether a packet marked "Congestion Experienced" was received during the rate increase time timed by the codec rate increase timer (step <NUM>). If a marked packet was received during the rate increase time, the codec rate increase timer is restarted, by returning to step <NUM>. If a marked packet was not received during the rate increase time, it is determined whether the current rate is the highest rate (step <NUM>). If the current rate is the highest rate, no increase in the rate is possible, and the codec rate increase timer is restarted by returning to step <NUM>. If the current rate is not the highest rate, the codec rate is increased (step <NUM>). Step <NUM> may include increasing the codec rate by one step within a set of negotiated codec rates or by one step according to a codec rate increase sequence. Step <NUM> may include generating and sending from user equipment an appropriate codec rate change request. The codec rate increase timer is restarted after increasing the rate, by returning to step <NUM>.

The flowchart of <FIG> illustrates another example of a method <NUM> for rate adaptation in accordance with an illustrative embodiment. In accordance with method <NUM>, the adaptation of codec rate using Explicit Congestion Notification (ECN) is controlled by two parameters, the code rate reduction inhibit time and the code rate increase time. These parameters may be configured into a Multimedia Telephony Services for IP Multimedia Subsystem (MTSI) client based on operator policy, for example, using Open Mobile Alliance -Device Management (OMA-DM). If the parameters are not configured, then default values of <NUM> and <NUM> seconds, respectively, may be used.

It is determined if a receiving MTSI client in terminal that supports and has negotiated ECN detects an ECN "Congestion Experienced" (CE) marking in a received Internet Protocol/User Datagram Protocol/Real-time Transport Protocol (IP/UDP/RTP) packet (step <NUM>). If a marked packet is received, it is determined whether the receiving MTSI client is already operating at the lowest codec rate (step <NUM>). If the MTSI client is not already operating at the lowest codec rate, the receiving MTSI client in terminal reduces the codec rate by one codec rate within the set of negotiated codec rates (step <NUM>). The receiving MTSI client in terminal notifies the sender of the new code rate via the Codec Mode Request (CMR) bits in the RTP payload if supported by the codec and via a Temporary Maximum Media Stream Bit Rate Request (TMMBR) message if the RTP payload for the codec does not support a CMR field (step <NUM>). The receiving MTSI client in terminal starts a codec rate reduction inhibit timer with the value of the codec rate reduction inhibit time (step <NUM>). The receiving MTSI client in terminal starts or, if already started running, restarts a codec rate increase timer with the value of the codec rate increase time (step <NUM>).

It is determined whether the codec rate reduction inhibit timer is running (step <NUM>). If the codec rate reduction inhibit timer is running, the receiving MTSI client in terminal will not act on the ECN marking of received IP/UDP/RTP packets (step <NUM>). If the codec rate reduction inhibit timer expires, the receiving MTSI client in terminal shall again act on the ECN marking of received IP/UDP/RTP packets.

It is determined whether the codec rate increase timer expires (step <NUM>). It is determined if there is no ECN-CE marked IP/UDP/RTP packet received during the time period (step <NUM>). It is determined whether the rate is already at the highest codec rate (step <NUM>). If the codec rate timer expires and there is no ECN-CE marked IP/UDP/RTO packet received during the time period and the rate is not already at the highest codec rate the MTSI client in terminal increases the codec rate by one codec rate within the set of negotiated codec rates (step <NUM>). The receiving MTSI client in terminal notifies the sender of the new codec rate via the CMR bits in the RTP payload, if supported by the codec, and via a TMMBR message if the RTP payload for the codec does not support a CMR field (step <NUM>). The receiving MTSI client in terminal then starts the codec rate increase timer with the value of the codec rate increase time.

Claim 1:
A computer implemented method for controlling congestion on a network (<NUM>), comprising:
receiving, by a receiver (<NUM>, <NUM>, <NUM>, <NUM>), at least one packet sent by a sender, wherein the at least one packet is marked with a marker indicating "Congestion Experienced" when congestion between the sender (<NUM>) and the receiver is detected or the at least one packet is not marked with the marker indicating "Congestion Experienced" when no congestion is detected between the sender (<NUM>) and the receiver;
on receiving the at least one packet at the receiver, the method comprises:
i) determining by the receiver (<NUM>, <NUM>, <NUM>, <NUM>), based on the packet not being marked with the marker, that there is no congestion between a sender (<NUM>) and the receiver and responsive to determining that there is no congestion, assuming by the receiver that a highest data rate is used by the sender between the sender and the receiver;
ii) determining by the receiver, based on the packet being marked with the marker, that there is congestion between the sender (<NUM>) and the receiver and responsive to determining that there is congestion, determining that a rate adaptation is required; and
setting the rate adaptation by determining a lower data rate, the rate adaptation being set based upon a rate adaptation sequence; and
sending by the receiver to the sender a data rate change request (<NUM>) including the lower data rate.