KR102234927B1 - Application quality management in a cooperative communication system - Google Patents

Abstract

The application manager node in the communication network includes a transceiver module configured to monitor data communication in the communication network, and a processor coupled to the transceiver, the processor comprising at least one application associated with at least one application running in at least one terminal node. Receive application information related to the application data stream from at least one terminal node, and update a relationship map including a relationship between each of the at least one application data stream and an access node based on the application information, and at least one terminal node Determining a comprehensive quality metric value associated with the access node based at least in part on application information received from one or more of, and at least one mitigation option for at least one of the at least one application data stream based on the comprehensive quality metric Is configured to choose.

Description

Application quality management in a cooperative communication system {APPLICATION QUALITY MANAGEMENT IN A COOPERATIVE COMMUNICATION SYSTEM}

Cross-reference to related applications

This application is filed on December 22, 2011, US Provisional Application No. 61/579,324 (invention title: "Congestion Induced Video Scaling") and US Provisional Application No. 61/658,774, filed on June 12, 2012 (invention US Patent Application No. 13/653,239, filed on October 16, 2012, claiming the benefits of "Systems and Methods for Cooperative Applications in a Communication System" (name of the invention: "Systems and Methods for Cooperative Applications in a Communication System") Applications in Communication Systems"), which is a continuing application in part of U.S. Patent Application No. 13/744,101, filed January 17, 2013 (name of the invention: "Systems and Methods for Cooperative Applications in Communication Systems"). , All of these are incorporated herein by reference.

The present invention relates generally to the field of communication systems, and to the implementation, use and management of cooperative applications in communication systems.

In a communication network such as an Internet Protocol (IP) network, each node and subnet has a limitation on the amount of data that can be effectively transmitted at any predetermined time. In a wired network, this is usually a function of equipment capabilities. For example, a Gigabit Ethernet link can transmit only 1 billion bits of traffic per second. In wireless networks, capacity is limited by the communication protocol, transmission technology and channel bandwidth used. Wireless networks are further constrained by the quality of the signal between the transmitting and receiving systems and the amount of spectrum allocated to the service area. Because these aspects can be dynamic, the capacity of a wireless system can vary over time.

Historically, communication systems have differentiated traffic by a class of service (CoS) within a core, as in a packet gateway (P-GW) within an LTE system. This means that operator-provided services, such as voice and video from the operator's own or coordinated content delivery network (CDN), have a quality of service (QoS) such as a guaranteed bit rate (GBR). It has the advantage of getting a guarantee. Traffic that is not associated with operator-provided services is typically less differentiated, leading to heterogeneous traffic being grouped into the same CoS. Moreover, such traffic is usually provided with resources on a best effort basis, ignoring the QoS requirements of specific applications that generate the traffic, and ignoring the quality of experience (QoE) perceived by the end user.

The additional communication traffic may be from an over-the-top (OTT) service, ie, an operator provided or uncoordinated service. Skype over internet protocol (VoIP), YouTube progressive download video, Netflix streaming video, and Pandora Radio streaming audio are examples of OTT services. OTT voice and video services tend to be grouped together as best effort traffic along with email, social networking and file transfer. When the network becomes congested, all OTT services are typically treated the same regardless of the impact on the quality perceived by the end user. They are typically scheduled as the same CoS. Additionally, OTT services are typically grouped into the same logical bearer. In today's communication systems, admission control is performed on a logical bearer basis, without considering the mixing of services on that bearer. As a result, real-time services such as voice, streaming video and streaming audio are perceived to have significantly lower QoE compared to non-real-time services such as email.

Methods, devices and systems are provided for collaborative applications in communication systems. In one aspect, the present invention provides an application manager node in a communication network, comprising a transceiver module configured to monitor data communication in the communication network, and a processor coupled to the transceiver, the processor operating in at least one terminal node. Receiving application information related to at least one application data stream associated with at least one application being executed from at least one terminal node, and including a relationship between each of the at least one application data stream and an access node based on the application information Update the relationship map, determine a comprehensive quality metric value associated with the access node based at least in part on application information received from one or more of the at least one terminal node, and based on the comprehensive quality metric value, at least one application data Configured to select at least one mitigation option for one or more of the streams.

In another aspect, the present invention provides a terminal node in a communication network having an access node, comprising a transceiver module configured to transmit and receive data packets in and out of an access node through a communication network, and a processor coupled to the transceiver, the The processor detects at least one application data stream by monitoring data packets transmitted and received in and out of the access node through the communication network, and for each of the detected at least one application data stream, a terminal associated with each application data stream As application information related to an application running in the node, application information including a data stream quality metric for each application data stream is determined, and application information for each of the detected at least one application data stream is transmitted to the communication network Transmit via, and receive at least one mitigation instruction associated with one or more of the at least one application data stream through the communication network, and implement at least one mitigation instruction for the associated one or more of the at least one application data stream. It is composed.

In another aspect, the present invention provides a method for managing application quality in a communication network, the method comprising an application related to at least one application data stream associated with at least one application operating in at least one terminal node. Receiving information from at least one terminal node, updating a relationship map including a relationship between each of at least one application data stream and an access node, based on the application information, from at least one of the at least one terminal node Determining a comprehensive quality metric value based at least in part on the received application information, and selecting at least one mitigation option for one or more of the at least one application data stream based on the comprehensive quality metric value. .

In another aspect, the present invention provides a method for managing application quality in a terminal node in a communication network, the method comprising monitoring data packets transmitted and received in and out of an access node through a communication network, thereby providing at least one application data stream. Detecting, for each of the detected at least one application data stream, a data stream for each application data stream as application information related to an application running in a terminal node associated with each application data stream Determining application information including a quality metric, and transmitting application information for each of the detected at least one application data stream through the communication network. The method includes receiving, via a communication network, at least one mitigation instruction associated with one or more of the at least one application data stream, and implementing at least one mitigation instruction for the associated one or more of the at least one application data stream. It further includes.

Other features and advantages of the present invention will become apparent from the following description illustrating aspects of the present invention by way of example.

Details of the present invention can be obtained in part by review of accompanying drawings in which similar reference numerals indicate similar parts, both for their structure and for their operation.
1 is a block diagram of a communication network in which the methods and systems disclosed herein may be implemented in accordance with aspects of the present invention;
2 is a block diagram of an access node in accordance with an aspect of the present invention;
3 is a block diagram of a terminal node according to an aspect of the present invention;
4 is an illustration of an aspect of an access node in accordance with an aspect of the present invention;
5 is a block diagram of a communication system showing a control plane relationship in accordance with an aspect of the present invention;
6 is a block diagram of an application and an application agent in accordance with an aspect of the present invention;
7 is a block diagram of a communication system with an application and an application agent in accordance with an aspect of the present invention;
8 is a block diagram of another communication system with an application and an application agent in accordance with an aspect of the present invention;
9 is a block diagram of a packet inspection module according to an aspect of the present invention;
10 is a block diagram of a communication network environment including a sensory quality manager module according to an aspect of the present invention;
11 is a block diagram of a communication network environment including a sensory quality manager module according to an additional aspect of the present invention;
12 is a block diagram of a master application module in a terminal node supporting haptic quality management according to an aspect of the present invention;
13 is a block diagram of a sensory quality manager module according to an aspect of the present invention;
14 is a flow chart depicting the functionality of a master application module in a terminal node supporting haptic quality management in accordance with an aspect of the present invention;
15 is a flow chart depicting the functionality of a sensory quality manager module in accordance with an aspect of the present invention;
16 is a flow chart depicting the functionality of a master application module in a terminal node supporting haptic quality management in accordance with an aspect of the present invention;
17 is a block diagram of a master application module in a terminal node performing haptic quality management according to an aspect of the present invention; And
18 is a flow chart depicting the functionality of a master application module in a terminal node performing haptic quality management in accordance with an aspect of the present invention.

A method and system is provided for a communication system with scheduling and admission control functions that are aware of application needs. Communication and cooperation between user equipment applications and application-aware base stations (or other network nodes) can improve the quality of experience (QoE) of users. The systems and methods are particularly useful for capacity and spectrum constrained multiple-access communication systems. In one aspect, the systems and methods disclosed herein may be used with classes of service that are associated with data streams or flows from heterogeneous applications.

The systems and methods disclosed herein can be applied to a variety of capacity-limited communication systems including wired and wireless technologies. For example, the systems and methods disclosed herein include cellular 2G, 3G, 4G, cellular backhaul, Wi-Fi, ultra mobile broadband (UMB), cable modems and others (including Long Term Evolution (LTE), LTE Advanced and WiMAX). It can be used with point-to-point or point-to-multipoint wired or wireless technologies. For the sake of brevity, various embodiments are described using specific techniques and standards of systems and predicates. However, the systems and methods described herein are widely applicable to other technologies and standards.

1 is a block diagram of a communication network in which the methods and systems disclosed herein may be implemented in accordance with aspects of the present invention. The macro base station 110 is connected to the core network 102 through a backhaul connection 170. In one embodiment, the backhaul connection 170 is a bidirectional link or two unidirectional links. The direction from the network 102 to the macro base station 110 is referred to as a downstream or downlink (DL) direction. The direction from the macro base station 110 to the core network 102 is referred to as an upstream or uplink (UL) direction. The subscriber stations 150(1) and 150(4) may access the core network 102 through the macro base station 110. The radio link 190 between the subscriber station 150 and the macro base station 110 is a two-way point-to-multipoint link in one embodiment. The direction of the radio link 190 from the macro base station 110 to the subscriber station 150 is referred to as a downlink or downstream direction. The direction of the radio link 190 from the subscriber station 150 to the macro base station 110 is referred to as an uplink or upstream direction. A subscriber station is sometimes referred to as a user equipment (UE), a user, a user device, a handset, a terminal node or a user terminal, and is usually a mobile device such as a smart phone or tablet. The subscriber station 150 accesses the content over the radio link 190 using a base station such as the macro base station 110 as a bridge. In other words, in general, a base station passes user application data and any user application control messages between subscriber station 150 and core network 102 without the base station being the source of data and control messages or the destination for data and control messages. give.

In the network configuration illustrated in FIG. 1, office building 120(1) causes coverage shading 104. The pico station 130 may provide coverage to the subscriber stations 150(2) and 150(5) in the coverage shade 104. The pico station 130 is connected to the core network 102 through a backhaul connection 170. The subscriber stations 150(2) and 150(5) are the same or similar to the radio link 190 between the macro base station 110 and the subscriber stations 150(1) and 150(4). ) Can be accessed.

For office building 120(2), enterprise femtocell 140 provides in-building coverage to subscriber stations 150(3), 150(6). The enterprise femtocell 140 may access the core network 102 through the Internet service provider network 101 by using the broadband connection 160 provided by the enterprise gateway 103.

To help allocate scarce communication resources, conventional communication systems have discriminated against traffic by a class of service (CoS) within a core network, as in a packet gateway (P-GW) within an LTE system. Within the CoS, traffic is usually treated similarly for the purpose of scheduling resource allocation. Within the CoS, traffic is usually treated similarly for the purpose of scheduling resource allocation. This enables operator-provided services such as voice and video from the operator's own or coordinated content delivery network (CDN) to receive QoS guarantees such as Guaranteed Bit Rate (GBR).

Traffic that is not associated with an operator-provided service may be referred to as over-the-top (OTT) traffic. Conventional systems typically have little or no difference between the various types of OTT traffic. Thus, heterogeneous traffic can be grouped into the same CoS. Moreover, such traffic is provided with resources on a best effort basis, for example without guaranteed bit rate. Thus, the conventional system ignores the QoS requirements of specific applications that generate OTT traffic, and ignores the perceived quality of experience (QoE) by the end user. In particular, OTT voice and video services such as Skype Internet Telephony (VoIP), YouTube progressive download video, Netflix streaming video, FaceTime interactive video, and Pandora Radio streaming audio as best effort traffic along with email, social networking and file transfer. May have been grouped together. When the network becomes congested, all of these services are typically treated the same regardless of the impact on the quality perceived by the end user. As a result, real-time services (eg, voice, streaming video and streaming audio) are perceived to have a significant drop in QoE compared to non-real-time services (eg, email).

In the communication network of FIG. 1 and in other wired and wireless networks, one or more data streams or services may be assigned an importance and a desired level of performance. The importance and desired performance level can be used to assign packets from each data stream to the scheduling group and data queue. The scheduling algorithm can also use that information to determine which queues (and thus which data streams and packets) to treat in preference to others.

The scheduling algorithm can use scheduling weights to convey the desired service level and importance of each queue. For example, weighted round robin (WRR) and weighted fair queuing (WFQ) scheduling methods can be used, both of which use weights to adjust services between data queues. The scheduling algorithm can also convey the importance and desired service level of each queue through the use of credits and debits. For example, the proportional fair scheduler (PFS) method can use credits and debits to control services between data queues. The scheduling algorithm may use a weight and convert the weight into a credit in the form of a number of bytes or packets to be served during the scheduling round.

Nodes in the communication network can improve QoE by using an application factor (AF) to dynamically modify the weight or credit used to allocate resources in the scheduler. AF may be related to the current session QoE level. A larger AF can be applied to sessions with low QoE, thereby increasing resource allocation. Conversely, smaller AFs can be applied to sessions with high QoE, thereby reducing the resources allocated to that session and releasing resources for use by other sessions. Devices in a communications network are described in US Patent Application No. 13/607,559 filed September 7, 2012 (name of the invention: "Systems and Methods for Congestion Detection for use in Prioritizing and Scheduling Packets in a Communication Network"). You can use a method for scheduling, which is incorporated herein by reference.

The network of FIG. 1 (such as macro base station 110, pico station 130, enterprise gateway 103, enterprise femtocell 140, devices in core network 102, and devices in Internet service provider network 101) My communication node and subscriber station 150 may communicate application-related information. Cooperation between the application in the subscriber station and the application agent in the communication node can improve the performance of the communication network, including user experience. Application-related information may be derived through inspection of packets passing through the communication node. For many applications, there may be additional information, such as client-side buffer occupancy, residing in the application in the subscriber station that can allow for more efficient and improved communication. Similarly, information, such as congestion status information, available within the communication node, which can assist the application in making more intelligent resource requests, which in turn will result in improved performance by the communication node, for example in the scheduler and admission control functions. Can exist. For example, a communication system may use application information and congestion information to improve communication channel resource allocation and to determine which session to accept, reject or modify.

Application-related communication or cooperation between client-side applications and communication node scheduling and admission control functions can improve QoE for users. Application-related communication and cooperation can improve QoE even when QoS resource guarantees are available. For example, resource guarantees may not cover instantaneous conditions such as congestion, peak-to-average bit rate, and heterogeneity of data between applications.

2 is a functional block diagram of an access node 275 in accordance with an aspect of the present invention. In various embodiments, the access node 275 is a mobile WiMAX base station, a global system for mobile (GSM) radio base station transceiver (BTS), a Universal Mobile Telecommunications System (UMTS) node B, an LTE evolution node B (eNB or eNodeB), It may be a cable modem head end, or other wired or wireless access node of various form factors. For example, the macro base station 110, the pico station 130, or the enterprise femtocell 140 of FIG. 1 may be provided by, for example, the access node 275 of FIG. 2. The access node 275 includes a processor module 281. The processor module 281 is coupled to a transceiver (transceiver) module 279, a backhaul interface module 285 and a storage module 283.

The transceiver module 279 is configured to transmit and receive communications with other devices. In various embodiments, communications are transmitted and received wirelessly. In such embodiments, the access node 275 generally includes one or more antennas for transmission and reception of radio signals. In another embodiment, the communication is transmitted and received over a physical connection such as a wired or optical cable. Communication of the transceiver module 279 may be performed with a terminal node.

The backhaul interface module 285 provides communication between the access node 275 and the core network. Communication may be through a backhaul connection, for example backhaul connection 170 of FIG. 1. Communication received via the transceiver module 279 may, after processing, be transmitted on the backhaul connection. Similarly, communications received from the backhaul connection may be transmitted by the transceiver module 279. Although the access node 275 of FIG. 2 is shown as having a single backhaul interface module 285, other embodiments of the access node 275 may include multiple backhaul interface modules. Similarly, the access node 275 may include multiple transceiver modules. A plurality of backhaul interface modules and transceiver modules may operate according to different protocols.

Processor module 281 may process communications received and transmitted by access node 275. The storage module 283 stores data for use by the processor module 281. The storage module 283 may also be used to store computer readable instructions for execution by the processor module 281. Computer readable instructions may be used by the access node 275 to accomplish various functions of the access node 275. In one embodiment, storage module 283 or portions of storage module 283 may be considered a non-transitory machine-readable medium. For the sake of brevity, the access node 275 or an embodiment thereof is described as having certain functionality. It will be appreciated that in some embodiments this functionality is achieved by processor module 281 with storage module 283, transceiver module 279 and backhaul interface module 285. Moreover, in addition to executing instructions, processor module 281 may include special purpose hardware to achieve certain functions.

The access node 275 may communicate application-related information with other devices. The access node 275 may receive application-related information from another device, transmit application-related information to another device, or both. For example, an application within a terminal node may work cooperatively with the access node 275 to improve QoE for users of the terminal node.

3 is a functional block diagram of a terminal node 255 according to an aspect of the present invention. In various embodiments, the terminal node 255 may be a mobile WiMAX base station, a GSM cellular phone, a UMTS cellular phone, an LTE user equipment, a cable modem, or other wired or wireless terminal node of various form factors. The subscriber station 150 of FIG. 1 may be provided, for example, by the terminal node 255 of FIG. 3. The terminal node 255 includes a processor module 261. The processor module 261 is coupled to a transceiver module (transceiver) 259, a user interface module 265 and a storage module 263.

The transceiver module 259 is configured to transmit and receive communications with other devices. For example, the transceiver module 259 may communicate through the access node 275 of FIG. 2 and its transceiver module 279. In embodiments where the communication is wireless, the terminal node 255 generally includes one or more antennas for transmitting and receiving radio signals. In another embodiment, the communication is transmitted and received over a physical connection such as a wired or optical cable. Although the terminal node 255 of FIG. 3 is shown as having a single transceiver module 259, other embodiments of the terminal node 255 may include multiple transceiver modules. Multiple transceiver modules can operate according to several different protocols.

The terminal node 255, in various embodiments, provides data to and receives data from a person (user). Accordingly, the terminal node 255 includes a user interface module 265. The user interface module 265 includes a module for communicating with a person. The user interface module 265, in one embodiment, includes a microphone and speaker for voice communication with a user, a screen for providing visual information to the user, and a keypad for receiving alphanumeric commands and data from the user. In some embodiments, a touch screen may be used in combination with or instead of a keypad to allow graphical input in addition to alphanumeric input. In an alternative embodiment, the user interface module 265 includes a computer interface, eg, a universal serial bus (USB) interface, to interface the terminal node 255 to the computer. For example, the terminal node 255 may be in the form of a dongle that can be connected to a notebook computer through the user interface module 265. The combination of a computer and a dongle can also be thought of as a terminal node. The user interface module 265 may have different configurations and may include functions such as a vibrator, a camera, and a light.

The processor module 261 may process communications received and transmitted by the terminal node 255. Processor module 261 may also process output to and input from user interface module 265. The storage module 263 stores data for use by the processor module 261. The storage module 263 can also be used to store computer readable instructions for execution by the processor module 261. Computer-readable instructions may be used by the terminal node 255 to achieve various functions of the terminal node 255. In one embodiment, storage module 263 or portions of storage module 263 may be considered a non-transitory machine-readable medium. For concise description, the terminal node 255 or its embodiment is described as having certain functionality. It will be appreciated that in some embodiments such functionality is achieved by processor module 261 with storage module 263, transceiver module 259 and user interface module 265. Furthermore, in addition to executing instructions, processor module 261 may include special purpose hardware to achieve certain functions.

The terminal node 255 may communicate application-related information with other devices. The terminal node 255 may receive application-related information from another device, transmit application-related information to another device, or both. For example, an application agent in the access node may work cooperatively with the terminal node 255 to improve QoE for users of the terminal node.

4 is an exemplary diagram of an aspect of an access node 475 in accordance with an aspect of the present invention. The access node 475 communicates with the terminal node 455 and the core network 410. The macro base station 110, pico station 130, enterprise femtocell 140, or enterprise gateway 103 of FIG. 1 is implemented using an access node 475, in some embodiments. The access node 475 may be implemented using, for example, the access node 275 of FIG. 2. The core network 410 may also be a service provider network, the Internet, or a combination of networks. For better understanding, in FIG. 4, a solid line represents user data and a broken line represents control data. The distinction between user data and control data is from the point of view of the access node 475. Since the access node 475 serves as a bridge, control data from the terminal node 455 to a predetermined entity, such as a video server, exists in the core network 410 recognized as user data by the access node 475. I can.

The access node 475 of FIG. 4 facilitates communication between the terminal node 455 and the core network 410 and other internal entities (eg, entities accessed through the Internet, such as a video server). The application 451 in the terminal node 455 communicates with a server application in or connected to the core network 410 through the access node 475. The application 451 provides a predetermined functionality or service to a user of the terminal node 455. For example, the application 451 may be a software program executed by the terminal node 455. The application 451 in the terminal node 455 also communicates with the application agent 470 in the access node 475. The application 451 may be, for example, a module provided by the processor module 261 of the terminal node 255 of FIG. 3 using a command from the storage module 263. The application agent 470 may be, for example, a module provided by the processor module 281 of the access node 275 of FIG. 2 using instructions from the storage module 283.

The application 451 and the application agent 470 communicate through an app-agent cooperative communication control path 403. Communication between the application 451 and the application agent 470 may provide improved communication system performance, for example, improved QoE for a user of the terminal node 455. An application that provides communication on the app-agent cooperative communication control path 403 may be considered an enhanced or cooperative application.

