WO2015028057A1

WO2015028057A1 - Packet processing in communications

Info

Publication number: WO2015028057A1
Application number: PCT/EP2013/067862
Authority: WO
Inventors: Ville Petteri PÖYHÖNEN; Janne Einari TUONONEN
Original assignee: Nokia Solutions And Networks Oy
Priority date: 2013-08-29
Filing date: 2013-08-29
Publication date: 2015-03-05

Abstract

A method for contextual packet processing in a communications system comprises monitoring (301) in a network apparatus (102), HTTP request messages transmitted from a user terminal (101) and destined to a destination FQDN. A HTTP request message received in the network apparatus (102), is processed (304) to map the destination FQDN to an alternative FQDN, and to map the alternative FQDN to a corresponding destination IP address or to a further alternative FQDN. A HTTP redirect message is received (309) from a core network node (103), regarding a packet marked with a new FQDN based on a packet matching pattern. The destination FQDN is mapped (309) to the new FQDN. The new FQDN is stored (310) as a new packet matching pattern to monitor new HTTP request messages transmitted from the user terminal (101) and destined to the new FQDN.

Description

DESCRIPTION

TITLE PACKET PROCESSING IN COMMUNICATIONS

FIELD OF THE INVENTION

The exemplary and non-limiting embodiments of this invention relate generally to wireless communications networks, and more particularly to packet processing.

BACKGROUND ART

The following description of background art may include insights, discoveries,

understandings or disclosures, or associations together with dis-closures not known to the relevant art prior to the present invention but provided by the invention. Some such contributions of the invention may be specifically pointed out below, whereas other such contributions of the invention will be apparent from their context. In a content distribution network (CDN), CDN content requests specify the content rather than the network address the content is provided from. The same content may be stored in multiple locations/caches for optimised delivery to a requesting user. A specific content item and the location data on the repositories it is provided from may be considered as the context of that content item. SUMMARY

The following presents a simplified summary of the invention in order to provide a basic understanding of some aspects of the invention. This summary is not an extensive overview of the invention. It is not intended to identify key/critical elements of the invention or to delineate the scope of the invention. Its sole purpose is to present some concepts of the invention in a simplified form as a prelude to the more detailed description that is presented later.

Various aspects of the invention comprise a method, apparatuses, and a computer program product as defined in the independent claims. Further embodiments of the invention are disclosed in the dependent claims. An aspect of the invention relates to a method for contextual packet processing in a communications system, the method comprising monitoring, in a network apparatus, HTTP request messages transmitted from a user terminal and destined to a destination FQDN; processing a HTTP request message received in the network apparatus, to map the destination FQDN to an alternative FQDN, and to map the alternative FQDN to a corresponding destination IP address or to a further alternative FQDN; receiving, from a core network node, a HTTP redirect message regarding a packet marked with a new FQDN based on a packet matching pattern; mapping the destination FQDN to the new FQDN; storing the new FQDN as a new packet matching pattern to monitor new HTTP request messages transmitted from the user terminal and destined to the new FQDN.

A further aspect of the invention relates to a first apparatus comprising at least one processor; and at least one memory including a computer program code, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the first apparatus to perform any of the method steps.A still further aspect of the invention relates to a second apparatus comprising at least one processor; and at least one memory including a computer program code, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the second apparatus to monitor HTTP messages transmitted from a first apparatus regarding a user terminal and destined to a destination FQDN; configure respective packet types and packet matching patterns; receive a HTTP redirect message destined to a destination FQDN; mark a packet with a new FQDN based on a packet matching pattern.

A still further aspect of the invention relates to a computer program product comprising program instructions which, when run on a computing apparatus, causes the computing apparatus to perform any of the method steps.

Although the various aspects, embodiments and features of the invention are recited independently, it should be appreciated that all combinations of the various aspects, embodiments and features of the invention are possible and within the scope of the present invention as claimed. BRIEF DESCRIPTION OF THE DRAWINGS

In the following the invention will be described in greater detail by means of exemplary embodiments with reference to the attached drawings, in which

Figure 1 shows a simplified block diagram illustrating exemplary system architecture;

Figure 2 shows a simplified block diagram illustrating exemplary apparatuses; Figure 3 shows a messaging diagram illustrating an exemplary messaging event according to an embodiment of the invention;

