WO2015028048A1

WO2015028048A1 - Method and apparatus

Info

Publication number: WO2015028048A1
Application number: PCT/EP2013/067699
Authority: WO
Inventors: Jarkko Henrikki ANSAMAA; Tommy Johannes LINDGREN
Original assignee: Nokia Solutions And Networks Oy
Priority date: 2013-08-27
Filing date: 2013-08-27
Publication date: 2015-03-05

Abstract

A method comprising: at a first apparatus controlling at least one user equipment, communicating information related to said at least one user equipment with a second apparatus; at least some of said information comprised in a message header communicated on a communication tunnel between said first and second apparatus.

Description

Description Title

Method and Apparatus

Some embodiments relate to methods and apparatus and in particular but not exclusively to methods and apparatus for use in communicating user equipment information.

A communication system can be seen as a facility that enables communications between two or more entities such as a communication device, e.g. mobile stations (MS) or user equipment (UE), and/or other network elements or nodes, e.g. Node B or base transceiver station (BTS), associated with the communication system. A communication system typically operates in accordance with a given standard or specification which sets out what the various entities associated with the communication system are permitted to do and how that should be achieved.

Wireless communication systems include various cellular or other mobile communication systems using radio frequencies for sending voice or data between stations, for example between a communication device and a transceiver network element. Examples of wireless communication systems may comprise public land mobile network (PLMN), such as global system for mobile communication (GSM), the general packet radio service (GPRS) and the universal mobile telecommunications system (UMTS).

A mobile communication network may logically be divided into a radio access network (RAN) and a core network (CN). The core network entities typically include various control entities and gateways for enabling communication via a number of radio access networks and also for interfacing a single communication system with one or more communication systems, such as with other wireless systems, such as a wireless Internet Protocol (IP) network, and/or fixed line communication systems, such as a public switched telephone network (PSTN). Examples of radio access networks may comprise the UMTS terrestrial radio access network (UTRAN) and Evolved UMTS terrestrial radio access network (EUTRAN) and the GSM/EDGE radio access network (GERAN).

A geographical area covered by a radio access network is divided into cells defining a radio coverage provided by a transceiver network element, such as a base station or Node B. A single transceiver network element may serve a number of cells. A plurality of transceiver network elements is typically connected to a controller network element, such as a radio network controller (RNC).

A user equipment or mobile station may be provided with access to applications supported by the core network via the radio access network or to locally supported applications.

In a first aspect there is provided a method comprising: at a first apparatus controlling at least one user equipment, communicating information related to said at least one user equipment with a second apparatus; at least some of said information comprised in a message header communicated on a communication tunnel between said first and second apparatus.

Preferably the method comprises a communication tunnel for each of said at least one user equipment.

Preferably the method comprises receiving at least one of subscriber related information and deep packet inspection information from said second apparatus.

Preferably the method comprises sending at least one of location information and information relating to network conditions to said second apparatus. Preferably the information is communicated between said first and second apparatus in an initial message on said communication tunnel.

Preferably the method comprises using the information at the first apparatus for traffic management.

Preferably said traffic management comprises at least one of scheduling and prioritisation of said at least one user equipment.

Preferably the method comprises receiving user data in a payload of said message.

Preferably the method comprises sending a request for said information.

Preferably the method comprises setting a flag in said message header to request said information.

Preferably said header comprises a general packet radio service tunnelling protocol header.

Preferably said subscriber related information comprises charging information.

Preferably said first apparatus comprises a base station. Preferably said apparatus comprises a radio application cloud server.

In a second aspect there is provided a computer program comprising computer executable instructions which when run on one or more processors perform the method of the first aspect.

In a third aspect there is provided an apparatus comprising at least one processor; and at least one memory including computer program code; the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus at least to: communicate information related to at least one user equipment controlled by said apparatus with a second apparatus; at least some of said information comprised in a message header communicated on a communication tunnel between said apparatus and said second apparatus.

Preferably the apparatus comprises a communication tunnel for each of said at least one user equipment.

Preferably the apparatus is configured to receive at least one of subscriber related information and deep packet inspection information from said second apparatus.

Preferably the apparatus is configured to send at least one of location information and information relating to network conditions to said second apparatus.

Preferably the apparatus is configured to communicate said information with said second apparatus in an initial message on said communication tunnel. Preferably the apparatus is configured to use the information for traffic management.

Preferably the apparatus is configured to receive user data in a payload of said message.

Preferably the apparatus is configured to send a request for said information.

Preferably the apparatus is configured to set a flag in said message header to request said information.

Preferably said subscriber related information comprises charging information.

