WO2013144094A1

WO2013144094A1 - Supporting guaranteed bit rate in a non-guaranteed bit ratebearer

Info

Publication number: WO2013144094A1
Application number: PCT/EP2013/056305
Authority: WO
Inventors: Stefan Rommer; Yong Yang
Original assignee: Telefonaktiebolaget L M Ericsson (Publ)
Priority date: 2012-03-26
Filing date: 2013-03-25
Publication date: 2013-10-03

Abstract

Embodiments herein relate to a base station and a method therein for packet handling of service marked IP packets as well as a Traffic Detection Function "TDF" and method therein for providing a service identification marking. The TDF receives (30) at least one IP packet and identifies (32) at least one intended service for the IP packet. Next, the TDF assigns (34) at least one marking according to the at least one intended service. The assigned at least one marking being located in a user plane protocol header of the at least one IP packet. The assigned at least one marking is associated with a minimum bit rate "MIB". The TDF sends (38) the at least one IP packetto the base station (129). The base station (129) identifies (16) the intended service requiring the MIB based on the at least one marking.

Description

SUPPORTING GUARANTEED BIT RATE IN A NON-GUARANTEED BIT RATEBEARER

TECHNICAL FIELD

Embodiments herein relate to radio communication systems, such as a cellular telecommunication system. In particular, embodiments herein relate to a base station and corresponding method therein for packet handling of service marked Internet Protocol packets. Moreover, embodiments herein relate to a Traffic Detection Function and corresponding method therein for providing a service identification marking. BACKGROUND

In a typical cellular system, also referred to as a wireless communications network, wireless terminals, also known as mobile stations and/or user equipment units

communicate via a Radio Access Network (RAN) to one or more core networks. The wireless terminals can be mobile stations or user equipment units such as mobile telephones also known as "cellular" telephones, and laptops with wireless capability, e.g., mobile termination, 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.

The radio access network covers a geographical area which is divided into cell areas, with each cell area being served by a base station, e.g., a Radio Base Station (RBS), which in some networks is also called "NodeB" or "B node" and which in this document also is referred to as a base station. A cell is a geographical area where radio coverage is provided by the radio base station equipment at a base station site. Each cell is identified by an identity within the local radio area, which is broadcast in the cell. The base stations communicate over the air interface operating on radio frequencies with the user equipment units within range of the base stations.

In some versions of the radio access network, several base stations are typically connected, e.g., by landlines or microwave, to a Radio Network Controller (RNC). The radio network controller, also sometimes termed a Base Station Controller (BSC), supervises and coordinates various activities of the plural base stations connected thereto. The radio network controllers are typically connected to one or more core networks. The Universal Mobile Telecommunications System (UMTS) is a third generation mobile communication system, which evolved from the Global System for Mobile

Communications (GSM), and is intended to provide improved mobile communication services based on Wideband Code Division Multiple Access (WCDMA) access technology. UMTS Terrestrial Radio Access Network (UTRAN) is essentially a radio access network using wideband code division multiple access for user equipment units (UEs). The Third Generation Partnership Project (3GPP) has undertaken to evolve further the UTRAN and GSM based radio access network technologies. Long Term Evolution (LTE) together with Evolved Packet Core (EPC) is the newest addition to the 3GPP family.

For GSM Enhanced Data Rates for GSM Evolution (EDGE) Radio Access Network (GERAN), 3GPP has proposed a mechanism to improve radio resource management based on the knowledge of the current used applications/services by the user equipment (UE). The proposal aims at considering the fact that the dedicated bearer service is not fully supported in the network or by the user equipment.

Since data usage by diverse data applications, such as Instant Messaging (IM),has led to a significant increase of load in the network, there is a need to utilize the radio resource more efficiently in the network. For example, in some GERAN networks, some services such as IM chatting may unnecessarily and frequently occupy radio resources for a long time to the detriment of other applications which may suffer from network congestion.

As a result, GERAN would benefit from identifying the new service information associated with a mobile data application to improve radio resource control and management as well as user experience.

Therefore, as proposed in 3GPP, a GTP-U extension header is introduced in General Packet Radio Services (GPRS) Tunneling Protocol user data tunneling (GTP-U) to carry Service Identification (SI). The Slwill be inserted by the end GTP-U entities, such as Packet Data Network Gateway (PDN GW or PGW)/ Serving GW according to the current QoS architecture as specified in TS 23.401 and 3GPP TS 23.402 v1 1.2.0 (2012- 03) Architecture enhancements for non-3GPP accesses(Release 1 1 ), and later on be extracted by the other end GTP-U entities such as Serving GPRS Support Node (SGSN), Gn/Gp SGSN or S4-SGSN, and then be put into Base Station System GPRS Protocol (BSSGP) unit data. Such Service Identification could be derived from the parameters in the installed Policy and Charging Control (PCC) rules or QoS rules, such as QoS Class Identifier (QCI)/Allocation and Retention Priority (ARP), at the entities which perform bearer binding, i.e. Policy and Charging Enforcement Function (PCEF) or Bearer Binding and Event Reporting Function (BBERF), as specified in 3GPP TS 23.203 v1 1.4.0 (201 1 - 12) Policy and charging control architecture (Release 1 1 ).

The above solution, in which SI is provided in a GTP-U extension header, is aimed at providing a mechanism to allow RAN to improve radio resource management based on the knowledge of currently used service(s). Even though, the knowledge of currently used service(s) allows the RAN to improve radio resource management, some service(s) may still degenerate in some scenarios. For example, the user equipment may receive streaming video content from a site on the internet. In this context, a problem may be that there may be interruptions in the streaming.

SUMMARY

An object is hence to provide a radio communication system, e.g. of the above motioned kind, which overcomes or at least alleviates the above problem and/or other related problems.

This object is achieved by the methods and network nodes, such as a base station and a Traffic Detection Function (TDF) and methods therein, according to the

independent claims.

Accordingly, some of the example embodiments may be directed towards the classification or marking if Internet Protocol (IP) packets based on an intended service. In some of the example embodiments, a TDF or PDN Gateway (PGW) may be configured to provide such markings. Furthermore, these service based markings may be associated with a MlnimumBitrate (MIB), thus when a base station encounters such IP packets, the base station may provide the packet with Guaranteed BitRate (GBR) treatment if so indicated. Furthermore, some of the example embodiments provided herein may be directed towards the establishment of a TDF-PGW tunneling where information related to such markings, of the IP packets themselves, may be sent in a more efficient manner.

According to an aspect, the object is achieved by a method, in a base station for packet handling. The base station is comprised in a wireless communications network. The method comprises receiving at least one IPpacket on a bearer, said IP packet comprising at least one marking which identifies an intended service of the IP packet. The method further comprises identifying the intended service requiring a minimum bit rate, MIB, based on the at least one marking. According to another aspect, the object is achieved by a base station for packet handling. The base station is comprised in a wireless communications network. The base station comprises radio circuitry configured to receive at least one IP packet on a bearer, said IP packet comprising at least one marking which identifies an intended service of the IP packet. The base station further comprises processing circuitry configured to identify the intended service requiring a minimum bit rate, MIB, based on the at least one marking.

According to a further aspect, the object is achieved bya method, in a TDF for providing a service identification marking in a user protocol header.The method comprises receiving at least one IP packet, and identifying at least one intended service for the IP packet. The method further comprises assigning at least one marking according to the at least one intended service, where the assigned at least one marking is located in a user plane protocol header of the at least one IP packet, and the assigned at least one marking is associated with a minimum bit rate, MIB. The method further comprises sending, to a base station, the at least one IP packet.

According to yet another aspect, the object is achieved bya TDF for providing a service identification marking in a user protocol header. The TDF comprises radio circuitry configured to receive at least one IP packet and processing circuitry configured to identify at least one intended service for the IP packet.The processing circuitry is further configured to assign at least one marking according to the at least one intended service, where the assigned at least one marking is located in a user plane protocol header of the at least one IP packet, and the assigned at least one marking being associated with a minimum bit rate, MIB. The radio circuitry is further configured to send, to a base station, the at least one IP packet.

