HK1151656B - Policy control and charging (pcc) rules based on mobility protocol - Google Patents

Description

Policy Control and Charging (PCC) rules based on mobility protocol

This application claims priority from U.S. provisional patent application No.61/021,013, entitled PCC RULES BASED ONIP-CAN FOR MOBILE IP, filed on 14.1.2008, assigned to the assignee of the present invention and incorporated herein by reference.

Technical Field

The present disclosure relates generally to communications, and more specifically to techniques for supporting Policy Control and Charging (PCC) functions in a wireless communication network.

Background

Wireless communication networks are widely deployed today to provide various communication services such as voice, video, packet data, messaging, broadcast, and so on. These wireless networks may be multiple-access networks that support multiple users by sharing the available network resources. Examples of such multiple access networks include: code Division Multiple Access (CDMA) networks, Time Division Multiple Access (TDMA) networks, Frequency Division Multiple Access (FDMA) networks, Orthogonal Frequency Division Multiple Access (OFDMA) networks, and single carrier FDMA (SC-FDMA) networks.

A User Equipment (UE) may communicate with a wireless network to exchange data with a remote entity (e.g., another UE). The UE may exchange data packets with remote entities and may route the packets through various network entities in the wireless network. The network entity may handle these packets differently depending on whether the UE supports roaming using a mobility protocol such as Mobile Internet Protocol (MIP). It may be desirable to support PCC functionality well regardless of whether the UE uses mobility protocols.

Disclosure of Invention

Techniques for supporting PCC functionality in a wireless communication network are described herein. In an aspect, the PCC rule for the PCC session may be determined based on (i.e., by considering) a parameter indicating whether the UE uses the mobility protocol. The parameter may be an IP-CAN type parameter present in PCC signaling. PCC rules determined in this manner may provide certain advantages, as described below.

In one design, a policy control and charging rules function (PCRF) (or equivalent network entity) may receive a request from a first network entity (e.g., a home agent) to establish a PCC session for a UE to access the first network entity using a mobility protocol (e.g., MIP). The request may include an IP-CAN type parameter, which may be set to a mobility protocol. The PCRF may determine a mobility protocol used by the UE based on the IP-CAN type parameter, and may determine PCC rules for the PCC session based on the mobility protocol. The PCC rules may include a first set of at least one filter to identify packets for the PCC session, an indication indicating whether to count the packets for charging, quality of service (QoS) rules for the packets, charging information for the PCC session, and/or other information related to the PCC session. The PCRF may send the PCC rules to the first network entity, which may apply the PCC rules on the packets of the PCC session and may count each packet for charging.

Packets of the PCC session may be encapsulated in tunneled packets, which may be exchanged between the UE and the first network entity via a second network entity (e.g., a serving gateway). In this case, the PCRF may determine a second PCC rule for the second network entity. The second PCC rule may include (i) a second set of at least one filter to identify the tunneled packet and (ii) an indication that the tunneled packet is not to be counted at charging, which may be implicitly provided by the absence of charging information in the second PCC rule. The PCRF may send the second PCC rules to the second network entity, which may apply the second PCC rules on the tunneled packets. The tunneled packets may be counted only once by the first network entity and not by the second network entity at the time of charging.

Various aspects and features of the disclosure are described in further detail below.

Drawings

Fig. 1 shows an exemplary network arrangement.

Fig. 2 shows packet processing for tunneling Internet Protocol (IP) packets.

Fig. 3 and 4 show two procedures for supporting the use of PCC of IP-CAN type.

Fig. 5 and 6 show a procedure and an apparatus, respectively, for supporting PCC functionality through PCRF.

Fig. 7 and 8 show a process and apparatus, respectively, for supporting PCC functionality via a home agent.

Fig. 9 and 10 show a process and apparatus, respectively, for supporting PCC functionality through a serving gateway.

Fig. 11 and 12 show a procedure and an apparatus for supporting PCC functionality by a UE, respectively.

Fig. 13 shows a block diagram of various network entities in fig. 1.

Detailed Description

The techniques described herein may be used for various wireless communication networks such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA and other networks. The terms "network" and "system" are generally used interchangeably. A CDMA network may implement a radio technology such as Universal Terrestrial Radio Access (UTRA), CDMA2000, and so on. UTRA includes wideband CDMA (W-CDMA) and other variants of CDMA. cdma2000 covers IS-2000, IS-95 and IS-856 standards. TDMA networks may implement wireless technologies such as global system for mobile communications (GSM). OFDMA networks may implement methods such as evolved UTRA (E-UTRA), Ultra Mobile Broadband (UMB), IEEE 802.11(Wi-Fi), IEEE802.16(WiMAX), IEEE 802.20, Flash-Etc. wireless technologies. UTRA and E-UTRA are part of the Universal Mobile Telecommunications System (UMTS). The 3GPP Long Term Evolution (LTE) is a release-to-date release of UMTS that uses E-UTRA. UTRA, E-UTRA, UMTS, LTE, and GSM are described in the literature for an organization named "third Generation partnership project" (3 GPP). Cdma2000 and UMB are described in a document entitled "third generation partnership project 2" (3GPP 2) organization. The techniques described herein may be used for the networks and wireless technologies given above, as well as other networks and wireless technologies. For clarity, certain aspects are described below for LTE, and LTE terminology is used in much of the description.

Fig. 1 shows an exemplary network arrangement 100. UE110 may communicate with an evolved universal terrestrial radio access network (E-UTRAN) 120a or a non-3 GPP Radio Access Network (RAN)120b to receive one or more data services, such as internet connectivity, Short Message Service (SMS), Instant Messaging (IM), Wireless Application Protocol (WAP) access, multimedia streaming, multimedia messaging, and so forth. UE110 may also be referred to as a mobile station, a terminal, an access terminal, a subscriber unit, a station, etc. The UE110 may be a handset, a Personal Digital Assistant (PDA), a wireless modem, a wireless communication device, a handset, a laptop, a cordless phone, a Wireless Local Loop (WLL) station, and so forth.

