WO2012090401A1

WO2012090401A1 - Method for ip-based flow mobility and associated apparatus thereof

Info

Publication number: WO2012090401A1
Application number: PCT/JP2011/006884
Authority: WO
Inventors: Chun Keong Benjamin Lim; Chan Wah Ng; Hong Cheng; Keigo Aso
Original assignee: Panasonic Corporation
Priority date: 2010-12-28
Filing date: 2011-12-09
Publication date: 2012-07-05

Abstract

When a user equipment (UE) is roaming, a packet data network gateway (PGW) will be provided from the Policy and Charging Rules Function (PCRF), a set of Policy Control and Charging (PCC) rules for control of UE's packets. In addition, the Access Network Discovery and Selection Function (ANDSF) will provide the UE with a set of routing policies, known as Inter-System Routing Policy (ISRP). There is a possibility that the ISRP used by the UE differs from the PCC rule used by the PGW. This means that the UE will think that it is sending its IP packets correctly based on ISRP but the PGW is dropping the IP packets as it differs from the PCC rule. The solution is for UE to ask the network for information (e.g. location information of the PGW and the source of the PCC rule used by the PGW) to allow the UE to decipher which ISRP to use to overcome the problem.

Description

METHOD FOR IP-BASED FLOW MOBILITY AND ASSOCIATED APPARATUS THEREOF

This invention relates to the field of telecommunications in a packet-switched data communications network. More particularly, this invention pertains to a means to allow a communication node to understand which IP flow policy to apply when routing IP flows in a communications network.

In Third Generation Partnership Project (3GPP), the Long Term Evolution (LTE) program is developing a new system, termed the Evolved Packet System (EPS), which provides improved spectral efficiency, reduced latency and better utilization of radio resources. With the EPS, users can experience faster data rate and richer application and services at lower cost. In order to get connectivity to the EPS, a user has to obtain a User Equipment (UE) that is LTE compliant. In recent market trends, the UE normally supports multiple different radio technologies. For example, most mobile phones have at least a cellular radio interface to access the mobile cellular network and an IEEE 802.11 radio interface to access a Wireless Local Area network (WLAN). In an LTE deployment, a UE is also able to access the EPS services via different Public Land Mobile Networks (PLMNs) operated by different cellular operators. For a UE to access EPS services while connected to a PLMN operated by a foreign operator, it is termed as roaming.

Fig. 1 illustrates a roaming system described in the Third Generation Partnership Program (3GPP). In this system, Home PLMN (HPLMN 0100) is a network operated by an operator that UE 0101 has a contract with for EPS services. UE 0101 can roam to a visited PLMN (VPLMN 0102) to access EPS services. Operator of HPLMN 0100 can have a business agreement with the operator of VPLMN 0102 in order to ensure that subscribers of HPLMN 0100 are provided with EPS services when they roam to VPLMN 0102. UE 0100 has multiple radio interfaces, e.g. a cellular radio interface (IF 0103) and a WLAN radio interface (IF 0104). The cellular radio interface (IF 0103) is connected (S0105) to a Radio Access Technology (RAT 0106) while the WLAN radio interface (IF 0104) is connected (S0107) to another Radio Access Technology (RAT 0108). In this system, RAT could be, but not limited to, evolved UMTS radio access network (E-UTRAN), UMTS radio access network (UTRAN), GPRS radio access network (GERAN), WLAN or Worldwide Interoperability for Microwave Access (WiMAX), etc. In this system, RAT 0106 is assumed to be E-UTRAN, and RAT 0108 is assumed to be WLAN.

RAT 0106 is provided by an evolved Node B (eNB 0110) (via S0109). eNB 0110 manages RAT 0106 and handles the radio resource management and admission control for UE 0101. In addition, eNB 0110 is also responsible for necessary E-UTRAN functions, e.g. header compression, ciphering and reliable delivery of packets, etc. eNB 0110 is connected (via S0111) to a Mobility Management Entity (MME 0112). MME 0112 is responsible for a mobility signaling for UE 0101. This includes tracking the location of UE 0101 and paging for UE 0101. Furthermore, MME 0112 is involved in the bearer management, e.g. activation/deactivation process, for UE 0101. For this technology, a bearer is an information transmission path of defined capacity, delay and bit error rate. MME 0112 is connected (via S0113) to a Serving Gateway (SGW 0114). For UE 0101 to send data IP packets, UE 0101 would need to have a data path established first. In the due process, MME 0112 would instruct SGW 0114 to setup a data communication path (S0115) to eNB 0110 for UE 0101.

SGW 0114 is connected (S0116) to a Packet Data Network (PDN) Gateway (PGW 0117). For this system, PGW 0117 is located in HPLMN 0100. This is termed as the home-routed scenario. PGW 0117 is connected (S0118) to a home Packet Control and Charging Function (H-PCRF 0119). H-PCRF 0119 provides policy to PGW 0117 for the routing and treatment of IP packets for UE 0101. For example, a rule in the policy can specify a certain level of Quality of Service (QoS) to be provided to UE 0101. In addition, PGW 0117 uses the policy provided by H-PCRF 0119 to ensure that IP packets are routed in accordance. In this system, such policy provided by the PCRF is termed as Policy Charging and Control (PCC) rule. With the data path setup, UE 0101 can use IF 0103 to send/receive IP packets to/from the PDN connected via PGW 0117.

Additionally, UE 0101 can connect to PGW 0117 over another interface (IF 0104). In this system, RAT 0108 is assumed to be an untrusted WLAN. RAT 0108 is connected (via S0120) to an evolved Packet Data Gateway (ePDG 0121). ePDG 0121 acts as a gateway for UE 0101 into the cellular operator's network from RAT 0108. ePDG 0121 is connected (via S0122) to PGW 0117. It is assumed that the protocol to allow UE 0101 to connect simultaneously to PGW 0117 over different RATs is using Dual Stack Mobile IPv6 (DSMIPv6), see (NPL 1). A Binding Identifier (BID) allows UE 0101 to uniquely identify both connections (IF 0103, IF 0104) to PGW 0117. The BID is carried in the Binding Update (BU) message from UE 0101 to PGW 0117. The BU message serves as a periodic update by UE 0101 to PGW 0117 to let PGW 0117 to know that UE 0101 is still connected. Therefore, PGW 0117 serves as a Home Agent (HA) for UE 0101 and can use two possible data paths to send IP packets to UE 0101. A first path (to IF 0103) would be via signaling data path S0116, S0115, S0109 and S0105. A second path (to IF 0104) would be via signaling data path S0122, S0120 and S0107.

To allow for some means of control on which path IP packets are sent, UE 0101 is provided with a policy set that instructs how IP packets are to be routed. This policy set can be provided to UE 0101 from an entity in the network known as Access Network Discovery and Selection Function (ANDSF). In this system, such policy set provided by ANDSF is termed as Inter System Routing Policy (ISRP). When UE 0101 is roaming, it is possible for UE 0101 to have more than one ISRP. UE 0101 can setup a connection (S0123) with a home ANDSF (H-ANDSF 0124) and get a home ISRP (H-ISRP). Also, UE 0101 can setup a connection (S0125) with a visited ANDSF (V-ANDSF 0126) and get a visited ISRP (V-ISRP). With the ISRP, UE 0101 is provided with the guidance on how IP packets are to be routed and can install routing rules at PGW 0117. To uniquely identify the routing rules, a flow identifier (FID) is tagged to each routing rule. UE 0101 uses the BU message to convey routing rules to PGW 0117.