Although FIG. 4 illustrates a single instance of each element, in one embodiment, there may be multiple instances of various elements. For example, an access node may concurrently communicate with multiple end nodes, and each of the end nodes may have multiple applications capable of concurrently cooperating with one or more application agents in one or more access nodes. have.

The access node 475 includes a packet inspection module 429, a scheduler module 430, and a transmit/receive module (transceiver) 479. The packet inspection module 429, the scheduler module 430, and the transmit/receive module 479 are used by the access node 475 in communicating with the terminal node 455. The transmission/reception module 479 provides communication with the terminal node 455. The transmission/reception module 479 may implement, for example, a radio access network physical layer. The access node 475 also includes a resource control module 480 responsible for controlling various aspects of the resource. The application agent 470 may also communicate with the resource control module 480.

The packet inspection module 429 is in a data path between the core network 410 and the terminal node 455. In the downlink direction, the packet inspection module 429 receives data from the core network 410 and determines what to do with the data. For example, user data destined for the terminal node 455 may be differentiated into a queue in the scheduler module 430 for transmission to the terminal node 455 through the transmission/reception module 479. The discrimination into the queue may be based on various characteristics associated with user data, such as logical link, IP source and destination address, or application class. In one embodiment, packet inspection module 429 is part of or coupled to a data bridge/relay module. The packet inspection module 429 may also include a routing function performed before or after the data bridge/relay module.

Some data from the core network may be control data intended for control and configuration of the access node 475. This data may be directed to various control or management modules of the access node 475, for example, the resource control module 480.

The scheduler module 430 implements some or all of the functionality required to allocate physical resources across a communication link between the access node 475 and the terminal node 455. The scheduler module 430 is typically associated with or is part of a medium access control (MAC) layer. For the downlink direction, the scheduler module 430 determines which data to transmit and when to transmit. Resources can be allocated as subcarriers and timeslots, for example. The scheduler module 430 may also process uplink resource requests from the terminal node 455 and authorize the uplink bandwidth. The scheduler module 430 may use PHY information from the transmission/reception module 479, such as a modulation and coding scheme, to determine the amount of resources to be allocated to specific user data. The scheduler module 430 may also inform the resource control module 480 about statistics related to monitoring of congestion or congestion occurring on the communication link (eg, buffer occupancy and egress rate). In one embodiment, the scheduler module 430 may receive an update to the scheduler parameter, such as a change to the weight and credit, from the resource control module 480.

The packet inspection module 429 may also detect the application and provide application information such as application class, specific application, data rate and duration to the resource control module 480. In one embodiment, the packet inspection module 429 may help to receive admission control response information and implement an admission control response such as packet blocking for a specific connection or session.

The resource control module 480 illustrated in FIG. 4 includes a resource estimation module 481, a congestion monitoring module 482, an admission control response module 483, and a scheduler parameter calculation module 484. The resource estimation module 481 estimates the expected resource demand of the currently active application. The resource estimation module 481 may use application parameters, such as the expected data rate, and PHY parameters, such as changes in modulation and coding for the terminal node 455, to estimate the expected resource demand. Any excess in resources may be available or available to new applications to increase the resources allocated to the currently active application.

The congestion monitoring module 482 monitors the current congestion state. The current congestion state may vary from resource estimation performed by the resource estimation module 481. For example, when a short-term change in data rate occurs (e.g., a peak in data rate for variable data rate streaming video), the information from the scheduler module 430 is current, even if long-term resource estimation does not indicate congestion. May indicate congestion (eg, increased buffer occupancy for the application or decreased buffer exit rate for the application). The congestion monitoring module 482 may also maintain congestion history information that can be used to predict congestion.

The admission control response module 483 may generate a control response to accept, reject, delay, or modify a logical link, connection, and/or stream, thereby generating a control response for the session. The admission control response module 483 provides various information, for example, a policy (e.g., a user's priority or an acceptable user QoE level), service level agreement (SLA) information, application parameters (e.g., For example, a specific application or data rate), resource estimation, app-agent cooperative communication, and congestion indicators can be used to generate a control response.

The scheduler parameter calculation module 484 may calculate modifications to scheduler parameters such as weights and credits. The scheduler parameter calculation module 484 uses a variety of information, e.g., app-agent cooperative communication, policy, SLA information, application parameters, resource estimation, congestion indicator and control response (e.g., admission control response). Then you can calculate the correction.

The transmit/receive module 479, in addition to facilitating uplink and downlink data transmission, also includes physical layer (PHY) parameters such as modulation, coding, and signal-to-noise ratio (SNR) associated with communication with the terminal node 455, and You may be monitoring or maintaining the condition. The ability of the access node 475 to communicate with the terminal node depends in part on the PHY parameters and state. Information about the PHY parameters and status may be made available to the scheduler module 430 to make scheduling decisions and to the resource control module 480 to calculate the scheduler parameter adjustment or determine an admission control response. The transmit/receive module 479 may also facilitate or generate communication between the radio access protocol module and the terminal node 455 in the access node 475.

In the uplink direction, the packet inspection module 429 receives user data from the terminal node 455 through the transmission/reception module 479 and forwards the user data to the core network 410. The packet inspection module 429 also receives communication from the terminal node 455 with the application agent 470 as a destination. The packet inspection module 429 can identify these communications and forward them to the application agent 470.

The application agent 470 and the application 451 establish an app-agent cooperative communication control path 403. The app-agent cooperative communication control path 403 may be, for example, a TCP connection. The app-agent cooperative communication control path 403 is used to exchange app-agent cooperative communication. Routing of data on the app-agent cooperative communication control path 403 may be facilitated by the packet inspection module 429. Alternatively, its routing may be facilitated by a routing function that may be inside or outside the access node 475.

The app-agent cooperative communication from the application 451 to the application agent 470 may include, for example, information that enables the access node 475 to improve admission control and scheduling. Communication between the application agent 470 and the application 451 may provide, for example, additional information to the resource control module 480.

An example for an introduction to app-agent cooperative communication considers a communication network in which the application 451 provides YouTube streaming video to the user of the terminal node 455. Streaming video may be available in a number of formats with several different associated data rates. The information on the format may be communicated by a YouTube specific application to a YouTube-aware application agent that can sequentially provide information on the format to the resource control module. The resource control module may use the application information to generate an admission control response indicating which format, if any, matches the current estimate of the available resources. The YouTube-aware application agent can process the admission control response into the app-agent cooperative communication to the YouTube-specific application by specifying which formats are currently acceptable. In various embodiments, a particular selection of formats may be made by or by the application agent and communicated back to the application agent. The application agent may inform the resource control module of the selected format and associated data rate. The resource control module updates the resource estimate and scheduler parameters to reflect the selected format.

4 illustrates specific distribution of modules within various communication nodes and specific allocation of functions to various modules. Several other arrangements can also be used. For example, some or all of the packet inspection module 429, the application agent 470, and the resource control module 480 are in a gateway node in a core network, for example, a serving gateway (S-GW) in an LTE network or May be in the packet gateway (P-GW). Additionally, there may be an intermediate device between the access node 475 and the core network 410 and the terminal node 455. Several combinations of applications and application agents and their related functions may also be used. For example, one application agent to communicate with all applications, one application agent for each specific application (e.g. YouTube application agent, Pandora application agent, etc.), one application agent for each end node, Alternatively, there may be one application agent for each application (eg, a YouTube application agent for a first terminal node and another YouTube application agent for a second terminal node). When there are multiple applications and application agents, there may be individual communication connections (eg, TCP/IP connections) between each pair of applications and application agents. Alternatively, communication between multiple applications and application agents may be aggregated and carried over a reduced number of connections. For example, a single TCP/IP connection can be used to communicate between multiple application agents and applications for a particular terminal node.

The application agent 470 uses connection-oriented and byte stream based protocols to perform connection lifecycle management and segment buffering and reordering for TCP/IP connections and other connections, for example, by using an instance of the TCP stack. I can. Alternatively, app-agent cooperative communication can use a simplified communication connection, eg UDP/IP.

5 is a block diagram of a communication system showing a control plane relationship in accordance with an aspect of the present invention. The communication system includes a terminal node 555, an access node 575, and an application server 590. The terminal node 555 includes an application 551 that communicates with the server application 592 in the application server 590. Communication is through the access node 575. Application 551 also communicates with application agent 570 in access node 575.

The example protocol, control plane relationships, and other descriptions of FIG. 5 may be used to further understand aspects related to the access node 475 of FIG. 4. The access node 475 of FIG. 4 may be the same as or similar to the access node 575 of FIG. 5. The terminal node 455 of FIG. 4 may be the same as or similar to the terminal node 555 of FIG. 5. Similarly, communication between the access node 575 and the application server 590 may use the same or similar network as the core network 410 of FIG. 4. Further, the application server 590 of FIG. 5 may be in or connected to the same or similar network as the core network 102 or the Internet service provider network 101 of the communication network of FIG. 1. The application server may also be a network of separately located servers. Although the communication system of FIG. 4 uses the LTE protocol stack, other communication systems may use other protocol stacks. There may be more or fewer protocol layers, layer names and predicates may be different, their functionality may be different, and in which layer the function resides may be different.

Devices in a communication network often communicate over a communication path through a multi-layered protocol. The protocol stack in the communication device implements the protocol. For example, the application data path 501 conveys communication between the application server 590 and the terminal node 555 through the access node 575 using a protocol stack in each device. In addition to the protocol stack for handing over user application data and control, there may be a protocol stack for implementing and managing a communication link supporting the user application.

The access node 575 of FIG. 5 includes a RAN control plane protocol stack to implement a radio access network (RAN) control plane protocol for control plane communication between the terminal node 555 and the access node 575. The RAN control plane protocol in the access node 575 may be implemented using, for example, the processor module 281 of the access node 275 of FIG. 2 using instructions from the storage module 283. The RAN control plane protocol stack in the access node 575 includes a RAN physical (PHY) layer module 525, a medium access control (MAC) layer module 520, a radio link control (RLC) layer module 515, and packet data convergence. (PDCP) layer module 510, and radio resource control (RRC) layer module 505. Each of these protocol stack layers in the access node 575 has an equivalent layer in the terminal node 555. Thus, the RAN control plane protocol stack in the terminal node 555 is a PHY layer module 525', a MAC layer module 520', an RLC layer module 515', a PDCP layer module 510', and an RRC layer module ( 505').

In the control plane, RAN control information is typically exchanged between higher or lower layers within the same node, thereby logically creating a P-to-P control link between the layer on the access node 575 and the corresponding layer on the terminal node 555. do. The RAN control path 502 connects the peer layers of the terminal node 555 and the access node 575. Although FIG. 5 illustrates a single terminal node 555, the RAN control plane layer on the access node 575 may have logical control links to multiple equivalents on multiple terminal nodes.

The peer RAN control plane layer module exchanges control information necessary to control and operate a communication link between two devices. This control information originates and terminates within the access node 575 and the terminal node 555 and is specific to communication link operation and management. In contrast, user application data and application control messaging originate and terminate on terminal node 555 and application server 590. From the perspective of the access node 575, user application data and application control messaging can be thought of as being transmitted on the data plane rather than the control plane.

The RAN physical layer module 525 of the access node 575 has a control message equivalent relationship with the RAN physical layer module 525' of the terminal node 555. The RAN physical layer module 525 of the access node 575 may request a change in transmission power of the RAN physical layer module 525' of the terminal node 555, for example. The RAN physical layer module 525' of the terminal node 555 may send a radio link quality metric, such as a signal-to-noise ratio (SNR) measure, to the RAN physical layer module 525 on the access node 575. The MAC layer module 520 of the access node 575 has a control message equivalent relationship with the MAC layer module 520' of the terminal node 555. The MAC layer module exchanges, for example, resource requests and grants. The RLC layer module 515 of the access node 575 has a control message equivalent relationship with the RLC layer module 515' of the terminal node 555. The RLC layer module may exchange data segmentation and reassembly information, for example. The PDCP layer module 510 of the access node 575 has a control message feeder relationship with the PDCP layer module 510' of the terminal node 555. The PDCP layer module exchanges, for example, encryption and compression information. The RRC layer module 505 of the access node 575 has a control message equivalent relationship with the RRC layer module 505' of the access node 575. The RRC layer module may exchange, for example, a quality of service (QoS) parameter of a logical link.

The exchange of information between peer layers using control path 502 may be based on the use of one or more logical, transport and physical channels. In LTE, for example, cell-wide system information is defined in the RRC layer module 505 in the access node 575 and is one or more system information blocks (SIBs) and master information blocks (master information blocks). It is communicated to the terminal node 555 via a data set formed as an MIB). The MIB and SIB are a logical broadcast control channel (BCCH), a transport broadcast channel (BCH), and finally a physical broadcast channel (PBCH) and a physical downlink shared channel (physical). It is passed down the stack via downlink shared channel (PDSCH). Control channel information to be sent to a specific UE node is communicated through a signaling radio bearer (SRB) connection, and is a logical downlink control channel (DCCH) and a transmission downlink shared channel (DL-SCH). And a physical downlink shared channel (PDSCH).

For communication between the application 551 and the server application 592, the transmission and access protocol module 550 ′ on the terminal node 555 and the equivalent transmission and access protocol module 550 on the application server 590 are provided with an application data path. Used to establish 501. The application data path 501 transmits application control data and application user data. In various embodiments, the application data path 501 may use the same or different transport and access protocols for application control data and application user data. Additionally, the same or different instances of the protocol stack (eg, software processes) may be used for application control data and application user data.

The application data path 501 may be viewed as communicating user data by means of the RAN protocol stack. Unlike data on the RAN control path 502, data from the terminal node 555 on the application data path 501 is not terminated at the access node 575. Instead, data on application data path 501 is bridged by data bridge/relay module 530 to a communication link for ultimate transmission to application server 590. When an application does not provide app-agent cooperative communication, all application traffic can be bridged to the next node. For such applications, application control may be limited to communication between the application and the associated server application.

The transmission to the application server 590 may involve multiple links from the access node 575 through, for example, a gateway node or a router node. The access node 575 may use an additional transport and access protocol module 563 to communicate with the first upstream communication node through an additional physical layer module 565. The transport and access protocol module 563 may use, for example, an evolutionary general packet radio service (GPRS) tunneling protocol (eGTP). The physical layer module 565 may transmit data over a microwave backhaul or carrier Ethernet link, for example. At the application server 590, data is received via the physical layer module 597 and passed to the transport and access protocol module 550. Accordingly, the transmission and access protocol module 550 in the application server 590 provides a protocol comparable to the protocol used in the transmission and access protocol module 563 in the access node 575 and communicates with the terminal node 555. In addition to a protocol for communication, a protocol for communication with another communication node between the application server 590 and the access node 575 may be provided.

Data on the application data path 501, data on the RAN control path 502, and data on the app-agent cooperative communication control path 503 are transmitted between the terminal node 555 and the access node 575 through the RAN protocol stack. do. However, the packet inspection module 529 in the access node 575 may convert the app-agent cooperative communication to the application agent 570. Generating and communicating messages on the app-agent cooperative communication control path 503 is an additional protocol in the access node 575 that is comparable to the protocol used in the transmission and access protocol module 550' in the terminal node 555. You can use Additional protocols may be provided, for example, by packet inspection module 529 or application agent 570.

Networks use layers of protocols to abstract the functionality of one layer from those provided by another layer. Layered abstraction can make the application more portable across different networks. The initiation and subsequent termination of the flow of packets in the network can be triggered by a specific application or service. The flow of user data packets and control over the use of end-user applications or services is referred to as a session. Examples of sessions include voice (VoIP) calling from a laptop over the Internet Protocol using the Skype application, streaming video playback using the YouTube app running on an Android-based mobile phone, and two-way video calling using the Apple iChat application. Includes.

A network node, such as an application server or proxy server, and a terminal node, such as a smart phone, tablet, or laptop computer, may initiate or join a session. A node can host more than one session at the same time. The sessions may be independent from each other (eg, a user using Facebook and email at the same time) or related to each other (eg, a browsing session resulting in two video streaming sessions). A session can be established between two nodes. Alternatively, a session can be viewed as a relationship between one node and several nodes, for example through the use of multicast and broadcast packet protocols.

Sessions can be characterized or categorized by various criteria. A specific application may refer to a specific application initiated by the user and responsible for launching the session. Examples of specific applications include the YouTube app, Chrome Internet browser and Skype voice calling software. More generally, application classes can be used to describe the aggregate functionality served by a particular session. Example application classes include streaming video, voice calling, internet browsing, email, and gaming.

A session can consist of one or more independent data streams using the same or potentially different underlying connections. For example, a single VoIP phone call session may contain two streams of data. One data stream can serve two-way voice traffic (ie, payload or data plane packets) using a User Datagram Protocol (UDP) connection. The second data stream may use one or more Transmission Control Protocol (TCP) connections to handle call establishment/disconnection (i.e. signaling or control plane packets), such as when using Session Initiation Protocol (SIP). . In the example of video Skype, one stream carrying SIP signaling to start, stop, and otherwise control a session, a second stream carrying voice packets using Real Time Transport Protocol (RTP), and video using RTP. There may be a third stream carrying packets.

When an application is initiated by a user on a terminal node, the application can be started with control signaling between the application server and the associated application server. For example, when the YouTube app is launched, it requests information about the selection of available video feeds from the YouTube feed server in a number of simultaneous Hypertext Transfer Protocol (HTTP) requests. The YouTube feed server responds with data about the feed in a compressed format with an HTTP response. Each HTTP request/response is performed on a separate TCP connection established through a TCP establishment (eg, SYN, SYN-ACK, and ACK message) protocol between the TCP stack on the terminal node and the TCP stack on the YouTube server. Once the video feed data has been received, the YouTube app can use a number of simultaneous HTTP GET requests to query the thumbnail image from the YouTube image server for the videos listed in the feed data. The YouTube image server provides the requested thumbnail image as an HTTP response. Each thumbnail request/response is carried on its own separate TCP connection.

For each video in the video feed and search results, multiple uniform resource locators (URLs) for different formats of the video are provided. The YouTube app decides which format to use based on its capabilities and user configuration and preferences. The YouTube app sends an HTTP GET request to the server with the URL of the video in the selected format. The YouTube server sends the requested video back in an HTTP response. HTTP responses are segmented into multiple IP packets. The first IP packet of the HTTP response carries an HTTP response status code (200 = OK). An example HTTP response header is shown below.

In the above example, the HTTP response header "Content-Type" indicates that the MP4 format video is included in the response. The HTTP response header "Content-Length" indicates that the length of the MP4 video included in the HTTP response is about 57MB.

6 is a block diagram of an application and an application agent according to an aspect of the present invention. The application agent is associated with the access node 675; The application is associated with the terminal node 655. The application in the terminal node 655 operates cooperatively with the application agent in the access node 675. Application agents and applications can be used, for example, in the communication system of FIG. 4. The access node 675 of FIG. 6 may be the same as or similar to the access node 475 of FIG. 4 in various embodiments, and the terminal node 655 of FIG. 6 is the terminal node 455 of FIG. 4 in various embodiments. May be the same as or similar to

The access node 675 includes a master application agent 670. The master application agent 670 communicates with the master application 651 in the terminal node 655. In one embodiment, the master application 651 is part of the operating system of the terminal node 455. The master application agent 670 and the master application 651 include a specific application agent 671(1)-671(n) in the access node 675 and a specific application 653(1)-653 (in the terminal node 655). n)) to facilitate communication between them.

Master application agent 670 and master application 651 may facilitate communication between all specific application agents 671 and specific applications using a single TCP connection. An IP path is established between the master application 651 and the master application agent 670 in one embodiment.

The master application 651 and the master application agent 670 may recognize, by various techniques, the IP address of the associated access or its equivalent, which may or may not be the same as the IP address of the terminal node. For example, the access node may establish or discover the IP address of the terminal node when the terminal node enters the network. In many embodiments, there may be multiple concurrently operating terminal nodes and thus the master application agent 670 is aware of multiple peer node addresses. Address Resolution Protocol (ARP) can be used when a suitable base layer 2 address on which the ARP function can be based is available (eg, Ethernet MAC address). Alternatively, the master application agent 670 may assign an address to the master application 651 using a dynamic assignment technique, such as Dynamic Host Configuration Protocol (DHCP). Alternatively, the IP route information can be programmed into the master application 651 and master application agent 670 by an operator, for example via a management connection. Alternatively, the access node 675 advertises the IP address of the master application agent 670. The IP address may be advertised as an augmentation of a control channel that is already ready to control the RAN (eg, using the RAN control path). For example, the access node 675 may include an address in a network entry response for a terminal node when it joins the network or address it on a broadcast control channel (e.g., an LTE system information block (SIB) channel). Can broadcast.

The IP address may not need to be routable outside the network defined by the access node and associated terminal node. Thus, a variety of well-known, non-routable IP addresses can be used. The allocation of non-routable IP addresses in the LTE network may be based on the eNodeB physical cell ID (PCI). For example, the IP address of the master application agent in the eNodeB may be assigned a 9-bit offset (of 9 least significant bits) plus a base address of 172.16.0.0 corresponding to the 9-bit PCI value. The master application agent in the eNodeB with a PCI value of 255 will be assigned an IP address of 172.16.0.255. Since the eNodeB PCI is broadcast to all UEs within the service provision range of the eNodeB, the master application agent IP address will be calculated by the UE without RAN signaling overhead. These techniques can also be applied to IPv6 addressing.