Figure 4 shows a schematic diagram of a flow chart according to an exemplary embodiment of the invention; Figure 5 shows a schematic diagram of a flow chart according to an exemplary embodiment of the invention;

Figure 6 shows a schematic diagram of a flow chart according to an exemplary embodiment of the invention. DETAILED DESCRIPTION OF SOME EMBODIMENTS

Presence information may be maintained and delivered either centrally by a presence server and its communication with user terminals (user equipment, UE), or in a distributed manner by maintaining and updating the presence information between individual UEs over peer-to-peer connections. In the distributed implementation, there is an excessive signalling load over the network and, subsequently, drainage of the battery of the user equipment. In the centralised implementation, there is a requirement of dedicated network nodes for management and dissemination of presence information.

An exemplary embodiment discloses storing the presence context neither in a central office nor purely in a device, but in an intelligent base station network element. The intelligent base station acts as a presence server towards the client of a centralised presence service and as a peer towards the client of a P2P presence service. A network of intelligent base stations works as a peer-to-peer network, exchanging the presence information of their UEs by P2P signalling (e.g. P2P SIP signalling, or other protocol signalling used with P2P approach). The proposed implementation may coexist with the two legacy types of presence services.

An exemplary embodiment reduces the network load, especially in the air interface and enables smooth scalability of presence services. It may mediate between the two main presence service types and coexist with the two by only minor additions in the network. An exemplary embodiment may be based on a radio application cloud server (RACS) technology or any other suitable radio application technology. A group of mobile network base stations may be connected as peers in a P2P network.

A typical way to deliver requested CDN content is to use a HTTP redirect function. This may be challenging for provisioning CDN content based on fully qualified domain names (FQDN) since a valid FQDN is typically carried in an original request and the subsequent requests may use other FQDNs that are more reflecting a CDN provider's internal cache/delivery node configuration and load situation.

Therefore, response traffic like HTTP redirect messages carrying an original FQDN are also monitored. This requires L7 DPI type of functionality which is a computationally heavy operation. Such a functionality is already in use in core network side where more HW/SW resources are available compared to access network entities like eNode-B.

However, access network applications like header enrichment (HE) of the radio application cloud server (RACS) concept need to know which packets (requests) are to be processed to properly support HTTP redirects for CDN requests.

An exemplary embodiment discloses response monitoring, for instance, by using the L7 deep packet inspection DPI mechanisms in the core network according to the access network needs, i.e. packet matching patterns are defined so that only correct types of IP packets are inspected in the core network. For each match, the core network informs the access network with the relevant information from the matching packet. This may be done using a separate control signalling or by marking the matching packets between the core and access network.

For example, the header enrichment (HE) application running in a radio application cloud server (RACS) may be configured to monitor and process each HTTP request destined to 'a. com'. The respective packet types and matching patterns are configured in the core network (e.g. packet gateway P-GW). When a HTTP redirect message arrives for 'a. com' to the core network, the packet matches and it is marked and forwarded to the access network. Due to this marking, the HE application receives the packet, parses it and complements its matching patterns with 'cache.com' FQDN. Once this is done, the packet is normally forwarded towards the client (UE). According to standard HTTP client behaviour, a new service request is then issued to 'cache.com', and the new service request is then intercepted and processed based on a standard HE application functionality of RACS.

Thus an exemplary embodiment enables finding out what is the final IP address that UE starts to use in its service session to be contextualized.

An exemplary embodiment relates to downlink monitoring to enable contextual packet processing in access network or base station. Response monitoring may act as an enabler for user's contextual packet processing. An exemplary embodiment involves a combination of RACS and CDN. Content distribution and optimization are becoming more and more important for telecommunications operators in order to optimize transferred content in mobile networks. While operators are just currently starting to study how they may become a part of CDN value chains in between CDN providers and end users, feasible migration path(s) still need to be ensured, where CDN services running as OTT (over to top) services may be economically and technically feasible for operators.

An exemplary embodiment introduces a response monitoring method based on which contextual information may then be applied properly in an access network for the service requests from end users.

When having additional functionality in the access network/base station exploiting contextual information for the services based on HTTP usage, some of the issues are that when is the contextual information used and for which user data plane (uplink) packets.