Thanks to that the base station identifies a service, e.g. an intended service, based on the at least one marking, e.g. together with the QoS requirement, such as a MIB, the base station is able to adapt its radio resource management such that it is ensured that the intended service obtains the required QoS, such as given by the MIB. The at least one marking may bereceived via control plane messages. Thereby, quality, e.g. in terms of bitrate, for the intended service may be adjusted accordingly, e.g. increased bitrate when required or decreased bitrate when possible. In this manner, it is made possible for the RAN, i.e. the radio base station, to enforce QoS requirement for the intended service, comparable to how QoS requirements can be enforced by use of bearer service, especially for a service requiring GBR. Consequently, the base station is able to preserve the end-to-end Quality of Service (QoS) architecture controlled by the core network.

Moreover, thanks to that the TDF assigns at least one marking, being associated with a MIB, to a user plane protocol header of the at least one IP packet, information about the Service Identification, may be sent to the base station. Thereby, enabling the base station to use the MIB as explained in the preceding paragraph.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing will be apparent from the following more particular description of the example embodiments, as illustrated in the accompanying drawings in which like reference characters refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating the example embodiments.

FIG. 1 is an example schematic of a wireless network;

FIG. 2 is an example of a TDF node, according to some of the example

embodiments;

FIG. 3 is a signaling diagram illustrating the establishment of TDF-PGW tunneling and IP packet marking, according to some of the example embodiments;

FIG. 4 is an example schematic of a wireless network featuring a TDF-PGW tunnel, according to some of the example embodiments;

FIG. 5 is a flow diagram illustrating example operations that may be taken by the TDF node of FIGS. 3-5;

FIG. 6 is an example of a base station, according to some of the example embodiments;

FIG. 7 is a signaling diagram illustrating the establishment of a PDN connection with a default bearer and the establishment of GBR service, according to some of the example embodiments; and

FIG. 8 is a flow diagram illustrating example operations that may be taken by the base station of FIGS. 6 and 7. DETAILED DESCRIPTION

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 example embodiments. However, it will be apparent to one skilled in the art that the example 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.

Now returning to the solution described in the background section. That solution is aimed at providing a comparable QoS differentiation mechanism as the mechanism that dedicated bearer service could provide. However, the solution is lacking a mechanism to support GBR when desired services requires Guarantee Bitrates, in such default bearer or primary Packet Data Protocol (PDP) context, which is supposed to be a non-GBR bearer context.

Furthermore, the solution assumes that the entities performing the bearer binding (PCEF and BBERF) also performs the packet inspect based on PCC/QoS Rules to determine how to classify the packet with the Service Identifier . However, with only a single bearer there is less need for bearer binding and it should be investigated what further simplifications can be made to the entities with PCEF/BBERF to fully utilize the simplifications when bearer signaling is not needed herefore, even for the UMTS UE, or LTE UE which support dedicated bearer service by default, the network will benefit from using GTP-U solution to realize the QoS differentiation.

More specifically, an example object of the example embodiments presented herein is to provide a mechanism in the Control Plane of 3GPP network elements, e.g. RAN (BSC, RNC and eNB), Gn/Gp SGSN, S4-SGSN, Mobility Management Entity (MME), Serving GateWay (SGW), Gateway GPRS Support Node (GGSN) and PGW, to allow the support of Guaranteed Bit Rates when the services authorized from Policy and Charging Rules Function (PCRF) require GBR i.e. the corresponding PCC rule contains QoS information including GBR.

Overview of a Wireless Communications System Figure 1 shows a schematic overview of a wireless communication system 200 in which the example embodiments presented herein may be applied. The system 200 is a so called LTE based system, also referred to as an EUTRAN system.lt should be pointed out that the terms "LTE" and "LTE based" system is here used to comprise both present and future LTE based systems, such as, for example, advanced LTE systems.

As shown, the system 200 can accommodate a number of user equipments one of which is shown as an example, with the reference number 130. Naturally, the system 200 can accommodate a large number of user equipments and is not limited to

accommodating only one user equipment.AII traffic to and from the user equipment 130 is routed via a so called "base station", which, depending on the nature of the system, has different names.

In a EUTRAN system such as the one 200 in Figure 1 , the "base station" is referred to as an enhanced Node B (eNodeB), shown as 129 in Figure 1 .The mobility of the user equipment 130 is controlled by what will here initially be referred to generically as a "mobility management node". The "mobility management node" is in a EUTRAN system referred to as a MME shown as 120 on Figure 1.

The "mobility management node" is connected to a Serving Gateway, an SGW 1 15, which in turn is connected to a PDN Gateway, PGW 1 10. The PGW 1 10 can be connected to a unit or a function for Policy and Charging Rules Function, a so called PCRF 105, or the PGW 1 10 can be arranged to take certain policy and charging actions on its own without the use of a PCRF.

It should be appreciated that although Figure 1 shows a system 200 which is an EUTRAN system, the example embodiments may also be applied in a GERAN/UTRAN system or in systems which combine these two technologies, i.e., combined

GERAN/UTRAN and EUTRAN systems.

The example embodiments presented herein are directed towards providing a mechanism in the Control Plane of 3GPP network elements, e.g. Gn/Gp SGSN, S4- SGSN, MME, SGW, GGSN and PDN-GW, to allow the support of Guaranteed Bit Rates when the services authorized from PCRF require GBR i.e. the corresponding PCC rule contains QoS information including GBR.

Accordingly, some of the example embodiments may be directed towards the classification or marking if Internet Protocol (IP) packets for an intended service. For example, the intended service may be determined by the TDF or PGW based on received PCC rule/QoS rule/ADC rule as is known in the art.ln some of the example embodiments, a TDF or PGW may be configured to provide such markings. Furthermore, these service based markings may be associated with a minimum bit rate (MIB), thus when a base station encounters such IP packets, the base station may provide the packet with GBR treatment if so indicated. Furthermore, some of the example embodiments provided herein may be directed towards the establishment of a TDF-PGW tunneling where information related to such markings, of the IP packets themselves, may be sent in a more efficient manner.

The association of the marking with a MIB may be specified in a related standard specification or provided by an operator of the wireless communication system.

Alternatively or additionally, the association, or mapping, may be determined by the PCRF, PGW/SGW or the like. Next, e.g. the PGW/SGW communicates the mapping to the base station or the like. As an example, the mapping may be in the form of a table, where each row comprises a marking and the MIB associated therewith.

For the purpose of explanation, the example embodiments will be described in two sections. First, example embodiments directed towards a Traffic Detection Function (TDF) providing IP packets with markings according to an intended service will be

discussed. Thereafter, example embodiments directed towards a base station receiving the same IP packets will be discussed.

Traffic Detection Function - Providing Service Identification Markings

A first general concept of some of the example embodiments described under this sub-heading is to provide a mechanism in the Control Plane to systematically create a new QoS handling in a 3GPP network, which is based on the Service Identification comprised in the user plane protocol, e.g., GTP-U header. However, it is intended to keep the basic bearer service, e.g., default bearer/primary PDP context concept to allow that a Core Network(CN)/RAN node may be upgraded seamlessly.

A second general concept of some of the example embodiments described under this sub-heading is to let another network entity such as the TDF, specialized in packet inspection, mark the packets instead of the GW entity hosting PCEF/BBERF functionality. Then the GW with PCEF/BBERF may thereafter copy the packet marking (Service information included in the User Plane protocol header) from the incoming downlink packet to the GTP-U header when forwarding the packet. This provides a further simplification of the GW entity and allows the GW to basically only handle mobility management and session management for 3GPP user equipments, without full