Similarly, the IP address of the master application in the LTE user equipment may also be a non-routable address. The non-routable address can be formed from a combination of the base address (using IPv4 or IPv6) plus an offset. The offset may be based on, for example, a default radio bearer identifier or a temporary mobile subscription ID (M-TMSI). Since the addressing scheme may be known by the master application agent, the IP address of the master application may be known without RAN signaling overhead.

Alternatively, an IP datagram sent as part of an App-Agent cooperative communication may use a combination of an all-zero (0.0.0.0) source address and a broadcast or multicast destination address. In one embodiment, communication from the master application agent 670 to the master application 651 may use an IP source address of 0.0.0.0 and a broadcast destination address of 255.255.255.255. Alternatively, a multicast address can be used as the destination address, in the range 224.0.0.0 and 239.255.255.255. In one embodiment, the multicast or broadcast destination address, once assigned and found using the techniques described above, may be replaced by a suitable unicast IP address. Similar methods and addresses may be used for specific application agent 671 and specific application 653. The IPv4 addressing method described above can be extended to work within an IPv6 network.

In one embodiment, communication between master application 651 and master application agent 670 is over a control communication channel specific to Radio Access Technology (RAT). The communication can, for example, use individual or broadcast messages. To facilitate new specific applications, RAT specific messages can be used that provide a container for application specific messages. For example, in an LTE network, referring to FIG. 5, one or more signaling radio bearers (SRBs) may be used to carry messages into and out of the application 551 and the application agent 570. In one embodiment, the message may be carried on one or more existing SRBs as defined by the Third Generation Partnership Program (3GPP) standard. Alternatively, messages may be carried on one or more SRBs established for the purpose of carrying messages between the application and the application agent. In such a scenario, the packet inspection module 529 in the access node 575 is an app sent on the SRB between the terminal node 555 and the access node 575 rather than forwarding the message to the MME as defined by the 3GPP standard. Agent cooperative communication messages can be intercepted, processed, and responded.

In an alternative embodiment, the app-agent cooperative communication may use an established or dedicated user data plane communication channel for the purpose of communicating application data traffic between the access node 575 and the terminal node 555. In this case, the app-agent cooperative communication on the logical app-agent cooperative communication control path 503 and the user data traffic on the logical application data path 501 may reside on the same user data plane communication channel. For example, in the LTE network, the app-agent cooperative communication is carried on an existing default data radio bearer (DRB) or a dedicated DRB, and is indicated for consumption at the access node rather than forwarding to the core network or Can be marked. Alternatively, a new dedicated DRB may be created for the purpose of carrying the app-agent cooperative communication. Additionally, the app-agent cooperative communication may be carried on multiple DRBs or a combination of one or more SRBs and one or more DRBs. For example, different bearers may be associated with different specific applications or specific groups of applications.

In one embodiment, a DRB dedicated to the purpose of carrying app-agent cooperative communication may be generated without using signaling between the terminal node 555 and the core network. For example, in an LTE network, a DRB dedicated to the purpose of carrying app-agent cooperative communication can be generated without the involvement of a mobility management entity (MME) located in the core network, thereby reducing signaling. And improve the efficiency of the network. In such a scenario, the packet inspection module 529 in the access node 575 is the terminal node 555 rather than forwarding the message to the MME or S-GW as defined by the 3GPP standard for signaling message and data traffic, respectively. ) And the app-agent cooperative communication message sent between the access node 575 may be intercepted, processed, and responded.

Master application agent 670 and master application 651 may also process app-agent cooperative communications. For example, the master application agent 670 or the master application 651 may coordinate, combine, or otherwise manipulate information communicated between the specific application agent 671 and the specific application 653.

The master application 651 may process the app-agent cooperative communication such that the specific application 653 does not need to be aware of or be associated with the app-agent cooperative communication. This can enable existing specific applications to benefit from app-agent cooperative communication without modification.

In one embodiment, the master application 651 may intercept streaming video communication between an application on a terminal node and a server application and filter available video representations based on system capacity limitations. For example, consider the YouTube streaming video example described above. Streaming video may be available in multiple formats and representations, each with an associated data rate. For example, the YouTube server may use a progressive download format that allows a YouTube application (an example of a specific application 653) to select a playback file from among a set of files each having a different bit rate, via an HTTP GET command have. A list of available formats and bit rates is passed through a list of URLs (one per playback file) and is usually sent from a YouTube server to a YouTube application. The list may be intercepted by the master application 651 and filtered based on the limit of available capacity before being handed over to the YouTube application.

Filtering can take several forms. In one embodiment, the list of available formats intercepted by the master application 651 is sent to either the master application agent 670 or the specific application agent 671 via app-agent cooperative communication. The format can be filtered by the master application agent 670 or a specific application agent 671. Filtering may occur after consultation with the resource control module (eg, the resource control module 480 of FIG. 4 ). For example, during a congestion period, the resource control module may provide an admission control response that limits all video streaming to a bit rate less than 1 Mbps. The master application agent 670 or specific application agent 671 retrieves all streaming options (e.g., URLs) with a bit rate greater than 1 Mbps from the list of available formats before sending the filtered list back to the master application. Use this information to delete it. In an alternative embodiment, the master application agent 670 may provide periodic updates describing the current limit to the streaming video bit rate to the master application 651 via app-agent cooperative communication. In turn, the master application 651 uses this information to locally filter the bit rate options before sending them to a YouTube specific app. The above technique can be applied to any video playback technology involving multi-bitrate streams, such as Dynamic Adaptive Streaming (DASH) over HTTP, Microsoft's Smooth Streaming, Apple's Live Streaming, and Adobe's Dynamic Streaming.

Information or requests that may be common to many different applications may be aggregated. For example, the master application agent 670 may provide current congestion and redundant resource headroom to the master application 651. Thereafter, the master application 651 may supply congestion and resource headroom information to the specific application 653.

Additionally, a common query, e.g., whether a particular application class (e.g., voice, video) at a particular data rate can be supported at the desired QoS level is determined by a single master application rather than at each particular application and a particular application agent. -Can be implemented uniformly in the master application agent pair. Admission control responses, such as those that terminate or modify a service, may additionally be implemented in master application 651 and master application agent 670.

In addition to supporting common application-generated cooperative communication, master application agent 670 and master application 651 can pass any app-agent cooperative communication. That is, cooperative communication specific to a specific application 653 and a specific application agent 671 of a specific pair may pass through the master application 651 and the master application agent 670. For example, cooperative communication about the video client playback buffer status may pass from one of the specific applications 653 to one of the specific application agents 671 through the master application 651 and the master application agent 670.

The use of a master application agent or master application can reduce signaling overhead and reduce the burden on application developers. This may also reduce the complexity of interfacing the application agent(s) 671 with other functions in the access node 675, such as a resource control module.

Several variations on the application agent and application shown in FIG. 6 are possible. For example, a master application may communicate directly with a specific application agent in an access node that does not contain a master application agent. Similarly, the master application agent can communicate directly with a specific application in the terminal node that does not include the master application agent. Additionally, in addition to the master application agent, the access node may have one or more application agents that directly communicate with the specific application, and the terminal node may have one or more applications that directly communicate with the specific application agent in addition to the master application. . Moreover, the scheme (or variations thereof) discussed above can be used even in the absence of a master application agent or master application.

The presence or absence of the master application agent in the access node may be signaled using a data field or bit in an existing broadcast control channel, for example, in an LTE SIB or MIB message. Data fields or bits may use existing but unused positions in the message. Alternatively, a new field in the existing SIB message or an entirely new SIB may be created for the purpose of indicating the existence of the master application agent.

In one embodiment, the access node 675 communicates the presence or absence of the master application agent 670 through communication to an element in the core network that subsequently informs the terminal node 655. For example, in an LTE network, the eNB may send a message indicating the presence or absence of a master application agent on the eNB to an MME server located in the EPC core network using a 3GPP defined S1 communication channel. The 3GPP S1-configuration/eNodeB configuration update can be enhanced to indicate application agent support by the use of ASN.1 extension markers and new fields using the TLV (type-length-value) format. Upon receipt of the S1 message, the MME may send presence information to the UE through a 3GPP NAS message. Several other signaling methods can also be used.

The terminal node 655 may, in an embodiment, signal the presence or absence of the master application 651 through communication to an element in the core network. For example, the LTE UE may signal the presence of the master application 651 through a NAS message sent to the MME. For example, the UE-specific S1-initial content configuration/E-RAB configuration/modification message may be modified to include presence information as an optional element of the TLV format. Following reception by the MME, the MME then communicates the information with the appropriate eNB.

In one embodiment, the access node 675 may communicate the presence or absence of the master application agent 670 by adding a presence bit to the packet header of one layer of the RAN protocol stack (e.g., Packet format defined for the packet data convergence layer, radio link control layer, or medium access control layer). A similar technique may be used by the terminal node 655 to indicate to the access node 675 the presence of the master application 651.

App-agent cooperative communication can be used in many ways. The following paragraphs describe examples of app-agent cooperative communication. While many examples have been described for specific applications and specific network technologies, it should be understood that the examples and variations are broadly applicable to other applications and other network technologies. Similarly, although many examples have been described for app-agent cooperative communication between an application agent in an access node and an application in a terminal node, it should be understood that the examples and variations are broadly applicable to other devices.

App-agent cooperative communication can be used to adapt video communication to change communication network conditions, eg, RAN conditions. For real-time video streaming protocols, for example, an application agent may inform an associated real-time streaming video application when the communication system has more or less resources available. The application agent may inform the application about network conditions, for example, by communicating resource availability or by communicating a new preferred or maximum data rate or resolution for video. When requesting the next block or segment of video, the application may request a segment with a different average or peak bit rate or different resolution to adapt the video to resource changes.

In one embodiment, the application agent may inform one or more video applications about the estimated future resource availability. An estimate of future resource availability may be communicated as a single number (eg, 2 Mbps) over a defined period (eg, the next 2 seconds). Alternatively, multi-point estimates can be used to describe the relationship between time and future capacity over longer horizontal lines. An example of multi-point estimation is shown in the table below. In the tabular state, the second column estimated the capacity at a given time in the first column.

The video application can use the estimated future capacity to select the next video segment so the bit rate is at or below the estimated future bit rate capacity during the segment duration. For example, consider a video stream with a 2-second segment available at three different bit rates: 0.7 Mbps, 1.3 Mbps and 2.5 Mbps. If the video application is informed that the estimated future bit rate will be reduced from 1.5 Mbps to 1.0 Mbps, then the application that was drawing the 1.3 Mbps segment at the time may select the 0.7 Mbps segment at the next opportunity.

Video applications say that in the future the capacity may be reasonably larger and that the current local buffer occupancy is sufficient to ensure stop-free operation until a larger capacity becomes available (e.g. the local buffer will not be empty). It is possible to use the estimated future bit rate to advocate a bit rate greater than the current capacity when expected. For example, consider a video application that fetches a 2.0 Mbps segment and stores 10 seconds of video in its local buffer. At that time, the application predicts that the capacity will drop from the current (time = 0) value of 2.0 Mbps to the minimum value of 0.5 Mbps at 3 seconds of time, and then in the future, the capacity will recover rapidly and exceed the current value, as shown in the table above. Receive the estimated future capacity. If the capacity deficit (ie, the estimated capacity is less than the current segment bit rate) is shorter than the amount of locally buffered video, the application may continue to fetch segments with a bit rate greater than the current capacity. In the example above, the undercapacity starts at t=1 second and ends at t=4 seconds, so it is 3 seconds. If the local buffer occupancy is 10 seconds, the video application will continue to fetch the 2.0 Mbps segment.

Conversely, an estimate that future resources may be declining can be used by video applications to reduce the bit rate for the next segment of video prior to reduction, thereby increasing the client buffer occupancy and impact of upcoming reductions (e.g., playback Stop).

Various methods can be used to estimate future resource availability. For example, the history of resource availability may be stored in the resource estimation module. The correlation of resource availability to time of day, day of week, and other events can enable application agents to predict whether future resources will be larger or smaller than current resources. For example, LTE eNBs serving major interstate highways can see peak demand during morning and evening weekday commuting. Based on the historical data, the application agent can predict that resources per user will drop at an average rate of 2% per minute over the next 30 minutes over the next 30 minutes, for example as commuter traffic increases.

Additionally, resource availability between a specific terminal node and an access node may be estimated based on a repetition pattern of time-varying channel conditions. For example, the resource estimation module 481 in the access node 475 may track the DL and UL modulation and coding scheme (MCS) of a specific terminal and determine that a repetition pattern exists. For example, the user's channel conditions (and thus available capacity) may change from good to bad and back to good at a 5-minute cycle every day around 5 pm. Such a pattern can be attributed to office workers leaving their desks and walking into their cars. In one embodiment, the access node uses knowledge, such as time of day, and matches the recent channel history (eg, the last minute) with a channel pattern on the history (eg, established in a 5-minute period) to allow the user to It can again be determined that is in such a pattern. Once the pattern is detected, the future capacity can be estimated by projecting forward from the current position in the detected historical pattern.

Estimation of future resource availability can also be made through extrapolation. For example, a linear regression of recent capacity (per terminal node and also for access nodes as a whole) can be used to predict capacity in the near future. Other forms of hysteresis curve fitting (eg, polynomial, exponential) can also be used to extrapolate resource availability.

App-agent cooperative communication can be used to coordinate the scheduling of communication from the access node.

A device using application-aware scheduling can obtain information about an application from the app-agent cooperative communication. The information on the application obtained through the app-agent cooperative communication may have been difficult or impossible to obtain otherwise. App-agent cooperative communication can reduce or eliminate the need for application detection and application information detection for cooperative applications. For example, as described in U.S. Patent Application No. 13/607,559, filed September 7, 2012 (title of the invention: "Systems and Methods for Congestion Detection for use in Prioritizing and Scheduling Packets in a Communication Network"). When a device capable of performing the same application detection and application information detection communicates with an application that provides an app-agent cooperative communication, less detection can be performed. Cooperation can also provide more accurate information about the state of the application. For a video session, for example, the app-agent cooperative communication can communicate whether the video is in an initial buffering state, a playback/viewing state, a pause state, a stop state, a rewind state, or a fast forward state. . The access node may use the video state in scheduling and admission control decisions.

The low initial buffering time (the duration of the buffering period between when playback starts and the initial data request) is important for user QoE during playback of streaming video. In one embodiment, the scheduling resource applied to the streaming video session by the access node may be temporarily increased to reduce the initial buffering time. This can be achieved by increasing the AF for the streaming video session during the initial buffering period. Information on the initial buffering period may be communicated to the access node through the app-agent cooperative communication. The information on the initial buffering period may include, for example, that the terminal node has a video within the initial buffering period and the number of bytes ("remaining bytes") that must be received before starting playback. The scheduling resource can be increased until the transmission of the remaining bytes is complete. Additionally, admission control requests that may be made by new users may be deferred until the initial buffering period of one or more video sessions for one or more existing users is complete. The access node may calculate the completion time of the initial buffering period by dividing the remaining bytes by the current or predicted resource allocated to the video stream (eg, expressed in bytes per second).

App-agent cooperative communication may communicate playback buffer status, local video buffer occupancy, and freeze indication from a video client application. The scheduler parameter in the access node can be adjusted accordingly. In one embodiment, the communication resources allocated to the video session by the access node may be based on the current buffer occupancy as communicated from the terminal node through the app-agent cooperative communication. For example, consider a terminal node at risk of stopping by reporting a low buffer occupancy rate. In such a case, the access node may increase the resources allocated to the video session by increasing the AF or scheduling priority for the associated packet. Conversely, consider a terminal node reporting a high buffer occupancy. For such video sessions, scheduling resources can be reduced through AF or reduction of scheduling priority, thereby releasing resources for other sessions.

App-agent cooperative communication can be used in admission control decisions. App-agent cooperative communication can be used to create a more accurate picture of the resource demand for the application-aware admission control system. For example, a cooperative application on a terminal node, such as a streaming video client, may report the average bit rate and duration of a streaming video session using app-agent cooperative communication. Such information can be used by the access node in calculating current and future resource demands. By subtracting the resource demand from the access node capacity, a measure of available excess capacity that can be applied to new services requesting acceptance is created.

App-agent cooperative communication can be used to provide an increased option to accept a modified version of a session or modify another session to provide an increased option to allow a new session. For example, a cooperating application on a terminal node can use an app-agent cooperative communication to a set of bit rate options available for a video clip (e.g., "dynamic adaptive streaming over HTTP" or to a DASH server during session initiation. By doing so, the rendering bit rate list transmitted to the DASH application can be communicated. Based on the available excess capacity, the access node may eliminate or prohibit the use of one or more of the higher bit rate options in the list. The reduced list can be communicated back to the terminal node to provide the reduced bit rate option set to the application. This allows for reliable video playback within the constraints of the available capacity of the access node. Additionally or alternatively, for networks with multiple terminal nodes, support of a new video session, such as the DASH session above, may include sending an updated bit rate list to one or more video sessions already in progress. For example, in order to support a new tenth DASH video session (a ninth ongoing session and a tenth session to be added), the access node not only reduces the maximum bit rate available for the tenth session, but also supports the tenth session. An updated bit rate list (with a lower maximum bit rate option) can be sent to one or more of the ninth sessions in progress to free up enough capacity to do so. During times of increasing excess capacity, the above method can be reversed to improve user QoE (i.e., enlarge the bit rate list by increasing the maximum allowable bit rate). Additionally, in systems such as LTE, where admission control is specified on a per-session basis rather than on a per-session basis, app-agent cooperative communication will be used to create finer admission control that responds with rejection and modification on a per-session basis. I can.

App-agent cooperative communication can be used during handover. Information from the app-agent cooperative communication can be used to optimize user experience quality (QoE) during handover. For example, data that is buffered in an application can be increased prior to handover to avoid buffering blanking during handover. When a handover is expected for a terminal node running a cooperative video application and the access node is aware that the video client playback buffer has additional capacity, via app-agent cooperative communication, within the access node. The scheduler parameter may be adjusted to increase the amount of video data buffered in the terminal node immediately before handover. In addition, the handover timing can be controlled so that the handover occurs during an application-friendly period, that is, during a period of time that any interruption or delay in the communication has less impact on the QoE. For example, if a handover is expected but not immediately necessary, the handover can be initiated immediately when the application indicates to the application agent that the video has been paused. Similarly, the application agent may instruct an application that is communicating delay tolerance information, such as an email application or a browser application, to postpone the request to send or receive until after the handover is complete. Handover improvements through app-agent cooperative communication can improve efficiency both for communication networks and for applications against lost or damaged retransmitted data during handover.

App-agent cooperative communication can be used to evaluate video quality. For example, an app-agent cooperative communication may communicate information from an RTP Control Protocol (RTCP) report. The RTCP report contains information that allows the evaluation of video quality. The access node can detect and extract information from the RTCP report (e.g., using a packet inspection module), while the same or similar information is passed from the application to the application agent, reducing computational resources required by the access node can do. The availability of video quality information can be used to adjust scheduler parameters and resource allocation. For example, the access node may increase the scheduler priority for a video application to improve the quality if it is insufficient, or reallocate resources to other applications if the quality is above a threshold.

App-agent cooperative communication can be used in scheduling acknowledgment. Information from the app-agent cooperative communication can be used, for example, to schedule a TCP acknowledgment (ACK) message. Improved scheduling of TCP ACK messages on the uplink can use TCP as one of its transport and connection protocols to avoid or correct conditions that may cause standstill or downlink data starvation for applications. The access node can use the information about the timing of the TCP ACK message when the access node allocates uplink bandwidth to the terminal node. More precise timing of uplink bandwidth allocation for TCP ACK messages may be possible if the cooperative application provides information about the expected occurrence of TCP ACK messages. The communication bandwidth used for bandwidth allocation can also be reduced.

Additionally, the robustness of the modulation and coding scheme can be increased when a TCP ACK message is expected. Alternatively, the cooperative application can send a TCP ACK message after a timeout even if no data has been received to prevent freezing or freezing. Timeout occurrence may be reported to the application agent for use in adjusting scheduler parameters to improve future performance, for example. The application agent may report a congestion condition to the application so that it can change its timeout threshold to send a TCP ACK message after a timeout even if no data has been received. Changing the threshold may occur, for example, when the next segment of video may be requested at a lower rate to avoid congestion in the future and there is a high likelihood of freezing for the remainder of the current video segment.

App-agent cooperative communication can be used in service differentiation. Information from the app-agent cooperative communication can be used, for example, to identify service scenarios that would have been difficult or impossible to detect. The cooperative email application may indicate to the corresponding application agent what event triggered email synchronization, for example. When email synchronization is triggered by a timeout or some other machine-generated stimulus, the access node can give a relatively low priority to scheduling the downlink data and the corresponding uplink protocol, and the email synchronization is triggered by a user action. When triggered, the access node can give a relatively high priority to scheduling the downlink data and the corresponding uplink protocol. In one embodiment, a low or high priority assignment may be established by applying a smaller or larger AF to the service in the scheduler, thereby increasing or decreasing the resources made available to the service. Thus, a higher priority is used when the user is waiting and a lower priority is used when the user is not waiting. Accordingly, the app-application cooperative communication from the terminal node to the access node may include a stimulus of a communication request, for example, information about whether a user is waiting for the requested data.

Similarly, an application may indicate whether the user is explicitly requesting to watch a video (e.g., the user has clicked on a video link) or a video accidentally embedded in a webpage (e.g., news that the user has accidentally embedded video The link to the article was selected) and can be distinguished. When the user explicitly selects the video, the QoE of the video is more important and the scheduler can adjust the scheduler parameter accordingly based on information from the app-agent cooperative communication. In contrast, when the video is secondary, the scheduler can give more priority to the text of the story. Similar considerations can be used, for example, in admission control decisions during severe congestion.

Moreover, an application that combines multiple media in a session can signal the relative importance of the media to the application agent. A video calling application may, for example, consider the audio portion of the session to be more important than the video portion. If resources are insufficient for both the voice part and the video part, the access node can use the information about the relative importance received in the app-agent cooperative communication to preserve the quality of the audio part while the video part is degraded or denied.

App-agent cooperative communication can be used to avoid reduced QoE caused by traffic grooming. The rate of traffic to and from the terminal node can be limited in a number of ways. When the traffic rate limit is exceeded, traffic grooming can be triggered with some packet dropouts or delays. Traffic grooming may take place in a communication node that is not aware of the application request of the terminal node. Thus, such communication nodes will delay or drop packets regardless of the effect on QoE. App-agent cooperative communication can be used by applications to avoid requesting excessive data that could trigger grooming. By not triggering grooming, QoE can be improved. Other capabilities for communication can be similarly signaled to the terminal node, and the terminal node can adjust its request accordingly.

An example rate limit is the aggregate maximum bit rate (AMBR) that the LTE system applies to terminal nodes (user equipment in LTE nomenclature). AMBR dominates bandwidth resources that can be allocated to a terminal node even if there are excess system resources. LTE packet gateways are usually provisioned to groom data going to a terminal node by delaying or discarding packets to ensure that the average data rate is only AMBR.

Traffic rates for terminal nodes may also be contractually limited by service level agreements (SLAs). SLA limits can be applied at various levels, for example terminal nodes, logical links, bearers or connections.

The terminal node may have limited or no knowledge of the rate limit. For example, the UE knows its AMBR, but the SLA limit may not. In general, individual applications do not know the rate limit. Moreover, the individual application will not know which other application is active or the resource demand of the other application versus the rate limit. For example, a video application may not know if a particular video resolution will cause a rate limit to be exceeded and thus trigger a delay and discard of packets for all applications on the terminal node.

In an embodiment, for example, a master application or a master application agent as shown in FIG. 6 may track an accumulated application resource request and track an accumulated resource against a rate limit. Other modules, e.g., part of the operating system of the terminal node or part of the RAN protocol stack (e.g., Radio Resource Control (RRC) or Radio Resource Management (RRM) for LTE) are accumulated for use by the application. Application resource requests can be tracked. The cooperative application may communicate with a master application, master application agent, or other module to use the rate information to determine the remaining data rate available and guide its request for data. In various embodiments, the cumulative resource request may be tracked at an access node or a terminal node. The mechanism by which the application determines resource allocation and rate limit information depends on where the information is available. For example, an application may communicate with an application agent that communicates with a module in the RAN protocol stack that tracks resource usage and rate limits for a terminal node and its active application collection.

App-agent cooperative communication can be used to analyze the performance of the communication network. Information related to performance may be collected from app-agent cooperative communication. For example, when an application communicates information about video stop, audio stop or buffer under-run, the information can be used to analyze the performance of terminal nodes, access nodes, and other areas of the communication system. The application may additionally communicate a timeline of playback, start and stop times or the number and duration of playback stops of each video or audio session. The application may communicate an estimate of the video or audio reproduction quality, for example in the form of an average score (MOS). Additionally, the application may communicate packet-level quality of service (QoS) metrics measured at the terminal node, such as packet delay and jitter. In addition, the application is subject to severe complaints about network performance, e.g., one or more browser or application refreshes, duplicate'clicks' or'touches' on the same link or command, or a period of poor network quality or poor application responsiveness. It can report user-level (human) actions that can signal user shutdown. Various information can be used to determine acceptable levels of congestion for different applications or different mixes of applications. The information can also be used by the operator to decide when to add more resources to the network.

It is clear from these examples that app-agent cooperative communication can be used for many different types of information, can be used with many different types of applications, and can be used to improve the communication network of many different aspects.

7 is a block diagram of a communication system having an application and an application agent according to an aspect of the present invention. The terminal node 755 hosts the application 751. The application 751 may communicate with the application server 790 to facilitate provision of services to users of the terminal node 755. The various elements of the communication system may be the same or similar to the similarly named elements described above.

The terminal node 755 in the communication system shown in FIG. 7 communicates with the access node 775 through a radio link 720. The access node 775 is connected to the gateway node 795. Gateway node 795 provides access to the Internet through connectivity to router node 793. Router node 793 provides access to application server 790. Thus, the application 751 can communicate with the application server 790 using the application data path 701 through the access node 775, the gateway node 795 and the router node 793. The application data path 701 carries application user data (eg, video data) and application control data (eg, information about available videos and their formats). The access node 775 acts as a bridge for communication on the application data path 701, passing it over between the terminal node 755 and the next node in the communication system.

The application 751 also communicates with the application agent 770 in the access node 775 using the app-agent cooperative communication control path 703. The app-agent cooperative communication control path 703 is transmitted through the radio link 720. Communication on the app-agent cooperative communication control path 703 between the application 751 and the application agent 770 may be used to improve scheduling, admission control, efficiency and responsiveness, for example.

8 is a block diagram of another communication system with an application and an application agent according to an aspect of the present invention. The communication system of FIG. 8 is similar to the communication system of FIG. 7, and a terminal node 855, an access node 875, a gateway node 895, and a router node corresponding to a pseudo-named device in the communication system of FIG. 7 893), and an application server 890. The terminal node 855 communicates with the access node 875 via a radio link 820. The access node 875 is connected to the gateway node 895. Gateway node 895 provides access to the Internet through connectivity to router node 893. A router node 893 provides access to an application server 890.