The E-UTRAN 120a may include evolved node Bs (eNBs) that support wireless communication for the UEs. An eNB may be a fixed station that communicates with UEs and may also be referred to as a node B, base station, access point, etc. The Serving Gateway (SGW)130a may interface the interface to the E-UTRAN 120a and may perform various functions, such as handover of the UE between multiple enbs, buffering, routing and forwarding of data for the UE, initiation of network-triggered service request procedures, accounting functions for charging, and so forth. The Home Agent (HA)140 may communicate directly or indirectly with the serving gateway 130a and may support one or more mobility protocols such as MIP, Proxy MIP (PMIP), dual stack mobile IPv6(DSMIPv6), mobile IPv4 collocated care-of-address (MIPv4-CCoA), General Packet Radio Service (GPRS) tunneling protocol (GTP), and so forth. Home agent 140 may maintain current location information for roaming UEs and may route packets for these UEs. The home agent 140 may be a gateway dedicated to the home agent or a gateway that may provide home agent functionality as well as other functionality.

Although not shown in fig. 1, a Packet Data Network (PDN) gateway may be coupled between the serving gateway 130a and the home agent 140. The PDN gateway may perform functions such as: packet filtering and IP address assignment for UEs, service level gating and rate enhancement, Dynamic Host Configuration Protocol (DHCP) functions for clients and servers, Gateway GPRS Support Node (GGSN) functions, etc. An authentication, authorization, and accounting/home subscriber server (AAA/HSS)142 may store subscription-related information (e.g., a user profile) and location information of the UE. AAA/HSS142 may perform authentication and authorization of the UE and provide the UE with information for requesting network entities.

The non-3 GPP RAN 120b may be a CDMA20001X network, a WiMAX network, a Wi-Fi network, or some other type of RAN. Non-3 GPP RAN 120b may interface with non-3 GPP gateway 130b, and non-3 GPP gateway 130b may perform functions similar to those performed by serving gateway 130 a.

PCRF150 and Policy and Charging Enforcement Function (PCEF) may jointly support PCC functionality. As shown in fig. 1, an instance of a PCEF may be co-located with each of gateways 130a and 130b and home agent 140. PCRF150 may act as a controller for PCC, receiving service information from an Application Function (AF), and providing PCC rules to the PCEF. The PCEF may enforce PCC rules provided by PCRF 150. For example, the PCEF may set the QoS for the IP flow and may provide charging functionality for the IP flow based on the PCC rules. IP flows may also be referred to as data flows, etc. PCC, PCRF and PCEF are described in publicly available 3GPP TS23.203 entitled "Policy and charging control architecture".

The network entities in fig. 1 may also be referred to by other names. For example, the PCEF for the serving gateway may be referred to as a Bearer Binding and Event Reporting Function (BBERF).

The RAN and the network entities in fig. 1 may belong to one or more Public Land Mobile Networks (PLMNs). For example, the Home PLMN (HPLMN) may include home agent 140 and AAA/HSS142, and the Visited PLMN (VPLMN) may include E-UTRA 120a and serving gateway 130 a. Non-3 GPP RAN 120b and non-3 GPP gateway 130b may belong to a HPLMN or VPLMN. The PCRF150 may include a local PCRF (H-PCRF) in the HPLMN and a visited PCRF (V-PCRF) in the VPLMN. Each PLMN also includes other network entities not shown in fig. 1.

Fig. 1 shows some network entities that may support an IP connectivity access network (IP-CAN). The IP-CAN is a collection of network entities and interfaces that provide IP transport connectivity between the UE and the core network entity. The network entities in fig. 1 may communicate with each other, directly or indirectly, e.g., via one or more data networks. In an Evolved Universal Radio Access Network (E-UTRAN) entitled "Evolved Universal Radio Access (E-UTRA) and Evolved Universal Radio Access Network (E-UTRAN); the Network entities of FIG. 1 are described in 3GPP TS 36.300 for Overall description "and 3GPP TS 23.401 entitled" General Packet Radio Services (GPRS) enhancements for Evolved Universal Radio Access Network (E-UTRAN) Access ". These documents are available to the public from 3 GPP.

UE110 may obtain internet connectivity via direct IP access and/or mobile IP access. Direct IP access refers to IP packet exchange between UE110 and a remote entity without support for UE mobility. Mobile IP access refers to the exchange of IP packets between UE110 and a remote entity via a network entity that can track the whereabouts of the UE and forward IP packets to the UE using tunneling. Mobile IP access may be supported using MIP, PMIP, DSMIPv6, MIPv-4CCoA, GTP, or some other mobility protocol. For example, UE110 may obtain direct IP access via serving gateway 130a or 130b and may exchange IP packets via gateway 130a or 130b without tunneling. UE110 may also obtain mobile IP access via home agent 140 using a mobility protocol such as MIP. For mobile IP access, IP packets may be tunneled between UE110 and home agent 140 via gateway 130a or 130 b.

Fig. 2 shows an example of a process for tunneling IP packets sent on the uplink from UE110 to home agent 140. UE110 may communicate with another UE and may generate an IP packet 210 to be sent to the other UE. The IP packet 210 includes an IP header and a payload. The IP header includes various fields including a source address field, a destination address field, and a protocol field. The source address field may be set to the IP address of the UE110 (UE1IP address), the destination address field may be set to the IP address of the other UE (UE2IP address) and the protocol field may be set to the transport layer protocol (e.g., TCP, UDP, etc.) used for the data sent in the payload. The payload of IP packet 210 may carry a transport layer datagram, which may include a header and a payload. The transport layer header may include (i) a source port field that may be set to port (port Y) at the UE110 and (ii) a destination port that may be set to port (port Z) at the other UE. The source address, destination address, and protocol fields of the header of the IP packet 210 and the source port and destination port fields of the header of the transport layer datagram may be considered as inner header fields.

IP packets 210 are un-tunneled packets and may be encapsulated by UE110 into tunneled IP packets 220 for uplink. For the tunneled IP packet 220, the source address field may be set to the IP address of UE110 (UE1IP address) and the destination address field may be set to the IP address of home agent 140 (HA IP address). The source address, destination address, and protocol fields of the header of IP packet 220 may be considered outer header fields

