Patent Description:
Internet protocol (IP) networks and other types of networks can be used to carry data for different types of calls. Various types of calls include voice and video communications and conferencing, and streaming services including audio and video streaming. Audio and video data are typically encoded for transmission via these networks by one or more codecs along the way. A codec may include hardware or software used to encode and decode data, such as audio and/or video data in a signal. A media gateway/media gateway controller and/or a session border controller, located along a network path between the two endpoints, may perform different types of services for the transmission of calls, including transcoding and encryption.

The impact on the internal resources available to the network component varies, depending upon the codec(s) used. Depending upon which codecs are used, transcoding or other services may be necessary at the network component. As the volume of media traffic carried by communications networks continues to increase, the need for network components to provide ever greater capability to handle media traffic in a manner that more efficiently uses resources internal to network components increases as well.

Various codecs may include certain features designed to improve call connectivity and reliability. For example, the Enhanced Voice Service (EVS) codec includes a "channel aware mode. " The channel aware mode packages data in a way such that it can more easily be recovered if a particular packet is lost during transit. Thus, the channel aware mode utilizes additional resources to improve call quality. It is desirable however for communication service providers to improve call quality while minimizing the use of additional resources.

<CIT> relates to systems and methods for dynamically causing a terminal to change audio codec modes during a session with another terminal.

The present disclosure is best understood from the following detailed description when read with the accompanying figures.

Aspects of the present invention are defined with reference to independent claims <NUM>, <NUM> and <NUM>.

The following disclosure provides many different embodiments, or examples, for implementing different features. Specific examples of components and arrangements are described below to simplify the present disclosure. These are merely examples and are not intended to be limiting.

As described above, it is desirable for communication service providers (also referred to as carriers) to improve call quality while minimizing the use of additional resources. Providing a communication service often involves a transcoding process. Transcoding is the process by which data is transferred from one coding format (i.e., codec) to another coding format. Carriers typically require high volumes of transcoding processing power during peak hours. This is an expense for carriers. Thus, carriers seek to use codecs and transcoding processes that minimize processing resources.

EVS (Enhanced Voice Services) is a new speech codec that introduces an enhanced mode referred to as "Channel Aware Mode. " The Channel Aware Mode increases the amount of robustness in call processing to recover data lost during transmission. In other words, the Channel Aware Mode is a tool to combat transmission errors in poor network conditions. Transmission errors could be, but are not limited to, discarded packets due to bit errors or packets arriving late (packet arrival timing is critical in real-time communications systems).

The Channel Aware Mode, while providing increased call quality in poor network conditions, increases the computational complexity for call processing systems. The added computational complexity results from redundant information being placed into packets. This redundant information is useful to conceal transmission errors and provide superior audio quality in harsh transmission conditions. However, transcoding data that is being transmitted with the Channel Aware mode utilizes more processing resources.

The added computational complexity is independent of network conditions. In other words, with Channel Aware Mode on, redundant information is transmitted in ideal network conditions, regardless of whether it is useful. Thus, in good network conditions, the Channel Aware Mode utilizes more processing resources but does not provide much value.

Accordingly, the present disclosure is directed to toggling the enhanced mode (e.g., Channel Aware Mode) on or off in response to certain conditions. According to one example, a network node, such as a MRFP processes a call between a first endpoint and a second endpoint. The processing of the call may be performed by one of several virtual machines. When the call is first established, the default may be for the channel aware mode to be off. During the call, the network node monitors packet loss on at least one leg of the call. If the packet loss exceeds a particular threshold, then it becomes desirable to use the channel aware mode to add increased call robustness. The channel aware mode is then toggled on. Turning on the enhanced mode increases the computational resources utilized by the virtual machine. If it is determined that turning on the enhanced mode for that particular call increases the computational load above a threshold, then that call can be moved to a different virtual machine that has spare capacity.