The application 851 in the terminal node 855 may communicate with the application server 890 using the application data path 801 through the access node 875, the gateway node 895, and the router node 893. The application 851 also communicates with the application agent 870 using the app-agent cooperative communication control path 803. In the communication system of FIG. 8, the application agent 870 resides in the gateway node 895. Information from application agent 870 may be provided to access node 875. App-agent cooperation type information, for example, may be supplied to the scheduler and resource control module in the access node 875. The access node 875 may use app-agent cooperative information to improve scheduling, admission control, efficiency and responsiveness, for example.

In other embodiments, the application agent may be located at router node 893 or at another network node. The functionality of the application agent may also be distributed across multiple devices.

Additionally, if the app-agent cooperative communication control path 803 is through an IP path, the path may be through an additional communication node. For example, cooperative communication may be routed through a router node 893. Locating an application agent outside the access node 875 may eliminate or reduce the uplink packet inspection requirement at the access node 875. Remotely located application agents can also perform functions for multiple access nodes.

9 is a block diagram of a packet inspection module according to an aspect of the present invention. The packet inspection module 429 of the access node 475 of FIG. 4 may be provided, for example, by the packet inspection module of FIG. 9. The packet inspection module, in one embodiment, is included in the terminal node 455 of FIG. 4 to detect and determine the placement of the DL App-Agent cooperative communication message. The packet inspection module may, for example, determine that the message should be ignored or that the message should be sent to either a master application or a more specific application. The packet inspection module can be used in the data path between the RAN protocol stack and another entity, such as an application server, residing in the core network or the Internet.

The uplink data can come to the packet inspection module via the first path 921 (e.g., on the radio link) and can be forwarded from the packet inspection module via the second path 922 (e.g., on the backhaul connection). have. The downlink data may come to the packet inspection module through the second path 922 and may be forwarded from the packet inspection module through the first path 921.

The packet inspection module includes a traffic monitoring module 925 capable of monitoring traffic on the first path 921 and the second path 922. The traffic monitoring module 925 identifies the app-agent cooperative communication from the application destined for the application agent. In particular, the traffic monitoring module 925 may monitor the uplink traffic on the first path 921 to identify the app-agent cooperative communication. App-agent cooperative communication can be identified using, for example, an IP address. For example, the traffic monitoring module 925 and the cooperative communication detection module 928 may detect those UL packets containing multicast or broadcast source or destination addresses assigned to the app-agent cooperative communication. Packet inspection can be used to identify agent-cooperative communications. This detection can be used with the multicast or broadcast method described above.

The packet inspection module, alternatively or additionally, is an app-through detection of one or more unique TCP/UDP source or destination port numbers not used by other traffic or explicitly assigned to app-agent cooperative communications. Agent cooperative communication can be identified. This technology can be applied to both UL and DL App-Agent cooperative communication. A single unique port number can be used to identify a single specific application and a specific application agent, a specific application group and a specific application agent group, and the source or destination of cooperative communication between various combinations.

In one embodiment, the traffic monitoring module 925 is provided by the packet inspection module 529 in the access node 575 of FIG. 5 (e.g., the transmission and access protocol module 550 in the terminal node 555). ') by detecting the use of the unique IP datagram protocol type), it is possible to detect the UL App-Agent cooperative communication. For example, the protocol type may be set to an unassigned value (eg, a number between 143 and 252). A similar method can be used to detect the DL App-Agent cooperative communication.

In various embodiments, various combinations of IP address, source port, destination port and protocol type are used to create unique connections for purposes of UL and DL App-Agent cooperative communication.

The traffic monitoring module 925 may also monitor traffic in the packet inspection module for other purposes, and the packet inspection module may include other logic modules 927 to handle other purposes. The packet inspection module may also detect information about applications associated with traffic on the first and second paths. Additional examples of packet inspection, traffic monitoring, and application-aware communication systems are U.S. Patent Application No. 13/549,106, filed July 13, 2012 (title of the invention: "Systems and Methods for Detection for Prioritizing and Scheduling Packets in a. Communication Network"), US Provisional Application No. 61/640,984 filed May 1, 2012 (invention title: “Application Aware Admission Control”) and US Patent Application No. 13/644,650 filed Oct. 4, 2012 It can be found in the issue (title of the invention: "Congestion Induced Video Scaling"), which are incorporated herein by reference.

Another logic module 927 can track the IP address, port number, and protocol type used for application data traffic. For example, in the communication network of FIG. 5, another logical module 927 may track the IP address, port number and protocol type on the application data path 501. Another logic module 927 may detect a conflict between an IP address, port number, and protocol type used for app-agent cooperative communication and an IP address, port number, and protocol type used for application data traffic. If the combination of IP address, port number and protocol type used by the App-Agent cooperative communication is the same as the combination used by the application data traffic, the other logic module 927 selects a new unused combination and this new combination Can communicate to the affected terminal node. The new combination can be selected from the list provided by the network operator.

App-agent cooperative communication traffic is converted to cooperative communication detection module 928. App-agent cooperative communication traffic may be diverted by the traffic monitoring module 925. The cooperative communication detection module 928 provides additional processing on the app-agent cooperative communication. An example of further processing is forwarding the traffic to the appropriate application agent. Further processing may also include no processing, for example, when the cooperative communication detection module 928 determines that the traffic forwarded thereto is not for the application agent associated with the packet inspection module.

The packet inspection module as illustrated in FIG. 9 may include a status module 926. The state module 926 may track information about an instance of connectivity between an application and an application agent. The information may include, for example, a status (eg, connected, disconnected, active, idle), a current resource estimate, and historical data (eg, a requested resource versus a used resource).

In another aspect, systems, methods, and devices are described for the management of cooperative specific applications, as well as other specific applications, operating on user equipment to increase the quality of experience for users of those applications. 10 is a block diagram of an exemplary communication network environment including a sensory quality manager module according to an aspect of the present invention. In FIG. 10, the communication network environment may include the Internet 1000 to which one or more content servers 1010 may be provided. Such a content server may be a third party content server that provides web pages, photos, videos, files, etc. to end users, or may be a private content server that provides such information to a limited group of end users, such as by subscription. The communication network environment is, in the example shown in FIG. 10, a PDN gateway (P-GW) 1030, a serving gateway (S-GW) 1040, a mobility management entity (MME) 1060, and one or more access nodes ( A quality of experience (QoE) manager module 1020 included in the network architecture that also includes an AN) 1050 may be further included. Each access node (AN) 1050 may communicate with one or more terminal nodes (TNs), such as TN1 (1071) and TN2 (1072), via a communication link between the access node and the terminal node, where communication The link may be a wireless communication link or a wired communication link. The wireless communication link can operate according to any one of several known wireless communication protocols such as CDMA, OFDM, LTE, and WiMAX. Similarly, the wired communication link can operate according to any one of several known wired communication methods such as Ethernet, DOCSIS, digital subscriber line (DSL), fiber to the home (FTTH), and hybrid fiber coax (HFC).

In the exemplary communication network environment shown in FIG. 10, certain applications running on TNs 1071 and 1072 are managed to maintain or increase the quality of experience for users of those applications. In an exemplary configuration, the master application (not shown in Fig. 10) operates on each of the TNs 1071 and 1072, but the master application detects the application downlink stream activity of the downlink data stream being sent to the TN and Characterize and operate to characterize the current terminal node state. The master application then determines the stream importance metric and stream quality metric for each detected downlink data stream. In the exemplary configuration of FIG. 10, the master application then transmits the stream importance metric and stream quality metric for each detected downlink data stream associated with the terminal node through the access node 1050 to the cloud-based QoE manager module. Sent to (1020). Although the QoE manager module 1020 is positioned between the P-GW 1030 and the Internet 1000 in FIG. 10, in another aspect, for example, the QoE manager module 1020 is connected to the S-GW 1040. It should be appreciated that it may be located at other locations within the communication network environment, such as between the access nodes 1050. In one aspect, the QoE manager module 1020 includes each of the terminal nodes, such as each of the TNs 1071 and 1072, in which the QoE manager module 1020 has a specific application managed by the QoE manager module 1020. It may be located at a location within a communications network environment that enables monitoring, access, copying, and/or intercepting of data stream traffic to and/or from. In this regard, according to an aspect of the present invention, the QoE manager module 1020 may manage downlink and/or uplink data streams associated with a specific managed application. Additionally, the functionality described with respect to the QoE manager module 1020 may be distributed among several devices in a communication network environment, such as, for example, entirely within the P-GW 1030 or P-GW 1030, S It may be distributed among any of the GW 1040, the access node 1050, and/or other devices and modules.

The QoE manager module 1020 receives, through the access node 1050, a stream importance metric and a stream quality metric for each detected downlink data stream associated with each terminal node. In this way, the QoE manager module 1020 collects this information from all terminal nodes, and maps each of the terminal nodes to a cell associated with each access node. In one aspect, the QoE manager module 1020 uses this collected information to determine a comprehensive cell quality metric for each cell, and if the comprehensive cell quality metric is below a threshold, the QoE manager module 1020 Based on the stream importance metric and the stream quality metric for each data stream, mitigation options for one or more data streams associated with one or more of the terminal nodes are determined. The mitigation option may be one of many options, such as reducing or stopping data packets being sent in the data stream, for example, or it may be to continue monitoring the state without taking any current action on any of the data streams. In some aspects, the mitigation option is either in the QoE manager module 1020 (e.g., traffic grooming, packet dropping and/or delay) or at the terminal node associated with the data stream to which the mitigation option is applied (e.g., packet dropping). And/or delay), or in both the QoE manager module 1020 and the terminal node. In this way, for example, the QoE manager module 1020 may attempt to maintain or increase the quality of experience for a user of a specific application associated with a terminal node associated with a given access node (eg, RAN cell). In aspects, for example, the QoE manager module 1020 may provide a detected data stream for or associated with a specific terminal node for a detected data stream across all terminal nodes associated with a given access node (e.g., a RAN cell). You can try to optimize the quality of experience.

11 is a block diagram of an exemplary communication network environment including a sensory quality manager module according to another aspect of the present invention. As mentioned above, the QoE manager module 1020 shown in FIG. 10 may be located at another location within a communication network environment. Referring to FIG. 11, the QoE manager module 1120 may be provided to the Internet 1100 in which, for example, one or more content servers 1110 may also be located. Other network nodes, such as a PDN gateway (P-GW) 1130, a serving gateway (S-GW) 1140, a mobility management entity (MME) 1160, and one or more access nodes (AN) 1150, are connected to the Internet ( 1100) and is provided to the mobile infrastructure 1190 in communication. Each access node (AN) 1150 may communicate with one or more terminal nodes (TNs) such as TN1 1171 and TN2 1172 through a communication link between the access node and the terminal node, where the communication link May be a wireless communication link or a wired communication link as described above with respect to FIG. 10. The QoE manager module 1120 of FIG. 11 may operate in a manner similar to that described above with respect to FIG. 10, but the P-GW 1130, S-GW 1140, MME 1160 and access node(s) It is not part of the mobile infrastructure, including (1150).

As mentioned above, the master application module can operate in each terminal node in the communication environment. In one aspect, the master application module may be located in a terminal node between a specific application and a TCP/IP stack, and may be used to monitor and manage application data streams related to a specific application. In one aspect, the master application module may be located in a separate layer between a particular application and the operating system, or may be implemented as part of the operating system.

The application data stream may be a flow of communication data in/out of the terminal node supporting a specific application running in the terminal node. For example, the application data stream may be a flow of video data packets from the content server to the terminal node through the access node, and the application data stream supports video applications running in the terminal node. In aspects, more than one application data stream may be associated with a single instance of a particular application running on a terminal node. The specific application operating in the terminal node may be a cooperative specific application that communicates and coordinates with the master application module, or may be a non-cooperated specific application that does not communicate or coordinate with the master application module. In an exemplary aspect, the master application module in the terminal node can monitor and/or access TCP packets at any point between the TCP and HTTP stack, where the TCP packets support a specific application running on the terminal node. It is a data packet. The master application module in the terminal node may also interface with a specific cooperative application operating in the application layer of the terminal node, thereby obtaining information from the specific application and/or sending commands and/or data to the specific application. In this regard, some or all of the functions of the master application module described herein may be located in some or all of the cooperative specific applications operating in the terminal node as an option.

12 is a block diagram of a master application module in a terminal node supporting haptic quality management according to an aspect of the present invention. In Fig. 12, an exemplary embodiment of a master application module 1200 includes several modules in communication with each other to share data, information and/or commands and commands. In one aspect, the exemplary embodiment of the master application module 1200 is, but is not limited to, a terminal node (TN) interface module 1210, a characteristic evaluation module 1220, a stream metric determination module 1230, and other There are several modules including a logic 1240, a stream detection and classification module 1250, a QoE manager communication module 1260, a QoE response module 1270, and a traffic interface module 1280.

In an exemplary aspect, the terminal node interface module 1210 is used to communicate with a specific cooperative application running on the terminal node and to calculate the data stream quality for each detected data stream associated with the specific application. It interfaces with the application layer of the terminal node to determine application characteristics and metrics. In addition, the terminal node interface module 1210 obtains quality of service (QoS) and cell ID (ID) information (eg, QCI and Cell_ID) for the detected application data stream stream, for example, in an LTE-based system. It can interface with a network interface of a terminal node, such as an LTE Uu stack. For example, such information may be obtained for each detected application data stream or for each group of detected streams. In this regard, performing these functions may not necessarily apply to each data stream, but instead may apply to each of a subset (some or all) of the data streams. The terminal node interface module 1210 may also interface with other terminal node services to obtain terminal node characteristics and other application characteristics, for example, to determine from the operating system which specific application is in the foreground of the display, for example. In one aspect, the terminal node interface module 1210 may also be used to implement mitigation actions, as discussed in more detail below.

In an exemplary aspect, the stream detection and classification module 1250 receives data packets from the terminal node interface module 1210 and examines them to determine whether they belong to a data stream associated with a specific application running on the terminal node. Function to do it. For example, the stream detection and classification module 1250 may include initiation and termination of a data connection, such as establishment of a TCP/IP connection, and data such as data traffic flowing across a newly established connection, for example. Data packets can be inspected to detect the stream. In one aspect, the stream detection and classification module 1250 associates one or more of the identified data streams to a corresponding specific application operating at the terminal node. For example, the stream detection and classification module 1250 may associate three identified HTTP data streams each carried on a unique TCP/IP connection with a single specific application running in the terminal node. Based on the data packet inspection, the stream detection and classification module 1250 may classify one or more of the identified data streams into an application class and/or a specific application. For example, the stream detection and classification module 1250 may classify the data stream into a video class because the data packet of the data stream carries video data, and the stream detection and classification module 1250 classifies the data stream, Based on the specific characteristics of the data stream, it can be further classified as a specific application, for example Netflix. Those of skill in the art will be aware of existing methods and techniques for classifying data streams and, in particular, determining such classification based on inspection of one or more data packets within the data stream.

In one aspect, the stream detection and classification module 1250 may perform the functions described above by using application signaling from a cooperative specific application operating in the terminal node. For example, a specific cooperative application running on the terminal node may send an indication to the stream detection and classification module 1250 that the specific cooperative application is starting a new data stream, and the indication is also, for example, , An application class associated with the new data stream, and information related to the new data stream, such as a specific application. In one aspect, the stream detection and classification module 1250 may use data packet inspection to determine connection information, such as socket information, associated with a new data stream.

The stream detection and classification module 1250 may use known data packet inspection and classification techniques. In one aspect, the stream detection and classification module 1250 is in US Patent Application Publication No. 2012/0327779A1 (name of the invention: "Systems And Methods For Congestion Detection For Use In Prioritizing And Scheduling Packets In A Communication Network"). The described data packet inspection and classification techniques can be used, which are incorporated herein by reference. For example, in US Patent Application Publication No. 2012/0327779A1, among other things, in FIGS. 4A to 4C and at least paragraphs [0056], [0057], [0060], [0061] and [0077] to [0091]. The inspection and classification techniques described for the classification/queueing module described in] can be implemented in the aspects and embodiments described herein. In one aspect, the stream detection and classification module 1250 also transfers data stream information and/or metrics, such as HTTP, TCP and/or IP header information and file metadata, to the property evaluation module 1220, Alternatively, for example, a byte counter and packet arrival information that can be used to compute a service provided bit rate may be provided to the stream metric determination module 1230.