PCEF/BBERF support. The dedicated packet inspection entity (TDF) can also perform charging and other IP level functionality that is not specific to 3GPP accesses. The mechanism may comprise the following example aspects: (an abbreviation to the mechanism: QoS based on Service Information in User Plane protocol is QSUP)

1 . During default bearer establishment/Primary PDP Context activation procedure, the Radio Access Nodes, e.g. RNC, eNB and BSS, may indicate its capability and/or preference to use QSUP, accordingly, it may provide a GTP-U tunnel end point identifier from a specific range, which can be recommended by 3GPP. (From RAN point of view, RNC/eNB may only support GTP-U, and BSC may only support BSSGP)

2. When the PGW receives such information, i.e., capability and/or preference to use QSUP, if QSUP is supported by all downstream nodes, e.g., RNC/eNB and SGW, it may send a PGW QSUP support indication to the PCRF, to allow the PCRF to decide if the QSUP should be used, based on the PGW capability (such as if ADF capable), knowledge about TDF capability (if TDF supports QSUP), PGW load information, Subscription information (such as subscribed service which requires Deep Packet Inspection, rating and so on). It should be appreciated that the PGW load information, PGW QSUP support indication are new information elements which are part of example embodiments described herein.

3. The PGW may also provide to the PCRF information about supported QSUP protocols (between the PGW and TDF), i.e., in the PGW QSUP support indication, the PGW indicate from what user plane protocols it supports to derive Service Information, which is inserted by a standalone TDF (e.g. GTP , IP-in-IP or Generic Routing

Encapsulation (GRE)). The PGW may, e.g., provide this information if the PGW knows that TDF supports QSUP in the user plane, when PGW has no (deeper) packet inspection function or due to load constraint. For GTP, this allows the PCRF to send tunneling protocol identifiers (e.g., PGW SGi F-TEID, where TEID is short for Tunnel End Point Identifier) to the standalone TDF during TDF session establishment procedure, to further extend the GTP-U tunnel to the TDF, as the consequence, the TDF should also provide the uplink F-TEID to the PGW via PCRF over Sd interface and Gx interface.

TDF - PGW interface:

The TDF can the insert the Service Information (SI) into the (tunneling) protocol header for downlink traffic from TDF to PDN GW.

- For GTP-U, the SI can be provided in a GTP-U extension header.

- For IP-in-IP, the SI can be provided in the IPv6 flow label (for IPv6 encapsulation) or IPv4 TOS field (for IPv4 encapsulation)

- For GRE, the SI can be provided in the GRE key option in the GRE tunnel header. S5/S8 reference point:

The PGW can then derive the Service Information from the user plane protocol used between the PGW and TDF, and then copy it into GTP-U header extension on S5/S8 if GTP-U is used between the SGW and PGW; or copy it into the GRE tunnel header in case of GRE tunneling is used between SGW and PGW. And if GRE tunneling is used between SGW and PGW, the SGW need copy the Service Information from GRE tunnel header into GTP-U header extension when forwarding onto S1 -U.

The GRE tunnel header does currently not comprise an Information Element (IE) that can carry the Service Identifier. The GRE key option IE could have been used but since this IE is used for other purposes on S5/S8 it is not a suitable solution. There are two alternative example embodiments that can be used instead:

1 . Re-use part of the GRE Routing option in the GRE tunnel header (e.g. first two octets) to carry the SI. The Routing IE is not widely used today and assuming that there are no NW entities between PGW and SGW that interpret this field it should be possible to re-use the field for SI.

2. Define a new GRE header extension to carry the Service Identification. This would require standardization in Internet Engineering Task Force (IETF). It should be appreciated that this problem does not exist on the interface between

PGW and TDF since there it is possible to use the GRE key option IE to carry SI. When RNC/eNB receives GTP-U packet, it should use Service Information included in the GTP- U header extension to perform Packet forwarding, which is comparable to use QCI as specified in TS 23.401 in ch. 4.7.3 Bearer level QoS parameters below:

"A QCI is a scalar that is 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). A one-to-one mapping of standardized QCI values to standardized characteristics is captured TS 23.203. "This mechanism (QSUP) can be used as standalone QoS differentiation mechanism or as the complement to the Bearer Service concept.

Figure 2 illustrates an example node configuration for a TDF 104 according to some of the example embodiments.As shown in Figure 2, the TDF 104 may

compriseprocessing circuitry 520, a memory 530, radio circuitry 510, and at least one antenna. The radio circuitry may comprise RF circuitry and baseband processing circuitry (not shown). In particular embodiments, some or all of the functionality described herein may be provided by the processing circuitry 520 executing instructions stored on a computer-readable medium, such as the memory 530 shown in Figure 2.Alternative embodiments of the TDF 104 may comprise additional components responsible for providing additional functionality, comprising any of the functionality identified herein and/or any functionality necessary to support the example embodiments described herein.

Figure 3 illustrates a signalling diagram of an Initial Attach procedure in Evolved Universal Terrestrial Radio Access Network (E-UTRAN), according to some of the example embodiments.lt is pre-assumed that GTP-U protocol is used between eNB and PGW, and that the example embodiments extend the GTP-U tunnel to the TDF.lt should be appreciated that the example embodiments are also applicable to the GGSN.

Furthermore, it should be appreciated that other tunneling protocols may be used between the PGW/GGSN and TDF as long as it is possible to mark the packets with Service Information. For example, it should be possible to use GRE tunneling with key extensions, and placing the Service Identifier in the Key Identifier field. Alternatively, user plane IP packets may be forwarded without tunneling between, e.g., for IPv6 user plane by utilizing the IPv6 Flow Label field can be used to carry the Service Identifier.

The messages proposed here are used for depicting the procedure, some messages as specified in ch. 5.3.2.1 E-UTRAN Initial Attach of TS 23.401 are skipped here but they are still valid, the key point here is the new parameters introduced by the solution.lt should be appreciated that the messages below are a non-limiting example. Enhanced Initial Attach procedure in EPS

Message 1 . Here, an initial user equipment message may be sent by the user equipment and received by the MME. The initial user equipment message may be a S1AP Initial user equipment message. The initial user equipment message may be used to establish of the user equipment associated logical S1 -connection towards the CN. The initial user equipment message may indicate and/or provide RAN QSUP capability and/or RAN QSUP preference to use GTP-U header extension to perform QoS

differentiation.Another alternative is to use S1 Setup message with the same or similar properties.

Message 2. The MME may send such RAN QSUP support indication to the SGW/PGW, which receives the same. For example, the MME may provide such RANQSUP capability and/or RAN QSUP preference to use GTP-U header extension to perform QoS differentiation in the Create Session Request message to the SGW/PGW.

It should be appreciated that a new indication in GTP and/or Proxy Mobile IP (PMIP) may be created, to let SGW and PGW exchange their capability on the support to such GTP-U header extension. So the SGW should include such indication when it forwards Create Session Request message to the PGW and PGW should also include such indication in the Create Session Response message.

Message 3. The PGW may send such PGW QSUP support indication to the PCRF, which receives the same. This may e.g. be done by using CCR-lnitial if

downstream nodes support QSUP; at the same time, the PGW may provide its own PGW SGi F-TEID and PGW Load status additionally.

Message 4. The PCRF may send a message, e.g. a TSR message, to the TDF (which receives the message) to setup a TDF session for the specific user equipment.The message may comprise a PGW SGi F-TEID and/or PGW QSUP support indication and/or Service Information if the decision is to request TDF to use QSUP based on various inputs, e.g. Subscribed services and/or PGW load status and/or previous stored TDF load status from last transaction with the TDF.