Preferably said apparatus comprises a base station.

Preferably said apparatus comprises a radio application cloud server. In a fourth aspect there is provided an apparatus comprising means for communicating information related to at least one user equipment controlled by said apparatus with a second apparatus; at least some of said information comprised in a message header communicated on a communication tunnel between said apparatus and said second apparatus.

Preferably the apparatus comprises means for receiving at least one of subscriber related information and deep packet inspection information from said second apparatus.

Preferably the apparatus comprises means for sending at least one of location information and information relating to network conditions to said second apparatus.

Preferably the apparatus is configured to communicate said information with said second apparatus in an initial message on said communication tunnel.

Preferably the apparatus comprises means for using the information for traffic management.

Preferably said traffic management comprises at least one of scheduling and prioritisation of said at least one user equipment. Preferably the apparatus comprises means for receiving user data in a payload of said message.

Preferably the apparatus comprises means for sending a request for said information.

Preferably the apparatus comprises means for setting a flag in said message header to request said information.

Preferably said subscriber related information comprises charging information.

Preferably said apparatus comprises a base station.

Preferably said apparatus comprises a radio application cloud server.

In a fifth aspect there is provided a method comprising: at a first apparatus, communicating information related to at least one user equipment with a second apparatus controlling said at least one user equipment; at least some of said information comprised in a message header communicated on a communication tunnel between said first and second apparatus. Preferably the method comprises a communication tunnel for each of said at least one user equipment.

Preferably the method comprises carrying out deep packet inspection at said first apparatus of packets related to said at least one user equipment.

Preferably the method comprises sending at least one of subscriber related information and deep packet inspection information to said second apparatus.

Preferably the method comprises receiving at least one of location information and information relating to network conditions from said second apparatus.

Preferably said traffic management comprises throttling traffic for said at least one user equipment.

Preferably the information is communicated between said first and second apparatus in an initial message on said communication tunnel.

Preferably the method comprises receiving a request for said information.

Preferably the method comprises reading a flag in said message header indicative of said request for information. Preferably said first apparatus is in communication with at least one of a: policy and charging rules function; online charging system; charging gateway.

Preferably said subscriber related information comprises charging information.

Preferably said first apparatus comprises a gateway node.

In a sixth aspect there is provided a computer program comprising computer executable instructions which when run on one or more processors perform the method of the fifth aspect.

In a seventh aspect there is provided an apparatus comprising at least one processor; and at least one memory including computer program code; the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus at least to: communicate information related to at least one user equipment with a second apparatus controlling said at least one user equipment; at least some of said information comprised in a message header communicated on a communication tunnel between said apparatus and said second apparatus.

Preferably the apparatus comprises a communication tunnel for each of said at least one user equipment. Preferably the apparatus is configured to carry out deep packet inspection of packets related to said at least one user equipment.

Preferably the apparatus is configured to send at least one of subscriber related information and deep packet inspection information to said second apparatus.

Preferably the apparatus is configured to receive at least one of location information and information relating to network conditions from said second apparatus.

Preferably the apparatus is configured to use the information for traffic management.

Preferably the apparatus is configured to receive a request for said information.

Preferably the apparatus is configured to read a flag in said message header indicative of said request for information. Preferably said apparatus is in communication with at least one of a: policy and charging rules function; online charging system; charging gateway.

Preferably said subscriber related information comprises charging information.

Preferably said first apparatus comprises a gateway node.

In an eighth aspect there is provided an apparatus comprising means for communicating information related to at least one user equipment with a second apparatus controlling said at least one user equipment; at least some of said information comprised in a message header communicated on a communication tunnel between said apparatus and said second apparatus.

Preferably the apparatus comprises means for carrying out deep packet inspection of packets related to said at least one user equipment.

Preferably the apparatus comprises means for sending at least one of subscriber related information and deep packet inspection information to said second apparatus. Preferably the apparatus comprises means for receiving at least one of location information and information relating to network conditions from said second apparatus.

Preferably the apparatus comprises means for receiving a request for said information.

Preferably the apparatus comprises means for reading a flag in said message header indicative of said request for information.

Preferably said apparatus is in communication with at least one of a: policy and charging rules function; online charging system; charging gateway.

Preferably said header comprises a general packet radio service tunnelling protocol header. Preferably said subscriber related information comprises charging information.

Preferably said first apparatus comprises a gateway node.

Embodiments are described below, by way of example only, with reference to the accompanying drawings, in which:

Figure 1 shows a schematic general overview of a radio access network and a core network according to some embodiments;