Tunnelled IP packets for the downlink may be generated in a similar manner except for the following differences. In the outer header, the source address may be set to the IP address of home agent 140 and the destination address may be set to the IP address of UE 110.

For the uplink, UE110 may perform tunneling of IP packets and home agent 140 may perform de-tunneling. UE110 may send the tunneled IP packet to gateway 130a or 130b, and gateway 130a or 130b may forward the tunneled IP packet to home agent 140. For the downlink, the home agent 140 may perform tunneling of IP packets and the UE110 may perform de-tunneling. Home agent 140 may send the tunneled IP packet to gateway 130a or 130b, and gateway 130a or 130b may forward the tunneled IP packet to UE 110. For simplicity, IP packets are also referred to simply as packets in the following description.

Referring back to fig. 1, PCRF150 may send PCC rules for the PCC session to the PCEF. A PCC session may be established between PCRF150 and serving gateway 130a, non-3 GPP gateway 130b, or home agent 140, and may cover one or more IP flows. Each IP flow is identified by a set of parameters that may include a source address, a destination address, a transport layer protocol, a source port, and a destination port as shown in fig. 2. The PCC rules for each PCC session may include information regarding the IP flows in the PCC session, QoS rules and policies to be applied to the IP flows, charging information for the IP flows, and/or other information related to the IP flows. The QoS rules may indicate bandwidth, delay, and priority for the IP flow, whether to block or pass packets in the IP flow, and so on. The charging information may indicate a charging mechanism for the IP flow, such as a rating, time-based or packet count-based charging.

When using a mobility protocol such as MIP, packets between UE110 and home agent 140 may be tunneled via gateway 130, which gateway 130 may be serving gateway 130a or non-3 GPP gateway 130 b. Gateway 130 should know that the packet is tunneled in order to properly apply the applicable PCC rules.

Furthermore, there may be situations where both home agent 140 and gateway 130 have active PCC sessions that are charged using PCRF 150. This may occur, for example, if UE110 has direct IP access via gateway 130 and also has mobile IP access via home agent 140. Gateway 130 may forward both un-tunneled packets for direct IP access and tunneled packets for mobile IP access from home agent 140. Since both gateway 130 and home agent 140 forward the tunneled packets, the packets should be counted only once to avoid duplicate billing. The same applies when home agent 140 and gateway 130 are co-located but have different PCC sessions with PCRF 150.

In an aspect, the PCC rule for the PCC session may be determined based on a parameter indicating whether the UE uses a mobility protocol. In one design, the parameter is an IP-CAN type parameter that is present in PCC signaling. The IP-CAN type parameters typically provide information about the radio access type, e.g., E-UTRA, CDMA20001X, WiMAX, Wi-Fi, etc. The IP-CAN type parameter CAN be extended to provide information about the mobility protocol. For example, the IP-CAN type parameter may indicate (i) whether the UE uses mobility protocols or (ii) which mobility protocols are used, e.g., MIP, PMIP, DSMIPv6, MIPv-4CCoA, GTP, etc. As described below, an IP-CAN type parameter may be used to distinguish between tunneled and non-tunneled packets.

For direct IP access, the IP-CAN type parameter may be set to wireless access type for a PCC session between gateway 130 (e.g., serving gateway 130a or non-3 GPP gateway 130b) and PCRF 150. Gateway 130 may then count the un-tunneled packets for the PCC session for charging and home agent 140 may not count the un-tunneled packets.

For mobile IP access, the IP-CAN type parameter may be set to mobility protocol (e.g., MIP) for the PCC session between home agent 140 and PCRF 150. The PCC session may be associated with a tunneled packet, and the PCC rules for the PCC session may relate to the tunneled packet. The home agent 140 may count tunneled packets for billing. Gateway 130 does not count the tunneled packets at the time of charging because it does not have a PCC session with IP-CAN type parameters set to mobility protocol.

Table 1 summarizes the use of IP-CAN type parameters to communicate different types of PCC sessions. Table 1 also summarizes the actions performed by each network entity for each type of PCC session.

TABLE 1

	The IP-CAN type is set to the wireless access type	IP-CAN type set as mobile protocol
			For	PCC session with direct IP access	PCC session with Mobile IP Access
Charging	The gateway counts the un-tunneled packets. The home agent ignores the non-tunneled packet.	The home agent counts the tunneled packets. The gateway ignores the tunnelled packet.

Fig. 3 shows a design of a process 300 to support PCC using IP-CAN type parameters. UE110 may access a RAN (e.g., E-UTRAN 120a or non-3 GPP RAN 120b in fig. 1) and communicate with gateway 130 (e.g., serving gateway 130a or non-3 GPP gateway 130b) for access authentication (step 1). Gateway 130 may further communicate with AAA/HSS142 for AAA and access authentication for UE110 (also step 1). UE110 may then perform IP address configuration with gateway 130 and may be assigned an IP address (step 2).

Gateway 130 may send a request/indication to PCRF150 for IP-CAN bearer session establishment (step 3). The request may include the UE identity of UE110, an IP-CAN type parameter, and possibly other information. The IP-CAN type parameter may identify a radio access type (e.g., E-UTRA, WiMAX, etc.) of the IP-CAN session (or PCC session) to be established. PCRF150 may determine that PCC authorization is needed and may request authorization for the allowed services and information about PCC rules from a local or external entity (not shown in fig. 3). PCRF150 may make authorization and policy decisions based on the request from gateway 130 and may determine PCC rules for the PCC session based on IP-CAN type parameters and other information. PCRF150 may then return an acknowledgement (Ack) of the IP-CAN session establishment to gateway 130 (step 4). The acknowledgement may include PCC rules, charging information, and/or other information for the PCEF at gateway 130. The PCEF may enforce PCC rules from PCRF 150.