Message 5. The TDF may reply by sending a message, e.g. a TSA message, to the PCRF (which receives the message.The message may comprise the TDFs own TDF SGi F-TEID and/or TDF QSCU support indication and possible TDF Load Status. (The presence of TDF SGi F-TEID can be treated as confirmation from TDF).

Message 6. The PCRF may send a message to the PGW, which receives the same. The message may comprise TDF SGi F-TEID and/or TDF QSUP support indication and/or indicate how Service Information will be inserted, e.g., in the GTP-U header extension solution, for this PDN connection. If the TDF SGi F-TEID and/or TDF QSUP support indication are not provided, which may mean the TDF doesn't support QSUP but still, a new indication QSUP Activated is provided, the PGW derive Service information may be based on the existing PCC rule parameters, e.g., QCI/ARP if the Service

Information is not explicitly provided in the CCA-lnitial by the PCRF. When the PGW receives downlink IP packets, it may perform packet inspection and insert Service

Information into GTP-U head extension. The TDF QSUP support indication or similar QSUP support indication, may tell the PGW that how the TDF will insert Service

Information to downlink user plane packet, e.g. by an IPv6 flow label. In this case, there is no need for the PGW to perform packet inspection for this PDN Connection (Note: the presence of Service Information, which is a new information element, indicates QSUP may be used. When Service information is explicitly received, it shall be mapped into GTP-U extension header. ).

Message 7. The PGW may send a Create Session Response message with the indication QSUP activated indicating the example embodiments will be used for the PDN connection. The message is received by the MME.

Message 8. The MME may inform theeNB/RNC in the S1AP:INITIAL CONTEXT SETUP REQUEST message/RANAP:RAB Assignment Request messageabout that the GTP-U header extension solution will be used for this PDN and the eNB should be ready to perform QoS differentiation based on Service information received in GTP-U packets. This message is sent by the MME and received by the eNB/RNC.

Message 9. The TDF may perform Packet inspection and insert the Service Information to each IP packets received from PDN if it is required to perform such insertion. This message is sent by the TDF and received by the eNB/RNC.

Message 10. Alternatively, if TDF does not use QSUP, the PGW performs packet inspection and inserts Service Information into each GTP-U packets.

Figure 4 illustrates a wireless communications network with the established TDF- PGW tunnel 103 as discussed above. Figure 5 illustrates a flow diagram depicting general operations which may be taken by the TDF 104 of Figures 3-5 when providing service identification markings in a user protocol header.

Operation 30:

The TDF 104 receives at least one IP packet. Accordingly, the TDF 104 is configured to receive 30 at least one IP packet. As an example, the radio circuitry 510 is configured to receive the at least one IP packet.

Operation 32:

The TDF 104 identifies at least one intended service for the IP packet. Accordingly, the TDF 104 is further configured to identify 32 at least one intended service for the IP packet.As an example, the processing circuitry 520 is configured to identify at least one intended service for the IP packet.

The UE may use many services at the same time, but only part of them are applicable for this mechanism. Therefore, the service applicable to this mechanism is the intended service. E.g. the UE may have internet web browsing and IM simultaneously, but only IM is applicable for this mechanism. The remaining IP packets, i.e. those IP packets not involved in IM, without marking will be treated in the RAN according to prior art, e.g. with least priority and so on.

Operation 34:

The TDF 104 assigns at least one marking according to the at least one intended service.Accordingly, the TDF 104 is further configured to assign 34 at least one marking according to the at least one intended service. The assigned at least one marking is located in a user plane protocol header of the at least one IP packet and the assigned at least one marking (or at least one intended service) is associated with a minimum bit rate (MIB).

As an example, the processing circuitry 520 is configured to assign the at least one marking according to the at least one intended service, where the assigned at least one marking is located in a user plane protocol header of the at least one IP packet and the assigned at least one marking (or at least one intended service) is associated with a minimum bit rate (MIB).

Example Operation 36:

According to some of the example embodiments, the assigning 34 may further comprise retrieving 36 subscription based information from a PCRF 105.The processing circuitry 520 may be configured to retrieve the subscription based information from the PCRF 105.

According to some of the example embodiments, the subscription based information may be provided in the form of a table mapping the at least one marking and the corresponding MIB.lt should be appreciated that the PCRF is used merely as an example and such subscription based information and/or table may be provided by any node in the network. Operation 38:

The TDF 104 sends the at least one IP packet comprising the at least one marking to the base station 129. Accordingly, the TDF 104 is also configured to send 38, to the base station 129, the at least one IP packet comprising the at least one marking.As an example, the radio circuitry 510 is configured to send, to the base station 129, the at least one IP packet. Example Operation 40:

According to some of the example embodiments, the at least one IP packet may be sent to the base station 129 via TDF-PGW tunneling 103. Therefore, the example embodiments may further comprise establishing 40 the TDF-PGW tunneling. The processing circuitry 520 may be configured to establish the TDF-PGW tunneling.

Example Operation 42:

According to some of the example embodiments, the establishing 40 may further comprise receiving 42, from a PCRF 105, a request message to establish a TDF-PGW tunneling session for a specific user equipment 130. The radio circuitry 510 is configured to receive, from the PCRF 105, the request message to establish the TDF-PGW tunneling session for the specific user equipment 130.

According to some of the example embodiments, the request message may comprise at least one of a type of user plane information (e.g. GTP-U, PGW SGI F-TEID), an IP address to set up an IP over an IP tunnel, PGW load information, and/or a PGW support indication to indicate which user plane protocol(s) markings are supported.

According to some of the example embodiments, the request message may further comprise at least one of service information if a decision to establish the TDF-PGW tunneling is based on a subscribed service, load status of the PGW and/or a last stored TDF load status.

Example Operation 44:

According to some of the example embodiments, the TDF 104 may send an acknowledgement message. Accordingly, the TDF 104may be configured to send 44, to the PCRF 105, an acknowledgement message (e.g., TSA). The acknowledgement message may be configured to be sent to the PGW 1 10 from the PCRF 105 to complete the establishment of the TDF-PGW tunneling 103. The radio circuitry 510 may be configured to send, to the PCRF 105, the acknowledgement message (e.g., TSA).

According to some of the example embodiments, the acknowledgement message may comprise at least one of a type of user plane protocol information (e.g. GTP-U TDF SGi T-FEID), an IP address to setup an IP over an IP tunnel, a TDF QSUP support indication, where the TDF QSUP support indication informing the at least one markings will be provided for a PDN connection associated with the specific user equipment. The acknowledgement message may further comprise TDF user plane information, TDF support indication which informs the PGW how the TDF will insert Service Information to downlink user plane packet, e.g. by IPv6 flow label.

According to some of the example embodiments, the acknowledgement message may further comprise instructions on how service information should be inserted, either the PGW derive Service information based on the existing PCC rule parameters, e.g. QCI/ARP if the Service Information is not explicitly provided in the message, e.g. in CCA- Initial by the PCRF. When PGW receives downlink IP packets, it shall perform packet inspection and insert Service Information into GTP-U head extension, or Service information is explicitly provided by the PCRF.

According to some of the example embodiments, it should be appreciated that at least the following lEs are may be created in the RANAP (3GPP TS 25.413 V10.4.0 (201 1 -12) UTRAN lu interface Radio Access Network Application Part (RANAP) signalling (Release 10)) and S1AP (3GPP TS 36.413 v10.4.0 (201 1 -12) E-UTRAN; S1 Application Protocol (S1AP) (Release 10)):

1 . RAN QSUP support indication ((ENUMERATED (Supported, not

Supported)): RAN QSUP preference (ENUMERATED (QSUP Preferred, Bearer QoS preferred)) 2. QSUP activated

3. The QSUP support indication and QSUP preference lEs may be provided in the RANAP/S1AP message, Initial user equipment message (Per lu connection/S1 - MME connection), or/and S1AP message: S1 Setup message (Per eNB message).

It should be appreciated that one example reason to have a QSUP preference IE, is that when RNC/eNB supports both QoS based bearer service and GTP-U header extension, since such two mechanisms require different CPU consumptions/system resource, the first one may need more signaling on the control plane while the latter may require more packet handling on the user plane, so it is reasonable that at certain point, even a RNC/eNB support QSUP mechanism, it may indicate it is not preferred. Though if QSUP support is indicated per lu connection/S1 -MME connection, the CN may still store the QSUP support per RNC/eNB. At least when S1 Setup message is used, such QSUP support capability will be stored per eNB. 4. QSUP activated IE may be provided in S1AP:INITIAL CONTEXT SETUP REQUEST and RANAP: RAB Assignment Request message. This IE may be provided in S1AP: handover request message, Path Switch Request Acknowledge message and RANAP: SRNS Relocation Request message, Enhanced SRNS Relocation Complete Request to cover Active mode mobility case.

According to some of the example embodiments, at least the following lEs may be created in the GTPvl (3GPP TS 29.060 v1 1.1.0 (201 1 -12) General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) across the Gn and Gp interface (Release 1 1 )), GTPv2 (3GPP TS 29.274 v1 1 .1 .0 (201 1 -12) 3GPP Evolved Packet System (EPS);

Evolved General Packet Radio Service (GPRS) Tunnelling Protocol for Control plane (GTPv2-C); Stage 3 (Release 1 1 )) and PMIP (3GPP TS 29.275 vl O.0.0 (201 1 -03) Proxy Mobile IPv6 (PMIPversion 6) based Mobility and Tunnelling protocols; Stage 3 (Release 10)):

1 . RAN QSUP support indication

2. RAN QSUP preferred indication

3. SGW QSCU support indication

4. PGW QSUP support indication

5. SGSN QSUP support indication

6. QSUP activated indication

The RAN QSUP support, RAN QSUP preferred lEs may be provided in the Create Session Request message over S1 1/S4;SGSN QSUP support may also be provided for S4 interface.

The SGW QSUP support IE plus RAN QSUP support IE, RAN QSUP preferred IE and possible SGSN QSUP support indication if S4 is used may be provided in the Create Session Request message over S5/S8.

The PGW QSUP support IE and QSUP activated IE may be provided in the Create Session Response message over S1 1/S4/S5/S8.

And QSUP activated IE may be transferred from Source MME/SGSN to Target

MME/SGSN in the Forward Relocation Request message and Context Response message, this allows the target MME/SGSN to inform the target RAN that QSUP may be used. The QSUP activated IE may be provided in the Modify Bearer Response message to allow the PGW to inform the new SGW that QSUP may be used if the new SGW support QSUP during a SGW relocation procedure.

Echo Request/Response may be used to indicate the support to QSUP feature between the peer entities, e.g. MME and SGW, SGW and PGW.

For PMIP, Heartbeart Request/Response or/and Proxy Binding Request/Response may be used to indicate the support to QSUP feature between the peer entities, which means PMIP entities are able to insert Service Information in the GRE tunnel header as specified above. In addition, a new mobility option QSUP Support can be provided in the PBU message and new mobility option QSUP activated may be provided in the PBA message.

According to some of the example embodiments, at least the following new AVPs may be created in the Gx/Gxx/Sd protocol (3GPP TS 29.212 v1 1.3.0 (201 1 -12) PCC over Gx/Sd reference point (Release 1 1 )):

1 . PGW QSUP Support indication (the indication should not only indicate PGW support QSUP, but may also indicate from what protocol the PGW can extract the Service information, e.g. IPv6 flow label.).

2. TDF QSUP Support Indication (TDF may tell PCRF how it will insert Service Information, using GTP-U, or IPv6 flow label and so on).

3. PGW Load Status

4. SGW Load Status (for Gxx interface and only needed when PMIP is used and GRE header cannot be used to carry Service Information).

5. PGW/GGSN SGi F-TEID (if PGW/GGSN knows that TDF support GTP-U by local configuration).

QSUP Activated

TDF Load status 8. TDF SGi F-TEID 9. Service Information

10. PGW SGi GRE KEY

1 1 . TDF SGi GRE KEY

At least one example reason to introduce PGW/TDF Load status AVP is to allow the PCRF to decide where deep packet inspection should be performed and QSUP if should be used. As mentioned earlier, deep packet inspection consumes a lot of system resources, therefore it is a reasonable approach that the PCRF could use Load status to balance the load between an integrated TDF with PCEF and a standalone TDF.

The Service information can be derived from application services, based on characteristics, e.g. as specified in the Table 6.1.7: Standardized QCI characteristics in TS 23.203.

It should be appreciated that some of the example embodiments presented herein may also have an impact on the user plane between the TDF and the PGW/GGSN. Thus, some of the example embodiments may be used to specify the supported encapsulation protocols and how the Service Identifier may be carried within the protocol(s). In case GTP-U or GRE is used, the same impacts as described above may apply.

The example embodiments described above provide an alternative QoS

mechanism, which can be used as standalone solution or as complement to the existing mechanism which is based on bearer service. The example embodiments described above also simplify a lot the state machine handling in the GTP Control (GTP-C) entities, e.g. SGSN, MME, GGSN, SGW and PGW) since dedicated bearer support can be skipped. Consequently, it saves a lot of network signaling used for