Figure 2 shows a schematic overview of a control apparatus according to some embodiments;

Figure 3 shows certain entities of a radio access network according to some embodiments;

Figure 4 shows certain entities of a radio access network according to some embodiments;

Figure 5 shows certain entities of a radio access network according to some embodiments;

Figure 6 shows a GTP-U header according to an embodiment. Embodiments may be used where there are local break-out and off load solutions. This may be in the context of a 3GPP radio environment or any other suitable environment. In some embodiments, applications may be deployed to offload points using for example cloud style application deployments.

Local breakout function may provide a mechanism to serve traffic by local applications. In other words, Internet content or the like is brought to a local breakout point. There are many use cases of localization. By way of example, this may be one or more of a local content delivery network (CDN), local transparent caching, local content optimization for a mobile terminal and/or network, local hosting of other kind of services (used by mobile terminals), and local serving of machine-to-machine (M2M) terminals, for example aggregation functions or the like.

Local breakout may be applied alternatively or additionally to other types of radio networks, such as Wi-Fi, WiMax and Femto network. In such embodiments the offload may be between core network and Internet transit/peering.

Some embodiments may integrate a server module or function into the RAN (Radio Access Network). This application server function may be considered to be a RACS (Radio Applications Cloud Server). It should be appreciated that this application server function may be a cloud server or any other suitable server. The RAN may be provided by one or more entities. In some embodiments, the RAN may comprise a BTS (base transceiver station) to which an RNC (radio network controller) has been integrated or RNC in 3G networks, or an eNB (enhanced Node B) in LTE (Long term Evolution). It should be appreciated that other embodiments may alternatively or additionally be used in conjunction with any other suitable standard or system. The application server function may enable the deployment and hosting of local applications at the RAN side in a virtualization computing environment and/or the applying cloud technologies. The "leaky bearer" offload concept may be applied to gain access to the mobile bearer traffic flows. The traffic flows may be IP traffic flows. By way of example the IP traffic flows may comprise one or more of PDP (packet data protocol) contexts and EPS (evolved packet system) bearers.

Local breakout scenarios are specified in 3GPP release 10 under the name SIPTO (selected IP traffic offload). One of the concepts for 3G networks is the so-called "leaky bearer" traffic flow break-out, also called TOF (Traffic offload). It allows extracting or inserting IP flows of an existing mobile bearer based on activated IP flow traffic filters. This is a flexible break-out concept without involvement of or impact on the UE (user equipment). The concept provides local access to mobile bearer traffic flows and in this way is used for the deployment and execution of applications at the RAN like CDN (content delivery network) solutions, content delivery optimization, caching solutions or others. These local applications may benefit from the proximity to the radio (e.g. location awareness, lower latency) and of having access to radio information, e.g. radio cell load, location, UE's specific radio condition.

It should be appreciated that some embodiments may alternatively or additionally use different local breakout techniques other than those discussed above.

Reference is now made to Figure 1 which shows one example of a schematic architecture. In this example, an application server function 38 (such as a RACS) may be integrated at the RAN 39 level with an off load capability. The applications which may be supported by the architecture may have distributed and centralized components. The network architecture broadly comprises a radio access side 32 and a mobile packet core 34. The radio access side comprises user equipment 1 . The user equipment 1 are configured to communicate with a respective radio access network (RAN). In Figure 1 , first, second and third radio access networks 39 are shown. Each RAN may comprise one or more access nodes. The access nodes may comprise any suitable access node. Depending on the standard involved, the access node may be a base station such as a node B with at least some RNC functionality or an enhanced node B. The latter refers to the Long Term Evolution (LTE) of the Universal Mobile Telecommunications System (UMTS) standardised by 3GPP (Third Generation Partnership Project). A controller for the base stations may be provided. In some standards, the controller may be a radio network controller (RNC). The radio network controller is able to control the plurality of base stations. In other embodiments, a distributed control function is provided and each base station incorporates part of that control function.

Each of the RAN shown in Figure 1 is provided with a server such as an application server function. The application server function 38 may be provided by a separate entity or may be integrated with one or more other entities.

The application server function may be integrated with a base station 39 having at least some RNC functionality and/or RNC or any other type of controller. It should be appreciated that other embodiments are additionally or alternatively envisaged such as where server functionality is integrated into a node of the RAN, for example the RNC or the base station having for example RNC functionality. In some embodiments, a physical realisation would be a RNC/base station plus server in a same integrated hardware. In some embodiments the physical realisation or hardware may be different. A physical realization may be different (for example an integrated one), even though the software functionality may be the same or similar, in some embodiments. The mobile packet core 34 comprises a mobile gateway node 46 and 48. The mobile gateway 46 may be a GGSN (gateway GPRS (General Packet Radio Service) support node) and the mobile gateway 48 may be a packet data network gateway (PDN-GW). These gateways are by way of example. One or more other types of gateway may additionally or alternatively be provided in different embodiments. Only one type of gateway may be provided in some embodiments. More than one type of gateway may be provided in other embodiments.