Fig. 2 illustrates another roaming system described in the Third Generation Partnership Program (3GPP). In this system, Home PLMN (HPLMN 0200) is a network operated by an operator that UE 0201 has a contract with for EPS services. UE 0201 can roam to a visited PLMN (VPLMN 0202) to access EPS services. HPLMN 0200 can have a business contract with VPLMN 0202 in order to ensure that HPLMN 0200 subscribers are provided with EPS services when HPLMN 0200 subscribers roam to VPLMN 0202. UE 0200 has multiple radio interfaces, for example a cellular radio interface (IF 0203) and a WLAN radio interface (IF 0204). The cellular radio interface (IF 0203) is connected (via S0205) to a Radio Access Technology (RAT 0206) while the WLAN radio interface (IF 0204) is connected (via S0207) to another Radio Access Technology (RAT 0208). In this system, RAT could be, but not limited to, evolved UMTS radio access network (E-UTRAN), UMTS radio access network (UTRAN), GPRS radio access network (GERAN), WLAN or Worldwide Interoperability for Microwave Access (WiMAX). In this system, RAT 0206 is assumed to be E-UTRAN.

RAT 0206 is connected (S0209) to an evolved Node B (eNB 0210). eNB 0210 manages RAT 0206 to handle the radio resource management and admission control for UE 0201. In addition, eNB 0210 is also responsible for header compression, ciphering and reliable delivery of packets, etc. eNB 0210 is connected (S0211) to a Mobility Management Entity (MME 0212). MME 0212 is responsible for the mobility signaling for UE 0201. This includes tracking the location of UE 0201 and paging for UE 0201. Furthermore, MME 0212 is involved in the bearer activation/deactivation process for UE 0201. For this technology, a bearer is an information transmission path of defined capacity, delay and bit error rate. MME 0212 is connected (S0213) to a Serving Gateway (SGW 0214). For UE 0201 to send data IP packets, UE 0201 would need to have a data path established. MME 0212 would instruct SGW 0214 to setup a data communication path (S0215) to eNB 0210 for UE 0201.

SGW 0214 is connected (S0216) to a Packet Data Network Gateway (PGW 0217). For this system, PGW 0217 is located in VPLMN 0202. This is termed as the local breakout with home policy scenario. PGW 0217 is connected (S0218) to a visited Packet Control and Charging Function (V-PCRF 0219). V-PCRF 0219 provides policy to PGW 0217 for the treatment and routing of IP packets for UE 0201. In this system, the policy that V-PCRF 0219 provides to PGW 0217 is obtained from H-PCRF 0220 via S0221. For example, a rule in the policy can be to provide UE 0201 with a certain level of Quality of Service (QoS). In addition, PGW 0217 uses the policy provided by V-PCRF 0219 to ensure that IP packets are routed in accordance. In this system, such policy provided by the PCRF is termed as Policy Charging and Control (PCC) rule. With the data path setup, UE 0201 can use IF 0203 to send/receive IP packets to/from the PDN via PGW 0217.

Additionally, UE 0201 can connect to PGW 0217 over another interface (IF 0204). In this system, RAT 0208 is assumed to be an untrusted WLAN. RAT 0208 is connected (S0222) to an evolved Packet Data Gateway (ePDG 0223). ePDG 0223 acts as a gateway for UE 0201 into the cellular operator's network from RAT 0208. ePDG 0223 is connected (S0224) to PGW 0217. It is assumed that the protocol to allow UE 0201 to connect simultaneously to PGW 0217 over different RATs is using Dual Stack Mobile IPv6 (DSMIPv6), see (NPL 1). A Binding Identifier (BID) allows UE 0201 to uniquely identify both connections (IF 0203, IF 0204) to PGW 0217. The BID is carried in the Binding Update (BU) message from UE 0201 to PGW 0217. The BU message serves as a periodic update by UE 0201 to PGW 0217 to let PGW 0217 to know that UE 0201 is still connected. Therefore, PGW 0217 serves as a Home Agent (HA) for UE 0201 and can use two possible data paths to send IP packets to UE 0201. A first path (to IF 0203) would be via signaling data path S0216, S0215, S0209 and S0205. A second path (to IF 0204) would be via signaling data path S0224, S0222 and S0207.

To allow for some means of control on which path IP packets are sent, UE 0201 can be provided a policy that instructs how IP packets are to be routed. This policy can be provided to UE 0201 from an entity in the network known as Access Network Discovery and Selection Function (ANDSF). In this system, such policy provided by ANDSF is termed as Inter System Routing Policy (ISRP). When UE 0201 is roaming, it is possible for UE 0201 to have more than one ISRP. UE 0201 can setup a connection (S0225) with a home ANDSF (H-ANDSF 0226) and get a home ISRP (H-ISRP). Also, UE 0201 can setup a connection (S0227) with a visited ANDSF (V-ANDSF 0228) and get a visited ISRP (V-ISRP). With the ISRP, UE 0201 is provided with the guidance on how IP packets are to be routed and can install routing rules at PGW 0217. To uniquely identify the routing rules, a flow identifier (FID) is tagged to each routing rule. UE 0201 uses the BU message to convey routing rules to PGW 0217.

Fig. 3 illustrates another roaming system described in the Third Generation Partnership Program (3GPP). In this system, Home PLMN (HPLMN 0300) is a network operated by an operator that UE 0301 has a contract with for LTE services. UE 0301 can roam to a visited PLMN (VPLMN 0302) to access EPS services. HPLMN 0300 can have a business contract with VPLMN 0302 in order to ensure that HPLMN 0300 subscribers are provided with EPS services when HPLMN 0300 subscribers roam to VPLMN 0302. UE 0300 is implemented with multiple radio interfaces, namely a cellular radio interface (IF 0303) and a WLAN radio interface (IF 0304). The cellular radio interface (IF 0303) is connected (S0305) to a Radio Access Technology (RAT 0306) while the WLAN radio interface (IF 0304) is connected (S0307) to another Radio Access Technology (RAT 0308). In this system, RAT could be, but not limited to, evolved UMTS radio access network (E-UTRAN), UMTS radio access network (UTRAN), GPRS radio access network (GERAN), WLAN or Worldwide Interoperability for Microwave Access (WiMAX). In this system, RAT 0306 is assumed to be E-UTRAN.

RAT 0306 is connected (S0309) to an evolved Node B (eNB 0310). eNB 0310 manages RAT 0306 to handle the radio resource management and admission control for UE 0301. In addition, eNB 0310 is also responsible for header compression, ciphering and reliable delivery of packets, etc. eNB 0310 is connected (S0311) to a Mobility Management Entity (MME 0312). MME 0312 is responsible for the mobility signaling for UE 0301. This includes tracking the location of UE 0301 and paging for UE 0301. Furthermore, MME 0312 is involved in the bearer activation/deactivation process for UE 0301. For this technology, a bearer is an information transmission path of defined capacity, delay and bit error rate. MME 0312 is connected (S0313) to a Serving Gateway (SGW 0314). For UE 0301 to send data IP packets, UE 0301 would need to have a data path established. MME 0312 would instruct SGW 0314 to setup a data communication path (S0315) to eNB 0310 for UE 0301.

SGW 0314 is connected (S0316) to a Packet Data Network Gateway (PGW 0317). For this system, PGW 0317 is located in VPLMN 0302. This is termed as the local breakout with visited policy scenario. PGW 0317 is connected (S0318) to a visited Packet Control and Charging Function (V-PCRF 0319). V-PCRF 0319 provides policy to PGW 0317 for the treatment and routing of IP packets for UE 0301. In this system, the policy that V-PCRF 0319 provides to PGW 0317 is configured by the VPLMN 0302 cellular operator. For example, a rule in the policy can be to provide UE 0301 with a certain level of Quality of Service (QoS). In addition, PGW 0317 uses the policy provided by V-PCRF 0319 to ensure that IP packets are routed in accordance. In this system, such policy provided by the PCRF is termed as Policy Charging and Control (PCC) rule. With the data path setup, UE 0301 can use IF 0303 to send/receive IP packets to/from the PDN via PGW 0317.