In steps 3 and 4, a first PCC session may be established between gateway 130 and PCRF 150. The PCC session may be associated with the radio access type given in the IP-CAN type parameter sent in step 3 and the IP address assigned to UE110 in step 2. The wireless access specific PCC session may also be associated with un-tunneled packets that may be identified based on the service data flow template included in the PCC rules provided by PCRF150 in step 4. The service data flow template may include a set of service data flow filters for identifying un-tunneled packets of the IP flow covered by the PCC session. Gateway 130 may detect the un-tunneled packets of the PCC session based on the service data flow template and may count the packets for charging as indicated by the charging information provided by PCRF150 (block 5).

At a later time, UE110 may wish to use MIP. UE110 may determine that it is communicating with the visited network because its Home Network (HNP) IP address prefix is different from the gateway 130 IP address prefix. UE110 may perform an internet key exchange (IKEv2) to establish a security association with home agent 140 (step 6). Home agent 140 may also communicate with AAA/HSS142 to AAA the internet key exchange of UE110 (also step 6). UE110 may obtain a new IP address as the home address.

UE110 may then send a binding update to home agent 140 and provide its current location (step 7). The home agent 140 may then send a request/indication to the PCRF150 for IP-CAN bearer session establishment (step 8). The request may include an IP-CAN type parameter that may identify a mobility protocol (e.g., MIP) of the IP-CAN session to be established. PCRF150 may determine PCC authorization as needed and may make a decision on the request from home agent 140. PCRF150 may then return an acknowledgement of the IP-CAN session establishment to home agent 140 (step 9). The acknowledgement may include PCC rules, charging information, information regarding the tunneling encapsulation header of the mobility protocol, and/or other information for the PCEF at the home agent 140. The PCEF may implement PCC rules provided by PCRF 150. PCRF150 may also provide gateway 130 with PCC rules for tunneled packets for the PCC session between home agent 140 and PCRF150 (step 10). Gateway 130 may use the PCC rules to support QoS for the tunneled packet and/or perform other functions. Home agent 140 may also return a binding acknowledgement to UE110 (step 11).

A second PCC session may be established between home agent 140 and PCRF150 in steps 8 and 9. The PCC session may be associated with the mobility protocol given in the IP-CAN type parameter sent in step 8 and the IP address assigned to UE110 in step 6. The mobile protocol specific PCC session may also be associated with a tunneled packet, which may be identified based on a service data flow template included in the PCC rules provided by PCRF150 in step 9. The service data flow template may include a set of service data flow filters for identifying tunneled packets of the IP flow covered by the PCC session. Home agent 140 may detect tunneled packets of the PCC session based on the service data flow template and may count the packets for charging as indicated by charging information that PCRF150 is providing (block 12).

Fig. 4 shows a design of another process 400 to support PCC using IP-CAN type parameters. The UE110 may access the E-UTRAN 120a and the E-UTRAN 120a may belong to the HLPMN of the UE. UE110 may communicate with home agent 140 for IP address configuration (step 1). The home agent 140 may be a PDN gateway in the HLPMN and may also communicate with the AAA/HSS142 for AAA and access authentication of the UE110 (also step 1). The UE110 may obtain an IP address and a Home Network Prefix (HNP) from the home agent 140.

The home agent 140 may send a request/indication to the PCRF150 for IP-CAN bearer session establishment (step 2). The request may include an IP-CAN type parameter that may identify a radio access type (e.g., E-UTRA) of the IP-CAN session to be established. PCRF150 may determine PCC authorization as needed and may make a decision on the request from home agent 140. PCRF150 may then return an acknowledgement of the IP-CAN session establishment to home agent 140 (step 3). The acknowledgement may include PCC rules, charging information, and/or other information for the PCEF at home agent 140. The PCEF may implement PCC rules provided by PCRF 150.

A first PCC session may be established between home agent 140 and PCRF150 in steps 2 and 3. The PCC session may be associated with the radio access type given in the IP-CAN type parameter sent in step 2 and the HNP provided to UE110 in step 1. Home agent 140 may detect un-tunneled packets of the PCC session based on the service data flow template provided by PCRF150 and may count the packets for charging (block 4).

UE110 may perform an internet key exchange to establish a security association with home agent 140 (step 5). UE110 may recognize that it is in the HPLMN. As a result, the mobility protocol may not be activated and a PCC session of the mobility protocol may not be established.

Thereafter, the UE110 may move to the non-3 GPP RAN 120b and may perform access authentication and IP address configuration with the non-3 GPP gateway 130b (step 6). Gateway 130b may also communicate with AAA/HSS142 for AAA for access authentication of UE110 (or step 6). The gateway 130b may communicate with the PCRF150 to establish a gateway control session (step 7) and may set the IP-CAN type parameter to wireless access type (e.g., WiMAX) (step 7). PCRF150 may establish the gateway control session for gateway 130b and may send an acknowledgement for the gateway control session establishment (step 8). The gateway control session may be associated with the type of wireless access provided by gateway 130 b.

UE110 may thereafter send a binding update to home agent 140 and may provide its current location (step 9). The home agent 140 may then send a request/indication to the PCRF150 for IP-CAN bearer session establishment (step 10). The indication may include an IP-CAN type parameter that may identify a mobility protocol (e.g., DSMIPv6) of the IP-CAN session to be established. PCRF150 may determine PCC authorization as needed and may make a decision on the request from home agent 140. PCRF150 may then return an acknowledgement of the IP-CAN session establishment to home agent 140 (step 11). The acknowledgement may include PCC rules and other information for the PCEF at home agent 140. The PCEF may implement PCC rules provided by PCRF 150. PCRF150 may also provide gateway 130b with PCC rules for tunneled packets for the PCC session between home agent 140 and PCRF150 (step 12). Gateway 130 may use the PCC rules to support QoS for the tunneled packet and/or perform other functions. Home agent 140 may also return a binding acknowledgement to UE110 (step 13).

In steps 10 and 11, a second PCC session may be established between home agent 140 and PCRF 150. The PCC session may be associated with the mobility protocol given in the IP-CAN type parameters, the HNP of the home agent 140, and the care-of address (CoA) of the UE 110. Home agent 140 may detect the tunneled packets of the PCC session based on the service data flow template provided by PCRF150 in step 11 and may count the packets for charging (block 14).

