Patent Description:
The following summary is not intended to identify key or critical elements of the disclosure nor to delineate the scope of the disclosure. The following summary merely presents some concepts of the disclosure in a simplified form as a prelude to the description below. The scope of the protection is defined by the appended claims.

Methods, apparatuses, and systems for improving quality of service for such latency-sensitive traffic are described herein. Many different applications may generate conversational video and other latency-sensitive traffic. Wireless radio access networks (RANs) typically handle conversational video traffic in the same way as traffic that is not latency-sensitive (e.g., using best effort delivery). Because such conversational video traffic is often encrypted, the RAN may not know whether traffic is conversational video or some other type of traffic, and thus may not be able to optimally allocate resources to conversational video traffic in order to improve quality of service for that traffic. Without some signaling mechanism that would allow a particular application generating conversational video traffic (or other such latency-sensitive traffic) to notify the RAN that the traffic is latency-sensitive, the RAN may have no way to distinguish between latency-sensitive and other traffic. Adopting a signaling standard for communicating between conversational video applications and RANs would be difficult due to the large number of such applications, the various technologies used by different RANs, and other factors.

Conversational video applications running on user equipment typically set an encoding rate, which determines the data throughput, based on the end-end delay for prior packets in the conversational video session. A first user equipment sends out packets to a second user equipment and vice versa, and as the second user equipment receives packets, it will send out receiver reports on periodic intervals to the first user equipment, and vice versa. The periodicity may vary for different applications and may not be standardized. When the first user equipment, for example, receives these reports, it will decide the encoding rate for subsequent time intervals. If a reported end-to-end delay is high, the conversational video application on the user equipment may lower its encoding rates in order to avoid losing packets due to network congestion. If the reported end-to-end delay is low, the conversational video application on the user equipment may raise its encoding rates in order to provide better quality video.

Because of the periodicity of the reporting and the iterative adjustment process, encoding rates may be adjusted gradually over time. Because of the lack of signaling mechanisms, the RAN may be unaware of the upcoming encoding rate changes, which may prevent it from taking any pre-emptive action to ensure better quality of service for the adjusted video traffic.

Methods, apparatuses, and systems described herein allow a RAN to infer information about conversational video traffic without requiring signaling mechanisms that allow communication with conversational video applications. Methods, apparatuses, and systems described herein allow RAN equipment to detect conversational video traffic, collect information about the conversational video traffic and as well as other network conditions, predict delays associated with the conversational video traffic, predict a likely encoding rate that will be used by the application that generates the conversational video traffic, and allocate resources to the conversational video traffic based on the likely encoding rates and other network conditions.

The present disclosure is accompanied by figures in which like reference numerals indicate similar elements and in which:.

The embodiments related to <FIG>, <FIG>, and <FIG> are within the scope of the claims.

In the following description, reference is made to the accompanying drawings, which form a part hereof.

<FIG> illustrates a network environment including user equipment connected via wireless radio access networks and other networks. User equipment may connect to other user equipment via one or more access networks <NUM>, which in turn may be connected to each other via one or more core and/or external networks <NUM>. The user equipment may thus establish multimedia data flows (e.g., bidirectional video sessions) that may, in some cases, be routed through one or more radio access networks.

User equipment <NUM> may include, as illustrated, smartphones (e.g., 140a-c) and/or personal computers (e.g., 140d) and/or any other type of user equipment. For example, user equipment may include tablets, desktop computers, laptop computers, gaming devices, virtual reality (VR) headsets, other mobile devices, or other user equipment.

Multimedia data flows may include bidirectional video data flows associated with data traffic from a conversational video application (e.g., SKYPE, FACETIME, etc.) or other types of multimedia data flows that are latency-sensitive. Such latency-sensitive multimedia data flows further include bidirectional audio (e.g., audio chat), bidirectional VR video, unidirectional audio/video/VR, and other such multimedia data flows.

Multimedia data flows may be bidirectional data flows (e.g., a conversational video between user equipment 140a and user equipment 140b) and/or may involve a plurality of user equipment (e.g., a video conference involving user equipment 140a, user equipment 140b, and user equipment 140c). Such data flows involving multiple user equipment may involve multiple bidirectional data flows between each pair of user equipment (e.g., a first bidirectional data flow between user equipment 140a and user equipment 140b, and second bidirectional data flow between user equipment 140b and user equipment 140c, and a third bidirectional data flow between user equipment 140a and user equipment 140c), or may involve bidirectional data flows between each user equipment and a central server. Bidirectional data flows as described herein may thus occur between user equipment and other endpoints (e.g., servers).

