U.S. patent application number 13/051749 was filed with the patent office on 2011-07-14 for method and system for implementing policy and charging control in multi-pdn scenario.
This patent application is currently assigned to Huawei Technologies Co., Ltd. Huawei Administration Building. Invention is credited to Yan LI, Weihua QIAO.
Application Number | 20110173332 13/051749 |
Document ID | / |
Family ID | 42029805 |
Filed Date | 2011-07-14 |
United States Patent
Application |
20110173332 |
Kind Code |
A1 |
LI; Yan ; et al. |
July 14, 2011 |
METHOD AND SYSTEM FOR IMPLEMENTING POLICY AND CHARGING CONTROL IN
MULTI-PDN SCENARIO
Abstract
A method for implementing Policy and Charging Control (PCC) in a
multi-Packet Data Network (PDN) scenario is disclosed. The method
includes: a Visited Policy Control and Charging Rules Function
(VPCRF) receives PCC rules and the associated S9 sub-session
information from a Home Policy Control and Charging Rules Function
(HPCRF), and sends the PCC rules according to the associated S9
sub-session information. The S9 session message carries associated
S9 sub-session information, and therefore, in a multi-PDN scenario,
the S9 session can distinguish and handle creation, modification
and deletion of the Internet Protocol Connectivity Access Network
(IP-CAN) session and the gateway control session, and the VPCRF can
understand the information delivered by the HPCRF, and send the
information to the correct Policy and Charging Enforcement Function
(PCEF) or Bearer Binding and Event Reporting Function (BBERF) for
enforcement; moreover, the VPCRF can report the PDN connection
release information to the HPCRF, and the HPCRF releases the
corresponding PDN connection, thus avoiding ineffective occupation
of resources and ensuring correct policies.
Inventors: |
LI; Yan; (Beijing, CN)
; QIAO; Weihua; (Beijing, CN) |
Assignee: |
Huawei Technologies Co., Ltd.
Huawei Administration Building
Shenzhen
CN
|
Family ID: |
42029805 |
Appl. No.: |
13/051749 |
Filed: |
March 18, 2011 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
PCT/CN2009/073877 |
Sep 11, 2009 |
|
|
|
13051749 |
|
|
|
|
Current U.S.
Class: |
709/227 |
Current CPC
Class: |
H04M 15/66 20130101;
H04L 12/14 20130101; H04M 15/00 20130101; H04W 4/24 20130101; H04L
12/1403 20130101 |
Class at
Publication: |
709/227 |
International
Class: |
G06F 15/16 20060101
G06F015/16 |
Foreign Application Data
Date |
Code |
Application Number |
Sep 18, 2008 |
CN |
200810216273.4 |
Claims
1. A method for implementing Policy and Charging Control (PCC) in a
multi-Packet Data Network (PDN) scenario, comprising: receiving, by
a Visited Policy Control and Charging Rules Function (VPCRF), PCC
rules and associated S9 sub-session information that are sent by a
Home Policy Control and Charging Rules Function (HPCRF); and
sending, by the VPCRF, the PCC rules according to the associated S9
sub-session information.
2. The method according to claim 1, wherein: an S9 sub-session
identified by the associated S9 sub-session information is in a
one-to-one mapping relationship with an Internet Protocol
Connectivity Access Network (IP-CAN) session.
3. The method according to claim 1, wherein: an S9 sub-session
identified by the associated S9 sub-session information is in a
one-to-one mapping relationship with a gateway control session.
4. The method according to claim 2, wherein sending, by the VPCRF,
the PCC rules according to the associated S9 sub-session
information comprises: sending, by the VPCRF, the PCC rules to a
PDN gateway (P-GW) through a corresponding IP-CAN session according
to the mapping relationship between the S9 sub-session identified
by the S9 associated sub-session information and the IP-CAN
session.
5. The method according to claim 3, wherein sending, by the VPCRF,
the PCC rules according to the associated S9 sub-session
information comprises: obtaining, by the VPCRF, Quality of Service
(QoS) rules from the PCC rules, and sending the QoS rules to a
Serving Gateway (S-GW) through a corresponding gateway control
session according to the mapping relationship between S9
sub-session identified by the associated S9 sub-session information
and the gateway control session.
6. A method for implementing Policy and Charging Control (PCC) in a
multi-Packet Data Network (PDN) scenario, comprising: receiving, by
a Home Policy Control and Charging Rules Function (HPCRF), a
trigger event sent by a Visited Policy Control and Charging Rules
Function (VPCRF); modifying, by the HPCRF, corresponding PCC rules
according to the trigger event; and sending, by the HPCRF, the PCC
rules and associated S9 sub-session information to the VPCRF so
that the VPCRF sends the PCC rules according to the received
associated S9 sub-session information.
7. The method according to claim 6, wherein: an S9 sub-session
identified by the associated S9 sub-session information is in a
one-to-one mapping relationship with an Internet Protocol
Connectivity Access Network (IP-CAN) session.
8. The method according to claim 6, wherein: an S9 sub-session
identified by the associated S9 sub-session information is in a
one-to-one mapping relationship with a gateway control session.
9. A system for implementing Policy and Charging Control (PCC) in a
multi-Packet Data Network (PDN) scenario, comprising: a Home Policy
Control and Charging Rules Function (HPCRF), configured to: receive
a trigger event sent by a Visited Policy Control and Charging Rules
Function (VPCRF), modify corresponding PCC rules according to the
trigger event, and send the PCC rules and associated S9 sub-session
information to the VPCRF; and the VPCRF, configured to receive the
PCC rules and the associated S9 sub-session information from the
HPCRF, and send the PCC rules according to the associated S9
sub-session information.
10. The system according to claim 9, wherein: an S9 sub-session
identified by the associated S9 sub-session information is in a
one-to-one mapping relationship with an Internet Protocol
Connectivity Access Network (IP-CAN) session.
11. The system according to claim 9, wherein: an S9 sub-session
identified by the associated S9 sub-session information is in a
one-to-one mapping relationship with a gateway control session.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application is a continuation of International
Application No. PCT/CN2009/073877, filed on Sep. 11, 2009, which
claims priority to Chinese Patent Application No. 200810216273.4,
filed on Sep. 18, 2008, both of which are hereby incorporated by
reference in their entireties.
FIELD OF THE DISCLOSURE
[0002] The present disclosure relates to communication
technologies, and in particular, to a method and system for
implementing Policy and Charging Control (PCC) in a scenario
involving multiple Packet Data Networks (PDNs), also known as a
multi-PDN scenario.
BACKGROUND
[0003] In the evolution to all Internet Protocol (IP), a
communication network needs to ensure end-to-end Quality of Service
(QoS) to provide services that satisfy users. An IP network
provides various services (such as multimedia call, file
downloading, and web browse). Different services require different
QoS (including bandwidth, delay, and packet loss ratio), and employ
different charging rules (such as online charging, offline
charging, flow-based charging, or time-based charging).
[0004] To meet the QoS and charging requirements, the 3rd
Generation Partnership Project (3GPP) defines a PCC architecture,
which fulfills different QoS control and charging requirements.
[0005] As shown in FIG. 1, the 3GPP TS 23.402 defines two roaming
scenarios in the PCC architecture: Home Routed and Local Breakout.
Home Routed means that: A Packet Data Network Gateway (P-GW) is
located in a Home PLMN (HPLMN), and the data needs to be connected
to the Application Server (AS) through the home gateway. Local
Breakout means that the P-GW is located in a Visited PLMN (VPLMN),
and the data is connected to the AS not through the home gateway,
but through the visited gateway.
[0006] In a Home Routed roaming scenario (as shown in FIG. 1a), a
gateway control session (namely, a Gxx session) is created between
a Serving Gateway (S-GW) and a Visited Policy Control and Charging
Rules Function (V-PCRF or VPCRF). The V-PCRF forwards information
to a Home Policy and Charging Rules Function (H-PCRF or HPCRF)
through an S9 interface, and transmits the policy generated by the
H-PCRF to the S-GW. An IP Connectivity Access Network (IP-CAN)
session (namely, a Gx session) is created between the P-GW and the
H-PCRF. The gateway control session information and the IP-CAN
session information are transmitted to the H-PCRF respectively, and
the H-PCRF generates policies. In this scenario, the IP-CAN session
information of the P-GW does not pass through the V-PCRF.
[0007] In a Local Breakout roaming scenario (as shown in FIG. 1b),
a gateway control session is created between the S-GW and the
V-PCRF, and an IP-CAN session is created between the P-GW and the
V-PCRF. The V-PCRF processes the gateway control session
information and the IP-CAN session information, and then forwards
the information to the H-PCRF. The H-PCRF generates policies. The
H-PCRF delivers generated PCC rules to the V-PCRF. The V-PCRF
extracts information from the PCC rules to generate QoS rules,
sends the PCC rules to the P-GW and sends the QoS rules to the
S-GW. In this scenario, the V-PCRF decides whether to transmit the
gateway control session information to the H-PCRF according to
information such as the PDN identifier (ID) and roaming agreement.
The IP-CAN session information of the P-GW is sent to the V-PCRF.
The V-PCRF processes the information and generates an S9 session,
and transmits the information to the H-PCRF.
[0008] For ease of understanding, the terms involved in the PCC
architecture are described below:
[0009] IP-CAN: If the IP service connectivity is maintained
(namely, without interrupting the service) when a user roams in an
access network (changes the location), such an access network is
called "IP-CAN". Examples of an IP-CAN include a General Packet
Radio Service (GPRS) network and an Interworking Wireless Local
Area Network (I-WLAN).
[0010] IP-CAN session: An IP-CAN session refers to a connection
relation between a user and a PDN ID (for example, the ID indicates
that the network is the Internet), and this connection relation is
identified by the IP address of the user and the user ID (for
example, an International Mobile Station Identity (IMSI) in the
3GPP). The IP-CAN exists only if the user is allocated an IP
address and can be identified by the IP network. The IP-CAN session
may include one or more IP-CAN bearers.
[0011] S9 session: The S9 session is a session between the V-PCRF
and the H-PCRF, designed to transmit IP-CAN session information,
gateway control session information or Rx information to the
H-PCRF, and also designed for the H-PCRF to transmit PCC (including
QoS) rule information.
[0012] Besides, the functional entities in the PCC architecture are
described below:
[0013] S-GW: The S-GW is responsible for processing the mobility of
the user, and interacts with the P-GW through an S5/S8 interface
over the GPRS Tunneling Protocol (GTP) or Proxy Mobile Internet
Protocol (PMIP), and interacts with the PCRF through a gateway
control session interface (namely, a Gxx interface) by means of
Diameter messages.
[0014] P-GW: The P-GW is responsible for communications with the
external PDN (Internet, or IP service defined by an operator such
as IP Multimedia Subsystem (IMS)) through an SGi interface (not
illustrated in the figure), and interacts with the S-GW through an
S5/S8 interface over GTP or PMIP, and interacts with the PCRF
through an IP-CAN interface (Gx interface) by means of Diameter
messages.
[0015] H-PCRF: The H-PCRF is responsible for policy decision and
flow-based charging control. The H-PCRF decides the corresponding
policy according to the policy of the operator, user subscription
data (obtained from a Subscription Profile Repository (SPR)) and
the ongoing service information (obtained from an Application
Function (AF)), and provides the policy to a Policy and Charging
Enforcement Function (PCEF), and the PCEF enforces the policy. The
policy may be PCC rules or independent properties. For ease of
description, the description herein ignores the nuances between the
policy and the PCC rule. The H-PCRF provides the QoS policy to a
Bearer Binding and Event Reporting Function (BBERF). The BBERF
performs the QoS and the session control function. The policies
include rules for detecting service data flows (namely, a set of IP
flows for implementing a service such as voice communications),
gating or not, QoS, and flow-based charging rule.
[0016] V-PCRF: The V-PCRF exists in a Local Breakout scenario, and
sends the service information provided by the visited AF and the
IP-CAN session information of the P-GW to the H-PCRF, and provides
an event reporting function. The V-PCRF provides operator policies
in the visited network so that the H-PCRF can formulate PCC rules.
The V-PCRF transmits the PCC policies formulated by the H-PCRF to
the P-GW, transmits the QoS policy formulated by the H-PCRF to the
S-GW, and answers the gateway control session. In a Home Routed
scenario, the V-PCRF reports events to the H-PCRF, and provides the
operator policies in the visited network so that the H-PCRF can
formulate PCC rules; the V-PCRF transmits the QoS policy formulated
by the H-PCRF to the S-GW, and answers the gateway control
session.
[0017] PCEF (included in the P-GW): The PCEF detects service data
flows, enforces policies, and performs flow-based charging. The
PCEF enforces the policies delivered or specified by the PCRF.
Specifically, the PCEF detects and measures the service data flows,
ensures the QoS of the service data flows, processes the user-plane
traffic, and triggers the control-plane session management. The
PCEF may exist in a network entity such as a PDN GW in a System
Architecture Evolution (SAE) network.
[0018] BBERF (included in an S-GW): The BBERF is capable of bearer
binding, uplink bearer verification, and event reporting. The BBERF
may exist in a network entity such as an S-GW in the SAE network,
or a non-3GPP access gateway in a non-3GPP network.
[0019] FIG. 2 shows a multi-PDN scenario. In this scenario:
[0020] 1. A User Equipment (UE) is connected to different external
PDNs (PDN1 or PDN2 in FIG. 2);
[0021] 2. The UE is connected to the PDN through an S-GW or a
non-3GPP access gateway, and one or more P-GWs;
[0022] 3. The PDN-GW creates an IP-CAN session (Gx1 and Gx2 in FIG.
2) for every external PDN connection of the UE;
[0023] 4. If the S-GW or the non-3GPP access gateway communicates
with the PDN-GW through PMIP, the S-GW creates a gateway control
session (Gxx1 and Gxx2 in FIG. 2) for every external PDN connection
of the UE; and
[0024] 5. If the non-3GPP access gateway communicates with the
PDN-GW through the Client Mobile Internet Protocol (CMIP), the S-GW
creates a gateway control session (not illustrated in FIG. 2) for
the UE.
[0025] In this scenario, the S9 session is created for every UE.
The S9 interface has only one session. The gateway control session
and all information of the IP-CAN session are sent as S9 session
information. The first IP-CAN session or gateway control session
triggers creation of the S9 session, and creation, modification or
deletion of every subsequent IP-CAN session or gateway control
session triggers modification or deletion of the S9 session.
[0026] As regards the multi-PDN scenario, the inventor finds at
least the following problems in the prior art in the process of
implementing the present disclosure:
[0027] The S9 session is unable to distinguish or handle creation,
modification or deletion of the IP-CAN session and the gateway
control session, and thus the V-PCRF is unable to understand the
information delivered by the H-PCRF and unable to send the
information to the correct PCEF or BBERF for enforcement, which
leads to failure of the PCC function; if the V-PCRF is unable to
report the PDN connection release information to the H-PCRF, the
H-PCRF is unable to release the corresponding PDN connection, which
leads to ineffective occupation of resources and incorrect
policies.
SUMMARY
[0028] Embodiments of the present disclosure provide a method and
system for implementing PCC in a multi-PDN scenario to overcome the
following defects in the prior art: the S9 session in a multi-PDN
scenario is unable to distinguish or handle creation, modification
or deletion of an IP-CAN session and an gateway control session,
and the V-PCRF is unable to understand the information delivered by
the H-PCRF and unable to send the information to the correct PCEF
or BBERF for enforcement, which leads to failure of the PCC
function.
[0029] A method for implementing PCC in a multi-PDN scenario in an
embodiment of the present disclosure includes: receiving, by a
VPCRF, P CC rules and associated S9 sub-session information sent by
an HPCRF; and sending the associated PCC rules according to the S9
sub-session information.
[0030] Another method for implementing PCC in a multi-PDN scenario
in an embodiment of the present disclosure includes: receiving, by
an HPCRF, a trigger event sent by a VPCRF; modifying corresponding
PCC rules according to the trigger event; and sending the PCC rules
and associated S9 sub-session information to the VPCRF so that the
VPCRF sends the PCC rules according to the received associated S9
sub-session information.
[0031] A system for implementing PCC in a multi-PDN scenario in an
embodiment of the present disclosure includes an HPCRF and a VPCRF.
The HPCRF is configured to: receive a trigger event sent by a
VPCRF, modify corresponding PCC rules according to the trigger
event, and send the PCC rules and associated S9 sub-session
information to the VPCRF. The VPCRF is configured to receive the
PCC rules and the associated S9 sub-session information associated
with the PCC rules from the HPCRF, and send the PCC rules according
to the associated S9 sub-session information.
[0032] In the embodiments of the present disclosure, an S9 session
message carries S9 sub-session information associated with PCC
rules, and therefore, in a multi-PDN scenario, the S9 session can
distinguish and handle creation, modification and deletion of the
IP-CAN session and the gateway control session, and the V-PCRF can
understand the information delivered by the H-PCRF, and send the
information to the correct PCEF or BBERF for enforcement; moreover,
the V-PCRF can report the PDN connection release information to the
H-PCRF, and the H-PCRF releases the corresponding PDN connection,
thus avoiding ineffective occupation of resources and ensuring
correct policies.
BRIEF DESCRIPTION OF THE DRAWINGS
[0033] FIG. 1a shows a Home Routed roaming scenario in a PCC
architecture defined by the 3GPP in the prior art;
[0034] FIG. 1b shows a Local Breakout roaming scenario in a PCC
architecture defined by the 3GPP in the prior art;
[0035] FIG. 2 shows a multi-PDN scenario in the prior art;
[0036] FIG. 3 is a flowchart of a method for implementing an S9
session in a multi-PDN scenario according to an embodiment of the
present disclosure;
[0037] FIG. 4 is a flowchart of a first embodiment of the present
disclosure;
[0038] FIG. 5 is a flowchart of a second embodiment of the present
disclosure;
[0039] FIG. 6 is a flowchart of a third embodiment of the present
disclosure;
[0040] FIG. 7 is a flowchart of a fourth embodiment of the present
disclosure;
[0041] FIG. 8 is a flowchart of a fifth embodiment of the present
disclosure; and
[0042] FIG. 9 is a flowchart of a sixth embodiment of the present
disclosure.
DETAILED DESCRIPTION OF THE EMBODIMENTS
[0043] To make the solution, objectives and merits of the present
disclosure clearer, the following describes the embodiments of the
present disclosure in more detail with reference to accompanying
drawings.
[0044] As shown in FIG. 3, the method for implementing an S9
session in a multi-PDN scenario in an embodiment of the present
disclosure includes the following steps:
[0045] Step 300: A V-PCRF receives an S9 session message that
carries PDN information from an H-PCRF.
[0046] The S9 session message carries the PDN information. In
practice, the PCC rules defined in the existing IP-CAN session may
be extended to carry the PDN information. Here is an example:
TABLE-US-00001 Charging-Rule-Definition ::= < AVP Header: 1003
> { Charging-Rule-Name } [ Called-Station-ID ] [
Service-Identifier ] [ Rating-Group ] *[ Flow-Description ] [
Flow-Status ] [ QoS-Information ] [ Reporting-Level ] [ Online ] [
Offline ] [ Metering-Method ] [ Precedence ] [
AF-Charging-Identifier ] *[ Flows ] *[ AVP ]
[0047] "Charging-Rule-Definition AVP" above is the definition of
the existing PCC rules, and the newly added "Called-Station-ID"
represents the PDN corresponding to the PCC rules.
[0048] Alternatively, the "Charging-Rule-Install" may be extended
to indicate that all PCC rules under this Attribute Value Pair
(AVP) are associated with the PDN. Here is an example:
TABLE-US-00002 Charging-Rule-Install ::= < AVP Header: 1001 >
*[ Charging-Rule-Definition ] *[ Charging-Rule-Name ] *[
Charging-Rule-Base-Name ] [ Called-Station-ID ] [ Bearer-Identifier
] *[ AVP ]
[0049] "Charging-Rule-Definition" above indicates multiple dynamic
PCC rules to be installed; "Charging-Rule-Name" and
"Charging-Rule-Base-Name" indicate multiple predefined PCC rules to
be activated; and "Called-Station-ID" indicates the PDN
corresponding to such rules.
[0050] It should be noted that in addition to the PCC rules, other
AVP parameters specific to the PDN may be set in a similar way. For
example, the APN-AMBR parameter (indicating the maximum bandwidth
shared by all non-GBR bearers connected to the same PDN) may be set
in the following mode:
TABLE-US-00003 APN-AMBR ::= < AVP Header:xxxx > [
Max-Requested-Bandwidth-UL ] [ Max-Requested-Bandwidth-DL ] [
Called-Station-ID ] *[ AVP ]
[0051] "Max-Requested-Bandwidth-UL" and
"Max-Requested-Bandwidth-DL" above indicate the shared maximum
bandwidth information, and the "Called-Station-ID" indicates the
associated PDN information.
[0052] Step 302: The V-PCRF enforces the corresponding policy
according to the received S9 session message.
[0053] The V-PCRF searches for the corresponding IP-CAN session
and/or gateway control session according to the PDN information and
IP address information carried in the PCC rules, and sends the PCC
rules to the corresponding IP-CAN session (P-GW). If a gateway
control session is associated, the V-PCRF extracts QoS rules from
the PCC rules and sends QoS rules to the corresponding gateway
control session (BBERF).
[0054] Likewise, after receiving PDN-specific information, the
V-PCRF sends the information to the corresponding IP-CAN session or
gateway control session.
[0055] The following embodiments expound the mode of implementing
the foregoing method in different scenarios.
Embodiment 1
[0056] FIG. 4 shows a roaming scenario of 3GPP access, where a P-GW
is located in a visited network, an S8 session is based on a PMIP
protocol, a BBERF is located in an S-GW, a PCEF is located in the
P-GW, and an S9 session is already created between the VPCRF and
the HPCRF. The user initiates creation of a connection to PDN2. The
HPCRF delivers the PCC rules to the VPCRF through the S9 session,
and the session message carries PDN information. The VPCRF sends
the received PCC rules to the PCEF (P-GW), and extracts the QoS
rules from the PCC rules and sends the QoS rules to the BBERF
(S-GW). The detailed steps are as follows:
[0057] 1. The user has created a gateway control session, an IP-CAN
session and an S9 session which correspond to PDN1.
[0058] 2. The user initiates creation of a connection to PDN2.
First, the user triggers the BBERF (SGW) to initiate creation of a
gateway control session. After receiving the message for creating
the gateway control session, the VPCRF determines that the PDN
connection is a Local Breakout scenario, and therefore, conceals
the gateway control session (without sending a session update
message to the HPCRF), and returns a response for creating the
gateway control session to the BBERF directly.
[0059] 3. The PCEF sends an IP-CAN session instruction message to
the VPCRF as an instruction of creating an IP-CAN session, and
requests the PCC rules from the VPCRF.
[0060] 4. The VPCRF sends an S9 session update message that carries
IP-CAN session information, PDN2 information, and the user IPv4
address corresponding to PDN2.
[0061] 5. According to the IP-CAN session information, gateway
control session information, user subscription information, and
policies defined by the operator, the HPCRF formulates PCC rules
and sends the rules to the VPCRF through an S9 session update
response. The rules include the PDN information associated with the
PCC rules.
[0062] In practice, the Charging-Rule-Definition may be extended to
carry PDN2 information:
TABLE-US-00004 Charging-Rule-Definition ::= < AVP Header: 1003
> { Charging-Rule-Name } [ Called-Station-ID ] [
Service-Identifier ] [ Rating-Group ] *[ Flow-Description ] [
Flow-Status ] [ QoS-Information ] [ Reporting-Level ] [ Online ] [
Offline ] [ Metering-Method ] [ Precedence ] [
AF-Charging-Identifier ] *[ Flows ] *[ AVP ]
[0063] Alternatively, "Charging-Rule-Install" is extended to
indicate that all installed rules are specific to PDN2:
TABLE-US-00005 Charging-Rule-Install ::= < AVP Header: 1001 >
*[ Charging-Rule-Definition ] *[ Charging-Rule-Name ] *[
Charging-Rule-Base-Name ] [ Called-Station-ID ] [ Bearer-Identifier
] *[ AVP ]
[0064] Optionally, this message may carry rules specific to
PDN1.
[0065] 6. The VPCRF sends an IP-CAN session response message to the
P-GW connected to PDN2 according to the PDN information in the PCC
rules.
[0066] 7. The VPCRF extracts QoS rules from the PCC rules, and
sends the QoS rules to the S-GW through the newly created gateway
control session.
[0067] 8. If the S9 message sent by the HPCRF carries the PCC rules
specific to PDN1, the VPCRF sends the PCC rules to P-GW1 connected
to PDN1.
[0068] 9. If the S9 message sent by the HPCRF carries the PCC rules
specific to PDN1, the VPCRF sends the extracted QoS rules to the
S-GW through the previously created gateway control session.
[0069] Step 8 and step 9 above are optional.
Embodiment 2
[0070] FIG. 5 shows a CMIP roaming scenario of trusted non-3GPP
access. The UE communicates with the P-GW through a Dual Stack
Mobile IP (DSMIP) protocol, a BBERF is located in an A-GW (the A-GW
is located in the visited network), a PCEF is located in the P-GW
(the P-GW is located in the home network), and an S9 session is
already created between the VPCRF and the HPCRF. The user initiates
creation of a connection to PDN2. The HPCRF delivers the PCC rules
to the VPCRF through the S9 session, and the session message
carries PDN information. The VPCRF sends the received PCC rules to
the PCEF (P-GW). Through the S9 session, the HPCRF delivers the QoS
rules to the BBERF. The session carries tunnel information (based
on the prior art). The BBERF distinguishes the PDN corresponding to
the QoS rules according to the tunnel information. The detailed
steps are as follows:
[0071] 1. The user has created a gateway control session, an IP-CAN
session and an S9 session which corresponds to PDN1.
[0072] 2. The user initiates creation of a connection to PDN2. In a
CMIP scenario, one gateway control session of the same user is
associated with multiple IP-CAN sessions. Therefore, it not
necessary to create a second gateway control session. The PCEF
sends an IP-CAN session instruction message to the VPCRF as an
instruction of creating an IP-CAN session, and requests the PCC
rules from the VPCRF.
[0073] 3. The VPCRF sends an S9 session update message that carries
IP-CAN session information, PDN2 information, and the user
IPv4/IPv6 address corresponding to PDN2.
[0074] 4. According to the IP-CAN session information, gateway
control session information, user subscription information, and
policies defined by the operator, the HPCRF formulates PCC rules
and sends the rules to the VPCRF through an S9 session update
response. The PCC rules carry PDN2 information. The detailed
implementation mode is the same as that of the first
embodiment.
[0075] 5. The VPCRF sends an IP-CAN session response message that
carries PCC rules to the P-GW.
[0076] 6. The HPCRF delivers the QoS rules to the VPCRF through an
S9 interface. The VPCRF forwards the QoS rules to the BBERF. The
QoS rules carry a tunnel ID so that the BBERF can distinguish the
QoS rules of different PDNs.
Embodiment 3
[0077] FIG. 6 shows a roaming scenario of 3GPP access, where a P-GW
connected to PDN2 is located in a visited network, an S8 session is
based on a PMIP protocol, a BBERF is located in an S-GW, a PCEF is
located in the P-GW, and an S9 session is already created between
the VPCRF and the HPCRF. The user initiates creation of a
connection to PDN2. The HPCRF delivers the QoS rules to the VPCRF
through the S9 session, and the session message carries PDN
information. The VPCRF sends the received QoS rules to the BBERF
(S-GW). The detailed steps are as follows:
[0078] 1. The user has created a gateway control session, an IP-CAN
session and an S9 session which correspond to PDN1.
[0079] 2. The user initiates creation of a connection to PDN2, and
triggers the BBERF (SGW) to initiate creation of a gateway control
session first.
[0080] 3. After receiving the message for creating the gateway
control session, the VPCRF determines that the PDN is connected to
the home P-GW, and sends an S9 session update message (Credit
Control Request (CCR)) that carries PDN2 information to the
HPCRF.
[0081] 4. According to the gateway control session information,
user subscription information, and policies defined by the
operator, the HPCRF formulates QoS rules and sends the rules to the
VPCRF through an S9 session update response (Credit Control Answer
(CCA)). The rules include the PDN information associated with the
QoS rules.
[0082] In practice, the QoS-Rule-Definition may be extended to
carry PDN2 information:
TABLE-US-00006 QoS-Rule-Definition ::= < AVP Header: xxxx >
{QoS -Rule-Name } [ Called-Station-ID ] *[ Flow-Description ] [
QoS-Information ] [ Precedence ] * [ AVP ]
[0083] Alternatively, "QoS-Rule-Install" is extended to indicate
that all installed QoS rules are specific to PDN2:
TABLE-US-00007 QoS-Rule-Install ::= < AVP Header: xxxx > *[
QoS-Rule-Definition ] [ Called-Station-ID ] *[ AVP ]
[0084] 5. After receiving the message, the VPCRF returns the QoS
rules to the corresponding gateway control session according to the
PDN information carried in the message.
[0085] 6. The BBERF initiates a PMIP binding process to the home
PCEF.
[0086] Step 6 and step 2 may occur simultaneously.
[0087] 7. The PCEF sends an IP-CAN session instruction message
(CCR) to the HPCRF as an instruction of creating an IP-CAN session,
and requests the PCC rules from the HPCRF.
[0088] 8. According to the IP-CAN session information, gateway
control session information, user subscription information, and
policies defined by the operator, the HPCRF formulates PCC rules
and sends the rules to the PCEF through an IP-CAN session creation
response (CCA).
[0089] 9. If the HPCRF needs to install new QoS rules or modify
existing QoS rules according to the IP-CAN session information,
ongoing service information, user subscription information, and
policies defined by the operator, the HPCRF sends an S9 session
update message (Re-Auth Request (RAR)) that carries the new QoS
rules or modified QoS rules to the VPCRF. The rules carry PDN
information. The details are given in step 4.
[0090] 10. If the S9 message sent by the HPCRF carries the QoS
rules specific to PDN2, the VPCRF sends the QoS rules to the BBERF
through the newly created gateway control session.
Embodiment 4
[0091] FIG. 7 shows a roaming scenario of 3GPP access, where the
P-GW connected to PDN2 is located in the home network. The S8
session is based on a GTP protocol, the PCEF is located in the
P-GW, and the S9 session between the VPCRF and the HPCRF is already
created. The user initiates creation of a connection to PDN2. The
HPCRF delivers the PCC rules to the VPCRF through the S9 session,
and the session message carries PDN information. The VPCRF sends
the received PCC rules to the PCEF (P-GW).
[0092] 1. The user has created an IP-CAN session and an S9 session
which correspond to PDN1.
[0093] 2. The user initiates creation of a connection to PDN2, and
triggers the PCEF (P-GW) to initiate creation of an IP-CAN session
first.
[0094] The first IP-CAN session and the second IP-CAN session in
this embodiment are created by the same P-GW or by different
P-GWs.
[0095] 3. The VPCRF sends an S9 session update message that carries
IP-CAN session information, PDN2 information, and the user
IPv4/IPv6 address corresponding to PDN2.
[0096] 4. According to the IP-CAN session information, user
subscription information, and policies defined by the operator, the
HPCRF formulates PCC rules and sends the rules to the VPCRF through
an S9 session update response. The PCC rules carry PDN2
information. The detailed implementation mode is the same as that
of the first embodiment.
[0097] 5. The VPCRF sends an IP-CAN session creation response
message that carries PCC rules to the PCEF.
[0098] 6. The PCEF detects occurrence of certain events (such as
the change of an access technology, or change of a user location),
and requests new PCC rules from the VPCRF. The request (CCR)
carries a trigger event and is sent on the IP-CAN session
corresponding to PDN2.
[0099] 7. The VPCRF initiates session update. The message carries
the trigger event.
[0100] 8. According to the trigger event, the HPCRF modifies the
existing PCC rules, and sends the modified PCC rules to the VPCRF
through an S9 session update response. The PCC rules include PDN
information. The detailed implementation mode is the same as that
of the first embodiment. Meanwhile, the HPCRF modifies the maximum
bandwidth (APN-AMBR) parameter shared by all non-GBR bearers under
each PDN.
[0101] In practice, the CCA message may carry multiple APN-AMBR
parameters:
TABLE-US-00008 <CC-Answer> ::= < Diameter Header: 272, PXY
> < Session-Id > { Auth-Application-Id } { Origin-Host } {
Origin-Realm } *[ APN-AMBR ] * indicates multiple parameters Other
AVPs are omitted
[0102] Each APN-AMBR is defined as:
TABLE-US-00009 APN-AMBR ::= < AVP Header:xxxx > [
Max-Requested-Bandwidth-UL ] [ Max-Requested-Bandwidth-DL ] [
Called-Station-ID ] *[ AVP ]
[0103] The Called-Station-ID above indicates the associated PDN
information. In this way, one message may carry multiple APN-AMBR
parameters, and each parameter is associated with a PDN (such as
PDN 1, 2 or 3).
[0104] Because a lot of information needs to be associated with the
PDN, this embodiment takes the APN-AMBR parameter as an example,
and other parameters can be handled in the same way.
[0105] 9. The VPCRF returns a PCC rule response message to the
PCEF. If the response message returned by the HPCRF includes PCC
rules specific to PDN2, the modified PCC rules are carried in this
response message (CCA) directly.
[0106] 10. If the response message returned by the HPCRF includes
PCC rules specific to PDN1, the VPCRF delivers the modified PCC
rules to the PCEF through an IP-CAN session specific to PDN1 (RAR
message).
Embodiment 5
[0107] In a multi-PDN scenario, when the VPCRF notifies the HPCRF
to release an IP-CAN session and/or a gateway control session
corresponding to a PDN, or when the HPCRF notifies the VPCRF to
release an IP-CAN session and/or a gateway control session
corresponding to a PDN, an operation of updating the S9 session
needs to be initiated, and the S9 session message needs to carry
PDN information and the IPv4 and/or IPv6 address corresponding to
the PDN.
[0108] (1) For S9 session update initiated by the VPCRF, the VPCRF
may use a CCR command which instructs the HPCRF to release the
IP-CAN and/or gateway control session corresponding to a PDN. In
practice, the existing CCR may be extended. For example, an
extended CCR message is:
TABLE-US-00010 <CC-Request> ::= < Diameter Header: 272,
REQ, PXY > < Session-Id > { Auth-Application-Id } {
Origin-Host } { Origin-Realm } { Destination-Realm } {
CC-Request-Type } { CC-Request-Number } [ Destination-Host ] [
Origin-State-Id ] [ Framed-IP-Address ] [ Framed-IPv6-Prefix ] [
Called-Station-ID ] [PDN-CONNECT-RELEASE] Other AVPs are
omitted
[0109] In the message above, "Called-Station-ID" represents a PDN,
"Framed-IP-Address" and "Framed-IPv6-Prefix" represent the IPv4 and
IPv6 addresses corresponding to the PDN; and "PDN-CONNECT-RELEASE"
is a newly added information element which is an instruction of
releasing a PDN connection.
[0110] "Called-Station-ID", "Framed-IP-Address", and
"Framed-IPv6-Prefix" are existing information elements.
[0111] (2) For S9 session update initiated by the HPCRF, the HPCRF
may use an RAR command which instructs the VPCRF to release the
IP-CAN and/or gateway control session corresponding to a PDN. In
practice, the existing RAR may be extended. For example, an
extended RAR message is:
TABLE-US-00011 <RA-Request> ::= < Diameter Header: 258,
REQ, PXY > < Session-Id > { Auth-Application-Id } {
Origin-Host } { Origin-Realm } { Destination-Realm } {
Destination-Host } { Re-Auth-Request-Type } [ Origin-State-Id ]
[PDN-CONNECT-RELEASE] [ Called-Station-ID ] [ Framed-IP-Address ] [
Framed-IPv6-Prefix ] Other AVPs are omitted
[0112] In the message above, "Called-Station-ID" represents a PDN,
"Framed-IP-Address" and "Framed-IPv6-Prefix" represent the IPv4 and
IPv6 addresses corresponding to the PDN; and "PDN-CONNECT-RELEASE"
is an instruction of releasing a PDN connection.
[0113] Such information elements are newly added.
[0114] If the VPCRF receives an S9 session update message from the
HPCRF, or the HPCRF receives an S9 session update message from the
VPCRF, at the time of releasing the IP-CAN session and/or a gateway
control session corresponding to a PDN, the VPCRF/HPCRF finds the
corresponding IP-CAN session and/or gateway control session
according to the PDN information and IP address in the message, and
initiates an operation of releasing the IP-CAN session and/or
gateway control session.
[0115] FIG. 8 shows a roaming scenario of 3GPP access, where an S8
session is based on a PMIP protocol, a BBERF is located in an S-GW,
a PCEF is located in the P-GW, and an S9 session is already created
between the VPCRF and the HPCRF. The user has three IP-CAN sessions
and three gateway control sessions, which correspond to PDN1, PDN2,
and PDN3 respectively. As triggered by internal or external
conditions, the HPCRF needs to initiate release of the gateway
control session and IP-CAN session corresponding to PDN3, and
therefore, the S9 session update message carries PDN information
and the corresponding IP address information and release
instruction. The detailed steps are as follows:
[0116] 1. The user has created three IP-CAN sessions and three
gateway control sessions, which correspond to PDN1, PDN2, and PDN3
respectively.
[0117] 2. As triggered by internal or external conditions, the
HPCRF needs to initiate release of the gateway control session and
IP-CAN session corresponding to PDN3, and therefore, the S9 session
update message (such as RAR) carries PDN3 and a release
instruction, and optionally, carries IP address information.
[0118] 3. The VPCRF answers the S9 session update message of the
HPCRF.
[0119] 4. The VPCRF initiates release of the gateway control
session corresponding to PDN3.
[0120] 5. The BBERF (S-GW) makes an answer to the request for
releasing the gateway control session.
[0121] The gateway control session is applicable only to the S8
interface based on PMIP. If the S8 interface is based on GTP, no
gateway control session exists.
[0122] 6. The VPCRF initiates release of the IP-CAN session
corresponding to PDN3.
[0123] 7. The PCEF (P-GW) makes an answer to release of the IP-CAN
session.
[0124] Note:
[0125] (1) The IP-CAN session exists only if the PCEF is located in
the visited network; and
[0126] (2) It is possible that the VPCRF does not answer the HPCRF
in step 3 until step 7 is completed.
Embodiment 6
[0127] In the existing Diameter protocol, a concept of sub-session
(CC-Sub-Session-Id) exists. In an S9 session, if each IP-CAN
session or gateway control session is managed as a sub-session, the
creation of each IP-CAN session and/or gateway control session
corresponds to creation of the S9 sub-session; and the deletion of
each sub-session corresponds to deletion of the IP-CAN session
and/or gateway control session. The message of each sub-session may
carry PCC or QoS rules. The rules are specific to this sub-session
(namely, the corresponding IP-CAN session and/or gateway control
session). According to the analysis above, the use of sub-sessions
solves the problems involved in the S9 interface which uses one
session.
[0128] However, the existing Diameter protocol does not specify how
to modify multiple sub-sessions through one message. That is, each
message is specific to the whole session, or specific to a single
sub-session. No mechanism is available for modifying a part of the
sub-sessions. In the PCC, information or rules for modifying a part
of sub-sessions (the corresponding IP-CAN session and/or gateway
control session) exist.
[0129] Therefore, a possible implementation mode is: The PCC rules
specify the sub-session IDs corresponding to the PCC rules. In this
way, one message (the session ID is a main session) includes
multiple PCC rules corresponding to different sub-sessions. The
rules are extended in the following way:
TABLE-US-00012 Charging-Rule-Definition ::= < AVP Header: 1003
> { Charging-Rule-Name } [CC -Sub-Session-Id] [
Service-Identifier ] [ Rating-Group ] *[ Flow-Description ] [
Flow-Status ] [ QoS-Information ] [ Reporting-Level ] [ Online ] [
Offline ] [ Metering-Method ] [ Precedence ] [
AF-Charging-Identifier ] *[ Flows ] *[ AVP ] or
Charging-Rule-Install ::= < AVP Header: 1001 > *[
Charging-Rule-Definition ] *[ Charging-Rule-Name ] *[
Charging-Rule-Base-Name ] [CC-Sub-Session-Id ] [ Bearer-Identifier
] *[ AVP ]
[0130] In the rules above, "CC-Sub-Session-Id" is the sub-session
ID corresponding to the PCC rules.
[0131] A similar mechanism may be applied to the PDN information.
For example, the APN-AMBR parameter may be:
TABLE-US-00013 APN-AMBR ::= < AVP Header:xxxx > [
Max-Requested-Bandwidth-UL ] [ Max-Requested-Bandwidth-DL ]
[CC-Sub-Session-Id ] *[ AVP ]
[0132] In the parameter above, "Max-Requested-Bandwidth-UL" and
"Max-Requested-Bandwidth-DL" above indicate the shared maximum
bandwidth information, and "CC-Sub-Session-Id" indicates the
associated sub-session information.
[0133] FIG. 9 shows a roaming scenario of 3GPP access, where an S8
session is based on a PMIP protocol, a BBERF is located in an S-GW,
a PCEF is located in the P-GW, and all P-GWs are located in the
visited network. An S9 session is already created between the VPCRF
and the HPCRF. The user has three IP-CAN sessions and three gateway
control sessions, which correspond to three S9 sub-sessions
S9.sub.--1, S9.sub.--2, and S9.sub.--3 respectively. Due to the
change of the access technology, the HPCRF needs to modify the PCC
rules corresponding to sub-sessions 1 and 2. Therefore, the S9
session update message carries the S9 session ID and the PCC rules
of the corresponding sub-sessions 1 and 2. Meanwhile, the APN-AMBR
parameter specific to the sub-session (namely, the corresponding
IP-CAN session and/or gateway control session) is modified. The
detailed steps are as follows:
[0134] 1. The user has created three IP-CAN sessions and three
gateway control sessions, which correspond to three S9 sub-sessions
S9.sub.--1, S9.sub.--2, and S9.sub.--3 respectively.
[0135] 2. Upon the change of the access technology, or as triggered
by other conditions, the BBERF (S-GW) initiates gateway control
session update. Due to existence of the three gateway control
sessions, the BBERF (S-GW) may initiate update of the three gateway
control sessions simultaneously, or initiate update of only one of
the three gateway control sessions.
[0136] 3. The VPCRF sends a request for updating the S9 session.
The request carries a trigger event and an S9 session ID, but
carries no S9 sub-session ID, indicating that the events are
specific to all sub-sessions.
[0137] 4. According to the trigger event, the HPCRF modifies the
corresponding PCC rules. The HPCRF sends an S9 session update
message as a response to the VPCRF. The PCC rules include PDN
information. Specifically, the rules may be derived by extending
Charging-Rule-Definition and may carry sub-session information; or
may be derived by extending Charging-Rule-Install to indicate that
all installed rules are specific to a sub-session.
[0138] Meanwhile, the HPCRF modifies the APN-AMBR parameter shared
by all non-GBR bearers under each PDN. For that purpose, the CCA
message may carry multiple APN-AMBR parameters:
TABLE-US-00014 <CC-Answer> ::= < Diameter Header: 272, PXY
> < Session-Id > carries only the main session ID,
indicating that the message is specific to the main session {
Auth-Application-Id } { Origin-Host } { Origin-Realm } *[ APN-AMBR
] * indicates multiple parameters Other AVPs are omitted
[0139] Each APN-AMBR is defined as:
TABLE-US-00015 APN-AMBR ::= < AVP Header:xxxx > [
Max-Requested-Bandwidth-UL ] [ Max-Requested-Bandwidth-DL ]
[CC-Sub-Session-Id] *[ AVP ]
[0140] "CC-Sub-Session-Id" above indicates the associated
sub-session information. In this way, one message may carry
multiple APN-AMBR parameters, and each parameter is associated with
a sub-session (such as sub-session 1 or 2).
[0141] 5. The VPCRF sends a gateway control session response (CCA)
to the BBERF (S-GW). If the rules returned by the HPCRF include the
corresponding sub-session information, the rules are sent through
the corresponding message to the BBERF directly.
[0142] 6. If the BBERF requests to update only one gateway control
session, but the rules returned by the HPCRF include the rules
specific to other sub-sessions, the VPCRF initiates the rule update
process in other gateway control sessions actively (through an RAR
message).
[0143] 7. Because the modified APN-AMBR parameters returned by the
HPCRF include the parameters specific to sub-session 1, the
modified APN-AMBR parameters still need to be sent to the
corresponding PCEF1.
[0144] 8. Because the modified APN-AMBR parameters returned by the
HPCRF include the parameters specific to sub-session 2, the
modified APN-AMBR parameters still need to be sent to the
corresponding PCEF2.
[0145] In the embodiments above, an S9 session message carries PDN
information, and therefore, in a multi-PDN scenario, the S9 session
can distinguish and handle creation, modification and deletion of
the IP-CAN session and the gateway control session, and the V-PCRF
can understand the information delivered by the H-PCRF, and send
the information to the correct PCEF or BBERF for enforcement;
moreover, the V-PCRF can report the PDN connection release
information to the H-PCRF, and the H-PCRF releases the
corresponding PDN connection, thus avoiding ineffective occupation
of resources and ensuring correct policies.
[0146] After reading the foregoing embodiments, those skilled in
the art are clearly aware that the embodiments of the present
disclosure may be implemented through hardware, or, preferably,
through software in addition to a necessary universal hardware
platform in most circumstances. Therefore, the contributions made
by the present disclosure to the prior art may be partially or
completely embodied as a software product. The software product may
be stored in a storage medium such as a Read Only Memory/Random
Access Memory (ROM/RAM), a magnetic disk, or a Compact Disk-Read
Only Memory (CD-ROM), and incorporates several instructions for
instructing a computer device (for example, a personal computer, a
server, or a network device) to execute the method specified in
each embodiment of the present disclosure or a part of an
embodiment.
[0147] It is apparent to persons skilled in the art that various
modifications and variations can be made to the present disclosure
without departing from the scope of the disclosure. The disclosure
shall cover the modifications and variations provided that they
fall within the scope of protection defined by the appended claims
or their equivalents.
* * * * *