As shown in fig. 3 and 4, the PCC may be supported by indicating to gateway 130 or home agent 140 whether the PCC rule applies only to un-tunneled packets (e.g., for a first PCC session in fig. 3 and 4), or only to tunneled packets (e.g., for a second PCC session in fig. 3 and 4), or to both un-tunneled and tunneled packets (not shown in fig. 3 and 4). Gateway 130 or home agent 140 may count all packets of its PCC session for charging and each packet will be counted only once by gateway 130 or home agent 140. For example, as shown in fig. 4, gateway 130 or home agent 140 can correctly count packets for its PCC session even if both tunneled traffic (e.g., MIP traffic) and un-tunneled traffic (e.g., local breakout traffic) are present.

Fig. 3 and 4 show two designs of PCC supporting mobility protocols with IP-CAN type parameters. The techniques may be used for various mobility protocols, such as MIP, DSMIPv6, MIPv4-CCoA, PMIP, GTP, and so on. As an example, in case of MIPv4, the IP-CAN type parameter is set to MIPv4-CCoA instead of MIP in fig. 3 and 4.

For clarity, certain aspects of the techniques are described for LTE. The techniques may also be used for other wireless networks that may include other network entities that may perform functions equivalent to those performed by the network entities shown in fig. 1. For example, in UMTS release 8, the PDN gateway may act as the serving gateway and home agent for the UE. The PDN gateway may have two PCC sessions for the UE. In one PCC session, the PDN gateway may act as a serving gateway for direct IP access by the UE via the UTRAN. In another PCC session, the PDN gateway may act as a home agent for mobile IP access by the UE via another RAN. The UE may send un-tunneled packets for direct IP access and tunneled packets for mobile IP access. The tunneled and non-tunneled packets may match different service data flow templates for the two PCC sessions at the PDN gateway and count each packet only once for the appropriate PCC session. This case may be illustrated as process 400 in fig. 4, in which case home agent 140 may represent a PDN gateway, the first PCC session may be for direct IP access and the second PCC session may be for mobile IP access.

Fig. 5 shows a design of a process 500 for supporting PCC functionality in a wireless network. Process 500 may be performed by a PCRF (described below) or some other network entity. The PCRF may receive a request/indication from a first network entity (e.g., a home agent) to establish a PCC session for the UE to access the first network entity using a mobility protocol (e.g., MIP, PMIP, DSMIPv6, MIPv4-CCoA, GTP, etc.) (block 512). The PCRF may determine the mobility protocol used by the UE based on the request (block 514). In one design, the PCRF may obtain the IP-CAN type parameters from the request and may determine the mobility protocol used by the UE based on the IP-CAN type parameters. The mobility protocol may also be communicated in other ways, for example, using other parameters sent in the request.

The PCRF may determine PCC rules for the PCC session based on the mobility protocol and possibly other information (block 516). The PCC rules may include a set of at least one filter to identify packets for the PCC session, an indication of whether to count packets for charging, QoS rules for the packets, charging information for the PCC session, and/or other information related to the PCC session. The PCRF may send the PCC rules to the first network entity (block 518).

Packets of the PCC session may be encapsulated into tunneled packets, which may be exchanged between the UE and the first network entity via a second network entity (e.g., a serving gateway). In this case, the PCRF may determine a second PCC rule that includes (i) a set of at least one filter to identify the tunneled packets and (ii) an indication that the tunneled packets are not to be counted at charging, which may be implicitly provided by the absence of charging information in the second PCC rule (block 520). For example, the second PCC rule may include only the QoS rule and the set of at least one filter without charging information. The PCRF may send the second PCC rules to the second network entity to apply to the tunneled packets (block 522). The tunneled packets may be counted once by the first network entity instead of by the second network entity.

The PCRF may receive a second request from a third network entity (e.g., another serving gateway) to establish a second PCC session for the UE. The UE may have direct IP access with the third network entity and may exchange packets with the third network entity without tunneling. The PCRF may determine, based on the second request, a radio access type used by the UE for the third network entity. In one design, the PCRF may obtain the IP-CAN type parameter from the second request and may determine the type of radio access used by the UE based on the IP-CAN type parameter. The PCRF may determine a third PCC rule for the second PCC session based on a radio access type used by the UE. The third PCC rule may include, among other information, at least one filter to identify un-tunneled packets for the second PCC session. The PCRF may then send the third PCC rules to the third network entity.

Fig. 6 shows a design of an apparatus 600 for supporting PCC functionality in a wireless network. The apparatus 600 comprises: a module 612 for receiving a request from a first network entity to establish a PCC session for a UE using a mobility protocol for accessing the first network entity; a module 614 for determining a mobility protocol used by the UE based on the request; a module 616 for determining PCC rules for the PCC session based on the mobility protocol; a module 618, configured to send a PCC rule to the first network entity; a module 620 for determining a second PCC rule comprising a set of at least one filter for identifying tunneled packets for a PCC session and an indication indicating not to count tunneled packets at charging; and a module 622 for sending the second PCC rule to the second network entity for application to the tunneled packet.

Fig. 7 shows a design of a process 700 for supporting PCC functionality. A first network entity (e.g., a home agent) may accept UE mobility protocol based access (block 712). The first network entity may send a request to a second network entity (e.g., PCRF) to establish a PCC session for the UE (block 714). The request may include a mobility protocol used by the UE. In one design, the request may include an IP-CAN type parameter that may be set to a mobility protocol used by the UE.

The first network entity may receive PCC rules for the PCC session from the second network entity (block 716). The PCC rules may be determined by the PCRF based on mobility protocols. The PCC rules may include a set of at least one filter to identify packets for the PCC session, an indication of whether to count the packets for charging, QoS rules for the packets, charging information for the PCC session, and/or other information for the PCC session. The first network entity may apply the PCC rule to packets exchanged with the UE for the PCC session (block 718). These packets may be sent in tunneled packets. In one design of block 718, the first network entity may identify packets of the PCC session based on the set of at least one filter obtained from the PCC rule. The first network entity may count packets for charging.