A radio access network (RAN) <NUM> may include multiple access points <NUM> that are configured to communicate wirelessly with user equipment <NUM>. The access points may include base stations and/or nodes that enable wireless communications with user equipment <NUM> according to wireless standards (e.g., <NUM>, <NUM>, <NUM>, or other such wireless standards). Such nodes of the access points <NUM> may provide scheduler functionality, traffic management functionality, and other RAN resource management functionality.

The RANs <NUM> may further include network equipment <NUM> for providing RAN functionality. Such network equipment <NUM> may implement radio network controller functionality for controlling an access point <NUM> to communicate with user equipment <NUM>. Additionally or alternatively, the network equipment <NUM> may include cloud RAN functionality (e.g., functionality of the access point <NUM> managed in a cloud environment). In some embodiments, some or all functions of the network equipment <NUM> may be implemented by nodes and/or base stations of the access points <NUM>.

As illustrated in <FIG>, some user equipment may connect via other access networks 150d that may not be radio access networks. Although the concepts described below are often described with respect to a radio access network, it should be understood that the concepts described herein may be used in any type of access network.

<FIG> illustrates an example bidirectional data flow between user equipment 210a and user equipment 210b, which may be examples of user equipment <NUM> according to <FIG>. Such a data flow may be, for example, a conversational video session in which user equipment 210a is transmitting video to user equipment 210b, and user equipment 210b is transmitting video to user equipment 210a. The user equipment 210a, 210b may be executing a video application <NUM> (e.g., SKYPE, FACETIME, etc.) that provides the bidirectional video. In the illustrated example, the two instances of application <NUM> may send signaling messages to each other to establish and tear down video sessions, communicate regarding video encoding and/or encoding rates, indicate delays or other transmission issues, and the like. Many such bidirectional video applications negotiate between endpoints in order to establish video encoding rates based on delays, bandwidth, lost traffic, and other network issues. Signaling messages between the video applications are often encrypted and thus may be unusable by equipment in a RAN or other access network.

The bidirectional data flow may pass through a first radio access network 220a and a second radio access network 220b, which may be examples of radio access networks <NUM> of <FIG>. The bidirectional data flow may also pass through one or more core and/or external networks (e.g., networks <NUM>). Due to varying technologies (e.g., one of the RANs may be part of a <NUM> network and the other RAN may be part of a <NUM> network), varying traffic levels at the RANs, varying signal strength for the wireless connections between the user equipment and the RAN, and other factors, one or both of the RANs may act as a bandwidth and/or latency bottleneck for the bidirectional data flow at various times during the data flow session.

The first equipment 210a may transmit data (e.g., video) to the second user equipment 210b by transmitting the video via a uplink of the first RAN 220a. The first RAN 220a may then transmit the video (e.g., via one or more core and/or external networks, which are not illustrated) to a second RAN 220b. The second RAN 220b may then transmit the video to the user equipment 210b via a downlink. Similarly, the second user equipment 210b may transmit data (e.g., video) to the first user equipment 210a by transmitting the video via an uplink of the second RAN 220b. The second RAN 220b may then transmit the video (e.g., via one or more core and/or external networks, which are not illustrated) to the first RAN 220a. The first RAN 220a may then transmit the video to the user equipment 210a via a downlink. Because the uplink and downlink of a particular RAN may experience varying traffic and congestion levels and signal issues, among other issues, the available bandwidth and end-to-end (e2e) delay of traffic in one direction may be different from the available bandwidth and e2e delay in the other direction.

<FIG> illustrates a second example bidirectional data flow between user equipment 210a and user equipment 210b, which may be examples of user equipment <NUM> of <FIG>. In this example, a bidirectional data flow may have endpoints at user equipment 210a and user equipment 210b, but the second user equipment 210b may be connected to an other access network, which may be an example of an other access network 150d of <FIG>. Such an other access network may include a cable access network, a fiber access network, or some other type of access network, and may include one or more wired or wireless connections (e.g., a Wi-Fi access point).

In some embodiments, both user equipment <NUM> of a bidirectional data flow may connect via other access networks (e.g., non-RAN access networks). In some embodiments, more than two user equipment <NUM> may be endpoints of a data flow among the more than two user equipment (e.g., a three-way video conference). In some embodiments, a bidirectional or other multimedia data flow may occur between a user equipment and a server or other non-user equipment.