Additionally, UE 0301 can connect to PGW 0317 over another interface (IF 0304). In this system, RAT 0308 is assumed to be an untrusted WLAN. RAT 0308 is connected (S0320) to an evolved Packet Data Gateway (ePDG 0321). ePDG 0321 acts as a gateway for UE 0301 into the cellular operator's network from RAT 0308. ePDG 0321 is connected (S0322) to PGW 0317. It is assumed that the protocol to allow UE 0301 to connect simultaneously to PGW 0317 over different RATs is using Dual Stack Mobile IPv6 (DSMIPv6), see (NPL 1). A Binding Identifier (BID) allows UE 0301 to uniquely identify both connections (IF 0303, IF 0304) to PGW 0317. The BID is carried in the Binding Update (BU) message from UE 0301 to PGW 0317. The BU message serves as a periodic update by UE 0301 to PGW 0317 to let PGW 0317 to know that UE 0301 is still connected. Therefore, PGW 0317 serves as a Home Agent (HA) for UE 0301 and can use two possible data paths to send IP packets to UE 0301. A first path (to IF 0303) would be via signaling data path S0316, S0315, S0309 and S0305. A second path (to IF 0304) would be via signaling data path S0322, S0320 and S0307.

To allow for some means of control on which path IP packets are sent, UE 0301 can be provided a policy that instructs how IP packets are to be routed. This policy can be provided to UE 0301 from an entity in the network known as Access Network Discovery and Selection Function (ANDSF). In this system, such policy provided by ANDSF is termed as Inter System Routing Policy (ISRP). When UE 0301 is roaming, it is possible for UE 0301 to have more than one ISRP. UE 0301 can setup a connection (S0323) with a home ANDSF (H-ANDSF 0324) and get a home ISRP (H-ISRP). Also, UE 0301 can setup a connection (S0325) with a visited ANDSF (V-ANDSF 0326) and get a visited ISRP (V-ISRP). With the ISRP, UE 0301 is provided with the guidance on how IP packets are to be routed and can install routing rules at PGW 0317. To uniquely identify the routing rules, a flow identifier (FID) is tagged to each routing rule. UE 0301 uses the BU message to convey routing rules to PGW 0317.

Fig. 4 shows an example of a Policy Charging and Control (PCC) rule provided by a policy control and charging function to a packet data network gateway. Each PCC rule is associated to an IP-CAN session, such as identified by an IP address. PCC rule 0400 comprises Rule identifier 0401, Service data flow detection 0402, Charging 0403, Policy control 0404 and Usage Monitoring Control 0405. Rule identifier 0401 uniquely identifies the PCC rule within an IP-CAN session. It is used between PCRF and PGW for referencing PCC rules. In this example, the PCC rule is identified as Rule ID1. Service data flow detection 0402 is used for detecting IP packets belonging to a service data flow. It further comprises Service Data Flow Template 0406 that specifies the filters to be used by PGW for filtering IP packets. In this example, there are two service data flow filters. Service data flow filter 1, which is meant for Skype application, provides the instruction that if a PGW receives an IP packet with a source address of IPX and a source port number of 9090, the IP packet is to be forwarded to the UE's home address (HoA). Service data flow filter 2, which is meant for IMS voice application, provides the instruction that if a PGW receives an IP packet with a source address of IPY and a source port number of 4050, the IP packet is to be forwarded to the UE's HoA.

Charging 0403 provides the instructions to the PGW for charging and accounting. For example, charging information can provide the type of service and how the service should be charged (e.g. volume of usage, duration of usage, or QoS level based, etc). Policy control 0404 specifies how the PGW would control the IP flow. For example, gate status would let PGW know if the associated IP flow is to be forwarded (i.e. gate open) or dropped (i.e. gate closed). Usage Monitoring Control 0405 provides the information that is required to enable user plane monitoring of resources for an IP-CAN session.

Fig. 5 shows an example of inter-system routing policies present in a user equipment. In this example, it is assumed that the UE has multiple ISRPs, namely an H-ISRP 0500 and a V-ISRP 0501. H-ISRP 0500 comprises two routing policies. Routing policy 1 describes the routing rules for Skype and IMS voice applications, and is valid when the UE is connected to the HPLMN. Routing policy 2 describes the routing rules for Skype and IMS voice applications, and is valid when the UE is connected to the VPLMN. V-ISRP 0501 comprises one routing policy. Routing policy 3 describes the routing rules for Skype application and is valid when the UE is connected to the VPLMN.

When the UE is connected to a VPLMN and has multiple ISRPs, there is a possibility that the UE is selecting a routing policy that differs from the policy used by the PGW. This means that the UE applies an incorrect ISRP for an IP flow. For example, in Fig. 5, both routing policy 2 and routing policy 3 describe the routing rules for a UE when the UE is connected to VPLMN. In this scenario, the UE does not know which routing policy to use. Routing policy 2 is configured by HPLMN while routing policy 3 is configured by VPLMN. If the UE uses routing policy 2 but PGW uses PCC rule from V-PCRF, it is possible that the PGW would drop IP packets as the PGW detects a mismatch on how the IP packets are routed.

For example, in Fig. 3, it is assumed that the IP address for IF 0303 is HoA while the IP address for IF 0304 is CoA. UE 0301 uses routing policy 2 of H-ISRP 0500 and sends Skype IP packets via HoA. However, PGW 0317 uses the PCC rule provided by the V-PCRF 0319 which states that Skype IP packets must be routed over CoA. As PGW 0317 detects that Skype IP packets are not routed in accordance to the PCC rule, PGW 0317 drops that Skype IP packets.

Also, in (NPL 2), it describes the UE behavior in the event if the UE has access to multiple ISRPs. The behavior is for UE to use the ISRP of the registered PLMN, meaning the PLMN that the UE is currently connected to. Referring to Fig. 1, UE 0101 is connected to VPLMN 0102. Hence, following the behavior defined in (NPL 2), UE 0101 will use the V-ISRP for guidance on how IP packets are to be routed and install the appropriate routing rules at PGW 0117. Furthermore, it is assumed that PGW 0117 uses the PCC rule 0400 and UE 0101 has both H-ISRP 0500 and V-ISRP 0501. Another assumption is that the default route for UE 0101 is to IF 0104. Yet another assumption is that the IP address for IF 0103 is HoA while the IP address for IF 0104 is CoA. This means that if PGW 0117 receives an IP packet that does not match any routing filters that PGW 0117 has, PGW 0117 will send that IP packet to CoA.

When UE 0101 detects the launch of Skype application, UE 0101 uses the V-ISRP 0501 as guidance on how to route Skype IP packets. V-ISRP 0501 instructs UE 0101 to use WLAN (RAT 0108) for the routing of Skype IP packets. This means that UE 0101 should send/receive Skype IP packets over CoA. As the default route is CoA, UE does not need to install any routing rules at PGW 0117 as if PGW 0117 cannot find any routing rules for Skype IP packets, PGW 0117 will send Skype IP packets to CoA. However, when UE 0101 sends a Skype IP packet via CoA to PGW 0117, PGW 0117 might drop that Skype IP packet. The reason is that when PGW 0117 receives the Skype IP packet, PGW 0117 checks with the PCC rule 0400 and identifies that the Skype IP packet should be routed over HoA. Since PGW 0117 receives the Skype IP packet over CoA, it does not comply with the PCC rule and hence the Skype IP packet is dropped.

(PTL 1) explains how ANDSF can provide network selection policy to the UE for access network selection to route IP packets. This prior art proposes that when the UE queries ANDSF for a network selection policy to select access networks, ANDSF will ask PCRF for guidance on how to configure the policy for the UE. PCRF uses the policy rules that govern the routing of UE's IP packets (e.g. SDF template) to configure the network selection policy to be provided to the UE from ANDSF. Hence, this prior art can overcome the above mentioned problem by ensuring that the policy provided to the PGW and UE are synchronized.

(PTL 2) introduces a new entity in the network, known as routing policy control (RPC) function. RPC will ensure that the policy used for IP packets routing is synchronized between the UE and PGW. Hence, this prior art can overcome the above mentioned problem by ensuring that the policy provided to the PGW and UE are synchronized.

[PTL 1] Pittmann, F., "Optimizing ANDSF information provisioning for multiple-radio terminals", PCT Patent Application Publication Number WO2010/037422, April 8, 2010.
[PTL 2] Liebsch, M., Loureiro P-F., Kunz, A., "A radio network and a method for operating a radio network", PCT Patent Application Publication Number WO2010/069601, June 24, 2010.