In order to solve these issues, response monitoring is required. There are two separate cases: i) uplink provisioning is carried out based on the destination FQDNs, and ii) uplink provisioning is carried out based on destination IPs. For the former, DNS response and HTTP response, i.e. HTTP redirect, monitoring is needed to map the defined FQDNs and the destination IPs used in the relevant service requests. For the latter, HTTP redirects need to be monitored. By HTTP redirect the contacted server may instruct the client to use some other server in terms of HTTP URL (where either IP address or FQDN is used) instead. This redirection mechanism breaks a single level indirection between FQDN and IP address by introducing potentially multiple additional indirections. For instance, as single mapping

'www.example.com→ 10.10.10.10' may become in practice 'www.example.com→ www.examplel .cache.com→ 10.10.10.35'. Another example of the issue is YouTube where the FQDN part of the service URL is changing between the original and the final service request.

HTTP redirect is commonly used in nowadays content distribution network (CDN) solutions that are typically implemented as OTT over operators' mobile networks.

Similarly, an operator may implement its own (non-OTT) CDN (either alone or with a 3rd party), and in that case HTTP redirect is also a commonly used technology to do load balancing, for instance. In such an environment, a typical way to deliver the requested content for end users is to use HTTP redirect. This may be problematic for provisioning CDN content based on FQDNs since the valid FQDN is typically carried in the original request and the subsequent requests may use other FQDNs that are more reflecting the

CDN provider's internal cache/delivery node configuration and load situation. Therefore, response traffic like HTTP redirect messages carrying the original FQDN is also monitored. This requires an L7 DPI (layer-7 download provisioning interface) type of functionality which is a computationally heavy operation. However, in current mobile network architectures such a functionality is already in use in core network side where more HW/SW resources are available compared to access network entities like eNode-B. There are certain things that are better suited to be done at access network than in the core network, like functionalities requiring access network specific info such as cell and radio channel specific info that is frequently changing. These functionalities, however, need to know which packets (requests) are to be processed, and in order to, for instance, use header enrichment (HE) RACS application in cases where HTTP redirections are used, it is required that HTTP redirects are properly provisioned and processed.

CDN is an example of an application/service that uses HTTP redirect to enable content transmission. However, it is not the only one. There are also other applications/service (typically relating to caching and/or load balancing) which also use HTTP redirect and an exemplary embodiment is applicable to them too.

An exemplary embodiment enables adding a response monitoring feature, but is not limited only for this scope, but may be used more widely when contextual information exploitation also needs to consider downlink (response) packets/communication. An exemplary embodiment involves a method and an apparatus for implementing response monitoring, for instance, by using L7 DPI mechanisms in the core network according to the access network's needs, i.e. packet matching patterns may be defined so that only correct types of IP packets are inspected in the core network and in case of a search pattern match. For each match, the core network informs the access network with relevant information from the matching packet. This may be done by using separate control signalling or by marking the matching packets between the core and access network. For packet marking, there are basically two options: i) explicitly marked packets (some additional info is added into the packets, e.g. in IP header option), and/or ii) implicit marking via a communication channel specific marking for the matching packets, for instance, by using mechanisms like virtual LAN tagging. For the former, packets may be then inspected using a lower layer DPI in the access network to separate packets not requiring special processing from packets requiring special processing. For the latter, the communication channel from where a packet was received may explicitly indicate whether the packet needs further processing or not. Additionally, the response monitoring may be implemented in a distributed manner, wherein some "computationally lighter" monitoring is done in the access network, e.g. DNS monitoring, and other heavier monitoring is done in the core network where more resources are available.

Exemplary embodiments will now be described more fully hereinafter with reference to the accompanying drawings, in which some, but not all embodiments of the invention are shown. Indeed, the invention may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will satisfy applicable legal requirements. Although the specification may refer to "an", "one", or "some" embodiment(s) in several locations, this does not necessarily mean that each such reference is to the same embodiment(s), or that the feature only applies to a single embodiment. Single features of different embodiments may also be combined to provide other embodiments. Like reference numerals refer to like elements throughout.

The present invention is applicable to any user terminal, network node, server, corresponding component, and/or to any communication system or any combination of different communication systems that support packet processing. The communication system may be a fixed communication system or a wireless communication system or a communication system utilizing both fixed networks and wireless networks. The protocols used, the specifications of communication systems, servers and user terminals, especially in wireless communication, develop rapidly. Such development may require extra changes to an embodiment. Therefore, all words and expressions should be interpreted broadly and they are intended to illustrate, not to restrict, the embodiment.

