Patent Grant
9722929
Exemplifying embodiments presented herein are directed towards a Radio Access Node (RAN) and/or a Core Network (CN) node and a corresponding method in the RAN and/or CN node, which RAN and/or CN node is configured to operatively handle at least one of Congestion, User Plane Congestion Control (UPCON), throughput targets, Quality of Service (QoS), quality of experience (QoE) for a user of a radio terminal at congestion situations.
Packet data traffic is growing very quickly in mobile operator networks, in many cases it grows much more quickly than the rate at which the operator can expand its network capacity. This leads to more frequent occurrences of network congestion when the offered traffic is higher than what the RAN (radio access network) is able to fulfill. Also, new services appear often, which may lead to a situation when a new QoE requirement has to be introduced into the network quickly. In this situation, operators need efficient and flexible tools by which they can control how the bottleneck RAN capacity can be best shared so that they can maximize the Quality of Experience of their users.
The current 3GPP QoS is based on the bearer mechanism, e.g. as described in 3GPP TS 23.401 section 4.7.2. Traffic that requires differentiated QoS treatment is classified into bearers. For each bearer, the QoS Class Identifier (QCI) parameter determines the basic QoS treatment. A few other parameters, such as the Maximum Bitrate (MBR), Guaranteed Bitrate (GBR), UE or Access Point Name (APN) specific Aggregate Maximum Bitrate (AMBR) and Allocation and Retention Priority (ARP) parameters can further influence the quality of service applied to the bearer traffic.
The bearer based QoS has some limitations which has so far prevented its wide adoption. One limitation is that for 3G, the network based QoS mechanism requires the release-7 Network Initiated Dedicated Bearer (NIDB) support, which has so far not yet materialized in terminal equipment. Even though new NIDB enable terminals may come out, it may take a few years before they reach a sufficiently high penetration for operators to make efficient use of the feature.
As another limitation, the currently defined QoS parameters do not provide a predictable QoE in congestion situations. The GBR and MBR parameters only apply to GBR bearers while most of the traffic currently goes over non-GBR bearers. The AMBR parameter only allows enforcement of a maximum over several bearers which is not flexible enough to specify congestion behavior.
Moreover, in the context of the 3GPP UPCON (User plane congestion management) work item, a new type of solution has recently been put forward which utilizes congestion feedback from the CN to the RAN. This has e.g. been documented in 3GPP TR 23.705 version 0.3 section 6.1. When RAN indicates congestion to the CN, the CN can take actions to mitigate the congestion, e.g. such as limiting some classes of traffic. Congestion feedback as proposed so far is based on the measurement of the RAN load, i.e., resource utilization, and providing congestion feedback when the average load over a period of time exceeds a pre-defined threshold level. A main characteristic of such load-based congestion feedbacks is that it cannot differentiate in the congestion status once RAN is fully loaded. Load-based congestion feedback is illustrated in
Possible examples for load-based congestion feedback can be:
As already mentioned in the “Background” section, the bearer based QoS has some limitations, which has so far prevented its wide adoption, e.g. network based QoS mechanism requires the release-7 Network Initiated Dedicated Bearer (NIDB) support, which has so far not yet materialized in terminal equipment. Another limitation is that the currently defined QoS parameters do not provide a predictable QoE in congestion situations. The GBR and MBR parameters only apply to GBR bearers, while most of the traffic currently goes over non-GBR bearers. The Aggregate Maximum Bitrate (AMBR) parameter only allows enforcement of a maximum over several bearers, which is not flexible enough to specify congestion behavior.
Moreover, using a load-based congestion feedback from the RAN to the CN causes a number of disadvantages. Load-based congestion feedback considers all packets to be equal when it comes to congestion reporting. Even though two different packets may be part of traffic flows that represent highly different values to the user and the operator, they have equal role when it comes to load-based congestion feedback reporting. Load-based congestion feedback ignores the quality of experience observed by the user for a given traffic flow, and ignores the quality of service requirements that the operator sets.
There are a number of consequences of this simplistic congestion feedback reporting, of which some are summarized in the bullets below.
Some aspects of the present solution suggest the following concept:
Some embodiments of the present solution are directed to a method in a CN node for handling QoS targets for traffic flows between the CN node and a RAN node and/or traffic flows between the RAN node and a radio terminal served by the RAN node, wherein the method comprises:
Some other embodiments of the present solution are directed to a CN node for handling QoS targets for traffic flows between the CN node and a RAN node and/or traffic flows between the RAN node and a radio terminal served by the RAN node, wherein a processing circuitry 210 is configured to operatively:
A traffic flow may e.g. be comprised by a bearer established between the CN node and a RAN node and/or a bearer (e.g. a radio bearer, e.g. such as a Radio Access Bearer (RAB) or similar) established between the RAN node and a radio terminal, e.g. such as a UE or similar.
A radio terminal may e.g. be a mobile station (MS) or a user equipment unit (UE) or similar, e.g. such as mobile telephones also known as “cellular” telephones, and laptops with wireless capability, and thus can be, for example, portable, pocket, hand-held, computer-comprised, or car-mounted mobile devices which communicate voice and/or data with radio access network.
A QoS target may be one or more simple QoS targets, e.g. any information indicating one ore more of;
a bandwidth target,
a throughput target (e.g. bit rate or similar),
a Bit Error Rate (BER) or a Block Error Rate (BLER) target,
a loss of data target (e.g. the percentage of lost data),
a delay or a latency or jitter (variation in latency) target,
a retransmission (e.g. number of retransmissions) or a retransmission frequency target,
Embodiments of the present solution may use QoS targets in the form of congestion level dependent QoS targets, as will be described in more detail below. A congestion level dependent QoS target may e.g. be based on one or more of the more simpler QoS targets mentioned above.
In the CN (Continued)
(Receiving information indicating a QoS based congestion from a RAN node in a CN node)
Some embodiments of the present solution are directed to a method in a CN node for handling QoS targets for traffic flows between the RAN node and a CN node and/or traffic flows between the RAN node and a radio terminal served by the RAN node, wherein the method comprises:
It is preferred that the method also comprises sending the load instructions to the RAN node, so as to enable the RAN node to reduce or adapt the QoS based congestion in the RAN node.
Some other embodiments of the present solution are directed to a CN node for handling QoS targets for traffic flows between the CN node and a RAN node and/or traffic flows between the RAN node and a radio terminal served by the RAN node, wherein a processing circuitry 210 is configured to operatively:
It is preferred that the processing circuitry 210 is also configured to operatively send the load instructions to the RAN node, so as to enable the RAN node to reduce or adapt the QoS based congestion in the RAN node.
In the RAN
(Receiving or pre-configure traffic classes and QoS targets—e.g. congestion level dependent QoS targets—and using the traffic classes and QoS targets)
Some other embodiments of the present solution are directed to a method in a RAN node for handling QoS targets for traffic flows between the RAN node and a CN node and/or traffic flows between the RAN node and a radio terminal served by the RAN node, wherein the method comprises:
It is preferred that the method also comprises detecting that at least one determined QoS target can not be satisfied at the obtained congestion level, and sending congestion information to the CN node indicating a QoS based congestion in the RAN node, i.e. a congestion based on the failure of satisfying a QoS target at a congestion in the RAN node.
Some other embodiments of the present solution are directed to a RAN node for handling QoS targets for traffic flows between the RAN node and a CN node, and/or traffic flows between the RAN node and a radio terminal served by the RAN node, wherein a processing circuitry 110 is configured to operatively:
It is preferred that the processing circuitry 110 is also configured to operatively detect that at least one determined QoS target can not be satisfied at the obtained congestion level, and to send congestion information to the CN node indicating a QoS based congestion in the RAN node, i.e. a congestion based on the failure of satisfying a QoS target at a congestion in the RAN node.
Traffic classes and QoS targets may both be received by the RAN node; or traffic classes may be pre-configured in the RAN node while QoS targets are received; or traffic classes may be received by the RAN node while QoS targets are pre-configured in the RAN node.
The congestion information may e.g. indicate a congestion level in the form of exhaustion of available bandwidth or similar provided by the RAN node, or exhaustion of the available throughput or similar provided by the RAN node.
The traffic class for a traffic flow may be determined and/or obtained based on e.g. bearer association for the traffic flow (e.g. using QCI) and/or packet marking of the packets in the traffic flow (e.g. made by a CN node) as will be described in more detail below.
Some embodiments described herein may be summarised more explicitly in the following manner:
One embodiment is directed to a method in a core network, CN, node for handling quality of service, QoS, targets for traffic flows between a radio access network, RAN, node and a radio terminal served by the RAN node, wherein the method comprises: obtaining a number of traffic classes into which the traffic flows can be classified, and defining QoS targets for each obtained traffic class for at least two congestion levels, and providing the traffic classes with the associated QoS targets and congestion levels to the RAN node so as to provide congestion level dependent QoS targets for the traffic classes to the RAN node.
Another embodiment is directed to a core network, CN, node for handling quality of service, QoS, targets for traffic flows between a radio access network, RAN, node and a radio terminal served by the RAN node, wherein a processing circuitry is configured to operatively: obtain a number of traffic classes into which the traffic flows can be classified, and define QoS targets for each obtained traffic class for at least two congestion levels, and provide the traffic classes with the associated QoS targets and congestion levels to the RAN node so as to provide congestion level dependent QoS targets for the traffic classes to the RAN node.
Another embodiment is directed to a method in a radio access network, RAN, node for handling quality of service, QoS, targets for traffic flows between the RAN, node and a wireless terminal (300) served by the RAN node, wherein the method comprises: defining traffic classes into which the traffic flows can be classified and QoS targets for at least two congestion levels for each traffic class so as to provide congestion level dependent QoS targets for the traffic classes in the RAN node, and classifying each traffic flow received by the RAN node into a traffic class, and obtaining congestion information indicating a congestion level in the RAN node and determining a QoS target for each traffic class based on the obtained congestion level and the congestion level dependent QoS targets.
Another embodiment is directed to a radio access network, RAN, node for handling quality of service, QoS, targets for traffic flows between the RAN, node and a wireless terminal served by the RAN node, wherein a processing circuitry is configured to operatively: define traffic classes into which the traffic flows can be classified and QoS targets for at least two congestion levels for each traffic class so as to provide congestion level dependent QoS targets for the traffic classes in the RAN node, and classify each traffic flow received by the RAN node into a traffic class, and obtain congestion information indicating a congestion level in the RAN node and determining a QoS target for each traffic class based on the obtained congestion level and the congestion level dependent QoS targets
In the following description, for purposes of explanation and not limitation, specific details are set forth, such as particular components, elements, techniques, etc. in order to provide a thorough understanding of the exemplifying embodiments. However, it will be apparent to one skilled in the art that the exemplifying embodiments may be practiced in other manners that depart from these specific details. In other instances, detailed descriptions of well-known methods and elements are omitted so as not to obscure the description of the example embodiments. The terminology used herein is for the purpose of describing the example embodiments and is not intended to limit the embodiments presented herein.
It should be appreciated that although
Thus,
The eNodeB 110 is a radio access node that interfaces wirelessly with a radio terminal, which is denoted User Equipment (UE) in LTE. In fact, the eNodeBs of the system forms the radio access network E-UTRAN for LTE.
The SGW is a core network node that routes and forwards user data packets, while also acting as the mobility anchor for the user plane during inter-eNB handovers and as the anchor for mobility between LTE and other 3GPP technologies (terminating S4 interface and relaying the traffic between 2G/3G systems and PDN GW). For idle state UEs, the SGW terminates the DL data path and triggers paging when DL data arrives for the UE. It manages and stores UE contexts, e.g. parameters of the IP bearer service, network internal routing information. It also performs replication of the user traffic in case of lawful interception.
The MME is a core network node that is a key control-node for the LTE access-network. It is responsible for idle mode UE tracking and paging procedure including retransmissions. It is involved in the bearer activation/deactivation process and is also responsible for choosing the SGW for a UE at the initial attach and at time of intra-LTE handover involving Core Network (CN) node relocation. It is responsible for authenticating the user (by interacting with the HSS). The Non-Access Stratum (NAS) signaling terminates at the MME and it is also responsible for generation and allocation of temporary identities to UEs. It checks the authorization of the UE to camp on the service provider's Public Land Mobile Network (PLMN) and enforces UE roaming restrictions. The MME is the termination point in the network for ciphering/integrity protection for NAS signaling and handles the security key management. Lawful interception of signaling is also supported by the MME. The MME also provides the control plane function for mobility between LTE and 2G/3G access networks with the S3 interface terminating at the MME from the SGSN. The MME also terminates the S6a interface towards the home HSS for roaming UEs
The PGW 210 is a core network node that provides connectivity to the UE to external packet data networks 250 by being the point of exit and entry of traffic for the UE. A UE may have simultaneous connectivity with more than one PGW for accessing multiple PDNs. Typically the PGW performs one ore more of; policy enforcement, packet filtering for each user, charging support, lawful Interception and packet screening. Another key role of the PGW is to act as the anchor for mobility between 3GPP and non-3GPP technologies such as WiMAX and 3GPP2 (CDMA 1× and EvDO).
The PCRF is a core network node that determines policy rules in real-time with respect to the radio terminals of the system. This may e.g. include aggregating information in real-time to and from the core network and operational support systems etc of the system so as to support the creation of rules and/or automatically making policy decisions for user radio terminals currently active in the system based on such rules or similar. The PCRF provides the PGW with such rules and/or policies or similar to be used by the acting as a Policy and Charging Enforcement Function (PCEF).
The GGSN 220 is a core network node that is a main component of the GPRS network. The GGSN is responsible for the interworking between the GPRS network and external packet data networks 250, like the Internet and X.25 networks. The GGSN is the anchor point that enables the mobility of the user terminal in the GPRS/UMTS networks and it may be seen as the GPRS equivalent to the Home Agent in Mobile IP. It maintains routing necessary to tunnel the Protocol Data Units (PDUs) to the SGSN that services a particular Mobile Station (MS). The GGSN converts the GPRS packets coming from the SGSN into the appropriate packet data protocol (PDP) format (e.g., IP or X.25) and sends them out on the corresponding packet data network. In the other direction, PDP addresses of incoming data packets are converted to the GSM address of the destination user. The readdressed packets are sent to the responsible SGSN. The GGSN is responsible for IP address assignment and is the default router for the connected user equipment (UE). The GGSN also performs authentication and charging functions. Other functions include subscriber screening, IP Pool management and address mapping, QoS and PDP context enforcement.
The SGSN is a core network node that is responsible for the delivery of data packets from and to the radio terminals such as mobile stations within its geographical service area. Its tasks include packet routing and transfer, mobility management (attach/detach and location management), logical link management, and authentication and charging functions. The location register of the SGSN stores location information (e.g., current cell, current Visitor Location Register (VLR)) and user profiles (e.g., International Mobile Station Identity (IMSI), address(es) used in the packet data network) of all GPRS users registered with this SGSN.
The RNC 124 is a radio access network node in the UMTS radio access network (UTRAN) and is responsible for controlling the NodeBs that are connected to it. The NodeB 122 is also a radio access node. The RNC carries out radio resource management, some of the mobility management functions and is the point where encryption is done before user data is sent to and from the mobile. The RNC connects to a Circuit Switched Core Network through Media Gateway (MGW) and to the SGSN in the Packet Switched Core Network.
The BSC 134 is a radio access network node in the GSM Radio Access Network (GERAN) and is responsible for controlling the BTSs that are connected to it. The BTS 132 is also a radio access network node. The BSC carries out radio resource management and some of the mobility management functions.
As can be seen in
To increase the level of operator control over the RAN congestion handling, it is proposed to define congestion level dependent QoS targets for a number of congestion levels. Note that the number of congestion levels can be arbitrarily increased for higher accuracy and control. The QoS targets apply to a traffic flow classified into a traffic class (TC), e.g. with a given combination of packet marking and bearer QCI as will be describe in more detail below. The traffic class determines the QoS treatment at each congestion level. The operator may e.g. use a O&M function of the network to configure the QoS parameters that determine the congestion level dependent QoS targets at different congestion levels for a given traffic class (TC).
It can be noted that embodiments of the present solution are typically described herein with reference to a Core Network (CN) node and a Radio Access Network (RAN) node. This should be understood such that any RAN node mentioned herein can be used in said embodiments together with any CN node mentioned herein, unless the context in which the nodes are mentioned clearly contradicts this.
In
For each user/radio terminal, the following traffic classes (TCs) are used:
For easier representation, the big dots corresponding to the congestion level dependent throughput targets are connected by a line. However, it is the dots that represent the actual congestion level dependent throughput targets, which may be pre-defined in the RAN or communicated to the RAN and used in the resource sharing control.
Note that the throughput target for a lower congestion level of a given traffic class (TC) is normally higher than the throughput target for a higher congestion level, since we expect more throughput to be available with lower congestion.
This representation—as exemplified in
The number of TCs with respect to the different applications/services and subscriptions can of course be increased to a higher granularity, depending on the operator's need for differentiation. The number and/or nature of the TCs may e.g. be determined by means of empirical investigations. In other occasions the number and character of the TCs may be the same as one of the sets of traffic classes determined in the 3GPP specifications.
Traffic Classification
Classifying a traffic flow into a suitable traffic class (TC) in a set of given traffic classes (TCs) may e.g. be done based on one of or a combination of SPI (shallow packet inspection) and DPI (deep packet inspection). SPI may e.g. involve checking the packet header fields, e.g. one or more of: IP source and/or destination addresses, TCP/UDP source and/or destination ports, protocol id field, IPsec fields, VPN tunneling fields, or additional header fields. DPI may e.g. involve checking the packet data contents, e.g. one ore more of: HTTP headers, packet lengths and timing characteristics, and so on. The SPI and DPI functions can be used to identify the application/service that the given packet falls into, and thus possibly also the traffic class to which the traffic flow comprising the packet should belong.
This may be combined with information about the user's subscription that may be available in the CN.
Traffic flows that have the same or similar characteristics may be associated with the same traffic class. For example, traffic flows with the same source address may in some occasions be associated with the same traffic class.
Classifying a traffic flow into a suitable traffic class (TC) may e.g. be performed at the GGSN or PGW nodes, or in a standalone node in the core network. It can be based on pre-configured rules, or using the PCC framework which is defined in 3GPP TS 23.203 and may be extended for this purpose.
As a result of the classification, the traffic flow is marked so as to indicate its association to a given traffic class (TC), which e.g. may represent a given combination of application/service and/or subscription. Typically, a traffic class is a subset of the traffic of a given user.
There are at least two tools available for the operator to identify traffic classes (TCs) in the RAN: today's well known bearer based traffic classes e.g. based on QCI or any other similar bearer based traffic classification, and packet marking based traffic classification.
Traffic classification based on QCI or similar may e.g. associate a traffic flow in a bearer or similar with a traffic class based on the QCI or similar allocated to the bearer or similar.
Traffic classification based on packet marking may e.g. use a header field of the packets in a traffic flow to associate the traffic flow with a traffic class, e.g. in downlink user plane packets, to differentiate certain sets of data packets from the point of view of QoS handling. Typically data packets belonging to a particular traffic flow are marked in a similar manner.
To mark the packets of a given traffic class, it is possible to use one or more of the methods below:
To realize this, each time a RAN (e.g. such as RNC and/or eNB) node and the SGW/SGSN need to allocate a separate TEID for downlink traffic, it would allocate a number of TEIDs, one corresponding to each traffic class within the bearer. The number of TEIDs per bearer could be a configuration parameter. The TEIDs assigned for the TCs would be communicated using the same control messages as today. In this way, the GGSN/PGW node can become aware of the TEIDs used by the SGW or SGSN or RNC, and the SGW/SGSN node can also become aware of the TEIDs used by the RNC or eNB. To determine the number of TCs within the bearer, one of the following options may be used.
It is possible to apply only one of the two above indicated tools for indicating traffic classes (i.e. bearer based traffic classification e.g. based on QCI, or packet marking based traffic classification). Note that the packet marking based traffic classification can also be used in combination with the existing bearer based traffic classification using different QCIs. Note that bearer based differentiation can apply to both uplink and downlink traffic. As a special case, it is possible to use only the currently specified bearer based traffic classification without packet markings.
Below an exemplifying case is discussed with reference to
Here different QoS targets are used on per QCI, per packet marking and per congestion level basis. For each QCI, packet markings are associated with different QoS treatment, and a default QoS treatment may be assigned for the traffic that has no packet marking present. For each congestion level, there is a set of QoS parameters that the operators can set. It is required in this solution that each vendor implements these QoS targets according to this framework, while the exact definition of the QoS targets may be vendor specific. As an example, target bitrates or similar can be used as a QoS target.
Thus, some aspects of the present solution suggest the following concept:
When packet marking is used to differentiate traffic classes within a given QCI, it is preferred that the congestion level corresponding to the traffic classes in the bearers with the given QCI is similar—there can be differences based on the momentary traffic mix, and differences due to difference in radio channel conditions, but the congestion level is expected to increase or decrease similarly for these classes. It might be possible that a traffic classes in a different QCI experience a different level of congestion because e.g., different delay requirements for different QCIs may lead to lower congestion levels in certain QCIs.
When QCI is used to differentiate traffic classes (TCs) which are assigned congestion level specific QoS targets, then it is preferred that the congestion level is similar over a set of QCI values. It shall be possible to control which set of QCIs experience a similar congestion level.
Note that traffic flow in bearers with a certain QCIs may be excluded from the congestion level specific QoS target concept, e.g. QCIs which are used to deliver mission critical traffic with very low delay may get priority over other traffic and hence may experience no congestion.
The RAN congestion level concept presented above gives a framework to define the congestion behavior for a given combination of bearer based traffic classes and packet marking based traffic classification. Given the framework in which operators can set the QoS targets for a traffic class (TC), the packet marking itself does not need to carry any additional information regarding RAN packet treatment. Classifying a traffic flow into a suitable traffic class (TC) and/or packet marking may e.g. be performed by a suitable core network (CN) node, e.g. a GGSN or a PGW node, or in a standalone node in the core network.
There is full flexibility in how the traffic flows are classified in the core network. A number of criteria can be used as basis, e.g. such as:
In this way, there is flexibility in the core network to map traffic flows into traffic classes (TCs) based on packet marking and/or based on bearer association for the traffic flow, and flexibility in the RAN to assign a set of QoS parameters to each traffic class (TC).
Communicating Congestion Level Dependent QoS Targets to RAN
As noted above, congestion level dependent throughput targets are typically set for each traffic class (TC) such that each traffic class is associated with a QoS target (e.g. a throughput target, e.g. a target bitrates or similar) for each congestion level. It should be noted that congestion level dependent throughput targets are an exemplary realization of general congestion level dependent QoS targets. Besides congestion level dependent throughput targets, embodiments of the present solution are similarly applicable for other possible types of congestion level dependent QoS targets, such as congestion level dependent QoS targets expressed in terms of target delays or target packet loss or similar, or a combination thereof. These congestion level dependent QoS targets can be expressed by a set of QoS parameters. Realizations of embodiments of the present solution are possible wherein these QoS parameters are not standardized, however the parameter structuring with congestion level dependent QoS targets per congestion level for a given traffic class are preferred.
For each TC, the congestion level dependent throughput targets for all congestion levels are preferably sent to the RAN nodes (e.g. such as RNC and/or eNB), so that the RAN node is prepared to provide the intended resource sharing at a specific congestion level. Alternatively, the congestion level dependent throughput targets may be pre-defined in the RAN node(s). The RAN node then tries to apply the lowest congestion level that is feasible, and applies the throughput targets according to that congestion level. If a given congestion level is not feasible, the RAN node may apply the next higher congestion level. If none of the congestion levels are feasible then the RAN node actions may be implementation dependent. Also, the resources remaining after the targets have been met may be shared in an implementation specific way.
Note also that the congestion dependent QoS targets (e.g. such as congestion level dependent throughput targets) are preferably set in advance, i.e. without knowing the momentary congestion level in the RAN node. Once these throughput targets are set in advance and communicated to or pre-defined in the RAN node, the RAN node can apply the target that fits the momentary congestion level.
There are two preferred options for informing the RAN node about the congestion level dependent QoS targets: explicit control signaling of the throughput targets, or in-band user plane signaling.
Explicit Control Signaling of Congestion Level Dependent QoS Targets.
With this alternative, the congestion level dependent QoS target such as throughput targets are communicated from the CN to the RAN node, e.g. during bearer establishment or bearer modification. This can be achieved by including the list of throughput targets or similar for all traffic classes which applies to the given bearer, and for all congestion levels. The RAN node may then maintain these values in its user specific context, it may also pass this values on to a new RAN node in case of congestion. Note that in addition to the throughput targets, it is also possible to optionally include delay targets for the given traffic class, to indicate whether or not (and to what extent) the given traffic is delay sensitive.
Implicit Control Signaling of Congestion Level Dependent QoS Targets.
With this alternative, a given traffic class is associated with an index, here called Throughput Target Set Index or TTSI for short. Pre-configuration in the RAN maps the TTSI to a set of throughput targets for the different congestion levels. The pre-configuration can be achieved e.g. by O&M, or by explicit control signaling that is performed e.g., when a RAN node is switched on or at other times. Once the throughput targets for a TTSI are pre-configured, it is sufficient to supply the TTSI for a given traffic class to make the throughput targets known in the RAN for that traffic class.
Supplying the TTSI is possible by packet marking, i.e. adding a new packet header such as e.g. a GTP-U header. Note that the TTSI may be identical to the identifier of the traffic class (TC) itself, e.g., it is possible to use a packet header field both as an identifier of the traffic class and as TTSI, identifying the set of congestion level dependent QoS targets. It is also possible to use separate header fields to identify the TC and to identify the TTSI.
Supplying the TTSI is also possible with explicit control signaling. For example, at bearer setup it is possible to supply a list of TTSIs that are to be used for the TCs within the bearer. Then, the RAN node can e.g., reserve separate TEIDs for the TCs within the bearer, and then use the list of supplied TTSIs to associate a set of throughput targets with each TCs.
Supplying the TTSI is also possible via the use of bearer based differentiation, e.g. so that TTSI corresponds to the QCI for the bearer in question. Combinations are also possible, i.e. the combination of QCI and packet marking determines the TTSI.
In-Band User Plane Signaling of Congestion Level Dependent QoS Targets.
With this alternative, a new packet congestion level marking is used to communicate the throughput targets to the RAN node. For this packet marking, it is possible to use a GTP-U extension hearer, or the Differentiated Service Code Point filed (DSCP field) in the IP header or other header fields. Consider that the throughput targets for a given traffic class are TH, TM, TL for high, medium and low congestion levels, respectively. Then, a packet marking is applied such that 0-TH of the total throughput is marked with marking e.g. 0; TM-TH of the total throughput is marked with marking e.g., 1; TL-TM of the total throughput is marked with marking e.g., 2; traffic in excess of TL is marked with marking e.g., 3. This can e.g. be achieved by applying a marker using 3 token buckets to the traffic flow within the traffic class, where the rate of the token buckets is TH, TM-TH and TL-TM. Other methods based on bitrate measurement are also possible.
Once the traffic congestion level is marked as outlined above, the RAN node can determine the throughput targets by measuring the total throughput of the packets with different markings. In the example above, the RAN node can measure the throughput of packets with marking 0 to get the throughput threshold TH; the RAN node can measure the throughput of packets with marking 0 and 1 to get the throughput threshold TM; the RAN node can measure the throughput of packets with marking 0, 1 and 2 to get the throughput threshold TL. Using the measured throughput targets, the RAN node can then provide the expected resource sharing. The RAN node can store the measurement in the user context. During handover, it is possible to pass on the most recent measurement to the new RAN node, but it is also possible for the new RAN node to start over the measurement again.
The in-band user plane signaling of throughput targets has the advantage that it does not require control signaling for the throughput targets, and it can work even if the throughput targets are not passed on during handovers. Also, it is easier to dynamically change the throughput targets, e.g. depending on the actual settings of a video codec, or with the changes of the traffic pattern. Additionally, the in-based user plane signaling also allows the packet markings to be used in the transport network. On the other hand, the explicit or implicit control plane signaling of the throughput targets does not require RAN measurements and the additional marking.
Note that the methods can also be used in combination, i.e. use explicit or implicit control signaling to inform the RAN about the throughput targets, yet at the same time use packet congestion level marking to mark the packets with different values depending on how many throughput thresholds the given packet exceeds. The advantage of using both methods is that the packet marking can be utilized in the transport network, while the RAN can use the more simple explicit or implicit control signaling to be informed about the throughput targets.
Roaming Case
In case of a roaming subscriber, the congestion level dependent QoS targets may be set by the home network and may be overridden in the visited network. This enables the visited network to apply its own policies on roaming subscribers. In case of explicit signaling of congestion level dependent QoS targets, this can e.g. be performed by replacing the throughput targets in the control signaling. In case of implicit signaling of throughput targets, this can e.g. be performed by replacing the TTSI in the control signaling In case of in-band user plane signaling of throughput targets, this require re-marking the packets according to the visited network's policies.
Transport Network Support
As outline above, a packet congestion level marking is possible to apply depending on how many of the congestion level dependent QoS targets are exceeded with a given packet. Such a packet marking could e.g. be applied in the DSCP field, or mapped to lower layers, e.g., mapped to Ethernet drop eligibility. It is possible to map multiple marking levels to a single lower layer marking in case the lower layers support fewer levels of differentiation. As noted above, the packet marking depending on how many congestion level dependent QoS targets such as throughput thresholds are exceeded are possible to apply no matter whether the RAN node is based on explicit or implicit notification of the throughput targets, or also uses the packet markings to measure the throughput targets.
In this way, the transport network can utilize the congestion level dependent QoS targets, and in cases of congestion apply a resource control mechanism based on the marking. A typical such resource control mechanism is to apply differentiated packet dropping. For example, packets with higher marking levels can have a higher precedence for packet dropping in case a packet drop is necessary, as determined e.g. by the buffer length status in transport equipment. Such multiple differentiated levels are already supported by routers which support differentiated services assured forwarding (RFC2597) where multiple drop levels are used within a class. An advantage of using the packet markings in the transport (e.g. in the transport layer and/or in the transportation network) is that the same resource sharing target can be applied in the transport as well as in the RAN air interface. Note that the application of drop precedence based on the packet marking is possible to use for aggregate traffic as well, i.e., the transport equipment does not need to separate traffic for each user.
Possible RAN Implementation
There can be many implementations defining how the resource sharing at the air interface is performed based on the throughput targets. One example implementation is outlined below.
The example implementation is similar to how the transport network can work, as described above. For this, the RAN node utilizes congestion level marking similarly as for the in-band based user plane signaling of throughput values. For example, consider that the throughput targets for a given traffic class are TH, TM, TL for high, medium and low congestion levels, respectively. Then, a packet marking is applied such that 0-TH of the total throughput is marked with marking e.g. 0; TM-TH of the total throughput is marked with marking e.g., 1; TL-TM of the total throughput is marked with marking e.g., 2; traffic in excess of TL is marked with marking e.g., 3. (For the case when the implementation takes place in a single RAN node, the congestion level marking is only logical concept.)
This type of marking may already be available in the RAN node if we use in-based user plane signaling of throughput values or similar. In case of explicit or implicit control signaling of throughput targets, the RAN node can measure the traffic against the throughput targets and mark the packets internally depending on how many throughput targets are exceeded.
Once the congestion level marking is available in the RAN node, it can apply differentiated packet dropping depending on the congestion level marking. I.e., the packets with a higher congestion level marking have a higher drop precedence value. The packets with a higher drop precedence are dropped earlier in case the buffer length increases during congestion.
Note that the RAN can apply the throughput targets for traffic classes not only within a given user, but also between users as well. In that way, an overall resource sharing control can be achieved that allocates resources both between and within users in accordance with the throughput targets set by the operator.
Note that the above example implementation does not require any 3GPP access specific RAN functions, and hence it can also be implemented over non-3GPP accesses such as WLAN, WiFi or cdma2000. The example implementation can be utilized in the same way, i.e. apply different congestion level packet markings based on the throughput thresholds, and use different drop precedence depending on the congestion level marking. This method could e.g. be applied for WiFi access connected to a PGW over an S2a interface.
Communicating a RAN Congestion from RAN to CN Based on Congestion Level Dependent QoS Targets
Congestion feedback based on congestion level dependent QoS targets is based on to what extent congestion level dependent QoS targets for traffic flows can be fulfilled. A main characteristic of congestion level dependent QoS congestion feedback is that it can differentiate in the congestion status while RAN is fully loaded. Congestion feedback based on congestion level dependent QoS targets is illustrated in
To enable congestion feedback based on congestion level dependent QoS targets, traffic flows are preferably differentiated into traffic classes (TCs) as described above, e.g. using bearers/QCI based differentiation and/or packet marking. For each traffic class (TC), a RAN node is configured with congestion level dependent QoS targets. The RAN node can then determine whether or not the congestion level dependent QoS targets can be fulfilled for a particular traffic flow at a particular congestion level in the RAN node. The RAN node can also determine whether a low QoS is due to congestion in the RAN, or simply because the given traffic flow does not have more traffic. Congestion is reported if one ore more congestion level dependent QoS targets cannot be met due to congestion in the RAN node. Conversely, no congestion is reported if the congestion level dependent QoS targets can be met, even if there is congestion in the RAN node. Preferably, no congestion is reported if one or more congestion level dependent QoS targets cannot be met while there is no congestion in the RAN node. This type of differentiation is possible since the RAN node is the bottleneck point performing the resource allocation, so it can determine whether or not more resources could have been given to a given traffic flow.
Based on whether or not one or more congestion level dependent QoS targets can be fulfilled, it is possible to report not only a binary value of congestion/no congestion, but also the character of the congestion, e.g. the specific level of congestion. For example, the following scheme can be applied for the congestion feedback signalling:
Congestion feedback based on congestion level dependent QoS targets can consider the actual QoS requirements of the different traffic flows in making the congestion feedback. In this way, it can also incorporate the relative importance of the different traffic flows from the operator's perspective.
In a radio cell the channel quality of different UEs can significantly differ from each other. It is often hard to provide the desired QoS to UEs with poor radio channel quality. This effect can also be taken into account during reporting, e.g. when the target QoS of a congestion level cannot be provided only for a small subset of UEs (e.g. 5-10%) then the RAN vendor might decide to not report that level of congestion.
In a network where both load-based congestion feedback and congestion feedback from the RAN to the CN based on congestion level dependent QoS targets are used, it is useful to differentiate the two types of congestion feedback, as a RAN and CN implementation uses different functional split as discussed above. RAN and CN implementations hence do not interwork well if they have different assumptions about whether the congestion feedback is load-based or QoS-based as indicated above.
Hence, it is possible to signal an indication together with the congestion feedback whether it is load-based or QoS-based as indicated above. Such an indication helps the CN to take the proper set of actions.
It is also possible to apply an a priori negotiation between the CN and the RAN about whether the RAN and the CN supports load-based or QoS-based congestion feedback as indicated above. Based on such negotiation, it is possible to use the type of congestion feedback that is supported for both sides. For example, if RAN or CN does not support QoS-based congestion feedback as described above, then load-based congestion feedback is used; if both RAN and CN support QoS-based congestion feedback, then QoS-based congestion feedback is used.
It is possible to set a minimal congestion level in the RAN below which changes in the congestion level are not reported to the CN. This can be a way to reduce the network signaling load generated by congestion feedback signaling, and send signaling only for the cases when really needed. This configuration could be achieved by sending a minimal congestion level, e.g. for either a given UE, or on a per bearer basis, from the CN to the RAN. As a special case, it is also possible to disable congestion feedback reporting for certain UEs or for certain bearers to reduce signaling. The configuration of RAN can e.g. be done when the RAN context is initially set up as the UE moves into connected mode, by adding a new information element. For LTE, this information can be conveyed e.g., in the Initial Context Setup Request sent from the MME to the eNB. Note that it is also possible to set a minimal congestion level for reporting for a whole cell, or for a given RAN area. This can be achieved via O&M configuration. The per user, per bearer or per cell/area granularity is not exclusive for setting a congestion feedback level reporting threshold. A combination of these approaches are also possible, and in case there are several configurations applying to a given case, it is possible to use either the minimal or the maximal congestion level reporting threshold.
The solutions discussed above may e.g. provide one or more of the following advantages:
Furthermore, feedback from the RAN to the CN based on congestion level dependent QoS targets gives a clear meaning to the congestion feedback signaling as follows:
Moreover, Feedback from the RAN to the CN based on congestion level dependent QoS targets has a number of advantages over load-based congestion feedback.
Some embodiments described herein may be summarized in the following manner:
One embodiment is directed to a method in a core network, CN, node for handling quality of service, QoS, targets for traffic flows between a radio access network, RAN, node and a radio terminal (300) served by the RAN node, wherein the method comprises:
The method may further comprise:
The method may comprise: receiving congestion information from the RAN node indicating a failure of satisfying a congestion level dependent QoS target in the RAN node.
The method may comprise:
The obtaining of the method may comprise:
The classifying of the method may comprise: marking each received traffic flow so as to associate the traffic flow with a traffic class.
The traffic classes and the QoS targets and the congestion levels may be set in advance without knowledge of a momentary congestion level in the RAN node so as to provide congestion level dependent QoS targets set in advance.
Some other embodiments described herein may be summarized in the following manner:
One other embodiment is directed to a core network, CN, node for handling quality of service, QoS, targets for traffic flows between a radio access network, RAN, node and a radio terminal served by the RAN node, wherein a processing circuitry is configured to operatively:
The processing circuitry may be further configured to operatively:
The processing circuitry may be further configured to operatively: receive congestion information from the RAN node indicating a failure of satisfying a congestion level dependent QoS target in the RAN node.
The processing circuitry may be further configured to operatively:
The processing circuitry may be further configured to operatively:
The processing circuitry may be further configured to operatively: mark each received traffic flow so as to associate the traffic flow with a traffic class.
The processing circuitry may be further configured to operatively: set the traffic classes and the QoS targets and the congestion levels in advance, without knowledge of a momentary congestion level in the RAN node, so as to provide congestion level dependent QoS targets set in advance.
Some other embodiments described herein may be summarized in the following manner:
One other embodiment is directed to a method in a radio access network, RAN, node for handling quality of service, QoS, targets for traffic flows between the RAN, node and a wireless terminal served by the RAN node, wherein the method comprises:
In the method, the defining may comprise:
The method may comprise:
The method may comprise:
receiving from the CN node load instructions to be used by the RAN node for reducing or adapting the congestion level dependent QoS congestion in the RAN node.
The method may comprise:
applying the congestion level dependent QoS targets based on the congestion level indicated by the obtained congestion information.
The method may comprise:
applying the congestion level dependent QoS targets such that if a given congestion level indicated by the congestion level dependent QoS targets is not feasible, then the next higher congestion level indicated by the by the congestion level dependent QoS targets should be applied
Some other embodiments described herein may be summarized in the following manner:
One other embodiment is directed to a radio access network, RAN, node for handling quality of service, QoS, targets for traffic flows between the RAN, node and a wireless terminal served by the RAN node, wherein a processing circuitry is configured to operatively:
The processing circuitry may be further configured to operatively define said traffic classes into which the traffic flows can be classified and QoS targets for at least two congestion levels for each traffic class by:
The processing circuitry may be further configured to operatively:
The processing circuitry may be further configured to operatively:
receive from the CN node load instructions to be used by the RAN node for reducing or adapting the congestion level dependent QoS congestion in the RAN node.
The processing circuitry may be further configured to operatively:
apply the congestion level dependent QoS targets based on the congestion level indicated by the obtained congestion information.
The processing circuitry may be further configured to operatively:
apply the congestion level dependent QoS targets such that if a given congestion level indicated by the congestion level dependent QoS targets is not feasible, then the next higher congestion level indicated by the by the congestion level dependent QoS targets should be applied.
The example embodiments presented herein are not limited to LTE, but may apply in any RAN, single- or multi-RAT. Some other RAT examples are LTE-Advanced, UMTS, HSPA, GSM, cdma2000, HRPD, WiMAX, and WiFi. The foregoing description of the example embodiments have been presented for purposes of illustration and description.
The foregoing description is not intended to be exhaustive or to limit example embodiments to the precise form disclosed, and modifications and variations are possible in light of the above teachings or may be acquired from practice of various alternatives to the provided embodiments. The examples discussed herein were chosen and described in order to explain the principles and the nature of various example embodiments and its practical application to enable one skilled in the art to utilize the example embodiments in various manners and with various modifications as are suited to the particular use contemplated. The features of the embodiments described herein may be combined in all possible combinations of methods, apparatus, modules, systems, and computer program products. It should be appreciated that any of the example embodiments presented herein may be used in conjunction, or in any combination, with one another.
It should be noted that the word “comprising” does not necessarily exclude the presence of other elements or steps than those listed and the words “a” or “an” preceding an element do not exclude the presence of a plurality of such elements. It should further be noted that any reference signs do not limit the scope of the example embodiments, that the example embodiments may be implemented at least in part by means of both hardware and software, and that several “means”, “units” or “devices” may be represented by the same item of hardware.
The various example embodiments described herein are described in the general context of method steps or processes, which may be implemented in one aspect by a computer program product, embodied in a computer-readable medium, including computer-executable instructions, such as program code, and executed by computers in networked environments. A computer-readable medium may include removable and non-removable storage devices including, but not limited to, Read Only Memory (ROM), Random Access Memory (RAM), compact discs (CDs), digital versatile discs (DVD), etc. Generally, program modules may include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Computer-executable instructions, associated data structures, and program modules represent examples of program code for executing steps of the methods disclosed herein. The particular sequence of such executable instructions or associated data structures represents examples of corresponding acts for implementing the functions described in such steps or processes.
| Number | Date | Country | Kind |
|---|---|---|---|
| PCT/EP2013/060090 | Jun 2013 | WO | international |
This application is a 35 U.S.C. §371 National Phase Entry Application from PCT/EP2014/056961, filed Apr. 8, 2014, which claims priority to U.S. Application No. 61/809,637 filed Apr. 8, 2013 and International Application No. PCT/EP2013/060090 filed Jun. 20, 2013. The above identified applications are incorporated by reference.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/EP2014/056961 | 4/8/2014 | WO | 00 |
| Publishing Document | Publishing Date | Country | Kind |
|---|---|---|---|
| WO2014/166884 | 10/16/2014 | WO | A |
| Number | Name | Date | Kind |
|---|---|---|---|
| 20040170127 | Tanaka | Sep 2004 | A1 |
| 20050174965 | Sarkkinen et al. | Aug 2005 | A1 |
| 20060039313 | Chou et al. | Feb 2006 | A1 |
| 20090268684 | Lott | Oct 2009 | A1 |
| 20110170414 | Lee | Jul 2011 | A1 |
| 20120039175 | Sridhar | Feb 2012 | A1 |
| 20130329559 | Cabrera | Dec 2013 | A1 |
| 20140213310 | Yeh | Jul 2014 | A1 |
| 20140254356 | Jeong | Sep 2014 | A1 |
| 20140328183 | Au | Nov 2014 | A1 |
| 20140355463 | Smith | Dec 2014 | A1 |
| 20150043346 | Miller | Feb 2015 | A1 |
| 20150172954 | Zhang | Jun 2015 | A1 |
| 20150373077 | Ramamurthi | Dec 2015 | A1 |
| 20160112896 | Karampatsis | Apr 2016 | A1 |
| Number | Date | Country |
|---|---|---|
| 2009008817 | Jan 2009 | WO |
| Entry |
|---|
| International Search Report and Written Opinion issued by the International Searching Authority in corresponding International Application No. PCT/EP2014/056961 dated May 30, 2014, 6 pages. |
| Number | Date | Country | |
|---|---|---|---|
| 20160359750 A1 | Dec 2016 | US |
| Number | Date | Country | |
|---|---|---|---|
| 61809637 | Apr 2013 | US |