<FIG> illustrates further details of a resource allocation controller <NUM> of a RAN <NUM>, which may be an example of a RAN <NUM> of <FIG>. The resource allocation controller <NUM> may be implemented by a node and/or a base station of a RAN access point (e.g., an access point <NUM>) and/or may be implemented by network equipment (e.g., network equipment <NUM>) as illustrated at <FIG>. The RAN 320a may connect to user equipment 310a (which may be an example of user equipment <NUM>, <NUM>) via the wireless network provided by the RAN. The RAN 320a may thus receive data from the user equipment 310a via an uplink data flow and transmit data to the user equipment 310a via a downlink data flow. The RAN 320a may also send and receive data bidirectionally via intermediate networks <NUM> to and from user equipment 310b. The intermediate networks may include core and/or external networks, (e.g., networks <NUM>) and/or access networks (e.g., RAN <NUM> or other access network 220c).

The resource allocation controller <NUM> may manage RAN resources for the user equipment 310a to improve a quality of service of the bidirectional data flow. Because the resource allocation controller <NUM> manages resources for the RAN 320a, it may manage resources for first and fourth data flows of <FIG>. The second and third data flows involve other intermediate networks <NUM> over which the resource allocation controller <NUM> may have no control. Accordingly, the resource allocation controller may manage the RAN resources to prevent the RAN 320a from becoming a bottleneck in either direction of the bidirectional data flow.

The resource allocation controller <NUM> may comprise one or more processors <NUM> and one or more memories <NUM>. The memory(s) may store instructions 332a which, when executed by the processor(s) <NUM>, cause the resource allocation controller <NUM> to perform functions described herein. For example, the instructions 332a may cause the resource allocation controller <NUM> to perform the method of <FIG>, as further described below.

The resource allocation controller may allocate resources for the uplink (e.g., the first data flow) and the downlink (e.g., the fourth data flow) with the user equipment 310a based on a predicted future encoding rate (and/or predicted future throughput) of the uplink data flow and/or the downlink data flow. In order to predict the future encoding rate, the resource allocation controller may use one or more delay model(s) 332b to determine uplink delays associated with both the RAN and with intermediate networks (e.g., associated with the first and second data flows) and to determine downlink delays associated with both the RAN and with intermediate networks (e.g., associated with the third and fourth data flows). The RAN may then calculate an end-to-end delay for both directions of the bidirectional data flow (e.g., by adding the delays associated with the first and second data flows to determine an end-to-end delay for one direction, and adding the delays associated with the third and fourth data flows to determine an end-to-end delay for the other direction).

After determining end-to-end delays for both directions of the bidirectional data flow, the resource allocation controller <NUM> may use one or more rate model(s) 332c to predict a future encoding rate for multimedia data transmitted in each direction based on the corresponding end-to-end delay. For example, using a first end-to-end delay, the resource allocation controller <NUM> may calculate, using one of the rate models 332c, a predicted encoding rate for video sent from user equipment 310a to user equipment 310b. The resource allocation controller <NUM> may also calculate, using the same or a different rate model 332c, a predicted encoding rate for video sent from user equipment 310b to user equipment 310a.

Based on the predicted encoding rates, the resource allocation controller <NUM> may allocate sufficient RAN resources in order to avoid limiting the bidirectional data flow. The resource allocation controller may thus transmit instructions (e.g., to a node of the RAN 320a that is associated with the user equipment 310a via a communication interface <NUM>) to allocate resources appropriately. A method for allocating resources based on predicted delays and encoding rates is described in more detail below with respect to <FIG>.

<FIG> illustrates a first example model 410a for predicting delays for an uplink data flow. The model 410a may one of the delay models 332b used to predict delays. The model 410a may be trained to predict a first delay (e.g., a portion of an end-to-end delay associated with the data flow through the RAN 320a) and a second delay (e.g., the remaining portion of the end-to-end delay associated with the data flow through intermediate networks <NUM> outside the RAN) based on multiple input features. The input features may include network conditions information related to the uplink data flow, such as congestion information for the uplink direction, channel conditions information for uplink channels, and throughput information for the uplink data flow. Other example features may include any information about throughputs and/or latencies for any backhaul links (e.g., core and/or external networks <NUM>).

The uplink congestion information may indicate how congested the RAN uplink is, which may tend to predict delays in the bidirectional data flow. The uplink congestion information input may be determined in various ways. In a <NUM>/LTE context, congestion information may be indicated in terms of an available number of physical resource blocks (PRBs). Thus, for example, a simple measure of uplink network congestion may be a number and/or percentage of PRBs that are available for uplink traffic. Another congestion measurement may include an average number of PRBs/second for an active bearer, described in <CIT>. Another congestion measurement may be an average round-trip delay for all users connected to an access point of the RAN. Some or all of these measurements may be used as one or more inputs to the model 410a. In some embodiments (e.g., for non-<NUM>/LTE networks), congestion information may be measured in terms of other types of network resources than PRBs.