The mobile packet core 34 also comprises a mobile network control part 54. This part comprises SGSNs (serving GPRS Support Node) and MMEs (mobile management entities) 56 and 58.

In some embodiments, the mobile packet core 34 may comprise a function 60. This function may provide one or more of a lawful intercept function which allows authorised authorities to monitor communications, a policy control function and a charging control function. One or more of these functions may be provided separately and/or in different combinations.

The radio access part 32 is able to communicate with the mobile packet core via connectivity and transport function 62.

The application server function 38 may host applications, which can be accessed by subscribers via leaky bearer traffic offload. For example, a subscriber can access applications hosted by the server 38 via the offload of respective IP flows of the subscriber's mobile bearer to the corresponding application. Figure 2 shows an example of a control apparatus. Such a control apparatus may be incorporated in any one or more of the nodes shown in Figure 1 . For example the control apparatus 300 may be comprised in one or more of base station 39, application server function 38, GGSN 46, PGW 48, Charging Policy LI 60, mobile network control part 54, and entities 56 and 58.

The control apparatus 300 comprises at least one memory 301 , at least one data processing unit 302, 303 and an input/output interface 304. Via the interface 304 the control apparatus can be coupled to a receiver and/or transmitter for reception and transmission of data. For example the control apparatus 300 can be configured to execute an appropriate software code to provide the control functions. The control apparatus may control which path is used and the switching to another path in the event of a path failure. It should be appreciated that this control apparatus may be provided in the application server functionality and/or the eNode B and/or the gateway and may be used to support route selection. This route selection is described in more detail later.

In embodiments the application server function 38 (also referred to as radio applications cloud server (RACS)) may have access to radio information such as cell load or congestion status and location information for a cell or cells associated with the RACS, and in relation to UEs within that cell or those cells.

In a typical implementation the RACS may not be aware of subscriber information such as subscriber identity, subscription type (e.g. prepaid or postpaid), subscriber policies (e.g. access restrictions), and other subscriber related business logic such as remaining data allowance/quota etc. This is because the RACS will not typically be configured to store such information. Accordingly the RACS will not typically be able to differentiate between different user plane packets. In other words all traffic may look the same from the perspective of the RACS. Accordingly since the RACS has limited or no knowledge of the subscribers in some respects, then the possible applications which may be distributed to RAN (implemented in RACS for example) may be restricted.

Subscriber information may be available in the policy charging and rules function (PCRF) (e.g. the charging policy LI 60 in Figure 1 ) and the online charging system (OCS), which may communicate this information to the gateway (GW) upon bearer or context set up.

For implementing differentiated traffic handling at the RACS, such as throttling file sharing traffic during congestion (application aware congestion control), it has been identified by the present inventors that the RACS would need to perform deep packet inspection (DPI) to detect what kind of services are actually being carried by the user plane packets at any particular time.

DPI is a processing intensive function which requires various computing methods as well as protocol signature files to detect and classify service data flows. As applications and services evolve, the signature files require constant updating to be able to detect the latest applications and application protocol version. For example when Facebook® and Skype® change their implementation older DPI signature files cannot detect them. Also since DPI is commonly used for network wide traffic analysis DPI elements tend to be centralised and located at traffic aggregation points, such as mobile gateway/PGW in cellular networks. Thus carrying out the DPI in RACS has been deemed not to be economical. Figure 3 shows a simplified version of a telecommunications network according to an embodiment. Figure 3 shows a user equipment 401 under the control of a base station 438. The base station 438 has RACS functionality as shown at 440. The RACS 440 may be part of base station 438, or may be remotely connected to base station 438. The base station 438 communicates with a mobility management entity (MME) 454 over an S1 -MME interface 410. The base station 438 also communicates with a gateway node (S/PGW) 448 over an S1 -U interface 412. The gateway 448 can communicate with the MME 454 over S1 1 interface 414.

Also shown in Figure 3 is policy and charging rules function (PCRF) 460, online charging system (OCS) 464, and charging gateway (CG) 466. In this embodiment the PCRF 460, OCS 464 and CG 466 are shown as connected to the gateway 448. In other embodiments one or more of the PCRF, OCS and CG may be located within the gateway 448. Either way, the gateway 448 is able to obtain subscriber information from the PCRF 460, OCS 464 and CG 466. It should also be noted that the gateway 448 is capable of DPI, as shown by DPI functionality 468.