creation/modification/deletion of dedicated bearer context, especially considering GTPvl message is per bearer context.

When QoS based on Bearer Service and QoS based on Service Information in a User plane protocol header are supported in the PGW, it is possible for the PCRF to balance the load between the PCEF and the TDF since QoS based on Bearer Service may need more resources on the control plane and QoS based on Service Information in User plane protocol header may need more user plane resources. By having packet inspection in a dedicated standalone entity (e.g., the TDF) it is possible to simplify the PDN GW. The PDN GW does not need to perform packet inspections and/or classify packets based on, e.g., IP layer or higher layer filters. Instead the PDN GW can perform "tunnel switching" by simply moving the Service Information from the received packet on Gi to the GTP-U header on S5/S8. This is especially valid when GTP is used between TDF and PGW since the F-TEID is used to identify the PDN Connection and there is no need to inspect the destination IP address for downlink traffic.

Base Station Handling of Service Marked IP Packets

A basic concept of the some of the example embodiments described in the following sub-heading is to provide a mechanism in the Control Plane of 3GPP network elements, e.g. Gn/Gp SGSN, S4-SGSN, MME, SGW, GGSN and PDN-GW, to allow the support of Guaranteed Bit Rates when the services authorized from PCRF require GBR, i.e., the corresponding PCC rule contains QoS information including GBR.

The mechanism is comprised of the following aspects:

1. Introduction of a new essential information element Minimum Bit rate (MIB), comprising its uplink and downlink components, which may be similar to the existing QoS parameter MBR (Maximum Bit Rate).

2. The MIB is intended to be associated with a non-GBR bearer, which was established to carry the services not requiring Guaranteed Bitrates. However, when certain services are authorized by the PCRF which are requiring Guaranteed Bitrates support, and if the establishment of dedicated bearer is not possible for the PDN connection, (the above sub-heading related to TDF service markings), the PCRF or the PCEF will then set the minimum bit rate (MIB) for this non-GBR bearer, e.g., default bearer. The MIB denotes that dedicated network resources to satisfy the Minimum Bit Rate (MIB) are allocated (e.g., by an admission control function in the eNodeB) at bearer modification (initiated by the PCRF and/or the PGW, depending in if the MIB is provided in a PCC rule or QoS rule). Since the SGW, when served as BBERF, performs QoS enforcement, so the procedure to set MIB may be initiated by the SGW.

3. The MIB may be associated with a list of Service Information; the number of Service Information in the list could be one or more. When the MIB is associated with multiple types of Service Information (e.g., Service Identifications), one of the services may excess the GBR which it should have. So from an implementation point of view, it is easier for a network entity, to enforce the MIB per SI, so it is better to provide MIB per SI, instead of aggregate into one. Therefore in such situation that there are several GBR services requested by UE, PCRF/PGW may aggregate the MIB assigned for each GBR service, however such MIB can be provided together with MIB for each service to update the default bearer accordingly. For example, MIB may be provided as follows:

