Patent Publication Number: US-9419896-B2

Title: Differentiated handling of data traffic with user-class dependent adaptation of network address lookup

Description:
CROSS REFERENCE TO RELATED APPLICATION(S) 
     This application is a 35 U.S.C. §371 National Phase Entry Application from PCT/EP2011/065664, filed Sep. 9, 2011, designating the United States, the disclosure of which is incorporated herein in its entirety by reference. 
     TECHNICAL FIELD 
     The present invention relates to methods for differentiated handling of network traffic and to corresponding network devices and network systems. 
     BACKGROUND 
     In communication networks, differentiated handling of data traffic may be used to distinguish between different classes of data traffic. For example, a forwarding treatment of data packets, i.e., the way of forwarding a data packet on the way towards its destination, may be controlled to provide a certain Quality of Service (QoS) level, which depends on the traffic class. In other examples, the handling of the data traffic may also be differentiated with respect to charging, i.e., one traffic class could be charged in a different manner than another. Typically, traffic classification rules, e.g., packet classification rules, are defined so as to implement the differentiation between different classes of data traffic. 
     For example, in mobile communication networks data traffic related to a specific service may be directed to a bearer offering a certain QoS level. In this respect, a bearer is considered to be an information transmission context or path of defined characteristics, e.g. capacity, delay and/or bit error rate. Typically, a number of bearers will be established between a gateway of a mobile communication network and a user equipment (UE), e.g. a mobile phone or other type of mobile terminal. A bearer may carry downlink (DL) data traffic in a direction from the network to the user equipment, and may carry data traffic in an uplink (UL) direction from the user equipment to the network. In the gateway and in the user equipment the data traffic, which includes a plurality of IP data packets (IP: “Internet Protocol”, which can be the IP Version 4, also referred to as IPv4, or the IP Version 6, also referred to as IPv6) can be filtered, e.g. using IP 5-tuple packet filters, thereby directing the IP data packets to a desired bearer. According to the 3GPP (Third Generation Partnership Project) Technical Specifications (TSs) 23.060 and 24.301, a set of packet filters used to direct the data traffic to a certain bearer is also referred to as a Traffic Flow Template (TFT). In this context, the TFT can be considered as an example of a packet classification rule. 
     Differentiated handling of data traffic may also be useful in other types of communication network environment, e.g., using fixed access technology such as DSL (Digital Subscriber Line), fibre optical access or coaxial cable access. 
     Further, it is also desirable to apply differentiated handling to data traffic related to specific network resources. For example, data traffic related to a certain network resource, e.g., to a certain internet service or to a certain content provider, may be known to require a specific QoS level. However, it may in some cases be hard to decide on the basis of the data traffic itself which handling is required. Problems may also arise if a large number of specific network resources need to be covered, which in turn may use a variety of different network addresses. Therefore rather complex traffic classification rules would need to be defined in order to take into account a large number of arbitrary network addresses. This may specifically be problematic when considering that in some communication network environments there exist limits on the complexity of the traffic classification rules. For example, the 3GPP TSs limit the maximum number of packet filters which can be installed in a TFT of the UE. In addition to differentiating between different network resources, it may also be desirable to differentiate between different users of such network resources, e.g., between a premium subscriber and a normal subscriber of an internet service. 
     Accordingly, there is a need for techniques which allow for efficient differentiated handling of network traffic related to a specific network resource having different classes of users. 
     SUMMARY 
     According to an embodiment of the invention, a method differentiated handling of data traffic between a user and a network resource is provided. The data traffic is preceded by a lookup procedure for obtaining a network address of the network resource. According to the method, a message of the lookup procedure is processed depending on a class of users to which the user belongs. If the user belongs to a first class of users, the message of the lookup procedure is processed for adapting the lookup procedure to return a first network address of a replacement network resource capable of handling the data traffic. If the user belongs to a second class of users, processing the message of the lookup procedure is processed for adapting the lookup procedure to return a second network address of a replacement network resource capable of handling the data traffic. The second network address is different from the first network address. The first network address matches a packet filter for directing the data traffic to a bearer and the second network address does not match this packet filter. 
     According to a further embodiment of the invention, a network device for differentiated handling of data traffic between a user and a network resource is provided. The network device is provided with an interface for receiving a message of a lookup procedure for obtaining a network address of the network resource. Further, the network device is provided with a processor. The processor is configured to process the received message depending on a class of users to which the user belongs: If the user belongs to a first class of users, the processor processes the message of the lookup procedure for adapting the lookup procedure to return a first network address of a replacement network resource capable of handling the data traffic. If the user belongs to a second class of users, the processor processes the message of the lookup procedure for adapting the lookup procedure to return a second network address of a replacement network resource capable of handling the data traffic. The second network address is different from the first network address. The first network address matches a packet filter for directing the data traffic to a bearer. The second network address does not match this packet filter. 
     According to a further embodiment of the invention, a network system for differentiated handling of data traffic between a user and a network resource is provided. The data traffic is preceded by a lookup procedure for obtaining a network address of the network resource. The network system comprises at least one communication device and a network device. The at least one communication device comprises a packet filter for directing the data traffic to a bearer. The network device is configured to process a message of the lookup procedure depending on a class of users to which the user belongs: If the user belongs to a first class of users, the network device processes the message of the lookup procedure for adapting the lookup procedure to return a first network address of a replacement network resource capable of handling the data traffic. If the user belongs to a second class of users, the network device processes the message of the lookup procedure for adapting the lookup procedure to return a second network address of a replacement network resource capable of handling the data traffic. The second network address being different from the first network address. The first network address matches the packet filter and the second network address does not match the packet filter. 
     According to further embodiments, other methods, devices, or computer program products for implementing the methods may be provided. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  schematically illustrates a communication network environment in which concepts according to embodiments of the invention are implemented. 
         FIG. 2  shows a signaling diagram for illustrating an exemplary scenario of differentiated handling of data traffic according to an embodiment of the invention. 
         FIG. 3  shows a signaling diagram for illustrating a further exemplary scenario of differentiated handling of data traffic according to an embodiment of the invention. 
         FIG. 4  schematically illustrates a network device according to an embodiment of the invention. 
         FIG. 5  shows a flowchart for schematically illustrating a method according to an embodiment of the invention. 
     
    
    
     DETAILED DESCRIPTION OF EMBODIMENTS 
     In the following, the invention will be explained in more detail by referring to exemplary embodiments and to the accompanying drawings. The illustrated embodiments relate to concepts for differentiated handling of network traffic. As illustrated in  FIG. 1 , the concepts are applied in a mobile communication network according to the 3GPP TSs. However, it is to be understood that the illustrated concepts may be applied in other types of communication network as well, e.g. using fixed access technology such as DSL, fiber optical access, or coaxial cable access. 
       FIG. 1  schematically illustrates a communication network environment in which concepts according to embodiments of the invention the invention can be applied. 
     The communication network environment includes a UE  10 , which may also be referred to as a terminal, and a number of network components  22 ,  24 ,  26 ,  30 . Among these network components there is a Radio Access Network (RAN)  22 . The RAN  22  is based on a certain type or certain types of radio access technology, e.g. GSM (Global System for Mobile Communications), EDGE (Enhanced Data Rate for GSM Evolution), UMTS (Universal Mobile Telecommunications System), Wideband Code Division Multiple Access (WCDMA), or LTE (Long Term Evolution). Although the RAN  22  is illustrated as a single node, it is to be understood that the RAN  22  may actually be formed of a number of components, which are not further explained herein. The RAN  22  is coupled to a transport node  24 , which in turn is coupled to a gateway (GVV)  26 . Here, it is to be understood that alternatively more than one transport node  24  may be coupled between the RAN  22  and the gateway  26  or that the RAN  22  may be directly coupled to the gateway  26 . The gateway  26  may be a Gateway GPRS Support Node (GGSN) providing a connection of GPRS-based services to one or more external packet data networks. The gateway  26  may also be a Packet Data Network Gateway (PDN GW) according to the 3GPP TSs. 
     In addition, the mobile communication network includes a policy controller  30 , which is implemented as a Policy and Charging Rules Function (PCRF) according to the 3GPP TSs. The policy controller  30  may be implemented by dedicated hardware and/or comprise software functions executed by a processor. The gateway  26  and the policy controller  30  are typically regarded as components of a core network. The policy controller  30  communicates with the gateway  26  via a signaling path  6 , which may be implemented using the Gx interface according to the 3GPP TSs. The policy controller  30  may be further coupled to a subscriber database  32 , e.g., a Home Location Register (HLR) or a Home Subscriber server (HSS) according to the 3GPP TSs, and to a service policy database  34  via a signaling path  8 , e.g., implemented using a Sp interface according to the 3GPP TSs. The policy controller  30  may thus receive policy data relating to a specific user and/or relating to a specific service available in the mobile communication network, e.g. mobile TV. The policy controller  30  may further communicate with other network functions using a control signaling path  5 , which may be implemented using the Rx interface according to the 3GPP TSs. 
     Among other functions, the policy controller  30  may comprise a filter generator  35 . The filter generator  35  is adapted to specify packet filters to be used in the UE  10  and the gateway  26 , which may be accomplished on the basis of subscription data from the subscription database  32 , service policies from the service policy database  34 , and control data received via the signaling path  5 . The packet filters are an example of packet classification rules, which in the illustrated example are used to provide different QoS levels. 
     As further illustrated, data traffic between the network and the user equipment  10  is carried by a number of bearers  52 ,  54  established across a radio interface between the UE  10  and the RAN  22 . The data traffic typically pertains to one or more client/peer applications  12  running on the UE  10 , and may be related to certain network resources, e.g., internet services or content providers. The bearers  52 ,  54  are established between the user equipment  10  and the gateway  26 . The bearers  52 ,  54  carry data traffic in both the DL and the UL direction, i.e. may also be regarded as being formed of a DL bearer and a UL bearer. For supporting bidirectional communication on the bearers  52 ,  54 , the UE  10  is provided with a corresponding interface  15  which allows for receiving incoming data packets from the bearers  52 ,  54  and sending outgoing data packets on the bearers  52 ,  54 . Similarly, the gateway  26  is provided with a corresponding interface  25  which allows for receiving incoming data packets from the bearers  52 ,  54  and sending outgoing data packets on the bearers  52 ,  54 . The bearers  52 ,  54  may include a default bearer  52  generally established for offering packet-based services to the user equipment  10  and one or more dedicated bearer  54  which may have different QoS level, e.g. a higher or lower QoS level, than the default bearer. The default bearer  52  is typically established when the UE  10  attaches to the gateway  26  and receives its IP address and IP connectivity. The dedicated bearer  54  is typically established on demand, e.g. when data packets requiring a certain QoS level need to transmitted. 
     However, in some embodiments dedicated bearers may also established in advance, e.g., when the UE  10  attaches to the gateway  26 . Each bearer  52 ,  54  may be associated with a corresponding QoS profile. The QoS profile may be defined through parameters such as a QoS Class Identifier (QCI), an Allocation/Retention Priority (ARP), a Traffic Handling Priority (THP), a Maximum Bit Rate (MBR), an Aggregate Maximum Bit Rate (AMBR), and/or a Guaranteed Bit Rate (GBR). Accordingly, a certain QoS level may be provided for communicating data packets between the UE  10  and the gateway  26  by assigning the data packets to a corresponding one of the bearers  52 ,  54 . 
     In the UE  10 , the data packets are routed to a desired bearer  52 ,  54  using correspondingly configured packet classification rules in the form of UL packet filters  62 ,  64 . In the gateway  26 , the data packets are routed to the desired bearers  52 ,  54  using correspondingly configured packet classification rules in the form of DL packet filters  72 ,  74 . In accordance with the illustrated 3GPP scenario, a set of filters  62 ,  64 ,  72 ,  74  which operates to direct the data packets to a corresponding bearer may also be referred to as a Traffic Flow Template (TFT). Parameters of the QoS profile may be signaled from the policy controller  30  to the gateway  26  using the signaling path  6 . Similarly, the DL packet filters  72 ,  74  to be used in the gateway  26  may be signaled from the policy controller  30  to the gateway  26  via the signaling path  6 . As regards the UL packet filters  62 ,  64  used in the UE  10 , these may be signaled from the policy controller  30  via the gateway  26 . In some embodiments, at least some of the UL packet filters  62 ,  64  may be preconfigured in the UE  10  and/or some of the DL packet filters may be preconfigured in the gateway  26 . Also, in some embodiments the UL packet filters could be preconfigured in the gateway  26  and be signaled to the UE  10  when it attaches to the gateway  26  or when the corresponding bearer  52 ,  54  is established. In such embodiments using preconfigured packet filters in the UE  10  and/or in the gateway  26 , the policy controller  30  and/or the filter generator  35  of the policy controller  30  could be omitted. In some embodiments, the UL and/or DL packet filters could also be preconfigured in the policy controller  30  and be signaled to the gateway  26  and/or to the UE  10 , e.g., when the UE  10  attaches to the gateway  26  or when the corresponding bearer  52 ,  54  is established. 
     In the following, concepts according to embodiments of the invention will be explained, which allow for efficiently subjecting the data traffic related to one or more specific network resources to differentiated handling. In this respect, the term “network resource” is intended to cover various types of structures, content, or services which are accessible in the network. In some examples, the network resource may be a server on which the service or content is hosted, e.g., under a Uniform Resource Identifier (URI) or Uniform Resource Identifier. In some scenarios, the same server may host different network resources. In the example of  FIG. 1 , these concepts are applied with respect providing a certain QoS level, which is achieved by routing the data packets to the bearers  52 ,  54  using the packet filters  62 ,  64 ,  72 ,  74  in the UE  10  and in the gateway  26 . 
     The packet filters  62 ,  64 ,  72 ,  74  are generally configured to operate on the basis of network addresses, which are included in a respective protocol header of the data packets. The network addresses may in particular be IP addresses. For example, when using the Transport Control Protocol (TCP) or the User Datagram Protocol (UDP) for implementing transport of data via the data packets, the protocol header will include IP addresses defining a source network address and a destination network address of the data packet, which can be used separately or in combination as a basis for matching a filter pattern defined in the packet filter  62 ,  64 ,  72 ,  74 . Moreover, the above examples of a protocol header will also define a source port number and a destination port number, which can be used separately or in combination as a basis for matching a filter pattern defined in the packet filter  62 ,  64 ,  72 ,  74 . In some embodiments, the packet filters  62 ,  64 ,  72 ,  74  may operate on the basis of a pattern for matching an IP 5 tuple (source IP address, destination IP address, source port number, destination port number, protocol ID of the protocol above IP) of the data packets. Further, the packet filters may operate on a filter pattern in which an IP address is be combined with a prefix mask, and/or port numbers are be specified as port ranges. The filter pattern can also be extended by the Type of Service (TOS) (IPv4)/Traffic class (IPv6) and Mask. The filter pattern can also consist of the destination IP address, protocol ID of the protocol above IP, the Type of Service (TOS) (IP Version 4)/Traffic class (IP Version 6) and Mask and the IPSec Security Parameter Index (SPI). The filter pattern can also consist of the destination IP address, the Type of Service (TOS) (IPv4)/Traffic class (IPv6) and Mask and the Flow Label (IPv6). In some embodiments, a value left unspecified in the filter pattern packet filter  62 ,  64 ,  72 ,  74  may match any value of the corresponding information in the data packet, i.e., wildcards may be defined. 
     In order to reduce complexity of the packet filters  62 ,  64 ,  72 ,  74 , the concepts as explained in the following are based on an adaptation of lookup procedures for obtaining network addresses of the specific network resources for which differentiated handling is implemented. This adaptation is accomplished by processing one or more messages of the lookup procedure depending on a class of users to which a user of the network resource belongs. For example, a certain network resource may have a first class of users, such as premium subscribers, and a second class of users, such as normal subscribers. The user makes use of the UE  10  to send data traffic to the network resource and receive data traffic from the network resource. Various scenarios of differentiated handling may apply here: On a network resource level, the data traffic between the UE  10  and the network resource may be prioritized as compared to data traffic between the UE  10  and another network resource, i.e., it may be differentiated between different network resources. In addition, the data traffic between the UE  10  and the network resource may be prioritized as compared to data traffic of another user of the same network resource, i.e., it may be differentiated between different classes of users. 
     The processing of one or more messages of the lookup procedure may involve receiving a query for the network address of the network resource and responding to the query with the network address of the replacement network resource. Further, this processing may involve receiving a response to a query for the network address of the network resource and modifying the response by replacing the network address of the network resource with the network address of the replacement network resource. Further, this processing may also involve redirecting a query for the network address of the network resource. In the illustrated examples, the lookup procedures are based on the Domain Name System (DNS), and the adaptation is accomplished by processing one or more DNS messages, e.g., a DNS query or a response to a DNS query. In other examples, other lookup procedures could be used as well, e.g., a NetBIOS lookup procedure. 
     More specifically, the illustrated concepts apply to scenarios in which data traffic between the network resource and the user of the network resource is preceded by a lookup procedure for obtaining a network address of this network resource. The lookup procedure is adapted by processing of one or more messages of the lookup procedure in such a way that the lookup procedure returns a network address of a replacement network resource capable of replacing the network resource in communication of data packets. The returned network address depends on a class of users to which the user belongs. That is to say, if the user belongs to a first class of users, a first network address is returned, and if the user belongs to a second class of users, a second network address is returned. The first and second network addresses are different, e.g., may correspond to different IP addresses. In some embodiments, the first and second network addresses may also include first and second port numbers, respectively. In such cases, the difference between the first network address and the second network address could differ with respect to the first and second port numbers, but correspond to the same IP address. In this way, the available address space could be used in an efficient manner. 
     The class to which the user belongs may be determined on the basis of an identifier of the network resource in the message. In this case, the network resource could be identifiable by a first identifier for the first class of users and a second identifier for the second class of users. For example, if the network resource is an internet service such an identifier may be a Uniform Resource Identifier (URI) or Uniform Resource Locator (URL) under which the users log in. A certain URI or URL may be provided for log in of normal subscribers of the internet service, and another URI or URL may be provided for log in of premium subscribers of the internet service. For example, a content provider may set up one domain identified by a first URI, e.g., “cp.com”, for normal subscribers, and a further domain identified by a second URI, e.g., “supreme.cp.com” for premium subscribers, and could provide the same content via the first URI and the second URI. That is to say, both the first URI and the second URI would point to the same network resource. 
     The class to which the user belongs may also be obtained on the basis of a user identifier in the message, e.g., a user name of the user. In this case, the class of users to which the user belongs could be obtained from a database relating user names to classes of users. 
     The replacement network resource may be configured with the capability to replace the network resource by operating as a proxy node with respect to the network resource. The replacement network resource may also cache content provided by the network resource. In some embodiments, the replacement network resource may be a cache server or a tunnel edge server for delivering the content of the network resource. 
     The communication of data packets may then be established with respect to the replacement network resource, and differentiated handling of the data packets may be accomplished on the basis of the network address of the replacement network resource. Accordingly, the differentiated handling of the data packets can be facilitated by suitably selecting the network address of the replacement network resource. For this purpose, the replacement network resource may be located in the same local network as communication device, e.g., the UE  10 , to which the communication is established. A network operator of the local network may therefore suitably assign the network address to the replacement network resource. For example, the network address may be selected from a private network address range, e.g., as defined in RFC 1918, RFC 4193, or RFC 5735. However, the network address could also be selected from a specific range of public network addresses, e.g., allocated to the network operator. 
     For example, the network address of the replacement network resource may be selected from a network address range corresponding to a subnet. For differentiating between different classes of users as described herein, the first network address corresponding to the first class of users may be selected from a first network address range corresponding to a subnet, and the second network address corresponding to the second class of users may be selected form a second network address range corresponding to another subnet. In this case, the packet classification rules operating on the basis of the first and second network addresses may be provided with a simple structure. For example, the filter pattern as used by one or more of the packet filters  62 ,  64 ,  72 ,  74  may define the network address to be matched by using a wildcard, thereby achieving that every network address within the respective subnet will match the filter pattern. As can be seen, it is therefore possible to efficiently define a packet classification rule to provide the same handling for all network addresses from this subnet. This could be used to provide a specific handling for a number of specific network resources by assigning the replacement network resources for these network resources network addresses from the same subnet. According to a further example, also differentiation between the data traffic of different network resources can be implemented by selecting the network addresses of the corresponding replacement network resources each from a different network range corresponding to a subnet. In this case, the subnet corresponding to the first class of users and the subnet corresponding to the second class of users may be located in the same higher-level subnet. This higher-level subnet may correspond to the network resource and be used for differentiation with respect to other network resources. 
     In order to implement the above concepts, the communication system of  FIG. 1  further includes a lookup adaptation device (LAD)  100 . Typically, the lookup adaptation device  100  will receive lookup messages pertaining to the data traffic related to the specific network resource. In some embodiments, the lookup adaptation device  100  may be arranged in such a way that lookup messages pertaining to the data traffic of the UE  10  are routed through the lookup adaptation device  100 . For example, this could be accomplished by arranging the lookup adaptation device  100  in a data path between the gateway  26  and a local DNS server (not illustrated in  FIG. 1 ). In some embodiments the lookup adaptation device  100  may be part of the gateway  26 . In some embodiments, the lookup adaptation device  100  could also be part of the local DNS server. According to still further embodiments, the lookup adaptation device could also be arranged in a data path between the local DNS server and an external DNS server. Further, in some embodiments the lookup adaptation device  100  may also be part of an external DNS server. The lookup adaptation device  100  may be implemented within other network devices, e.g., the gateway  26  or the local DNS server, or as a standalone network device. The functionalities of the lookup adaptation device  100  may be implemented by software by having a processor (not illustrated in  FIG. 1 ) of the lookup adaptation device  100  execute suitably configured program code and use suitably configured lookup adaptation data. As an alternative, the lookup adaptation device  100  may at least in part be implemented by dedicated hardware. 
     In some embodiments, the network address of the replacement network resource may be selected in such a way that it matches a preconfigured packet filter operating on the basis of this network address. In this way, no individual procedures for generating and/or signaling the packet filters are necessary. For example, in the mobile communication network environment of  FIG. 1 , the packet filters  62 ,  64  could be preconfigured in the UE  10 , and/or the packet filters  72 ,  74  could be preconfigured in the gateway  26 . Also, the packet filters  62 ,  64  could be preconfigured in the gateway  26  and then signaled to the UE  10 . Further, the packet filters  62 ,  64 ,  72 ,  74  could be preconfigured in the policy controller  30  and then be signaled to the gateway  26  and/or to the UE  10 . The preconfiguration could be obtained, e.g., by providing the packet filters together with an operating software of the gateway  26 , policy controller  30 , or UE  10 , or by using maintenance procedures. In some embodiments such preconfigured packet filters may be updated in response to inspecting the data packets, thereby allowing for a refined differentiation, e.g., between different classes of data traffic related to the same network resource and user class. For example, it would be possible that video streaming to a premium subscriber of a content provider is treated with a different priority than file downloads the premium subscriber performs from this content provider. 
     In some embodiments, a packet filter operating on the basis of the network address of the replacement network resource may also be dynamically generated in response to selecting the network address of the replacement network resource, or an existing packet classification rule may be modified in response to selecting the network address of the replacement network resource. In the example of  FIG. 1 , the lookup adaptation device  100  may use a signaling path  9  to the policy controller  30  to initiate generation of new packet filters to be used by the UE  10  and/or by the gateway  26  or to initiate modification of the existing packet filters  62 ,  64 ,  72 ,  74 , which in each case may be accomplished by the filter generator  35  of the policy controller  30 . 
     As further illustrated, the communication system of  FIG. 1  also includes a packet inspector  40 . In some embodiments, the packet inspector  40  is used to further differentiate between traffic classes within data traffic related to the same network resource and user class, e.g., different applications of the same internet service or different types of content from the same content provider. 
     The packet inspector  40  is operable to determine a traffic class of data packets in the UL or DL traffic. For this purpose, the packet inspector  40  may analyze data packets of the UL or DL traffic, e.g., with respect to information going beyond the protocol header of the data packets. For example, the packet inspector  40  could analyze the data packets with respect to Hostnames, Uniform Resource Identifiers URIs, URLs, or network addresses included in a payload section of the data packets. For example, such information may be found in HTTP requests, e.g., in a request header of a HTTP request. Information obtained by the packet inspector  40  can then be used to update the packet classification rules, e.g., one or more of the packet filters  62 ,  64 ,  72 ,  74 . In the example of  FIG. 1 , the update may be initiated by the packet inspector  40  using the signaling path  5  to the policy controller  30 . The filter generator  35  of the policy controller  30  may then generate updated filters to be used in the gateway  26  and/or in the UE  10 . 
       FIG. 2  shows a signaling diagram for illustrating an exemplary scenario in which differentiated handling of data traffic is provided by adapting a lookup procedure in accordance with the above concepts. The signaling diagram of  FIG. 2  shows the UE  10 , a local DNS server  50 , a replacement server  60 , and a server  80 . The above-described functionality of the lookup adaptation device is implemented within the local DNS server  50 . That is to say, the lookup adaptation device  100  of  FIG. 1  may be part of the local DNS server  50 . 
     In the scenario of  FIG. 2 , the server  80  represents an example of a specific network resource for which the related data traffic is to be subjected to differentiated handling in communication with respect to the UE  10 . For example, the server  80  may provide one or more specific internet services or may be part of a content delivery system used for efficient delivery of content. In addition, it is assumed that there are different classes of users of the server  80 , e.g., premium subscribers of an internet service hosted on the server  80  and normal users of this internet service. As explained in connection with  FIG. 1 , this differentiated handling may have the purpose of providing a certain QoS level for the data traffic, which can be obtained by routing data packets of this data traffic to a corresponding bearer, e.g., one of the bearers  52 ,  54 , in particular the dedicated bearer  54 . For example, data traffic of a user belonging to a first class of users, e.g., premium subscribers, could be routed to the dedicated bearer  54  so as to be prioritized whereas data traffic of a user belonging to a second class of users, e.g., normal subscribers, could be routed to the default bearer  52 . In the scenario of  FIG. 2 , it is assumed that the user at the UE  10  belongs to the first class of users, for which data traffic is to be prioritized. 
     The replacement server  60  functions as a replacement network resource for the server  80 . The replacement server  60  is capable of replacing the server  80  in communication with the UE  10 . In particular, the replacement server  60  is capable of responding to requests from the UE  10  in the same way as the server  80 . For this purpose, the replacement server  60  may operate a proxy node with respect to the server  80 , e.g., by relaying the requests to the server  80  and forwarding responses from the server  80  to the UE  10 , and/or may cache content provided by the server  80 . In some cases, an acceleration tunnel may be provided for communication between the replacement server  60  and the server  80 . In such cases, the replacement server may function as tunnel edge server and accomplish, e.g., encapsulation of data packets to be transmitted via the acceleration tunnel to the server  80  and decapsulation of data packets received via the acceleration tunnel from the server  80 . In some embodiments, proxy node operation, cache server operation, and tunnel edge server operation of the replacement server  60  may be combined. 
     Moreover, it is assumed that the UE  10  is attached to a mobile communication network using radio access technology, e.g., as illustrated in  FIG. 1 , and that the local DNS server  50  and the replacement server  60  are part of this mobile communication network, i.e., controlled by the same network operator. The network operator may have allocated a certain range of network addresses to be used by replacement network resources, e.g., a range of private network addresses. The replacement server  60  is assumed to have two different network address selected from this range: a first network address and a second network address. In alternative implementations, the replacement server  60  could be duplicated, e.g., by using a mirror server, and the first network address could correspond to the replacement server  60  and the second network address could correspond to the duplicate or “mirror” of the replacement server  60 . 
     At step  201 , bearers to be used for the data traffic between the UE  10  and the server  80  are established. For the following explanations, these bearers are assumed to be a default bearer  52  and a dedicated bearer  54  as illustrated in  FIG. 1 . The dedicated bearer  54  may already be established when the UE  10  attaches to the mobile communication network. Alternatively, the dedicated bearer  54  could also be established in response to first detecting the data traffic related to the server  80 , e.g., using the packet inspector  40 . 
     One or more packet filters are configured to direct data packets carrying the first network address to the dedicated bearer  54  and to direct data packets carrying the second network address to the default bearer. More specifically, a first UL packet filter in the UE  10 , e.g., the UL packet filter  64 , may be configured to direct UL data packets carrying the first network address as destination address to the dedicated bearer  54 , but block UL data packets carrying the second network address as destination address from being transmitted to the dedicated bearer  54 . Similarly, a first DL packet filter in the gateway to which the UE  10  is attached, e.g., the DL packet filter  74 , may be configured to direct DL data packets carrying the first network address as source address to the dedicated bearer  54 , but block DL data packets carrying the second network address as source address from being transmitted to the dedicated bearer  54 . A second UL packet filter in the UE  10 , e.g., the UL packet filter  62 , may be configured to direct UL data packets carrying the second network address as destination address to the default bearer  54 , and a second DL packet filter in the gateway to which the UE  10  is attached, e.g., the DL packet filter  72 , may be configured to direct DL data packets carrying the second network address as source address to the default bearer  52 . The second UL and DL filters  62 ,  72  may be configured as “match all” packet filters, i.e., direct all data packets to the default bearer  52  which are blocked by other packet filters. In some scenarios, the second UL and DL filters associated with the default bearer  52  may also be omitted. 
     The packet filters may be preconfigured in the UE  10  or in the gateway and the network address of the replacement server  60  may be selected to match these preconfigured packet filters. Alternatively, the packet filters could be generated in response to selecting the network address of the replacement server. In each case, the signaling needed to establish the bearer is limited. Moreover, network addresses of other replacement servers corresponding to other servers could be assigned in such a way that a simple filter structure is obtained. 
     As illustrated at  202 , the server  80  transmits data to the replacement server  60 . Depending on the operation of the replacement server  60 , this may be accomplished at any suitable time. For example, the transmission could be triggered by new data becoming available at the server  80  or by a request for the data by another client. Such a request could be first received by the replacement server  60  which, if the data is not locally available, then forwards the request to the server  80 . The replacement server  60  may then store the received data so as to be used for responding to subsequent requests. In proxy node operation, e.g., as a tunnel edge server, the transmission of the data from the server  80  to the replacement server  60  is triggered by the requests of the UE  10  which are relayed by the replacement server  60  to the server  80 . 
     When the UE  10  now needs to access the server  80 , the UE  10  first issues a DNS query  203  to the local DNS server  50 . The DNS query  203  specifies a hostname or URI associated with the server  80  to request the network address of the server  80 . For differentiating between different user classes as described herein, it is assumed that this hostname or URI is dedicated to a certain user class, e.g., corresponds to a web page for log in of premium subscribers or the like. The local DNS server  50 , which includes the lookup adaptation functionality, then performs an adaptation step  204  before responding to the DNS query with a message  205 . The adaptation step  204  causes the DNS query  203  to be processed in such a way that the message  205  indicates the network address of the replacement server  60 . The adaptation step  204  therefore causes the lookup procedure to return the network address of the replacement server  60 . The adaptation step  204  may be implemented by corresponding configuration of resource records as stored by the local DNS server  50  for the hostname or URI associated with the server  80 . The configuration of the resource records may be based on suitably configured lookup adaptation data relating the hostname and/or URI associated with the server  80  to the network address of the replacement server  60 . Since the hostname or URI in the message  203  is dedicated to a class of users, the network address returned by the lookup procedure will depend on the class of users as well. In the illustrated scenario, since the user at the UE  10  belongs to the first class of users, the network address returned by the lookup procedure would be the first network address corresponding to the first class of users. In an alternative scenario, in which the user at the UE  10  belongs to the second class of users, a different URI dedicated to the second class of users would be specified in the DNS query, and the network address returned by the lookup procedure would be the second network address corresponding to the second class of users. 
     The UE  10  then sends a request  206  to the replacement server  60  to request the data, and the replacement server  60  sends a response  207  with the requested data to the UE  10 . The data packets of the request  206  will indicate the first network address as their destination address. Because the first network address matches the first UL filter, the data packets of the request  206  are directed to the dedicated bearer  54  by the first UL packet filter. The data packets of the response  207  will indicate the first network address as their source address. Because the first network address matches the first DL packet filter, the data packets of the response  207  are directed to the dedicated bearer  54  by the first DL packet filter. In the alternative scenario of the user at the UE  10  belonging to the second class of users, the data packets of the request  206  and of the response  207  would indicate the second network address as their destination address and therefore not match the first UL packet filter. Similarly, the data packets of the response  207  would indicate the second network address as their source address and therefore not match the first DL packet filter. However, since the second network address matches the second UL packet filter and the second DL packet filter, the data packets would be directed to the default bearer  52 . 
     For subsequent data traffic related to the server  80 , no new DNS query by the UE  10  is needed as long as the network address of the replacement server  60  is cached by the UE  10 . Such traffic would directly be routed to the replacement server  60 . 
     It is to be understood that the lookup procedure of  FIG. 2  could be modified in various manners. For example, the DNS query  203  could be redirected by the local DNS server  50  to an external DNS server, e.g., to a DNS server which is authoritative for the domain of the server  80 . This redirection could be in one ore more steps. The adaptation of step  204  could then also be accomplished by the external DNS server. This external DNS server may however be hosted by the network operator of the mobile communication network. In such cases, the lookup procedure could also include further steps to optimize the delivery of content, e.g., steps for selecting cache clusters or cache servers. 
     In some scenarios, the lookup procedure of  FIG. 2  may also be iterative. In such scenarios, the local DNS server  50  may respond to the UE  10  with a message indicating a further DNS server to which the DNS query should be sent in the next step. The UE  10  then sends the DNS query to the further DNS server to obtain the requested network address, or information on a still further DNS server to which the DNS query is to be sent in the next step. This may be iterated until the DNS query arrives at a DNS server which responds to the DNS query with the network address of the replacement server  60 . This DNS server, which sends the final response to the query, may be an external DNS server, e.g., a DNS server which is authoritative for the domain of the server  80 . However, this external DNS server may be hosted by the network operator of the mobile communication network. 
     Also, the DNS query  203  and the message  205  returned to the UE in response to the DNS query  203  could be routed to the dedicated bearer  54  by generating the first UL and DL packet filters to be matched by all data packets indicating port number  53  as source or destination port. 
       FIG. 3  shows a signaling diagram for illustrating a further exemplary scenario in which differentiated handling of data traffic is provided by adapting a lookup procedure in accordance with the above concepts. In this scenario, the adaptation is based on an interception of a message transmitted in response to a DNS query. The signaling diagram of  FIG. 3  shows the UE  10 , the lookup adaptation device  100 , a local DNS server  50 , a replacement server  60 , an external DNS server, and a server  80 . The lookup adaptation device  100  is illustrated to be arranged between the UE  10  and the local DNS server  50 . For example, the lookup adaptation device  100  could be implemented within or collocated with the gateway to which the UE  10  is attached, e.g., the gateway  26  of  FIG. 1 . 
     In the scenario of  FIG. 3 , the server  80  represents an example of a specific network resource for which the related data traffic is to be subjected to differentiated handling in communication with respect to the UE  10 . For example, the server  80  may provide one or more specific internet services or may be part of a content delivery system used for efficient delivery of content. In addition, it is assumed that there are different classes of users of the server  80 , e.g., premium subscribers of an internet service hosted on the server  80  and normal users of this internet service. As explained in connection with  FIG. 1 , this differentiated handling may have the purpose of providing a certain QoS level for the data traffic, which can be obtained by routing data packets of this data traffic to a corresponding bearer, e.g., one of the bearers  52 ,  54 , in particular the dedicated bearer  54 . For example, data traffic of a user belonging to a first class of users, e.g., premium subscribers of an internet service, could be routed to the dedicated bearer  54  so as to be prioritized whereas data traffic of a user belonging to a second class of users, e.g., normal subscribers of the internet service, could be routed to the default bearer  52 . In the scenario of  FIG. 3 , it is assumed that the user at the UE  10  belongs to the first class of users, for which data traffic is to be prioritized. 
     The replacement server  60  functions as a replacement network resource for the server  80 . The replacement server  60  is capable of replacing the server  80  in communication with the UE  10 . In particular, the replacement server  60  is capable of responding to requests from the UE  10  in the same way as the server  80 . For this purpose, the replacement server  60  may operate as a proxy node with respect to the server  80 , e.g., by relaying the requests to the server  80  and forwarding responses from the server  80  to the UE  10 , and/or may cache content provided by the server  80 . In some cases, an acceleration tunnel may be provided for communication between the replacement server  60  and the server  80 . In such cases, the replacement server may function as tunnel edge server and accomplish, e.g., encapsulation of data packets to be transmitted via the acceleration tunnel to the server  80  and decapsulation of data packets received via the acceleration tunnel from the server  80 . In some embodiments, proxy node operation, cache server operation, and tunnel edge server operation of the replacement server  60  may be combined. 
     Moreover, it is assumed that the UE  10  is attached to a mobile communication network using radio access technology, e.g., as illustrated in  FIG. 1 , and that the local DNS server  50  and the replacement server  60  are part of this mobile communication network, i.e., controlled by the same network operator. The network operator may have allocated a certain range of network addresses to be used by replacement network resources, e.g., a range of private network addresses. The replacement server  60  is assumed to have two different network address selected from this range: a first network address and a second network address. In alternative implementations, the replacement server  60  could be duplicated, e.g., by using a mirror server, and the first network address could correspond to the replacement server  60  and the second network address could correspond to the duplicate or “mirror” of the replacement server  60 . The external DNS server  70  may be, e.g., a DNS server which is authoritative for the domain of the sever  80 . 
     At step  301 , bearers to be used for the data traffic between the UE  10  and the server  80  are established. For the following explanations, these bearers are assumed to be a default bearer  52  and a dedicated bearer  54  as illustrated in  FIG. 1 . The dedicated bearer  54  may already be established when the UE  10  attaches to the mobile communication network. Alternatively, the dedicated bearer  54  could also be established in response to first detecting the data traffic related to the server  80 , e.g., using the packet inspector  40 . 
     One or more packet filters are configured to direct data packets carrying the first network address to the dedicated bearer  54  and to direct data packets carrying the second network address to the default bearer. More specifically, a first UL packet filter in the UE  10 , e.g., the UL packet filter  64 , may be configured to direct UL data packets carrying the first network address as destination address to the dedicated bearer  54 , but block UL data packets carrying the second network address as destination address from being transmitted to the dedicated bearer  54 . Similarly, a first DL packet filter in the gateway to which the UE  10  is attached, e.g., the DL packet filter  74 , may be configured to direct DL data packets carrying the first network address as source address to the dedicated bearer  54 , but block DL data packets carrying the second network address as source address from being transmitted to the dedicated bearer  54 . A second UL packet filter in the UE  10 , e.g., the UL packet filter  62 , may be configured to direct UL data packets carrying the second network address as destination address to the default bearer  54 , and a second DL packet filter in the gateway to which the UE  10  is attached, e.g., the DL packet filter  72 , may be configured to direct DL data packets carrying the second network address as source address to the default bearer  52 . The second UL and DL filters  62 ,  72  may be configured as “match all” packet filters, i.e., direct all data packets to the default bearer  52  which are blocked by other packet filters. In some scenarios, the second UL and DL filters associated with the default bearer  52  may also be omitted. 
     The packet filters may be preconfigured in the UE  10  or in the gateway and the network address of the replacement server  60  may be selected to match these preconfigured packet filters. Alternatively, the packet filters could be generated in response to selecting the network address of the replacement server. In each case, the signaling needed to establish the bearer is limited. Moreover, network addresses of other replacement servers corresponding to other servers could be assigned in such a way that a simple filter structure is obtained. 
     As illustrated at  302 , the server  80  transmits data to the replacement server  60 . Depending on the operation of the replacement server  60 , this may be accomplished at any suitable time. For example, the transmission could be triggered by new data becoming available at the server  80  or by a request for the data by another client. Such a request could be first received by the replacement server  60  which, if the data is not locally available, then forwards the request to the server  80 . The replacement server  60  may then store the received data so as to be used for responding to subsequent requests. In proxy node operation, e.g., as a tunnel edge server, the transmission of the data from the server  80  to the replacement server  60  is triggered by the requests of the UE  10  which are relayed by the replacement server  60  to the server  80 . 
     When the UE  10  now needs to access the server  80 , it first issues a DNS query  303  to the local DNS server  50 . The DNS query  303  specifies a hostname or URI associated with the server  80  to request the network address of the server  80 . It is now assumed that the local DNS server  50  is not capable of responding to the DNS query  303  and therefore issues a further DNS query  304  to the external DNS server  70 . The external DNS server  70  responds to the local DNS server  50  with a message  305  indicating the network address of the server  80 . The local DNS server  50  then issues a message  306  indicating the network address of the server  80  toward the UE  10 . The message  306  is intercepted by the lookup adaptation device  100  and modified at adaptation step  307  by replacing the network address of the server  80  with the network address of the replacement server  60 . The lookup adaptation device  100  then forwards the modified message  308  to the UE  10 . The adaptation step  307  causes the lookup procedure to return the network address of the replacement server  60 . The adaptation step  307  may be implemented by providing the lookup adaptation device  100  with suitably configured lookup adaptation data relating the network address, hostname, and/or URI associated with the server  80  to the network address of the replacement server  60 . Since the hostname or URI is dedicated to a class of users, the network address returned by the lookup procedure is returned depending on the class of users. In the illustrated scenario, since the user at the UE  10  belongs to the first class of users, the network address returned by the lookup procedure would be the first network address corresponding to the first class of users. In an alternative scenario, in which the user at the UE  10  belongs to the second class of users, the network address returned by the lookup procedure would be the second network address corresponding to the second class of users, because a different URI dedicated to the second class of users would be specified in the DNS query  303 . 
     The UE  10  then sends a request  309  to the replacement server  60  to request the data, and the replacement server  60  sends a response  310  with the requested data to the UE  10 . The data packets of the request  309  will indicate the first network address as their destination address. Because the first network address matches the first UL filter, the data packets of the request  309  are directed to the dedicated bearer  54  by the first UL packet filter. The data packets of the response  310  will indicate the first network address as their source address. Because the first network address matches the first DL packet filter, the data packets of the response  310  are directed to the dedicated bearer  54  by the first DL packet filter. In the alternative scenario of the user at the UE  10  belonging to the second class of users, the data packets of the request  309  would indicate the second network address as their destination address and therefore not match the first UL packet filter. Similarly, the data packets of the response  310  would indicate the second network address as their source address and therefore not match the first DL packet filter. However, since the second network address matches the second UL packet filter and the second DL packet filter, the data packets would be directed to the default bearer  52 . 
     For subsequent data traffic between the user at the UE  10  and the server  80 , no new DNS query by the UE  10  is needed as long as the network address of the replacement server  60  is cached by the UE  10 . Such traffic would directly be routed to the replacement server  60 . 
     It is to be understood that the lookup procedure of  FIG. 3  could be modified in various manners. For example, the redirection of the DNS query to the external DNS server could include one or more further redirection processes. Further, the lookup procedure could also include further steps to optimize the delivery of content, e.g., steps for selecting cache clusters or cache servers. Also, the lookup adaptation device  100  could intercept a response to a DNS query at a different position. For example, the lookup adaptation device  100  could be arranged between the local DNS server  50  and the external DNS server  70  and intercept the message  305 . 
     In some scenarios, the lookup procedure of  FIG. 3  may also be iterative. In such scenarios, the local DNS server  50  may respond to the UE  10  with a message indicating a further DNS server to which the DNS query should be sent in the next step. The UE  10  then sends the DNS query to the further DNS server to obtain the requested network address, or information on a still further DNS server to which the DNS query is to be sent in the next step. This may be iterated until the DNS query arrives at a DNS server which responds to the DNS query with the network address of server  80 . This final response would then be intercepted by the lookup adaptation device  100  and modified as explained for adaptation step  307 . 
     Also, the DNS query  303  and the message  308  returned to the UE in response to the DNS query  303  could be routed to the dedicated bearer  54  by generating the first UL and DL packet filters to be matched by all data packets indicating port number  53  as source or destination port. 
     In the scenarios of  FIGS. 2 and 3 , data traffic corresponding to a first class of users is directed to the dedicated bearer  54  whereas data traffic of a second class of users is directed to the default bearer  52 . However, it is to be understood that also another dedicated bearer, e.g., with different QoS level, could be used in place of the default bearer, e.g., in order to prioritize the data traffic of both classes of users of the server  80  against other data traffic, e.g., related to other servers, and to provide even higher prioritization for one class of users. 
     In the scenarios of  FIGS. 2 and 3 , the step of establishing the dedicated bearer  54  can depend on further conditions. For example, the bearer could be established only for certain types of UE, e.g., on the basis of an International Mobile Eqipment Identity (IMEI) of the UE  10 . Further, the dedicated bearer could be established only for certain subscribers of the mobile communication network, e.g., based on information in the subscriber database  32  of  FIG. 1 . Further, the bearer could be established only in certain parts of the network, e.g., based on the location of the UE  10 . Further, the bearer could be established only for certain radio access technologies the UE  10  uses for attaching to the mobile communication network, e.g., on the basis of the type of the RAN  22  in  FIG. 1 . If the dedicated bearer  54  is not established, the data traffic may be handled in the usual manner, e.g., be routed to the default bearer  52 . 
     In the above described concepts, various types of differentiated handling can be implemented in addition to the differentiation between classes of users. For example, data traffic related to a plurality of different network resource could be handled in the same way by providing a corresponding replacement network resource for each of the network resources and by selecting the network addresses of the replacement network resources in such a way that the packet classification rule(s) operating thereon can be provided with a simple structure, e.g., by selecting the network addresses from the same subnet or from a contiguous range of network addresses. 
     Also, the data traffic related to a first set of network resources could be handled differently from that related to a second set of network resources by providing a corresponding replacement network resources for each of the network resources and by selecting the network addresses of the replacement network resources in such a way that the packet classification rules operating thereon can be provided with a simple structure, e.g., by selecting the network addresses of the replacement network resources corresponding to the first set from different subnets or from different contiguous ranges of network addresses than the network addresses of the replacement network resources corresponding to the second set. Typically different packet classification rules may then be defined for the first and second set. For example, different sets of packet filters could be defined in order to route the data traffic related to the first set to another bearer, e.g., to another dedicated bearer, than the data traffic related to the second set. For example these two bearers could be dedicated bearers having different QoS levels. However, this also includes the possibility of providing no explicit packet classification rule for one set of network resources and corresponding replacement network resources. In the example of  FIG. 1 , this would cause the data traffic related to this set to be routed to the default bearer. 
     In some embodiments, the same replacement network resource may be used to provide two or more different ways of handling the data traffic. For example, this can be achieved by assigning two or more network addresses to the same replacement network resource, each of the network addresses being selected from a range associated with a different way of handling the data traffic, e.g., from different subnets. Examples in which two network addresses assigned to the same replacement network resource are used to differentiate between different classes of users are described in connection with  FIGS. 2 and 3 . 
     Further, it is to be understood that the above concepts may also be applied to differentiated handling with respect to other features than QoS. In some embodiments, the packet classification rules or packet filters could be used to differentiate between different ways of charging, e.g., one rate of charging for the first class of users and another rate of charging for the second class of users. 
       FIG. 4  further schematically illustrates an exemplary structure of a network device for implementing the lookup adaptation device  100 . 
     In the illustrated implementation, the lookup adaptation device  100  includes a first interface  130  configured to receive messages of a lookup procedure, e.g., DNS queries or responses to DNS queries. Further, the lookup adaptation device  100  also includes an second interface  135  configured to transmit messages of a lookup procedure, e.g., to send or forward DNS queries or to send responses to DNS queries. In some embodiments, the first and second interfaces  130 ,  135  could also be implemented in a single bidirectional interface. 
     Moreover, the lookup adaptation device  100  may also be provided with a control interface  140 , which can be used to provide indications to other entities, e.g., to initiate generation or updating of packet filters by signaling to the policy controller  30  and/or to the gateway  26 , and/or to initiate control processes with respect to forwarding procedures of data packets, e.g., modification and/or establishment of the bearers  52 ,  54 . In the illustrated 3GPP scenario, the control interface  140  may be implemented as the Rx interface according to the 3GPP TSs. Further, the interface  140  may also be used to obtain lookup adaptation data and/or or other data from which the lookup adaptation data may be derived. In some embodiments, the control interface  140  may be implemented in a single interface with the first and second interfaces  130 ,  135 . 
     Further, the lookup adaptation device  100  includes a processor  150  coupled to the interfaces  130 ,  135 ,  140  and a memory  160  coupled to the processor  150 . The memory  160  may include a read-only memory (ROM), e.g. a flash ROM, a random-access memory (RAM), e.g. a Dynamic RAM (DRAM) or static RAM (SRAM), a mass storage, e.g. a hard disk or solid state disk, or the like. The memory  160  includes suitably configured program code to be executed by the processor  150  so as to implement the above-described functionalities of the lookup adaptation device  100 . More specifically, the memory  160  may include a lookup adaptation module  170  so as to implement the above-described mechanisms of adapting lookup procedures depending on a class of users and lookup adaptation data  180  to be used in the process of adapting the lookup procedure, e.g., lookup adaptation data relating classes of users of a network resource to corresponding network addresses or network address ranges. 
     It is to be understood that the structure as illustrated in  FIG. 4  is merely schematic and that the lookup adaptation device  100  may actually include further components which, for the sake of clarity, have not been illustrated, e.g. further interfaces. Also, it is to be understood that the memory  150  may include further types of program code modules, which have not been illustrated. According to some embodiments, also a computer program product may be provided for implementing concepts according to embodiments of the invention, e.g., a computer-readable medium storing the program code and/or the lookup adaptation data to be stored in the memory  160 . 
       FIG. 5  shows a flowchart for schematically illustrating a method  500  for differentiated handling of data traffic according to an embodiment of the invention. The method may be used to implement the above described concepts, e.g., in the mobile communication network of  FIG. 1  by using the lookup adaptation device  100 . In some embodiments, the method  500  may also be used to implement the above concepts by using a network system including the lookup adaptation device and at least one communication device, e.g., the UE  10  and/or the gateway  26 . In some embodiments, the network system may include further components, e.g., a replacement network resource, such as the replacement server  60 , or the packet inspector  40 . As explained above, the method  500  is based on the assumption that the data traffic is between a network resource, e.g., an internet service or a content provider, and a user of the network resource. Further, it is assumed that the user of the network resource belongs either to a first class of users, e.g., premium subscribers of an internet service, or a second class of users, e.g., normal subscribers of the internet service. In addition, it is assumed that the data traffic is preceded by a lookup procedure for obtaining a network address of the network resource. 
     At step  510 , a message of the lookup procedure is received, e.g., using the interface  130  of the lookup adaptation device  100  as illustrated in  FIG. 4 . The message may be a DNS message, e.g., a DNS query or a response to a DNS query. 
     At step  520 , it is determined whether the user belongs to the first class of users. If this is the case, as indicated by branch “Y”, the method continues with step  530 . If this is not the case, as indicated by branch “N”, the method continues with step  540 . The determination of step  520  may depend on an identifier of the network resource, e.g., an URI or URL used to access the network resource. In particular, the network resource may be identifiable by a first identifier for the first class of users and by a second identifier for the second class of users. If the message includes the first identifier, the user is determined to belong to the first class of users. The determination of step  520  may also depend on an user identifier in the message, e.g., a user name or the like. In particular, the user may be determined to belong to the first class of users if the message includes a first user identifier indicating that the user belongs to the first class of users. 
     At step  530 , the message is processed so as to adapt the lookup procedure. Due to the adaptation, the lookup procedure returns a first network address of a replacement network resource, e.g., the replacement server  60  which may be a cache server or tunnel edge server. The replacement network resource is capable of replacing the network resource in communication of data packets of the data traffic. For this purpose, the replacement network resource may cache content provided by the network resource and/or operate as a proxy node with respect to the network resource. 
     At step  540 , it is determined whether the user belongs to the second class of users. If this is the case, as indicated by branch “Y”, the method continues with step  550 . The determination of step  540  may depend on an identifier of the network resource, e.g., an URI or URL used to access the network resource. In particular, the network resource may be identifiable by a first identifier for the first class of users and by a second identifier for the second class of users. If the message includes the second identifier, the user is determined to belong to the first class of users. The determination of step  540  may also depend on an user identifier in the message, e.g., a user name or the like. In particular, the user may be determined to belong to the first class of users if the message includes a second user identifier indicating that the user belongs to the second class of users. 
     It is to be understood that in some scenarios the determination of step  540  may be implicitly included in the determination of step  520 . For example, if there are only two classes of users, the a determination of the user not belonging to the first class of users at step  520  would at the same time mean that the user belongs to the second class of users. Accordingly, in some embodiments the determination of step  540  does not need to be provided as a separate step. 
     At step  550 , the message is processed so as to adapt the lookup procedure. Due to the adaptation, the lookup procedure returns a second network address of a replacement network resource. The second network address returned at step  550  is different from the first network address returned at step  530 . For example, the first and second network addresses may include different port numbers and/or different IP addresses. In some embodiments, the second network address may be selected from a different subnet than the first network address. The replacement network resource may be the same as in step  530  or may be a duplicate thereof. Accordingly, also the replacement network resource of step  550  may be, e.g., the replacement server  60  or a duplicate thereof. 
     Following the adaptations of steps  530  or  550 , differentiated handling of the data traffic may be performed on the basis of the network address of the replacement network resource, i.e., on the basis of the first network address and the second network address. For this purpose the first network address matches a packet filter for directing the data traffic to a certain bearer, e.g., the dedicated bearer, and the second network address does not match this packet filter. In some embodiments, the second network address may match a further packet filter for directing the data traffic to a further bearer, e.g., to the default bearer  52  or to another dedicated bearer. 
     The processing of the message in steps  530  and  550  may involve receiving a query for a network address of the network resource, such as DNS query  203  of  FIG. 2 , and responding to the query with the first network address if the user belongs to the first class of users and responding to the query with the second network address if the user belongs to the second class of users. 
     The processing of the message in steps  530  and  550  may also involve receiving a response, to a query for a network address of the network resource, e.g., DNS response  305  of  FIG. 3 , and modifying the response by replacing the network address of the network resource with the first network address if the user belongs to the first class of users and modifying the response by replacing the network address of the network resource with the second network address if the user belongs to the second class of users. 
     The processing of the message may also involve redirecting a query for a network address of the network resource, e.g., DNS query  203  of  FIG. 2  or DNS query  304  of  FIG. 3 . 
     By appropriate selection of the first and second network addresses, e.g., from a range of private IP addresses, a simple structure of the packet filters can be achieved. For example, a total range for selection of the first and second network addresses can be organized into subranges corresponding to different classes of users. These subranges then correspond to different subnets. Further, also differentiation with respect to other network resources can be achieved in an efficient manner, e.g., by correspondingly assigning different subnets to such other network resources or groups of other network resources. 
     As can be seen, by using the above described concepts, differentiated handling of data traffic related to different classes of users of a specific network resource can be implemented in a very efficient manner. 
     It is to be understood that the examples and embodiments as explained above are merely illustrative and susceptible to various modifications. For example, the concepts could be used in other types of communication network, without limitation to mobile communication networks. In such other types of communication networks, the bearers could be implemented in a different manner. For example, in an IP based network Differentiated Services Code Point Fields of the data packets could be set in order to implement an information transmission context or path of defined characteristics. Also, the concepts may be applied to any number of classes of users. Further, it is to be understood that the above concepts may be implemented by using correspondingly designed software in existing network devices, or by using dedicated network device hardware.