<FIG> is a diagram showing an illustrative network component <NUM> that bridges a first network <NUM> and a second network <NUM>. According to the present example, the network component <NUM> handles traffic passing between the first network <NUM> and the second network <NUM>. For example, the network component may handle Voice over Internet Protocol (VoIP) traffic between a first endpoint <NUM> and a second endpoint <NUM>.

The first network <NUM> may be a private network. A private network uses a private logical address (e.g., Internet Protocol (IP) address)). Such networks are typically used for a personal home network, an office network, or an enterprise Local Area Network (LAN). Endpoint devices such as endpoint <NUM> may be connected to the private network <NUM>. The private network <NUM> may also be connected to a public network such as the Internet. Thus, devices on the first network <NUM> may have access to the Internet.

The second network <NUM> may be a public network such as the Internet. Endpoint devices such as endpoint <NUM> may connect to the public second network <NUM> through an Internet service provider. Through both networks <NUM>, <NUM>, the endpoints <NUM>, <NUM> may communicate. A telecommunication service may utilize telecommunication components such as the network component <NUM> to process data passing between two different networks. The network component <NUM> may include several nodes, both physical and virtual, each node being able to handle a predefined number of subscribers. For example, each node may be able to handle <NUM>,<NUM> calls.

The endpoints <NUM>, <NUM> may be user devices such as desktop computers, laptop computers, mobile phones, or tablets. In the present example, endpoint <NUM> is in communication with the network component <NUM> through the first network <NUM>. Endpoint <NUM> is in communication with the network component <NUM> through the second network <NUM>.