Fig. 8 shows a design of an apparatus 800 for supporting PCC functionality. The apparatus 800 comprises: a module 812 for accepting access of the UE based on a mobility protocol at the first network entity; a module 814 for sending a request to a second network entity to establish a PCC session for a UE, the request including a mobility protocol used by the UE; a module 816 configured to receive, from the second network entity, a PCC rule for the PCC session, the PCC rule being determined based on a mobility protocol; and module 818 for applying the PCC rule to packets exchanged with the UE for the PCC session.

Fig. 9 shows a design of a process 900 for supporting PCC functionality. A first network entity (e.g., a serving gateway) may receive PCC rules for a PCC session established by a second network entity (e.g., a home agent) for a UE to access the second network entity using a mobility protocol (e.g., MIP) (block 912). The UE and the second network entity may exchange tunneled data, which may be forwarded by the first network entity. The first network entity may identify a tunneled packet of the PCC session based on the first set of at least one filter obtained from the PCC rule (block 914). The first network entity may not count the tunneled packets at the time of charging, but instead the second network entity counts the tunneled packets for charging (block 916).

The first network entity may send a request to establish a second PCC session for the UE to access the first network entity using direct IP access (block 918). The request may include an IP-CAN type parameter set to a radio access type used by the UE for the first network entity. The first network entity may receive a second PCC rule for the second PCC session, which may be determined based on a type of radio access used by the UE (block 920). The first network entity may identify un-tunneled packets of the second PCC session based on the second set of at least one filter obtained from the second PCC rule (block 922) and may count the un-tunneled packets for charging (block 924).

Fig. 10 shows a design of an apparatus 1000 for supporting PCC functionality. The apparatus 1000 comprises: a module 1012 for receiving, at a first network entity, a PCC rule for a PCC session established by a second network entity for a UE to access a second network using mobility protocols; a module 1014 for identifying tunneled packets of the PCC session based on a first set of at least one filter obtained from the PCC rule; a module 1016 for not counting tunneled packets at charging, the tunneled packets being counted by the second network entity for charging; a module 1018 for sending a request to establish a second PCC session for the UE to access the first network entity using direct IP access; a module 1020 for receiving a second PCC rule for a second PCC session; a module 1022 for identifying un-tunneled packets of the second PCC session based on the second set of at least one filter obtained from the second PCC rule; and a module 1024 for counting un-tunneled packets for billing.

Fig. 11 shows a design of a process 1100 performed by a UE. The UE may access a first network entity (e.g., a home agent) using a mobility protocol (e.g., MIP) (block 1112). The first network entity may establish the PCC session for the UE based on the mobility protocol, e.g., by setting an IP-CAN type parameter to the mobility protocol. The UE may exchange tunneled packets for the PCC session with the first network entity (block 1114). The first network entity may count the tunneled packets for charging according to a PCC rule determined for the mobility protocol based PCC session.

The UE may access a second network entity (e.g., a serving gateway) using direct IP access (block 1116). The second network entity may establish a second PCC session for the UE based on a radio access type (e.g., E-UTRA, WiMAX, Wi-Fi, etc.) used by the UE for the second network entity. The UE may exchange un-tunneled packets of the second PCC session with the second network entity (block 1118). The second network entity may count the un-tunneled packets for charging according to a second PCC rule determined for a second PCC session based on the radio access type.

Tunneled packets of the first PCC session may be exchanged between the UE and the first network entity via the second network entity. The tunneled packets may be counted by the first network entity for charging and not counted by the second network entity.

Fig. 12 shows a design of an apparatus 1200 for a UE. The apparatus 1200 includes: a module 1212 for accessing, by a UE, a first network entity using a mobility protocol, wherein the first network entity establishes a PCC session for the UE based on the mobility protocol; module 1214 for exchanging tunnelled packets of a PCC session with a first network entity, wherein the first network entity counts the tunnelled packets for charging according to PCC rules determined for the mobile protocol based PCC session; a module 1216 for accessing, by the UE, the second network entity using direct IP access, wherein the second network entity establishes a second PCC session for the UE based on a radio access type used by the UE for the second network entity; and a module 1218 configured to exchange non-tunneled packets of the second PCC session with the second network entity, wherein the second network entity counts the non-tunneled packets for charging according to a second PCC rule determined for the second PCC session based on the radio access type.

The modules in fig. 6, 8, 10, and 12 may comprise processors, electronics devices, hardware devices, electronics components, logic circuits, memories, software codes, firmware codes, or any combination thereof.

Fig. 13 shows a design of UE110, RAN 120, gateway 130, home agent 140, and PCRF 150. The RAN 120 may be the E-UTRAN 120a or the non-3 GPP RAN 120b in FIG. 1 or some other RAN. The gateway 130 may be the serving gateway 130a or the non-3 GPP gateway 130b in fig. 1 or some other gateway. For simplicity, fig. 13 shows (i) a controller/processor 1130, a memory 1312, and a receiver/transmitter 1314 for UE110, (ii) a controller/processor 1320, a memory (Mem)1322, a receiver/transmitter 1324, and a communication (Comm) unit 1326 for RAN 120, (iii) a controller/processor 1330, a memory 1332, and a communication unit 1334 for gateway 130, (iv) a controller/processor 1340, a memory 1342, and a communication unit 1344 for home agent 140, and (v) a controller/processor 1340, a memory 1352, and a communication unit 1354 for PCRF 150. In general, each entity may include any number of controllers, processors, memories, transceivers, communication units, and the like.

On the downlink, the RAN 120 sends data and messages to UEs in its coverage area. The data and messages may be processed by processor 1320 and conditioned by transmitter 1324 to generate a downlink signal, which may be transmitted to the UE. At UE110, the downlink signals from RAN 120 may be received and conditioned by a receiver 1314 and processed by a processor 1310 to recover the data and messages sent to UE 110. A memory 1312 may store program codes and data for UE 110. Processor 130 may perform or direct process 1100 in fig. 11 and/or other processes for the techniques described herein. Processor 1310 may also perform the processing in message flows 300 and 400 in fig. 3 and 4, respectively, for UE 110.