Non-Patent Literature

[NPL 1] 3GPP TS 23.261 (V10.1.0): "IP flow mobility and seamless Wireless Local Area Network (WLAN) offload", September 29, 2010.
[NPL 2] 3GPP TS 24.302 (V10.1.0): "Access to the 3GPP Evolved Packet Core (EPC) via non-3GPP access networks", September 28, 2010.

A possible skilled person solution is for a UE to try and test each connection a UE has for an application to allow the UE to determine which ISRP to apply. For example, in Fig. 1, UE 0101 is connected to an APN which is managed by PGW 0117. UE 0101 sends a dummy IP packet for Skype over IF 0103 and IF 0104. As PGW 0117 is using PCC rule 0400 from H-PCRF, the dummy IP packet for Skype over IF 0104 would be dropped. This means UE 0101 will detect that Skype communication can only be done over IF 0103. Comparing H-ISRP 0500 and V-ISRP 0501, UE 0101 can deduce after testing, that routing policy 2 of H-ISRP 0500 matches the PCC rule used by PGW 0117. Thus, UE 0101 decides that any applications that would use the APN managed by PGW 0117 would require UE 0101 to consult H-ISRP 0500.

However, given a different scenario where each application to the same APN has a different routing rule, the above skilled person solution might not be suitable. For example, it is assumed that H-ISRP specifies the following routing rules for VPLMN. For Skype application IP flows, a routing rule is defined to be routed over IF 0103. For IMS voice application IP flows, a routing rule is defined to be routed over IF 0104. On the other hand, the V-ISRP specifies the following routing rules for VPLMN. For Skype application IP flows, a routing rule is defined to be routed over IF 0103. For IMS voice application IP flows, a routing rule is defined to be routed over IF 0103. If UE 0101 would to apply the result after testing Skype that all IP flows to the APN managed by PGW 0117 is to be sent over IF 0103 for IMS voice application, this means that PGW 0117 would drop IMS voice application IP flows as it differs from the PCC rules in PGW 0117. Thus, the problem of UE 0101 using an incorrect ISRP is still present.

According to the disclosure of (PTL 1), if one were to consider that ANDSF and PCRF are in different PLMNs, this would require tight co-ordination between operators of different PLMNs to allow ANDSF in PLMN A to query PCRF in PLMN B. This might require some security procedures which might lead an increase in network complexity to support such inter-PLMN queries. Furthermore, according to the disclosure of (PTL 2), there is the need to introduce new protocols into the 3GPP system to support this new entity which might increase the deployment cost of a network.

It is thus an objective of the present invention to overcome or at least substantially ameliorate the afore-mentioned disadvantages and shortcomings of the prior art. Specifically, the main objective of this invention is to ensure that a UE uses the correct ISRP for guidance on routing of IP packets. The correct ISRP will ensure that the UE's IP packets are not dropped by the PGW.

Accordingly, it is provided in a preferred embodiment of the present invention a user equipment comprising:
a network connecting unit configured to connect to a network where a flow filtering apparatus is located, the flow filtering apparatus performing flow filtering of a traffic flow for the user equipment, based on one of plural rules;
a policy storing unit configured to store plural routing policies which correspond to the plural rules respectively;
an information obtaining unit configured to obtain reference information to know a routing policy to be used for a traffic flow among the plural routing policies stored in the policy storing unit; and
a policy determining unit configured to determine the routing policy to be used for the traffic flow, based on the reference information obtained by the information obtaining unit.

Furthermore, it is provided in a preferred embodiment of the present invention a flow filtering apparatus located in a network, comprising:
a rule storing unit configured to store a rule which is used when performing flow filtering of a traffic flow for a user equipment connected to the network;
a flow filtering unit configured to perform the flow filtering of the traffic flow for the user equipment, based on the rule stored in the rule storing unit;
a query responding unit configured to send reference information for the user equipment to know a routing policy to be used for the traffic flow among plural routing policies which the user equipment has, when receiving a query from the user equipment.

In another preferred embodiment of the present invention a method used by an apparatus for filtering traffic flows comprising of: a step of deciding when to obtain information to know which routing policy to use for an application; and a step of understanding which routing policy to use based on the information obtained.

In another preferred embodiment of this invention, the step of deciding when to obtain information to know which routing policy to use for an application further comprises a step of checking if the UE already has information to understand which routing policy to use.

In yet another preferred embodiment of this invention, the method of checking if the UE already has information to understand which routing policy to use further comprises: a step of querying the location of the PGW if the UE does not already have information to understand which routing policy to use; and a step of determining the location of the PGW.

In another preferred embodiment of this invention, the step of determining the location of the PGW further comprises: a step of analyzing the location of the PGW; and a step of asking for the source of the PCC rules that the PGW is using if the location of the PGW is in the VPLMN.

In yet another preferred embodiment of this invention, the step of understanding which routing policy to use based on the information obtained further comprises a step of using the information obtained from the PGW to understand which routing policy to use.

In another preferred embodiment of this invention, the method used by apparatus for filtering traffic flows further comprises: a step of receiving ISRP with an Enforceable leaf; and a step of deciphering the ISRP.

In yet another preferred embodiment of this invention, the step of deciphering the ISRP further comprises a step of checking the Enforceable leaf in the ISRP to know if there is a need to obtain information to know which routing policy to use for an application.

The present invention has the advantage of ensuring that a UE uses the correct ISRP for guidance on routing of IP packets. In this way, the correct ISRP will ensure that the UE's IP packets are not dropped by the PGW.

Fig. 1 is a diagram illustrating a network topology of a home-routed scenario for a system described in the Third Generation Partnership Program (3GPP); Fig. 2 is another diagram illustrating a network topology of a local breakout with home policy scenario for a system described in the Third Generation Partnership Program (3GPP); Fig. 3 is a yet another diagram illustrating a network topology of a local breakout with visited policy scenario for a system described in the Third Generation Partnership Program (3GPP); Fig. 4 is a diagram illustrating a Policy Charging and Control (PCC) rule provided by a policy control and charging function to a packet data network gateway according to a prior art; Fig. 5 is a diagram illustrating Inter system routing policy present in a user equipment according to a prior art; Fig. 6 is a diagram illustrating a flow chart on a general logic performed by a user equipment to understand which ISRP apply according to a preferred embodiment of this invention; Fig. 7 is a diagram illustrating a message sequence that explains how a user equipment can query a PGW for information to decide which ISRP to use according to a preferred embodiment of this invention; Fig. 8 is a diagram illustrating a Policy Charging and Control (PCC) rule provided by a policy control and charging function to a packet data network gateway according to a preferred embodiment of this invention; Fig. 9 is a diagram illustrating a flow chart on a decision the user equipment undertakes to determine the need to query a PGW for information to decide which ISRP to use according to a preferred embodiment of this invention; Fig. 10 is a diagram illustrating the functional architecture of a preferred apparatus according to this invention; and Fig. 11 is a diagram illustrating Inter system routing policy present in a user equipment according to a preferred embodiment of this invention.

In the following description, for purposes of explanation, specific numbers, times, structures, protocol names, and other parameters are set forth in order to provide a thorough understanding of the present invention. However, it will be apparent to anyone skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known components and modules are shown in block diagrams in order not to obscure the present invention unnecessarily.

(General Method Embodiment)
The present invention provides a method for a UE to have knowledge of how the network is configured to identify which ISRP to use for IP packet routing. Once the UE knows how the network is configured, the UE can deduce which ISRP to apply that is suitable for the current network configuration. The benefit of having the UE to know which ISRP to apply will ensure that the UE knows how IP packet routing is done in the network and thus reduce the chances of the UE's IP packets being dropped by the network.

Fig. 6 illustrates a flow chart on a general logic performed by a UE to understand which ISRP to apply. The UE gathers necessary information that the UE has to aid in the UE's decision on which ISRP to apply (0600). Next (S0601), the UE determines if the information present in the UE is enough for the UE to know which ISRP to apply (0602). If the UE determines that the current information that the UE has is enough (S0603), the UE uses the information it has to decide which ISRP to apply (0604).