MIB(total) [MIB1 for Sl(1 ), MIB2 for Sl(2)...], where MIB(total)=MIB1 +MIB2

The fundamental difference between the concept of GBR and MIB is that GBR is only associated with a GBR bearer, together with a specific QCI which defining how the packet should be forwarded, the GBR defines the scalar that system resources shall be reserved on the bearer level; while the MIB is associated with a non-GBR bearer, and the network elements associated with the PDN connection should use Service Information provided in the GTP-U header extension to perform Packet forwarding instead of using QCI. And also each MIB shall be associated with Service Information (e.g. Service Identification), which are requiring Guaranteed Bit rate.

4. MIB may only supported by the network, the user equipment may not be aware of the MIB, so the procedure to set/modification of MIB may have no impact on the user equipment. Figure 6 illustrates a base station according to some of the example embodiments described herein. As shown in Figure 6, the base station 129 may comprise processing circuitry 420, a memory 430, radio circuitry 410, and at least one antenna. The

processing circuitry 420 may comprise RF circuitry and baseband processing circuitry (not shown). In particular embodiments, some or all of the functionality described above as being provided by a mobile base station, a base station controller, a relay node, a NodeB, an enhanced NodeB, positioning node, and/or any other type of mobile communications node may be provided by the processing circuitry 420 executing instructions stored on a computer-readable medium, such as the memory 430 shown in Figure 6. Alternative embodiments of the base station 129 may comprise additional components responsible for providing additional functionality, comprising any of the functionality identified above and/or any functionality necessary to support the example embodiments described herein.

Figure 7 illustrates a signaling diagram, according to some of the example embodiments, which utilizes a GBR service establishment procedure after the Initial Attach procedure in E-UTRAN. It is pre-assumed that a GTP-U protocol is used between the eNB and the PGW. The idea is independent to Radio Access type and the control plane protocol used in the Packet Core network, i.e. either GTPvl or GTPv2; and in RAN, i.e. BSSGP, S1AP or RANAP.

The messages proposed here are just for depicting the procedures, some messages are skipped here but they are still valid, the key point here is the new parameters introduced by the example embodiments.

Some messages/parameters are reused, which were introduced in the above subheading related to TDA service markings. The detail related QSUP (QoS based on Service Information included in the User Plane protocol) refers to the QSUP discussed the above sub-heading related to TDA service markings.

Establishment of a PDN connection with a default bearer and setting up a GBR service

Message 1 . The S1 AP Initial user equipment message which is used to establish the user equipment associated logical S1 -connection towards the CN may comprise RAN QSUP capability and/or RAN QSUP preference to use GTP-U header extension to perform QoS differentiation (QSUP). Another alternative is to use S1 Setup message. According to some of the example embodiments, the eNBmay indicate the support for MIB as well. Message 1 is sent by the user equipment and received by the MME.

Message 2. The MME may send such RAN QSUP support indication to the SGW/PGW, which receives the same. For example, the MME may provide such RAN QSUP capability and/or RAN QSUP preference to use GTP-U header extension to perform QoS differentiationin the Create Session Request message to the SGW/PGW. According to some of the example embodiments, the MME may indicate support for the MIB as well.

It should be appreciated that a new indication in GTP and/or PMIP may be created, to let the SGW and the PGW exchange their capability on the support to such a GTP-U header extension. So the SGW should provide such indication when it forwards a Create Session Request message to the PGW and the PGW should also provide such indication in the Create Session Response message. According to some of the example

embodiments, a new indication in GTP and/or PMIP may be created, to let the MME, SGW and the PGW exchange their capability on the support of MIB. Message 3. The PGW may send such PGW QSUP support indication to the PCRF, which receives the same. This may e.g. be done by using CCR-lnitial if downstream nodes support QSUP; at the same time, the PGW may provide its own PGW SGi F-TEID and PGW Load status additionally. According to some of the example embodiments, the PGW may send such PGW MIB support indication to the PCRF by using CCR-lnitial if downstream nodes support MIB.

Message 4. The PCRF may provide the PCC rule which is applicable to the default bearer based configured policies. This message is sent by the PCRF to the MME, which receives the same. The PCRF may indicate that QSUP should be used for this PDN Connection.

Message 5. The PGW may send a Create Session Response message with the indication QSUP activated indicating the example embodiments may be used for the PDN connection. The message is received by the MME.

Message 6. The MME may inform the eNB/RNC in the S1AP:INITIAL

CONTEXT SETUP REQUEST message/RANAP:RAB Assignment Request

messageabout that the GTP-U header extension that the example embodiments may be used for this PDN and the eNB should be ready to perform QoS differentiation based on Service information received in GTP-U packets. This message is sent by the MME and received by the eNB/RNC.

Message 7. The user equipment may Initiate Application level signaling on the default bearer which triggers a request for a GBR service.

Message 8. According to some of the example embodiments, the Application Function (AF) may initiate a new Rx session by sending AAR to the PCRF, and provide Service information, where GBR is needed.

Message 9. According to some of the example embodiments, the PCRF may acknowledge the request.

Message 10. According to some of the example embodiments, the PCRF may derive the PCC rule, which may contain the MIB, and associated Service Information (to be inserted into GTP-U header also). If MIB is not supported by the PCRF, the PGW maymap a GBR provided in the QoS information to MIB. If Service Information is not supported over Gx interface, the PGW may map the QCI/ARP to the service information. The PCRF may thereafter send the RAR to provide the PCC rule associated the user equipment requested GBR service.

Message 1 1 . According to some of the example embodiments, the PGW may acknowledge the new authorized PCC rule by replying RAA.

Message 12. According to some of the example embodiments, the PGW may send the Update Bearer Request message providing the MIB, together with Service Information to the SGW/MME.

Message 13. According to some of the example embodiments, the MME may send an E-UTRAN Radio Access Bearer (E-RAB) modify request to the eNBproviding the MIB, together with the Service Information.

Message 14. According to some of the example embodiments, the eNBmay accept the adding of the MIB for the default bearer and reserve system resources for the bandwidth equal to the MIB, and store the associated service information.

Message 15. According to some of the example embodiments, the MME may accept an update of the default bearer by adding the MIB together with associated service information. Message 16. According to some of the example embodiments, the user equipment may start to use this GBR service, where each corresponding downlink packet is marked with Service Information (e.g. Service Identification field), to allow network elements to treat the packet accordingly and each associated network element shall reserve a bandwidth equal to the MIB for each SI that has an associated MIB.

Figure 8 illustrates a flow diagram depicting general operations which may be taken by the base station (or eNB) 129 of Figures 6 and 7 when providing packet handling for service marked packets.

Example Operation 10: According to some of the example embodiments, the base station 129 may send a capability notification to an MME 120. Accordingly, the base station 129 may be configured to send 10 the capability notification to the MME 120. The capability notification may indicate that the base station is configured to identify MIBs. The radio circuitry 410 may be configured to send the capability notification to the MME. According to some of the example embodiments, the capability notification may further comprise instructions for the MME 120, SGW 1 15, and/or the PGW 1 10 to exchange capability information regarding MIB support. Operation 12:

The base station 129 receives at least one IP packet on a bearer. Accordingly, the base station 129 is configured to receive 12 at least one IP packet on the bearer. The IP packet comprises at least one marking (e.g., a service marking) which identifies an intended service of the IP packet. As an example, the radio circuitry 410 is configured to receive the at least one IP packet on the bearer.

According to some of the example embodiments, the at least one marking may be comprised in a user plane protocol header (e.g., a GTP-U header, BSSGP, and/or a UNITDATA PDU). According to some of the example embodiments, the at least one marking may have been inserted in a user plane protocol header by a TDF 104 or a PCRF 105. According to some of the example embodiments, the at least one marking may have been inserted in a user plane protocol header by a PGW 1 10. According to some of the example embodiments, the insertion of the at least one marking may be for the intended service which requires GBR, where the GBR is comprised in an