In the following, different embodiments will be described using, as an example of a system architecture whereto the embodiments may be applied, an architecture based on LTE (or LTE-A) (long term evolution (advanced long term evolution)) network elements, without restricting the embodiment to such an architecture, however. The embodiments described in these examples are not limited to the LTE radio systems but can also be implemented in other radio systems, such as 3G, 4G, 5G, B4G, UMTS (universal mobile

telecommunications system), GSM, EDGE, WCDMA, bluetooth network, WLAN, WiMAX or other fixed, mobile or wireless network. In an embodiment, the presented solution may be applied between elements belonging to different but compatible systems such as LTE and UMTS.

A general architecture of a communication system is illustrated in Figure 1 . Figure 1 is a simplified system architecture only showing some elements and functional entities, all being logical units whose implementation may differ from what is shown. The connections shown in Figure 1 are logical connections; the actual physical connections may be different. It is apparent to a person skilled in the art that the systems also comprise other functions and structures. It should be appreciated that the functions, structures, elements and the protocols used in or for packet processing, are irrelevant to the actual invention. Therefore, they need not to be discussed in more detail here. The exemplary radio system of Figure 1 comprises a network node 102 of a network operator. The network node 102 may include e.g. an LTE/LTE-A base station (eNB), radio network controller (RNC), or any other network element, or a combination of network elements. The network node 102 may be connected to one or more core network (CN) elements 103 such as a PDN gateway (P-GW), mobile switching centre (MSC), MSC server (MSS), mobility management entity (MME), gateway GPRS support node (GGSN), serving GPRS support node (SGSN), home location register (HLR), home subscriber server (HSS), visitor location register (VLR). In Figure 1 , the radio network node 102 that may also be called eNB (enhanced node-B, evolved node-B) or network apparatus of the radio system, hosts the functions for radio resource management in a public land mobile network. Figure 1 shows one or more user equipment 101 located in the service area of the radio network node 102. The user equipment refers to a portable computing device, and it may also be referred to as a user terminal. Such computing devices include wireless mobile communication devices operating with or without a subscriber identification module (SIM) in hardware or in software, including, but not limited to, the following types of devices: mobile phone, smart-phone, personal digital assistant (PDA), handset, laptop computer, tablet. In the example situation of Figure 1 , the user equipment 101 is capable of connecting to the radio network node 102 via a connection 104, and the radio network node 102 is capable of connecting to the network element 103 via a connection 105. Figure 2 is a block diagram of an apparatus according to an embodiment of the invention. Figure 2 shows a user equipment 101 located in the area of a radio network node 102. The user equipment 101 is configured to be in connection with the radio network node 102. The user equipment or UE 101 comprises a controller 201 operationally connected to a memory 202 and a transceiver 203. The controller 201 controls the operation of the user equipment 101. The memory 202 is configured to store software and data. The transceiver

203 is configured to set up and maintain a wireless connection 104 to the radio network node 102. The transceiver 203 is operationally connected to a set of antenna ports 204 connected to an antenna arrangement 205. The antenna arrangement 205 may comprise a set of antennas. The number of antennas may be one to four, for example. The number of antennas is not limited to any particular number. The user equipment 101 may also comprise various other components, such as a user interface, camera, and media player. They are not displayed in the figure due to simplicity. The radio network node 102, such as an LTE/LTE-A base station (eNode-B, eNB) comprises a controller 206 operationally connected to a memory 207, and a transceiver 208. The controller 206 controls the operation of the radio network node 102. The memory 207 is configured to store software and data. The transceiver 208 is configured to set up and maintain a wireless connection to the user equipment 101 within the service area of the radio network node 102. The transceiver 208 is operationally connected to an antenna arrangement 209. The antenna arrangement 209 may comprise a set of antennas. The number of antennas may be two to four, for example. The number of antennas is not limited to any particular number. The radio network node 102 may be operationally connected (directly or indirectly) to another network element 103 of the communication system, such as a PDN gateway (P-GW), a radio network controller (RNC), a mobility management entity (MME), an MSC server (MSS), a mobile switching centre (MSC), a radio resource management (RRM) node, a gateway GPRS support node, an operations, administrations and maintenance (OAM) node, a home location register (HLR), a visitor location register (VLR), a serving GPRS support node, a gateway, and/or a server, via an interface 210. The network element 103 (network node), such as a PDN gateway (P-GW) comprises a controller 21 1 operationally connected to a memory 212, and an interface 213. The controller 21 1 controls the operation of the network element 103. The memory 212 is configured to store software and data. The interface 213 is configured to set up and maintain a connection 105 to the radio network node 102. The embodiments are not, however, restricted to the network given above as an example, but a person skilled in the art may apply the solution to other communication networks provided with the necessary properties. For example, the connections between different network elements may be realized with internet protocol (IP) connections. Although the apparatus 101 , 102, 103 has been depicted as one entity, different modules and memory may be implemented in one or more physical or logical entities. The apparatus may also be a user terminal which is a piece of equipment or a device that associates, or is arranged to associate, the user terminal and its user with a subscription and allows a user to interact with a communications system. The user terminal presents information to the user and allows the user to input information. In other words, the user terminal may be any terminal capable of receiving information from and/or transmitting information to the network, connectable to the network wirelessly or via a fixed connection. Examples of the user terminals include a personal computer, a game console, a laptop (a notebook), a personal digital assistant, a mobile station (mobile phone), a smart phone, a tablet, and a line telephone.