The uplink channel conditions information indicates a quality of the wireless uplink connection to the user equipment, which may tend to indicate delays due to lost packets and the like. The uplink channel conditions information may be determined in various ways. A received signal strength indication (RSSI), a reference signals received power (RSRP), a signal to interference plus noise ratio (SINR), and/or other types of noise ratios may be used as indications of conditions on the channel used to connect with the user equipment 310a. Other measurements include an average number of PRBs allocated to each bearer and/or a number of bits per PRB. Some or all of these measurements may be used as one or more inputs to the model 410a.

The uplink throughput information may indicate a current throughput (e.g., in bits per second) associated with the user equipment 310a in the uplink direction, as measured over a recent time period (e.g., the past <NUM> or <NUM> of milliseconds or seconds).

The model 410a may be trained to predict both a first delay associated with the RAN uplink and a second delay associated with the remainder of the data flow through various intermediate networks. To train the model 410a, a training data set may be generated from data collected at both a RAN and at user equipment providing bidirectional data flows through the RAN. For example, to generate a training data set for the model 410a, an operator may connect test user equipment wirelessly to the RAN. The operator may then establish a bidirectional data flow with the test user equipment as one end point (e.g., by executing a video application <NUM> and establishing a conversational video session). The RAN may then log uplink congestion information, uplink channel conditions information, throughput information, and any other information used to provide input features to the model 410a. Simultaneously, the test user equipment may log end-to-end delays (e.g., as indicated by data generated by and collected from the video application <NUM> executing on the test user equipment, and/or from signaling messages received from the video application <NUM> executing on user equipment at the other endpoint of the bidirectional data flows). Additionally, the test equipment and/or the RAN may log first delays associated with the RAN uplink by configuring the test equipment and/or the RAN to provide signaling to measure such delays. From the end-to-end delay data and the first delay data associated with the RAN uplink, second delay data associated with the remainder of the data flow through various intermediate data networks may be generated (e.g., by subtracting the first delay from the end-to-end delay). In other examples, instead of outputting first and second delays, the model 410a may be trained to output a single (e.g., end-to-end) delay.

The operator may then correlate and compile the logged data to form a training data set. The first and second delay data may be set as the target variables, and the input data may be used as the input features. The model may be trained using various machine learning and/or statistical techniques (e.g., gradient descent, backpropagation, etc.) to develop a trained model. The training process may adjust the weights assigned to the nodes of each layer in order to map the input features to the target outputs. The training process may map the input features to delay measurements associated with later times (e.g., <NUM> or <NUM> of milliseconds later, for example) in relation to the times associated with the input features such that the model is trained to predict future delays (e.g., <NUM> or <NUM> of milliseconds in the future, for example) based on the input features.

Although <FIG> shows a simple neural network, other variations and/or types of models may be used. For example, although <FIG> illustrates a single hidden layer with five nodes, in other examples additional hidden layers may be used. For example, deep neural networks may use large numbers of hidden layers. Additionally or alternatively, various numbers of nodes may be used for different hidden layers. Additionally or alternatively, as described above, the model 410a may use less or more than the illustrated four inputs.

In some embodiments, rather than calculating specific features for inputs, some or all of the inputs may be raw or lightly processed data. For example, instead of calculating network congestion information, a raw or lightly-processed (e.g., re-formatted) feed of traffic and/or a data structure used by a network scheduler may be provided as input(s) to the model 410a. Deep neural networks and other deep learning techniques may be particularly suited to making predictions based on this type of more complex input data.

<FIG> illustrates a second example model 410b for predicting delays for a downlink data flow. The model 410b may be one of the delay models 332b used to predict delays. The model 410b may be trained to predict a third delay (e.g., a portion of the end-to-end delay associated with the data flow through intermediate networks <NUM> outside the RAN) and a fourth delay (e.g., a portion of an end-to-end delay associated with the data flow through the RAN 320a) based on multiple input features. The input features may include network conditions information related to the downlink data flow, such as congestion information for the downlink direction, channel conditions information for downlink channels, throughput information for the downlink data flow, and other example input features as discussed above for model 410a. The congestion information, channel conditions information, and throughput information related to the downlink data flow may be determined as discussed above for model 410a.

The training data set for the model 410b may be compiled, and the model 410b trained, similarly as for the model 410a discussed above. Similarly, the example model 410b may be varied to include different numbers of layers and/or nodes, or to use different models besides neural networks, such as other machine learning models. Additionally or alternatively, the model 410b may be a deep neural network. Additionally or alternatively, the model 410b may receive varying number of inputs and/or may receive raw or lightly processed (e.g., re-formatted) data as an input, such as a raw or lightly processed feed of traffic and/or a data structure used by a network scheduler.