In one aspect, the feature evaluation module 1220 may determine a current set of application features for each particular application associated with one or more detected data streams. For example, the current application characteristic data set may include an initiation type indicating whether the associated specific application was launched by a user of the terminal node on which the specific application is running, or whether the associated specific application was launched by the terminal node itself without user initiation. have. The current application characteristic data set may also include an indication of whether the specific application associated with it is in the foreground or background of the display of the currently associated terminal node, and also whether the response that the particular application is waiting for is from another entity, such as a content server. Alternatively, it may include recognition from the user of the terminal node. In one aspect, the characteristic evaluation module 1220 can access the operating system of the associated terminal node to obtain information that can determine some or all of the current application characteristic data set for a particular application. In a further aspect, the characteristic evaluation module 1220 receives data stream information and/or metrics from the stream detection and classification module 1250 and determines some or all of the current application characteristic data sets for a particular application. Information and/or metrics may be used. In one aspect, the characteristic evaluation module 1220 receives application information indirectly or directly from a cooperative specific application running on the terminal node, and thereafter, some or all of the current application characteristic data sets for that specific application. You can use this information in your decisions.

In one aspect, the current application characteristic data set determined by the characteristic evaluation module 1220 may include one or more of the following:

-Application class metrics:

예시값: 대화형 음성, 대화형 비디오, 스트리밍 오디오, 스트리밍 빕디오, 양방향성 게이밍, 브라우저 데이터, 네이티브 애플리케이션 데이터, 및 모름

Examples: Interactive Voice, Interactive Video, Streaming Audio, Streaming Vidio, Interactive Gaming, Browser Data, Native Application Data, and Unknown

결정: 대역-내 패킷 검사 기술(위에서 설명함)이 트래픽 인터페이스 모듈(1280)을 통하여 모니터링된 데이터 패킷에 적용될 수 있다

Decision: In-band packet inspection technique (described above) can be applied to data packets monitored through the traffic interface module 1280

-Stream initiation metric:

예시값: 사용자에 의한 개시 및 머신에 의한 개시

Example values: user initiated and machine initiated

결정: 스트림 개시 유형의 메트릭은 연관된 협력형 특정 애플리케이션으로부터 수신될 수 있다. 다른 일 태양에 있어서, 이것은 데이터 스트림과 연관된 결정된 애플리케이션 클래스로부터 추론될 수 있다(예를 들어, 단일 스트리밍 비디오 스트림을 갖는 특정 애플리케이션은 사용자에 의해 개시된다고 상정될 수 있다). 데이터 스트림의 개시는 대응하는 특정 애플리케이션의 개시와 똑같을 수도 있고 그렇지 않을 수도 있음을 유념해야 한다. 예를 들어, 사용자-개시된 특정 애플리케이션은 사용자에 의해 개시되는 푸시-업데이트를 가질 수도 있고 또한 머신에 의해 개시되는 용례 보고를 가질 수도 있다(특정 애플리케이션의 개시와는 별개임).

Decision: The metric of the stream initiation type can be received from the associated cooperative specific application. In another aspect, this can be inferred from the determined application class associated with the data stream (eg, a particular application with a single streaming video stream can be assumed to be initiated by the user). It should be noted that the initiation of the data stream may or may not be the same as the initiation of the corresponding specific application. For example, a particular user-initiated application may have push-updates initiated by the user and may also have usage reports initiated by the machine (separate from the initiation of the particular application).

-User Interface (UI) Update Pending Metrics:

예시값: 계류중, 계류중 아님, 적용불가

Example values: pending, not pending, not applicable

결정: 이것은 데이터 스트림이 현재, 스크린 리프레시와 같은, 계류중 UI 업데이트와 연관되어 있는지 여부를 가리킨다. UI 업데이트 계류중의 표시는, 예를 들어 인터넷 브라우저 또는 네이티브 애플리케이션과 같은, 연관된 협력형 특정 애플리케이션으로부터 수신될 수 있다. 이것은 또한 애플리케이션 데이터 스트림 내 데이터 패킷으로부터 파싱될 수 있다. 이러한 표시는, 예를 들어 대화형 음성과 같이, 모든 애플리케이션 클래스에 적용가능한 것은 아닐 수 있음을 유념한다.

Decision: This indicates whether the data stream is currently associated with a pending UI update, such as a screen refresh. The indication of a UI update pending may be received from an associated cooperative specific application, such as an internet browser or a native application, for example. It can also be parsed from data packets in the application data stream. Note that this indication may not be applicable to all application classes, for example interactive speech.

-Display position metrics:

예시값: 전경, 배경

Example values: Foreground, Background

결정: 이러한 메트릭은 애플리케이션 데이터 스트림과 연관된 특정 애플리케이션이 단말 노드 상에서 UI 배경에서 디스플레이되고 있는지 또는 전경에서 디스플레이되고 있는지를 가리킨다. 디스플레이 위치는 연관된 협력형 특정 애플리케이션으로부터 수신될 수 있다. 또한, 디스플레이 위치 표시는 단말 노드 내 운영 체제로부터 획득될 수 있다.

Decision: This metric indicates whether a particular application associated with the application data stream is being displayed on the terminal node in the UI background or in the foreground. The display location can be received from an associated cooperative specific application. In addition, the display position indication may be obtained from an operating system in the terminal node.

-Network quality of service (QoS) metrics:

예시값: QCI = 1-9

Example value: QCI = 1-9

결정: 이러한 메트릭은, 단말 노드 인터페이스 모듈(1210)을 통하여, 단말 노드 내 네트워크 스택(예를 들어, LTE Uu 스택)으로부터 획득될 수 있다. 국한되는 것은 아니지만, 보증 비트 레이트(GBR) 클래스 또는 비-보증 비트 레이트(비-GBR) 클래스와 같이 QoS에 대한 대안이 사용될 수 있다.

Decision: This metric may be obtained from a network stack (eg, an LTE Uu stack) within a terminal node through the terminal node interface module 1210. Although not limited, alternatives to QoS may be used, such as guaranteed bit rate (GBR) classes or non-guaranteed bit rate (non-GBR) classes.

-Buffer margin metric:

예시값: 0 = 모름, 1-15값(8 = 중립)

Example values: 0 = unknown, values 1-15 (8 = neutral)

결정: 버퍼 마진 메트릭은 데이터 스트리밍 서비스에 대한 버퍼 점유율(BO) 마진을 가리킨다. 이러한 메트릭은 연관된 협력형 특정 애플리케이션으로부터 획득될 수 있다. 비디오 스트리밍의 경우에, 메트릭은 BO 추정을 사용함으로써 결정될 수 있다. 예를 들어, BO 추정은 미국 특허 출원 제13/789,462호(발명의 명칭: "Systems And Methods For Using Client-Side Video Buffer Occupancy For Enhanced Quality Of Experience In A Communication Network")에 설명된 방법 및 기술을 사용함으로써 획득될 수 있으며, 그것은 참조에 의해 여기에 편입되는 것이다. 스트리밍 오디오 BO 추정은 유사한 기술을 통하여 획득될 수 있다.

Decision: The buffer margin metric refers to the buffer occupancy (BO) margin for the data streaming service. These metrics can be obtained from associated cooperative specific applications. In the case of video streaming, the metric can be determined by using the BO estimation. For example, BO estimation is based on the methods and techniques described in U.S. Patent Application No. 13/789,462 (title of the invention: "Systems And Methods For Using Client-Side Video Buffer Occupancy For Enhanced Quality Of Experience In A Communication Network"). It can be obtained by use, which is incorporated herein by reference. Streaming audio BO estimation can be obtained through a similar technique.

In an exemplary aspect, the characteristic evaluation module 1220 may also determine a set of terminal node characteristic data for the terminal node, which may include current characteristic data related to the state of the terminal node. The terminal node characteristic data set is not limited to, but is not limited to, a user SLA indicating the level of attention the user is giving to the associated terminal node, a service level agreement (SLA) assigned to the user of the terminal node, and the type of terminal node being used. Terminal node type metrics (eg, tablets, smartphones, feature phones, large display TVs, industrial M2M modules, etc.) may be included. In one aspect, the characteristic evaluation module 1220 may access the operating system of the associated terminal node to obtain information by which it can determine some or all of the current terminal node characteristic data. For example, the characteristic evaluation module 1220 acquires historical data from the operating system related to the type of the received user input and the time of the received user input by the graphic user interface of the terminal node associated with a specific application. And then use this information to determine the user attention metric associated with a particular application. Other information from the operating system may also include, for example, an indication of the phone position or movement, an indication of whether the display of the terminal node is off or timed out, an indication of the user's eye tracking of the display from a camera or other sensor in the terminal node. It may help to determine the user attention metric including. It should be appreciated that other known types of data and information from the operating system and/or from the terminal node may be used to determine some or all of the current terminal node characteristic data sets.

In one aspect, the current terminal node characteristic data set determined by the characteristic evaluation module 1220 may include one or more of the following:

-User Attention (UA) metrics:

예시값: 주의, 방치, 적용불가, 모름

Example values: caution, neglect, not applicable, unknown

결정: 일 태양에 있어서, UA 메트릭에 대한 적용불가값은, 비디오 모니터링 또는 다른 머신-대-머신(M2M) 애플리케이션과 같이, 무인 특정 애플리케이션에 대하여 사용될 수 있음을 유념한다. 부가적으로, UA 메트릭은 또한 대형 스크린 스마트폰 및 태블릿과 같이 다수의 특정 애플리케이션으로부터의 정보를 동시에 디스플레이할 수 있는 그들 단말 노드 디바이스에 대한, 단말 노드 특성이라기보다는, 애플리케이션 특성일 수 있다.

Decision: Note that in one aspect, the non-applicable value for the UA metric may be used for unmanned specific applications, such as video monitoring or other machine-to-machine (M2M) applications. Additionally, the UA metric may also be an application characteristic, rather than a terminal node characteristic, for those terminal node devices capable of simultaneously displaying information from multiple specific applications, such as large screen smartphones and tablets.

위에서 논의된 바와 같이, 사용자 주의와 관련된 정보는 단말 노드의 운영 체제로부터 그리고/또는 가속도계, 카메라 등과 같은 단말 노드 내 다양한 유형의 센서로부터 획득될 수 있다. 예를 들어, 사용자가 존재하고 주의를 기울이고 있는지 평가하도록 그리고 단말 노드의 디스플레이 상의 주의의 대상을 나타내도록 전방 대향 카메라를 통하여 시선 추적(눈 추적) 정보가 획득될 수 있다. 예를 들어, 2010년 ACM 출판, 페이지 15-20, 휴대용 모바일(MobiHeld 10)에 대한 네트워킹, 시스템 및 애플리케이션에 관한 ACM SIGCOMM 워크샵 제2 절차, E.Miluzzo, T.Wang 및 A.Campbell의 "Eyephone: Activating Mobile Phones with Your Eyes"를 참조하라. 가속도계 데이터는, 단말 노드가 위로 향하고 있는지 거꾸로 있는지와 같은, 단말 노드의 오리엔테이션을 결정하도록 사용될 수 있다. 예를 들어, http://stackoverflow.com/questions/7590996/detecting-the-device-upside-down를 참조하라. 주머니-안에 있음 또는 가방-안에 있음 검출은 단말 노드 내 센서로부터의 정보에 기반하여 결정될 수 있다. 예를 들어, http://www.cs.dartmouth.edu/~campbell/papers/miluzzo-phonesense.pdf를 참조하라. 유사하게, 손-안에-폰 있음 검출은 또한 단말 노드 내 센서로부터의 정보에 기반하여 결정될 수 있다. 예를 들어, http://www.cs.dartmouth.edu/~campbell/papers/miluzzo-phonesense.pdf를 참조하라. "마지막 사용자 상호작용" 타이머는 동작하고 있는 양방향성 애플리케이션이 '케케묵었는지'(사용자에 의해 방치되었는지) 결정하도록 연관된 특정 애플리케이션으로부터 직접 또는 운영 체제로부터 정보에 기반하여 이용될 수 있다. 스크린 세이버 모드 또는 스크린-오프 모드 정보는 단말 노드의 방치된 상태를 나타내도록 단말 노드 내 OS로부터 획득될 수 있다.

As discussed above, information related to user attention may be obtained from the operating system of the terminal node and/or from various types of sensors in the terminal node such as accelerometers, cameras, and the like. For example, gaze tracking (eye tracking) information may be obtained through the front facing camera to evaluate whether a user is present and paying attention and to indicate an object of attention on the display of the terminal node. For example, 2010 ACM Publications, pages 15-20, ACM SIGCOMM Workshop Second Procedure on Networking, Systems and Applications for Portable Mobile (MobiHeld 10), "Eyephone" by E.Miluzzo, T.Wang and A.Campbell. : See "Activating Mobile Phones with Your Eyes". The accelerometer data can be used to determine the orientation of the terminal node, such as whether the terminal node is facing up or upside down. See, for example, http://stackoverflow.com/questions/7590996/detecting-the-device-upside-down. The in-bag or in-bag detection may be determined based on information from sensors in the terminal node. See, for example, http://www.cs.dartmouth.edu/~campbell/papers/miluzzo-phonesense.pdf. Similarly, the hand-in-phone presence detection can also be determined based on information from sensors in the terminal node. See, for example, http://www.cs.dartmouth.edu/~campbell/papers/miluzzo-phonesense.pdf. The “last user interaction” timer may be used based on information from the operating system or directly from the specific application associated to determine whether the running interactive application is'obsolete' (neglected by the user). The screen saver mode or screen-off mode information may be obtained from the OS in the terminal node to indicate the neglected state of the terminal node.

위의 설명된 방법 및 기술 중 하나 이상이 UA값을 결정하도록, 예를 들어, 논리 조합과 같은 조합으로 사용될 수 있음을 유념해야 한다. 부가적으로, 논리 조합은 또한 UA 메트릭값을 더 정제하도록 각각의 방법에 의해 보고된 신뢰값(또는 간격)을 이용할 수 있다.

It should be noted that one or more of the methods and techniques described above may be used in combinations, for example logical combinations, to determine the UA value. Additionally, the logical combination can also use the confidence values (or intervals) reported by each method to further refine the UA metric values.

-Network Service Level Agreement (SLA) metrics:

예시값: 골드, 실버, 브론즈

Example values: gold, silver, bronze

결정: 이 단말 노드에 배정된 SLA는, 예를 들어, LTE 네트워크 내 LTE Uu 스택으로부터와 같이, 네트워크 스택으로부터 요청될 수 있다. 예를 들어, SLA는, 네트워크의 오퍼레이터에 의해 단말 노드/사용자에 배정되는, 단말 노드에 대한 배정된 서비스 레벨일 수 있다.

Decision: The SLA assigned to this terminal node may be requested from the network stack, for example from the LTE Uu stack in the LTE network. For example, the SLA may be an assigned service level for the terminal node, which is assigned to the terminal node/user by the operator of the network.

In an exemplary aspect, the stream metric determination module 1230 uses the current terminal node characteristic data set and the current application characteristic data set, and other information obtained from the characteristic evaluation module 1220, to perform at least one associated with each data stream. Determine the metric. In one aspect, the stream metric determination module 1230 determines a data stream metric including at least a data stream importance metric and a data stream quality metric associated with each detected data stream. In an exemplary aspect, the stream metric determination module 1230 determines a data stream importance metric for a corresponding data stream according to the following.

Here, f{} may be a weighted sum of the current terminal node characteristic data and the current application characteristic data.

Where x = appID, y = streamID, z = terminalnodeID, and c ₁ ..c ₈ are weighting factors used to increase/decrease the relative importance of each associated feature, and the use of zero weight to eliminate the effect of the associated feature. Includes. The application characteristics and the terminal node characteristics are functions of x, y, and z, respectively, although not shown above for ease of display. Those of skill in the art will appreciate that the variables described in the functions listed above may be expressed as numbers for use in calculations. The functions listed above are exemplary and may be expressed in different formats and terms, and may include other additional parameters and/or variables, or fewer parameters and/or variables. In one aspect, the stream metric determination module 1230 may determine a data stream importance metric for the data stream based at least in part on the delay tolerance of the data stream. In one aspect, such delay tolerance may be indicated by, or derived from, the application class of the data stream.

In an exemplary aspect, the stream metric determination module 1230 determines a data stream quality metric for a corresponding data stream as a normalized real-time estimate of user experience associated with a particular application corresponding to the data stream. In this regard, known methods and techniques for determining user experience metrics, such as the examples given below and VMOS estimation, may be used together with other known techniques. See, for example, Spirent Communications 2013 "OTT vs OTT: Comparing Video Chat Experience", incorporated herein by reference. In one aspect, the stream metric determination module 1230 may determine data stream quality metrics differently for different data streams depending on the application class associated with each data stream and, optionally, the specific application. In one aspect, the stream metric determination module 1230 may determine a data stream quality metric for the data stream using calculations based on data transmission quality information related to the data stream, such as data packet delay, discard, retransmission, and the like. In another aspect, the stream metric determination module 1230 is a data stream quality metric for the data stream based on metrics received from a cooperative specific application, such as a video average score (VMOS) estimate from a cooperative video streaming application. Can be determined. In another aspect, the stream metric determination module 1230 may determine a data stream quality metric for the data stream based on a combination of metric(s) received from a corresponding cooperative specific application. For example, a cooperative video application may provide a target video bitrate, and then the stream metric determination module 1230 compares this target video bitrate to an actual (or estimated) serviced bitrate value to determine the associated data. A data stream quality metric for the stream can be determined. In another aspect, the stream metric determination module 1230, as described above with respect to FIGS. 1-9, from another node in the network, including information provided by, for example, an application agent in the access node. By including the obtained metric information, a data stream quality metric for the data stream can be determined.

As mentioned above, the stream metric determination module 1230 may determine the data stream quality metric differently for different data streams depending on the application class. For different application classes, examples of information that can be used, and different quality metric determination techniques are provided below:

-Application class: interactive voice

품질 측정 기술(들): 스트림 메트릭 결정 모듈(1230)은 패킷 지터값, TCP 재송신 백분율값, 패킷 라운드 트립 시간값, 및 서비스 제공되는 비트레이트 대 목표 비트레이트 메트릭(시간 기간에 걸친 평균) 중 하나 이상을 획득 및 사용할 수 있다. 예를 들어, 이러한 정보는 스트림 검출 및 분류 모듈(1250) 및 트래픽 인터페이스 모듈(1280)의 도움으로 획득 및/또는 유도될 수 있다.

Quality measurement technology(s): The stream metric determination module 1230 is one of a packet jitter value, a TCP retransmission percentage value, a packet round trip time value, and a service provided bitrate versus target bitrate metric (average over time period). You can acquire and use the above. For example, such information may be obtained and/or derived with the aid of the stream detection and classification module 1250 and the traffic interface module 1280.

협력형 특정 애플리케이션으로부터 획득된 메트릭: 평균평가점(MOS) 추정치, 분실 데이터의 시간 백분율값, 및 애플리케이션 동결의 시간 백분율, 발생 수 및/또는 듀레이션값(즉, 대화형 음성이 누락되거나 왜곡되는 시간 기간), 및 목표 비트레이트.

Metrics obtained from cooperative specific applications: Mean Score (MOS) estimate, time percentage value of lost data, and time percentage of application freeze, number of occurrences and/or duration values (i.e., time at which interactive speech is missing or distorted Period), and target bit rate.

주의: 위에서 언급된 패킷 지터값 사용은 고정-주기 패킷 송신의 사용을 상정한다. 또한, 스트림 검출 및 분류 모듈(1250)로부터 획득된 패킷 레벨 정보(예를 들어, IP, UDP, TCP, HTTP, SIP)에 기반하여 대화형 음성에 대한 MOS 추정치를 컴퓨팅하도록 기지의 기술이 사용될 수 있다.

Note: The use of packet jitter values mentioned above assumes the use of fixed-period packet transmission. In addition, known techniques can be used to compute MOS estimates for interactive voice based on packet level information (e.g., IP, UDP, TCP, HTTP, SIP) obtained from the stream detection and classification module 1250. have.

-Application class: Interactive video (can contain interactive voice)

품질 측정 기술(들): 스트림 메트릭 결정 모듈(1230)은 패킷 지터값, 패킷 재송신 백분율값, 패킷 라운드 트립 시간값, 및 서비스 제공되는 비트레이트 대 목표 비트레이트 메트릭(시간 기간에 걸친 평균) 중 하나 이상을 획득 및 사용할 수 있다. 예를 들어, 이러한 정보는 스트림 검출 및 분류 모듈(1250) 및 트래픽 인터페이스 모듈(1280)의 도움으로 획득 및/또는 유도될 수 있다.

Quality measurement technology(s): The stream metric determination module 1230 is one of a packet jitter value, a packet retransmission percentage value, a packet round trip time value, and a service provided bitrate versus target bitrate metric (average over time period). You can acquire and use the above. For example, such information may be obtained and/or derived with the aid of the stream detection and classification module 1250 and the traffic interface module 1280.

협력형 특정 애플리케이션으로부터 획득된 메트릭: 비디오 평균평가점(VMOS) 추정치, 분실 데이터의 수량 또는 시간 백분율값, 및 애플리케이션 동결의 듀레이션 또는 발생의 수량 또는 시간 백분율값(즉, 음성 및/또는 비디오가 동결되거나, 누락되거나, 왜곡되는 시간 기간), 및 목표 비트레이트.

Metrics obtained from collaborative specific applications: Video Average Point (VMOS) estimate, quantity or time percentage value of lost data, and duration or time percentage value of duration or occurrence of application freeze (i.e., voice and/or video freezes. , Missing, or distorted time period), and the target bit rate.

주의: 이 애플리케이션 클래스의 오디오 부분은 별개의 데이터 스트림 상에서 반송될 수도 있고 그렇지 않을 수도 있다.