The apparatus 101 , 102, 103 may generally include a processor, controller, control unit or the like connected to a memory and to various interfaces of the apparatus. Generally the processor is a central processing unit, but the processor may be an additional operation processor. The processor may comprise a computer processor, application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), and/or other hardware components that have been programmed in such a way to carry out one or more functions of an embodiment.

The memory 202, 207, 212 may include volatile and/or non-volatile memory and typically stores content, data, or the like. For example, the memory 202, 207, 212 may store computer program code such as software applications (for example for the detector unit and/or for the adjuster unit) or operating systems, information, data, content, or the like for a processor to perform steps associated with operation of the apparatus in accordance with embodiments. The memory may be, for example, random access memory (RAM), a hard drive, or other fixed data memory or storage device. Further, the memory, or part of it, may be removable memory detachably connected to the apparatus.

The techniques described herein may be implemented by various means so that an apparatus implementing one or more functions of a corresponding mobile entity described with an embodiment comprises not only prior art means, but also means for implementing the one or more functions of a corresponding apparatus described with an embodiment and it may comprise separate means for each separate function, or means may be configured to perform two or more functions. For example, these techniques may be implemented in hardware (one or more apparatuses), firmware (one or more

apparatuses), software (one or more modules), or combinations thereof. For a firmware or software, implementation can be through modules (e.g. procedures, functions, and so on) that perform the functions described herein. The software codes may be stored in any suitable, processor/computer-readable data storage medium(s) or memory unit(s) or article(s) of manufacture and executed by one or more processors/computers. The data storage medium or the memory unit may be implemented within the processor/computer or external to the processor/computer, in which case it can be communicatively coupled to the processor/computer via various means as is known in the art.

The signalling chart of Figure 3 illustrates the required signalling. Figure 3 illustrates an exemplary HE application with response monitoring. Figure 3 shows an example where response monitoring according to an exemplary embodiment is used together with HE RACS application. In the example of Figure 3, a HE application running in RACS (radio application cloud server) (e.g. in an access network node 102, such as a LTE/LTE-A- capable base station, eNode-B, eNB 102) is configured to monitor 301 , process 304 (i.e. mark) and forward 305 each HTTP request 303 destined to 'a. com'. The processing step 304 may include two separate cases that complement each other: 1 ) FQDN maps to an alternative FQDN, and 2) FQDN maps to a corresponding IP address. "1 )" may involve either the original FQDN for which the original HTTP request was issued, e.g. 303 in Fig. 3, or it may be a 1 st alternative FQDN mapping to a 2nd alternative FQDN. "2)" may involve that each FQDN option described in "1 )" is valid and the mapping is used for IP address based monitoring, e.g. in eNB 102 in Fig. 3.

An example for )": abc.com -(A)-> def.com -(B)-> 10.10.10.10, where the 1 st mapping (A) is from FQDN to an alternative FQDN and the 2nd one (B) is from an alternative FQDN to a corresponding IP address.

An example for "2)": abc.com -> 10.10.10.10, where there is no alternative FQDNs, thus FQDN just maps to a corresponding IP address.