The network component <NUM> includes a plurality of control nodes <NUM> (<NUM>-<NUM>, <NUM>-<NUM>. <NUM>-n) and a plurality of process nodes <NUM> (<NUM>-<NUM>, <NUM>-<NUM>. In one example, the process nodes <NUM> are virtual nodes. In one example, the control nodes are signaling nodes and the process nodes <NUM> are media nodes. To establish a communication session between the two endpoints <NUM>, <NUM>, any one of the control nodes <NUM> establishes a connection between the two endpoints. Then, any one of the process nodes <NUM> may process traffic between the two endpoints. The communication session may have a first leg <NUM> in the first network <NUM> and a second leg <NUM> in the second network <NUM>.

As a further example, endpoints <NUM>, <NUM> may be analog or digital telephones. In one embodiment, the network component <NUM> may be a media gateway (MG). A MG may perform various services for a call originating from or routing to any of endpoints <NUM>,<NUM>, such as transcoding a call for disparate networks or devices. Transcoding may refer to a conversion between different transmission and/or coding types for a call and may include transrating (a bit-rate conversion for a call). The network component <NUM> is not limited to any particular hardware type, but may be implemented in some embodiments using commodity servers running an operating system (e.g., Linux) with SBC, MG, MGC, MRFC, and/or MRFP functionality included as applications running on top of the operating system. Various embodiments may include the SBC, MG, MGC, MRFP and/or MRFC functionality as computer-readable code that is executed by processors of the network components.

The networks <NUM>/<NUM> may include any kind of network such as a Local Area Network (LAN), a cellular data network (e.g., an LTE network or a <NUM> network), the Internet, and/or the like, utilizing various types of network protocols, such as IP or asynchronous transfer mode (ATM) to name just a few examples.

In an embodiment, a call may originate from endpoint <NUM> towards endpoint <NUM>. As an example, the call may be made using SIP. When using SIP, an INVITE with a Session Description Protocol (SDP) offer attached to the message from endpoint <NUM> reaches the network component <NUM>. SDP is used for call session initialization, including negotiation of parameters for the call session. Among other things, the INVITE message may include a list of codecs available to the endpoint <NUM>. Some examples of available codecs could include audio codecs such as Enhanced Variable Rate Codec (EVRC), Adaptive Multi-Rate (AMR), G. <NUM>, Internet Low Bit Rate Codec (iLBC), AMR-WB, G. <NUM>, and/or video codecs such as H. <NUM>, Moving Picture Experts Group (MPEG), or VP8, to name just a few examples of each. In the case of LTE, the available codecs may include EVS. Codecs, such as those listed above, may have different impacts on the network component <NUM>'s internal resources, such as one or more of its DSP, bandwidth, hardware accelerator, memory, CPU, etc. Different codec parameters, such as bandwidth and bitrate, may also affect usage of internal resources of network component <NUM>.

The network component <NUM> may have a list of codecs that are available to the destination endpoint <NUM>. In embodiments of the present disclosure, the network component <NUM> determines the utilization of one or more of its internal resources by measurement or estimation. Based on the utilization determination, the network component <NUM> may select codec parameters to balance resource usage and call quality should transcoding be used.

<FIG> is a flowchart showing an illustrative method for toggling an enhanced mode. According to the present example, the method <NUM> includes a process <NUM> for monitoring packet loss. This may be performed by a process node such as an MRFP (Media Resource Function Processor) node. In one example, the process node monitors packet loss for a specific call leg of a call between a first endpoint and a second endpoint. That call leg may be handled by one of a plurality of virtual machines associated with the process node. In other words, the process node may utilize multiple virtual machines for processing calls. Additionally, the process node may monitor the packet loss for each one of the calls on each one of the virtual machines separately. Because each call being handled by the process node may have a different route through the network, different calls may experience different levels of packet loss.

Packet loss may occur for a variety of reasons. In some examples, signal interference can cause packets to drop. Specifically, some networks include wireless portions. Communication signals for wireless network may be prone to interference and other anomalies that cause the data within the signals to be lost. In some cases, network congestion can result in packet loss. This is because real time communication sessions may drop packets that arrive too late.

At process <NUM>, the process node determines whether packet loss exceeds a first threshold. If the first threshold has not been exceeded, then the process node keeps the enhanced mode off. If, however, the packet loss exceeds the first threshold, then the process node turns on the enhanced mode at process <NUM>. The first threshold may be a customizable value. Different carriers may choose to set different threshold values for turning on the enhanced mode.

Turning on the enhanced mode may be done in one of a variety of manners. In some examples, when the call is first being established, the process node they negotiate the ability to toggle the enhancement on and off during the call. If so, then the process node can use this mechanism. In some examples, the process node may send a SIP invite message to continue the call with the enhanced mode on. In some examples, this may involve renegotiating the codec used to continue the call. Other mechanisms for turning on the enhanced mode are contemplated.

The enhanced mode involves a number of additional tasks that provide increased error resilience. For example, when a codec is using the channel aware mode, data is encoded such that data in a particular packet is redundantly placed in neighboring packets (i.e., packets that are sent after the particular packet). Thus, if the particular packet is lost, it can be partially reconstructed from data in neighboring packets.

As described above, turning on enhanced mode for a particular call increases the processing resources used to process that call. Thus, at process <NUM>, the process node determines whether the processing demand on that node exceeds a threshold. If the processing demand has not exceeded the threshold, then the process node continues to process the call as normal. If, however, the processing demand does in fact exceed the threshold, then the process node moves the call having the newly toggled on enhanced mode to a different virtual machine. The different virtual machine may be one that is already provisioned and thus moving the call to that virtual machine is seamless.

In other words, moving the call from one virtual machine to another is transparent to the end devices <NUM>, <NUM> as the network addresses associated with the call between the endpoints do not change when the call is transferred. Specifically, the call is transferred without changing network addresses such as the IP addresses and port numbers of the various devices associated with the call. Specifically, each of the endpoints <NUM>, <NUM> has an IP address and port number used to communicate over the communication session between the endpoints. Additionally, each network component (e.g., <NUM>) along the communication session may have an IP address and port number for sending and receiving data to and from the first endpoint <NUM>, as well as a different IP address and port number for sending and receiving data to and from the second endpoint <NUM>. When the communication session is transferred from one virtual machine to another, none of these network addresses are changed.

As will be explained in further detail below in the text accompanying <FIG>, the process node may be embodied as multiple virtual machines. Each virtual machine may process a certain number of calls. Each virtual machine is a particular processing capacity. If the capacity for the virtual machine is exceeded due to one of the calls it is processing being switched to enhanced mode on, then one or more calls from that virtual machine may be transferred to another virtual machine that does have capacity. In some examples, a call other than the one recently having its enhanced mode turned on is passed to a different virtual machine as a result of a call having its enhanced mode turned on.

After the call has been transferred in process <NUM>, the process node continues to monitor packet loss at process <NUM>. Packet loss may change over time as network conditions change. Thus, improvement or conditions may make the use of the enhanced mode unnecessary.

At process <NUM> the process node determines whether packet loss has fallen below a second threshold. If the process node determines that packet loss has not fallen below the second threshold, then the process node keeps the enhanced mode on. If, however, the process node determines that packet loss has in fact fallen below the second threshold, then the process node toggles off the enhanced mode process <NUM>.

Turning off the enhanced mode may be done in one of a variety of manners. In some examples, when the call is first being established, the process node they negotiate the ability to toggle the enhancement on and off during the call. If so, then the process node may use this mechanism to turn off enhanced mode. In some examples, the process node may send a SIP invite message to continue the call with the enhanced mode off. In some examples, this may involve renegotiating the codec used to continue the call. Other mechanisms for turning off the enhanced mode are contemplated.

<FIG> is a graph <NUM> showing toggling points as packet loss changes over time. According to the present example, the vertical axis <NUM> represents packet loss and the horizontal axis <NUM> represents time. Thus, line <NUM> represents packet loss over time. The graph <NUM> includes a first threshold <NUM> and a second threshold. In the present example, the first threshold <NUM> is associated with toggling enhanced mode on. Additionally, the second threshold <NUM> is associated with toggling the enhanced mode off.

The various thresholds <NUM>, <NUM> may be set in customizable by the carrier. These thresholds may also be dynamic and change over time. For example, the thresholds <NUM>, <NUM> may change based on a variety of factors, including the cost of processing resources, the current network conditions, the geographic locations of the endpoints, the time of day, the day of the week, month, or year, and other factors. In some examples, the thresholds <NUM>, <NUM> may be identical.

At point <NUM>, packet loss exceeds the first threshold <NUM>. This would trigger turning on the enhanced mode as discussed above at process <NUM>. At point <NUM>, the packet loss falls below the second threshold <NUM>. This would trigger turning off the enhanced mode as discussed above at process <NUM>.

<FIG> are diagrams showing call handling. <FIG> illustrates four calls handled by a first virtual machine <NUM> and two calls handled by a second virtual machine. It is noted that practical implementations will include virtual machines with much greater call capacity, such as <NUM>,<NUM> calls. The examples shown here are for discussion purposes.

In the present example, call <NUM> (<NUM>-<NUM>) has its enhanced mode toggled on as a result of packet loss on that call. In one example, turning on the enhanced mode for call <NUM> causes the first virtual machine <NUM> to exceed processing capacity. However, virtual machine <NUM> has spare capacity. Accordingly, in one example, call <NUM> is moved to virtual machine <NUM> as shown in <FIG>. Call <NUM> (<NUM>-<NUM>), call <NUM> (<NUM>-<NUM>), and call <NUM> (<NUM>-<NUM>) remain on virtual machine <NUM>.

<FIG> shows an example in which the call that is transferred to the different virtual machine is not the call for which enhanced mode was turned on. Specifically, call three is moved from virtual machine <NUM> to virtual machine <NUM> after the enhanced mode is turned on for call <NUM>.

In some examples, if all virtual machines associated with a particular process node are at full capacity, then an additional virtual machine may be provisioned. Conversely, if the overall capacity across multiple virtual machines falls below a certain threshold, then a particular virtual machine may be decommissioned. Such elasticity may be provided by, for example, a network that utilizes network function virtualization (NFV).

<FIG> is a diagram showing network function virtualization <NUM>. According to the present example, a Network Function Virtualization Infrastructure (NFVI) <NUM> is used to provide network function virtualization <NUM>. The NFVI <NUM> provides the infrastructure for a number of VNFs <NUM>. Both the VNFs <NUM> and the NFVI <NUM> are managed by an NFV management module <NUM>.

The NFVI <NUM> includes a set of physical resources <NUM> that are used to provide a set of virtual resources <NUM>. The physical resources <NUM> include computing resources <NUM>, storage resources <NUM>, and network resources <NUM>. Other resources, such as input/output resources are contemplated as well. The physical resources <NUM> are typically embodied as a plurality of physical computing systems, sometimes referred to as servers, within a datacenter. For example, a datacenter may include several servers that are positioned on racks and interconnected via physical network cables. Each of the servers includes hardware including a physical processor, a memory, and a network interface. Some servers may be designed primarily for processing power and some servers may be designed primarily for storage. In one example, the servers are commodity servers that include a number of physical processors, such as x86 processors. The servers utilize an operating system, such as Linux, to provide various applications with access to the hardware of the servers. More specifically, the operating system will schedule processing tasks on the physical processor of the server and allocate physical memory for use by the application.

The computing resources <NUM> include a plurality of processors within a plurality of physical computing systems. The processors are designed to process machine readable instructions to perform specifically designed tasks. The processors can be designed to work together to provide parallel processing capabilities.

The storage resources <NUM> include various types of memory. Some types of memory, such as non-volatile types of memory, typically have large storage volume but relatively slow performance. The storage resources <NUM> may include a series of hard disk drives or solid state drives that store data in the form of machine readable instructions as well as large amounts of data. The storage resources <NUM> may also include volatile forms of memory, such as those used for Random Access Memory (RAM), which are optimized for speed and are often referred to as "working memory.

The network resources <NUM> include the physical network infrastructure that provides communication between the physical computing systems as well as to an external network such as the Internet. The physical network infrastructure includes the physical cables, such as Ethernet or fiber optic, that connect the physical systems to routers, switches, and other networking equipment that provides the desired interconnectivity.

The physical resources <NUM> use hypervisors to provide a virtual computing environment that provides the virtual resources <NUM>. Specifically, the hypervisors provide virtual hardware to guest operating systems. A physical computing system may provide one or more virtual machines for use by guest operating systems. The virtual resources <NUM> include virtual computing resources <NUM>, virtual storage resources <NUM>, and virtual network resources <NUM>. Such virtual resources <NUM> may emulate their underlying physical resource counterparts.

The virtual computing resources <NUM> include virtual processors that execute machine readable instructions as a physical processor does. The hypervisor then maps the execution of those instructions to execution of instructions on a physical processor. The architecture of the virtual processor does not necessarily have to match the architecture of the underlying physical processor, which allows a variety of instruction set architectures to be used for various virtual machines.

The virtual storage resources <NUM> include short term and long term storage services. Specifically, the virtual machines may include virtual memory that is then mapped to physical memory by the hypervisor. There does not necessarily have to be a one-to-one mapping of virtual memory to physical memory. For example, two gigabytes of virtual working memory may be mapped to only one gigabyte of working memory in the physical system. Various paging techniques are then used to swap physical memory from working memory to a volatile storage memory to allow for such mapping.

Each virtual machine may run a guest operating system. The guest operating system may be similar to a host operating system. For example, the guest operating system may also be Linux. The guest operating system runs applications and provides such applications with access the virtual hardware of the virtual machines. For example, the guest operating system schedules processing tasks associated with the applications on the virtual processor. The guest operating system also provides the application with access to virtual memory associated with the virtual machines.

When the guest operating system provides applications running thereon with access to the virtual resources, the hypervisor of the underlying physical computing systems then maps those resources to the underlying physical resources. For example, when an application running on the guest operating system stores data in virtual memory, the hypervisor translates a virtual memory address into a physical memory address and the data is stored at that physical memory address. When the guest operating system schedules processing tasks for execution on the virtual processor, the hypervisor translates those processing tasks into executable instructions for the physical processor.

The virtual machines that are provided as part of the virtual resources <NUM> can be interconnected to each other through one or more virtual networks that make up the virtual networking resources <NUM>. Such virtual networks emulate physical networks. Virtual networks may include a number of machines, both physical and virtual, that are assigned a virtual network address. The virtual networks can also isolate sets of virtual machines as desired. This can be helpful if some virtual machines are owned and/or operated by one entity and other virtual machines are owned and/or operated by another entity.

The NFVI <NUM> is managed by an infrastructure manager <NUM>, which is part of the NFV management module <NUM>. The infrastructure manager <NUM> may operate under a set of pre-defined rules that instruct the infrastructure manager how to manage the NFVI <NUM>. Such rules may be adjusted by a human operator as desired. For example, such rules may instruct the infrastructure manager <NUM> how to provision additional virtual machines when instructed to do so. The infrastructure manager <NUM> may include hardware, software, or a combination of both to perform various management functions. For example, the infrastructure manager <NUM> may be an application that resides on one or more physical machines and can receive input from human administrators as well as other management functions. The infrastructure manager <NUM> can then manage the physical and virtual environment as appropriate. For example, if it is determined that more virtual machines are desired, then the infrastructure manager <NUM> can send an instruction to the NFVI to create an additional virtual machine and configure it for use by whatever entity uses that virtual machine. Additionally, the infrastructure management can cause the physical computing systems to enter standby mode if less physical computing power is desired. The infrastructure manager <NUM> can also take such physical computing systems out of standby mode when more computing power is desired.

In the present example, the infrastructure manager <NUM> includes two components. Specifically, the infrastructure manager <NUM> includes a cloud manager <NUM> and an SDN controller <NUM>. The cloud manager <NUM> is responsible for managing the cloud computing environment provided by the virtual resources <NUM> of the NFVI <NUM>. For example, the cloud manager <NUM> may be responsible for provisioning additional virtual machines within the cloud computing environment when instructed to do so. The cloud manager <NUM> may have access to a set of pre-defined rules. Such rules may be configured and/or defined by a human administrator. Such rules may be stored as a data structure in physical memory. In one example, such rules may instruct the cloud manager <NUM> how to tear down a virtual machine when instructed to do so. One example of a cloud manager <NUM> includes the open-source cloud computing software platform provided by the Openstack Foundation under the name OpenStack™.

The SDN controller <NUM> is used to control the network resources of the NFVI <NUM>. The SDN controller <NUM> may control both the physical network resources <NUM> and the virtual network resources <NUM>. As will be described in further detail below, the SDN controller <NUM> receives instructions from various applications for how to configure the network infrastructure. The SDN controller <NUM> may have access to a set of pre-defined rules. Such rules may be configured and/or defined by a human administrator. Such rules may be stored as a data structure in physical memory. One example of a rule used by the SDN controller <NUM> may be how to establish virtual network connections when instructed to do so.

As described above, a VNF <NUM> represents a virtualization of specific telecommunication functions that are typically performed by specialized pieces of hardware. Examples of a VNF <NUM> include, but are not limited to, an SBC, an Internet Protocol (IP) Multimedia Subsystem (IMS) core, and a telephony application server. A VNF <NUM> may include a number of components, or instances of an application, that run within the virtual machine environment. Such applications are designed to emulate the specialized pieces of telecommunication hardware. Thus, instead of setting up a new physical piece of specialized equipment, a service provider can simply spin up a virtual machine environment and run applications. Each VNF <NUM> has a corresponding Element Management System (EMS) <NUM>. The EMS <NUM> includes a user interface, or a dashboard, that allows an administrator to configure the VNF <NUM> as desired. To provide full NFV, several VNFs work together to provide the desired services. In the present example, a plurality of VNFs <NUM>-<NUM>, <NUM>-<NUM>. <NUM>-n and corresponding EMSs <NUM>-<NUM>, <NUM>-<NUM>. <NUM>-n are used to provide NFV.

An EMS <NUM> may have access to a set of pre-defined rules. Such rules may be configured and/or defined by a human administrator. Such rules may be stored as a data structure in physical memory. One example of a rule used by an EMS <NUM> may define what statistics should be collected regarding operation of the VNF <NUM>.

A VNF <NUM> typically includes several different components, which may or may not be identical, that together form the full VNF <NUM>. For example, the different components may be different instances of the VNF application. The different instances then work together to provide the functionality of the full VNF <NUM>. Multiple VNFs <NUM> are then used in concert to provide a telecommunication network for a telecommunication service. A telecommunications network is an infrastructure that provides communication services between multiple subscribers. One example of a communication service is a Voice over IP (VoIP) service. Such services typically include several pieces of specialized hardware that perform specific network functions. However, according to principles described herein, the VNF <NUM> provides such functions instead of a specialized piece of hardware.

A VNF <NUM> may be part of a telecommunications core network. The core network is the central part of a telecommunications networks. The core network provides various communication services to the subscribers such as voice communication. Subscribers are connected to the core network through an access network, which will be described in further detail below. In some examples, the VNF component can communicate with the core network over a first network and communicate with the access network over a second network. The first network is isolated from the second network such that communication between the VNF and the core network does not traverse the same physical network components as the communication between the VNF and the access network.

The VNFs <NUM> are managed by a VNF manager <NUM>, which is part of the NFV management module <NUM>. In some cases, there may be multiple VNF managers <NUM>, each managing one or more specific VNFs <NUM>. The VNF manager <NUM> can manage the VNFs based on network demand. For example, at peak times, the VNF manager <NUM> can start up new instances of VNF components to scale dynamically according to demand. While there may be several VNF managers <NUM>, there is a single orchestrator <NUM> that manages the VNF managers <NUM> and thus manages the entire NFV service. The VNF manager <NUM> may have access to a set of pre-defined rules. Such rules may be configured and/or defined by a human administrator. Such rules may be stored as a data structure in physical memory. One example of a rule used by the VNF manager <NUM> may be when to instruct the cloud manager <NUM> to provision an additional virtual machine. For example, when demand for services reaches a certain threshold of capacity, the VNF manager <NUM> can instruct the cloud manager to provision an additional virtual machine so that an additional VNF component can be provisioned.

Each of the VNFs may correspond to virtual machines of a process node as described above. Particularly, each VNF <NUM> may handle transcoding functions for a particular set of calls. The VNF <NUM> may thus monitor those calls and toggle on the enhanced mode (e.g., channel aware mode) in the manner described above.

Using principles described herein, network components are able to improve their performance by using resources more efficiently to provide robust call quality and error resilience. For example, network systems are able to better utilize the channel aware mode of the EVS codec to use it only when needed and seamlessly turn it on and off.

Claim 1:
A method comprising:
processing a communication session with a first virtual machine of a plurality of virtual machines associated with a network node;
monitoring packet loss (<NUM>) on a leg of the communication session between a first endpoint and a second endpoint;
in response to determining (<NUM>) that the packet loss exceeds a first threshold, toggling on (<NUM>) an enhanced mode for a codec associated with the communication session, the enhanced mode providing increased error resilience; and
in response to determining (<NUM>) that the toggling on the enhanced mode causes the first virtual machine to exceed a processing capacity threshold, moving (<NUM>) the communication session to a second virtual machine of the plurality of virtual machines and continuing processing the communication session with the second virtual machine with the enhanced mode toggled on;
continuing to monitor packet loss (<NUM>) in order to verify whether the use of the enhanced mode is unnecessary.