Note: The audio portion of this application class may or may not be carried on a separate data stream.

-Application Class: Streaming Audio

품질 측정 기술(들): 스트림 메트릭 결정 모듈(1230)은 서비스 제공되는 비트레이트 대 목표 비트레이트값, 및 BO 추정값 중 하나 이상을 획득 및 사용할 수 있다. 예를 들어, 이러한 정보는 스트림 검출 및 분류 모듈(1250) 및 트래픽 인터페이스 모듈(1280)의 도움으로 획득 및/또는 유도될 수 있다. BO 추정값은 스트리밍 비디오 클래스에 대하여 위에서 언급된 것들과 유사한 BO 추정 방법에 의해 결정될 수 있다. 일 태양에 있어서, BO 추정은 현재 시간과 상영 타임스탬프 간 상대적 비교에 기반할 수 있다.

Quality measurement technique(s): The stream metric determination module 1230 may obtain and use one or more of a serviced bit rate versus a target bit rate value, and a BO estimate value. For example, such information may be obtained and/or derived with the aid of the stream detection and classification module 1250 and the traffic interface module 1280. The BO estimate can be determined by a BO estimation method similar to those mentioned above for the streaming video class. In one aspect, the BO estimation may be based on a relative comparison between the current time and the show timestamp.

협력형 특정 애플리케이션으로부터 획득된 메트릭: 평균평가점(MOS) 추정치, 분실 데이터의 시간 백분율값, 및 애플리케이션 동결의 듀레이션 또는 발생의 수량 또는 시간 백분율값, 및 목표 비트레이트.

Metrics obtained from cooperative specific applications: average rating point (MOS) estimate, time percentage value of lost data, and duration of application freezing or quantity or time percentage value of occurrence, and target bit rate.

-Application Class: Streaming Video

품질 측정 기술(들): 스트림 메트릭 결정 모듈(1230)은, 예를 들어 참조에 의해 여기에 편입되어 있는 ITU Standard J.247 "Objective perceptual multimedia video quality measurement in the presence of a full reference"(이하 "사이테크닉스 모델"이라고 함)에 설명된 품질 메트릭 방법 및 기술과 같은, 대역-내 비디오 품질 메트릭 결정 방법들 중 하나 이상을 획득 및 사용할 수 있다. 다른 일 태양에 있어서, 대역-내 비디오 품질 메트릭 결정 방법은 위에서 논의된 바와 같은 BO 추정 기술에 기반할 수 있다. 품질 메트릭은 또한 스트리밍 비디오 상영의 오디오 스트림에 대해 결정될 수 있다.

Quality measurement technology(s): The stream metric determination module 1230 is, for example, ITU Standard J.247 "Objective perceptual multimedia video quality measurement in the presence of a full reference" (hereinafter referred to as " One or more of the in-band video quality metric determination methods, such as the quality metric method and technique described in "Scitechnics Model") can be obtained and used. In another aspect, the method of determining the in-band video quality metric may be based on a BO estimation technique as discussed above. The quality metric can also be determined for the audio stream of a streaming video presentation.

협력형 특정 애플리케이션으로부터 획득된 메트릭: 비디오 평균평가점(VMOS) 추정치, 분실 데이터의 시간 백분율값, 및 애플리케이션 동결의 듀레이션 또는 발생의 수량 또는 시간 백분율값, 및 목표 비트레이트. 부가적으로, 협력형 특정 애플리케이션은 스트리밍 비디오 상영과 연관되어 있는 오디오 스트림에 대한 품질 메트릭을 제공할 수 있다.

Metrics obtained from collaborative specific applications: Video Average Point (VMOS) estimates, time percentage values of lost data, and quantity or time percentage values of duration or occurrences of application freezes, and target bit rates. Additionally, cooperative specific applications may provide quality metrics for audio streams associated with streaming video presentations.

-Application Class: Interactive Gaming

품질 측정 기술(들): 스트림 메트릭 결정 모듈(1230)은 패킷 재송신 백분율값, 패킷 라운드-트립-시간값(예를 들어, SRTT), 및 HTTP 요청과 제1 HTTP 응답 간 시간값 중 하나 이상을 획득 및 사용할 수 있다. 예를 들어, 이러한 정보는 스트림 검출 및 분류 모듈(1250) 및 트래픽 인터페이스 모듈(1280)의 도움으로 획득 및/또는 유도될 수 있다.

Quality measurement technology(s): The stream metric determination module 1230 determines one or more of a packet retransmission percentage value, a packet round-trip-time value (eg, SRTT), and a time value between the HTTP request and the first HTTP response. Can be obtained and used. For example, such information may be obtained and/or derived with the aid of the stream detection and classification module 1250 and the traffic interface module 1280.

협력형 특정 애플리케이션으로부터 획득된 메트릭: 라운드-트립 커맨드-응답 레이턴시값.

Metrics obtained from cooperative specific applications: round-trip command-response latency values.

-Application class: browser data

품질 측정 기술(들): 스트림 메트릭 결정 모듈(1230)은 HTTP 요청과 제1 HTTP 응답 간 시간값, 및 서비스 제공되는 평균 비트 레이트값 중 하나 이상을 획득 및 사용할 수 있다. 예를 들어, 이러한 정보는 스트림 검출 및 분류 모듈(1250) 및 트래픽 인터페이스 모듈(1280)의 도움으로 획득 및/또는 유도될 수 있다.

Quality measurement technology(s): The stream metric determination module 1230 may acquire and use one or more of a time value between an HTTP request and a first HTTP response, and an average bit rate value provided with a service. For example, such information may be obtained and/or derived with the aid of the stream detection and classification module 1250 and the traffic interface module 1280.

협력형 특정 애플리케이션으로부터 획득된 메트릭: 요청 사이즈에 의해 정규화(예를 들어, MB당 초)될 수 있는 사용자(또는 머신) 요청과 스크린 리프레시 간 시간값.

Metrics obtained from cooperative specific applications: The time value between a user (or machine) request and a screen refresh that can be normalized (eg, seconds per MB) by request size.

-Application class: native application data

품질 측정 기술(들): 스트림 메트릭 결정 모듈(1230)은 HTTP 요청과 제1 HTTP 응답 간 시간값, 및 서비스 제공되는 평균 비트 레이트값 중 하나 이상을 획득 및 사용할 수 있다. 예를 들어, 이러한 정보는 스트림 검출 및 분류 모듈(1250) 및 트래픽 인터페이스 모듈(1280)의 도움으로 획득 및/또는 유도될 수 있다.

Quality measurement technology(s): The stream metric determination module 1230 may acquire and use one or more of a time value between an HTTP request and a first HTTP response, and an average bit rate value provided with a service. For example, such information may be obtained and/or derived with the aid of the stream detection and classification module 1250 and the traffic interface module 1280.

협력형 특정 애플리케이션으로부터 획득된 메트릭: 요청 사이즈에 의해 정규화(예를 들어, MB당 초)될 수 있는 사용자(또는 머신) 요청과 스크린 리프레시 간 시간값.

Metrics obtained from cooperative specific applications: The time value between a user (or machine) request and a screen refresh that can be normalized (eg, seconds per MB) by request size.

-Application Class: Unknown

품질 측정 기술(들): 스트림 메트릭 결정 모듈(1230)은 HTTP 요청과 제1 HTTP 응답 간 시간값, 및 서비스 제공되는 평균 비트 레이트값 중 하나 이상을 획득 및 사용할 수 있다. 예를 들어, 이러한 정보는 스트림 검출 및 분류 모듈(1250) 및 트래픽 인터페이스 모듈(1280)의 도움으로 획득 및/또는 유도될 수 있다.

Quality measurement technology(s): The stream metric determination module 1230 may acquire and use one or more of a time value between an HTTP request and a first HTTP response, and an average bit rate value provided with a service. For example, such information may be obtained and/or derived with the aid of the stream detection and classification module 1250 and the traffic interface module 1280.

협력형 특정 애플리케이션으로부터 획득된 메트릭: 모름 클래스에는 적용가능하지 않음

Metrics obtained from cooperative specific applications: not applicable to unknown classes

In an exemplary aspect, the QoE manager communication module 1260 may operate to generate a terminal node update message for sending to a QoE manager module in the network, such as the QoE manager module 1020 of FIG. 10. In one aspect, the QoE manager communication module 1260 includes a data stream importance metric and data stream quality metric associated with each data stream, and a terminal node ID and associated access node ID, and other information related to the terminal node and associated access node. It is possible to generate a terminal node update message including at least one of. In one aspect, the QoE manager communication module 1260 may receive a mitigation command message from the QoE manager module, and may assist in implementing the mitigation command contained in the mitigation command message.

In one aspect, the terminal node update message prepared by the QoE manager communication module 1260 may be sent only for data streams within a specific class of service (CoS) or a subset of quality of service (QoS). For example, the QoE manager communication module 1260 can only prepare and send a terminal node update message for data streams within the following criteria: LTE QCI=6-9, non-GBR, best effort stream. This example assumes that other resource allocation systems will be in charge of guaranteeing the quality of the higher importance stream, such as an eNB layer 2 scheduler that will properly manage the GBR stream.

In one aspect, the terminal node update message prepared by the QoE manager communication module 1260 may be sent only when triggered. Options for such triggers are: Periodically; Upon receiving a request from a QoE manager module (such as QoE manager module 1020 in FIG. 10); Based on changes or updates in data stream status or data stream characteristics; And based on the handoff to the new serving access node. In one aspect, the QoE manager communication module 1260 inserts the terminal node update message into the outbound traffic stream of the terminal node, so that it has access to forward it to the QoE manager module (such as the QoE manager module 1020 in FIG. 10). The terminal node update message can be sent by using the traffic interface module 1280 to be sent to the node. Techniques for sending messages from a terminal node to an external module through an associated access node, such as those discussed above with respect to cooperative specific applications or other techniques known in the art, may be used. In one aspect, the QoE manager communication module 1260 may send the terminal node update message as a whole, or may divide the update information and send it as a plurality of messages. In one aspect, the terminal node update message may contain only information related to a change in the characteristics of the data stream of the data stream or the characteristics of the terminal, rather than all possible information related to the terminal node or all data streams.

In an exemplary aspect, the terminal node update message may include one or more of the following data fields for each data stream:

-Data field: TerminalNodeID

소스: 단말 노드 인터페이스 모듈(1210)을 통하여 네트워크 스택으로부터 획득됨.

Source: Obtained from the network stack through the terminal node interface module 1210.

설명: 단말 노드에 대한 식별자.

Description: The identifier for the leaf node.

예: MAC 주소, IP 주소(공공인 경우), IMSI 또는 다른 고유 ID 중 하나일 수 있음.

Example: May be one of the MAC address, IP address (if public), IMSI, or some other unique ID.

-Data field: AppID

소스: 스트림 검출 및 분류 모듈(1250)에 의해 배정됨.

Source: assigned by stream detection and classification module 1250.

설명: 데이터 스트림과 연관된 특정 애플리케이션의 로컬 고유 식별자.

Description: The local unique identifier of the specific application associated with the data stream.

예: 특정 애플리케이션의 OS 프로세스 ID 및 타임스탬프의 n-비트 해시일 수 있음.

Example: May be an n-bit hash of a specific application's OS process ID and timestamp.

-Data field: StreamID

소스: 단말 노드 인터페이스 모듈(1210)을 통하여 네트워크 스택으로부터 획득됨.

Source: Obtained from the network stack through the terminal node interface module 1210.

설명: 데이터 스트림의 식별자. 5-투플 정보(IP 소스, IP 수신지, 포트 소스, 포트 수신지, 프로토콜)의 n-비트 해시일 수 있음. 이 데이터 필드는 그것이 스트림 분류 데이터 필드에 대해 리던던트로 생각될 수 있기 때문에 옵션일 수 있다.

Description: The identifier of the data stream. May be an n-bit hash of 5-tuple information (IP source, IP destination, port source, port destination, protocol). This data field can be optional because it can be thought of as redundant for the stream classification data field.

-Data field: StreamClassification

소스: 단말 노드 인터페이스 모듈(1210)을 통하여 네트워크 스택으로부터 획득됨.

Source: Obtained from the network stack through the terminal node interface module 1210.

설명: 이것은 데이터 패킷을 특정 데이터 스트림에 연관시키기 위해 패킷 검사를 수행하도록 QoE 매니저 모듈에 정보를 제공한다. 이 데이터 필드는 데이터 스트림의 5-투플 정보(IP 소스 주소, IP 수신지 주소, IP 소스 포트, IP 수신지 포트, 프로토콜)의 연접일 수 있다.

Description: This provides information to the QoE manager module to perform packet inspection to associate data packets with specific data streams. This data field may be a concatenation of 5-tuple information (IP source address, IP destination address, IP source port, IP destination port, protocol) of the data stream.

-Data field: Cell_ID

소스: 단말 노드 인터페이스 모듈(1210)을 통하여 네트워크 스택으로부터 획득됨.

Source: Obtained from the network stack through the terminal node interface module 1210.

설명: 단말 노드와 연관된 액세스 노드의 식별자.

Description: The identifier of the access node associated with the terminal node.

예: 이 데이터 필드는 예를 들어 LTE eNB에 대한 글로벌 셀 ID일 수 있다.

Example: This data field may be, for example, a global cell ID for an LTE eNB.

-Data field: Data stream importance metric

소스: 스트림 메트릭 결정 모듈(1230)에 의해 결정됨.

Source: Determined by the stream metric determination module 1230.

설명: (위에서 설명된) 데이터 스트림에 대한 중요도 표시자. 이 데이터 필드는 데이터 스트림 중요도 메트릭의 계산에서 사용되는 메트릭 중 하나 이상에 의해 대신 교체되어 그로써 QoE 매니저 모듈이 데이터 스트림에 대한 데이터 스트림 중요도 메트릭을 자체 컴퓨팅 가능하게 할 수 있다.

Description: An indicator of importance for the data stream (described above). This data field is instead replaced by one or more of the metrics used in the calculation of the data stream importance metric, thereby enabling the QoE manager module to self-compute the data stream importance metric for the data stream.

예: 이 데이터 필드는 4 비트값일 수 있다.

Example: This data field can be a 4-bit value.

-Data field: data stream quality metric

소스: 스트림 메트릭 결정 모듈(1230)에 의해 결정됨.

Source: Determined by the stream metric determination module 1230.

설명: (위에서 설명된) 데이터 스트림에 대한 품질 표시자. 이 데이터 필드는 데이터 스트림 품질 메트릭의 계산에서 사용되는 메트릭 중 하나 이상에 의해 대신 교체되어 그로써 QoE 매니저 모듈이 데이터 스트림에 대한 데이터 스트림 품질 메트릭을 자체 컴퓨팅 가능하게 할 수 있다.

Description: A quality indicator for the data stream (described above). This data field is instead replaced by one or more of the metrics used in the calculation of the data stream quality metric, thereby enabling the QoE manager module to self-compute the data stream quality metric for the data stream.

예: 이 데이터 필드는 4 비트값일 수 있다.

Example: This data field can be a 4-bit value.

-Date field: Handover metric

소스: 단말 노드 인터페이스 모듈(1210)을 통하여 네트워크 스택으로부터 획득됨.

Source: Obtained from the network stack through the terminal node interface module 1210.

설명: 단말 노드가 어느 다른 액세스 노드로 핸드오버 되었음의 표시. 이 데이터 필드는 연관된 데이터 스트림을 새로운 셀(액세스 노드)에 리-매핑하도록 QoE 매니저 모듈에 의해 사용될 수 있다. 일 태양에 있어서, 이 데이터 필드는 단말 노드 인터페이스 모듈(1210)에 의해 새로운 Cell_ID(액세스 노드)의 검출에 뒤이어 제1 단말 노드 업데이트 메시지에서 보내진다.

Description: An indication that the leaf node has been handed over to some other access node. This data field can be used by the QoE manager module to re-map the associated data stream to a new cell (access node). In one aspect, this data field is sent in the first terminal node update message following detection of a new Cell_ID (access node) by the terminal node interface module 1210.

예: 이 데이터 필드는 1 비트값일 수 있다.

Example: This data field can be a 1-bit value.

In an exemplary aspect, the QoE response module 1270, from a QoE manager module in the network, such as the QoE manager module 1020 of FIG. 10, is associated with one or more data streams and contains a QoE mitigation command to be executed in a terminal node. It may be operable to receive a command message. In one aspect, the QoE response module 1270 may be operable to execute mitigation instructions associated with one or more data streams. Such mitigation instructions may include, for example, coordinating with the traffic interface module 1280 to delay or discard data packets associated with a particular application, and the terminal node interface module 1210 to terminate or otherwise adjust the operation of the particular application. And coordination.

In one aspect, the traffic interface module 1280 monitors and/or accesses data packets, such as at any point between the IP and TCP layers, or for example between the TCP and HTTP layers. Acts as an interface. Data packets monitored by traffic interface module 1280 may then be inspected by stream detection and classification module 1250. In one aspect, the traffic interface module 1280 may also be operable to insert a message provided from the QoE manager communication module 1260, such as a terminal node update message, into the user plane traffic of the terminal node. Traffic interface module 1280 may also operate to perform or assist in implementing mitigation options as indicated by QoE response module 1270. For example, the traffic interface module 1280 may delay a data packet of a data stream so as not to reach a specific application associated with it, or may discard a data packet of a data stream associated with a specific application. The traffic interface module 1280 may also use the method described above with respect to FIGS. 1 to 9 or other known methods, such as the QoE manager module 1020 of FIG. It can act to communicate outside. For example, the traffic interface module 1280 may communicate in/out of the QoE manager module in the network using a TCP/IP socket, a remote procedure call, or other known communication technology.

In an exemplary aspect, other logic modules 1240 may include the logic and functionality necessary to help other modules in master application module 1200 execute their functions and communications as described herein.

As mentioned above, in an exemplary aspect, the QoE manager module collects data stream information from various terminal nodes associated with a plurality of access nodes in the network environment, and then uses the collected information to perform mitigation actions in each cell. Determine if one or more of the data streams are required to maintain or increase the overall perceived quality metric for In one aspect, the QoE manager module is operative to maintain or increase the overall perceived quality metric for all or part of the data stream associated with the access node. In one aspect, the QoE manager module maps each data stream to a cell, calculates a comprehensive cell-wide quality metric (CQM) for each cell, and determines whether a mitigation action is required for the data stream in any of the cells. Determine and use the collected data stream information to initiate mitigation actions, whether locally or by sending commands to the appropriate terminal node(s). The QoE manager module may be implemented in its own dedicated network node like the QoE manager module 1020 of FIG. 10, and its functionality is, for example, the P-gateway 1030 and the S-gateway 1040 of FIG. , MME 1060 and access node 1050, may be implemented in one or more network nodes that are also configured to perform other network functions. The QoE manager module may be located at a predetermined point in a network environment through which all data streams providing services to a specific cell will pass. For example, in an LTE network environment, the QoE manager module may be located between the P-gateway and the Internet when the LTE network operator uses a single PDN. In another example, in an LTE network environment, the QoE manager module may be located between the P-gateway and the S-gateway.

In an alternative aspect, the QoE manager module may be located at a certain point through which the desired subset of data streams will pass. For example, in an LTE network environment, the QoE manager module may be located between the Internet and one P-gateway providing best effort (without telecommunications company sponsorship) data traffic service in a multi-PDN network. In such an example, the system is limited to managing those data streams passing through one P-gateway, which may be, for example, best effort, QCI=9 data stream traffic. As mentioned above, the QoE manager module function is distributed in a cloud-based manner anywhere on the Internet that needs to be located at one of the network location points described above, except for the mitigation module and the traffic interface module 1280. Can be. In an alternative aspect, the cloud-based QoE manager is based on an existing network capable of grooming and/or policing data stream traffic, such as an eNB, PCEF or P-gateway that applies MBR to each data stream. Policy changes can be communicated to the rescue node.

13 is a block diagram of a Quality of Experience (QoE) manager module according to an aspect of the present invention. In an exemplary aspect, the quality of experience (QoE) manager module 1300 of FIG. 13 is, but is not limited to, a traffic interface module 1370, a mapper module 1310, a metric determination module 1320, and another logic module ( 1330), an update receiving module 1340, a mitigation module 1350, and a communication module 1360.

In an exemplary aspect, the traffic interface module 1370 monitors data stream traffic in the network environment, such as data traffic between the content server 1010 and one or more of UE1 1071 and UE2 1071, It is an in-band, user plane traffic interface that can be copied, delayed and/or discarded. In one aspect, the traffic interface module 1370 may monitor data traffic to identify and receive a terminal node update message sent to it from a terminal node in the network environment, for use by the update receiving module 1340 . The traffic interface module 1370 may also support mitigation actions on one or more data streams as indicated by the metric determination module 1320 and the mitigation module 1350, such as delaying or discarding data packets of the data stream. have. The traffic interface module 1370 also inserts a message into the network traffic flow sent from the communication module 1360, such as a mitigation command message instructing each terminal node to take a local mitigation action against one or more data streams. By doing so, it is possible to support the mitigation action. The traffic interface module 1370 may also facilitate and support communication in and out of the terminal node, such as by cooperative application communication technology as discussed above or by other known communication methods.

In an exemplary aspect, the update receiving module 1340 receives a terminal node update message sent to it from the traffic interface module 1370, and thereafter, information contained in each of the received terminal node update messages is stored in the QoE manager module 1300. ) Each received terminal node update message can be parsed so that it can be used by other modules within.