If the UE determines that the current information that the UE has is not enough (S0605), the UE will attempt to collect more information (e.g. by asking the PGW of the location of the PGW and the source of the PCC rule) to help the UE decide which ISRP to apply (0606). With new information obtained, the UE utilizes (S0607) the new information along with its current information to decide on which ISRP to apply (0600).

(Main Embodiment: UE asking the network for information)
Based on the network configurations shown in Fig. 1 to Fig. 3, the most straightforward way is for a UE to ask where the PGW is located. Fig. 7 describes a method for a UE to query a PGW for information. The method described in Fig. 7 can be done when the UE collects more information in step 0606 of Fig. 6. UE 0700 can represent UE 0101, UE 0201 or UE 0301. Similarly, PGW 0701 can represent PGW 0117, PGW 0217 or PGW 0317. When UE 0700 needs to know the location of PGW 0701, UE 0700 sends a query message 0702 to PGW 0701. PGW 0701 provides the response to UE 0700 in a response message 0703. For this invention, the location of the PGW 0701 can be represented by, but not limited to, the PLMN that the PGW 0701 is located in.

In one example, the query and response exchange is done via protocol configuration option (PCO). For this example, the query message 0702 can be, but not limited to, a Bearer resource allocation request, Bearer resource modification request, PDN connectivity request, Activate PDP context request, Activate Secondary PDP Context Request, Request PDP context activation, Modify PDP context request or Request Secondary PDP Context Activation. Similarly, the query response 0703 can be, but not restricted to, an Activate dedicated EPS bearer context request, Activate dedicated EPS bearer context accept, Activate default EPS bearer context request, Activate default EPS bearer context accept, Activate PDP context accept, Activate Secondary PDP Context Accept or Modify PDP context accept.

In another example, the query and response exchange is done via a payload in an Internet Key Exchange version 2 (IKEv2) protocol. For this example, the query message 0702 can be, but not limited to, an IKE_AUTH, IKE_SA_INIT, IKE_CHILD_SA, INFORMATIONAL request message. Similarly, the query response 0703 can be, but not restricted to, an IKE_AUTH, IKE_SA_INIT, IKE_CHILD_SA, INFORMATIONAL response message.

In yet another example, the query and response exchange is done via a MIPv6 vendor specific option in a Dual Stack Mobile IPv6 mobility message. For this example, the query message 0702 can be, but not limited to, a Binding Update message. Similarly, the query response 0703 can be, but not restricted to, a Binding Acknowledgement message.

In another example, the query and response exchange is done via a Dynamic Host Configuration Protocol (DHCP) vendor-specific information option in a DHCP message. For this example, the query message 0702 can be, but not limited to, a DHCP request message. Similarly, the query response 0703 can be, but not restricted to, a DHCP reply message.

In another example, the query and response exchange is done via some other service discovery protocols with extensions, e.g. DNS, SLP, SSDP, etc.

With knowledge of the location of a PGW by the UE, the UE can identify which ISRP to use. For example, in Fig. 1, PGW 0117 obtains PCC rule 0400 from H-PCRF 0119. In this example, it is assumed that PCC rule 0400 is associated with UE 0101 HoA (IF 0103). After querying PGW 0117, UE 0101 knows PGW 0117 is located in HPLMN 0100. Thus, by referring to Fig. 5, UE 0101 identifies that in the H-ISRP 0500, routing policy 1 is generated by source=HPLMN (HPLMN 0100) and the routing rules are valid in validityarea=HPLMN (HPLMN 0100). This lets UE 0101 know that H-ISRP routing policy 1 should be applied to ensure that PGW 0117 would not drop Skype IP packets.

Another example, in Fig. 3, PGW 0317 obtains PCC rule 0400 from V-PCRF 0319. In this example, it is assumed that PCC rule 0400 is associated with UE 0301 HoA (IF 0303). After querying PGW 0317, UE 0301 knows PGW 0317 is located in VPLMN 0302. Thus, by referring to Fig. 5, UE 0301 identifies that in the V-ISRP 0501, routing policy 3 is generated by source=VPLMN (VPLMN 0302) and the routing rules are valid in validityarea=VPLMN (VPLMN 0302). This lets UE 0301 know that V-ISRP routing policy 3 should be applied to ensure that PGW 0317 would not drop Skype IP packets.

However, in certain network configurations, the knowledge of PGW location might not allow a UE to identify the correct ISRP to use. Consider, for example, the case illustrated in Fig. 2 where PGW 0217 obtains PCC rule 0400 from V-PCRF 0219. However, V-PCRF 0219 gets PCC rule 0400 from H-PCRF 0220. Hence, when UE 0201 queries PGW 0217 of its location, UE 0201 knows PGW 0217 is located in VPLMN 0202. Referring to Fig. 5, UE 0201 might identify that in the V-ISRP 0501, routing policy 3 is generated by source=VPLMN (VPLMN 0202) and the routing rules are valid in validityarea=VPLMN (VPLMN 0202). Following V-ISRP 0501, UE routes Skype IP packets over CoA (WLAN). At PGW 0217, PCC rule 0400 is associated to HoA (E-UTRAN) and since Skype IP packets are not received over HoA, PGW 0217 drops the Skype IP packets.

To overcome this, in certain situations, there is a need for a UE to ask for additional information, for example, in case that the UE knows PGW is located in VPLMN. In this invention, the additional information can be, but not limited to, the source of the PCC rule that PGW is using.

Based on the network configurations shown in Fig. 1 to Fig. 3, the UE can determine which routing policy should be used by knowing that the PGW is provided with the PCC rule from either the H-PCRF or V-PCRF. If the UE knows the source of the PCC rule that a PGW is using, UE can use that information to identify if UE should use the H-ISRP or V-ISRP. Fig. 8 shows an extended format of the PCC rule. A new entry, known as Rule source 0800, is introduced in PCC rule 0400. Rule source 0800 identifies which domain created the PCC rule. For example, in Fig. 1, PCC rule 0400 is provided from H-PCRF 0119 to PGW 0117. Hence, H-PCRF 0119 specifies HPLMN 0100 for Rule source 0800 of PCC rule 0400. This allows the recipient of PCC rule 0400 (e.g. PGW 0117) to know that PCC rule 0400 is generated by a PCRF in PLMN 0100 (e.g. H-PCRF 0119) and respond the source of the PCC rule 0400 to the UE.

As another example, in Fig. 2, PCC rule 0400 is provided from V-PCRF 0219 to PGW 0217. However, V-PCRF 0219 gets PCC rule 0400 from H-PCRF 0220. Hence, it is H-PCRF 0220 that generates PCC rule 0400. Thus, Rule source 0800 of PCC rule 0400 would indicate HPLMN 0200. This allows the recipient of PCC rule 0400 (e.g. PGW 0217) to know that PCC rule 0400 is generated by a PCRF in PLMN 0100 (e.g. H-PCRF 0220) and respond the source of the PCC rule 0400 to the UE.

As yet another example, in Fig. 3, PCC rule 0400 is provided from V-PCRF 0319 to PGW 0317. Hence, V-PCRF 0319 specifies HPLMN 0302 for Rule source 0800 of PCC rule 0400. This allows the recipient of PCC rule 0400 (e.g. PGW 0317) to know that PCC rule 0400 is generated by a PCRF in PLMN 0302 (e.g. V-PCRF 0319) and respond the source of the PCC rule 0400 to the UE.

The UE can use the message exchange as described in Fig. 7 to ask PGW 0701 for the source of the PCC rule that the PGW is using. In one example, the query and response exchange is done via protocol configuration option (PCO). For this example, the query message 0702 can be, but not limited to, a Bearer resource allocation request, Bearer resource modification request, PDN connectivity request, Activate PDP context request, Activate Secondary PDP Context Request, Request PDP context activation, Modify PDP context request or Request Secondary PDP Context Activation. Similarly, the query response 0703 can be, but not restricted to, an Activate dedicated EPS bearer context request, Activate dedicated EPS bearer context accept, Activate default EPS bearer context request, Activate default EPS bearer context accept, Activate PDP context accept, Activate Secondary PDP Context Accept or Modify PDP context accept.