It has been identified by the present inventors that to perform one or more of differentiated scheduling and prioritisation, and traffic blocking, the RACS application needs information about the traffic content. As discussed above the RACS does not typically store this information itself. In order to implement new subscriber aware applications in RACS there therefore needs to be an efficient method to propagate the information between the network elements.

It has been known to use bearer Quality of Service class index (QCI) and differentiated services (DIF serve) code points to relay coarse or rough service or subscription information to the entity hosting the RACS, such as an eNB or RNC. Typically DIF serve code points (DSCP) values are used for bearer differentiation as standardised by 3GGP. However DSCP marking is suitable for a limited number of services only.

A system according to an embodiment comprising a base station and a gateway node is shown in Figure 4. It will of course be understood that this system has been simplified for the purposes of explanation.

Figure 4 shows a base station 538 comprising a RACS 540. The base station 538 is connected to an S/PGW node 548 which comprises DPI functionality 568. The base station 538 communicates with the S/PGW over S1 -U interface 512. It will be appreciated that this Figure is simplified for the purposes of explanation and that in other embodiments there may be any number of gateway nodes in communication with any number of base stations. The base station 538 will also be connected to one or more UEs.

According to this embodiment the S/PGW 548 performs DPI analysis on traffic flow associated with a UE (not shown). The S/PGW 548 can then relay the DPI results to the base station 538 and accordingly to RACS 540. As will be explained in more detail below the DPI results can be sent from S/PGW 548 to base station 538 and / or RACS 540 using GPRS tunnelling protocol (GTP) extensions. More particularly GTP-U (GTP-User Plane) extensions may be used. More particularly still, GTP-U may be used in the S1 -U interface, and GTP-C (GTP-Control Plane) may be used in the S1 1 and S1 -MME interfaces.

The RACS 540 can then use the DPI result for traffic management of the UE.

It will be appreciated that embodiments may therefore provide a mostly decentralised policy enforcement architecture by carrying out the DPI analysis in a centralised location at the mobile gateway, and distributing the results for use by RACS entities for traffic management actions. That is the traffic detection and traffic policy enforcement may be separated between entities. More particularly the gateway node may perform the DPI analysis for the user plane data, and the results are distributed alongside the user data to the RACS entities, where enforcement may then be administered.

The way in which the information is propagated from the gateway node to the base station and RACS entity or entities will now be described in more detail.

Figure 5 shows a base station 638 comprising a RACS entity 640 in communication with gateway node S/PGW 648. The S/PGW 648 has DPI functionality as shown at 668. The base station 638 is also in communication with user equipment 601 .

The base station 638 communicates with the S/PGW 648 over S1 -U interface 612.

A second base station 636 comprising RACS entity 637 is also in communication with S/PGW 648 over S1 -U interface 614. The base station 636 is also in communication with UE 601 .

The S/PGW 648 is connected to PCRF 660, OCS 664 and CG 666.

According to the terminology of GTP-U, a message carrying user data is known as G-PDU, and the original user data is known as T-PDU. Accordingly in a G-PDU message, the GTP-U header is followed by T-PDU. In some embodiments G-PDU messages are not acknowledged in the GTP layer in any way. Therefore in some embodiments the only time an indication can be sent as a response may be when a corresponding tunnel no longer exists.

Referring back to Figure 5, the entity hosting RACS (e.g. base stations 636 and 630) and the gateway 648 interact directly via GTP-U protocol. In some embodiments a GTP-U tunnel is created for each subscriber bearer or context to transport user data between the UE 601 and the gateway 648, thus providing a mobility anchor point towards the services and the Internet.

As briefly discussed above the GTP-U tunnel headers can include header extensions. In embodiments the gateway 648 propagates service related information to the base stations 636 and 638 in the GTP-U header extensions. That is information obtained from the results of DPI can be transmitted from the gateway to the RACS in the GTP-U header extensions. In some embodiments this is carried out directly between the gateway 648 and the RACS 640 and/or 637. Again, this can be done on a per subscriber/UE basis. This information can be used in RACS (or the base station) for scheduling and prioritisation purposes. For example software in the base station or RACS can prioritise operator premium content over file transfer. Additionally or alternatively service information can be used to shape or block traffic at the base station level based on a current congestion status. Enabling these functions at the RAN level (e.g. at eNB) can provide a more responsive system that can more quickly adapt to network requirements and/or the requirements of individual users.