On the uplink, UE110 may send data and messages to RAN 120. The data and messages can be processed by the processor 1310 and conditioned by the transmitter 1314 to generate an uplink signal, which can be transmitted to the RAN 120. At RAN 120, the uplink signals from UE110 and other UEs may be received and conditioned by a receiver 1324 and processed by a processor 1320 to recover the data and messages transmitted by the UEs. Memory 1322 may store program codes and data for RAN 120, which RAN 120 may communicate with other network entities via communication unit 1326.

In gateway 130, processor 1330 may perform processing for the gateway, memory 1332 may store program codes and data for the gateway, and communication unit 1334 may allow the gateway to communicate with other network entities. Processor 1330 may perform or direct process 900 in fig. 9 and/or other processes for the techniques described herein. Processor 1330 may also perform the processing in message flow 300 in fig. 3 for gateway 130 and the processing in message 400 in fig. 4 for non-3 GPP gateway 130 b.

In the home agent 140, the processor 1340 may perform processing for the home agent, the memory 1342 may store program codes and data for the home agent, and the communication unit 1344 may allow the home agent to communicate with other network entities. Processor 1340 may perform or direct process 700 in fig. 7 and/or other processes for the techniques described herein. Processor 1310 may also perform the processing in message flows 300 and 400 in fig. 3 and 4, respectively, for home agent 140.

In PCRF150, processor 1350 may perform processing for the PCRF, memory 1352 may store program codes and data for the PCRF, and communication unit 1354 may allow the PCRF to communicate with other network entities. Processor 1350 may perform or direct process 500 in fig. 5 and/or other processes for the techniques described herein. Processor 1350 may also perform the processing for PCRF150 in message flows 300 and 400 in fig. 3 and 4, respectively.

Those of skill in the art would understand that information and signals may be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the above description may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.

Those of skill would further appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the disclosure herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.

The various illustrative logical blocks, modules, and circuits described in connection with the disclosure may be implemented or performed with a general purpose processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, but, in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.

The steps of a method or algorithm described in connection with the disclosure herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor such the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an ASIC. The ASIC may reside in a user terminal. In the alternative, the processor and the storage medium may reside as discrete components in a user terminal.

In one or more exemplary designs, the functions described herein may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A storage media may be any available media that can be accessed by a general purpose or special purpose computer. Such computer-readable media can comprise, for example, but is not limited to, RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to carry or store desired program code means in the form of instructions or data structures and which can be accessed by a general-purpose or special-purpose computer, or a general-purpose or special-purpose processor. Also, any connection is properly termed a computer-readable medium. For example, if the software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, Digital Subscriber Line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. Disk or disc, as used herein, includes Compact Disc (CD), laser disc, optical disc, Digital Versatile Disc (DVD), floppy disk and blu-ray disc where disks (disks) usually reproduce data magnetically, while discs (discs) reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.

The previous description of the disclosure is provided to enable any person skilled in the art to make or use the present invention. Various modifications to the disclosure will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other variations without departing from the spirit or scope of the disclosure. Thus, the present invention is not intended to be limited to the examples and designs described herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims (29)

1. A method for wireless communication, comprising:

receiving a request from a first network entity to establish a policy control and charging, PCC, session for a user equipment, UE, to access the first network entity using mobility protocols;

determining the mobility protocol used by the UE based on the request;

determining a PCC rule for the PCC session based on the mobility protocol; and is

Sending the PCC rule to the first network entity.

2. The method of claim 1, wherein determining the mobility protocol used by the UE comprises:

obtaining an IP-CAN type parameter from the request, and

determining the mobility protocol used by the UE based on the IP-CAN type parameter.

3. The method of claim 1, wherein the PCC rules comprise at least one of: a set of at least one filter to identify packets of the PCC session, an indication indicating whether to count the packets for charging, quality of service (QoS) rules for the packets, and charging information for the PCC session.

4. The method of claim 1, wherein packets of the PCC session are encapsulated into tunneled packets exchanged between the UE and the first network entity via a second network entity, the method further comprising:

determining a second PCC rule comprising a set of at least one filter for identifying the tunneled packet and an indication indicating that the tunneled packet is not to be counted at charging; and is

Sending the second PCC rule to the second network entity for application to the tunneled packet.

5. The method of claim 1, further comprising:

receiving a second request from a second network entity to establish a second PCC session for the UE;

determining a radio access type used by the UE for the second network entity based on the second request;

determining a second PCC rule for the second PCC session based on the radio access type used by the UE; and is

Sending the second PCC rule to the second network entity.

6. The method of claim 5, wherein packets of the second PCC session are exchanged between the UE and the second network entity without tunneling, and wherein the second PCC rule includes at least one filter identifying un-tunneled packets of the second PCC session.

7. The method of claim 5, wherein the first network entity comprises a home agent that services mobile internet protocol, IP, access of the UE based on a mobility protocol, and wherein the second network entity comprises a serving gateway that services direct IP access of the UE.

8. An apparatus for wireless communication, comprising:

means for receiving a request from a first network entity to establish a policy control and charging, PCC, session for a user equipment, UE, to access the first network entity using mobility protocols;

means for determining the mobility protocol used by the UE based on the request;

means for determining PCC rules for the PCC session based on the mobility protocol; and

means for sending the PCC rule to the first network entity.

9. The apparatus of claim 8, wherein means for determining the mobility protocol used by the UE comprises:

a module for obtaining an IP-CAN type parameter from said request, an

Means for determining the mobility protocol used by the UE based on the IP-CAN type parameter.

10. The apparatus of claim 8, wherein packets of the PCC session are encapsulated into tunneled packets exchanged between the UE and the first network entity via a second network entity, the apparatus further comprising:

means for determining a second PCC rule comprising a set of at least one filter for identifying the tunneled packets and an indication indicating that the tunneled packets are not to be counted at charging, and

means for sending the second PCC rule to the second network entity for application to the tunneled packet.