In a further example, the query and response exchange is done via a Dynamic Host Configuration Protocol (DHCP) vendor specific option in a DHCP message. For this example, the query message 0702 can be, but not limited to, a DHCP request message. Similarly, the query response 0703 can be, but not restricted to, a DHCP reply message.

In a yet further example, the query and response exchange is done via some other service discovery protocols with extensions, e.g. DNS, SLP, SSDP, etc.

In some situations, there is no need for a UE to ask for the source of the PCC rule that a PGW is using. For example, if the UE knows that the PGW is located in a HPLMN, then the PCC rule can only be provided by the H-PCRF. Fig. 9 illustrates a flow chart on a UE's decision logic to query a PGW for information about network configuration. The function starts (0900) when UE wants to create a new PDN connection to a PGW or the UE wants to start sending data through the PDN connection over either 3GPP access or Non-3GPP access. When this is triggered (S0901), the function instructs the UE to query for the location of PGW (0902). The UE can use the message exchange described in Fig. 7 to ask PGW 0701 for the location of the PGW 0701. If the function can know the location of the PGW 0701 by checking the IP address of the PGW 0701, the UE can use the message exchange described in Fig. 7 to obtain the IP address of PGW 0701. If the UE already has the IP address of the PGW 0701, the UE does not need to send a Query message to the PGW 0701. With knowledge of the location of the PGW, the function proceeds (S0903) to check if the PGW is located in a HPLMN (0904). If so (S0905), the function will determine that the UE should use the routing policy that is valid for HPLMN in the H-ANDSF ISRP (H-ISRP) (0906). Once the UE knows which ISRP to apply for an IP flow, the function proceeds (S0907) to terminate the decision process (0908).

If the function determines that the PGW is located in a VPLMN (S0909), the function will instruct the UE to ask the PGW of the source of the PCC rule the PGW is using (0910). The PGW obtains the source of the PCC rule from the Rule source 0800 in the PCC rule. When the UE receives the response from the PGW with the source of the PCC rule, the function (S0911) looks at which PLMN the PCC rule is from (0912). If the function determines the source of PCC rule is from the HPLMN (S0913), the function informs the UE to use the routing policy that is valid for VPLMN in the H-ANDSF ISRP (H-ISRP) (0914). Once the UE knows which ISRP to apply for an IP flow, the function proceeds (S0915) to terminate the decision process (0908). If the function determines the source of PCC rule is from the VPLMN (S0916), the function informs the UE to use the routing policy that is valid for VPLMN in the V-ANDSF ISRP (V-ISRP) (0917). Once the UE knows which ISRP to apply for an IP flow, the function proceeds (S0918) to terminate the decision process (0908). If the UE sends the query message to the PGW in order to ask the location of the PGW, the UE can ask the source of the PCC rule in the same message to reduce the number of message exchanged between the PGW and the UE.

Fig. 10 shows the functional architecture 1000 of a preferred apparatus (for example, UE 0101), comprising a network interface module 1001, a 3GPP access stack 1002, a non-3GPP access stack 1003, an IP Protocol stack 1004 and Applications 1005. This preferred apparatus might be, but not restricted to, any mobile electronic communication device such as a mobile phone or a laptop for the various preferred embodiments of this invention.

The network interface module 1001 is a functional block that encompasses all the hardware and software necessary for the preferred apparatus to communicate with another node via some communications medium. Using terminology well-known in the relevant field of art, the network interface module 1001 would represent communications components, firmware, drivers, and communications protocols of Layer 1 (Physical Layer) and Layer 2 (Data Link Layer). A person skilled in the art would appreciate that network interface module 1001 is an abstraction of all the communication technologies the UE has, e.g. WLAN, WiMAX, U-TRAN, GERAN, LTE, LTE-Advanced, etc. The signal/data path S1006 allows the network interface module 1001 to provide triggers/packets transmission to the 3GPP access stack 1002. For example, the network interface module 1001 would forward any NAS messages (e.g. PDN connectivity accept with PCO) it receives to the 3GPP access stack 1002 for processing. In addition, the signal/data path S1001 allows the 3GPP access stack 1002 to pass any NAS messages (e.g. PDN connectivity request with PCO) it wants to send to the network to the network interface module 1001 for transmission. The signal/data path S1007 allows the network interface module 1001 to provide triggers/packets transmission to the Non-3GPP access stack 1003. For example, the network interface module 1001 would forward any IKE messages it receives to the Non-3GPP access stack 1003 for processing. In addition, the signal/data path S1007 allows the Non-3GPP access stack 1003 to pass any IKE messages it wants to send to the network to the network interface module 1001 for transmission.

The 3GPP access stack 1002 is a functional block that manages the communication between the UE and the network over the 3GPP radio access networks. The 3GPP access stack 1002 handles the mobility and session aspects for the UE while the UE's cellular radio interface is roaming in the 3GPP radio access networks. The signal/data path S1008 allows the 3GPP access stack 1002 to provide triggers/packets transmission to the IP Protocol stack 1004. For example, when the network assigns an IP address or prefix for the UE's cellular radio interface, this IP address or prefix is conveyed in the NAS message. The 3GPP access stack 1002 passes the IP address or prefix to the IP Protocol stack 1004 for further processing. In addition, the signal/data path S1008 allows the IP Protocol stack 1004 to pass any IP packets it wants to send to the network to the 3GPP access stack 1002 for formatting. The signal/data path S1009 allows the 3GPP access stack 1002 to provide triggers/packets transmission to the Applications 1005. For example, when the UE wants to create a new PDN connection to a PGW, the 3GPP access stack 1002 will instruct the Policy Determination module 1010 to check the location of the PGW. In another example, when the PGW provides its location and/or the source of the PCC rule in the PCO, the 3GPP access stack 1002 will pass the information of the PGW location in the PCO to Policy Determination module 1010 for processing and possibly storing such information of the PGW in Database module 1011.

The Non-3GPP access stack 1003 is a functional block that manages the communication between the UE and the network over the non-3GPP radio access networks. The Non-3GPP access stack 1003 handles the mobility and security for the UE while the UE's WLAN radio interface is roaming in the non-3GPP radio access networks. The signal/data path S1012 allows the Non-3GPP access stack 1003 to provide triggers/packets transmission to the IP Protocol stack 1004. For example, when the network assigns an IP address or prefix for the UE's WLAN radio interface, this IP address or prefix is conveyed in the IKE message. The Non-3GPP access stack 1003 passes the IP address or prefix to the IP Protocol stack 1004 for further processing. In addition, the signal/data path S1012 allows the IP Protocol stack 1004 to pass any IP packets (e.g. Skype IP packets) it wants to send to the network to the Non-3GPP access stack 1003 for formatting. The signal/data path S1013 allows the Non-3GPP access stack 1003 to provide triggers/packets transmission to the Applications 1005. For example, when the PGW provides its location and/or the source of the PCC rule in the IKEv2 authentication response message, the Non-3GPP access stack 1003 will pass the information of the source of the PCC rule to Policy Determination module 1010 for processing and possibly storing such information in Database module 1011.

The IP Protocol stack 1004 is a functional block that comprises the software that implements the internet protocols in order for the UE to communicate with other nodes on the global internet, across the cellular network. For mobility function, the IP Protocol stack 1004 could comprise, but not limited to, Mobile IPv4 or Mobile IPv6. The signal/data path S1014 allows the IP Protocol stack 1004 to provide triggers/packets transmission to the Applications 1005. For example, if the IP Protocol stack 1004 receives an IP packet with a data payload for a particular application (e.g. Skype), the IP Protocol stack 1004 would pass the data payload to the Skype client application. In addition, the signal/data path S1014 allows the Applications 1005 to pass data payload from Applications 1005 to the IP Protocol stack 1004 for formatting into IP packets for transmission.

