Abstract:
The present invention relates to a method for localization of peer-to-peer packet data traffic in a mobile network comprising a core network and at least one radio access network (RAN). The method comprises obtaining data traffic information for a packet data connection between two peers located in the RAN and where the connection is passing through a packet gateway node P-GW in the core network. If it is determined that the packet data connection is carrying peer-to-peer traffic, the PG-W requests localization policy information from a policy control function entity PCRF. The PCRF returns localization policy information related to the two peers and if localization is permitted, the P-GW requests a mobile management function entity to move the data traffic from the existing packet data connection to another packet data connection passing through another (local) packet gateway node L-GW which could be located in the same RAN as the peers.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     This application is a National stage of International Application No. PCT/SE2013/050577 filed May 21, 2013, which claims priority to International Application No. PCT/CN2012/075985 filed May 24, 2012, which are hereby incorporated by reference. 
     TECHNICAL FIELD 
     The present invention relates to a method and a node for localization of peer-to-peer packet data traffic in a mobile network. 
     BACKGROUND 
     Due to the quick growth of smart phone penetration, data traffic in mobile networks is experiencing an explosive growth. Among all mobile data traffic, video streaming is one important part. Along this trend, several streaming delivery methods have being deployed. Among all methods, Content Delivery Networks, CDN and Peer-to-peer, P2P are two important approaches to deliver streaming content over networks. Recently, some P2P based live streaming systems have being quite successful in context of fixed access networks. P2P streaming system is quite scalable by making use of uplink contribution from large amount of peers. Due to the advantage of P2P systems, several CDN players start introducing P2P into their CDN system. 
     On the other hand, existing P2P streaming systems are facing some problems in the context of mobile networks. For example, it is possible that one or more mobile peers involved in a P2P streaming application are located in the same area, such same cell/Base Station, BS or same Radio Access Network, RAN. While, according to current mobile network principles, a packet gateway node such as a P-GW/GGSN is the only IP anchor point for all user equipment, UEs served by it, and all IP traffic from/to UEs should be routed through the P-GW/GGSN. Therefore, the problem like triangle routing of mobile IPv4 would happen. The problem is more serious in case a large number of mobile peers are involved in streaming applications. 
     The problems are illustrated by three scenarios in  FIGS. 1 to 3 . 
     Summarizing these scenarios, in  FIG. 1  a mobile peer A located in a radio access network ( 111 ) involved in a P2P application may fetch a chunk of streaming content  132  from a server  131  in a content distribution network, CDN  130  and another chunk of data of the same streaming from another mobile peer B located in the same cell. Meanwhile, peer A may also fetch a different chunk of data of the same streaming from peer C located at a different base station but the same packet gateway node, S-GW ( 121 ) as in  FIG. 2 . Meanwhile, it may also fetch some chunks from peer D located at a different base station, a different S-GW ( 123 ) but the same packet gateway node, P-GW ( 122 ). In existing mobile networks, typically all IP traffic from/to a UE should be forwarded to P-GW ( 122 ), where IP traffic is routed to different destinations. 
     So, obviously, certain backhaul transport resources and core network element resources would be wasted in case a lot of IP traffic is exchanged between mobile peers local in same area. One problem is how to localize related P2P traffic. Another problem is how to enforce such traffic localization (P2P traffic turning). Another problem is how to recognize the right traffic for localization and which node to make decision for traffic localization. Yet another problem is to select factors that should be taken into account when deciding that certain traffic between certain peers should be localized or not. For example, due to some special requirements related to national security (as lawful interception) or charging considerations from operators, it is not permitted to enforce such traffic localization for certain UEs and certain traffic. While for other UEs and traffic it is possible. Another example, it is possible that certain UEs located in certain areas are not permitted for traffic localization. In addition, it is possible that traffic localization between certain peers is only expected due to some dynamic reasons, for example, the load in core network or backhaul transport network is about to be overloaded. 
     P2P traffic localization has been discussed both in the academic world and within industry and can basically be categorized into two types: 
     Type 1: Peer-driven biased neighbour selection for traffic localization. 
     The general idea of this approach is that, a specific peer performs optimized neighbour selection locally by various metrics, such as: latency based topology maps, Autonomous System, AS mapping and other related metrics locality-aware neighbour selection. 
     Type 2: ISP-driven biased neighbour selection for traffic localization. 
     The general thinking of this approach is that the ISP provides an underlay network info by some network elements to P2P application system for optimized peer selection. For example one or more trackers could be introduced by an operator to facilitate P2P system for more reasonable peer selection. Two important methods in this direction are: P4P framework and ALTO. Both of them are under development in different IETF working groups. 
     However, these prior art focus on ISP and fixed network level traffic localization. None of them has paid attention to traffic localization for mobile networks. 
     SUMMARY 
     With this background, it is the objective to obviate at least some of the problems mentioned above. 
     This objective is achieved by: 
     Firstly a method and a modified packet gateway node (such as a P-GW) that is configured to
         obtain data traffic information for an existing packet data connection between a first peer and a second peer passing through the packet gateway node   determine that the existing packet data connection is carrying peer-to-peer traffic   request for localization policy information from a policy control function entity (such as an PCRF) wherein the request comprises the obtained data traffic information and additional information such as location information about the first and the second peer   receive from the policy control function entity the requested localization policy information   and to request a mobile management function entity (such as an MME) to move the data traffic from the existing packet data connection to another packet data connection passing through another packet gateway node (such as a local gateway, L-GW) if the localization policy information received from the policy control function entity so permits.       

     Secondly a method and a mobile management function entity (such as an MME) that is configured to
         receive from the packet gateway node (such as the P-GW described above) the request to move the data traffic from the existing packet data connection (between the first peer and a second peer) to another second packet data connection passing through the second packet gateway node.   based on location information received in the request, select another packet gateway node   instruct the related UEs/peers to establish the other packet data connection between the first peer and the second peer through the selected second packet gateway node.       

     This solution has at least the following advantages:
         1. It makes it possible to localize peer to peer applications between local mobile UEs in a dynamic and flexible way by taking into account various dynamic info and policy from operators.   2. With the solution, backhaul transport resources and core network resources consumed by P2P traffic can be reduced significantly in case P2P streaming applications and the number of mobile peers is high.   3. The solution brings no or little impact to the installed base of RAN products such as base stations.       

     The invention will now be described in more detail and with preferred embodiments and referring to accompanying drawings. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWING 
         FIGS. 1, 2 and 3  are block diagrams showing existing P2P streaming systems. 
         FIGS. 4A and 4B  are block diagrams showing two embodiments of improved traffic localization in a mobile network. 
         FIGS. 5A, 5B and 5C  are message flow charts corresponding to the embodiments in  FIGS. 4A and 4B . 
         FIGS. 6A and 6B  are block diagrams showing embodiments of an improved packet gateway node and an improved mobile management function entity for traffic localization. 
     
    
    
     DETAILED DESCRIPTION 
       FIGS. 4A and 4B  illustrate two embodiments of improved traffic localization of P2P traffic in a mobile network comprising a core network  420  and at least one radio access network (here a LTE RAN  411 ).  FIG. 4A  illustrates the embodiment where the traffic localization is done in the core network  420  and  FIG. 4B  illustrates the embodiment where the traffic localization is done in the radio access network  411 .
         1. Upon identified P2P traffic in a packet data connection  441  between two mobile peers A 1  and B 1 , the packet gateway node P-GW  422  asks for traffic localization policy from a policy control node or function, PCRF  434  by reporting detected P2P traffic info (such as traffic content or channel ID/application ID info, P2P application name), and related peer info (location info, mobility info, UE ID) for peers A 1  an B 1 , as well as core network related load status information and/or backhaul link load status information.   2. The PCRF  434  generates a traffic localization policy regarding the related peers A 1 ,B 1 . In case of a roaming UE situation, the negotiation between a visited policy control node or function vPCRF and a home policy control node or function hPCRF may be performed to determine the traffic localization policy between two peers A 1 ,B 1 . During the process, subscription information for the UE 1 ,UE 2 , detected P2P traffic information reported from the P-GW  422 , a local packet gateway node L-GW topology, charging or security requirements for UE 1 ,UE 2  as well as another operator&#39;s strategy are taken into account.   3. The PCRF  434  replies to the P-GW  422  with specific traffic localization policy, which may include following information whether localization is permitted or not, associated condition (such as time or core network CN load status), where to localize related traffic (at RAN or CN level), and description information about traffic/applications subject to the localization policy.   4. According to the policy from the PCRF  434 , in case the traffic localization between related peers A 1 ,B 1  is permitted, the P-GW  422  initiates a traffic localization process by sending a message to a mobile management function/node MME  435 , wherein the message includes traffic localization level (RAN or CN), related traffic description/or specific UL and DL TFT to identify related IP traffic, ID of involved UE 1  and UE 2 .   5. The MME  435  is enhanced to select a common local gateway, L-GW for the involved UE 1  and UE 2  based on the traffic localization level indication provided from the P-GW  422 . In  FIG. 4A  the traffic localization level indication is set to Core Network, CN (and L-GW  425  is selected) and in  FIG. 4B  the traffic localization level indication is set to Radio Access Network, RAN (and L-GW  426  is selected).   6. The MME  435  may initiate a network based packet data connection setup process to each of the UE 1  and UE 2  by a NAS message which may indicate a cause for the additional packet data connection, such as traffic localization and service/application/traffic to be localized through the local packet data connection. During the process, the L-GW (LG-W  425  or L-GW  426 ) may allocate a new local IP address, which can be used by the mobile peer to exchange related P2P traffic/application with other mobile peers by local packet data connection. In addition, the IP address can be used by the L-GW  425 , 426  to route IP traffic between UE 1  and UE 2  locally.   7. On the local packet data connection, the MME  435  initiates a local bearer establishment process between the selected L-GW  425 , 426  and UE 1  and UE 2 , and moves related P2P applications/traffic to the local bearer  442 ,  443  by providing a specific UL TFT to related UE. Besides, DL TFT associated with the bearer  442 , 443  may be provided to the L-GW  425 , 426  for DL traffic mapping.   8. The mobile peer A 1 , B 1  may advertise its local IP address info associated with related P2P application/content permitted for localization to a tracker of the specific P2P application, as well as to other peers involved in the same application. Other neighbour mobile peers with similar local IP address may communicate directly with the mobile peer through local packet data connections.       

       FIGS. 5A, 5B and 5C  are message flow charts corresponding to the embodiments in  FIGS. 4A and 4B . 
     Through the bearer  441  established between UE 1  and UE 2 , two mobile peers A 1 , B 1  exchange P2P traffic through a P-GW or a GGSN  422 . The P-GW/GGSN  422  analyses in step  501  if there is some P2P application traffic between UE 1  and UE 2  based on deep packet inspection DPI functions. 
     If in step  501 , P2P application traffic is detected between the two local mobile peers A 1 , B 1 , the P-GW/GGSN  422  sends in step  502  a request message to the PCRF  434  to get traffic localization policy between the related peers A 1 ,B 1 . The message to the PCRF  434  may include the following info: detected P2P traffic info (such as traffic content or channel ID info, P2P application name), related peers info (location info, mobility info, UE ID), as well as core network related load status info and/or backhaul link load status info. 
     Upon receiving the request message from the P-GW/GGSN  422 , the PCRF  434  generates in step  503  traffic localization policy between the peers A 1 ,B 1  by taking into account the reported info, as well as subscription info of related UEs and L-GW topology info. The generated traffic localization policy may include: whether localization is permitted, associated condition (such as time or Core Network, CN load status), where to localize related traffic (at RAN or CN level), and description info about traffic/applications or UL TFT and DL TFT subject to localize policy. 
     The PCRF  434  provides the related traffic localization policy to the P-GW/GGSN  422  by a response message in step  504 . 
     Based on the policy info from the PCRF  434 , the P-GW  422  initiates a traffic localization process in case traffic localization should be enforced to the traffic between the two mobile peers A 1 , B 1 . More specifically, the P-GW  422  sends in step  505  a message to the MME  435  (for example through a S-GW  421 , 423  in  FIG. 4A or 4B ) the message including traffic localization level (RAN or CN), related P2P traffic description, ID of UE 1  and UE 2 . 
     The MME  435  selects in step  506  a common L-GW for the involved UEs based on the traffic localization level. For example, in case the traffic localization level is RAN, then a common L-GW  426  located in or above RAN  411  is selected for the involved UEs; in case traffic localization level is CN, then a common L-GW  425  located in the core network  420  is selected for the involved UEs. 
     If necessary, the MME  435  may initiate a network based packet data connection setup process to each UE in question by a NAS message to the UE as in step  507  and  508 . The message may indicate a cause for such additional packet data connection such as traffic localization, and service/application/traffic to be localized through the local packet data connection. In addition, the L-GW  425 ,  426  may allocate a new local IP address to the UE, which can be used by the mobile peer to exchange related P2P traffic/application with other mobile peers by local packet data connection. 
     On the local packet data connection, the MME  435  initiates in steps  509  and  510  a bearer establishment process between the selected L-GW  425 ,  426  and each UE 1 ,UE 2  and the related P2P application/traffic is moved in step  511  to the local bearer  442 , 443  by providing a specific UL TFT to the related UE. Besides, DL TFT associated with the bearer is provided to the L-GW  425 ,  426  for traffic mapping. The MME  435  further sends a traffic localization response back to the P-GW  422  in step  512 . 
     Through the new established bearer  442 , 443  between UE 1  and UE 2  and the common L-GW  425 , 426  the two peers A 1 , B 1  can exchange the specific P2P application traffic through the L-GW  425 , 426 . 
     Meanwhile, the mobile peers A 1 , B 1  may in steps  513  and  514  advertise their local IP address information associated with the related P2P application/content permitted for localization to the tracker  520  of the P2P system, as well as to other peers. Other neighbour mobile peers with similar local IP address may communicate directly on local packet data connections. 
       FIGS. 6A and 6B  are block diagrams illustrating embodiments of the improved packet gateway node, P-GW  422  and the improved mobile management function entity, MME  435 . 
     The P-GW  422  comprises a processor  4222  coupled to a non-transitory memory  4221  storing computer program instructions wherein when the processor  4222  executes the instructions, the P-GW  422  is caused to perform the method steps described above for the P-GW  422 . Similarly, the MME  435  comprises a processor  4352  coupled to a non-transitory memory  4351  storing computer program instructions wherein when the processor  4352  executes the instructions, the MME  435  is caused to perform the corresponding method steps described above for the MME  435 . 
     ABBREVIATIONS 
     
         
         ALTO Application-Layer Traffic Optimization 
         APN Access Point Name 
         BS Base Station 
         CDN Content Delivery Network 
         CN Core Network 
         DL TFT DownLink Traffic Flow Template 
         DPI Deep Packet Inspection 
         GGSN Gateway GPRS Support Node 
         GPRS General Packet Radio Services 
         hPCRF Home PCRF 
         IETF Internet Engineering Task Force 
         IP Internet Protocol 
         IP-v4 IP version 4 
         ISP Internet Service Provider 
         L-GW Local GateWay 
         LTE Long Term Evolution 
         MME Mobility Management Entity 
         NAS Non-access Stratum 
         PDN Public Data Network 
         P2P Peer-to-peer 
         P4P Proactive Provider Assistance for P2P 
         PCRF Policy and Charging Rules Function 
         P-GW PDN Gateway 
         RAN Radio Access Network 
         S-GW Serving Gateway 
         UE User Equipment 
         UL Uplink 
         UL TFT UpLink Traffic Flow Template 
         vPCRF Visited PCRF