11. The apparatus of claim 8, further comprising:

means for receiving a second request from a second network entity to establish a second PCC session for the UE;

means for determining a radio access type used by the UE for the second network entity based on the second request;

means for determining a second PCC rule for the second PCC session based on the radio access type used by the UE; and

means for sending the second PCC rule to the second network entity.

12. A method for wireless communication, comprising:

accepting, at a first network entity, mobility protocol based access by a user equipment, UE;

sending a request to a second network entity to establish a policy control and charging, PCC, session for the UE, the request including the mobility protocol used by the UE;

receiving, from the second network entity, a PCC rule for the PCC session, the PCC rule determined based on the mobility protocol; and is

Applying the PCC rule to packets exchanged with the UE for the PCC session.

13. The method of claim 12, further comprising:

setting an IP-CAN type parameter based on the mobility protocol used by the UE; and is

Generating the request including the IP-CAN type parameter.

14. The method of claim 12, wherein applying the PCC rule comprises:

identifying packets of the PCC session based on a set of at least one filter obtained from the PCC rule; and is

The packets are counted for billing.

15. The method of claim 12, wherein the PCC rules comprise at least one of: a set of at least one filter to identify packets of the PCC session, an indication indicating whether to count the packets for charging, quality of service (QoS) rules for the packets, and charging information for the PCC session.

16. The method of claim 12, wherein the first network entity comprises a home agent for the UE, and wherein the second network entity comprises a policy control and charging rules function, PCRF.

17. An apparatus for wireless communication, comprising:

means for accepting, at a first network entity, user equipment, UE, mobility protocol based access;

means for sending a request to a second network entity to establish a policy control and charging, PCC, session for the UE, the request including the mobility protocol used by the UE;

means for receiving, from the second network entity, a PCC rule for the PCC session, the PCC rule determined based on the mobility protocol; and is

Means for applying the PCC rule to packets exchanged with the UE for the PCC session.

18. The apparatus of claim 17, further comprising:

means for setting an IP-CAN type parameter based on the mobility protocol used by the UE; and is

Means for generating the request including the IP-CAN type parameter.

19. The apparatus of claim 17, further comprising:

means for identifying packets of the PCC session based on a set of at least one filter obtained from the PCC rule; and is

Means for counting the packets for billing.

20. A method for wireless communication, comprising:

receiving, at a first network entity, a policy control and charging, PCC, rule for a PCC session established by a second network entity for a user equipment, UE, to access the second network entity using a mobility protocol, the PCC rule determined based on the mobility protocol;

identifying tunneled packets of the PCC session based on a first set of at least one filter obtained from the PCC rule; and is

The tunneled packets are not counted at charging, the tunneled packets being counted by the second network entity for charging.

21. The method of claim 20, further comprising:

sending a request to establish a second PCC session for the UE to access the first network entity using direct Internet Protocol (IP) access;

receiving a second PCC rule for the second PCC session, the second PCC rule determined based on a radio access type used by the UE for the second network entity;

identifying un-tunneled packets of the second PCC session based on a second set of at least one filter obtained from the second PCC rule; and is

The un-tunneled packets are counted for billing.

22. An apparatus for wireless communication, comprising:

means for receiving, at a first network entity, a Policy Control and Charging (PCC) rule for a PCC session established by a second network entity for a User Equipment (UE) to access the second network entity using a mobility protocol, the PCC rule determined based on the mobility protocol;

means for identifying tunneled packets of the PCC session based on a first set of at least one filter obtained from the PCC rule; and is

Means for counting the tunneled packets at charging, the tunneled packets being counted by the second network entity for charging.

23. The apparatus of claim 22, further comprising:

means for sending a request to establish a second PCC session for the UE to access the first network entity using direct Internet Protocol (IP) access;

means for receiving a second PCC rule for the second PCC session, the second PCC rule determined based on a type of radio access used by the UE for the second network entity;

means for identifying un-tunneled packets of the second PCC session based on a second set of at least one filter obtained from the second PCC rule; and is

Means for counting the un-tunneled packets for charging.

24. A method for wireless communication, comprising:

accessing, by a User Equipment (UE), a first network entity using a mobility protocol, the first network entity establishing a Policy Control and Charging (PCC) session for the UE based on the mobility protocol; and is

Exchanging tunneled packets of the PCC session with the first network entity, the first network entity counting the tunneled packets for charging according to PCC rules determined for the PCC session based on the mobility protocol, and the PCC rules determined based on the mobility protocol.

25. The method of claim 24, further comprising:

accessing, by the UE, a second network entity using direct Internet protocol, IP, access, the second network entity establishing a second PCC session for the UE based on a radio access type used by the UE for the second network entity; and is

Exchanging non-tunneled packets of the second PCC session with the second network entity, the second network entity counting the non-tunneled packets for charging according to a second PCC rule determined for the second PCC session based on the radio access type.

26. The method of claim 25, wherein the tunneled packets are exchanged between the UE and the first network entity via the second network entity, and wherein the second network entity does not count the tunneled packets at charging.

27. The method of claim 25, wherein the first network entity comprises a home agent that services mobile IP access for the UE based on a mobility protocol, and wherein the second network entity comprises a serving gateway that services direct IP access for the UE.

28. An apparatus for wireless communication, comprising

Means for accessing, by a User Equipment (UE), a first network entity using a mobility protocol, the first network entity establishing a Policy Control and Charging (PCC) session for the UE based on the mobility protocol; and is

Means for exchanging tunneled packets of the PCC session with the first network entity, the first network entity counting the tunneled packets for charging according to PCC rules determined for the PCC session based on the mobility protocol, and the PCC rules determined based on the mobility protocol.

29. The apparatus of claim 28, further comprising:

means for accessing, by the UE, a second network entity using direct Internet Protocol (IP) access, the second network entity establishing a second PCC session for the UE based on a radio access type used by the UE for the second network entity; and is

Means for exchanging non-tunneled packets of the second PCC session with the second network entity, the second network entity counting the non-tunneled packets for charging according to a second PCC rule determined for the second PCC session based on the radio access type.