The Applications 1005 represent a functional block that encompasses all the protocols and programs that sit on top of the network layer in a communications stack. This includes any transport or session layer protocol, such as the Transmission Control Protocol (TCP), Stream Control Transport Protocol (SCTP), and User Datagram Protocol (UDP), or programs and software that need to communicate with other nodes. Applications 1005 further comprise a Policy Determination Module 1010 and a Database Module 1011. The Database Module 1011 provides storage of necessary information required by the functional architecture 1000. One example of such information could be, but not limited to the H-ISRP, V-ISRP or the routing rules in the binding cache of the UE.

This invention introduces the Policy Determination Module 1010 where the objective is to decide on the need to obtain information on the network configuration in order to know which ISRP to apply when routing an IP flow. For example, when the Policy Determination module 1010 receives a trigger from the UE Skype client to setup a PDN connection to an APN, Policy Determination module 1010 checks with Database module 1011 if there exists any information regarding the PGW that manages that APN. If there is no information about the PGW, Policy Determination module 1010 can trigger the UE to ask the PGW for the information. If the Policy Determination module 1010 is triggered by the establishment of a new PDN connection to an APN, the 3GPP access stack 1002 or the Non-3GPP access stack 1003 will instruct the Policy Determination module 1010 via the signal/data path S1009 or the signal/data path S1013 to check with the Database module 1011. If the Policy Determination module 1010 is triggered by sending data through the established PDN connections over the 3GPP access or the Non-3GPP access, the 3GPP Access stack 1002 or Non-3GPP Access stack 1003 that is instructed by the IP Protocol stack 1004 to send data will instruct the Policy Determination module 1010 to check with the Database module 1011.

Thus far, it has been described that the trigger for a UE to run the logic shown in Fig. 9 is based on when the UE wants to setup a PDN connection or when the UE wants to send data. In a variant embodiment, the trigger can be based on information that the UE may already have. For example, the UE has set up a connection to an APN and has obtained information on which ISRP to use for that APN. The UE now wants to set up another connection to the same APN. Based on the current 3GPP architecture, the same APN is managed by the same PGW and hence the UE does not need to query the PGW for information about the network configuration.

In another variant embodiment, the trigger can be based on the IP address of the PGW. For example, the UE has set up a connection to an APN and has obtained information on which ISRP to use for that APN. In addition, the UE is using DSMIPv6 and has the IP address of the PGW acting as the UE's home agent. When the UE wants to set up another PDN connection to a different APN, the UE discovers a home agent for that APN. If the UE sees the same home agent IP address, the UE can guess that both APNs are managed by the same PGW. Hence, the UE does not need to query the PGW for information about the network configuration.

In yet another variant embodiment, due to some operator policy to protect their network, it might not be possible for a UE to query for the PLMN that a PGW is located in. Thus, the UE can try to use other information to deduce the PGW's location. For example, the UE can query for the timezone that the PGW is located in. If the UE determines that the timezone provided by the PGW is similar to the UE's home timezone, the UE can determine that the PGW is located in HPLMN. On the other hand, if the timezone provided by the PGW is not similar to the UE's home timezone, the UE can determine that the PGW is located in VPLMN.

In another variant, the UE can query for the receiving time when the PCC rule that a PGW is using has been received by the PGW, in order to determine where the PGW is located. If the UE knows that the PCC rule has been received by the PGW before the UE begins to connect to a current network (VPLMN) due to handoff, the UE can determine that PGW is located in HPLMN. On the other hand, the UE knows that the PCC rule has been received by the PGW after the UE begins to connect to a current network (VPLMN) due to handoff, the UE can determine that the PGW is located in VPLMN. Furthermore, the UE can query for the generation time when the PCC rule that a PGW is using has been generated (i.e. when the PCC rule has been imposed for the UE), in order to determine the source of the PCC rule that the PGW is using. If the UE knows that the PCC rule has been generated before the UE begins to connect to a current network (VPLMN) due to handoff, the UE can determine that the source of the PCC rule is HPLMN. On the other hand, the UE knows that the PCC rule has been generated after the UE begins to connect to a current network (VPLMN) due to handoff, the UE can determine that the source of the PCC rule is VPLMN.

In yet another variant embodiment, it might be possible for a UE to use the charging information to determine the source of the PCC rule that a PGW is using. Such charging information is available in cellular operator's website that provides information to users on how much their data charge would be based on where the user roams to. The UE can query the PGW on what the current charging rate is for the UE. Based on the charging rate provided by the PGW and the charging information obtained by the UE from the cellular operator's website, the UE can deduce the location of the PGW and also the source of the PCC rule the PGW is using.

For example, the UE knows from the HPLMN operator's website that if the UE roams to VPLMN, the HPLMN operator will charge 10USD per MB. From the VPLMN operator's website, the charge is 3USD per MB. Assuming the network configuration is Fig. 3, UE 0301 queries PGW 0317 on the charging rate used and gets a response that it is 3USD per MB. Thus, UE 0301 can guess that PGW 0317 is located in VPLMN 0302 and the source of the PCC rule is from V-PCRF 0319.

(Variant Embodiment 1: Network uses TFT to tell UE)
In a variant embodiment, the network can assume that a UE might be confused on which ISRP to use for IP packets routing when multiple paths are present. Hence, the PGW can use the PCC rule it has to construct Traffic Flow Templates (TFTs) for the 3GPP cellular radio interface to assist the UE to know which ISRP to use. For example, referring to Fig. 1, PGW 0117 knows that Skype is to be routed over IF 0103 based on PCC rule 0400. Thus, PGW 0117 creates a TFT for Skype on IF 0103 and passes this TFT to UE 0101. When UE 0101 sees the TFT for Skype, UE 0101 checks both H-ISRP 0500 and V-ISRP 0501 to find a matching ISRP. Since V-ISRP 0501 states that Skype should be routed over IF 0104, UE 0101 understands V-ISRP 0501 is not the correct ISPR to use. Thus, UE 0101 uses the H-ISRP 0500 for routing of Skype IP packets.

(Variant Embodiment 2: Information provided by the network)
In another variant embodiment, the response from a PGW to a UE's query can contain additional information. The additional information could be, but not limited to, the ANDSF IP address that the UE should contact for the correct ISRP. For example, referring to Fig. 2, PGW 0217 knows from PCC rule 0400 that the source of PCC rule 0400 is from H-PCRF 0220. Thus, when UE 0201 either query for the location of PGW 0217 or the source of the PCC rule, PGW 0217 can further provide the IP address of H-ANDSF 0226 to UE 0201 in the response message. It can be assumed that PGW 0217 has been statically configured with the IP address of H-ANDSF 0226. The benefit of providing H-ANDSF 0226 IP address to UE 0201 is to remove the need for UE 0201 to perform discovery of H-ANDSF IP address if UE 0201 has not done so. This saves in the amount of signaling exchange that is needed for UE 0201 to discover the IP address of ANDSF.

(Variant Embodiment 3: Enforceable flag in ISRP)
In the previous embodiments, it is assumed that when a PGW receives an IP packet from a path that does not correspond to a PCC rule that the PGW is using, the PGW will drop the IP packet. This is deemed as an operator having very tight control of the network. However, it is possible that an operator can be a bit more flexible on routing selective IP flows. For example, an operator provides an application store where users can login to download applications for their mobile devices. There is no restriction on which access network that a user's UE can access the application store. Hence, the PCC rule that the PGW is using would not have any rules for application store specific IP packets, which can mean that the PGW is allowed to forward those IP packets regardless of where they are received from.

Referring to Fig. 1, if the UE were to send application store specific IP packets over either IF 0103 or IF 0104, PGW 0117 will forward the packets to the intended destination. However, if UE 0101 applies this invention, then when UE 0101 setups a PDN connection with PGW 0117, UE 0101 will query for the location for PGW 0117. It is not necessary for UE 0101 to make use of the location information of PGW 0117 since PGW 0117 will not drop UE 0101 application store specific IP packets. For this embodiment, to reduce the need for a UE to make unnecessary queries to the network, a new leaf is introduced in the ISRP to allow the network to inform the UE on the necessity for the UE to query for network configuration information to decide which ISRP to use.