The respective packet types and matching patterns are configured 302 in the core network (e.g. in a core network node, such as a PDN gateway, P-GW 103). When a HTTP redirect message 306 arrives for 'a. com' to the core network (e.g. to P-GW 103), the packet is matched and it is marked (either explicitly or implicitly) 307 and forwarded 308 towards the access network (e.g. to eNB 102). Due to this marking, the HE application (e.g. in eNB

102) receives 309 the packet and parses 309 it and extends 310 its matching patterns with 'cache.com' FQDN. Once this is done, the packet is normally forwarded 31 1 towards the client (e.g. a user terminal, UE 101 ). According to a standard HTTP client behaviour, a new service request is issued 312 to 'cache.com', which request is then intercepted, processed 313 (i.e. marked) and forwarded 314 based on the "standard" HE application functionality (e.g. in eNB 102).

Alternatively, HTTP redirection parsing may be carried out only in the core network which then issues a new control signal to extend the access network's matching patterns with a new FQDN (cache.com). In other words, HE application monitoring and enriching uplink packets are updated with the new FQDN carried in the HTTP redirect message.

Figure 4 is a flow chart illustrating an exemplary embodiment. An apparatus (e.g. a user terminal, UE 101 ) may be configured to transmit HTTP request 303 destined to 'a. com'. When a HTTP redirect message arrives for 'a. com' to the core network (e.g. to P-GW

103) , the packet is matched and it is marked (either explicitly or implicitly) and forwarded towards the access network (e.g. to eNB 102). Due to this marking, the HE application (e.g. in eNB 102) receives the packet and parses it and extends its matching patterns with 'cache.com' FQDN. Once this is done, the packet is normally forwarded towards the apparatus UE 101 (i.e. the client) which receives the packet in item 402. According to a standard HTTP client behaviour, a new service request is then transmitted 403 to

'cache.com'.

Figure 5 is a flow chart illustrating an exemplary embodiment. An apparatus (e.g. an access network node 102, such as a LTE/LTE-A-capable base station, eNode-B, eNB 102) may be configured to monitor 501 , receive 502, process 503 (i.e. mark) and forward 504 HTTP requests destined to 'a. com' (e.g. based on a HE application running in RACS (radio application cloud server)). The processing 503 may include two separate cases that complement each other: 1 ) FQDN maps to an alternative FQDN, and 2) FQDN maps to a corresponding IP address. "1 )" may involve either the original FQDN for which the original HTTP request was issued, or it may be a 1 st alternative FQDN mapping to a 2nd alternative FQDN. "2)" may involve that each FQDN option described in "1 )" is valid and the mapping is used for IP address based monitoring.

When a HTTP redirect message arrives for 'a. com' to the core network (e.g. to P-GW 103), the packet is matched and it is marked (either explicitly or implicitly) and forwarded towards the access network (e.g. to eNB 102). Due to this marking, the apparatus eNB 102 (e.g. based on the HE application) receives 505 the packet and parses 506 it and extends 507 its matching patterns with 'cache.com' FQDN. Once this is done, the packet is normally forwarded 508 towards the client (e.g. a user terminal, UE 101 ). According to a standard HTTP client behaviour, a new service request is issued to 'cache.com', which request is then intercepted 509, processed 510 (i.e. marked) and forwarded 51 1 e.g. based on the "standard" HE application functionality in the apparatus eNB 102.

Figure 6 is a flow chart illustrating an exemplary embodiment. An apparatus (e.g. a PDN gateway, P-GW 103) may be arranged to configure 601 respective packet types and matching patterns. When a HTTP redirect message arrives 602 for 'a. com' to the core network (i.e. in the apparatus P-GW 103), the packet is matched and it is marked (either explicitly or implicitly) 603 and forwarded 604 towards the access network (e.g. to eNB 102). Alternatively, HTTP redirection parsing may be carried out only in the core network apparatus 103 which then issues a new control signal to extend the access network's matching patterns with a new FQDN (cache.com). In other words, HE application monitoring and enriching uplink packets are updated with the new FQDN carried in the HTTP redirect message.

Figures 1 to 6 show examples of FQDN monitoring and how matching patterns may be extended by new FQDNs. As stated above, in addition to FQDN monitoring also IP addresses may be monitored, or both may be done at the same time, although not shown in Figures 1 to 6.