<FIG> illustrates a third example model <NUM>. The model <NUM> may one of the rate models 332c used to predict encoding rates based on delays. The model <NUM> may be trained to predict an encoding rate for a first user equipment (e.g., user equipment 310a at one end of a bidirectional data flow) and an encoding rate for a second user equipment (e.g., user equipment 310b at the other end of a bidirectional data flow) based on multiple input features. The input features may include end-to-end delay for a first direction of the bidirectional data flow, end-to-end delay for a second direction of the bidirectional data flow, application information, and other example input features. Such other example input features may include end-to-end delays for other user equipment in communication with the RAN (e.g., besides the user equipment 310a and the user equipment 310b).

End-to-end delays may influence the encoding rate selected by an application for establishing the bidirectional data flow (e.g., video application <NUM>). For example, the video application, upon encountering certain amounts of delay, may tend to reduce an encoding rate in order to prevent packet loss or delay that may cause video hiccups and other such quality issues. The end-to-end delays may be derived arithmetically from the outputs of the delays models 332b, <NUM>. For example, first and second delays may be added together to yield the first end-to-end delay for the first direction. Similarly, third and fourth delays may be added together to yield the second end-to-end delay for the second direction.

Application information may indicate a determination of the specific application (e.g., SKYPE, FACETIME, WECHAT, etc.) or type of application (e.g., what video protocols and/or standards are used by the application). The application information may provide information about predicted encoding rates. For example, some applications may rapidly reduce encoding rates upon encountering certain delays and/or rapidly increase encoding rates in the absence of delays, whereas other applications may more slowly reduce or increase encoding rates under the same conditions.

The model <NUM> may be trained to predict both a first encoding rate associated with first user equipment and a second encoding rate associated with second user equipment. To train the model <NUM>, a training data set may be generated from data collected at both a RAN and at user equipment providing bidirectional data flows through the RAN. For example, to generate a training data set for the model <NUM>, an operator may connect test user equipment wirelessly to the RAN. The operator may then establish a bidirectional data flow with the test user equipment as one end point (e.g., by executing a video application <NUM> and establishing a conversational video session). The test user equipment may then log end-to-end delays in both directions (e.g., as indicated by data generated by and collected from the video application <NUM> executing on the test user equipment, and/or from signaling messages received from the video application <NUM> executing on user equipment at the other end of the bidirectional data flow). Additionally, the test equipment may log application information such as the application or application type. Simultaneously, the test user equipment may log encoding rates for both the test user equipment and the user equipment at the other end of the bidirectional data flow (e.g., as indicated by data generated by and collected from the video application <NUM> executing on the test user equipment, and/or from signaling messages received from the video application <NUM> executing on user equipment at the other end of the bidirectional data flow). In some embodiments, the training data for training the model <NUM> may be collected at the same time as the training data for training the models 410a, 410b (e.g., using the same bidirectional data flow established by the same test user equipment). Thus, the training data set for training the model <NUM> may be the same training data set used to train the models 410a, 410b (e.g., as a single data set containing correlated training information for the plurality of models).

For training the model <NUM>, the encoding rates for both endpoints may be set as the target variables, and the first and second delay data, the application information, and any other features may be used as the input features. The model may be trained using various machine learning and/or statistical techniques (e.g., gradient descent, backpropagation, etc.) to develop a trained model. The training process may adjust the weights assigned to the nodes of each layer in order to map the input features to the target outputs. The training process may map the input features to encoding rates associated with later times (e.g., <NUM> or <NUM> of milliseconds later, for example) in relation to the times associated with the input features such that the model is trained to predict future encoding rates (e.g., <NUM> or <NUM> of milliseconds in the future, for example) based on the input features.

In some embodiments, instead of using a single model <NUM> that outputs encoding rates for both a first user equipment and a second user equipment, one model 332c may be trained to predict an encoding rate for one user equipment (e.g., the user equipment 310a connected wirelessly to the RAN 320a), and a second model 332c may be trained to predict an encoding rate for another user equipment (e.g., the user equipment 310b connected via intermediate networks <NUM> to the RAN 320a). Accordingly, the models 332c may each receive a single end-to-end delay input. The model 332c for predicting an encoding rate for the user equipment connected wirelessly to the RAN may receive, as an input feature, an end-to-end delay associated with traffic in the uplink direction with respect to the RAN (e.g., an end-to-end delay calculated by adding first and second delays). The model 332c for predicting an encoding rate for the user equipment connected via intermediate networks to the RAN may take, as an input feature, an end-to-end delay associated with traffic in the downlink direction with respect to the RAN (e.g., an end-to-end delay calculated by adding third and fourth delays).