In an exemplary aspect, the mapper module 1310 is sent to the corresponding cell or access node based on information contained in each received terminal node update message sent from the update receiving module 1340 to the mapper module 1310. It is possible to update and maintain the relational mapping of each data stream of. In one aspect, the access node may be another type of node in the network through which data stream traffic passes in/out of the terminal node, such as, for example, a router. In one aspect, the mapper module 1310 may use the cell_ID data field for each data stream in the terminal node update message to generate, update, and maintain the relationship mapping between the associated cell or access node and each data stream. . The mapper module 1310 may also generate, update, and maintain a relationship mapping of each data stream with its associated terminal node and each data stream and with its associated specific application running on the terminal node. These relationships can be determined and derived from information contained in the terminal node update message. The mapper module 1310 controls the storage of mapping information in a data file such as a database such as a table, a spreadsheet, or a SQL database, or a logical mapping such as a pointer, a linked list, or a database query, or another known data mapping method. You can do it easily. In one aspect, the mapper module 1310 updates the mapping information as a new terminal node update message is received by the update receiving module 1340 and thereby, for example, by a handover metric data field in the terminal node update message. As described above, when a terminal node handover is indicated in one or more of the newly received terminal node update messages, the data stream-to-cell mapping will be updated. In one aspect, the mapper module 1310 checks the cell_ID data field from every received terminal node update message to determine whether the cell_ID has changed for terminal_ID, thereby indicating that the terminal node has gone to another cell through handover.

In an exemplary aspect, the metric determination module 1320 determines an aggregate quality metric value based on all or part of the reported data stream from the terminal node update message associated with the access node. In one aspect, the overall quality metric value may be based on all of the reported data streams associated with the cell of the access node. In one aspect, the metric determination module 1320 is provided by the update receiving module 1340, such as the data stream quality metric for each data stream, for use in the determination of the overall quality metric value for each cell. Receive or access terminal node update message information and "data stream to access node" mapping information. The overall quality metric value may be determined as an average or median value of the data stream quality metric for all or part of the data stream associated with a particular access node. In one aspect, the aggregate quality metric value is a subset of all data streams associated with a particular cell of the access node, e.g., only for data streams associated with best effort connections, such as those with QCI=9. Can only be determined for

In one aspect, the comprehensive quality metric value is modified based on the data stream importance metric, quality of service (QoS) value, or service level agreement (SLA) value associated with each data stream used in the determination of the overall quality metric value. Or can be adjusted. For example, the SLA value, QoS value, or data stream importance metric may be provided as a data field associated with each data stream in the terminal node update message, and then the data stream quality of each data stream in the overall quality metric value determination. A weight may be applied to the metric, where the weight is based on a data stream importance metric, QoS value, or SLA value for the data stream. In this way, the importance of high SLA users, such as Gold SLA, will weight the determined overall quality metric more severely, and if the determined high SLA user is experiencing a low data stream quality metric then it will have more impact and lower overall quality. It may result in a metric value and then result in a mitigation action. In one aspect, the determination of the overall quality metric value for each access node may be determined over a period of time, such as by averaging the data stream quality metric for each data stream over a sliding time window. In one aspect, the overall quality metric value may be determined on a periodic basis, or may be determined upon receipt of each terminal node update message. In one aspect, the overall quality metric value is, for example, after the reception of a minimum number of terminal node update messages, such as 3 terminal node update messages, and/or a minimum time period elapsed since the last decision, such as 5 seconds. It can be decided after doing. In one aspect, the determination of the overall quality metric value may exclude a data stream quality metric for a data stream that is intentionally degrading through the implementation of a mitigation option by a QoE manager module or by an associated terminal node.

In one aspect, the metric determination module 1320 may also compare each determined overall quality metric value to a threshold to determine if the overall quality is below a desired level. The threshold for each data stream group, cell or access node may be the same or different, eg, based on the type of data stream associated with it. In one aspect, a threshold value QMV_thresh is established, and when the overall quality metric value falls below QMV_thresh, a timer T is started and mitigation is initiated for that cell. Thereafter, when the overall quality metric value rises above QMV_thresh, the timer T is reset and the mitigation for the cell is ended. The threshold check may further include a minimum duration To (using T) that the overall quality metric value must be below the threshold value before taking the mitigation action, and may also include a hysteresis of the overall quality metric value. Those skilled in the art know how to use other known methods and techniques to determine that a mitigation action is desired, such as comparison of the overall quality metric value to a threshold value, or the use of a mapping between the overall quality metric value and one or more mitigation actions. There will be.

In one aspect, the mitigation module 1350 is configured to apply an action to one or more data streams based on an indication from the metric determination module 1320 that the overall quality metric value associated with the data stream is below the desired level. It can act to determine the mitigation option from among the options. In addition to selecting from among a plurality of mitigation options, the mitigation module 1350 may also indicate the mitigation level to which the mitigation option should be applied. For example, for the mitigation option for discarding data packets, the associated mitigation level may be one or more of a time duration to apply the discard data packet option, the number of data streams to apply the discard data packet option, and a data packet discard rate. In one aspect, the selection of the mitigation option may be a function of the time duration in which the overall quality metric value is below a threshold and/or may be a function of the value of the overall quality metric value.

The plurality of mitigation options may involve local implementation of techniques and/or procedures in the QoE manager module 1300, such as, for example, delaying and/or discarding data packets by the traffic interface module 1370, and It may involve implementation of techniques and/or procedures in the terminal node associated with the data stream(s), for example termination of a particular application associated with the data stream(s). In this regard, the mitigation module 1350 may send a mitigation command message including a mitigation option to be applied to one or more data streams in the terminal node and an mitigation level as an option to a suitable terminal node(s). In one aspect, one of the mitigation options is to take no mitigation action on the cell and continue to monitor the overall quality metric value for that cell.

In one aspect, multiple mitigation options for selection by mitigation module 1350 may consist of multiple tiers of mitigation actions. For example, the mitigation options may be based on the time duration at which the overall quality metric is below the threshold, such as each tier with a stronger mitigation action as the time duration for which the overall quality metric is below the threshold increases. It can be arranged in different tiers of mitigation actions. Similarly, mitigation options can be arranged with mitigation actions of different tiers based on the value of the overall quality metric, such as each tier with a stronger mitigation action as the overall quality metric goes further below the threshold. have. An example aspect showing three tiers of mitigation options based on a time duration (T) where the overall quality metric is below a threshold is described below; Rather, note that the mitigation option tier may be based on the current overall quality metric value or a combination of both T and the overall quality metric (QMV).

-Reduction Tier: Light

임계값 아래 시간 QMV: 5초 미만

Time QMV below threshold: less than 5 seconds

QoE 매니저 모듈에서의 경감 옵션: (1) 가장 낮은 데이터 스트림 중요도 메트릭을 갖는 데이터 스트림으로 시작하여, 데이터 스트림의 서브세트 상에 데이터 패킷 지연 및/또는 폐기를 구현한다; (2) 가장 낮은 데이터 스트림 중요도 메트릭으로 시작하여, 데이터 스트림의 서브세트에 대해 업링크 확인응답(ACK) 지연 및/또는 폐기를 구현한다.

Mitigation options in the QoE manager module: (1) Implement data packet delay and/or discard on a subset of the data stream, starting with the data stream with the lowest data stream importance metric; (2) Starting with the lowest data stream importance metric, implement uplink acknowledgment (ACK) delay and/or discard for a subset of the data stream.

단말 노드에서의 경감 옵션: (1) 가장 낮은 데이터 스트림 중요도 메트릭을 갖는 데이터 스트림으로 시작하여, 데이터 스트림의 서브세트 상에 데이터 패킷 지연 및/또는 폐기를 구현한다; (2) 가장 낮은 데이터 스트림 중요도 메트릭으로 시작하여, 데이터 스트림의 서브세트에 대해 업링크 확인응답(ACK) 지연 및/또는 폐기를 구현한다.

Mitigation options at the terminal node: (1) Implement data packet delay and/or discard on a subset of the data stream, starting with the data stream with the lowest data stream importance metric; (2) Starting with the lowest data stream importance metric, implement uplink acknowledgment (ACK) delay and/or discard for a subset of the data stream.

-Reduction Tier: Medium

임계값 아래 시간 QMV: 5초와 20초 사이

Time below threshold QMV: between 5 and 20 seconds

QoE 매니저 모듈에서의 경감 옵션: "라이트" 경감 티어와 동일하다, 더하여 (3) 단말 노드 업데이트 메시지에 들어있는 부가적 데이터 스트림 정보에 기반하여, 단말 노드 내 새로 론칭된 특정 애플리케이션과 같이, 특정 애플리케이션과 연관된 새로운 데이터 스트림의 개시 요청의 지연 및/또는 폐기를 구현한다.

Mitigation options in the QoE manager module: Same as the "light" mitigation tier, in addition (3) Based on the additional data stream information contained in the terminal node update message, a specific application, such as a newly launched specific application in the terminal node Implement a delay and/or discard of a request to initiate a new data stream associated with it.

단말 노드에서의 경감 옵션: "라이트" 경감 티어와 동일하다, 더하여 (3) 단말 노드 내 새로 론칭된 특정 애플리케이션과 같이, 특정 애플리케이션과 연관된 새로운 데이터 스트림의 개시 요청의 지연 및/또는 폐기를 구현한다. 일 태양에 있어서, 협력형 특정 애플리케이션은 새로운 데이터 스트림에 대한 그 요청이 거부된다고 명령받을 수 있고, 새로운 데이터 스트림에 대한 어떠한 요청도 개시하지 않도록 명령받을 수 있다.

Mitigation options at the terminal node: Same as the "light" mitigation tier, in addition (3) Implement delay and/or discard the request to initiate a new data stream associated with a specific application, such as a newly launched specific application within the terminal node. . In one aspect, a cooperative specific application may be instructed that the request for a new data stream is denied and may be instructed not to initiate any request for a new data stream.

-Reduction Tier: Heavy

임계값 아래 시간 QMV: 20초 초과

Time QMV below threshold: greater than 20 seconds

QoE 매니저 모듈에서의 경감 옵션: "미디움" 경감 티어와 동일하다, 더하여 (4) 예를 들어 특정 구체적 애플리케이션과 연관된 모든 스트림에 대한 모든 데이터 패킷을 폐기함으로써와 같이, 가장 낮은 데이터 스트림 중요도 메트릭과 연관된 특정 애플리케이션으로 시작하여, 셀 내 데이터 스트림과 연관된 특정 애플리케이션의 서브세트의 종료를 구현한다. 일 태양에 있어서, 특정 구체적 애플리케이션과 연관되어 있는 모든 스트림에 대한 모든 데이터 패킷의 무한 지연의 구현은 효과적으로는 특정 애플리케이션을 종료시킬 것이다.

Mitigation options in the QoE Manager module: Same as the "medium" mitigation tier, in addition (4) associated with the lowest data stream importance metric, for example by discarding all data packets for all streams associated with a specific specific application. Starting with a specific application, it implements the termination of a subset of the specific application associated with the data stream in the cell. In one aspect, the implementation of an infinite delay of all data packets for all streams associated with a specific specific application will effectively terminate the specific application.

단말 노드에서의 경감 옵션: "미디움" 경감 티어와 동일하다, 더하여 (4) 가장 낮은 데이터 스트림 중요도 메트릭과 연관된 특정 애플리케이션으로 시작하여, 셀 내 데이터 스트림과 연관된 특정 애플리케이션의 서브세트의 종료를 구현한다. 일 태양에 있어서, 종료될 특정 구체적 애플리케이션은 협력형 특정 애플리케이션이고 QoE 매니저 모듈은 협력형 특정 애플리케이션에 의해 수신되는 경감 명령어 메시지를 연관된 단말 노드에 보내고 그 결과 협력형 특정 애플리케이션은 스스로 종료되고, 옵션으로서는 임박한 종료에 대해 경고하도록 사용자 메시지를 또한 디스플레이할 수 있다. 일 태양에 있어서, QoE 매니저 모듈은 특정 구체적 애플리케이션과 연관된 모든 스트림에 대한 모든 데이터 패킷을 인터셉트 및 폐기하도록 그 연관된 단말 노드 내 마스터 애플리케이션 모듈에 경감 명령어 메시지를 보낼 수 있다. 일 태양에 있어서, 연관된 단말 노드 내 마스터 애플리케이션 모듈로의 경감 명령어 메시지는 특정 구체적 애플리케이션과 연관되어 있는 모든 스트림에 대한 모든 데이터 패킷의 무한 지연을 구현하여 효과적으로는 특정 애플리케이션을 종료시키게 되도록 명령할 수 있다.

Mitigation options at the terminal node: same as the "medium" mitigation tier, in addition (4) implements termination of a subset of specific applications associated with the data stream in the cell, starting with the specific application associated with the lowest data stream importance metric . In one aspect, the specific specific application to be terminated is a specific cooperative application and the QoE manager module sends a mitigation command message received by the specific cooperative application to the associated terminal node, as a result of which the specific cooperative application terminates itself, and optionally A user message can also be displayed to warn of an impending shutdown. In one aspect, the QoE manager module may send a mitigation command message to a master application module in its associated terminal node to intercept and discard all data packets for all streams associated with a specific specific application. In one aspect, the mitigation command message to the master application module in the associated terminal node implements an infinite delay of all data packets for all streams associated with a specific specific application, thereby effectively instructing to terminate a specific application. .

As mentioned above, in addition to the selection of the mitigation option, the mitigation module 1350 may also indicate the level at which the mitigation option should be applied, such as, for example, mitigation strength and/or mitigation time duration. In one aspect, the time duration to implement the mitigation option and the intensity level to implement the mitigation option are (1) the time duration (T) where the overall quality metric value (QMV) is below the threshold value, and/or (2) the overall quality metric value itself. Can be a function of The strength level for the mitigation option may be, for example, the number or percentage of data streams to implement the mitigation option, the percentage level of data packets to be discarded, and/or the delay time to delay the data packets. In one aspect, the determination of the percentage of streams to be mitigated using, for example, data packet delay and/or discard may be based on Table A below.

In one aspect, for example, the determination of the percentage of data packets to discard for the data stream being mitigated may be based on Table B below.

In an exemplary aspect, the communication module 1360 generates a mitigation command message comprising a mitigation option selected by the mitigation module 1350 and, as an option, a mitigation level, to be applied to one or more data streams at the terminal node and (S), through the traffic interface module 1370, can operate to send. In this way, the communication module 1360 supports mitigation options to be implemented wholly or partially at the terminal node level. For example, a specific mitigation option is directly related to local mitigation in the QoE manager module 1300 by discarding data packets of one or more data streams, and a mitigation action at the terminal node to delay data packets of one or more data streams. Can be directly related to. In such an example, the communication module 1360 generates a mitigation command message including a mitigation option that instructs the terminal node to delay packets of one or more data streams, and to the appropriate terminal node, the traffic interface module 1370. Through, send. In an alternative aspect, in a manner similar to that described above with respect to the QoE manager module 1300, the communication module 1360 may, such as a total quality metric value and/or a time duration in which the overall quality metric value is below a threshold, A mitigation command message containing raw data can be generated and sent to the appropriate terminal node, via the traffic interface module 1370, after which the master application module in the terminal node can use the raw data to determine what mitigation options to take. have.

In an exemplary aspect, the other logic module 1330 may include the logic and functionality necessary to help other modules in the QoE manager module 1300 execute their functions and communications as described herein.

14 is a flowchart depicting top-level functionality of a master application module in a terminal node supporting haptic quality management according to an aspect of the present invention. In step 1401, the terminal node updates application data stream information for each data stream it detects that it is providing a service to a specific application running on the terminal node. For example, as described above with respect to FIG. 12, master application module 1200 performs this task by using traffic interface module 1280 and stream detection and classification module 1250. Next, in step 1403, the terminal node updates the current application characteristic data set and the terminal node characteristic data set. For example, as described above with respect to FIG. 12, the master application module 1200 performs this task by using the characteristic evaluation module 1220. In step 1405, the terminal node determines a data stream importance metric for each data stream, and in step 1407, the terminal node determines a data stream quality metric for each data stream. For example, as described above with respect to FIG. 12, the master application module 1200 performs this task by using the stream metric determination module 1230.

Next, the terminal node generates a terminal node update message and sends it to the QoE manager module implemented in one or more other nodes in the network. For example, as described above with respect to FIG. 12, the master application module 1200 performs this task by using the QoE manager communication module 1260 and the traffic interface module 1280. In step 1411, the terminal node waits for the occurrence of a trigger event or a periodic period of time, such as receipt of a message from the OS or a specific cooperative application, before returning to the start of the process in step 1401. One or more of the steps of FIG. 14 described above may be optional, and the determination of whether to perform one or more of the steps of FIG. 14 may depend on the condition or the type of event that triggered the start of the procedure of FIG. 14. It should be noted that there is.

15 is a flow chart depicting the top-level functionality of a sensory quality manager module in accordance with an aspect of the present invention. In step 1501, the QoE manager module receives a terminal node update message from various terminal nodes in the network. For example, as described above with respect to FIG. 13, the QoE manager module 1300 performs this task by using the update receiving module 1340 and the traffic interface module 1370. Next, in step 1503, the QoE manager module updates the relationship map associating each data stream to its associated cell and each data stream to its associated terminal node. For example, as described above with respect to FIG. 13, the QoE manager module 1300 performs this task by using the update receiving module 1340 and the traffic interface module 1370. In step 1505, the QoE manager module determines a comprehensive quality metric value for each cell based on the data stream quality metric for each data stream extracted from the received terminal node update message. For example, as described above with respect to FIG. 13, the QoE manager module 1300 performs this task by using the metric determination module 1320. Thereafter, in step 1507, the QoE manager module determines an abatement option for one or more of the data streams in the cell based on the comprehensive quality metric value, where the abatement option may be that no action is taken. For example, as described above with respect to FIG. 13, the QoE manager module 1300 performs this task by using the mitigation module 1350. Then, in step 1509, the QoE manager module executes the mitigation option for one or more of the data streams in the cell, which may be implemented locally by the QoE manager module or at the associated terminal node. For example, as described above with respect to FIG. 13, the QoE manager module 1300 performs this task by using an mitigation module 1350, a traffic interface module 1370, and optionally a communication module 1360. One or more of the steps of FIG. 15 described above may be optional, and the determination of whether to perform one or more of the steps of FIG. 15 may depend on a condition at the start of the procedure of FIG. 15 or the type of event. You should keep in mind.

16 is a flow chart depicting top-level mitigation functionality of a master application module in a terminal node supporting haptic quality management according to an aspect of the present invention. In step 1601, the terminal node receives, from the QoE manager module, a mitigation command message containing, partially or entirely, an mitigation option on one or more data streams associated with the terminal node. For example, as described above with respect to FIG. 12, the master application module 1200 in the terminal node performs this task by using the QoE manager communication module 1260 and the traffic interface module 1280. Next, the terminal node executes the mitigation option received in the mitigation command message on one or more data streams associated with the terminal node in step 1603. For example, as described above with respect to FIG. 12, the master application module 1200 in the terminal node uses a QoE response module 1270, a traffic interface module 1280, and an optional terminal node interface module 1210. Perform these tasks. In this way, the terminal node can monitor the quality of the data stream and, if necessary, act in a cooperative manner with the QoE manager module to maintain or increase the quality of experience for the terminal node user by taking mitigation actions on one or more data streams. have. Although the aspects and embodiments described above may relate to monitoring and management of downlink data streams related to a specific application operating in the terminal node, the QoE manager module and the master application module(s) operate in the terminal node and It is noted that we can similarly cooperate to monitor and manage uplink data streams associated with those specific applications in existence. In such a scenario, the content server may be located on the terminal node, and the client application may be located on another node in the network.

In an alternative aspect, a terminal node in the network environment monitors the quality of a data stream associated with a specific application within the terminal node and, if necessary, takes a mitigation action on one or more data streams to experience the experience associated with one or more of those specific applications within the terminal node Each can act alone to maintain or increase quality. In this aspect, the terminal node operates alone without the help of the QoE manager module and instead implements some of the features and functions described above with respect to the QoE manager module directly in the terminal node. In this way, each terminal node operates locally to monitor and adjust the quality of the data stream associated with a particular application running on each terminal node.

17 is a block diagram of a master application module in a terminal node performing haptic quality management according to an aspect of the present invention. The master application module 1700 of FIG. 17 is an alternative aspect mentioned above in which the terminal node operates independently without the help of the QoE manager module to locally monitor and adjust the quality of the data stream associated with a specific application running in the terminal node. Is configured to operate according to. It can be seen from FIG. 17 that the master application module 1700 includes several of the same modules described above with respect to the master application module 1200 of FIG. 12. The functionality of each identical module is not repeated here for brevity, except where some differences may apply in this alternative aspect. One of the key differences in this alternative aspect is that the QoE response module 1270 and the QoE manager communication module 1260 in the master application module 1200 of FIG. 12 are not included in the master application module 1700 of FIG. 17. will be. Instead, the mitigation module 1760 is provided to the master application module 1700 to determine and execute, if any, mitigation options based on the aggregate quality metric for the data stream associated with the terminal node, as described more fully below. do.