The steps/points, signalling messages and related functions de-scribed above in Figures 1 to 6 are in no absolute chronological order, and some of the steps/points may be performed simultaneously or in an order differing from the given one. Other functions can also be executed between the steps/points or within the steps/points and other signalling messages sent be-tween the illustrated messages. Some of the steps/points or part of the steps/points can also be left out or replaced by a corresponding step/point or part of the step/point. The apparatus operations illustrate a procedure that may be implemented in one or more physical or logical entities. The signalling messages are only exemplary and may even comprise several separate messages for transmitting the same information. In addition, the messages may also contain other information.

Thus, according to an exemplary embodiment, there is provided a method for contextual packet processing in a communications system, the method comprising monitoring, in a network apparatus, HTTP request messages transmitted from a user terminal and destined to a destination FQDN; processing a HTTP request message received in the network apparatus, to map the destination FQDN to an alternative FQDN, and to map the alternative FQDN to a corresponding destination IP address or to a further alternative FQDN; receiving, from a core network node, a HTTP redirect message regarding a packet marked with a new FQDN based on a packet matching pattern; mapping the destination FQDN to the new FQDN; storing the new FQDN as a new packet matching pattern to monitor new HTTP request messages transmitted from the user terminal and destined to the new FQDN.

According to another exemplary embodiment, there is provided a method for forwarding the packet to the user terminal; receiving a new service request destined to the new FQDN; processing the new HTTP request message received in the network apparatus, to map the new FQDN to the corresponding destination IP address.

According to yet another exemplary embodiment, the network apparatus comprises a header enrichment application running in a radio application cloud server RACS, for monitoring the HTTP request messages. According to yet another exemplary embodiment, the further alternative FQDN is mapped to a corresponding destination IP address.

According to yet another exemplary embodiment, there is provided a method for finding out what is the final IP address that the user terminal is to use in its service session to be contextualized. According to yet another exemplary embodiment, uplink provisioning is carried out based on the destination FQDN, wherein DNS response monitoring and HTTP response monitoring are used to map the new FQDN and the destination IP address used in relevant service requests. According to yet another exemplary embodiment, uplink provisioning is carried out based on the destination IP address, wherein HTTP response monitoring is used to map the new FQDN and the destination IP address used in relevant service requests.

According to yet another exemplary embodiment, there is provided a first apparatus comprising at least one processor; and at least one memory including a computer program code, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the first apparatus to perform any of the method steps.

According to yet another exemplary embodiment, there is provided a second apparatus comprising at least one processor; and at least one memory including a computer program code, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the second apparatus to monitor HTTP messages transmitted from a first apparatus regarding a user terminal and destined to a destination FQDN; configure respective packet types and packet matching patterns; receive a HTTP redirect message destined to a destination FQDN; mark a packet with a new FQDN based on a packet matching pattern.

According to yet another exemplary embodiment, the at least one memory and the computer program code are configured to, with the at least one processor, cause the second apparatus to forward, to the first apparatus, a HTTP redirect message regarding the packet marked with the new FQDN.

According to yet another exemplary embodiment, the at least one memory and the computer program code are configured to, with the at least one processor, cause the second apparatus to update header enrichment application monitoring and enriching uplink packets with the new FQDN to map the destination FQDN to the new FQDN. According to yet another exemplary embodiment, the at least one memory and the computer program code are configured to, with the at least one processor, cause the second apparatus to perform response monitoring by using L7 deep packet inspection DPI mechanisms according to access network's needs, wherein packet matching patterns are defined so that only correct types of IP packets are inspected in the second apparatus. According to yet another exemplary embodiment, the at least one memory and the computer program code are configured to, with the at least one processor, cause the second apparatus to perform packet matching and marking such that, for each match, the second apparatus informs the first apparatus on the matching packet by using separate control signalling or by marking the matching packets between the core and access network.

According to yet another exemplary embodiment, for packet marking, explicitly marked packets are used, wherein packets are inspected using lower layer DPI in the access network to separate packets not requiring special processing from packets requiring special processing.

According to yet another exemplary embodiment, for packet marking, implicitly marked packets are used, wherein the communication channel from which the packet was received explicitly indicates whether the packet needs further processing or not.

According to yet another exemplary embodiment, there is provided a computer program product comprising program instructions which, when run on a computing apparatus, causes the computing apparatus to perform any of the method steps.

It will be obvious to a person skilled in the art that, as the technology advances, the inventive concept can be implemented in various ways. The invention and its embodiments are not limited to the examples described above but may vary within the scope of the claims.