authorized/received QoS. As an example, at least one marking may be the Service Identification (SI) of the service requiring GBR ina GTP-U extension header according to prior art.

Example Operation 14:

According to some of the example embodiments, the base station 129 may receive at lest one other IP packet with at least one other marking on a same bearer. Accordingly, the base station 129 may be further configured to receive 14 at least one other IP packet with at least one other marking on the same bearer. The at least one other marking is not associated with a MIB. The radio circuitry 410 may be configured to receive the at least one other IP packet with the at least one other marking on the same bearer. Therefore, a same bearer may provide both GBR and non-GBR service. Operation 16:

The base station 129 identifies aservice requiring MIBas GBR, based on the at least one marking. Accordingly, the base station 129 is also configured to identify 16 a servicerequiring MIB as GBR based on the at least one marking. As an example, the processing circuitry 420 is configured to identify the servicerequiring MIB, e.g. as

GBR, based on the at least one marking. The MIB associated with SI is received via control plane signallingas shown in FIGURE 7. The base station may reserve certain resource when it receives the MIB. When the base station receives IP packets belonging to the SI, the reserved resource(s)may be used to deliver the IP packets.

Example Operation 18:

According to some of the example embodiments, the base station 129 may reserve an amount of bandwidth for the at least one IP packet according to the MIB associated with the at least one marking. Accordingly, the base station129 may be configured to reserve 18 the amount of bandwidth for the at least one IP packet according to the MIB associated with the at least one marking. As an example, the processing circuitry 420 may be configured to reserve the amount of bandwidth for the at least one IP packet according to the MIB associated with the at least one marking.

Example Operation 20:

According to some of the example embodiments, the identifying 16 may further comprise analyzing 20 a mapping of the at least one marking and the MIB associated with the at least one marking. The processing circuitry 420 may be configured to analyze the mapping of the at least one marking and the MIB associated with the at least one marking.

According to some of the example embodiments, the mapping may be provided by a table which may be controlled by the PCRF 105 and/or the PGW 1 10. The table may also be maintained in a plurality of network entities on a user plane path (e.g., in the SGW and/or the SGSN).