In some embodiments, in addition to or as an alternative to using machine learning techniques, neural networks, or the like, statistical models such as regression models may be trained and used. In some embodiments, instead of using one or more models 332b, 332c, a lookup table may be used. For example, as an alternative to model(s) <NUM>, 332c for predicting encoding rates, one or more lookup tables containing predicted encoding rates based on end-to-end delays may be used. Such a lookup table may contain different data for different applications such that the encoding rate predictions may be application-specific.

<FIG> illustrates a method for allocating RAN resources to bidirectional data flows (e.g., conversational video) based on predicted encoding rates. The method of <FIG> may be executed by the resource allocation controller <NUM>, which may be implemented by a node and/or base station of RAN access points <NUM> and/or by RAN network equipment <NUM>.

The process begins at step <NUM>. The process may begin when equipment is brought online and may run continuously or periodically (e.g., continuously or periodically executing in a loop). The process begins when a new data flow is detected by the resource allocation controller <NUM>. At step <NUM>, the resource allocation controller <NUM> may test a data flow to determine whether it contains latency-sensitive bidirectional data flows. As illustrated, the resource allocation controller <NUM> may determine whether the traffic is associated with conversational video specifically. The resource allocation controller <NUM> may determine the application type (e.g., whether the application type is conversational video or some other latency-sensitive data flow) based on statistics vectors of bearer metrics and locating points on a label map corresponding to the statistics vectors, as described in <CIT>. If the resource allocation controller <NUM> determines that the application type is not conversational video (and/or some other type of latency-sensitive multimedia data flow), it may loop back and repeat the test on the same data flow and/or another data flow. The resource allocation controller <NUM> may perform step <NUM> again (e.g., on the same data flow or another data flow) after waiting for some time (e.g., after a delay step, not illustrated) in order to conserve computational resources. If the resource allocation controller <NUM> determines that the data flow is conversational video (and/or some other type of latency-sensitive multimedia data flow), it proceeds to step <NUM>.

In some embodiments, in addition to or as an alternative to using statistics vectors to determine an application type, the resource allocation controller <NUM> may use an application model 332d trained to identify an application and/or an application type. The model 332d may take, as input, a traffic flow and, based on the traffic, predict an application or application type that generated the traffic. Additionally or alternatively, the model 332d may take, as input, statistics and/or other information derived from the traffic flow. The model 332d may be a deep neural network trained using a training data set consisting of example traffic flows and/or information (e.g., statistics) derived from the traffic flows as inputs and indications of which application and/or application type generated the corresponding traffic flow as a target variable. Such a model may be trained using any of the techniques described above, including machine learning and/or statistical modeling techniques (e.g., neural networks, deep learning, regression models, and/or the like).

At step <NUM>, the resource allocation controller <NUM> collects network conditions information for the RAN. The resource allocation controller <NUM> may thus collect data used to generate input features for the delay models 332b (e.g., models 410a, 410b). Such network conditions information may include one or more of uplink and/or downlink congestion information, uplink and/or downlink channel conditions information, uplink and/or downlink throughput information, and any other network conditions features for inputting into delay models 332b (e.g., models 410a, 410b). The resource allocation controller <NUM> may collect such information from other components of the RAN (e.g., from nodes and/or base stations of the access points <NUM> and/or network equipment <NUM>) by requesting the information from such components (e.g., by transmitting one or more requests to the components via communication interfaces <NUM>) and/or may receive such information continuously, periodically, or at some other interval. Additionally or alternatively, the resource allocation controller <NUM> may generate and/or calculate such network conditions information itself (e.g., based on other information previously obtained and/or stored by the resource allocation controller <NUM>).

At step <NUM>, resource allocation controller <NUM> processes the network conditions information to generate the input features for the delay model(s) 332b (e.g., models 410a, 410b). Such processing may involve normalizing, correlating, structuring or otherwise modifying the format of the data into a format suitable for input into the delay model(s) 332b (e.g., models 410a, 410b). The delay model features may include any of the input features discussed above.

At step <NUM>, the resource allocation controller <NUM> uses the one or more delay model(s) 332b to predict delays (e.g., first through fourth delays associated respectively with a uplink connection with a first user equipment via the RAN, an uplink connection with a second user equipment, a downlink connection with the second user equipment, and a downlink connection with the first user equipment via the RAN). The resource allocation controller <NUM> may thus input the delay model features to the delay models 332b in order to generate the predicted delays. The predicted delays may indicate delays in the near future (e.g., in the next <NUM> or <NUM> of milliseconds) based on the input features.

