Patent Application
20160156753
The present invention generally relates to wireless communication networks, and more specifically relates to a method, apparatus and computer program product for providing an enhanced General Packet Radio Service GPRS Tunnel Protocol GTP Tunnel Endpoint Identifier TEID.
Mobile data transmission and data services are constantly making progress, wherein such services provide various communication services, such as voice, video, packet data, messaging, broadcast, etc. In recent years, Long Term Evolution LTE™ has been specified, which uses the Evolved Universal Terrestrial Radio Access Network E-UTRAN as radio communication architecture according to 3GPP specification.
Such 3GPP network elements, which use GTP-based interfaces, use a TEID value in the GTP header for finding internal process that handle the given communication. During a session setup or modification, each GTP entity sends an own control plane TEID value (TEID-C) to a GTP-C peer, and receives a peer's control plane TEID-C value. In addition to that, GTP entities that support GTP-based user plane, must also send and receive user plane TEID-U values with control plane messages. After such exchange, GTP-U entities (evolved Node B—eNodeB, Serving Gateway—SGW, Packet Gateway—PGW, Radio Network Controller—RNC, Serving GPRS Support Node—SGSN, Gateway GPRS Support—Node GGSN) can exchange uplink UL and downlink DL GTP-U payload. Each user plane bearer is assigned TEID-U value, which is unique in the given GTP-U entity.
Currently, both GTPv1 (GTP Version 1) and GTPv2 (GTP Version 2) TEID values are represented with a 32 bits long number, which provides for around 4 billion values. Modern GTP-U entities typically run on a distributed hardware (e.g. Advanced Telecommunications Computing Architecture ATCA), which is capable of supporting large number of user plane bearers, represented by TEID-Us. Each logical entity (node) in a distributed GTP-U entity typically can handle few millions of TEID-Us, which is significantly less than 4 billion. The problem however is that in a distributed architecture more and more bits from TEID range are required for finding the correct node in a simpler and faster way. So, 32 bits long number no longer looks sufficient and should be extended.
Hence, in view of the above drawbacks, there is a need for providing an enhanced GPRS Tunnel Protocol Tunnel Endpoint Identifier.
Therefore, in order to overcome the drawbacks of the prior art, it is an object underlying the present invention to provide an enhanced GPRS Tunnel Protocol Tunnel Endpoint Identifier.
In particular, it is an object of the present invention to provide a method, apparatus and computer program product for providing an enhanced GPRS Tunnel Protocol Tunnel Endpoint Identifier.
According to the present invention, there is proposed an extension for GTPv1 and GTPv2 TEID values.
According to a first aspect of the present invention, there is provided a method, comprising composing a General Packet Radio Service Tunnel Protocol header, and causing transmission of the General Packet Radio Service Tunnel Protocol header to a network element, wherein the General Packet Radio Service Tunnel Protocol header includes at least one first field comprising Tunnel Endpoint Identifier information, and at least one second field comprising extended user plane Tunnel Endpoint Identifier information.
According to a second aspect of the present invention, there is provided an apparatus, which comprises a processing means adapted to compose a General Packet Radio Service Tunnel Protocol header, and a transmission means adapted to cause transmission of the General Packet Radio Service Tunnel Protocol header to a network element, wherein the General Packet Radio Service Tunnel Protocol header includes at least one first field comprising Tunnel Endpoint Identifier information, and at least one second field comprising extended user plane Tunnel Endpoint Identifier information.
According to a third aspect of the present invention, there is provided a computer program product comprising computer-executable components which, when the program is run, are configured to carry out the method according to the first aspect.
Advantageous further developments or modifications of the aforementioned exemplary aspects of the present invention are set out in the dependent claims.
According to certain embodiments of the present invention, the extension is achieved by using extended TEID-U range across Gn/Gp interfaces (tunnel setup with GTPv1-C).
According to certain embodiments of the present invention, the extension is achieved by using extended TEID-U range across GTP-based S5/S8 and S2b/S2a interfaces (tunnel setup with GTPv2).
Further, according to certain embodiments of the present invention, the extension is achieved by using extended TEID-U range across GTP-based S1-U interface (tunnel setup with GTPv2 via S11 and with S1AP across S1-MME).
Still further, according to certain embodiments of the present invention, the extension is achieved by using extended TEID-U range across GTP-based S4 interfaces (tunnel setup with GTPv2).
Further, according to certain embodiments of the present invention, the extension is achieved by using extended TEID-U range across GTP-based S12 interface (tunnel setup with GTPv2 via S4-C and with RANAP across Iu-PS).
For a more complete understanding of example embodiments of the present invention, reference is now made to the following descriptions taken in connection with the accompanying drawings in which:
Exemplary aspects of the present invention will be described herein below. More specifically, exemplary aspects of the present invention are described hereinafter with reference to particular non-limiting examples and to what are presently considered to be conceivable embodiments of the present invention. A person skilled in the art will appreciate that the invention is by no means limited to these examples, and may be more broadly applied.
It is to be noted that the following description of the present invention and its embodiments mainly refers to specifications being used as non-limiting examples for certain exemplary network configurations and deployments. Namely, the present invention and its embodiments are mainly described in relation to 3GPP specifications being used as non-limiting examples for certain exemplary network configurations and deployments. As such, the description of exemplary embodiments given herein specifically refers to terminology which is directly related thereto. Such terminology is only used in the context of the presented non-limiting examples, and does naturally not limit the invention in any way. Rather, any other network configuration or system deployment, etc. may also be utilized as long as compliant with the features described herein.
Hereinafter, various embodiments and implementations of the present invention and its aspects or embodiments are described using several alternatives. It is generally noted that, according to certain needs and constraints, all of the described alternatives may be provided alone or in any conceivable combination (also including combinations of individual features of the various alternatives).
Firstly, a solution for the serving gateway SGW and packet gateway PGW according to certain embodiments of the present invention is described.
That is, according to certain embodiments of the present invention, an extended TEID-U range across Gn/Gp interfaces (tunnel setup with GTPv1-C) is used.
In the following, the extended TEID coding according to the present embodiment is described.
For extending TEID value range, either N-PDU Number field in GTPv1 header can be used, as illustrated in
Using N-PDU Number field may be more appealing, because SGSN never sends anything meaningful with N-PDU Number field to GGSN and vice versa. The only limitation with this approach is that Create/Update packet data protocol PDP Context Request messages contain two TEID values: TEID-C and TEID-U. So, N-PDU Number field must be used for extending only TEID-U range. So, semantically modified GTPv1 header may look as is schematically shown in
In
The above solution will extend TEID-U range to 40 bits (up to 1 trillion values) and requires low standardization efforts.
Next, exchanging extended TEIDs via control plane according to the present embodiment is described.
Without Direct Tunnel deployment, it is easy to implement and use the new feature for nonroaming cases. Only a few of SGSNs and GGSNs are provided in a public land mobile network PLMN, so that an operator can easily configure SGSNs (which support the extended TEID-U feature) to know which GGSNs also support this feature. So, such SGSN will send own extended TEID-U only to such GGSNs as follows:
GGSN will return own extended TEID-U in a similar way:
After this, G-PDU (GTP-U user plane packets) headers between such SGSN and GGSN will contain five octets long destination TEID-U in octets 5 to 8 and 11.
If Direct Tunnel is used, then SGSN needs to know which Radio Network Controller RNC and which GGSNs support the feature to negotiate extended TEID-Us between these. A solution for such scenarios may not be practically feasible, because instead of upgrading Gn/Gp SGSNs to new features, operators typically upgrade them to support S4-SGSn functionality.
Further, according to certain embodiments of the present invention, an extended TEID-U range across GTP-based S5/S8 and S2b/S2a interfaces (tunnel setup with GTPv2) is used.
In the following, the extended TEID coding according to the present embodiment is described.
During a session setup and modification, user plane F-TEID values are exchanged between SGW/ePDG/Trusted-AP and PGW. Currently, 3GPP TS 29.274 specifies the coding of this IE as is schematically shown in
According to certain embodiments of the invention the TEID field (octets 6 to 9) is extended with three octets from k to (k+2), so that the overall F-TEID value becomes a multiple of 4, as is illustrated in
As is shown in
So, the overall length of the TEID field will become 54 bits, which is a value range up to around 72×10̂15.
Backward compatibility requires that the Length field (octets 2 to 3) should be used for telling new coding form the old one. Legacy GTPv2 entities will simply ignore extended TEID filed in octets e to (e+2). Other option could be using one of the spare bits in octet 4, but many implementations have hard coded handling of the first, common 4 octets of GTPv2 IEs.
Next, exchanging extended TEIDs via control plane according to the present embodiment is described.
All GTPv2 messages across S5/S8 and S2b/S2a interfaces contain a F-TEID field. It is desirable that GTP-C entity, which initiates procedure, knows if the peer supports extended TEID, or not. This can be achieved by adding a new flag to GTPv2 Node Features IE type, as is schematically shown in
The following table shows the Node Features on GTPv2 interfaces according to certain embodiments of the present invention, with the new feature octet/bit 5/4 comprising the extended TEID support indication.
A further option is sending an interim extended TEID and awaiting for the response. If the response does not contain extended TEID, this means the peer does not support the feature and the originator needs to revert to 32 bits long TEIDs. This option is less appealing.
Still further, according to certain embodiments of the present invention, an extended TEID-U range across GTP-based S1-U interface (tunnel setup via S11) is used.
In the following, the extended TEID coding according to the present embodiment is described.
During a session setup and modification, user plane F-TEID values must be exchanged between SGW and eNodeB, but these nodes do not have a direct control plane interface. In order to setup user plane between SGW and eNodeB (S1-U), the Mobility Management Entity MME needs to communicate with SGW across S11 (GTPv2) and also with eNodeB across S1-MME (S1 Application Protocol S1AP) interfaces.
The extended TEID coding for GTPv2 is the same as in the previous embodiment. However, the S1AP part is different. 3GPP TS 36.413 specifies GTP-TEID ASN-1 type, which is 4 octets long:
So, either new ASN.1 type should be added to 3GPP TS 36.413, or the exiting type may be modified. Therefore, either of the following may be adapted:
Next, exchanging extended TEIDs via control plane according to the present embodiment is described.
The GTPv2 part is the same as in preceding embodiment. The only difference is that ‘S11’ must be added to “52a, S2b, S5, S8” in the above table.
The problem with S11 interface solution is that before sending Create Session Request to an SGW, the MME must know if the eNodeB supports the extended TEIDs. The reason is that if the SGW returns an extended TEID-U with Create Session Response, but the eNodeb does not support that, then the subsequent E-RAB SETUP REQUEST to eNodeB will fail. This problem can be solved by configuring the MME with the knowledge that all eNodeBs in the PLMN support this feature. Otherwise, the MME should never send an ‘ETSI’ flag to the SGW.
Another alternative is configuring the MME with a knowledge which eNodeB supports the feature and which does not.
Still further, according to certain embodiments of the present invention, an extended TEID-U range across GTP-based S4-U, or S12 interfaces (tunnel setup via S4-C) is used.
In the following, the extended TEID coding according to the present embodiment is described.
During a session setup and modification, user plane F-TEID values must be exchanged between SGW and S4-SGSN or RNC. In order to setup user plane between SGW and RNC (S12), the S4-SGSN needs to communicate with SGW across S4 (GTPv2) and also with RNC across Iu-PS (RANAP) interfaces.
The extended TEID coding for GTPv2 is the same as in the previous embodiment. However, the RANAP part is different. 3GPP TS 25.413 specifies GTP-TEI ASN.1 type, which is 4 octets long:
So, either new ASN.1 type may be added to 3GPP TS 25.413, or the exiting type may be modified. Therefore, either of the following may be adapted:
Next, exchanging extended TEIDs via control plane according to the present embodiment is described.
GTPv2 part is the same as in the previous embodiment. The only difference is that ‘S4’ and ‘S12’ must be added to “S2a, S2b, S5, S8” in the above Table.
The problem with S12 interface solution is that before sending a Create Session Request to an SGW, the S4-SGSN must know if the RNC supports the extended TEIDs. The reason is that if the SGW returns extended TEID-U with Create Session Response, but RNC does not support that, then the subsequent RAB SETUP REQUEST to RNC will fail. This problem can be solved by configuring the S4-SGSN with the knowledge that all RNCs in the PLMN support this feature. Otherwise, the S4-SGSN should never send ‘ETSI’ flag to SGW.
Another alternative is to configure the S4-SGSN with a knowledge which RNC supports the feature an, but that's quite challenging, because of a large number of RNCs.
Matters that are Common for GTPv1 and GTPv2 Based Networks
In Step S71, a General Packet Radio Service Tunnel Protocol header is composed, which includes at least one first field comprising Tunnel Endpoint Identifier information, and at least one second field comprising extended user plane Tunnel Endpoint Identifier information.
In Step S72, transmission of the General Packet Radio Service Tunnel Protocol header to a network element is caused.
The apparatus 80 comprises a processing means 81 adapted to compose a General Packet Radio Service Tunnel Protocol header, and a transmission means 82 adapted to cause transmission of the General Packet Radio Service Tunnel Protocol header to a network element. The General Packet Radio Service Tunnel Protocol header includes at least one first field comprising Tunnel Endpoint Identifier information, and at least one second field comprising extended user plane Tunnel Endpoint Identifier information.
Implementations may support all of the above options, but the simplest ones are:
The present invention addresses method, apparatus and computer program product for providing an enhanced GPRS Tunnel Protocol Tunnel Endpoint Identifier. There is proposed an extension for GTPv1-U TEID-U values by using extended TEID-U range across Gn/Gp interfaces (tunnel setup with GTPv1-C).
There is another proposal for extending both GTPv2 TEID-C values and also linked GTPv1-U TEID-U values by using extended TEID ranges across GTP-based S5/S8 and S2b/S2a interfaces (tunnel setup with GTPv2), by using extended TEID-U range across GTP-based S1-U interface (tunnel setup via S11) and/or by using extended TEID-U range across GTP-based S4-U, or S12 interfaces (tunnel setup via S4-C).
It is to be noted that embodiments of the present invention may be implemented as circuitry, in software, hardware, application logic or a combination of software, hardware and application logic. In an example embodiment, the application logic, software or an instruction set is maintained on any one of various conventional computer-readable media. In the context of this document, a “computer-readable medium” may be any media or means that can contain, store, communicate, propagate or transport the instructions for use by or in connection with an instruction execution system, apparatus, or device, such as a computer or smart phone, or user equipment.
As used in this application, the term “circuitry” refers to all of the following: (a) hardware-only circuit implementations (such as implementations in only analog and/or digital circuitry) and (b) to combinations of circuits and software (and/or firmware), such as (as applicable): (i) to a combination of processor(s) or (ii) to portions of processor(s)/software (including digital signal processor(s)), software, and memory(ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions) and (c) to circuits, such as a microprocessor(s) or a portion of a microprocessor(s), that require software or firmware for operation, even if the software or firmware is not physically present. This definition of ‘circuitry’ applies to all uses of this term in this application, including in any claims. As a further example, as used in this application, the term “circuitry” would also cover an implementation of merely a processor (or multiple processors) or portion of a processor and its (or their) accompanying software and/or firmware. The term “circuitry” would also cover, for example and if applicable to the particular claim element, a baseband integrated circuit or applications processor integrated circuit for a mobile phone or a similar integrated circuit in server, a cellular network device, or other network device.
The present invention relates in particular but without limitation to mobile communications, for example to environments under LTE™ or LTE-Advanced, and can advantageously be implemented also in controllers, base stations, user equipments or smart phones, or personal computers connectable to such networks. That is, it can be implemented e.g. as/in chipsets to connected devices.
If desired, the different functions discussed herein may be performed in a different order and/or concurrently with each other. Furthermore, if desired, one or more of the abovedescribed functions may be optional or may be combined.
Although various aspects of the invention are set out in the independent claims, other aspects of the invention comprise other combinations of features from the described embodiments and/or the dependent claims with the features of the independent claims, and not solely the combinations explicitly set out in the claims.
It is also noted herein that while the above describes example embodiments of the invention, these descriptions should not be viewed in a limiting sense. Rather, there are several variations and modifications which may be made without departing from the scope of the present invention as defined in the appended claims.
The following meanings for the abbreviations used in this specification apply:
eNodeB evolved Node B (base station in LTE)
IPv4 Internet Protocol version 4
IPv6 Internet Protocol version 6
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/EP2013/059009 | 4/30/2013 | WO | 00 |