Without repeating the detailed functionality of the same modules as those shown in FIG. 12, a brief overview of the process flow for the master application module 1700 is provided by the stream detection and classification module 1750 and the traffic interface module 1780. It detects, identifies, and classifies data streams that support a specific application running in, and then the characteristic evaluation module 1720, with possible support from the terminal node interface module 1710, is the current application for each data stream. It is to identify the characteristic data set and the current terminal node characteristic data set together with other related information. The stream metric determination module 1730 determines a data stream importance metric and a data stream quality metric for each data stream based on the current application characteristic data set and the current terminal node characteristic data set along with other related information, and then A comprehensive (terminal node wide) quality metric for some or all of the data streams associated with the node is further determined. In this regard, the stream metric determination module 1730 includes a data stream quality metric, a data stream importance metric, and a data stream quality metric according to any one of the techniques and methods described above with respect to the metric determination module 1320 of the QoE manager module 1300 of FIG. 13. Comprehensive (terminal node wide) quality metrics can be determined. The difference in this alternative aspect of FIG. 17 is that the aggregate quality metric value determined by the metric determination module 1320 of FIG. 13 is for some or all of the data streams associated with all terminal nodes corresponding to the access nodes in the network. In contrast to being based on the data stream quality metric, the overall (terminal node wide) quality metric is based on the data stream quality metric for only data streams associated with a specific terminal node. The stream metric determination module 1730 may then compare the comprehensive (terminal node wide) quality metric to a threshold value using the techniques and methods described above with respect to the metric determination module 1320 of FIG. 13.

The mitigation module 1760 determines a mitigation option to be applied to one or more of the data streams associated with the terminal node by using the result of comparing the comprehensive (terminal node wide) quality metric against the threshold value. As mentioned above, one of the mitigation options is to take no current action and continue to monitor the overall quality metric. The mitigation option types described above with respect to the mitigation module 1350, and techniques and methods for determining mitigation options, may be used by the mitigation module 1760 and are not repeated here for brevity. Those mitigation options described above that may be implemented and/or applied by the terminal node may be used. In this regard, the mitigation module 1760 may coordinate with one or more of the traffic interface module 1780 and the terminal node interface module 1710, and then execute the mitigation option determined on one or more data streams associated with the terminal node. . As described above with respect to the mitigation module 1350 of FIG. 13, the manner of execution of the mitigation option including the duration and level (intensity) of the implementation is used by the mitigation module 1760 of FIG. 17 to execute the mitigation option. Can be.

18 is a flow chart depicting top-level functionality of a master application module in a terminal node performing haptic quality management in accordance with an aspect of the present invention. In particular, the flowchart of FIG. 18 corresponds to the master application module 1700 of FIG. 17. In step 1801, the terminal node updates application data stream information for each data stream it detects that it is providing a service to a specific application running in the terminal node. For example, as described above, master application module 1700 performs this task by using traffic interface module 1780 and stream detection and classification module 1750. Next, in step 1803, the terminal node updates the current application characteristic data set and the current terminal node characteristic data set. For example, as described above, the master application module 1700 performs this task by using the characteristic evaluation module 1720. In step 1805, the terminal node determines a data stream importance metric for each data stream, and in step 1807, the terminal node determines a data stream quality metric for each data stream. For example, as described above, the master application module 1700 performs these tasks by using the stream metric determination module 1730. Next, in step 1809, the terminal node provides a comprehensive (terminal wide) quality based on a data stream quality metric, a data stream importance metric, and other information related to one or more of the data streams associated with a specific application running in the terminal node. Determine the metric. For example, as described above, the master application module 1700 performs these tasks by using the stream metric determination module 1730 in addition to comparing the overall (terminal wide) quality metric to a threshold. .

Then, in step 1811, the terminal node determines an mitigation option for one or more of the data streams associated with the terminal node based on the overall quality metric value, where the mitigation option may be to take no action. For example, as described above, the master application module 1700 performs this task by using the mitigation module 1760. In step 1813, the terminal node executes a reduction option for one or more of the data streams associated with the cell. For example, as described above, the master application module 1700 performs this task by using the mitigation module 1760, the traffic interface module 1780 and, optionally, the terminal node interface module 1710. In this way, each terminal node can independently operate locally to monitor and adjust the quality of a data stream associated with a specific application running on each terminal node.

Although the aspects and embodiments described above with respect to FIGS. 17 and 18 may relate to monitoring and management of downlink data streams related to a specific application operating in the terminal node, the master application module(s) is the terminal node. Note that we can similarly cooperate to monitor and manage the uplink data streams associated with those specific applications running on. In such a scenario, the content server may be located on the terminal node, and the client application may be located on another node in the network.

The above-described systems and methods and associated devices and modules are readily possible in many variations. Additionally, for clarity and brevity, many descriptions of the systems and methods have been simplified. For example, although the drawings generally illustrate one of each type of device (eg, one access node, one terminal node), a communication system may have multiple devices of each type. Similarly, many descriptions use the structure and predicates of certain wireless standards such as LTE. However, the disclosed systems and methods are more widely applicable, including, for example, hybrid fiber-coaxial cable modem systems.

Those of skill in the art will recognize that the various illustrative logical blocks, modules, units, and algorithm steps described in connection with the embodiments disclosed herein can often be implemented in electronic hardware, computer software, or a combination thereof. To clearly illustrate this compatibility of hardware and software, various exemplary components, blocks, modules and steps have been described above generally in terms of their functionality. Whether such functionality will be implemented in hardware or software depends on the specific constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular system, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention. Additionally, grouping of functions within a unit, module, block or step is for ease of description. Certain functions or steps may be moved from one unit, module or block without departing from the invention.

The various illustrative logic blocks, units, steps, and modules described in connection with the embodiments disclosed herein include general purpose processors, digital signal processors (DSPs), application specific semiconductors (ASICs), field programmable gate arrays (FPGAs), or other programmable gate arrays (FPGAs). It may be implemented or performed with a processor such as a logic device, discrete gate or transistor logic, discrete hardware components, or any combination designed to perform the functions described herein. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any processor, controller, microcontroller or state machine. The processor may also be implemented in a combination of computing devices, eg, a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors with a DSP core, or any other such configuration.

The processes of the blocks or modules described in connection with the embodiments disclosed herein and the steps of the algorithm or method may be embodied as hardware directly, as a software module executed by a processor, or as a combination of both. The software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, removable disk, CD-ROM or any other type of storage medium. An exemplary storage medium may be coupled to the processor such that the processor can write information to and read information from the storage medium. Alternatively, the storage medium may be integral to the processor. The processor and storage medium can reside in the ASIC. Additionally, a device, block, or module described as coupled may be coupled through an intermediary device, block or module. Similarly, the first device is said to transmit (or receive from) data to the second device when there is an intermediary device coupling the first device and the second device and also when the first device is unaware of the ultimate destination of the data. May be explained.

The above description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles described herein can be applied to other embodiments without departing from the spirit or scope of the present invention. Thus, it is to be understood that the description and drawings presented herein represent the presently preferred embodiments of the present invention and thus represent the subject matter broadly contemplated by the present invention. Moreover, it is understood that the scope of the invention encompasses entirely other embodiments that may become apparent to those skilled in the art and thus the invention is not limited by anything other than the appended claims.

Claims (84)

As an application manager node in a communication network,
A transceiver module configured to monitor data communication within the communication network; And
A processor coupled to the transceiver, the processor comprising:
Application information related to at least one application data stream associated with at least one application operating in at least one terminal node is transmitted from the at least one terminal node through an application protocol (APP)-agent cooperative communication control path. Receiving, but the at least one application data stream is communicated through an application data path,
Based on the application information, updating a relationship map including a relationship between each of the at least one application data stream and an access node,
Determine a comprehensive quality metric value based at least in part on the application information received from one or more of the at least one terminal node, and
An application manager node configured to select at least one mitigation option for one or more of the at least one application data stream based on the overall quality metric value. The method of claim 1, wherein the relationship map further includes a relationship between each of the at least one application data stream and one of the at least one terminal node transmitting application information for each application data stream to the application manager node. The application manager node. The application manager node of claim 1, wherein the comprehensive quality metric value is based at least in part on the application information received from one or more of the at least one terminal node associated with the access node. The application manager node of claim 1, wherein the processor is further configured to initiate the at least one mitigation option. The application manager node of claim 1, wherein the aggregate quality metric value is compared to a threshold value and mitigation selection is performed when the aggregate quality metric value crosses the threshold value. The application manager node of claim 1, wherein a communication link through which the access node and the terminal node communicates is one of a wireless network and a wired network. The application manager node of claim 1, wherein the application information is one of an aperiodic report and a periodic report received from the at least one terminal node. The application manager node of claim 1, wherein the application information includes application information and terminal node information, and the comprehensive quality metric value is determined based on the application information and the terminal node information. The application manager node of claim 1, wherein the application information includes at least one of a data stream importance metric and a data stream quality metric related to one or more of at least one data stream associated with a corresponding application. The method of claim 1, wherein the comprehensive quality metric value is a cell-wide quality metric value determined based on a data stream quality metric for at least one of the at least one application data stream associated with a cell of the access node. Application manager node. 11. The application manager node of claim 10, wherein the determination of the overall quality metric value is based on an average value of data stream quality metrics for one or more of the at least one application data stream. The method of claim 10, wherein when determining the overall quality metric value, a weight is applied to each data stream quality metric, and each weight is a service level agreement (SLA) value, a quality of service (QoS). ) Value and the data stream importance metric. The application manager node of claim 1, wherein the aggregate quality metric value is determined based on a data stream quality metric for each of a subset of the at least one application data stream associated with the access node. The application manager node according to claim 5, wherein the selection of the at least one reduction option is performed when the comprehensive quality metric value stays below the threshold value for a minimum time duration. The method of claim 4, wherein initiating the at least one mitigation option comprises transmitting a mitigation command message to one of the at least one terminal node associated with the application data stream in which the mitigation option is to be implemented. Application manager node. The application manager node of claim 15, wherein the mitigation command message includes at least one of the total quality metric value and a time duration in which the comprehensive quality metric value is below a threshold value. The method of claim 1, wherein the at least one mitigation option is to delay the data packet, discard the data packet, delay the acknowledgment, discard the acknowledgment, delay a request to initiate a new data stream. , Discarding a request to initiate a new data stream, terminating the application, and taking no action. The application of claim 1, wherein the selection of the at least one mitigation option associated with one or more of the at least one application data stream is based at least in part on a data stream importance metric for each of the at least one application data stream. Manager node. 5. The application manager node of claim 4, wherein the selected at least one mitigation option is implemented based on a time duration in which the aggregate quality metric value is below a threshold value. 5. The application manager node of claim 4, wherein the selected at least one mitigation option is implemented based on the aggregate quality metric value. As a terminal node in a communication network having an access node,
A transceiver module configured to transmit and receive data packets to and from the access node through the communication network; And
Comprising a processor coupled to the transceiver, wherein the processor,
At least one application data stream is detected through an application data path by monitoring the data packet transmitted and received in and out of the access node through the communication network,
For each of the detected at least one application data stream, as application information related to an application running in the terminal node associated with each application data stream, a data stream quality metric for each application data stream is included. Determine the application information to be
Transmitting application information for each of the detected at least one application data stream through the communication network through an application protocol (APP)-agent cooperative communication control path,
Receiving at least one mitigation command associated with one or more of the at least one application data stream through an application protocol (APP)-agent cooperative communication control path through the communication network, and
Wherein the terminal node is configured to implement the at least one mitigation instruction for an associated one or more of the at least one application data stream. The terminal node according to claim 21, wherein the communication network is one of a wireless communication network and a wired communication network. The terminal node according to claim 21, wherein the application information for each of the detected at least one application data stream is determined based at least in part on a current terminal node characteristic data set. 22. The terminal node according to claim 21, wherein the application information is transmitted to the access node for transmission from the access node to an application manager node. The method of claim 21, wherein the processor examines one or more data packets associated with each of the application data streams and assigns an application class value to the application data stream based on the inspection of the one or more data packets. The terminal node is further configured to classify one or more of the application data streams, wherein the application class value is included in application information for each of the application data streams. The method of claim 21, wherein determining application information for each application data stream comprises determining a data stream importance metric for the application data stream and including the data stream importance metric in application information for the application data stream. The terminal node that is to be. The method of claim 26, wherein the processor is based on a current application characteristic data set for each of the at least one application data stream based on a current characteristic of an application associated with the respective application data stream, and a current characteristic of the terminal node. The terminal node further configured to generate at least one of the current terminal node characteristic data set. 28. The terminal node of claim 27, wherein the data stream importance metric is based at least in part on the current application characteristic data set and the current terminal node characteristic data set. The method of claim 27, wherein the current application characteristic data set includes at least one of an application class value, a stream start type value, an update pending value, a display position value, a network quality of service (QoS) value, and a buffer margin value. Terminal node. 28. The terminal node of claim 27, wherein the current terminal node characteristic data set includes at least one of a user attention value and a service level agreement (SLA) value, and a terminal node type. 27. The terminal node of claim 26, wherein the data stream quality metric is based at least in part on an indication of lost or delayed data packets associated with the application data stream. The terminal node according to claim 26, wherein the data stream quality metric is based at least in part on an application quality metric value received from the application operating in the terminal node associated with a corresponding application data stream. The terminal node according to claim 21, wherein the application information for each application data stream includes at least one of an application characteristic data set and a terminal node characteristic data set related to the data stream. The terminal node according to claim 21, wherein the application information is transmitted from the terminal node to the access node in one of a periodic unit and an aperiodic unit. The terminal node of claim 21, wherein the application information further includes at least one of a terminal node ID associated with the terminal node, a cell ID associated with the access node, and a handover metric value. The method of claim 21, wherein the at least one mitigation instruction is a data packet delay instruction, a data packet discard instruction, an acknowledgment delay instruction, an acknowledgment discard instruction, a new data stream request delay instruction, a new data stream request discard instruction, and an application termination. The terminal node comprising one or more of the instructions. The method of claim 21, wherein the at least one mitigation command includes at least one of a comprehensive quality metric value and a time duration in which the comprehensive quality metric value is less than a threshold value, and the implementation of the at least one mitigation command is the comprehensive And determining a mitigation action based on the at least one of a quality metric value and the time duration. 22. The terminal node of claim 21, wherein the implementation of the at least one mitigation instruction is based at least in part on a data stream importance metric for each of the at least one application data stream. 39. The method of claim 38, wherein each one of the at least one mitigation instruction is implemented on the application data stream having the lowest data stream importance metric, and thereafter at least one having the next lowest data stream importance metric in succession. A terminal node that is implemented for other application data streams. 22. The terminal node of claim 21, wherein the at least one mitigation instruction is implemented on an increasing number of associated application data streams as the time duration of implementation increases. 22. The terminal node of claim 21, wherein the at least one mitigation command is implemented based on a time duration in which a quality metric value is less than a threshold value. The terminal node according to claim 21, wherein the implementation level of the at least one mitigation instruction is based on a quality metric value. A method for managing application quality in a communication network, the method comprising:
Application information related to at least one application data stream associated with at least one application operating in at least one terminal node is transmitted from the at least one terminal node through an application protocol (APP)-agent cooperative communication control path. Receiving, the at least one application data stream being communicated via an application data path;
Updating a relationship map including a relationship between each of the at least one application data stream and an access node based on the application information;
Determining a comprehensive quality metric value based at least in part on the application information received from one or more of the at least one terminal node; And
And selecting at least one mitigation option for one or more of the at least one application data stream based on the overall quality metric value. The method of claim 43, wherein the relationship map further comprises a relationship between each of the at least one application data stream and one of the at least one terminal node that has transmitted application information for each application data stream to an application manager node. How it would be. 44. The method of claim 43, wherein the aggregate quality metric value is based at least in part on the application information received from one or more of the at least one terminal node associated with the access node. 44. The method of claim 43, further comprising initiating the at least one mitigation option. 44. The method of claim 43, wherein the aggregate quality metric value is compared to a threshold value and mitigation selection is performed if the aggregate quality metric value crosses the threshold value. 44. The method of claim 43, wherein the communication link through which the access node and the terminal node communicate is one of a wireless network and a wired network. 44. The method of claim 43, wherein the application information is one of an aperiodic report and a periodic report received from the at least one terminal node. 44. The method of claim 43, wherein the application information includes application information and terminal node information, and the comprehensive quality metric value is determined based on the application information and the terminal node information. 44. The method of claim 43, wherein the application information includes at least one of a data stream importance metric and a data stream quality metric related to one or more of at least one data stream associated with a corresponding application. The method of claim 43, wherein the comprehensive quality metric value is a cell-wide quality metric value determined based on a data stream quality metric for one or more of the at least one application data stream associated with a cell of the access node. Way. 53. The method of claim 52, wherein determining the overall quality metric value is based on an average value of the data stream quality metric for one or more of the at least one application data stream. The method of claim 52, wherein when determining the overall quality metric value, a weight is applied to each data stream quality metric, and each weight is selected from among a service level agreement (SLA) value, a quality of service (QoS) value, and a data stream importance metric. Method based on at least one. 44. The method of claim 43, wherein the aggregate quality metric value is determined based on a data stream quality metric for each of a subset of the at least one application data stream associated with the access node. 48. The method of claim 47, wherein selecting the at least one mitigation option is performed if the aggregate quality metric value stays below the threshold value for a minimum time duration. The method of claim 46, wherein initiating the at least one mitigation option comprises transmitting a mitigation command message to one of the at least one terminal node associated with the application data stream in which the mitigation option is to be implemented. How to do it. 58. The method of claim 57, wherein the mitigation command message includes at least one of the aggregate quality metric value and a time duration in which the aggregate quality metric value was below a threshold value. 44. The method of claim 43, wherein the at least one mitigation option is to delay the data packet, discard the data packet, delay the acknowledgment, discard the acknowledgment, delay a request to initiate a new data stream. , Discarding a request to initiate a new data stream, terminating the application, and taking no action. 44. The method of claim 43, wherein selecting the at least one mitigation option associated with one or more of the at least one application data stream is based at least in part on a data stream importance metric for each of the at least one application data stream. Way. 47. The method of claim 46, wherein the selected at least one mitigation option is implemented based on a time duration in which the aggregate quality metric value is below a threshold value. 47. The method of claim 46, wherein the selected at least one mitigation option is implemented based on the aggregate quality metric value. A method for managing application quality in a terminal node in a communication network, the method comprising:
Detecting at least one application data stream through an application data path by monitoring data packets transmitted and received in and out of the access node through the communication network;
For each of the detected at least one application data stream, as application information related to an application running in the terminal node associated with each application data stream, a data stream quality metric for each application data stream is included. Determining the application information to be performed;
Transmitting application information for each of the detected at least one application data stream through the communication network through an application protocol (APP)-agent cooperative communication control path;
Receiving at least one mitigation command associated with at least one of the at least one application data stream through an application protocol (APP)-agent cooperative communication control path through the communication network; And
And implementing the at least one mitigation instruction for an associated one or more of the at least one application data stream. 64. The method of claim 63, wherein the communication network is one of a wireless communication network and a wired communication network. 64. The method of claim 63, wherein application information for each of the detected at least one application data stream is determined based at least in part on a current terminal node characteristic data set. 64. The method of claim 63, wherein the application information is transmitted to the access node for transmission from the access node to an application manager node. 64. The detected at least one application data according to claim 63, by examining one or more data packets associated with each of the application data streams and assigning an application class value to the application data stream based on the inspection of the one or more data packets. Classifying at least one of the streams, and including the application class value in application information for each of the application data streams. 64. The method of claim 63, wherein determining application information for each application data stream comprises determining a data stream importance metric for the application data stream and including the data stream importance metric in application information for the application data stream. The method comprising the step. 69. The terminal of claim 68, wherein a current application characteristic data set for each of the at least one application data stream based on a current characteristic of an application associated with the respective application data stream, and a current terminal based on a current characteristic of the terminal node. The method further comprising generating at least one of the node characteristic data sets. 70. The method of claim 69, wherein the data stream importance metric is based at least in part on the current application characteristic data set and the current terminal node characteristic data set. The method of claim 69, wherein the current application characteristic data set comprises at least one of an application class value, a stream start type value, an update pending value, a display position value, a network quality of service (QoS) value, and a buffer margin value. Way. 70. The method of claim 69, wherein the current terminal node characteristic data set includes at least one of a user attention value and a service level agreement (SLA) value, and a terminal node type. 69. The method of claim 68, wherein the data stream quality metric is based at least in part on an indication of lost or delayed data packets associated with the application data stream. 69. The method of claim 68, wherein the data stream quality metric is based at least in part on an application quality metric value received from the application operating at the terminal node associated with a corresponding application data stream. 64. The method of claim 63, wherein the application information for each application data stream comprises at least one of an application characteristic data set and a terminal node characteristic data set related to the data stream. 64. The method of claim 63, wherein the application information is transmitted from the terminal node to the access node in one of a periodic unit and an aperiodic unit. 64. The method of claim 63, wherein the application information further comprises one or more of a terminal node ID associated with the terminal node, a cell ID associated with the access node, and a handover metric value. The method of claim 63, wherein the at least one mitigation instruction is a data packet delay instruction, a data packet discard instruction, an acknowledgment delay instruction, an acknowledgment discard instruction, a new data stream request delay instruction, a new data stream request discard instruction, and an application termination. Comprising one or more of the instructions. The method of claim 63, wherein the at least one mitigation command includes at least one of a comprehensive quality metric value and a time duration in which the comprehensive quality metric value is less than a threshold value, and implementing the at least one mitigation command comprises: And determining a mitigation action based on the at least one of the aggregate quality metric value and the time duration. 64. The method of claim 63, wherein implementing the at least one mitigation instruction is based at least in part on a data stream importance metric for each of the at least one application data stream. 81. The method of claim 80, wherein the at least one mitigation instruction is implemented on the application data stream having the lowest data stream importance metric, and thereafter at least one other application data having the next lowest data stream importance metric in succession. The method that is implemented for streams. 64. The method of claim 63, wherein the at least one mitigation instruction is implemented on an increasing number of associated application data streams as the time duration of the implementation increases. 64. The method of claim 63, wherein the at least one mitigation instruction is implemented based on a time duration in which a quality metric value is below a threshold value. 64. The method of claim 63, wherein the level of implementation of the at least one mitigation instruction is based on a quality metric value.

Images