List of abbreviations

CDN content distribution network

DHT distributed hash table

DNS domain name service

HE header enrichment

NRS name resolution system

RACS radio application cloud server

FQDN fully qualified domain name

PDN packet data network

GW gateway

HTTP hypertext transfer protocol

Claims

1. A method for contextual packet processing in a communications system, the method comprising monitoring (301, 501), in a network apparatus (102), HTTP request messages transmitted from a user terminal (101 ) and destined to a destination FQDN; processing (304, 503) a HTTP request message received in the network apparatus (102), to map the destination FQDN to an alternative FQDN, and to map the alternative FQDN to a corresponding destination IP address or to a further alternative FQDN; receiving (309), from a core network node (103), a HTTP redirect message regarding a packet marked with a new FQDN based on a packet matching pattern; mapping (309) the destination FQDN to the new FQDN; storing (310) the new FQDN as a new packet matching pattern to monitor new HTTP request messages transmitted from the user terminal (101) and destined to the new FQDN.

2. A method according to claim 1, characterized by forwarding (311) the packet to the user terminal (101); receiving a new service request destined to the new FQDN; processing (304, 503) the new HTTP request message received in the network apparatus (102), to map the new FQDN to the corresponding destination IP address.

3. A method as claimed in claim 1 or 2, characterized in that the network apparatus (102) comprises a header enrichment HE application running in a radio application cloud server RACS, for monitoring the HTTP request messages.

4. A method as claimed in claim 1,2 or 3, characterized in that the further alternative FQDN is mapped (304, 503) to a corresponding destination IP address.5. A method as claimed in any one of the preceding claims, characterized by finding out what is the final IP address that the user terminal is to use in its service session to be contextualized.

5. A method as claimed in any one of the preceding claims, characterized in that uplink provisioning is carried out based on the destination FQDN, wherein DNS response monitoring and HTTP response monitoring are used to map the new FQDN and the destination IP address used in relevant service requests.

6. A method as claimed in any one of the preceding claims, characterized in that uplink provisioning is carried out based on the destination IP address, wherein HTTP response monitoring is used to map the new FQDN and the destination IP address used in relevant service requests.

7. A first apparatus comprising at least one processor; and at least one memory including a computer program code, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the first apparatus (102) to perform any of the method steps of claims 1 - 6.

8. A second apparatus comprising at least one processor; and at least one memory including a computer program code, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the second apparatus (103) to monitor HTTP messages transmitted from a first apparatus regarding a user terminal (101) and destined to a destination FQDN; configure respective packet types and packet matching patterns; receive a HTTP redirect message destined to a destination FQDN; mark a packet with a new FQDN based on a packet matching pattern.

9. A second apparatus according to claim 8, characterized in that the at least one memory and the computer program code are configured to, with the at least one processor, cause the second apparatus (103) to forward, to the first apparatus, a HTTP redirect message regarding the packet marked with the new FQDN.

10. A second apparatus according to claim 9, characterized in that the at least one memory and the computer program code are configured to, with the at least one processor, cause the second apparatus (103) to update HE application monitoring and enriching uplink packets with the new FQDN to map the destination FQDN to the new FQDN .

11. A second apparatus according to claim 8, 9 or 10, characterized in that the at least one memory and the computer program code are configured to, with the at least one processor, cause the second apparatus (103) to perform response monitoring by using L7 deep packet inspection DPI mechanisms according to access network's needs, wherein packet matching patterns are defined so that only correct types of IP packets are inspected in the second apparatus.

12. A second apparatus as claimed in any one of the preceding claims 8 to 11,

characterized in that the at least one memory and the computer program code are configured to, with the at least one processor, cause the second apparatus (103) to perform packet matching and marking such that, for each match, the second apparatus informs the first apparatus on the matching packet by using separate control signalling or by marking the matching packets between the core and access network.

13. A second apparatus according to claim 12, characterized in that for packet marking, explicitly marked packets are used, wherein packets are inspected using lower layer DPI in the access network to separate packets not requiring special processing from packets requiring special processing.

14. A second apparatus according to claim 12, characterized in that for packet marking, implicitly marked packets are used, wherein the communication channel from which the packet was received explicitly indicates whether the packet needs further processing or not.

15. A computer program product comprising program instructions which, when run on a computing apparatus, causes the computing apparatus to perform a method according to any one of the claims 1 to 6.