The information may be first exchanged upon first GTP-U message between the RACS (or base station or RNC) and the gateway. Upon handover, propagated information can be put into the first GTP-U header for communication with the base station to which control has been handed. The RACS entities in the handover therefore do not need to exchange any information, since it has been or will be propagated in the GTP-U headers. Information can also be transmitted from the RACS 637 and / or 640 or base stations 636 and / or 638 to the gateway 648 in a similar manner. That is the RACS can send information to the gateway 648 in message headers. Such information could, for example, relate to location and / or network conditions such as congestion.

Therefore in embodiments information can be transmitted between entities such as a RACS and a gateway node (in both directions) in an efficient manner. In embodiments this may enable the distribution of functions (such as policy enforcement) between network nodes. Functions may also be executed based on a combination of information. Accordingly, policy actions based on DPI information and congestion status can ultimately be carried out either in RACS or in the GW, once the relevant entity has the necessary information.

As will be discussed in more detail below actual message flows can be implemented either by "always try to exchange the information" or "exchange information upon RACS request" methods.

It will therefore be appreciated that the transport of the DPI result to RACS utilises existing signalling and messaging procedures (i.e. using the headers of existing messages), meaning no new signalling load or messages are required. The user data (T-PDU) may be transported normally as IP payload inside a GTP-U header (G-PDU), and the header may be amended with the exchanged information element.

The information sent from the gateway 648 to the base stations or RACS or RNCs can be added on a per packet basis and can also be configured separately for each subscriber. The gateway node may add service information based on its shallow packet inspection (SPI) and DPI rule configurations.

Implementation of information propagation via GTP-U extension headers can be carried out in at least two ways.

In one embodiment the gateway will send the information to the RACS independently i.e. it does not wait for a request for information. In one embodiment the information is sent with the first downlink (DL) traffic transported in the tunnel for a user (first DL G-PDU). This method may be considered a straightforward "shoot and forget" mechanism. Since G-PDUs are not acknowledged then the GW will not know whether the information sent has reached the RACS, or indeed whether there is a RACS entity present at the GTP tunnel end point. One benefit of this method is that it is simple to implement.

This method may be enhanced by the RACS using the GTP-U signalling message "supported extensions header notification", via which it can notify the GW that it needs the information. In such an embodiment the GW is configured, for each eNB/RNC connected thereto, to remember whether to send the information or not. In such an embodiment the RACS may not be able to send such a notification of whether information is needed on a variable basis e.g. based on time of day or per user.

According to another embodiment the RACS notifies the GW, in the first uplink (UL) traffic transported in the tunnel (G-PDU UL message), that information exchange is requested. In response to this message the GW may then send the necessary information in the first DL traffic (i.e. in the G-PDU DL message). As discussed above this information is obtained at the GW by DPI. If the message does not reach the RACS then the RACS may keep notifying the GW until it has received the information. This implementation therefore provides an error checking mechanism.

The notification from RACS to GW can be sent as GTP-U header extension in the first uplink G-PDU message by setting the "E" flag in the header and including the need for information propagation to GW using a pre-defined "Next Extension Header Type" with zero value. This is shown in more detail in Figure 6.

As shown in Figure 6 the GTP-U header 702 comprises various information elements. The function of each octet 706 and each bit 704 is clearly shown in Figure 6 e.g. the second octet relates to "message type", the third octet relates to message length (of the first octet) etc.

As discussed above when the "E" flag 708 is set, the header 702 includes "Next Extension Header Type" 710 which can be used for informing of the need for information propagation.

In one embodiment the RACS sets bit seven 712 in the Next Extension Header Type 710, such that it requires the gateway node to interpret the header. In such an embodiment if the gateway does not understand the request then it will invoke the 3GGP defined error mechanism by which RACS can be notified about the situation.

Bits 7 and 8 can be configured as shown in table 1 below. The gateway node is configured to interpret these bits in line with the "Meaning" column of table 1 . Bits Meaning

8 7

0 Comprehension of this extension header is not required. An Intermediate 0 Node shall forward it to any Receiver Endpoint

0 Comprehension of this extension header is not required. An Intermediate 1 Node shall discard the Extension Header Content and not forward it to any Receiver Endpoint. Other extension headers shall be treated independently of this extension header.

1 Comprehension of this extension header is required by the Endpoint 0 Receiver but not by an Intermediate Node. An Intermediate Node shall forward the whole field to the Endpoint Receiver.

1 Comprehension of this header type is required by recipient (either 1 Endpoint Receiver or Intermediate Node)

