WO2016112958A1

WO2016112958A1 - Qci mobility handling

Info

Publication number: WO2016112958A1
Application number: PCT/EP2015/050494
Authority: WO
Inventors: Maria Belen PANCORBO MARCOS; Peter Hedman; Stefan Rommer
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2015-01-13
Filing date: 2015-01-13
Publication date: 2016-07-21

Abstract

The present invention relates to a method and nodes for handling a QCI setting for a radio access type change. The method comprises assigning, by a first node, a plurality of radio access type dependent QCI values; and transmitting the assigned radio access type dependent QCI values to a second node and a third node.

Description

QCI MOBILITY HANDLING

TECHNICAL FIELD

The present invention relates to a method and node(s) for handling QoS Class Identifier (QCI) settings for radio access type changes as well as to a corresponding system and computer program, and in particular to a method and node(s) for handling QCI settings for radio access type changes in a policy and charging system of a communication network by assigning radio access type dependent QCI values.

BACKGROUND

In communication networks, such as telecommunication networks, a call or a service or an application often involves, on the one hand, a control plane or signalling piane and, on the other hand, a user plane or media plane. The control plane or signalling plane is in charge of establishing and managing a connection between two points of the network. The user plane or media plane is in charge of transporting user data or service data.

Network operators have the desire to define and enforce a set of rules in the network. A set of rules constitutes policies. A policy framework for managing and enforcing these policies usually includes at least three elements or functions: a policy repository for storing policy rules, which may be user-specific, a policy decision element or function and a policy enforcement element or function. The purpose of a policy framework includes controlling subscriber access to networks and services as well as the kind of access, i.e. its characteristics. A policy framework notably addresses the decisions as to whether the subscriber is entitled, or authorized, to enjoy a service, and whether the network can provide the service to the subscriber, and particularly whether the network can provide the service to the subscriber with the desired Quality of Service (QoS). Policy and charging control architectures, such as, but not limited to, the architecture described in 3GPP TS 23.203 version 13.1 .0 (2014-09), Technical Specification Group Services and System Aspects; Policy and charging control architecture (release 13) (available on http://www.3gpp.org/ftp/specs/archive/23_series/23.203), integrate policy and charging control. One aim of a policy framework is to set up and enforce rules dependent on subscribers and/or desired services to ensure efficient usage of network resources among ail subscribers.

An architecture that integrates and supports Policy and Charging Control (PCC) functionality, i.e. a PCC architecture, is depicted in Figure 1 which is taken from 3GPP TS 23.203 specifying the PCC functionality for Evolved 3GPP Packet Switched domain including both 3GPP (E-UTRAN) accesses and Non-3GPP (GERAN/UTRAN) accesses.

The Policy and Charging Rules Function (PCRF) 110 of Figure 1 is a functional element that encompasses policy control decision and flow based charging control functionalities. The PCRF provides network control regarding Service Data Flow (SDF) detection, gating, QoS and flow based charging (except credit management) towards the Policy and Charging Enforcement Function (PCEF) 120. The PCRF receives session and media related information from the Application Function (AF) 140 and informs the AF of traffic plane events. The PCRF 1 10 is also coupled to a Subscriber Profile Repository (SPR) 150. Commonly, the PCRF functionality is implemented by stand-alone node(s). The PCRF shall provision PCC Rules to the PCEF via the Gx reference point and may provision QoS Rules to the Bearer Binding and Event Reporting Function (BBERF) 130 via the Gxx reference point. The provisioning of QoS Rules to the BBERF depends on the protocol supported by the access type. When the protocol transfers information to the PCEF that is needed for a policy decision, such as GTP, no BBERF is deployed. Otherwise, the BBERF provides the information to the PCRF over the "Gxx" interface. in the architecture 100 of Figure 1, the PCRF shall inform the PCEF through the use of PCC Rules on the treatment of each service data flow that is under PCC control, in accordance with the PCRF policy decision(s).

The SPR 150 in Figure 1 is a functional entity that contains all subscriber/subscription related information used as input to generate PCC/QoS/ADC rules by the PCRF. The SPR functionality can be implemented by a typical subscriber database node, such as a Home Location Register (HLR) or Home Subscriber Server (HSS) node, which in turn - and for the sake of storage capacity and reliability aspects- can be distributed along a plurality of database nodes (e.g. comprising replicas and/or distributing the data).

The Gx reference point of Figure 1 is defined in 3GPP TS 29.212 "Policy and charging control over Gx reference point", and lies between the PCRF and the PCEF. The Gx reference point is used for provisioning and removal of PCC Rules from the PCRF to the PCEF and the transmission of traffic plane events from the PCEF to the PCRF. The Gx reference point can be used for charging control, policy control or both. The Rx reference point of Figure 1 is defined in 3GPP TS 29.214 "Policy and charging control over Rx reference point" and is used to exchange application level session information between the PCRF and the AF. An example of a PCRF is the Ericsson Service-Aware Policy Controller (SAPC), see for example F. Castro et al., "SAPC: Ericsson's Convergent Policy Controller", Ericsson review No. 1 , 2010, pp. 4 - 9. An example of an AF is the IP Multi-Media Subsystem (IMS) Proxy Call Session Control Function (P-CSCF).

The Sd reference point of Figure 1 is defined in 3GPP TS 29.212 and lies between the Policy and Charging Rule Function (PCRF) and the Traffic Detection Function (TDF).

Both Gx and Rx reference points may be based on Diameter, see for example P. Calhoun et al., "RFC 3588: Diameter Based Protocol", IETF, September 2003. Gx is based on DCCA RFC 4006 or DBP RFC 6733. Rx is based on NasReq RFC 4005 and DBP 6733. PCEF encompasses service data flow detection, policy enforcement and flow based charging functionalities. A node implementing the PCEF can further encompass application traffic detection and reporting capabilities (e.g. in case it incorporates the Application Detection and Control functionality, ADC, or an equivalent Traffic Detection Function, TDF, as described below). The nodes implementing PCEF functionality are located within the path taken by the IP data packets sent and received to/from user terminals of communication users.

In particular, the PCEF enforces policy decisions received from the PCRF and also provides the PCRF with user-and access-specific information over the Gx reference point. The node including the policy enforcing functions (e.g. the PCEF or another Bearer Binding Function, BBF) encompasses SDF detection based on filter definitions included in the PCC Rules, as well as online and offline charging interactions (not described here) and policy enforcement. Since the PCEF is usually the one handling bearers, it is where the QoS is being enforced for the bearer according to the QoS information coming from the PCRF. This functional entity, i.e. the PCEF, can be located at a Gateway, e.g. in the PDN-GW in EPC case, or in the Gateway GPRS Support Node (GGSN), in the GPRS case. For all the cases where there is Proxy Mobile IP (PMIP) or Dual-Stack Mobile IP (DSMIP) in the core network, the above bearer control is performed in the BBERF instead.

The Application Function (AF) 140 of Figure 1 is an element offering applications in which service is delivered in a different layer, e.g. transport layer, from the one the service has been requested, e.g. signalling layer. One example of a network node including an AF 140 is the P-CSCF (Proxy-Call Session Control Function) of the IP multi-media (IM) core network (CN) sub-system. The AF 140 may communicate with the PCRF 110 to transfer dynamic session information, i.e. description of multi-media to be delivered in the transport layer. This communication is performed using the above-described Rx interface or Rx reference point, which is placed between the PCRF 110 and AF 140. Information in the Rx interface may be derived from the session information or service session information in the P-CSCF and it mainly includes what is called media components. Another example of a network node including an AF 140 is a streaming server. Further, the PCC architecture in Figure 1 depicts an Online Charging System (OCS) 180 and an Offline Charging System (OFCS) 190. The OCS 180 in Figure 1 performs credit control based on service data flow as known in the art and the OFCS 190 in Figure 1 is also known in the art. Upon reception of the PCC/QoS rules from the PCRF, a Bearer Binding Function (BBF), either the PCEF 120 or the BBERF 130 depending on the deployment scenario, performs the bearer binding, i.e. associates the provided rule to an IP-CAN bearer within an IP-CAN (Internet Protocol Connectivity Access Network) session. The BBF will use the QoS parameters provided by the PCRF to create the bearer binding for the rule.

Next, PCC support to applications is described. When an application requires dynamic policy and/or charging control over the IP-CAN user plane to start a service session, the AF will communicate with the PCRF to transfer the dynamic session information required for the PCRF to take the appropriate actions on the IP-CAN network. The PCRF will authorize the session information, create the corresponding PCC/QoS rules and install them in the PCEF/BBERF. The PCEF/BBERF will encompass SDF detection, policy enforcement (gate and QoS enforcement) and flow based charging functionalities. As described, the applicable bearer will be initiated/modified and if required, resources will be reserved for that application.

The Traffic Detection Function (TDF) 160 of Figure 1 is a functional entity that performs application detection and control, and reporting of detected application or service and its service data flow description to the PCRF. The TDF can act in solicited mode, i.e. upon request from the PCRF, or unsolicited mode, i.e. without any request from the PCRF. For example, the TDF is a stand-alone kind of node introduced in 3GPP release 11 for the purpose of traffic detection and enforcement. The TDF preferably applies Deep Packet Inspection (DPI) techniques -sometimes combined with heuristic analysis- for accomplishing with its detection functionality. According to 3GPP TS 23.203 (chapter 4.5) Application Detection and Control (ADC) functionality can also be located within a node implementing a PCEF enhanced with ADC functionality. As in the case of PCEF, nodes implementing TDF and/or ADC functionality use to be located within the path taken by the IP data packets sent and received to/from user terminals.

On the other hand, 3GPP release 8 standardizes a set of QoS Class Identifier (QCi) values. In particular, each SDF is associated with one and only one QoS Class Identifier (QCI). A QCI value is a reference to a specific QoS characteristic that a traffic, being related to a call or a service, for a bearer receive between a user equipment (UE) and a packet data network gateway (PDN GW). The QCI is a scalar, i.e. a pointer to a predefined QoS characteristic such as a certain packet delay budget, priority, and packet error loss rate. Further, the QCI accommodates the need for differentiating QoS in all types of 3GPP IP-CANs and some non-3GPP IP-CANs. In particular, a QCI value may be used as a reference to access node-specific parameters that control bearer level packet forwarding treatment (e.g. scheduling weights, admission thresholds, queue management thresholds, link layer protocol configuration, etc.), and that have been pre-configured by the operator owning the access node (e.g. eNodeB). Moreover, when bearer binding is performed, a bearer is associated with a specific QCI value as a bearer level QoS parameter (3GPP TS 23.401 V13.0.0 (2014-09), Section 4.7.3). In other words, the QCI values may be used to indicate what QoS characteristics are required for a traffic flow. In addition, a QCI value is one of the elements of a QoS rule.

The standardized QoS characteristics as implied by the QCI values are not signaled on any interface. They should be understood as guidelines for the pre-configuration of node specific parameters for each QCI. The goal of standardizing a QCI with corresponding QoS characteristics is to ensure that calls and/or applications and/or services mapped to that QCI receive the same minimum level of QoS in multi-vendor network deployments and in case of roaming. A standardized QCI and a corresponding QoS characteristic is therefore independent of the UE's current access technology (3GPP or Non-3GPP). The QCI values represent a certain performance characteristics in terms of priority, packet delay budget and packet error loss rate. A set of standardized QCI values is defined in 3GPP TS 23.203 v.13.1.0, Table 6.1.7: Standardized QCI characteristics. Accordingly, within a guaranteed bit rate (GBR) as resource type, a QCI value of 1 being related to a conversational voice service, for example, has a priority level of 2, a packet delay budget of 100 ms, and a packet error loss rate of 10-2. Furthermore, a QCI value of 65 being related to a mission critical user plane Push to Talk (PIT) voice service, for example, has a priority level of 0.7, a packet delay budget of 75 ms, and a packet error loss rate of 10-2. In addition, within a non-guaranteed bit rate (Non-GBR) as resource type, a QCI value of 6 being related to a video service (buffered streaming), for example, has a priority level of 6, a packet delay budget of 300 ms, and a packet error loss rate of 10-6. Furthermore, a QCI value of 69 being related to a mission critical delay sensitive signaling services (e.g. mission critical PTT signaling), for example, has a priority level of 0.5, a packet delay budget of 60 ms, and a packet error loss rate of 10-6. In Gx and GTPv2 protocols defined in 3GPP TS 29.212 V12.6.0 (2014-09) and 29.274 QCI values 0, 255 and from 10 - 64, 67 - 68, 71 - 127, 128 - 254 are "Reserved". Alternatively, the coding of QCI values may be set to "Spare" instead of "Reserved".

In general, standardized QCI values are supported by E-UTRAN only, while in GERAN or UTRAN access, the standardized QCI values are mapped to UMTS QoS values. For example, 3GPP TS 23.401 V13.0.0 (2014-09) Table E.3 lists a QCI to UMTS QoS mapping. As described above, the PCRF provisions PCC Rules to the PCEF via the Gx reference point. Each PCC Rule includes a QCI value. The mapping from QCI to UMTS QoS is local to the Mobility Management Entity (MME)/S4-SGSN. As further shown in Figure 2 and known in the art (for example, 3GPP TS 23.401 V13.0.0 (2014-09)), in a mobile communication system employing an LTE (Long Term Evolution) scheme, the Mobility Management Entity (MME) performs access control for a mobile station (UE) to a handover destination cell in a handover procedure. In addition, the S4- SGSN is a Serving GPRS Support (SGSN) Node using the S4 interface to interface the Serving Gateway, as shown, for example, in Fig. 4.2.1 in 3GPP TS 23.401 V13.0.0 (2014- 09). The architecture of Figure 2 further includes the policy and charging system of a communication network, in particular the PCRF 1 10, the PCEF 120, and the BBERF 130. In addition, Packet Data Network (PDN) Gateway and the Serving Gateway of Figure 2 may be standalone functions that interface using the S5 interface {non-roaming or visited access roaming) or the S8 interface (home routed roaming). In session management procedures, a 3GPP Rel-12 MME and S4-SGSN deactivates a bearer with a QCI values that are matching "Reserved" values. For example, the QCI values selected for PTT services may be within those QCI values that are "Reserved". Furthermore, a eNB may downgrade a QCI value that is not understood, i.e. a QCI value not being assigned any QoS characteristics, to a QCI value of 9, and then the session management procedure is accepted. In this case, an eNB may use QCI 9 "background traffic" instead of rejecting. When a bearer for a particular service, such as the PTT service, is deactivated, the corresponding service traffic may, however, be carried over another bearer that is not aligned with the performance requirements that this particular service demands or the traffic may be discarded by the PDN GW.

The following approaches have been suggested to overcome the above problems.

First, TS 23.203 v.13.1.0 clause A.4.3.1.3 specifies that the PCRF assigns GBR QCI values within the limits supported by the serving network (NW). The PCRF learns what the serving NW is at the time the Gx session is established. The PCRF also learns when the serving NW is changed, if the PCRF is subscribing to events for serving NW changes. If, for example, the serving NW supports QCI 65, the PCRF assigns this QCI value typically to PTT voice service. Second, 3GPP contribution S2-143741 and S2-143551 propose that at inter radio access type (RAT) mobility, i.e. a RAT change, from E-UTRAN, a non-supported QCI by the target RAT, being the radio access type after the change, is mapped onto the appropriate QoS value by MME. For example, a QCI value of 65 is mapped onto UMTS QoS value(s) by MME, if the target RAT is UTRAN.

And third, 3GPP contribution S2- 143739 proposes that at inter-RAT mobility to E-UTRAN, the PCRF is notified as to RAT type change(s). Accordingly, the PCRF triggers a QoS change when it learns that the RAT type has changed from, e.g., UTRAN to E-UTRAN. There are, however, technical problems with the above proposed solutions.

With regard to the first approach, the PCRF only knows the QCI supported by the serving NW which is, however, independent of RAT. Therefore, when a RAT change occurs within a serving NW, the same QCl applies and PCC Rules will be not be updated. It is therefore not possible to apply the correct QCl in mobility scenarios, i.e. for a radio access type change within the same serving NW.

With regard to the second approach, performing a local mapping or changing the QCl in the M E/S4-SGSN without a consistent change to the PCC rule with regard to the applicable QoS results in an inconsistent usage of QoS throughout the system, for example with regard to the binding of an appropriate bearer, and thus also, e.g., to over- charging etc.

With regard to the third approach, the PCRF triggers a bearer update at the time the mobility procedure, i.e. the RAT change, has been completed. This necessarily requires extra signaling from PCEF to MME or S4-SGSN to assign QCl values to the bearer required by the call or service and supported by the radio access network (RAN). In the meantime, i.e. until the bearer update is completed, the service or call traffic, such as the PTT traffic, is carried over a bearer that is not aligned with the performance requirements that the PTT service demands, or the PTT traffic can be discarded. Therefore, there is the general problem of handling QCl settings due to Radio Access Type (RAT) changes in respect to the radio accesses utilized by the UE, and the prior art solutions do not offer a satisfactory solution for all eventual cases. In other words, there is the general problem of setting QoS parameters for a specific data connection of a mobile device (user terminal/equipment, UE), and, in particular, setting of QCIs for a specific data connection of the mobile device.

It is thus desirable to provide methods, nodes, systems and computer programs to improve the QCl setting when handling calls and/or services for mobility scenarios, for example the PTT service, which may have QCl values that are not supported, are reserved or the like.

SUMMARY

A suitable method, node(s), a system and computer program are defined in the independent claims. Advantageous embodiments are defined in the dependent claims. In one embodiment, a method for handling a QCI setting for a radio access type change in a policy and charging system of a computer network is provided. This method comprises the step of assigning, by a first node, a plurality of radio access type dependent QCI values. Further, the method comprises the step of transmitting the assigned radio access type dependent QCI values to a second node and a third node of a communication network. Accordingly, by providing RAT-dependent QCI values the local mapping of QCI values in the MME or S4-SGSN is not needed. Further, the QoS characteristics used for bearer binding and policy enforcement is improved as the radio access type may be taken into account that is used by the UE.

In another embodiment, a first node in a policy and charging system of a computer network is provided. The first node comprises an assigning module configured to assign a plurality of radio access type dependent QCI values. Further, the first node comprises a communication module configured to transmit the assigned radio access type dependent QCI values to a second node of the communication network. Accordingly, by providing improved radio access type dependent QCI values, the information in the PCEF/BBERF and RAN is consistent, therefore QoS enforcement in the RAN and in the PCEF is consistent for both uplink and downlink directions and charging in the PCEF is according to the QoS provided at the current RAT type. In particular, RAT changes with regard to UE access changes may be handled more consistently throughout the system.

In another embodiment, a second node in a policy and charging system of a computer network is provided. The second node comprises a communication module configured to receive the plurality of RAT- dependent QCI values. Further, the second node comprises an examination module configured to check the plurality of RAT-dependent values per radio access type. In addition, the second node comprises an updating module configured to update a bearer QCI value, at mobility to a target RAT if the bearer QCI value is not aligned with the RAT-dependent QCI values. Accordingly, the bearer may be better brought in line with the performance requirements that a particular traffic of a call, a service, or an application has.

In another embodiment, a third node is provided. The third node comprises a communication module configured to receive a plurality of radio access type dependent QCI values assigned by the first node. Further, the third node comprises an examination module configured to determine a radio access type being a target of the radio access type change. Further, the third node comprises a mapping module configured to map a selected one of the plurality of radio access type dependent QCI values according to the target radio access type. Accordingly, an improved mapping, in line with service or application requirements, of QCI values may be applied in mobility scenarios of the UE.

In still another embodiment, a system is provided comprising the above-described first, second, and third nodes.

In still another embodiment, a computer program is provided which includes instructions configured, when executed on a single or a plurality of data processors, to cause the single or the plurality of data processors to carry out the above-described method.

Further, advantageous embodiments of the invention are disclosed in the dependent claims.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 illustrates an exemplary PCC architecture to assist the reader in understanding an exemplary content, in which embodiments of the invention may be applied.

Figure 2 illustrates an exemplary communication system including elements of the above PCC architecture to assist the reader in understanding an exemplary content, in which embodiments of the invention may be applied.

Figure 3 illustrates operations of a method for handling a QCI setting for a radio access type change according to an embodiment.

Figure 4 illustrates operations of a method for handling a QCI setting for a radio access type change according to an embodiment.

Figure 5 illustrates elements of a first node for handling a QCI setting for a radio access type change according to an embodiment.

Figure 6 illustrates elements of a second node for handling a QCI setting for a radio access type change according to an embodiment. Figure 7 illustrates elements of a third node for handling a QCI setting for a radio access type change according to an embodiment. Figure 8 illustrates an exemplary flow diagram for explaining an embodiment of the present invention in detail.

Figure 9 illustrates an exemplary flow diagram for explaining an embodiment of the present invention in detail.

Figure 10 illustrates an exemplary flow diagram for explaining an embodiment of the present invention in detail. DESCRIPTION OF THE EMBODIMENTS

Further embodiments of the invention are described with reference to the Figures. It is noted that the following description contains examples only and should not be construed as limiting the invention.

In the following, similar or same reference signs indicate similar or same elements or operations.

Figure 3 illustrates a flowchart of a method for handling a QCI setting for a radio access type change in a policy and charging system of a communication network, e.g. a telecommunication network of the 3rd or 4th generation, such as UMTS, LTE, LTE- Advanced, etc. The operations, also referred to as steps in the following, of the method may be carried out by at least one node of a policy and charging system, preferably the node comprising the Policy and Charging Rules Function (PCRF). For assisting the reader in understanding embodiments of the invention, examples are described by referring to the previously described PCC architecture of Figure 1. As mentioned above, the function described in Figure 1 are functional elements which may be placed in nodes of the policy and charging system and may be realized by suitable servers, routers, computers, a combination thereof, etc. as known in the art.

For example, the policy and charging system of the communication network comprises the above-mentioned node including the PCRF collocated with a node including the above- mentioned Policy and Charging Enforcement Function (PCEF) or a standalone PCRF node.

As can be seen in Figure 3, the method comprises a step S210 in which a plurality of radio access type dependent QCI values are assigned by a first node which preferably is the above-mentioned node including the PCRF. Accordingly, a QCI value being associated to specific QoS characteristics of a call/service/application is additionally being defined or determined per RAT type(s) that may be accessed by the UE. For example, for the PTT service a QCI value of 65, as described above and being conventionally independent on RAT, according to step S210 of the embodiment a plurality of RAT-dependent QCI are assigned such as a QCI value of 65 for E-UTRA, and appropriately (e.g. smaller) QCI values for GERAN and UTRAN. As such, the plurality of radio access type dependent QCI values are distinct QCI values for a call/service/application each being related to a different RAT. This also means that a SDF is not anymore associated with one and only one QCI value, but with a plurality of QCI values each being defined for a specific RAT. in another example, the plurality of radio access type dependent QCI values may be a predefined or dynamically updated list in the form of a new information element {IE)/attribute value pair (AVP). For example, the radio access type dependent QCI values may be defined in the form of

QoS-Class-ldentifier-per-RAT ::= < AVP Header: xxxx >

*[ QoS-Class-ldentifier ]

[ Access-Type ]

That is, a QoS-Class-ldentifier-per-RAT AVP (being related to a specific AVP code xxxx) may be defined of type "Grouped", as it contains the QoS-Class-ldentifier(s) for an associated "Access-Type" which may be, in general, a 3GPP or Non-3GPP access type by the UE.

In another example, the above "Access-Type" may further contain both an IP-CAN type AVP and an RAT-Type AVP both being associated to the QoS-Class-identifier(s). Here, all QoS-Class-ldent^'ifiers applicable to the provided Access-Type are preferably included within the QoS-Class-ldentifier-per-RAT. For example, the "Access-Type" may be defined in the form of Access-Type ::= < AVP Header: xxxx >

^*[ RAT-Type ]

[ IP-CAN-Type ] Accordingly, the Access-Type AVP (being related to a specific AVP code xxxx) may also be of type "Grouped' as it contains the type of the radio access technology, i.e. RAT- Type(s) for the associated IP-CAN-Type. Preferably, all the RAT-Types applicable to the provided IP-CAN-Type shall be included within the Access-Type. As may be taken from the above Access-Type structure, each of the assigned RAT-dependent QCI values may further include or may further be defined with regard to an IP-CAN type that is associated with that RAT. RAT-Type A VPs have been defined, for example, in TS 29.212, and may include values to identify that the RAT currently serving the UE is, for example, WLAN(O), UTRAN (1000), GERAN (1001 ), E-UTRAN (1004), or the like. That is, specific values are defined for generic RATs, Non-3GPP RATs, and 3GPP specific RATs. Furthermore, IP-CAN-Type AVPs have also been defined in TS 29.212, and may indicate the type of Connectivity Access Network in which the UE is currently connected or will be connected after a RAT change. For example, a value 3GPP-GPRS (0) may be used to indicate that the IP-CAN is associated with a 3GPP GPRS access that is connected to the GGSN based on the Gn/Gp interfaces and is further detailed by the RAT-Type AVP. Moreover, a value 3GPP-EPS (5) may be used to indicate that the IP-CAN is associated with a 3GPP EPS access and is further detailed by the RAT-Type AVP. As another example, a value Non-3GPP-EPS (6) may be used to indicate that the IP-CAN is associated with an Evolved Packet Core (EPC) based non-3GPP access. in addition, the assigning of a plurality of radio access type dependent QCI values may further be performed with regard to the limits supported by the serving network. Such limits may refer to situations that the QoS used via LTE is not supported via UMTS/GSM, for example with regard to packet delay or a certain combination of bearers etc. Other limits may refer to a situation that old SGSGs are used, which have not been provisioned to handle certain QoS values. As such, the current limits of the serving network are determined and are subsequently used to assign suitable QCI values.

As can be further seen in Figure 3, the method may further comprises a step S220 in which the assigned RAT-dependent QCI values are transmitted to a second node which preferably is the above-mentioned node including the PCEF or the BBERF, and is also transmitted to a third node which preferably is the above-mentioned node MME or the S4- SGSN of the communication system. The transmission to the third node may be performed from the PCEF/BBERF node that has received the assigned RAT-dependent QCt values. Accordingly, the PCRF node interacts with the PCEF node when the GPRS Tunneling Protocol (GTP) is used in the S5/S8 interface to provide a list of the assigned QCI values per RAT. More specifically, the list of the assigned QCi values per RAT may be transmitted within a message, for example a Create session response massage to an attach request. In addition, the PCRF node interacts with the BBERF node when the Proxy Mobile IP Protocol (PMIP) is used in the S5/S8 interface for the purpose of providing the list of the assigned QCI values per RAT. In other words, the list of radio access type dependent QCI values, for example in the form of the above described QoS-Class-ldentifier-per-RAT AVP may be sent from a first node, for example, the PCRF, to a second node, for example the PCEF/BBERF, depending on the used protocol. Then, the second node, i.e. the PCRE/BBERF, may further transmit this information to the MME or S4-SGSN. The MME or S4-SGSN may subsequently use this information to send it to the appropriate S4-SGSN or MME at mobility, e.g. when the UE changes the RAF, for example from a 3GPP access to a Non- 3GPP access. This means that RAT-dependent QoS characteristics may be signalled over specific interfaces which are known according to the exemplary architectures in Figures 1 and 2. As a result, the local mapping in the MME/S4-SGSN, as proposed in 3GPP contribution S2- 43741 or S2-1 3551 , for example in the home PLMN, is not required.

In still other words, the method illustrated in Figure 3, proposes to first (S210) determine, by a policy decision node having, e.g., a PCRF, a plurality of distinct QCI values that are to be applied/enforced per RAT currently accessed by an UE or being a target RAT after a RAT change, and to second (S210) transmit the determined QCI values-per-RAT-type to the nodes entitled to subsequently apply/enforce the corresponding QCI.

In an embodiment, the above assigning step (S210) may further be performed such as to assign multiple QCI values assigned for a specific RAT provided to the PCEF within a PCC Rule. Enforcing this PCC rule may thus be performed RAT-dependently. As such, a RAT change of the UE, for example from E-UTRAN to GERAN/UTRAN, may be suitably taken into account when enforcing the PCC rule. An improved subscriber access is thus achieved, as even during UE mobility, the information in the PCRF and both the PCEF and the BBERF is consistent with the QoS that is provided by the current radio access network. In order to maintain a unique enforcement of the PCC rules and/or a unique bearer binding, the above assigning step (S210) is further preferably be performed such that one QCI value is assigned per RAT.

In another embodiment, the above assigning step (S2 0) may further be performed such as to assign the RAT-dependent QCI values according to a subscription profile. This configuration guarantees that not only a flexible mapping for non-supported or reserved QCI values may be achieved, but also implies that a subscriber may receive a service or an application depending on the subscription type. As such, when assigning appropriate RAT-dependent QCI values for non-supported or reserved QCI values, this assigning/mapping may not be fixed with regard to RAT for example, but may also depend on a subscriber profile. For example, the QCI value of 70, for E-UTRAN, may be mapped into QCI values 6, 8 or 10 depending on subscription profile (such as gold, silver, bronze), all for UTRAN. This mapping of non-supported or reserved QCI values may typically be configured in the node of the policy and charging system, e.g. PCRF, PCEF, and BBERF, or the S4-SGSN node or the MME node that learns that a target node, i.e. a node to which data are transmitted, does not support a certain QCI value.

Figure 4 illustrates a flowchart of a method for handling a QCI setting for a radio access type change in a policy and charging system of a communication network in an embodiment of the present invention. Here, the steps S210 and S220 of Figure 4 which are known from Figure 3 are preferably performed by a node comprising the Policy and Charging Rules Function (PCRF). Conversely, the steps S230, S270, S280, and S290 of Figure 4 (to be described below) are preferably performed by a node comprising the Policy and Charging Enforcement Function (PCEF) or the Bearer Binding and Event Reporting Function (BBERF), while the steps S240, S250, and S260 of Figure 4 (to be described below) are preferably performed by a S4-SGSN/ ME node.

According to an embodiment of the present invention, the assigned RAT-dependent QCI values are used in step S230 of Figure 4 to perform appropriate bearer binding. More specifically, the present RAT or the target RAT, i.e. the RAT after mobility handover, is used to determine an appropriate QCI value. For example, a QCI value of 70 may be used and set for bearer binding in the case of E-UTRAN, while a QCI value of 6 may be set for bearer binding in the case of UTRAN. Moreover, a PCC rule change consistent with RAT change from E-UTRAN to UTRAN may be enforced, preferably at the PCEF node or the BBERF node. In addition, a flexible mapping for non-supported or reserved QCI values may be consistently used throughout the entire system, in particular with regard to consistent use of the appropriate bearer and PCC rule. In addition, this flexible and consistent mapping is achieved with a minimal usage of communication resources, and that a subscriber can receive a service depending on his subscription type.

According to an embodiment of the present invention, steps S270 and S280 of Figure 4 comprise the steps of checking (S270) the plurality of RAT-dependent QCI values per radio access type and updating (S280) a bearer QCi value, if the bearer QCI value is not aligned with the received RAT-dependent QCI values via step S220. For example, as a bearer is associated with a QCI value as a bearer level QoS parameter, in step S270 it is checked whether the RAT-dependent QCI values transmitted in step S220 are consistently used as a bearer QCI value for the present RAT or the target RAT. If, for example, a QCI value of 70 should be used in the case of E-UTRAN according to the received RAT-dependent QCI values, and there is presently UE access via a bearer having a bearer QCI value of 6, then it is found that the bearer QCI value is not aligned with the received RAT-dependent QCI values, i.e. a mismatch has occurred. Then, the bearer QCI value is appropriately updated with regard to the RAT. Accordingly, it is possible to apply the correct QCI value in mobility scenarios, and to appropriately consistently update and use PCC rules and the correct bearer when a RAT change occurs within a serving network. According to an embodiment of the present invention, step S290 of Figure 4 comprises transmitting the plurality of RAT-dependent QCI values node, preferably to the S4- SGSN/ ME node, only, if a mismatch between a QCI value assigned to a bearer and a QCI value allocated for a radio access type occurs. This solution allows for a reduction of signaling, for example, between the PCEF/BBERF node and the S4-SGSN/M E node, due to fact that a bearer update is sent only when the QCI value of the bearer should be changed.

According to an embodiment of the present invention, steps S240 and S250 of Figure 4 comprise determining (S240) a RAT being a target of the radio access type change; and mapping (S250) a selected one of the plurality of RAT-dependent QCI values according to the target radio access type. As such, when a RAT change occurs at mobility of the UE, one of the RAT-dependent QCI values is selected that corresponds to the target RAT, and is subsequently mapped/set as the applicable QCI value that should be used after the RAT change and PCC rule enforcement in the PCEF . As indicated above, the steps S240 and S250 are preferably be performed by a source S4-SGSN/MME node so that a legacy ME/S4-SGSN node does not have to perform any mapping. As such, the mapping or setting of QCI values according to the target RAT, for example, with regard to assigning the QCI value to a bearer, allows a consistent usage of QoS parameters throughout the system, as also the appropriate PCC rule is enforced for the target RAT.

According to an embodiment of the present invention, step S260 of Figure 4 comprises notifying (S260) about the mapped selected one of the plurality of radio access type dependent QCI values, preferably to the PCEF/BBERF node. Then, the PCEF/BBERF node may perform the above checking of the QCI values per RAT, followed by a bearer update if the bearer QCI value is not aligned with the QCI values per RAT. As can be seen from Figure 5, the node 200 (a first node) which is preferably a policy decision node, e.g. having the PCRF, comprises an assigning module 210 and a communication module 220, which both may be tangible elements or software functions running on a processor. The assigning module 210 of Figure 5 is configured to assign a plurality of RAT- dependent QCI values, wherein details about this assignment and the RAT-dependent QCI values have been described above. This assigning may be performed in advance, or in response to a request message from, e.g., the PCEF node. The communication module 220 of Figure 5 is configured to transmit the assigned RAT- dependent QCI values to a second node 300. In addition, the communication module 220 may also transmit the assigned RAT-dependent QCI values to a third node 300. As described above, the second node 300 is preferably a node within the policy and charging system, e.g. having the PCEF or BBERF. Again it is referred to the above discussion for more details to avoid unnecessary repetition.

Accordingly, the same advantages which are achieved with the above-described methods can also be achieved by the node 200. In one embodiment, the assigning module 210 of Figure 5 may be configured to assign multiple QCI values for a given PCC rule. Additionally or alternatively, the assigning module (210) of Figure 5 may be configured to assign one QCI value per radio access type, In one embodiment, the assigning module 210 of Figure 5 may be configured to assign RAT-dependent QCI values so as to include an IP-CAN type associated with the RAT. Additionally or alternatively, assigning module 210 of Figure 5 may be configured to assign the RAT-dependent QCI values according to a subscription profile.

Accordingly, the same advantages which are achieved with the above-described methods can also be achieved by the node 200.

As can be seen from Figure 6, the node 300 (a second node) which is preferably a node having the PCEFor the BBERF, comprises a communication module 310, an examination module 320, an updating module 330, and a bearer binding module 340, which may be tangible elements or software functions running on a processor.

The communication module 310 of Figure 6 is configured to receive a plurality of RAT- dependent QCI values assigned by the first node 200. In addition, the communication module 310 of Figure 6 may also be configured to transmit the received plurality of RAT- dependent QCI values to the node 400 (a third node).

The examination module 320 of Figure 6 is configured to check the plurality of RAT- dependent values per radio access type. As illustrated above, this checking may be performed by comparing the received RAT-dependent QCI values with a current bearer QCI value.

Further, the updating module 330 of Figure 6 is configured to update a bearer QCI value, if the bearer QCI value is not aligned with the radio access type dependent QCI values received from the first node. Again it is referred to the above discussion for more details to avoid unnecessary repetition.

Accordingly, the same advantages which are achieved with the above-described methods can also be achieved by the node 300. The bearer binding module 340 of Figure 6 being related to an embodiment of the present invention is configured to use the radio access type dependent QCI values for performing a bearer binding. Details of this configuration have been illustrated above with regard to step S230 in Fig. 4. As can be seen from Figure 7, the node 400 (a third node) which is preferably a S4- SGSN or a ME node comprises a communication module 410, an examination module 420, an updating module 330, and a mapping module 340, which may be tangible elements or software functions running on a processor.

The communication module 410 of Figure 7 is configured to receive a plurality of radio access type dependent QCI values assigned by the first node 200. Further, the examination module 420 of Figure 7 is configured to determine a radio access type being a target of the radio access type change. The mapping module 430 of Figure 7 is configured to map a selected one of the plurality of radio access type dependent QCI values according to the target radio access type. Again, it is referred to the above discussion for more details to avoid unnecessary repetition.

In an embodiment, the third node 400 the communication module 4 0 of the third node is further configured to notify the second node 300 about the mapped selected one of the plurality of radio access type dependent QCI values.

Accordingly, the same advantages which are achieved with the above-described methods can also be achieved by the node 400.

Another embodiment of the present invention is a communication system (not shown) that comprises the above first node, second node, and third node.

Figure 8 illustrates an exemplary flow diagram for explaining an embodiment of the present invention in detail, in particular being related to a mobility change of the UE from E-UTRAN to UTRAN/GERAN in the GTP case (in which the PCEF performs bearer binding) as a first mobility scenario. The detailed flow diagram of Figure 8 covers several steps of a possible implementation, in particular with regard to the first node 200 being related to a node having the PCRF, the second node 300 being related to a node having the PCEF, and the third node 400 being related to ME/S4-SGSN. In the flow diagram of Figure 8 also the user equipment (UE) of a user, e.g. a smartphone, is identified. Further, the PCRF 200 of Figure 8 includes the modules described above with regard to the first node 200, the PCEF 300 of Figure 8 includes the modules described above with regard to the second node 300, and the node MME/S4-SGSN 400 of Figure 8 includes the modules described above with regard to the third node 400, and the signaling between these entities will be described in detail below.

In step 1 of Figure 8 an "Attach Request" message is sent from the UE to the MME 400. As it is known in the art. such an "Attach Request" message within the attach procedure is involved in the RRC CONNECTION STEUP and may include parameters such as Evolved Packet System (EPS) attach type, EPS mobile identity, UE network capability, and the like. In step 2 of Figure 8 a "Create Session Request" message is sent from the M E 400 to the PCEF 300 which includes a default EPS bearer QoS (e.g. provided by HSS to the MME), for example a QCI value of 70, for the serving network (NW). It is to be noted that the default EPS bearer QoS is RAT-independent. In step 3 of Figure 8 an "IP-CAN Session Establishment (IPCSE)" message is sent from the PCEF 300 to the PCRF 200, as for example defined in 3GPP TS 23.203 (available on http://www.3gpp.org/ftp/Specs/html-info/23203.htm) (Section 7.2), to thereby obtain PCC rules for the UE. This message may further include the parameter/s User Location Information, Serving Network, Serving-GW address and RAT.

In step 4 of Figure 8 an IPCSE Acknowledgement" message is sent from the PCRF 200 to the PCEF 300 which includes the above-described list of RAT-dependent QCI values which are assigned by the PCRF node 200. In the present example of step 4 of Figure 8, a QCI value of 70 for RAT E-UTRAN and a QCI value of 6 for RAT UTRAN/GERAN are thus transmitted from the PCRF node 200 to the PCEF node 300.

Accordingly, the PCEF node 300 may use the list of RAT-dependent QCI values to perform bearer binding in which the current RAT is taken into account. As a result a bearer according to QCI value of 70 (QCI 70 bearer) is established between the UE and the PCEF node 300 as the RAT is E-UTRAN. In addition, in steps 5 and 6 of Figure 8 an appropriate "Create Session Response" message and an "Update Bearer Request" message are transmitted from the PCEF node 300 to the MME node 400. Here, the "Update Bearer Request" message includes the list of RAT-dependent QCI values which is thus also provided to the MME node 400.

In step 7 of Figure 8 an "Update Bearer Response" message is sent back from the MME node 400 to the PCEF node 300 indicating that the MME node 400 applies the QCI value according to the current RAT. For example, the MME node 400 may have assigned QCI values according to parameters received from HSS, that are later modified by PCRF, in that case the MME node 400 assigns the bearer QCI to the new value. In step 8 of Figure 8 a handover from E-UTRAN to UTRAN occurs, as a first mobility scenario, in which the M E node 400 performs uses the list of RAT-dependent QCI values provided in step 6 to perform a corresponding mapping to a QCI value of 6. As such, the MME node 400 applies the QCI value according to the target RAT, i.e. the RAT after the handover, and subsequently in step 9 forwards the list of RAT-dependent QCI values to the S4-SGSN node 400 within the "Forward Relocation Request" message.

Accordingly, the S4-SGSN node 400 assigns a QCI value of 6 since the target RAT after handover is UTRAN, and a bearer being associated with a QCI value of 6 is established between the S4-SGSN node 400 and the PCEF node 300, and a corresponding bearer having an UMTS QoS value between the UE and S4-SGSN node 400.

In step 10 of Figure 8 the S4-SGSN node 400 informs the PCEF node 300 as to the assigned bearer QCI value and the current RAT in a "Modify Berar Request" message. Accordingly, the PCEF node 300 checks the QCI value assigned by the S4-SGSN node 400 with the corresponding QCI value provided in the list of RAT-dependent QCI values which are assigned by the PCRF node 200. Since in the present example, the QCI value for the bearer (QCI 6 bearer) and the QCI value in the PCC rule, as derived from the list of RAT-dependent QCI values which are assigned by the PCRF node 200, are identical, no bearer update to the MME is needed and the PCEF node 300 enforces the PCC rule for UTRAN. Accordingly, when a RAT change occurs, the PCC rules are updated and the appropriate QCI value for the target RAT is used in the PCC rule.

Figure 9 illustrates an another exemplary flow diagram for explaining an embodiment of the present invention in detail, in particular being related to a mobility change of the UE from E-UTRAN to UTRAN/GERAN for the PMIP case (in which the BBERF performs bearer binding). Here, the list of assigned RAT-dependent QCI values is provided be the PCRF node 200 to the BBERF node 400 in step 9 (within a 'Gateway Control Session Establishment Acknowledgement" message), and is subsequently transmitted from the BBERF node 300 to the MME node 400 in step 10. After a handover from E-UTRAN to UTRAN in which the list of RAT-dependent QCI values is used for an appropriate mapping of the QCI to the target RAT, the BBERF node 300 informs the PCEF node 300 via the PCRF node in steps 15 - 17 of Figure 9 as to the assigned bearer QCI value and the current RAT. Accordingly, the PCC rule for UTRAN may be enforced at the PCEF node 300 and no bearer update is necessary. The remaining steps of Figure 9 are the same as in Fig. 8 or involve a signaling specific to the PMIP case. Figure 10 illustrates an another exemplary flow diagram for explaining an embodiment of the present invention in detail, in particular being related to a mobility change of the UE from UTRAN/GERAN to E-UTRAN for the GTP case. Accordingly, in step 1 of Figure 10 a handover to UTRAN occurs, as explained above, and the MME node 400 uses the list of RAT-dependent QCI values, as previously assigned by the PCRF node 200 and transmitted to the MME node 400, to map the QCI value a corresponding UTRAN value. In step 2 of Figure 10 this list of RAT-dependent QCI values is forwarded to the S4-SGSN node 400 in a ' Forward Relocation Request" message. The S4-SGSN node 400 discards this list of RAT-dependent QCI values, for example because the S4-SGSN node 400 does not understand this list. Subsequently, as described above with regard to the flow diagram of Figure 8, a bearer being associated with a QCI value of 6 is established between the S4-SGSN node 400 and the PCEF node 300, and a corresponding bearer having an UMTS QoS value between the UE and S4-SGSN node 400. The steps 3 and 4 of Figure 10 are the same as the steps 10 and 1 1 in Figure 8.

Subsequently, in step 5 of Figure 10 a handover occurs to E-UTRAN and a "Forward Relocation Request" message is sent from the MME node 400 to the S4-SGSN node 400 in step 6 of Figure 10. The PCEF node 300 is subsequently informed about the assigned QCI value (QCI 6 bearer) for the target RAT (E-UTRAN) in step 7 of Figure 10.

Based on the information provided in step 7, the PCEF node 300 enforces the PCC rules for E-UTRAN. In addition, the PCEF node 300 checks the QCI value applied for the present bearer (QCI 6 bearer) with the QCI value as assigned in the list of RAT- dependent QCI values, for example, by referring to the PCC rule. Since the QCI value for the present bearer (QCI 6 bearer) and the QCI value for E-UTRAN are not identical, i.e. a mismatch has occurred, a bearer update is required to change the QCI 6 bearer to the correct QCI 70 bearer for E-UTRAN.

Accordingly, in the context of steps 9 - 11 of Figure 10 the list of RAT-dependent QCI values is again provided to the S4-SGSN node 400 in an "Update Bearer Request" message. This procedure is required in a case that the UE has moved to a SGSN- S4/MME node 400 that has previously discarded the list of RAT-dependent QCI values.

In other words, the MME/SGSN-S4 node 400 notifies about the QCI value assigned to the bearer to the PCEF node 300. The PCEF node 300 checks the QCI values per RAT, as assigned by the PCRF node 200 and transmitted to the PCEF node 300, and then updates the bearer QCI if the QCI value is not aligned with assigned QCI values per RAT. The QCI values to be applied by the target RAT are provided to the M E/SGSN-S4 node 400 only, however, if a mismatch between the QCI assigned to the bearer and the QCI allocated for that RAT occurs.

In order to receive a message or to transmit, e.g. the RAT -dependent QCI values, it is further understood that the nodes 200, 300, and 400 may be implemented by including a bus, a processing unit, a main memory, a ROM, a storage device, an I/O interface consisting of an input device and an output device and a communication interface. The bus may include a path that permits communication among the components/modules of the node. The processing unit may include one or a plurality of processors, a microprocessor or other processing logic that interprets and executes instructions. The main memory may include a RAM or other type of dynamic storage device that may store information and instructions for execution by the processing unit. For example, the examination module and the mapping module discussed above with respect to Figures 7 may be realized by the processing unit. The ROM may include a ROM device or another type of static storage device that may store static information and instructions for use by the processing unit.

As mentioned above, the nodes 200, 300, and 400 may perform certain operations or processes described herein. The nodes 200, 300, and 400 may perform these operations in response to the processing unit executing software instructions contained in a computer-readable medium, such as the main memory, ROM and/or storage device. A com p uter-readable medium may be defined as a physical or a logical memory device. For example, a logical memory device may include memories within a single physical memory device or distributed across multiple physical memory devices. Each of the main memory, ROM and storage device may include computer-readable media with instructions as program code. The software instructions may be read into the main memory for another computer-readable medium, such as a storage device or from another device via the communication interface. The software instructions contained in the main memory may cause the processing unit including a data processor, when executed on the processing unit, to cause the data processor to perform operations or processes described herein. Alternatively, hard -wired circuitry may be used in place or on in combination with the software instructions to implement processes and/or operations described herein. Thus, implementations described herein are not limited to any specific combination of hardware and software. The physical entities according to the different embodiments of the invention, including the elements, modules, nodes and systems may comprise or store computer programs including software instructions such that, when the computer programs are executed on the physical entities, steps and operations according to the embodiments of the invention are carried out, i.e. cause data processing means to carry out the operations. In particular, embodiments of the invention also relate to computer programs for carrying out the operations/steps according to the embodiments of the invention, and to any computer- readable medium storing the computer programs for carrying out the above-mentioned methods. Where the term module is used, no restrictions are made regarding how distributed these elements may be and regarding how gathered these elements may be. That is, the constituent elements/modules of the nodes 200, 300, and 400 and systems may be distributed in different software and hardware components or other devices for bringing about the intended function. A plurality of distinct elements/modules may also be gathered for providing the intended functionality. For example, the elements/modules/functions of the node may be realized by a microprocessor and a memory similar to the above node including a bus, a processing unit, a main memory, ROM, etc. The microprocessor may be programmed such that the above-mentioned operation, which may be stored as instructions in the memory, are carried out.

Further, the elements/modules of the nodes or systems may be implemented in hardware, software, Field Programmable Gate Arrays (FPGAs), Application-Specific Integrated Circuits (ASICs), firmware or the like. From the above discussion, the skilled person becomes aware that by using the above schemes the assigning of RAT-dependent QCI values by the PCRF and the subsequent distribution to other nodes of the system allows for a consistent usage of QCI values, in particular for RAT changes, throughout the system, as the RAT-dependent QCI values are consistently used for bearer binding and PCC rule enforcement.

The skilled person becomes also aware this consistent usage of the RAT-dependent QCI values throughout the system minimizes the amount of signaling in the system, and allows for proper and timely alignment of a bearer with the performance requirements of a call, service, and/or application.

It will be apparent to those skilled in the art that various modifications and variations can be made in the entities and methods of this invention as well as in the construction of this invention without departing from the scope or spirit of the invention.

The invention has been described in relation to particular embodiments and examples which are intended in all aspects to be illustrative rather than restrictive. Those skilled in the art will appreciate that many different combinations of hardware, software and/or firmware will be suitable for practicing the present invention.

Moreover, other implementations of the invention will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. It is intended that the specification and the examples be considered as exemplary only, wherein abbreviations used in the above examples are listed below. To this end, it is to be understood that inventive aspects lie in less than all features of a single foregoing disclosed implementation or configuration. Thus, the true scope and spirit of the invention is indicated by the following claims.

ABBREVIATIONS

BBERF Bearer Binding and Event Reporting Function

eNB Evolved Node B

E-UTRAN Evolved UTRAN

GERAN GSM EDGE Radio Access Network

GTP GPRS Tunneling Protocol

NW Network

MCPTT Mission Critical PTT

MME Mobility Management Entity

PCC Policy and Charging Control

PCEF Policy Charging Enforcement Function

PCRF Policy and Charging Rule Function PDN GW Packet Data Network Gateway

PMIP Proxy Mobile IP protocol

PTT Push To Talk

QCI QoS Class Identifier

QoS Quality of Service

RAT Radio Access Type

SGSN Serving GPRS Support Node

UTRAN Universal Terrestrial Radio Access Network

RAN Radio Access Network

APN Access Point Name

CN Core Network

IP Internet Protocol

UE User Equipment (communications equipment utilized by a user, such as e.g. a smartphone).

Claims

Method for handling a QCI setting for a radio access type change, comprising the steps of: assigning (S210), by a first node (200), a plurality of radio access type dependent QCI values; transmitting (S220) the assigned radio access type dependent QCI values to a second node (300) and a third node (400).

Method of claim 1 , further comprising the step of: using (S230) the radio access type dependent QCI values by the second node (300) for performing a bearer binding.

Method of one of claims 1 to 2, wherein the assigning step (S210) by the first node (200) assigns multiple QCI values for a given PCC rule.

Method of one of claims 1 to 3, wherein the assigning step (S210) by the first node (200) assigns one QCI value per radio access type.

Method of one of claims 1 to 4, wherein each of the assigned radio access type dependent QCI values further includes an IP-CAN type associated with the radio access type.

Method of one of claims 1 to 5, wherein the assigned radio access type dependent QCI values are further defined according to a subscription profile.

7. Method of one of claims 1 to 6, further comprising the steps: determining (S240), by the third node (400), a radio access type being a target of the radio access type change; and mapping (S250), by the third node (400), a selected one of the plurality of radio access type dependent QCI values, as assigned by the first node (200), according to the target radio access type.

8. Method of claim 7, further comprising the step: notifying (S260) the second node (300) about the mapped selected one of the plurality of radio access type dependent QCI values.

9. Method of one of one of claim 1 to 8, further comprising the steps: checking (S270), by the second node (300), the plurality of radio access type dependent QCI values per radio access type; updating (S280), by the second node (300), a bearer QCI value, if the bearer QCI value is not aligned with the radio access type dependent QCI values received from the first node (200).

10. Method of one of one of claim 1 to 9, further comprising the step: transmitting (S290) the plurality of radio access type dependent QCI values to the third node (400) only, if a mismatch between a QCI value assigned to a bearer and a QCI value allocated for a radio access type occurs.

11. A first node (200), comprising: an assigning module (210) configured to assign a plurality of radio access type dependent QCI values; a communication module (220) configured to transmit the assigned radio access type dependent QCi values to a second node (300).

12. The first node (200) of claim 11 , wherein the assigning module (210) is further configured to assign multiple QCI values for a given PCC rule.

13. The first node (200) of one of claims 1 1 to 12, wherein the assigning module (210) is further configured to assign one QCI value per radio access type.

14. The first node (200) of one of claims 1 1 to 13, wherein each of the assigned radio access type dependent QCI values further includes an IP-CAN type associated with the radio access type.

15. The first node (200) of one of claims 1 1 to 14, wherein the assigned radio access type dependent QCI values are further defined according to a subscription profile.

16. A second node (300), comprising: a communication module (310) configured to receive a plurality of radio access type dependent QCI values assigned by a first node (200); an examination module (320) configured to check the plurality of radio access type dependent QCI; an updating module (330) configured to update a bearer QCI value, if the bearer QCI value is not aligned with the radio access type dependent QCI values received from the first node.

17. The second node (300) of claim 16, further comprising a bearer binding module (340) configured to use the radio access type dependent QCI values for performing a bearer binding.

18. The second node (300) of claims 16 to 17, wherein said communication module (310) is further configured to transmit the plurality of radio access type dependent QCI values to the third node (400) only, if a mismatch between a QCI value assigned to a bearer and a QCI value allocated for a radio access type occurs.

19. A third node (400), comprising: a communication module (410) configured to receive a plurality of radio access type dependent QCI values assigned by a first node (200); an examination module (420) configured to determine a radio access type being a target of the radio access type change; and a mapping module (430) configured to map a selected one of the plurality of radio access type dependent QCI values according to the target radio access type.

20. The third node (400) of claim 19, wherein said communication module (410) is further configured to notify a second node (300) about the mapped selected one of the plurality of radio access type dependent QCI values.

21. A system comprising the first node (200) of one of claims 11 to 15, the second node (300) of one of claims 16 to 18, and the third node (400) of one of claims 19 to 20.

22. Computer program including instructions configured, when executed on one or a plurality of data processors, to cause the data processor or the plurality of data processors to execute the method of one of claims 1 to 10.