At step <NUM>, the resource allocation controller <NUM> calculates end-to-end delays for both directions of the bidirectional data flow. The resource allocation controller <NUM> may, for example, add the first and second delays to yield the first end-to-end delay, and add the third and fourth delays to yield the second end-to-end delay. In other examples, the delay model(s) 332b may predict end-to-end delays and thus step <NUM> may not be necessary.

At step <NUM>, the resource allocation controller <NUM> may determine an application associated with the bidirectional data flow. In some embodiments, the process for detecting conversational video (e.g., for step <NUM>) may indicate an application, as discussed above. In such cases, the resource allocation controller <NUM> may look up and/or retrieve the previously determined application. In some embodiments, the resource allocation controller <NUM> may use an application model 332d to determine the application, as discussed above. Thus, the resource allocation controller <NUM> may retrieve the application determination if the resource allocation controller <NUM> previously determined the application using the application model 332d, and/or use the application model 332d at step <NUM> to determine the application based on the traffic flow and/or information derived from the traffic flow (e.g., statistics or other metrics).

At step <NUM>, the resource allocation controller <NUM> predicts encoding rates for the bidirectional data flow using the model(s) 332c. Accordingly, the resource allocation controller <NUM> may provide the end-to-end delays, the application information, and/or any other input features for the model(s) 332c in order to predict the encoding rates. In some embodiments, instead of model(s) 332c, the resource allocation controller <NUM> may use one or more lookup tables to predict the encoding rates based on the end-to-end delays. In such embodiments, the resource allocation controller <NUM> may look up the encoding rate information using one or more queries containing the end-to-end delay(s). In some embodiments, multiple lookup tables may be provided for various applications and/or application types. Accordingly, the resource allocation controller <NUM> may provide the determined application and/or application type in the one or more lookup table queries. The resource allocation controller <NUM> may thus determine predicted encoding rates for one or both user equipment of the bidirectional data flow.

At step <NUM>, the resource allocation controller <NUM> allocates RAN resources based on the predicted encoding rate, the current allocation of resources on the RAN, and/or the current uplink and downlink delay(s) associated with the wireless connection(s) between the first user equipment 310a and the RAN.

In some cases, to allocate RAN resources, the resource allocation controller <NUM> may calculate an uplink throughput and/or a downlink throughput based on the predicted encoding rate(s). The RAN may then ensure that sufficient resources are allocated to the user equipment 310a wirelessly connected to the RAN in order to accommodate the determined throughput. If insufficient resources are allocated to the user equipment 310a, the RAN may increase the resources allocated to the user equipment 310a (e.g., by assigning more PRBs to the user equipment 310a). In some cases, the RAN may re-allocate resources (e.g., PRBs) allocated to other devices (e.g., other user equipment wirelessly connected to the RAN) that are not associated with latency-sensitive data flows (e.g., conversational video data flows) to the user equipment <NUM>.

In some cases, the resource allocation controller <NUM> may determine that too many resources are allocated to the user equipment 310a based on the predicted encoding rate. If the RAN has resources to spare (e.g., if other user equipment connected wirelessly to the RAN does not need additional resources for latency-sensitive traffic), it may leave the extra resources allocated to the user equipment in case the encoding rate of the bidirectional data flow later increases. If other user equipment needs resources (e.g., if the resource allocation controller <NUM> determines, by executing the process of <FIG> in parallel for a second bidirectional data flow, or from a previous iteration through the loop of the process of <FIG> that related to the second bidirectional data flow, that the second bidirectional data flow has insufficient resources allocated), the resource allocation controller <NUM> may allocate the extra resources (e.g., PRBs) from the user equipment <NUM> to the other user equipment.

In some cases, the resource allocation controller <NUM> may determine, based on the current uplink and downlink delay(s) associated with the wireless connection(s) between the first user equipment 310a and the RAN, that the RAN is not the bottleneck even when the bidirectional data flow has insufficient resources. Therefore, the resource allocation controller <NUM> may, in some cases, deprioritize (e.g., in favor of another user equipment that also needs additional resources) user equipment 310a participating in latency-sensitive bidirectional data flows even when the bidirectional data flow has insufficient resources, because the resource allocation controller <NUM> determines that the RAN is not the bottleneck for traffic (e.g., because the intermediate networks <NUM> are delaying traffic). Therefore, in some cases the resource allocation controller <NUM> may determine that allocating additional resources will not improve a quality of service for a bidirectional data flow because intermediate networks <NUM> over which the resource allocation controller <NUM> may not have control are preventing better quality of service.

