The invention relates to communications.
Quality of experience (QoE) is a measure of the overall value of a service provided from a user's perspective. QoE takes into consideration various factors that contribute to overall user value, such as suitableness, flexibility, mobility, security, cost, personalization and/or choice.
According to an aspect, there is provided the subject matter of the independent claims. Embodiments are defined in the dependent claims.
One or more examples of implementations are set forth in more detail in the accompanying drawings and the description below. Other features will be apparent from the description and drawings, and from the claims.
In the following, the invention will be described in greater detail by means of preferred embodiments with reference to the accompanying drawings, in which
The following embodiments are exemplary. Although the specification may refer to “an”, “one”, or “some” embodiment(s) in several locations, this does not necessarily mean that each such reference is to the same embodiment(s), or that the feature only applies to a single embodiment. Single features of different embodiments may also be combined to provide other embodiments. Furthermore, words “comprising” and “including” should be understood as not limiting the described embodiments to consist of only those features that have been mentioned and such embodiments may contain also features/structures that have not been specifically mentioned.
With increasing usage of internet-based, data driven over-the-top (OTT) applications (such as multimedia, social networking sites, e-commerce, web browsing, etc.) on mobile devices, mobile operators are trying to ensure good quality of experience (QoE) to users accessing native and OTT applications/services. Network side resources are not necessarily able to provide good QoE under any conditions including user mobility, application and traffic demand and network side congestion (regarding radio access and/or mobile backhaul). Under congestion, applications compete for the same resources. Thus in order to provide the best possible overall QoE, active traffic management and enforcement actions (e.g. bandwidth limitation, bearer prioritization, scheduling, etc.) are required. Accordingly, a network functionality is required for detecting and monitoring the applications and their QoE, for detecting and localizing congestion, for defining required actions that prevent/resolve degradation caused by inefficient resource allocation or congestion, and for enforcing/executing a selected action. In 3GPP mobile systems such as 3G, HSPA and/or LTE, policy and charging control (PCC) framework is a standardized solution for user or application differentiation and traffic management. However, the PCC framework (containing PCC/QoS rules governed by PCRF/PCEF) and the participating functionalities do not have the capability of managing QoE of the applications. The PCC framework does not directly define or manage how resources are allocated to the applications or bearers in case of congestion. The PCC rules are defined and enforced for each user/bearer/application/flow separately without considering that upon congestion the flows are competing for the same resources. This may lead to inefficient system utilization from customer satisfaction point of view where some applications are over-provisioned, using more resources than what is needed for good QoE, whereas others are under-allocated, receiving less than they need and having QoE degradations.
Let us now describe an embodiment of the invention for central QoE orchestration with reference to
Referring to
In an embodiment, the action to enforce QoE of the application session to meet the resource requirement, comprises a QoE management action such as a traffic management/QoE enforcement and/or a resource redistribution action.
In an embodiment, QoE management functionalities, their execution and orchestration are created and added to the system.
In an embodiment, an apparatus such as the central QoE orchestrator maintains correlated application information, QoE information and network status information for detecting QoE degradations, for detecting and localizing congestion, and for enforcing QoE of the applications. Multiple actions (such as traffic shaping, QCI/SPI modification, TCP optimization and overload management, traffic steering) may be triggered or controlled in order to change the way how the resources are redistributed, depending on what is supported by the system, whether there is congestion, and what is the congested resource. The central QoE orchestrator is able to operate multiple actions cooperatively towards the same goal, i.e. to provide good QoE for the applications. The central QoE orchestrator is also able to harmonize existing mechanisms so that they are not counteracting against QoE targets (i.e. the central QoE orchestrator is able to prevent existing network mechanisms from counteracting against the quality of experience QoE targets of the application session).
In an embodiment, holistic QoE management of native and OTT application sessions is performed. The QoE management includes real time QoE measurement, network status monitoring and context-based QoE enforcement via orchestrating and/or harmonizing end-to-end actions in the communications system.
In an embodiment, an apparatus such as the central QoE orchestrator QME, is provided in the core network for QoE management (see
An embodiment is applicable to the QoS/QoE management in various releases of 3GPP networks (including co-existence of multiple technologies). An embodiment is also applicable to non-3GPP access networks integrated via an access gateway (e.g. Wi-Fi via an S2a interface) into a 3GPP core network.
In an embodiment, the central QoE orchestrator performs real time holistic QoE management and enforcement for native and OTT applications in the communications system. The central QoE orchestrator may be deployed as an in-line, standalone entity within an LTE, WCDMA/HSPA(+), Wi-Fi and/or multi-RAT heterogeneous system. Alternatively an existing network element (such as PGW, PCEF and/or PCRF) may be configured to perform the central QoE orchestration functions. The central QoE orchestrator is able to maximize QoE and resource usage efficiency. Accordingly, the central QoE orchestrator monitors traffic to detect data flows and applications sessions, derives a resource requirement that guarantees the right level of QoE and performs QoE measurements to generate an insight to customer experience. Additionally, the central QoE orchestrator monitors the network status to create an up-to-date view on the status of the available network resources (transport and radio resources) to detect, if there is congestion in an end-to-end path, to localize it (e.g. identify and/or localize UE and the application session), and to detect the set of applications competing for the same resources. Depending on the network status, QoE, context of the applications/users and external input such as operator policies, the central QoE orchestrator may execute multiple actions to enforce QoE of the applications, i.e. manage the application traffic or QoS parameters of the bearers so that the QoE requirements of the application are met. Actions may be triggered within the central QoE orchestrator, such as traffic manipulation (e.g. shaping), or the central QoE orchestrator may trigger network side mechanisms via a standard interfaces. Multiple actions may be executed and orchestrated in parallel in order to provide good QoE for the applications. Existing network mechanisms that are not able to manage QoE, may also be harmonized with the QoE management, i.e. enabled/disabled by the central QoE orchestrator, so that they are not counteracting against the QoE targets.
The granularity of the QoE management and enforcement performed by the central QoE orchestrator may target individual application sessions (e.g. a specific video download) and/or aggregates of applications (e.g. calculating and enforcing a cumulative bandwidth for bulk downloads). Each application session may incorporate multiple data flows during its lifetime.
Let us now describe some embodiments with reference to
As illustrated in
The operation of the central QoE orchestrator depends on whether congestion has been detected 5001 for a given resource (e.g. cell, transport link, etc.) or not. If there is no congestion, the central QoE orchestrator manages 5002 QoE of the application sessions sharing the resource on an individual basis, i.e. there is no need to consider the mutual influences between the application sessions as they are not competing for the same resources. In that case, the central QoE orchestrator harmonizes the QoS parameters (e.g. bearer attributes) and PCC rules applying to the application session to make sure that they do not limit QoE of the application. If there is congestion, the central QoE orchestrator identifies 5003 the application sessions competing for the same shared resources, considers their requirements and executes actions to redistribute the resources, such that QoE is preserved whereas scarce resources are not wasted.
The central QoE orchestrator performs QoE enforcement and congestion control for the QoE management, enforcing the limits on the resource usage of individual applications or groups of applications to prevent over-provisioning (in case there is no congestion) and redistributing the congested resources to prevent under-allocation (in case there is congestion).
The central QoE orchestrator performs dynamic QoS management 5005 by promoting or demoting the priority of the radio bearer (QCI in LTE and SPI in 3G/HSPA). In case there is congestion on the radio resources, the dynamic QoS management may be used to redistribute radio interface resources on the bearer level. If there is no congestion, the dynamic QoS management is used to change default QoS parameters if the default QoS parameters do not provide good QoE for the applications actually used. In case there are multiple applications simultaneously run on the same bearer, the dynamic QoS management is used in combination with the QoE enforcement.
The central QoE orchestrator performs TCP overload management 5006 by reducing the load that TCP sources may generate. The TCP overload management may include actions such as ACK shaping, advertised window (AWND) manipulation, and/or scaling factor (SF) manipulation. The TCP overload management is activated if light overload or increasing load trend is detected, in order to provide a proactive load throttling mechanism for reducing load.
The central QoE orchestrator performs TCP optimization by optimizing TCP throughput and sender behaviour such that TCP segment pacing is adjusted to a shaping rate defined by the QoE enforcement.
The central QoE orchestrator performs traffic steering/Wi-Fi offload by redirecting UEs to alternative radio layers or RATs in order to balance the load on radio resources or reduce the load on the transport network (in case the alternative radio resource applies disjoint transport). Real time traffic steering (TS) 5007 is executed during ongoing active connections and data transfer (requires MP-TCP support from UE). Active mode TS 5007 is executed when there is an idle period in the data transfer but the radio bearer is still established. Idle mode TS 5008 is executed when UE detaches from the cell. The real time TS and/or active mode TS may be used to manage QoE, while the idle mode TS is harmonized with the QoE management to prevent that new connections are steered towards already congested resources (e.g. a cell) as a result of the idle mode TS.
The central QoE orchestrator performs connection termination 5009. In case there is severe congestion where it is not possible to serve applications competing for the same resources according to the QoE requirements, some of the sessions are throttled or terminated from the network side to ensure that others may be served well with the existing resources. Criteria for the connection termination may be based on various inputs and policies (application type, operator policy, subscriber/subscription, etc.). The decision whether the applications are to be throttled or terminated depends on the QoE target of the application session.
Thus the central QoE orchestrator performs application session, network and user context based QoE management including real time QoE measurement, network status monitoring and QoE enforcement via orchestrating and/or harmonizing end-to-end actions in the system. The central QoE orchestrator is able to enforce QoE of multiple applications simultaneously sending traffic on the same bearer. The central QoE orchestrator enforces QoE in case of radio side congestion, transport network congestion as well as in case there is no congestion in the system. The central QoE orchestrator aligns multiple actions based on a common QoE target, which eliminates potential conflicts among the alternative actions, prevents that actions are counter-acting each other and enables them to be executed in parallel, increasing the efficiency of the QoE enforcement. The central QoE orchestrator harmonizes existing mechanisms (such as the idle mode traffic steering) that have no QoE awareness or target with real time QoE management.
The central QoE orchestrator QME may be an entity running on or attached/integrated to an existing network element such as PGW, PCEF and/or PCRF, or it may be a standalone entity such as a QoS/QoE management entity QME. The central QoE orchestrator QME is provided with access to the user plane traffic at a network location where a high amount of sessions/connections/flows are aggregated, see
The central QoE orchestrator monitors user plane packets to detect new flows 7001 (e.g. TCP and UDP flows), and to identify 7005 the user and to identify 7006 the application session to which they belong, see
For new application sessions, the central QoE orchestrator defines 7004 the initial resource (e.g. bandwidth) requirement based on individual needs of the application (e.g. the media rate of a video session, download rate to maintain a download time target for web pages, etc.), per user/application policies and PCC/QoS rules (if applicable), and the context and condition (such as network, resource and congestion status at the location of the user, other already established bearers and ongoing sessions, etc.). The lowest of these requirements is proposed as the initial BW requirement to the QoE management process that handles the application session and enforces its QoE during its lifetime. The full context of the initial bandwidth selection is also transferred to the QoE management to enable overriding the selection (in case the initial BW requirement is not enough for proper QoE due to the PCC rule or congested resource), deciding if the default QoS settings need to be adapted to the application itself, and performing additional actions if needed (such as handling multiple applications within the same bearer). During the lifetime of the application session, new connections may be established and dynamically added to the session as well as they may be completed and removed from the session. The localization of the user (and thus of the session) follows the handover of UE in real time, i.e. the location mapping is maintained up-to-date every time. The QoE management is performed until each flow corresponding to the application is terminated 7010 and the application session itself is also finished 7009.
Herein, QoE management refers any action that is executed for ensuring good QoE, preventing QoE degradation or resolving degradation for the application sessions. These actions include QCI/SPI change, QoE enforcement, real time/active mode TS/Wi-Fi offload, for example.
Herein, QoE enforcement refers to a specific QoE management action that is able to redistribute the resources according to the application needs without engaging in additional C-plane signaling (such as signaling needed for the QCI change). For example, a shaper hierarchy may be used for the QoE enforcement.
The QoE enforcement is a continuous activity of the central QoE orchestrator. The QoE enforcement may be implemented using shapers that operate on the cumulative traffic of the application session of the given user, or (alternatively) on a set of applications grouped based on arbitrary policies (e.g. each application of a given type such as peer-to-peer, etc.). The shapers enforce a maximum rate for the corresponding traffic by delaying excess data in their packet buffer, where the rate is defined based on the QoE requirement of the application (or applications) managed by the shaper. The shapers require a certain amount of buffer space to store packets that may arrive in burst or those that are not eligible for transmission (in case throttling is needed). The shapers may also have attributes such as the burst size and burst rate that enable a higher transmission rate up to a given amount of data size (i.e., the burst size). The shapers may be organized into a hierarchy so that the packets transferred from a shaper are enqueued to the buffer of another shaper to create hierarchical bandwidth distributions (possibly using a dynamic hierarchical token bucket structure). The shapers may also implement resource borrowing among each other (in order to implement a work conserving way of operation) so that bandwidth not utilized by one application may be transferred to another shaper, temporarily increasing its allowed rate for maximum system efficiency. In case there is no congestion in the system, the QoE enforcement follows the bandwidth requirement of the applications, so that they are not able to receive (significantly) more resources than what they need, preventing over-allocations and also preparing the configuration of the enforcement for congested cases. Additionally, for those applications that may benefit from increased bandwidth (e.g. file download or upload, web browsing) the QoE enforcement increases the bandwidth allocation to create reasonable load on the available resources, that is, in order not to waste any opportunity to transfer data. In case there is congestion, the central QoE orchestrator identifies the set of applications competing for the same resources and the amount of available resources. The central QoE orchestrator may construct a shaper hierarchy with a cumulative shaper representing the congested resource, configured with the amount of available resources as the shaper's rate, and channelize the shapers of the application sessions sharing the resource into the common shaper. This hierarchy may efficiently redistribute the bandwidth of the shared resource in a QoE friendly way, where resources not utilized by the application session may be borrowed by other application sessions to keep the system utilization at maximum. Shapers are not only used to throttle traffic (i.e. backpressure flows compared to their native sending rate) but also to prioritize flows/applications against others. Therefore, in case of congestion, some of the shapers scheduling data for the congested resource may even increase their rate to enforce QoE of the corresponding application sessions (whereas others are throttling non-interactive or bulk traffic). The shaping action maintains system efficiency (i.e. fully utilize the available resources) such that the maximum amount of application sessions (or, depending on operator policies, the important ones) are served with good QoE. This may require redistributing the available resources according to the QoE requirements of the application session. The available resources are detected by the central QoE orchestrator by correlating throughput measurements and congestion/overload detection, that is, the measured throughput on the congested/overloaded resource equals to the actual available capacity. In order to support the QoE enforcement, additional parallel actions are triggered (see the details of harmonization later), such as dynamic QoS management (in case of radio congestion) or even connection termination (in case the applications have conflicting requirements that cannot be satisfied at the same time).
The QoE enforcement action cooperates with some of the TCP optimization and overload management actions to create a symbiotic interworking where buffer overflows in the shaper architecture are prevented via TCP ACK shaping or AWND manipulation.
As described above, the QCI/SPI change may be operated in parallel to a basic QoE enforcement action, i.e. it relies on the resource sharing of the radio packet scheduler in a complementary manner to the shaping performed by the central QoE orchestrator itself. Alternatively, to prevent too frequent QCI/SPI changes (i.e. to prevent control plane overload) the central QoE orchestrator may override the QoS profile of the users, natively (i.e. already during the initial attach) mapping each and every bearer (non GBR bearer) established to the internet APN to the same QCI/SPI class. This approach equalizes the priority of the bearers on the radio interface and relies on the QoE enforcement actions to handle QoE of the applications via shaping, eliminating the need for the dynamic QoS management. This may be a permanent rule or an adaptive one, e.g. applied only to a given resource or set of resources for which overload is detected. This measure is limited to newly established bearers, so there is a ramp up period until the dominant fraction of the bearers converge to the same QoS class. This eliminates the control plane overhead that the dynamic QoS management imposes on the affected elements. Alternatively, the same QCI/SPI may be used by default for every non-GBR bearer within the system and to achieve the QoS/QoE targets and enforce the PCC rules through the operation of the QoE management. This may even increase the efficiency of the QoE enforcement action in case it is performed in the core network as there is no additional resource sharing mechanism (the QCI based redistribution) to be considered (or even compensated) by the shapers.
As the QCI/SPI change only aligns how the resources are assigned to radio bearers on the air interface, in case there are multiple applications within the same bearer 9004, in-bearer shaping is to be performed 9005 by the QoE enforcement to decide how the bearer's resources are further shared by the applications. As the QCI/SPI effectively defines the resource sharing of the applications in case of radio congestion, this action is not necessarily usable for handling transport congestion.
The TCP optimization may be executed without terminating the TCP connection (i.e. without the central QoE orchestrator beginning a TCP proxy).
The connection termination action involves discarding each packet in a given flow and/or sending a TCP RST packet in both directions (for TCP connections).
The central QoE orchestrator performs orchestration and harmonization of actions as illustrated in
In response to the load increasing, soft load prevention mechanisms referred to as the TCP overload management actions are activated. The trigger of this action is the detection of overload by the central QoE orchestrator over a given shared resource. These actions target only those flows that are not sensitive of reduced throughput or that belong to applications that are served with low priority or with best effort. In each case, the actions themselves are executed on the targeted flows individually. Similarly to the TCP optimization actions, the soft overload prevention mechanisms also utilize the native TCP mechanisms to implement network insight assisted TCP operation. The ACK shaping and AWND manipulation 1203 may also be triggered as mechanisms to selectively reduce the rate of certain flows thus freeing resources that may be scheduled for other flows/application sessions or resolving congestion altogether. The SF manipulation 1203 is a complementary lightweight overload management action that removes the window scaling factor present in the SYN/SYN-ACK segments in case window scaling is negotiated during the TCP handshake. As a result, the TCP source and receiver both infer that the peer entity is not capable (or willing) to handle window scaling as such and they use the legacy advertised window size with 64 KB upper limit. The SF action is extremely lightweight as it only needs to act on the initial handshake packets and does not need to follow the connection afterwards.
The TCP overload management actions may be switched on depending on the load and applied selectively to new flows (this is required for the SF manipulation but may apply to the AWND management or ACK shaping as well). As existing flows are terminated and new ones are established, the flow population gradually becomes subject to the overload management action.
The TCP overload management actions interoperate natively with the QoE enforcement actions and may be triggered simultaneously with the dynamic QoS management 1204 as well but not each time for the same flows. Triggering the actions for flows that may become subject to an TS/Wi-Fi offload action 1205 is possible but not efficient as the flows may be terminated 1206 and re-established after the TS/Wi-Fi offload completes (as the device may even receive a new IP address).
The orchestration of the dynamic QoS management may be triggered to influence the share of the radio resources among bearers in case there is radio side congestion. The action is applicable, for example, in case of overload or light congestion when there are enough resources on the radio interface but the default bearer configuration causes QoE degradation. In these cases reconfiguring only a few bearers may solve or prevent the QoE degradations. This mechanism is an auxiliary tool of the QoE management that may be triggered simultaneously with the following other actions: QoE enforcement (yes), TCP overload management and TCP optimization (no, that is, connections subject of QoS management actions leading to their positive discrimination are not to be subject to TCP overload management; if resolving the congestion requires that the rate of these flows is reduced, TCP optimisation may be used as the auxiliary mechanism of a demotion). Triggering the action implies that QoE of the application may be enforced within the current cell/RAT context, thus making the corresponding UE/bearer subject to TS/Wi-Fi offload at the same time is not reasonable.
The idle mode traffic steering/Wi-Fi offload 1207 redirects users to alternative radio layers to balance load on radio or reduce load on transport (in case the alternative radio applies disjoint transport). The real time or active mode TS/Wi-Fi offload actions may be triggered for individual UEs. Thus they provide dedicated actions whereas the idle mode TS operates on camping UEs thus it is a non-deterministic and non-real time action. The multiple variants of the TS/Wi-Fi offload may co-exist in the system.
The real time TS may execute traffic steering or offload while UE has active connections and ongoing data transfer. The smooth execution of the real time TS requires that UE supports MP-TCP, i.e. it is able to virtually split the TCP connection (end-to-end UE—server communication) over multiple RATs and receive data simultaneously via multiple RATs in the same connection. In that case, the MP-TCP connection may be migrated from one RAT to another by first switching on the target RAT and then switching off the source RAT. The real time TS may be triggered per UE or per a set of UEs, to control radio or transport congestion by being able to utilize the alternative RAT/transport resources.
The active mode traffic steering triggers the TS action in case the radio bearer of UE is still established but the applications are currently idle, i.e. there is no ongoing data transfer. The applicability is the same as that of the real time TS, however there is no need for UE side support (on the other hand, the active mode traffic steering has higher latency and more intrusive as the connectivity is fully broken until the re-establishment is completed).
The idle mode traffic steering impacts the RAT/cell selection of camping UEs, i.e. those that have no established radio bearers. This is to balance the load among RATs according to policy/load/radio channel measurement based criteria. Thus the idle mode traffic steering is not applicable in case of congestion, it is non-deterministic and it has to be harmonized with the QoE management to prevent counter-actions. The central QoE orchestrator prohibits TS or Wi-Fi offload to cell/Wi-Fi AP for which overload is detected or to those resources that are in permanent overload/congestion.
The idle mode traffic steering is harmonized with the QoE management.
In an embodiment, a QoE management entity QME monitors data traffic to detect the applications sessions, derive their resource requirement and perform QoE measurements. Additionally, QME monitors the network status to detect and localize congestion in the end-to-end path and detect the set of applications competing for the same resources. Using this correlated insight, QME initiates proactive or reactive actions to prevent or resolve QoE degradations in the network. QME aligns the QoS profile of the bearers or applications with their resource requirement even in case there is no congestion or QoE degradation, to keep the resource distribution scheme in the system close to optimal from QoE point of view. This ensures that in case congestion does happen, the degree of interaction required for QoE enforcement remains limited, large transients may be avoided and the applications receive as smooth and predictable service as possible even in case their allocated resources are decreased. QME interfaces with the PCC system to utilize the existing PCRF/PCEF functions for executing the actions, and also to harmonize its decisions with the PCC/QoS rules.
In an embodiment, a standardized Gxx interface is used to integrate QME with PCRF/PCEF based enforcement mechanisms already deployed in the mobile system. QME interfaces with the existing PCC infrastructure in order to harmonize its operation with the existing policies and also to implement non-existing QoE driven dynamic traffic management actions partly reusing the existing network functionalities through interfaces such as Gxx and optionally Sd. The Gxx interface may be used a) for obtaining information about the PCC and QoS rules being provisioned by the PCRF in the PCEF, and b) for pushing additional enforcement actions to PCEF through PCRF. The Gxx interface is utilized by masking the enforcement actions as UE initiated QoS modification requests. This makes the integration between QME and PCRF a vendor independent solution in case the PCRF implements the standardized Gxx interface. QME may also implement the Sd interface to provide additional QoE/application specific triggers towards PCRF. This enables shifting logic into an advanced PCRF implementation that is able to act upon application specific events, QoE degradation etc., and receive the required information/triggers from QME.
QME monitors user plane packets in order to detect applications, measure their QoE, collect application metadata and recognize user actions. When a new application session starts, QME detects its resource requirements and evaluates whether the PCC rules limit the traffic to the extent that prevents good QoE in the first place. In case the PCC rules are a limiting factor (e.g. MBR of the bearer established by UE is lower than the bandwidth requirement of the application session), QME may terminate the session or trigger content adaptation. Otherwise, QME may dynamically select a QoS profile that suits the need of the applications best, to harmonize the network mechanism with the applications. User plane packet monitoring is also an efficient and sensitive way to detect and localize network side congestion. In case there is congestion, QME measures the available resources in the congested network segment and identifies the impacted users, i.e. those that are competing for the same bottleneck resources. Based on the active application sessions, their resource needs, operator policies and priorities, subscription profiles, etc., QME defines how the resources are to be redistributed, i.e. what are the resources that individual application sessions or set of applications receive. The granularity of the application differentiation and resource allocation may target individual application sessions (e.g. a specific video download) and/or aggregates of applications (e.g. calculating and enforcing a cumulative bandwidth for bulk downloads). QME decides about the actions that enforce the proper treatment (e.g. prioritize important traffic, shape down non-interactive background traffic, etc.) in order to provide good QoE for the maximum number of users (or, in case of heavy congestion, to the users that have the highest priority from the operator's point of view). QME uses the Gxx interface in order to send commands (e.g. QCI change/bearer modification, bandwidth limitation, etc.) to PCRF which propagates them further to PCEF. The Gxx interface is also used in QME to get information on the enforcement performed by PCEF based on rules provisioned by PCRF itself.
The Gxx interface has two variants, depending on whether it is terminated by SGW or by another trusted AGW in the network. The SGW variant is referred to as the Gxc interface and the AGW variant is referred to as the Gxa interface. In case of QME integration, the usage of the Gxa or Gxc interfaces depends on the deployment and implementation of QME.
QME may be an in-line network element directly obtaining its user, application and QoE insight from user plane packet monitoring in the core network (see
When PMIP is used over the S5/S8 interfaces, Gxc is used between PCRF and BBERF located in the SGW to enforce QoS in the radio access network. In this case, QME may be located between PCRF and SGW acting as BBERF towards PCRF and acting as PCRF towards SGW.
Alternatively, QME may also be integrated with SGW itself, in which case the integration with PCRF uses the Gxc interface. This is possible both when GTP and when lo PMIP is used over S5.
In an embodiment, a QoE management action may be masked as a terminal device initiated QoS modification request, in order to enforce QoE of the application session. Thus QME may be able to trigger QoS modification masked as if it was originated from UE. In that case, controlling PCEF requires that QME submits its commands as UE-initiated QoS modification requests to PCRF, wherein the QoS modification requests are implemented as credit control requests (CCR) that are either add new rules or modify or delete existing ones. CCR includes the definition of IP flows which are in the scope of the enforcement, along with the corresponding QoS options. This requires the creation of CCRs with the following attributes: CC-Request-Type AVP is set to “UPDATE_REQUEST”; event-trigger AVP is set to “RESOURCE_MODIFICATION_REQUEST”; packet-filter-operation AVP is set to “ADDITION”, “MODIFICATION” or “DELETION”; packet-filter-information AVP defines the traffic (via IP filters) to which the enforcement applies; QoS-information AVP is set to indicate the requested QoS.
The packet filter information defines the granularity of the enforcement that is available to QME. The packet filters may be created per IP flow, which includes the protocol, the source and destination IP addresses (optionally masked) and source and destination port numbers (or ranges). This information may be obtained and filled by QME based its monitoring of the user plane packet headers.
The possible enforcement actions available for QME are defined by the possible set of supported QoS information. The QoS information may include one or more of the following: QCI of the corresponding bearer; setting guaranteed data rate in DL or in UL; setting maximum data rate in DL or in UL; additionally, it is possible to set the minimum required bandwidth which is used by PCRF to automatically derive the authorized guaranteed data rate and the maximum authorized data rate parameters.
The Gxx interface is also used to obtain information about the QoS rules that PCRF manages independently from QME. PCRF may send the QoS rules in a re-authentication request (RAR) message on the Gxx interface within either the QoS-rule-install AVP or the QoS-rule-remove AVP. QME replies with a re-authentication answer (RAA) accepting activation or removal of the QoS rule.
An alternative way to obtain QoS rules managed independently by PCRF is to deploy a diameter routing agent (DRA) on the Gx interface that forwards the Gx traffic to QME. This provides an insight to the QoS rules transparently to PCRF. In that case, the Gxx interface is used only as a unidirectional interface to propagate the QoS rules to the PCRF.
Optionally, the Sd interface may also be used between PCRF and QME, wherein QME also acts as TDF. QME may receive ADC rules directly from PCRF. These rules indicate the set of applications that may be differentiated using dedicated PCC rules in the existing PCEF and require information to be reported by QME. QME may perform only standard TDF reporting functionality (e.g. identify application sessions, detect and indicate the start and end of application sessions) or it may provide an extended non-standardized set of data (e.g. QoE of the applications, congestion indication, etc.). Receiving the extended measurements requires either Sd interface standardization or proprietary support from PCRF.
An embodiment provides an apparatus comprising at least one processor and at least one memory including a computer program code, wherein the at least one memory and the computer program code are configured, with the at least one processor, to cause the apparatus to carry out the procedures of the above-described network element or the network node. The at least one processor, the at least one memory, and the computer program code may thus be considered as an embodiment of means for executing the above-described procedures of the network element or the network node.
The processing circuitry 10 may comprise the circuitries 12 to 18 as sub-circuitries, or they may be considered as computer program modules executed by the same physical processing circuitry. The memory 20 may store one or more computer program products 24 comprising program instructions that specify the operation of the circuitries 12 to 18. The memory 20 may fur-their store a database 26 comprising definitions for central QoE orchestration, for example. The apparatus may further comprise a communication interface (not shown in
Another embodiment provides an apparatus comprising at least one processor and at least one memory including a computer program code, wherein the at least one memory and the computer program code are configured, with the at least one processor, to cause the apparatus to carry out the procedures of the above-described network element or the network node. The at least one processor, the at least one memory, and the computer program code may thus be considered as an embodiment of means for executing the above-described procedures of the network element or the network node.
The processing circuitry 10 may comprise the circuitries 12B to 18B as sub-circuitries, or they may be considered as computer program modules executed by the same physical processing circuitry. The memory 20 may store one or more computer program products 24 comprising program instructions that specify the operation of the circuitries 12B to 18B. The memory 20 may fur-their store a database 26 comprising definitions for central QoE orchestration, for example. The apparatus may further comprise a communication interface (not shown in
As used in this application, the term ‘circuitry’ refers to all of the following: (a) hardware-only circuit implementations such as implementations in only analog and/or digital circuitry; (b) combinations of circuits and software and/or firmware, such as (as applicable): (i) a combination of processor(s) or processor cores; or (ii) portions of processor(s)/software including digital signal processor(s), software, and at least one memory that work together to cause an apparatus to perform specific functions; and (c) circuits, such as a microprocessor(s) or a portion of a microprocessor(s), that require software or firmware for operation, even if the software or firmware is not physically present.
This definition of ‘circuitry’ applies to all uses of this term in this application. As a further example, as used in this application, the term “circuitry” would also cover an implementation of merely a processor (or multiple processors) or portion of a processor, e.g. one core of a multi-core processor, and its (or their) accompanying software and/or firmware. The term “circuitry” would also cover, for example and if applicable to the particular element, a baseband integrated circuit, an application-specific integrated circuit (ASIC), and/or a field-programmable grid array (FPGA) circuit for the apparatus according to an embodiment of the invention.
The processes or methods described above in connection with
The present invention is applicable to cellular or mobile communication systems defined above but also to other suitable communication systems. The protocols used, the specifications of cellular communication systems, their network elements, and terminal devices develop rapidly. Such development may require extra changes to the described embodiments. Therefore, all words and expressions should be interpreted broadly and they are intended to illustrate, not to restrict, the embodiment.
It will be obvious to a person skilled in the art that, as the technology advances, the inventive concept can be implemented in various ways. The invention and its embodiments are not limited to the examples described above but may vary within the scope of the claims.
ACK acknowledgement
AP access point
APN access point name
AWND advertised window
BS, BTS base station
BW bandwidth
CoDel controlled delay
DNS domain name system
DSCP differentiated services code point
eNB evolved node-B
GTP general packet radio service tunnelling protocol
HSPA high speed packet access
HSS home subscriber service
HTTP hypertext transfer protocol
IMSI international mobile subscriber identity
IP internet protocol
LTE long term evolution
MME mobility management entity
MP-TCP multipath TCP
OTT over the top
PCC policy and charging control
QCI QoS class index
QoE quality of experience
QoS quality of service
RAT radio access technology
RED random early detection
RFSP RAT/frequency selection priority
SAE-GW service architecture evolution gateway
SF scaling factor
SPI scheduling priority index
SSL secure socket layer
TCP transmission control protocol
TEID tunnel endpoint identity
TLS transport layer security
TS traffic steering
UDP user datagram protocol
UE user equipment
WCDMA wideband code division multiple access
PGW PDN gateway
PDN packet data network
PCEF policy and charging enforcement function
PCRF policy and charging rules function
Wi-Fi wireless fidelity
RADIUS remote authentication dial in user service
RAN radio access network
AVP attribute-value pair
KPI key performance indicator
RNC radio network controller
RAGS resource and admission control subsystem
OFCS off-line charging system
ANDSF access network discovery and selection function
SADM serve-at-once device manager
WAM Wi-Fi activation manager
WSM Wi-Fi system/service manager
SGW serving gateway
Filing Document | Filing Date | Country | Kind |
---|---|---|---|
PCT/EP2014/077146 | 12/10/2014 | WO | 00 |