Fig. 11 shows an extended format of the ISRP. A new leaf, known as Enforceable 1100, is introduced in the ISRP. Enforceable 1100 lets the UE know if a particular routing policy needs to be strictly followed to ensure that the IP packets would not be dropped by a PGW. For example, Enforceable 1100 is set to "No" in routing policy 1 of H-ISRP 0500. This means a flow specified in the routing policy can be transmitted over the access network that specified in the routing policy, therefore that if the UE were to route Skype IP packets over WLAN, the Skype IP packets would not be dropped by the PGW. In this case, the UE can know that regardless of how the UE sends the Skype IP packets, the network will not drop them. If the Enforceable 1100 is set to "Yes" in routing policy 1 of H-ISRP 0500, this means that a flow specified in the routing policy can be transmitted only over the access network that specified in the routing policy. Therefore, if the UE were to route Skype IP packets over WLAN, the Skype IP packets would be dropped by the PGW. Hence, the UE can use the value of the Enforceable leaf to determine if there is a need to trigger the UE decision logic described in Fig. 9.

(Variant Embodiment 4: Use the Enforceable flag to decide if to establish a new connection)
Another use of the "Enforceable" flag of the above ISRP format is for the UE to decide if it needs to establish a new connection towards the network. For example, the application layer may initiate a new Skype application, which fits the Routing Policy 1. The Routing Policy 1 indicates that "WLAN" type of connection should be used, but the UE may only have 3G connections.

The UE should check the "Enforceable" flag and decide whether an action should be taken. For example, if the "Enforceable" flag says "No", the UE can route the Skype application data via the existing connection over 3G, and ignore the Routing Policy. However, if the "Enforceable" flag says "Yes", the UE shall try to establish a new WLAN connection for the Skype traffic. In case the WLAN connection cannot be established, the UE should send an error message to the application layer, or drop the data packet. This would save radio resources by avoiding unnecessary traffic being sent to the network which would be dropped by the gateways.

(Variant Embodiment 5: Covering other technologies than DSMIP, and other ISRP types)
In the above embodiments, DSMIPv6 is used for illustration. However, it is obvious to anyone skilled in the art that other type of methods can be used without affecting the general principle of the present invention.

For example, the UE may have simultaneous multiple connections to the same PDN without using DSMIP. Examples of the mechanism could be, for example, the SCTP protocol, multipath TCP, Proxy Mobile IP, etc. In such cases, the ISRP rule set may have different IP Flow definitions, e.g. more than the normal 5 tuples to identify the IP flow. For example, the ISRP rule set may include further information, e.g. DSCP, IPv6 Flow Label, IPSec SPI, etc.

In another variant embodiment, the ISRP rules may indicate not only the type of access, but also a specific IP connectivity, e.g. PDN Connection type, PDN connection ID, or IP Prefix. For example, the ISRP rules may indicate that a particular traffic should go over a local breakout connection, a LIPA connection, SIPTO connection, or non-seamless WLAN offload connection.

It is obvious that the above variations of the ISRP contents do not affect the general principle of the invention.

Although the invention has been herein shown and described in what is conceived to be the most practical and preferred embodiments, it will be appreciated by those skilled in the art that various modifications may be made in details of design and parameters without departing from the scope and ambit of the invention. For example, in all the embodiments, reference was made to 3G and WLAN interface. However, it is important to appreciate that the invention is applicable when the UE has different type of access technology types and uses such different types of interfaces to attach to the network.

Each functional block used in the description of the embodiments as given above can be realized as LSI, typically represented by the integrated circuit. These may be produced as one chip individually or may be designed as one chip to include a part or all. Here, it is referred as LSI, while it may be called IC, system LSI, super LSI, or ultra LSI, depending on the degree of integration. Also, the technique of integrated circuit is not limited only to LSI and it may be realized as a dedicated circuit or a general-purpose processor. FPGA (Field Programmable Gate Array), which can be programmed after the manufacture of LSI, or a reconfigurable processor, in which connection or setting of circuit cell inside LSI can be reconfigured, may be used. Further, with the progress of semiconductor technique or other techniques derived from it, when the technique of circuit integration to replace LSI may emerge, the functional blocks may be integrated by using such technique. For example, the adaptation of bio-technology is one of such possibilities.

The present invention has the advantage of ensuring that a UE uses the correct ISRP for guidance on routing of IP packets, and can be applied to the field of telecommunications in a packet-switched data communications network.

Claims

A user equipment comprising:
- a network connecting unit configured to connect to a network where a flow filtering apparatus is located, the flow filtering apparatus performing flow filtering of a traffic flow for the user equipment, based on one of plural rules;
- a policy storing unit configured to store plural routing policies which correspond to the plural rules respectively;
- an information obtaining unit configured to obtain reference information to know a routing policy to be used for a traffic flow among the plural routing policies stored in the policy storing unit; and
- a policy determining unit configured to determine the routing policy to be used for the traffic flow, based on the reference information obtained by the information obtaining unit.
The user equipment according to claim 1, wherein the reference information includes location information indicating whether the flow filtering apparatus is located in a home network or visited network of the user equipment.
The user equipment according to claim 2, wherein the policy determining unit determines a first routing policy for the home network provided from the home network as the routing policy to be used for the traffic flow, when the policy determining unit knows that the flow filtering apparatus is located in the home network based on the location information.
The user equipment according to claim 2, wherein the information obtaining unit further obtains source information indicating a source of the rule which the flow filtering apparatus is using, if the information obtaining unit knows that the flow filtering apparatus is located in the visited network based on the location information.
The user equipment according to claim 4, wherein the policy determining unit determines a second routing policy for the visited network provided from the home network as the routing policy to be used for the traffic flow, when the policy determining unit knows that the rule which the flow filtering apparatus is using was generated by the home network based on the source information.
The user equipment according to claim 4, wherein the policy determining unit determines a third routing policy for the visited network provided from the visited network as the routing policy to be used for the traffic flow, when the policy determining unit knows that the rule which the flow filtering apparatus is using was generated by the visited network based on the source information.
The user equipment according to claim 1, wherein the reference information includes time information indicating a time when the rule which the flow filtering apparatus is using was received by the flow filtering apparatus, and the policy determining unit determines a first routing policy for the home network provided from the home network as the routing policy to be used for the traffic flow, when the policy determining unit knows that the time is before the user equipment connects to the network based on the time information.
The user equipment according to claim 1, wherein the reference information includes time information indicating a time when the rule which the flow filtering apparatus is using was generated, and the policy determining unit determines a third routing policy for the visited network provided from the visited network as the routing policy to be used for the traffic flow, when the policy determining unit knows that the time is after the user equipment connects to the network based on the time information.
The user equipment according to claim 1, wherein the information obtaining unit obtains the reference information from the flow filtering apparatus.
The user equipment according to claim 1, wherein the information obtaining unit obtains the reference information by sending a query to the flow filtering apparatus located in the network.
The user equipment according to claim 1, wherein each of the plural routing policies includes information indicating a need to determine the routing policy to be used for the traffic flow, and wherein the information obtaining unit starts obtaining the reference information only when there is the need to determine the routing policy
A flow filtering apparatus located in a network, comprising:
- a rule storing unit configured to store a rule which is used when performing flow filtering of a traffic flow for a user equipment connected to the network;
- a flow filtering unit configured to perform the flow filtering of the traffic flow for the user equipment, based on the rule stored in the rule storing unit;
- a query responding unit configured to send reference information for the user equipment to know a routing policy to be used for the traffic flow among plural routing policies which the user equipment has, when receiving a query from the user equipment.
The flow filtering apparatus according to claim 12, wherein the reference information sent by the query responding unit includes location information indicating whether the flow filtering apparatus is located in a home network or visited network of the user equipment.
The flow filtering apparatus according to claim 12, wherein the rule storing unit further stores source information indicating where the rule was generated, and wherein the query responding unit further sends the source information.
The flow filtering apparatus according to claim 12, wherein the reference information sent by the query responding unit includes time information indicating a time when the rule which the flow filtering apparatus is using was generated.