Table 1

As shown in Table 1 when bit 8 is set to 0 then comprehension of the extension header is not required by the receiving (e.g. gateway) node.

If bit 8 is set to 1 then comprehension of the extension header is required at the gateway node. If bit 8 is set to 1 and bit 7 is set to 0 then comprehension of the extension header is required by the end point receiver but not by any intermediate nodes. The intermediate node should forward the whole field to the endpoint receiver.

If both bits 8 and 7 are set to 1 then comprehension of this header is required by the recipient, whether that be the end point receiver or an intermediate node.

When the gateway detects the "information propagation" request as a GTP-U header extension, it then includes, in the next downlink G-PDU, the same "Next Extension Header Type" filled with the required information. Alternatively, the gateway can always send the information, without the RACS specifically requesting it.

In some embodiments the actual information to be exchanged is carried in the extension header content. If all of the required information does not fit in the extension header content, then in embodiments the same extension header type may be used in the following next extension header type. That is the GTP-U header extensions allows chaining of extensions one after another as shown in Table 2 below.

mm i

2 - M EMail) Mr (MM

mi

Table 2

Information elements to be exchanged can include (but are not limited to): international mobile subscriber identity (IMSI); mobile subscriber ISDN number (MISISDN); international mobile station equipment identity (software version number (IMEISV); charging characteristics; quality of service information; whether subscriber is offline or online charged etc.

In embodiments the encoding of the information follows the 3GPP specifications for Gy (online charging) and Gx (policy control) interfaces.

In embodiments the information carried can be encrypted for security reasons. The information may be encrypted with MD5# or another mechanism.

As discussed above in embodiments the service information to be exchanged may be carried in the extension header content. The services may be indicated with a numerical value which may be configurable by the operator. This allows the relay of all applications detected by the SPI and DPI rules in the PGW/GGSM.

Upon receiving the service information the eNB/RACS can apply policies. These policies may be defined by the operator. The eNB/RACS may have the policies stored in its memory. Applications which are not allowed in the operator network or subscriptions can be blocked at the eNB level and depending on congestion level the eNB can prioritise traffic based on service identification, for example prioritising value added services. Accordingly in embodiments operator revenue can be increased. Prioritisation can also be based upon other parameters which the operator may at any one time deem necessary for prioritisation.

In the above, many different embodiments have been described. It should be appreciated that further embodiments may be provided by the combination of any two or more of the embodiments described above.

An appropriately adapted computer program code product or products may be used for implementing the embodiments, when loaded on an appropriate data processing apparatus, for example for determining geographical boundary based operations and/or other control operations. The program code product for providing the operation may be stored on, provided and embodied by means of an appropriate carrier medium. An appropriate computer program can be embodied on a computer readable record medium. A possibility is to download the program code product via a data network. In general, the various embodiments may be implemented in hardware or special purpose circuits, software, logic or any combination thereof. Embodiments of the inventions may thus be practiced in various components such as integrated circuit modules. The design of integrated circuits is by and large a highly automated process. Complex and powerful software tools are available for converting a logic level design into a semiconductor circuit design ready to be etched and formed on a semiconductor substrate.

It is also noted herein that while the above describes exemplifying embodiments of the invention, there are several variations and modifications which may be made to the disclosed solution without departing from the scope of the present invention.

Claims

1 . A method comprising: at a first apparatus controlling at least one user equipment, communicating information related to said at least one user equipment with a second apparatus; at least some of said information comprised in a message header communicated on a communication tunnel between said first and second apparatus.

2. A method as set forth in claim 1 , comprising a communication tunnel for each of said at least one user equipment.

3. A method as set forth in claim 1 or claim 2, comprising receiving at least one of subscriber related information and deep packet inspection information from said second apparatus.

4. A method as set forth in any preceding claim, comprising sending at least one of location information and information relating to network conditions to said second apparatus.

5. A method as set forth in any preceding claim, wherein the information is communicated between said first and second apparatus in an initial message on said communication tunnel.

6. A method as set forth in any preceding claim comprising using the information at the first apparatus for traffic management.

7. A method as set forth in claim 6 wherein said traffic management comprises at least one of scheduling and prioritisation of said at least one user equipment.

8. A method as set forth in any preceding claim, comprising receiving user data in a payload of said message.

9. A method as set forth in any preceding claim, comprising sending a request for said information.

10. A method as set forth in claim 9, comprising setting a flag in said message header to request said information.

1 1 . A computer program comprising computer executable instructions which when run on one or more processors perform the method of any of claims 1 to 10.

12. An apparatus comprising at least one processor; and at least one memory including computer program code; the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus at least to: communicate information related to at least one user equipment controlled by said apparatus with a second apparatus; at least some of said information comprised in a message header communicated on a communication tunnel between said apparatus and said second apparatus.

13. An apparatus as set forth in claim 12, comprising a communication tunnel for each of said at least one user equipment.

14. An apparatus as set forth in claim 12 or claim 13, wherein the apparatus is configured to receive at least one of subscriber related information and deep packet inspection information from said second apparatus.

15. An apparatus as set forth in any of claims 12 to 14, wherein the apparatus is configured to send at least one of location information and information relating to network conditions to said second apparatus.

16. An apparatus as set forth in any of claims 12 to 15, wherein the apparatus is configured to communicate said information with said second apparatus in an initial message on said communication tunnel.

17. An apparatus as set forth in any of claims 12 to 16, wherein the apparatus is configured to use the information for traffic management.

18. An apparatus as set forth in claim 17, wherein said traffic management comprises at least one of scheduling and prioritisation of said at least one user equipment.

19. An apparatus as set forth in any of claims 12 to 18, wherein the apparatus is configured to receive user data in a payload of said message.

20. An apparatus as set forth in any of claims 12 to 19, wherein the apparatus 5 is configured to send a request for said information.

21 . An apparatus as set forth in claim 20, wherein the apparatus is configured to set a flag in said message header to request said information. 0

22. A method comprising: at a first apparatus, communicating information related to at least one user equipment with a second apparatus controlling said at least one user equipment; at least some of said information comprised in a message header communicated on a communication tunnel between said first and second apparatus. 5

23. A method as set forth in claim 22, comprising a communication tunnel for each of said at least one user equipment.

24. A method as set forth in claim 22 or claim 23, comprising carrying out deep o packet inspection at said first apparatus of packets related to said at least one user equipment.

25. A method as set forth in any of claims 22 to 24, comprising sending at least one of subscriber related information and deep packet inspection information to 5 said second apparatus.

26. A method as set forth in any of claims 22 to 25 comprising receiving at least one of location information and information relating to network conditions from said second apparatus.

5

27. A method as set forth in any of claims 22 to 26, comprising using the information at the first apparatus for traffic management.

28. A method as set forth in claim 27 wherein said traffic management 0 comprises throttling traffic for said at least one user equipment.

29. A method as set forth in any of claims 22 to 28, wherein the information is communicated between said first and second apparatus in an initial message on said communication tunnel. 5

30. A method as set forth in any of claims 22 to 29, comprising receiving a request for said information.

31 . A method as set forth in claim 30, comprising reading a flag in said o message header indicative of said request for information.

32. A method as set forth in any of claims 22 to 31 , wherein said first apparatus is in communication with at least one of a: policy and charging rules function; online charging system; charging gateway. 5

33. A computer program comprising computer executable instructions which when run on one or more processors perform the method of any of claims 22 to 32.

34. An apparatus comprising at least one processor; and at least one memory including computer program code; the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus at least to: communicate information related to at least one user equipment with a second apparatus controlling said at least one user equipment; at least some of said information comprised in a message header communicated on a communication tunnel between said apparatus and said second apparatus.

35. An apparatus as set forth in claim 34, comprising a communication tunnel for each of said at least one user equipment.

36. An apparatus as set forth in claim 34 or claim 35, wherein the apparatus is configured to carry out deep packet inspection of packets related to said at least one user equipment.

37. An apparatus as set forth in any of claims 34 to 36, wherein the apparatus is configured to send at least one of subscriber related information and deep packet inspection information to said second apparatus.

38. An apparatus as set forth in any of claims 34 to 37, wherein the apparatus is configured to receive at least one of location information and information relating to network conditions from said second apparatus.

39. An apparatus as set forth in any of claims 34 to 38, wherein the apparatus is configured to use the information for traffic management.

40. An apparatus as set forth in claim 39 wherein said traffic management comprises throttling traffic for said at least one user equipment.

41 . An apparatus as set forth in any of claims 34 to 40, wherein the apparatus is configured to communicate said information with said second apparatus in an initial message on said communication tunnel.

42. An apparatus as set forth in any of claims 34 to 41 , wherein the apparatus is configured to receive a request for said information.

43. An apparatus as set forth in claim 42, wherein the apparatus is configured to read a flag in said message header indicative of said request for information.

44. An apparatus as set forth in any of claims 34 to 43, wherein said apparatus is in communication with at least one of a: policy and charging rules function; online charging system; charging gateway.