According to some of the example embodiments, at least the following lEs may be created in the BSSGP (3GPP TS48.018 v10.4.0 (201 1 -12) General Packet Radio Service (GPRS); Base Station System (BSS) - Serving GPRS Support Node (SGSN); BSS GPRS protocol (BSSGP) (Release 10)), RANAP (TS 25.413) and S1AP (3GPP TS 36.413): 1 . RAN MIB support indication ((ENUMERATED (Supported, not Supported))

2. MIB which may comprise a Minimum downlink bit rate, Minimum uplink bit rate and associated Service Information.

According to some of the example embodiments, at least the following lEs may be created in the GTPvl (TS 29.060), GTPv2 (3GPP TS 29.274) and PMIP (3GPP TS 29.275):

1 . MIB support indication

2. MIB which may comprise Minimum downlink bit rate, Minimum uplink bit rate and associated Service Information.

3. Echo Request/Response may be used to indicate the support to MIB feature between the peer entities, e.g. MME and SGW, SGW and PGW.

4. For PMIP, Heartbeat Request/Response or/and Proxy Binding

Request/Response may be used to indicate the support to MIB feature between the peer entities.

According to some of the example embodiments, at least the following new AVPs may be created in the Gx/Gxx/Sd protocol (3GPP TS 29.212):

1 . MIB Support indication 2. MIB which contains Minimum downlink bit rate, Minimum uplink bit rate and associated Service Information.

The example embodiments presented in this sub-heading presesnt a new QoS handling mechanism, to support GBR service in a non-GBR bearer when the

establishment of dedicated bearer is not possible but QSUP is supported for the PDN connection.

Conclusion

Although the description is mainly given for a user equipment, it should be understood by the skilled in the art that "user equipment" is a non-limiting term which means any wireless device or node capable of receiving in DL and transmitting in UL (e.g. PDA, laptop, mobile, sensor, fixed relay, mobile relay or even a radio base station, e.g. femto base station). The example embodiments may apply for non-CA UE or both for user equipments capable and not capable of performing inter-frequency measurements without gaps, e.g. also including user equipments capable of carrier aggregation.

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.

Some example embodiments may comprise a portable or non-portable telephone, media player, Personal Communications System (PCS) user equipment, Personal Data Assistant (PDA), laptop computer, palmtop receiver, camera, television, and/or any appliance that comprises a transducer designed to transmit and/or receive radio, television, microwave, telephone and/or radar signals.

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 nonremovable 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.

A brief description of interfaces used herein is presented here. S1 -MME is a reference point for the control plane protocol between E-UTRAN and MME.S1 -U is a reference point between E-UTRAN and Serving GW for the per bearer user plane tunnelling and inter eNodeB path switching during handover.S3enables user and bearer information exchange for inter 3GPP access network mobility in idle and/or active state. S4 provides related control and mobility support between GPRS Core and the 3GPP Anchor function of Serving GW. In addition, if Direct Tunnel is not established, it provides the user plane tunnelling. S5provides user plane tunnelling and tunnel management between Serving GW and PDN GW. It is used for Serving GW relocation due to UE mobility and if the Serving GW needs to connect to a non-collocated PDN GW for the required PDN connectivity. S6aenables transfer of subscription and authentication data for

authenticating/authorizing user access to the evolved system (AAA interface) between MME and HSS.Gxprovides transfer of (QoS) policy and charging rules from PCRF to PCEF in the PDN GW.S8 is an Inter-PLMN reference point providing user and control plane between the Serving GW in the VPLMN and the PDN GW in the HPLMN. S8 is the inter PLMN variant of S5.S9provides transfer of (QoS) policy and charging control information between the Home PCRF and the Visited PCRF in order to support local breakout function. S10 is a reference point between MMEs for MME relocation and MME to MME information transfer.SH is a reference point between MME and Serving GW.S12 is a reference point between UTRAN and Serving GW for user plane tunnelling when Direct Tunnel is established. It is based on the lu-u/Gn-u reference point using the GTP-U protocol as defined between SGSN and UTRAN or respectively between SGSN and GGSN. Usage of S12 is an operator configuration option. S13enables UE identity check procedure between MME and EIR.SGiis the reference point between the PDN GW and the packet data network. Packet data network may be an operator external public or private packet data network or an intra-operator packet data network, e.g. for provision of IMS services. This reference point corresponds to Gi for 3GPP accesses. Rx is a reference point between the AF and the PCRF in the TS 23.203 [6].

Claims

A method, in a base station (129), for packet handling, the base station (129) being comprised in a wireless communications network (200), the method comprising: receiving (12) at least one Internet Protocol, "IP", packet on a bearer, said IP packet comprising at least one marking which identifies an intended service of the IP packet; and

identifying (16)the intended service requiring a minimum bit rate, "MIB", based on the at least one marking.

The method according to claim 1 , further comprising reserving (18) an amount of bandwidth for the at least one IP packet according to the MIB associated with the at least one marking.

The method according to any one of claims 1 -2, wherein the identifying (16) further comprises analysing (20) a mapping of the at least one marking and the MIB associated with said at least one marking.

The method according to claim 3, wherein said mapping is provided by a table being controlled by a Policy Control Rules Function "PCRF"(105) and/or Packet Gateway "PGW"(110) and maintained in a plurality of network entities on a user plane path.

The method according to any one of claims 1 -4, further comprising receiving (14) at least one other IP packet with at least one other marking on a same bearer, where the at least one other marking is not associated with a MIB.

The method according to any one of claims 1 -5, wherein the at least one marking is comprised in a user plane protocol header.

The method according to any one of claims 1 -6, wherein the at least one marking is inserted into a user plane protocol header by a Traffic Detection Function,

"TDF"(104), node, or a PCRF (105).

The method according to any one of claims 1 -6, wherein the at least one marking is inserted into a user plane protocol header by a PGW (110).

9. The method according to any one of claims 7-8, wherein the insertion of the at least one marking is based on a Guaranteed Bit Rate, "GBR", for the intended service, said GBR being comprised in an authorized/received Quality of Service, "QoS".

5 10. The method according to claims 1 -9, further comprising sending (10) a capability notification to a Mobility Management Entity, "MME"(120), said capability notification indicating that the base station is configured to identify MIBs.

1 1 . The method according to claim 10, wherein the capability notification further

10 comprises instructions for the MME (120), Serving GateWay "SGW"(115), and PGW

(110) to exchange capability information regarding MIB support.

12. A base station (129), for packet handling, the base station (129) configured tobe operatively comprised in a wireless communications network, the base station (129)

15 comprising:

radio circuitry (410) configured to receive at least one Internet Protocol, "IP", packet on a bearer, said IP packet comprising at least one marking which identifies an intended service of the IP packet; and

processing circuitry (420) configured to identify the intended service requiring 20 a minimum bit rate, "MIB", based on the at least one marking.

13. The base station (129) according to claim 12, wherein the processing circuitry (420) is further configured to reserve an amount of bandwidth for the at least IP packet according to the MIB associated with the at least one marking.

25

14. The base station (129) according to any one of claims 12-13, wherein the

processing circuitry (520) is further configured to analysea mapping of the at least one marking and the MIB associated with said at least one marking.

30 15. The base station (129) according to claim 14, wherein said mapping is provided by a table being controlled by a Policy Control Rules Function , "PCRF", (105) and/or a Packet Gateway, "PGW", (110) and maintained in a plurality of network entities on a user plane path.

16. The base station (129) according to any one of claims 12-15, wherein the radio circuitry (510) is further configured to receive at least one other IP packet with at least one other marking on a same bearer, where the at least one other marking is not associated with a MIB.

5

17. The base station (129) according to any one of claims 12-16, wherein the at least one marking is comprised in a user plane protocol header.

18. The base station (129) according to any one of claims 12-17, wherein the at least 10 one marking is inserted into a user plane protocol header by a Traffic Detection

Function, TDF (104), node, or a PCRF (105).

19. The base station (129) according to any one of claims 12-17, wherein the at least one marking is inserted into a user plane protocol header by a PGW (110).

15

20. The base station (129) according to any one of claims 18-19, wherein the insertion of the at least one marking is based on a Guaranteed Bit Rate, "GBR", for the intended service, said GBR being comprised in an authorized/received Quality of Service "QoS".

20

21 . The base station (129) according to claims 12-20, wherein the radio circuitry (510) is configured to send a capability notification to a Mobility Management Entity, "MME"(120), said capability notification indicating that the base station is configured to identify MIBs.

25

22. The base station (129) according to claim 21 , wherein the capability notification further comprises instructions for the MME (120), SGW (115), and PGW (110) to exchange capability information regarding MIB support.

30 23. A method, in a Traffic Detection Function, "TDF"(104), for providing a service

identification marking, the method comprising:

receiving (30) at least one Internet Protocol, IP, packet;

identifying (32) at least one intended service for the IP packet; assigning (34) at least one marking according to the at least one intended 35 service, said assigned at least one marking being located in a user plane protocol header of the at least one IP packet, and said assigned at least one marking being associated with a minimum bit rate, MI B; and

sending (38), to a base station (129), the at least one I P packet. 24. The method according to claim 23, wherein the at least one I P packet is sent to the base station (129) via a TDF- Packet Gateway, "PGW", tunnelling (103).

25. The method according to claim 24, further comprising establishing (40) the TDF- PGW tunnelling (103).

26. The method according to claim 25, wherein the establishing (40) further comprises receiving (42), from a Policy Control Rules Function "PCRF" (105), a request message to establish a TDF-PGW tunnelling session for a specific user equipment (130).

27. The method according to claim 26, wherein the request message comprises at least one of a type of user plane information, an I P address to set up an I P over an I P tunnel, PGW load information, and/or a PGW support indication to indicate which user plane protocol(s) markings are supported.

28. The method according to claim 27, wherein the request message further comprises at least one of service information if a decision to establish the TDF-PGW tunnelling (103) is based on a subscribed service, load status of the PGW and last stored TDF load status.

29. The method according to any one of claims 26-28, further comprising sending (44), to the PCRF (105), an acknowledgment message, said acknowledgement message being configured to be sent to the PGW (1 10) from the PCRF (105) to complete the establishment of the TDF-PGW tunnelling (103).

30. The method according to claim 29, wherein said acknowledgment message

comprises at least one of a type of user plane protocol information, an I P address to setup an I P over an I P tunnel, a TDF QoS based on Service information in User Plane protocol "QSUP" support indication, where said TDF QSUP support indication informs that the at least one markings will be provided for a PDN connection associated with the specific user equipment; the acknowledgement message further comprising TDF user plane information, TDF support indication which informs the PGW how the TDF will insert Service Information to downlink user plane packet.

5 31. The method according to claim 30, wherein the acknowledgment message further comprises instructions on how service information should be inserted, either the PGW derive Service information based on the existing Policy and Charging Control "PCC" rule parameters.

10 32. The method according to any one of claims 24-31 , wherein in the assigning (34)

further comprises retrieving (36) subscription based information from a PCRF.

33. The method according to claim 32, wherein the subscription based information is a table mapping the at least one marking and the MIB.

15

34. A Traffic Detection Function, "TDF"(104), for providing a service identification

marking, the TDF comprising:

radio circuitry (510) configured to receive at least one Internet Protocol, IP, packet;

20 processing circuitry (520) configured to identify at least one intended service for the IP packet;

the processing circuitry (520) further configured to assign at least one marking according to the at least one intended service, said assigned at least one marking being located in a user plane protocol header of the at least one IP packet, and said 25 assigned at least one marking being associated with a minimum bit rate, MIB; and the radio circuitry (510) further configured to send, to a base station (129), the at least one IP packet.

35. The TDF (104) according to claim 34, wherein the at least one IP packet is sent to 30 the base station via a TDF-PGW tunnelling (103).

36. The TDF (104) according to claim 35, wherein the processing circuitry (520) is

further configured to establish the TDF-PGW tunnelling (103).

37. The TDF (104) according to claim 36, wherein the radio circuitry (510) is further configured to receive, from a Policy Control Rules Function "PCRF" (105), a request message to establish the TDF-PGW tunnelling session for a specific user equipment (103).

38. The TDF (104) according to claim 37, wherein the request message comprises at least one of a type of user plane information, an IP address to set up an I P over an I P tunnel, PGW load information, and/or a PGW support indication to indicate which user plane protocol(s) markings are supported.

39. The TDF (104) according to claim 38, wherein the request message further

comprises at least one of service information if a decision to establish the TDF-PGW tunnelling (103) is based on a subscribed service, load status of the PGW (1 10) and last stored TDF load status.

40. The TDF (104) according to any one of claims 37-39, wherein the radio circuitry (510) is further configured to send, to the PCRF (105), an acknowledgment message, said acknowledgement message being configured to be sent to the PGW (1 10) from the PCRF (105) to complete the establishment of the TDF-PGW tunnelling (103).

41 . The TDF (104) according to claim 40, wherein said acknowledgment message

42. The TDF (104) according to claim 41 , wherein the acknowledgment message further comprises instructions on how service information should be inserted, either the PGW derive Service information based on the existing Policy and Charging Control "PCC'rule parameters.

43. The TDF (104) according to any one of claims 34-42, wherein in the processing circuitry (520) is further configured to retrieve subscription based information from a PCRF (105), in the assignment of the at least one marking.

44. The TDF (104) according to claim 43, wherein the subscription based information is a table mapping the at least one marking and the MIB.