<FIG> illustrates an example of resource allocation during an example multimedia data session. The illustrated example begins at steps 601a, 601b, in which the two user equipment A, B (which may be examples of user equipment <NUM>, <NUM>, <NUM>) establish a session. For example, a video application running on both of user equipment A and user equipment B may negotiate, perform handshake operations, and otherwise signal each other to set up a conversational video session. The session may be encrypted, which means equipment of RAN-A may be unable to observe the type of traffic, what signals are being exchanged, or otherwise extract information directly from the traffic.

At step <NUM>, equipment of the RAN (e.g., the resource allocation controller <NUM>) may execute steps <NUM>-<NUM> of the process of <FIG> (e.g., after determining that the initiated session is a conversational video session in step <NUM> of the process of <FIG>). The resource allocation controller <NUM> may thus allocate sufficient resources based on the predicted encoding rates of both the user equipment A and the user equipment B.

At step <NUM>, after repeatedly looping through the process of <FIG>, the resource allocation controller <NUM> may determine a new predicted encoding rate (e.g., for user equipment A, as illustrated, or for either or both of user equipment A and/or user equipment B). The predicted encoding rate may vary over time due to changes in network conditions information (e.g., channel uplink and/or downlink congestion, uplink and/or downlink channel quality, changes in uplink and/or downlink throughput, and the like). Such changes may occur because of other user equipment joining and/or leaving the RAN and/or using varying amounts of traffic bandwidth, due to movement of user equipment A and/or B causing varying channel conditions on either end of the bidirectional data flow, due to changes in encoding at either user equipment A or user equipment B, or for other reasons. In response to determining a new predicted encoding rate, the resource allocation controller <NUM> may re-allocate resources to the uplink and/or downlink of the RAN connection to user equipment A.

In some cases, as illustrated by <FIG>, re-allocating resources may prevent the user equipment A and/or user equipment B from having to adjust an encoding rate. Therefore, even though the resource allocation controller predicted a new encoding rate for at least one of the user equipment A and/or user equipment B, the user equipment A and/or user equipment B may not actually change their encoding rate. For example, if the resource allocation controller <NUM> predicts a lower encoding rate at step <NUM> for user equipment A in comparison to the predicted encoding rate for user equipment A at step <NUM>, the resource allocation controller may respond by increasing resources for the uplink connection with user equipment A so that the user equipment A does not need to lower its encoding rate. Therefore, predicting encoding rate changes and adjusting resources ahead of time may actually prevent the necessity of the encoding rate changes.

In other cases, the predicted encoding rate changes may occur. For example, the resource allocation controller <NUM> may predict a new encoding rate for user equipment A at step <NUM>, and the user equipment A may independently adjust its encoding rate at step <NUM>. In these cases, the resource allocation controller <NUM> may be ready for the new encoding rate by having adjusted the resource allocation ahead of time. For example, when the new encoding rate is higher than the previous encoding rate, the resource allocation controller <NUM> may be ready to deal with the increased traffic from the higher-rate data flow before the traffic increases.

Similarly, the resource allocation controller <NUM> may predict encoding rate changes for the user equipment B, as illustrated at step <NUM>, and adjust the resource allocation appropriately. In some cases, the encoding rate change may be avoided by such a re-allocation. In other cases (e.g., as illustrated) the user equipment B may independently adjust its encoding rate.

At some point, one or both of the user equipment A and/or user equipment B may terminate the session. In the illustrated example, user equipment B may terminate the session at step <NUM>. Later, in step <NUM>, the resource allocation controller <NUM> may determine that the data flow has terminated and de-allocate resources that were previously allocated to the data flow.

Thus, as shown by the example of <FIG>, the resource allocation controller <NUM> may be able to optimize resource allocation to improve quality of services for latency-sensitive bidirectional data flows without requiring signaling to and from the user equipment A and/or user equipment B and/or the video applications running on the user equipment A and B.

Claim 1:
A method comprising:
detecting (<NUM>), by a radio access network equipment, that a data flow is associated with bidirectional video;
determining (<NUM>, <NUM>, <NUM>, <NUM>), by the radio access network equipment, based on radio access network conditions information, at least one delay associated with the data flow;
determining (<NUM>), by the radio access network equipment, based on the at least one delay, at least one predicted encoding rate associated with the bidirectional video, wherein determining the at least one predicted encoding rate based on the at least one delay is performed using at least one model or a lookup table, wherein the at least one model or the lookup table is configured to predict encoding rates for use by an application that generates the data flow based on input features including the at least one delay; and
allocating (<NUM>), by the radio access network equipment, radio access network resources to the data flow based on the at least one predicted encoding rate.