U.S. patent application number 12/615528 was filed with the patent office on 2010-06-10 for method and system for supporting sip session policy using existing authorization architecture and protocols.
This patent application is currently assigned to RESEARCH IN MOTION LIMITED. Invention is credited to Andrew Allen, Adrian Buckley, Michael Montemurro.
Application Number | 20100142517 12/615528 |
Document ID | / |
Family ID | 42153638 |
Filed Date | 2010-06-10 |
United States Patent
Application |
20100142517 |
Kind Code |
A1 |
Montemurro; Michael ; et
al. |
June 10, 2010 |
Method and System for Supporting SIP Session Policy Using Existing
Authorization Architecture and Protocols
Abstract
A method for sending a session policy request to a network
component is provided. The method comprises a user agent sending
the session policy request to the network component using a lower
layer protocol. The lower layer protocol is at least one of
Extensible Authentication Protocol (EAP), Point to Point Protocol
(PPP), and General Packet Radio Service (GPRS) Activate Packet Data
Protocol (PDP) context.
Inventors: |
Montemurro; Michael;
(Mississauga, CA) ; Allen; Andrew; (Mundelein,
IL) ; Buckley; Adrian; (Tracy, CA) |
Correspondence
Address: |
Research in Motion Corp./CR;Attn: J. Robert Brown
5601 Granite Parkway, Suite 750
Plano
TX
75024
US
|
Assignee: |
RESEARCH IN MOTION LIMITED
Waterloo
CA
|
Family ID: |
42153638 |
Appl. No.: |
12/615528 |
Filed: |
November 10, 2009 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
61112873 |
Nov 10, 2008 |
|
|
|
Current U.S.
Class: |
370/352 ;
370/401 |
Current CPC
Class: |
H04W 12/069 20210101;
H04L 69/24 20130101; H04L 63/20 20130101; H04W 76/10 20180201; H04W
80/04 20130101; H04L 67/141 20130101; H04L 65/1006 20130101; H04L
65/1016 20130101; H04L 45/00 20130101; H04W 76/12 20180201; H04L
63/16 20130101; H04L 63/205 20130101; H04W 76/20 20180201; H04L
65/1073 20130101 |
Class at
Publication: |
370/352 ;
370/401 |
International
Class: |
H04L 12/66 20060101
H04L012/66; H04L 12/56 20060101 H04L012/56 |
Claims
1. A method for sending a session policy request to a network
component, comprising: a user agent sending the session policy
request to the network component using a lower layer protocol,
wherein the lower layer protocol is at least one of: Extensible
Authentication Protocol (EAP), Point to Point Protocol (PPP), and
General Packet Radio Service (GPRS) Activate Packet Data Protocol
(PDP) context.
2. The method of claim 1, wherein the network component is at least
one of: a policy server; an authentication server; a policy control
and charging rules function; a policy control and enforcement
function; a network access server; a gateway; and a router.
3. The method of claim 1, wherein the session policy request passes
through an intermediate component between the user agent and the
network component, and wherein the intermediate component is at
least one of: a gateway; an access point; and a network access
server.
4. The method of claim 3, wherein the user agent connects to the
intermediate component via a connectivity access network comprising
at least one of: General Packet Radio Service (GPRS); Global System
for Mobile Communications (GSM); Enhanced Data rates for GSM
Evolution (EDGE); UMTS (Universal Mobile Telecommunications System)
Terrestrial Radio Access Network (UTRAN); Evolved UTRAN (E-UTRAN);
Third Generation Partnership Project (3GPP) UTRAN; 3GPP2 Code
Division Multiple Access (CDMA); 802.11 Wireless Local Area Network
(WLAN); 802.16 Wireless Metropolitan Area Network (WMAN); 802.20
Wireless Wide Area Network (WWAN); 802.22 Wireless Regional Area
Network (WRAN); Data Over Cable Service Interface Specification
(DOCSIS); and Telecoms and Internet converged Services and
Protocols for Advanced Networks (TISPAN), including the xDSL family
of protocols.
5. The method of claim 3, wherein the at least one lower layer
protocol is used for transporting the session policy request
between the user agent and the intermediate component, and at least
one lower layer protocol frame transports the session policy
request between the intermediate component and the network
component using at least one of: a DIAMETER protocol; and a RADIUS
protocol.
6. The method of claim 1, wherein a type-length-value structure
capability in the at least one lower layer protocol is used to
express the session policy request.
7. The method of claim 1, wherein the network component provides a
policy document to the user agent in response to the session policy
request, and wherein the policy document is converted to binary to
decrease its size.
8. The method of claim 1, wherein the user agent contacts the
network component using a Uniform Resource Identifier (URI) in a
Session Initiation Protocol (SIP) message received by the user
agent.
9. The method of claim 8, wherein the URI is in a Policy-Contact
header of the SIP message.
10. The method of claim 8, wherein the user agent contacts a
plurality of network components via a single session policy request
sent to a single network component, the single network component
contacting the remainder of the network components, aggregating
policy information from the remainder of the network components,
and providing the aggregated policy information to the user
agent.
11. A user agent for a session policy request to a network
component, comprising: a processor configured to send the session
policy request to the network component using a lower layer
protocol, wherein the lower layer protocol is at least one of:
Extensible Authentication Protocol (EAP), Point to Point Protocol
(PPP), and General Packet Radio Service (GPRS) Activate Packet Data
Protocol (PDP) context.
12. The user agent of claim 11, wherein the network component is at
least one of: a policy server; an authentication server; a policy
control and charging rules function; a policy control and
enforcement function; a network access server; a gateway; and a
router.
13. The user agent of claim 11, wherein the session policy request
passes through an intermediate component between the user agent and
the network component, and wherein the intermediate component is at
least one of: a gateway; an access point; and a network access
server.
14. The user agent of claim 13, wherein the at least one lower
layer protocol is used for transporting the session policy request
between the user agent and the intermediate component, and at least
one lower layer protocol frame transports the session policy
request between the intermediate component and the network
component using at least one of: a DIAMETER protocol; and a RADIUS
protocol.
15. The user agent of claim 13, wherein the user agent connects to
the intermediate component via a connectivity access network
comprising at least one of: General Packet Radio Service (GPRS);
Global System for Mobile Communications (GSM); Enhanced Data rates
for GSM Evolution (EDGE); UMTS (Universal Mobile Telecommunications
System) Terrestrial Radio Access Network (UTRAN); Evolved UTRAN
(E-UTRAN); Third Generation Partnership Project (3GPP) UTRAN; 3GPP2
Code Division Multiple Access (CDMA); 802.11 Wireless Local Area
Network (WLAN); 802.16 Wireless Metropolitan Area Network (WMAN);
802.20 Wireless Wide Area Network (WWAN); 802.22 Wireless Regional
Area Network (WRAN); Data Over Cable Service Interface
Specification (DOCSIS); and Telecoms and Internet converged
Services and Protocols for Advanced Networks (TISPAN), including
the xDSL family of protocols.
16. The user agent of claim 11, wherein a type-length-value
structure capability in the at least one lower layer protocol is
used to express the session policy request.
17. The user agent of claim 11, wherein the network component
provides a policy document to the user agent in response to the
session policy request, and wherein the policy document is
converted to binary to decrease its size.
18. The user agent of claim 11, wherein the user agent contacts the
network component using a Uniform Resource Identifier (URI) in a
Session Initiation Protocol (SIP) message received by the user
agent.
19. The user agent of claim 18, wherein the URI is in a
Policy-Contact header of the SIP message.
20. The user agent of claim 18, wherein the user agent contacts a
plurality of network components via a single session policy request
sent to a single network component, the single network component
contacting the remainder of the network components, aggregating
policy information from the remainder of the network components,
and providing the aggregated policy information to the user
agent.
21. A network component for providing session policy, the network
component comprising: an authentication component configured to
receive a session policy request sent a lower layer protocol,
wherein the lower layer protocol is at least one of: Extensible
Authentication Protocol (EAP), Point to Point Protocol (PPP), and
General Packet Radio Service (GPRS) Activate Packet Data Protocol
(PDP) context.
22. The network component of claim 21, wherein the authentication
component is at least one of: a policy server; an authentication
server; a policy control and charging rules function; a policy
control and enforcement function; a network access server; a
gateway; and a router.
23. The network component of claim 21, wherein the session policy
request passes from a user agent through an intermediate component
to the network component, and wherein the intermediate component is
at least one of: a gateway; an access point; and a network access
server.
24. The network component of claim 23, wherein the at least one
lower layer protocol is used for transporting the session policy
request between the user agent and the intermediate component, and
at least one lower layer protocol frame transports the session
policy request between the intermediate component and the network
component using at least one of: a DIAMETER protocol; and a RADIUS
protocol.
25. The network component of claim 23 wherein the user agent
connects to the intermediate component via a connectivity access
network comprising at least one of: General Packet Radio Service
(GPRS); Global System for Mobile Communications (GSM); Enhanced
Data rates for GSM Evolution (EDGE); UMTS (Universal Mobile
Telecommunications System) Terrestrial Radio Access Network
(UTRAN); Evolved UTRAN (E-UTRAN); Third Generation Partnership
Project (3GPP) UTRAN; 3GPP2 Code Division Multiple Access (CDMA);
802.11 Wireless Local Area Network (WLAN); 802.16 Wireless
Metropolitan Area Network (WMAN); 802.20 Wireless Wide Area Network
(WWAN); 802.22 Wireless Regional Area Network (WRAN); Data Over
Cable Service Interface Specification (DOCSIS); and Telecoms and
Internet converged Services and Protocols for Advanced Networks
(TISPAN), including the xDSL family of protocols.
26. The network component of claim 21, wherein a type-length-value
structure capability in the at least one lower layer protocol is
used to express the session policy request.
27. The network component of claim 21, wherein the authentication
component provides a policy document to the user agent in response
to the session policy request, and wherein the policy document is
converted to binary to decrease its size.
28. The network component of claim 21, wherein the user agent
contacts the authentication component using a Uniform Resource
Identifier (URI) in a Session Initiation Protocol (SIP) message
received by the user agent.
29. The network component of claim 28, wherein the URI is in a
Policy-Contact header of the SIP message.
30. The network component of claim 28, wherein the user agent
contacts a plurality of authentication components via a single
session policy request sent to a single authentication component,
the single authentication component contacting the remainder of the
authentication components, aggregating policy information from the
remainder of the authentication components, and providing the
aggregated policy information to the user agent.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] The present application claims priority to U.S. provisional
patent application No. 61/112,873, filed Nov. 10, 2008, by Michael
Montemurro, et al, entitled "Method and System for Supporting SIP
Session Policy Using Existing Authorization" (34374-US-PRV
4214-12800), which is incorporated by reference herein as if
reproduced in its entirety.
BACKGROUND
[0002] The IP (Internet Protocol) Multimedia Subsystem (IMS) is a
standardized architecture for providing multimedia services and
voice-over-IP calls to both mobile and fixed user agents (UAs). The
Session Initiation Protocol (SIP) been standardized and governed
primarily by the Internet Engineering Task Force (IETF) as a
signaling protocol for creating, modifying, and terminating
IMS-based calls or sessions. As used herein, the terms "user agent"
and "UA" might in some cases refer to mobile devices such as mobile
telephones, personal digital assistants, handheld or laptop
computers, and similar devices that have telecommunications
capabilities. Such a UA might consist of a UA and its associated
removable memory module, such as but not limited to a Universal
Integrated Circuit Card (UICC) that includes a Subscriber Identity
Module (SIM) application, a Universal Subscriber Identity Module
(USIM) application, or a Removable User Identity Module (R-UIM)
application. Alternatively, such a UA might consist of the device
itself without such a module. In other cases, the term "UA" might
refer to devices that have similar capabilities but that are not
transportable, such as fixed line telephones, desktop computers,
set-top boxes, or network nodes. When a UA is a network node, the
network node could act on behalf of another function such as a UA
or a fixed line device and simulate or emulate the UA or fixed line
device. For example, for some UAs, the IMS SIP client that would
typically reside on the device actually resides in the network and
relays SIP message information to the device using optimized
protocols. In other words, some functions that were traditionally
carried out by a UA can be distributed in the form of a remote UA,
where the remote UA represents the UA in the network. The term "UA"
can also refer to any hardware or software component that can
terminate a communication session that could include, but is not
limited to, a SIP session. Also, the terms "user agent," "UA,"
"user equipment," "UE," and "node" might be used synonymously
herein.
BRIEF DESCRIPTION OF THE DRAWINGS
[0003] For a more complete understanding of this disclosure,
reference is now made to the following brief description, taken in
connection with the accompanying drawings and detailed description,
wherein like reference numerals represent like parts.
[0004] FIG. 1 is a flow diagram for establishment of a SIP session
according to the prior art.
[0005] FIG. 2 is a diagram of a policy architecture according to
the prior art.
[0006] FIG. 3 is an illustration of a policy and charging control
architecture according to the prior art.
[0007] FIG. 4 is an illustration of a telecommunications system
according to an embodiment of the disclosure.
[0008] FIG. 5 is an illustration of a protocol stack according to
an embodiment of the disclosure.
[0009] FIG. 6 is an illustration of an access network according to
an embodiment of the disclosure.
[0010] FIG. 7 is an illustration of another access network
according to an embodiment of the disclosure.
[0011] FIG. 8 is an illustration of another access network
according to an embodiment of the disclosure.
[0012] FIG. 9 is an illustration of another access network
according to an embodiment of the disclosure.
[0013] FIG. 10 is an illustration of another access network
according to an embodiment of the disclosure.
[0014] FIG. 11 is an illustration of another access network
according to an embodiment of the disclosure.
[0015] FIG. 12 is an illustration of another access network
according to an embodiment of the disclosure.
[0016] FIG. 13 is a diagram of a method for sending a session
policy request to a network component according to an embodiment of
the disclosure.
[0017] FIG. 14 is a diagram of a method for a user agent to access
a session policy in a network according to an alternative
embodiment of the disclosure.
[0018] FIG. 15 is an illustration of multiple interconnected Policy
Control and Charging Rules functions according to an embodiment of
the disclosure.
[0019] FIG. 16 is a diagram of a method for a user agent to access
a session policy in a network according to an alternative
embodiment of the disclosure.
[0020] FIG. 17 is a diagram of a method for a user agent to access
a session policy in a network according to an alternative
embodiment of the disclosure.
[0021] FIG. 18 illustrates a processor and related components
suitable for implementing the several embodiments of the present
disclosure.
DETAILED DESCRIPTION
[0022] It should be understood at the outset that although
illustrative implementations of one or more embodiments of the
present disclosure are provided below, the disclosed systems and/or
methods may be implemented using any number of techniques, whether
currently known or in existence. The disclosure should in no way be
limited to the illustrative implementations, drawings, and
techniques illustrated below, including the exemplary designs and
implementations illustrated and described herein, but may be
modified within the scope of the appended claims along with their
full scope of equivalents.
[0023] The SIP Request for Comments (RFC) 3261 is a signaling
protocol for creating, modifying, and terminating multimedia
sessions. A central element in SIP is the proxy server. Proxy
servers are intermediaries that are responsible for request
routing, rendezvous, authentication and authorization, mobility,
and other signaling services. However, proxies are divorced from
the actual sessions--audio, video, and session-mode messaging--that
SIP establishes. Details of the sessions are carried in the payload
of SIP messages and are usually described with the Session
Description Protocol (SDP) RFC 4566 and RFC 3264.
[0024] Experience has shown that there is a need for SIP
intermediaries to impact aspects of a session. Session parameters
are typically controlled through the enforcement of session
policies. For example, SIP can be used in a wireless network that
has limited resources for media traffic. During periods of high
activity, the wireless network provider could want to restrict the
amount of bandwidth available to each user. With session policies,
an intermediary in the wireless network can inform a UA about the
bandwidth it has available. This information enables the UA to make
an informed decision about the number of streams, the media types,
and the codecs it can successfully use in a session. Similarly, a
network provider can have a service level agreement with a user
that defines the set of media types the user can use. The network
can convey the current set of policies to user agents, enabling
them to set up sessions without inadvertently violating any of the
network policies.
[0025] In another example, a SIP UA is using a network which is
connected to the public Internet through a firewall or a network
border device. The network provider would like to tell the UA that
it needs to send its media streams to a specific IP address and
port on the firewall or border device to reach the public Internet.
Knowing this policy enables the UA to set up sessions across the
firewall or the network border. In contrast to other methods for
inserting a media intermediary, the use of session policies does
not require the inspection or modification of SIP message
bodies.
[0026] Domains often have the need to enforce the session policies
they have in place. For example, a domain might have a policy that
disallows the use of video and can have an enforcement mechanism
that drops all packets containing a video encoding. Unfortunately,
these enforcement mechanisms usually do not inform the user about
the policies they are enforcing. Instead, they silently keep the
user from doing anything against them. This can lead to a
malfunctioning of devices that is incomprehensible to the user.
With session policies, the user knows about the current network
policies and can set up policy-compliant sessions or simply connect
to a domain with less stringent policies. Thus, session policies
provide an important combination of consent coupled with
enforcement. That is, the user becomes aware of the policy and
needs to act on it, but the provider still retains the right to
enforce the policy.
[0027] The IETF is defining a session policy framework in
draft-sip-session-policy-framework-05 to enable the network to
convey the current set of policies to SIP UAs, enabling them to set
up sessions without inadvertently violating any of the network
policies.
[0028] Two types of session policies, session-specific policies and
session-independent policies, have been defined. Session-specific
policies are policies that are created for one particular session,
based on the description of the session. They enable a network
intermediary to examine the session description a UA is proposing
and to return a policy specifically for that session description.
For example, an intermediary could open pinholes in a
firewall/network address translation (NAT) for each media stream in
the proposed session description. It can then return a policy for
the session description that replaces the IP addresses and ports of
the UA with the ones opened in the firewall/NAT that are reachable
from external sources. Since session-specific policies are tailored
to a session, they only apply to the session they are created for.
Session-specific policies are created on a session-by-session basis
at the time the session is established.
[0029] Session-independent policies, on the other hand, are
policies that are created independently of a session and generally
apply to all SIP sessions set up by a UA. A session-independent
policy can, for example, be used to inform UAs about an existing
bandwidth limit or media type restrictions. Since these policies
are not based on a specific session description, they can be
created independently of an attempt to set up a session and only
need to be conveyed to the UA when it initializes (e.g., at the
time the device is powered on) and when policies are changed.
[0030] The mechanisms described below can be used for both
session-independent policies and session-specific policies. For
session-specific polices (i.e., policies provided in response to a
SIP request or SIP response), a PolicyOffer or PolicyAnswer
document might be returned to a UA. For session-independent
policies (i.e., policies provided to the UA prior to a session), a
Session Policy document might be returned.
[0031] In addition to media policies, the mechanisms defined herein
can be used to inform the UA to use a different IP address in the
SDP Offer or Answer, to navigate firewalls or NATs, or to route
media via a transcoder or other media relay.
[0032] The Third Generation Partnership Project (3GPP) has
standardized the IP Multimedia Subsystem (IMS) as a Next Generation
SIP/IP based network for multimedia services for mobile and
landline networks. The architecture for 3GPP IMS is specified in
3GPP Technical Specification (TS) 23.228. In 3GPP TS 23.228, the
functionality of IMS elements is specified, including the Serving
Call Session Control Function (S-CSCF) and the Proxy Call Session
Control Function (P-CSCF). The S-CSCF acts as both the SIP
Registrar and as a SIP Proxy as defined in RFC 3261. The P-CSCF
also acts as a SIP Proxy. The 3GPP IMS uses SIP for session
signaling and, as described above, the IMS network entities (P-CSCF
and S-CSCF) may need to impact aspects of a session (such as number
of streams, the media types, and the codecs).
[0033] 3GPP has defined the architecture for Policy and Charging
Control (PCC) that performs the necessary Authorization and
Accounting functions for UA access to IMS bearer resources. The PCC
architecture includes a policy server, the PCRF (Policy Control and
Charging Rules function), which, based on inputs from various
sources, determines which UAs are allowed bearer access based on
the attributes and characteristics of the session (such as the
number of streams, the media types, and the codecs). The PCRF
interfaces to the Subscription Profile Repository (SPR) for
subscription-based policies and to the Application Function (AF)
for application-specific inputs. When IMS is used with PCC, the AF
is a SIP proxy, the P-CSCF, that can influence the PCRF based on
the SIP Session Signaling. The PCRF interfaces to the Policy
Control Enforcement Function (PCEF) that provides gating and
filtering functions to ensure that the policy is enforced. The PCEF
is integrated with the Access Network specific gateway (e.g., GGSN,
PDG, PDSN, or CMTS). These entities might communicate using the
DIAMETER or RADIUS protocol and form part of the Authentication
Authorization Accounting (AAA) infrastructure. It should be
understood that a policy server as described herein is not limited
to the PCRF. Other embodiments are possible, such as a policy
server integrated with the P-CSCF.
[0034] Currently, 3GPP has defined in TS 24.229 a session policy
policing mechanism for IMS based on the SIP proxies sending a SIP
488 response if the original SIP INVITE request contains media
types or codecs that network policies do not allow. As specified in
RFC 3261 and 3GPP TS 24.229, the 488 response contains SDP
descriptions of the media types and codecs that would be allowed so
that the calling UA can retry the request with SDP that would be
allowed. However, this approach has the problem that, as the SIP
request traverses each domain, every domain may have its own set of
policies. It is quite possible in roaming situations that a single
SIP request can traverse four or more different IMS domains and
potentially have a SIP 488 response sent back by each domain.
Potentially, each proxy in each domain could have to reject the SIP
INVITE request with a SIP 488 response, resulting in the calling UA
having to send five (or even more) SIP INVITE requests (and receive
four or more SIP 488 responses) before the SIP INVITE request
reaches the called UA. This results in a severely delayed session
setup.
[0035] Also, this mechanism does not work for SIP INVITE requests
that do not contain SDP, which is allowed in RFC 3261, where an
initial SIP INVITE without SDP can be sent and the called UA can
then send back the SDP offer in the response, with the calling
party then returning the SDP answer in the ACK request. A response
cannot be rejected with a 488 response since a SIP response can
only be sent in response to a request. Therefore, 3GPP IMS has
restricted the use of these offerless SIP INVITE requests by
allowing them to come only from network servers (that are aware of
the policies) and from outside IMS networks where they may happen,
in which case, if the session is established with codecs contrary
to policies, it is immediately terminated with a BYE. This
situation is not satisfactory.
[0036] Additionally, the 3GPP PCC architecture depends on the
P-CSCF analyzing the SDP from the SIP signaling to provide input
into the PCRF for the authorization of bearer resources for the
session. For the called UA, the SDP answer sent in a response is
required by the P-CSCF in order to authorize the bearer resources
based on the media types and codecs accepted by the called UA. This
means that the called UA often needs to send a provisional (1xx)
response containing the SDP answer earlier than it would otherwise
have sent an answer. Since IMS uses the preconditions framework RFC
3312, this provisional response needs to be sent reliably. This can
require a further SIP PRACK request and 200OK response to be
exchanged as well, which results in a considerably delayed call
setup time due to the additional unnecessary SIP messages needing
to be exchanged end to end.
[0037] FIG. 1 is a flow diagram from
draft-sip-session-policy-framework-05 that illustrates the basic
IETF SIP architecture of the session policy framework with SIP
session establishment. At event 12, a first UA.sub.A 110.sub.A
sends a SIP INVITE message containing an SDP offer to a first
proxy.sub.A 120.sub.A. At event 14, the first proxy.sub.A 120.sub.A
sends a 488 message including a Policy-Contact header to the first
UA.sub.A 110.sub.A. The first UA.sub.A 110.sub.A then returns an
acknowledgement message to the first proxy.sub.A 120.sub.A. At
event 16, the first UA.sub.A 110.sub.A sends a PolicyChannel
message containing an InfoOffer to a first policy server.sub.A
130.sub.A. At event 18, the first policy server.sub.A 130.sub.A
sends a PolicyChannel message containing a PolicyOffer to the first
UA.sub.A 110.sub.A.
[0038] At event 20, the first UA.sub.A 110.sub.A sends an INVITE
message containing an SDP offer to a second UA.sub.B 110.sub.B via
the first proxy.sub.A 120.sub.A and a second proxy.sub.B 120.sub.B.
At event 22, the second UA.sub.B 110.sub.B sends a PolicyChannel
message containing an InfoOffer and an InfoAnswer to a second
policy server.sub.B 130.sub.B. At event 24, the second policy
server.sub.B 130.sub.B sends a PolicyChannel message containing a
PolicyOffer and a PolicyAnswer to the second UA.sub.B 110.sub.B. At
event 26, the second UA.sub.B 110.sub.B sends a SIP 200OK answer to
the first UA.sub.A 110.sub.A via the second proxy.sub.B 120.sub.B
and the first proxy.sub.A 120.sub.A. The first UA.sub.A 110.sub.A
then returns a SIP Acknowledgement (ACK) message to the second
UA.sub.B 110.sub.B. At event 28, the first UA.sub.A 110.sub.A sends
a PolicyChannel message containing an InfoAnswer to the first
proxy.sub.A 120.sub.A. At event 30, the first proxy.sub.A 120.sub.A
sends a PolicyChannel message containing a PolicyAnswer to the
first UA.sub.A 110.sub.A.
[0039] The following entities are typically needed for
session-specific policies: a UA, a proxy, a policy server, and
possibly a policy enforcement entity. A policy architecture for
these entities is illustrated in FIG. 2. The UA 110 communicates
with the proxy 120 via SIP signaling 125 and communicates with the
policy server 130 via a policy channel 135. Media 145 might be
exchanged between the UA 110 and a policy enforcement component
140.
[0040] The proxy 120 provides a rendezvous mechanism for UAs 110
and policy servers 130. It ensures that each UA 110 obtains the
Uniform Resource Identifier (URI) of the policy server 130 in its
domain and knows where to retrieve policies from. The proxy 120
conveys the policy server URI to the UAs 110 in case they have not
yet received it (e.g., in a previous call or through other means
such as configuration). The proxy 120 does not deliver the actual
policies to the UA 110. Instead, the proxy 120 provides the UA 110
with a URI or other identifier for the policy server 130 from which
the UA 110 can retrieve a policy document or other policy
information.
[0041] The policy server 130 is a separate logical entity that can
be physically co-located with the proxy 120. The role of the policy
server 130 is to deliver session policies to the UA 110. The policy
server 130 receives session information from the UA 110, uses this
information to determine the policies that apply to the session,
and returns these policies to the UA 110.
[0042] The Session Policies framework defines the SIP
Policy-Contact header (which can be included by the proxy 120 in
the SIP requests and responses) as the mechanism by which the UA
110 receives the URI of a policy server 130 from a proxy 120. That
is, the proxy 120 can add the URI of the policy server 130 to the
Policy-Contact header. The UA 110 uses this URI to contact the
policy server 130 and provides information (including Session
Descriptions (SDP)) about the current session to the policy server
130. The UA 110 then receives session policies from the policy
server 130 in response. The UA 110 can also receive policy updates
from the policy server 130 during the course of a session. The
communication exchange between the UA 110 and the policy server 130
is defined as the policy channel 135.
[0043] The current Session Policies framework defines a SIP-based
mechanism based only upon the SIP Events framework RFC 3265 and the
Event Package defined in draft-ietf-sipping-policy-package-05 to
deliver the session policy to the UA 110 using the policy channel
135 and currently defines only SIP and SIPS URIs as the URIs that
can be included by the proxy 120 in the SIP Policy-Contact header.
Full details of the Session Policies framework are defined in
draft-sip-session-policy-framework-05.
[0044] 3GPP has defined the Policy and Charging Control (PCC)
Architecture in TS 23.203 as shown in FIG. 3. In the figure, the
Policy and Charging Rules Function (PCRF) is the Policy Server. The
thick dashed lines show the reference points over which the Policy
Channel as defined in draft-sip-session-policy-framework-05 needs
to operate. The Subscription Profile Repository (SPR) also contains
subscription-related polices, but these are incorporated into the
PCRF policies by the PCRF. TS 23.203 also supports other
configurations with visited PCRFs for roaming scenarios, but in
these cases a single PCRF interfaces to the other policy servers.
The Policy Charging Enforcement function is incorporated into the
IP Connectivity Access Network (IP-CAN)-specific gateway (e.g.,
GGSN, PDG, CMTS). In 3GPP IMS, the P-CSCF implements the AF
(Application Function) functionality. The AF communicates with the
PCRF via the Rx reference point. In 3GPP IMS, the P-CSCF interacts
with the PCRF in order to authorize the bearer resources for the
IMS SIP session. The PCRF uses the P-CSCF information as one of the
criteria for determining the policy that the PCEF applies to the
session bearer. The Gx reference point utilizes DIAMETER as the
protocol for communicating between the PCEF and the PCRF. Likewise,
DIAMETER is the protocol used on the Rx reference point between the
P-CSCF and the PCRF.
[0045] The SIP Events framework RFC 3265 provides a good general
solution since it is independent of the underlying policy and
network architecture and it ensures that all SIP UAs 110 will be
able to interact with all policy servers 130. However, for limited
bandwidth networks, such as GSM (Global System for Mobile
Communications), UMTS (Universal Mobile Telecommunications System),
CDMA (Code Division Multiple Access), and E-UTRAN (Evolved UMTS
Terrestrial Radio Access Network), the SIP Events framework RFC
3265 is extremely heavy for transferring the session policy to the
UAs 110 during session setup. At a minimum, the SIP Events
framework requires the following SIP messages to be sent to obtain
the session policy: a SIP SUBSCRIBE message, a SIP 200OK message, a
SIP NOTIFY message, and another SIP 200OK message.
[0046] In addition, these messages, especially the SUBSCRIBE
message and the NOTIFY message, are large, text-based messages that
also include the overhead of the IP and UDP headers. Therefore, the
messages could be hundreds of bytes in size. The NOTIFY message
might be particularly large since it contains the Extensible Markup
Language (XML)-encoded policy document.
[0047] Thus, in the scenario shown in the session policy flow
diagram in FIG. 1, twelve SIP messages are required for the three
policy channel interactions using SIP Events on the policy channel,
in addition to the nine SIP Session Signaling messages needed to
establish the session. Thus, the SIP signaling overhead of using
the SIP Events framework is greater than the SIP signaling required
for the SIP session establishment. Not only is this a waste of
signaling bandwidth, but in limited bandwidth networks such as
cellular, with signaling channels of only a few thousand kilobits
per second, this could cause a significant delay in the session
setup.
[0048] Also, the SIP Events framework is stateful, which means that
it establishes a SIP dialog. This can place a significant load on
the network infrastructure entities. Also, policy servers 130
traditionally have not implemented SIP but have used other
protocols such as AAA (RADIUS and DIAMETER) for transferring
policies.
[0049] The large number of round trip SIP messages that need to be
sent under this scenario and the large size of the messages and the
policy document can result in an unacceptably inefficient mechanism
that can consume a great deal of overhead. Not only is this a waste
of signaling bandwidth, this could cause a significant delay in
session setup.
[0050] In an embodiment, instead of SIP or SIPS URIs, where a 3GPP
PCC or similar AAA infrastructure has been deployed, AAA URIs or
similar URIs are provided in the Policy-Contact header. That is, a
communication path that is at a lower layer than the SIP messaging
layer is created between a UA and a policy server and is used as a
policy channel. The UA can send the policy server a session policy
request over this policy channel using a lower layer protocol. In
some cases, the lower layer protocol might be the DIAMETER protocol
or the RADIUS protocol using the Extensible Authentication Protocol
(EAP). Whereas EAP is described, one of ordinary skill may choose
other protocols such as, but not limited to, Point to Point
Protocol (PPP), etc. In other cases, the lower layer protocol
creates a data bearer channel between the wireless device and the
network. For example, the wireless device might send a message to
the network containing information to create a data channel. This
might be a General Packet Radio Service (GPRS) Activate Packet Data
Protocol (PDP) which is communication from the wireless device to a
network node called SGSN. In an LTE environment, the lower layer
protocol in the ESM messages might be, but is not limited to, a
PDN_CONNECTIVITY_REQUEST or a BEARER_RESOURCE_MODIFICATION_REQUEST
that could be tunneled and/or piggy-backed in an ATTACH message
from the wireless device to the MME or as separate default
messages. As per RFC 3588 the following are examples of valid
DIAMETER or RADIUS host identities:
TABLE-US-00001 aaa://host.example.com
aaa://host.example.com:6666.
[0051] Alternatively instead of using an AAA URI a new URI format
could be defined for MPDF, such as MPDF URI "mpdf:" or "mpdfeap:".
Other URI syntaxes are also possible.
[0052] FIG. 4 illustrates a system in which session policy requests
and policy documents can be sent in such a manner that the UE
implements EAP (Extensible Authentication Protocol) and uses EAP to
implement the policy channel protocol with the PCRF. A UA 110 can
connect to a network node of a first type, which might be a
gateway, an access point, a network access server, a proxy, or
another component with substantially equivalent capabilities.
Hereinafter, this component will be referred to as a gateway 120.
The gateway 120 might include a Policy Charging Enforcement
Function (PCEF). Hereinafter, references to the gateway 120 might
refer to the gateway 120 alone, the PCEF alone, or the gateway 120
in combination with the PCEF.
[0053] The UA 110 can send session policy requests to the gateway
120 via the EAP protocol or a similar, lower layer protocol. The
gateway 120 can connect to a network node of a second type, which
might be a policy server, a policy and charging rules function, an
authentication server, or a similar component. In some embodiments,
this component can be a stand alone element. In other embodiments,
this component can be combined with another component such as a SIP
proxy, including the P-CSCF. Hereinafter, this component will be
referred to as a policy server 130. Although only one policy server
130 is shown, multiple policy servers could be present. The gateway
120 can send session policy requests to the policy server 130 via
the RADIUS protocol, the DIAMETER protocol, or some other lower
layer protocol with substantially equivalent capabilities. The
state of the art procedures discussed previously for sending
session policy requests and receiving policy documents are depicted
by dashed lines in FIG. 4.
[0054] In the process of authenticating the UA 110, a lower layer
communication path 160 is created between the UA 110 and the policy
server 130, via the gateway 120. This path 160 can be used as the
policy channel. The various technologies by which an EAP-based
request can be transported from the UA 110 to the gateway 120 can
have a RADIUS- or DIAMETER-based infrastructure that can transport
EAP frames. Therefore, an EAP-based request can be transported from
the UA 110, via the gateway 120, to the policy server 130, and an
EAP-based response can be transported from the policy server 130 to
the UA 110.
[0055] In an embodiment, the policy channel 160 is used to send a
session policy request from the UA 110 to the policy server 130 and
to deliver a policy document or other policy information from the
policy server 130 to the UA 110. The policy channel 160 can be a
replacement for the Policy Channel mechanism based on the Subscribe
and Notify mechanisms defined in the
draft-ietf-sip-session-policy-framework draft. More specifically,
one or more EAP frames might be transported over an IP-CAN (IP
(Internet Protocol) Connectivity Access Network) via IKEv2
(Internet Key Exchange version 2) over IP per RFC 5108 between the
UA 110 and the gateway 120. Alternatively, other transport
protocols could be used, such as transporting EAP over PPP
(Point-to-Point Protocol) as per RFC 2284, wired IEEE 802 LANs
(IEEE-802.1x), IEEE 802.11 wireless LANs (IEEE-802.11), UDP (L2TP
[RFC2661] and IKEv2 [IKEv2]), and TCP (PIC). Other transport
protocols are also possible. In any of these transport protocols,
messages are sent at a lower protocol layer than the SIP messages,
which are typically sent at the application layer.
[0056] In some embodiments, the type-length-value (TLV) structure
allowed in EAP might be used to insert a query that requests the
policy document. In other embodiments, the policy contact URI can
be appended to any NAI per RFC 4482 that has been used to identify
the user. The policy server address could also be encrypted by a
shared key between the SIP UA and the home AAA server that handles
the EAP frames. This allows the policy address to be kept secret
from any intermediate nodes.
[0057] In an embodiment, the gateway 120 forwards the EAP frames
over the Gx reference point to the policy server 130 using
DIAMETER. In other embodiments, RADIUS or a similar protocol might
be used. The EAP frames can transport policy channel documents such
as session information documents between the UA 110 and the gateway
120 and the policy server 130. The session information documents
might be InfoOffer, InfoAnswer, and/or other documents as defined
in the draft-ietf-sip-session-policy framework and related
documents or future extensions. The UA 110 can gain access to the
policy server 130 to obtain the policy document based on a policy
contact URI (Uniform Resource Indicator) provided in the
Policy-Contact header or a new header that could be called, but is
not limited to being called, a Policy-Contact header. The policy
server 130 can then return a policy document or other policy
information to the UA 110. The policy information might be returned
along the same path using the same protocol as the request, along
the same path using a protocol different from that used on the
request, along a different path from that used on the request, or
in some other manner. For session-specific policies, if the session
policies change during a session (because of a change in the
available radio resources, for example), the policy server 130 can
send a modified policy document to the UA 110 using the same
DIAMETER and EAP protocols.
[0058] FIG. 5 shows an embodiment of a proposed protocol stack for
transporting media policy documents over EAP and IP between a UA
and a DIAMETER-based PCRF via an IP-CAN access gateway.
[0059] When the embodiments described herein are implemented, the
number of round trip messages needed for the UA 110 to request and
receive a policy document can be greatly reduced compared to the
plurality of SIP messages that were used in the SIP scenario
described above. Also, EAP-based session policy requests can be
significantly smaller than some of the SIP messages described
above. For example, the overhead of a SIP message is typically
around 500 to 1000 bytes. The overhead of an EAP-based message, on
the other hand, is typically around 50 bytes.
[0060] In addition, in an embodiment, the policy document can be
converted to binary to make it smaller, and this smaller policy
document can be sent to the UA 110, rather than the large,
XML-based policy document that is sent in the SIP-based method. The
XML content of the session policy documents could be compressed
into binary form by a number of methods known in the art. One
example would be XML Infoset, as specified in ITU-T Rec. X.891.
[0061] 3GPP has as an objective that authorization requests for
media not be linked with SIP signaling. The session policy requests
described herein use EAP-based messages to request authorization to
obtain media and therefore can accomplish this decoupling of SIP
signaling from the authorization policy for media.
[0062] In addition, EAP-based session policy requests are access
network agnostic. That is, the UA 110 might connect to the gateway
120 via one or more of several different wireless or wired
communication technologies such as GPRS (which might include GSM,
EDGE, UTRAN, and/or E-UTRAN), 3GPP UTRAN, 3GPP2 CDMA, 802.11x WLAN,
802.16 WiMAX, 802.20 WLAN, DOCSIS (Data Over Cable Service
Interface Specification), and/or TISPAN (Telecoms and Internet
converged Services and Protocols for Advanced Networks) NASS/RACS
(Network Attachment Sub-System/Resource and Admission Control
System). Since these architectures typically rely on DIAMETER-based
or RADIUS-based policy servers, the UA 110 can submit EAP-based
session policy requests to the gateway 120 as described herein,
regardless of which of these access networks the UA 110 uses to
connect to the gateway 120.
[0063] FIG. 6 depicts an example of how session policy requests
might be handled when the UA 110 (which is referred to in FIGS. 6
through 12 as the UE) uses a GPRS (GSM/EDGE/UTRAN/E-UTRAN) IP-CAN.
3GPP cellular access (GSM/EDGE/UTRAN/E-UTRAN) to IMS uses GPRS. For
GPRS, the IP-CAN bearer is the PDP context. In GPRS, the gateway is
the GGSN and the PCEF is collocated with the GGSN. The Gx reference
point between the PCEF and the PCRF and the Rx reference point
between the P-CSCF and the PCRF use DIAMETER.
[0064] In this access network scenario, EAP frames from the UE
containing the Policy channel InfoOffer and InfoAnswer messages
would be transported over IKEv2 over IP or alternatively over PPP
to the GGSN. The EAP frames containing the Policy channel InfoOffer
and InfoAnswer messages would then be routed over DIAMETER using
the Gx reference point to the PCRF. The PCRF would then, based on
the Policy Info contained in the InfoOffer or InfoAnswer messages
from the UE, the policies installed in the PCRF, subscriber
policies fetched from the SPR, service based authorization policies
installed by the P-CSCF via Rx, and knowledge of the access network
the UE is using and its available resources, generate a Media
policy document. The PCRF will send the Media policy document in a
PolicyOffer or Policy Answer message in EAP frames over Gx to the
GGSN that then forwards to the UE in EAP transported over IKEv2
over IP or alternatively over PPP to the UE. Other scenarios are
also possible.
[0065] FIG. 7 depicts an example of how session policy requests
might be handled when the UE uses a 3GPP E-UTRAN or other non-3GPP
access with Enhanced Packet Core (EPC) IP-CAN. 3GPP E-UTRAN and
other non 3GPP accesses can use the Enhanced Packet Core (EPC) to
access IMS. For EPC, the IP-CAN bearer is the PDP context enhanced
from GPRS or Proxy Mobile IP (PMIP). In EPC, the gateway is the PDN
GW and the PCEF is collocated with the PDN GW. The Gx reference
point between the PCEF and the PCRF and the Rx reference point
between the P-CSCF and the PCRF use DIAMETER.
[0066] In this access network scenario, EAP frames from the UE
containing the Policy channel InfoOffer and InfoAnswer messages
could be transported over IKEv2 over IP to the PDN GW.
Alternatively, the channel InfoOffer could be tunneled,
piggybacked, or transported in an ESM message such as PDN
CONNECTIVITY REQUEST or, in the case where an ESM message has not
been included in the ATTACH message from the wireless device, the
InfoOffer could be transported via MME to the PDN GW. The EAP
frames containing the Policy channel InfoOffer and InfoAnswer
messages or the messages from the MME to the PDN that create the
EPC bearer channel containing, for example, the Create Session
Request containing the InfoOffer and Create Session Response
containing the InfoAnswer messages would then be routed over
DIAMETER using the Gx reference point to the PCRF. The PCRF would
then generate a media policy document based on the Policy Info
contained in the InfoOffer or InfoAnswer messages from the UE, the
policies installed in the PCRF, subscriber policies fetched from
the SPR, service based authorization policies installed by the
P-CSCF via Rx, and/or knowledge of the access network the UE is
using and its available resources. The PCRF will send the media
policy document in a PolicyOffer or Policy Answer message in EAP
frames over Gx to the PDN GW that then forwards to the UE in EAP
transported over IKEv2 over IP to the UE or via a Create Session
Response containing the Policy Answer.
[0067] FIG. 8 depicts an example of how session policy requests
might be handled when the UE uses a 3GPP2 CDMA IP-CAN. 3GPP2
cellular access (CDMA-1X, CDMA EVDO) to IMS uses mobile IP. In
3GPP2 CDMA, the gateway is the PDSN and the PCEF is collocated with
the PDSN. The Gx reference point between the PCEF and the PCRF and
the Rx reference point between the P-CSCF and the PCRF use
DIAMETER.
[0068] In this access network scenario, EAP frames from the UE
containing the Policy channel InfoOffer and InfoAnswer messages
would be transported over IKEv2 over IP to the PDSN. The EAP frames
containing the Policy channel InfoOffer and InfoAnswer messages
would then be routed over DIAMETER using the Gx reference point to
the PCRF. The PCRF would then generate a media policy document
based on the Policy Info contained in the InfoOffer or InfoAnswer
messages from the UE, the policies installed in the PCRF,
subscriber policies fetched from the home network (such as from the
SPR or the home PCRF or another policy server in the home network),
service based authorization policies installed by the P-CSCF via
Rx, and/or knowledge of the access network the UE is using and its
available resources. The PCRF will send the Media policy document
in a PolicyOffer or Policy Answer message in EAP frames over Gx to
the PDSN that then forwards to the UE in EAP transported over IKEv2
over IP to the UE.
[0069] FIG. 9 depicts an example of how session policy requests
might be handled when the UE uses an 802.11x WLAN IP-CAN. In
802.11x WLAN access to IMS the gateway is the PDG and the PCEF is
collocated with the PDG. The Gx reference point between the PCEF
and the PCRF and the Rx reference point between the P-CSCF and the
PCRF use DIAMETER.
[0070] In this access network scenario, EAP frames from the UE
containing the Policy channel InfoOffer and InfoAnswer messages
would be transported over IKEv2 over IP or alternatively over
802.1X to the PDG. The EAP frames containing the Policy channel
InfoOffer and InfoAnswer messages would then be routed over
DIAMETER using the Gx reference point to the PCRF. The PCRF would
then, based on the Policy Info contained in the InfoOffer or
InfoAnswer messages from the UE, the policies installed in the
PCRF, subscriber policies fetched from the SPR, service based
authorization policies installed by the P-CSCF via Rx, and
knowledge of the access network the UE is using and its available
resources, generate a Media policy document. The PCRF will send the
Media policy document in a PolicyOffer or Policy Answer message in
EAP frames over Gx to the PDG that then forwards to the UE in EAP
transported over IKEv2 over IP to the UE.
[0071] FIG. 10 depicts an example of how session policy requests
might be handled when the UE uses a WiMAX/802.16 IP-CAN. In the
WiMAX IP-CAN, the UE (also referenced as Mobile Station or MS in
IEEE 802.16 standards) connects to the WiMAX Access Service Network
(ASN). The ASN logically communicates with a Connectivity Service
Network (CSN) which is a collection of core networking functions
(e.g., Mobile IP HA, AAA Server, DHCP, DNS, etc.). The ASN manages
traffic admission and scheduling, enforces QoS for an authorized
UE, and performs accounting functions for the UE (per session,
flow, or UE). WiMAX PCEF is part of WiMAX IP-CAN and is to be
defined by WiMAX Forum. WiMAX PCEF terminates the Gx reference
point from the PCRF and may be a distributed enforcement
architecture.
[0072] The PCC functional mapping to WiMAX IP-CAN is shown in FIG.
8, where PCC Gx and Rx are applied. Gx and Rx use DIAMETER.
[0073] In this access network scenario, EAP frames from the UE
containing the Policy channel InfoOffer and InfoAnswer messages
would be transported over IKEv2 over IP or alternatively over
802.1X to the WiMAX PCEF. The EAP frames containing the Policy
channel InfoOffer and InfoAnswer messages would then be routed over
DIAMETER using the Gx reference point to the PCRF. The PCRF would
then, based on the Policy Info contained in the InfoOffer or
InfoAnswer messages from the UE, the policies installed in the
PCRF, subscriber policies fetched from the SPR, service based
authorization policies installed by the P-CSCF via Rx, and
knowledge of the access network the UE is using and its available
resources, generate a Media policy document. The PCRF will send the
Media policy document in a PolicyOffer or Policy Answer message in
EAP frames over Gx to the WiMAX PCEF that then forwards to the UE
in EAP transported over IKEv2 over IP to the UE.
[0074] FIG. 11 depicts an example of how session policy requests
might be handled when the UE uses a DOCSIS IP-CAN. In the DOCSIS
IP-CAN, each UE is connected to the network via a Cable Modem (CM)
which is connected through a Hybrid Fiber Coax (HFC) access network
to a Cable Modem Termination System (CMTS). Though the UE and CM
may or may not be embedded within the same physical package, they
remain separate logical devices. One or more UEs may subtend a
single CM. Because the CMTS provides the IP connectivity and
traffic scheduling and manages quality of service for the CM and
the UEs which subtend it, the CMTS fulfils the role of PCEF for the
DOCSIS IP-CAN. In the DOCSIS IP-CAN, the Application Manager (AM)
and the Policy Server (PS) fulfill the role of the PCRF.
[0075] When accessing resources via a DOCSIS IP-CAN, the Rx
interface can be used to request resources. The Rx interface uses
DIAMETER. The communication between the AM and PS and the PS and
CMTS uses the PKT-MM-2 interface, which is based on COPS and
defined in J.179. COPS runs over IP and use IPsec ESP using IKE or
Kerberos for key management.
[0076] The PKT-MM-2 interface performs the functions of the Gx
interface but uses COPS, not DIAMETER. DOCSIS systems do not
represent a full 3GPP PCC implementation but can interface to
it.
[0077] DOCSIS defined an mm-7 interface between the UE and the AM
to allow the UE to interact with the AM and to request and manage
QoS resources directly. This interface is not yet standardized by
Packet Cable.
[0078] EAP frames could potentially be transmitted over mm-7 to
reach the AM and via the AM the PS. Alternatively, since DOCSIS is
another 802.1x implementation, the EAP frames can be transmitted as
in 802.1x to reach the CMTS, and then the COPS protocol on the
PKT-MM-2 interface can be used to relay EAP frames as RADIUS
attributes.
[0079] In this access network scenario, EAP frames from the UE
containing the Policy channel InfoOffer and InfoAnswer messages
would be transported over IKEv2 over IP to the PCRF/AM using mm-7.
The PCRF (AM and PS) would then, based on the Policy Info contained
in the InfoOffer or InfoAnswer messages from the UE, the policies
installed in the PS, service based authorization policies installed
by the P-CSCF via Rx, and knowledge of the access network the UE is
using and its available resources, generate a Media policy
document. The PCRF/AM will send the Media policy document in a
PolicyOffer or Policy Answer message in EAP frames transported over
IKEv2 over IP to the UE via mm-7 or via COPS and 802.1x.
[0080] FIG. 12 depicts an example of how session policy requests
might be handled when the UE uses TISPAN NASS/RACS. TISPAN NGN does
not use 3GPP PCC. In TISPAN NGN there is the NASS (Network
Attachment Sub-System) and RACS (Resource and Admission Control
System). The RACS is responsible for elements of policing control,
including resource reservation and admission control in the access
and aggregation networks. The RACS provides policy-based transport
control services to applications. These services enable
applications to request and reserve transport resources from the
transport networks within the scope of the RACS. RACS consists of
the SPDF and the A-RACF.
[0081] The SPDF is a functional element that coordinates the
resource reservations requests that it receives from the P-CSCF.
Among the functions that the SPDF performs is determining whether
the request information received from the P-CSCF is consistent with
the policy rules defined in the SPDF. The SPDF also authorizes the
requested resources for the SIP session. To do so, the SPDF uses
request information received from the P-CSCF to calculate the
proper authorization (that is, to authorize certain media
components). In addition, the SPDF provides the location of the
A-RACF device in accordance with the required transport
capabilities, requests resources of the A-RACF, hides the details
of the RACS and the core transport layer from the control
architecture, and provides resource mediation by mapping requests
from application functions toward an appropriate A-RACF.
[0082] The A-RACF is a functional element that provides admission
control and network policy assembly. For admission control, the
A-RACF receives requests for QoS resources from the SPDF and uses
the QoS information received to perform admission control. It then
indicates to the SPDF whether or not a request for resources is
granted.
[0083] Access network policies are a set of rules that specify the
policies that should be applied to an access line. For network
policy assembly, the A-RACF ensures that requests from the SPDF
match the access policies, because multiple SPDFs can request
resources from the A-RACF. The A-RACF also combines the requests
from the SPDFs that have requested resources and ensures that the
total of the requests match the capabilities of the access
line.
[0084] The SPDF issues requests for resources in the access network
through the Rq interface. These requests indicate IP QoS
characteristics. The A-RACF uses the IP QoS information to perform
admission control and indicates to the SPDF through the Rq
interface its admission control decisions. The Rq interface uses
DIAMETER. The RACS performs similar policy control functions as the
3GPP PCC PCRF. The P-CSCF uses Gq' to communicate with RACS and Gq'
uses DIAMETER. Gq' provides similar functionality to Rx in 3GPP
PCC.
[0085] The IP Edge Router, which is equivalent to the gateway in
3GPP PCC, contains the ACEF (Access Control Enforcement Function),
which performs equivalent functions to the PCEF in 3GPP PCC. The Re
interface between RACS and the ACEF is not yet standardized. The IP
Edge Router also contains the AMF (Access Management Function),
which is a RADIUS client that interfaces to the NASS (technically
the AMF is part of the NASS). The AMF translates the network access
requests sent by UE, forwards the requests for allocation of an IP
address and network, and forwards the user authentication requests
to the User Access Authorization Function (UAAF). In the reverse
direction, AMF forwards the response from the UAAF (User Access
Authorization Function) within the NASS to the UE.
[0086] NASS provides registration at access level and
initialization of user equipment for access to TISPAN NGN services.
NASS provides network-level identification and authentication,
manages the IP address space of the access network, and
authenticates access sessions. NASS also announces the contact
point of the TISPAN NGN service/applications subsystems to the user
equipment. Network attachment via NASS is based on implicit or
explicit user identity and authentication credentials stored in the
NASS. Within the NASS there is the UUAF and the CLF (Connectivity
Session Location and Repository Function) along with other
functions not relevant here. The UAAF performs user authentication
and authorization checking. The UAAF retrieves user authentication
and access authorization information from the user profiles
contained in the Profile Database Function (PDBF). The UAAF also
collects accounting data for billing. The CLF registers the IP
address allocated to the UE, the related network location
information, and geographical location information provided by
NACF, and associates all the information. The CLF stores the
identity of user, the QoS profile of user network, and the user
privacy setting of location information. The CLF provides the
location query function for high-level service. The CLF
communicates with A-RACF within the RACS via the e4 interface. The
e4 interface uses DIAMETER. Interface a3 is used between the AMF
and the UAAF. It allows the AMF to request the UAAF to authenticate
the user and check the network subscription information. Interface
a4 is used between the UAAF and the CLF. It allows the UAAF to
request the CLF to register the association between the user
identity and the user privacy setting of location information as
well as user network profile information (for example, QoS profile)
in the mode of Push. Interface a4 allows the CLF to query the user
network profile from the UAAF in the mode of Pull. Interfaces a3
and a4 are not currently standardized.
[0087] In this access network scenario, EAP frames from the UE
containing the Policy channel InfoOffer and InfoAnswer messages
would be transported over IKEv2 over IP to the IP Edge Router. The
EAP frames containing the Policy channel InfoOffer and InfoAnswer
messages would then be routed over RADIUS using the a3 interface to
the NASS (UUAF). The NASS (UUAF) would then be forwarded on using
RADIUS (a4) and DIAMETER (e4) to the RACS (A-RACF). The RACS
(A-RACF and SPDF) would then, based on the Policy Info contained in
the InfoOffer or InfoAnswer messages from the UE, the policies
installed in the SPDF, service based authorization policies
installed by the P-CSCF via Gq', and knowledge of the access
network the UE is using and its available resources, generate a
Media policy document. The RACS (A-RACF) will send the Media policy
document in a PolicyOffer or Policy Answer message in EAP frames
over e4 to the NASS which will forward them on using RADIUS over a4
and a3 to the IP Edge Router that then forwards to the UE in EAP
transported over IKEv2 over IP to the UE.
[0088] FIG. 13 illustrates an embodiment of a method 400 for
sending a session policy request to a network component. At block
410, a UA sends a session policy request to the network component
using the EAP protocol or a similar protocol such as, but not
limited to, Activate PDP context. The network component might be a
policy server, an authentication server, a policy control and
charging rules function, a subscription profile repository, a
policy control and enforcement function, a network access server, a
gateway, a router, a SIP Proxy such as a CSCF (e.g., a P-CSCF or an
S-CSCF), or a similar component. In some cases, the session policy
request might pass through one or more of these components before
terminating at another of these components.
[0089] In some cases, one or more new URI schemes might be used
with the existing Policy-Contact header to ensure backward
compatibility with existing SIP User Agents that only understand
the SIP and SIPS URI schemes defined in
draft-ietf-sip-session-policy-framework-05. In an embodiment, the
new URI schemes are included in the Policy-Contact header by adding
new, alternate, non-SIP URIs (for example an AAA URI) of the policy
server in addition to the SIP or SIPS URI. For example, an
alternate URI could be:
TABLE-US-00002 Policy-Contact: sip::host.example.com,
aaa://pcrf.example.com; alt-uri=host.example.com
[0090] The above example shows an embodiment where the two
policyContactURIs are actually alternate URIs of the same policy
server that use different protocols on the policy channel to obtain
the policy documents. This can be contrasted with the current state
of the art in draft-ietf-sip-session-policy-framework-05, where
URIs might be specified for two different policy servers that both
need to be contacted.
[0091] A parameter (shown here as the alt-uri parameter) indicates,
by containing the hostname contained in the SIP URI of the same
policy server, that it is an alternate URI of the same policy
server in the other policyContactURI (sip:host.example.com).
Assuming that existing SIP UAs will ignore policyContactURI URI
schemes that they do not understand, as mandated in
draft-ietf-sip-session-policy-framework-05, all UAs that support
Session Policy might need to support the SIP and SIPS schemes for
obtaining policy documents. The UAs that only support SIP and SIPS
URI schemes will ignore the policyContactURIs that use other URI
schemes. SIP UAs that understand and support the new URI scheme and
the alt-uri tag will understand that aaa://pcrf.example.com is an
alternate URI or address of the same policy server at
sip:host.example.com.
[0092] It should be appreciated by those skilled in the art that
the parameter "alt-uri" is used to indicate that one
policyContactURI is an alternative URI of another policyContactURI
and that the name of the parameter could be different in different
embodiments. Other possible embodiments may not contain the
hostname as the value of the parameter. They could contain the SIP
URI or some other indication including an index of the
policyContactURI. For example, "1" could indicate the first
policyContactURI, or the parameter "prey" could indicate the
previous policyContactURI.
[0093] In another possible embodiment, a parameter could contain a
label that would indicate that multiple policyContactURIs are for
the same policy server. For example:
TABLE-US-00003 Policy-Contact: sip::host1.example1.com; label="A",
aaa://pcrf1.example1.com; label="A", sip::host2.example2.com;
label="B", aaa://pcrf2.example2.com; label="B"
[0094] In another possible embodiment, the SIP UA simply compares
the domain name portions of the hostnames or the fully qualified
domain names (FQDN) of the URIs and, if they are the same, the UA
assumes that they are different policyContactURIs for the same
policy server. If there are alternate policyContactURIs for the
same policy server, then the SIP UA can determine which
policyContactURI to use to contact the policy server.
[0095] FIG. 14 illustrates an embodiment of a method 500 for a UA
to access a session policy in a network. At block 510, the UA
receives, in a header field of a response message, a plurality of
URIs for a policy server.
[0096] Being based on DIAMETER or RADIUS, the 3GPP PCC architecture
supports inter-domain communication between policy servers. In an
IMS session, as many as four domains (Originating Visited,
Originating Home, Terminating Home, and Terminating Visited) can be
involved in a session setup (even more, possibly, if transit
networks are involved). Each of these domains potentially could
have policies that are applied to the session (media types, codecs,
etc.).
[0097] In addition, with the current session policy mechanism
defined by 3GPP, potentially each proxy in each domain could have
to reject a SIP INVITE request with a SIP 488 response, resulting
in the calling UA having to send five SIP INVITE requests (and
receive four SIP 488 responses) before the SIP INVITE request
reaches the called UA. In addition, the SIP servers might need to
contact each one of a plurality of policy servers to obtain policy
information. This can delay call setup and drain the UA's
battery.
[0098] The IETF Session Policy Framework provides a mechanism for
SIP proxies to inform both the originating and terminating UAs of
session policies that apply to the session. This is done by the
proxies each adding the URI of their policy server to the
Policy-Contact header.
[0099] DIAMETER and RADIUS enable a policy server in one domain to
communicate with policy servers in other domains (subject to
agreements between service providers). In an embodiment, this
capability is used to allow multiple policy servers to be contacted
via a single request from a UA, with the first policy server
contacting the other policy servers or in a hierarchical tree. For
example, the UA contacts policy server A, policy server A contacts
policy server B and policy server C, policy server B contacts
policy server D and policy server E, etc. The policy documents
returned are then combined into a single policy document that is
then returned to the UA. To achieve this, the SIP proxies indicate
to the UA that other policy servers whose URIs already are listed
in the Policy-Contact header can be contacted via the policy server
in its domain.
[0100] draft-ietf-sip-session-policy-framework-05 defines the
syntax of the Policy-Contact header field as:
TABLE-US-00004 Policy-Contact = "Policy-Contact" HCOLON
policyContactURI *(COMMA policyContactURI) policyContactURI = (
SIP-URI / SIPS-URI / absoluteURI ) [ SEMI "non-cacheable" ] *( SEMI
generic-param )
[0101] The Policy-Contact URI allows additional parameters
(generic-param as defined in RFC 3261). From RFC 3261:
TABLE-US-00005 generic-param = token [ EQUAL gen-value ] gen-value
= token / host / quoted-string host = hostname / IPv4address /
IPv6reference hostname = *( domainlabel "." ) toplabel [ "." ]
domainlabel = alphanum / alphanum *( alphanum / "-" ) alphanum
toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum
[0102] Thus, using the above Backus-Naur Form, the following
Policy-Contact header can be constructed:
TABLE-US-00006 Policy-Contact:
<aaa://host1.example1.com:1813>,
<aaa://host2.example2.com:3868>; proxy-to=
host1.example1.com, <aaa://host3.example3.com:1727>;>;
proxy-to= host1.example1.com; proxy-to= host2.example2.com
[0103] In the above example, the SIP Proxy for domain example1.com
has included its policy server URI,
"aaa://host1.example1.com:1813". Then the SIP proxy for domain
example1.com adds its policy server URI,
"aaa://host2.example2.com:3868", and determines that the Policy
Server for example1.com can be reached via its policy server and so
adds the parameter "proxy-to" set equal to the hostname of the
policy server for example1.com (host1.example1.com). Likewise, the
SIP proxy for domain example3.com adds its policy server URI,
"aaa://host3.example3.com:1727", and determines that the policy
server for example1.com and the policy server for example2.com can
be reached via its policy server and so adds the parameter
"proxy-to" set equal to the hostname of the policy server for
example1.com and a second "proxy-to" parameter set equal to the
hostname of the policy server for example2.com.
[0104] When the UA receives the SIP Invite request or SIP 488
response containing the above Policy-Contact header, it scans the
list of URIs. If a URI in the list has associated one or more
proxy-to parameters containing one or more hostnames or domain
names appearing in other URIs in the Policy-Contact header, the UA
can, when formatting the EAP InfoOffer or InfoAnswer message,
include parameters such as an Also-Contact parameter containing the
AM URIs of the policy servers from the Policy-Contact header whose
hostname or domain name appears in proxy-to parameters associated
with that URI listed in the Policy-Contact header. The EAP
InfoOffer or InfoAnswer messages also include the intended offer or
answer as defined in
draft-ietf-sipping-media-policy-dataset-06.
[0105] When the first policy server receives a Policy Channel
message containing an InfoOffer or InfoAnswer message containing
Also-Contact parameters, it will address DIAMETER requests to the
policy servers identified in the Also-Contact Parameters and will
include in the Also-Contact parameters in the request the URIs from
any proxy-to parameters.
[0106] When the first policy server receives policy documents from
the other policy servers, it composes all the received policy
documents along with its own policy document into a single policy
document and returns it in a PolicyOffer or Policy Answer Message
to the requestor. The first policy server also includes all the AAA
URIs of all the policy servers that contributed to the contained
policy document in a Policy-Contributor parameter in the
PolicyOffer or PolicyAnswer message.
[0107] When the UA receives the PolicyOffer or PolicyAnswer
message, it checks the Policy-Contributor parameter and ensures
that the policy document represents the policies from all the
policy servers that were indicated in the EAP InfoOffer or
InfoAnswer message. According to draft-ietf-sip-session-policy, "If
setting up a policy channel to one of the discovered policy servers
fails, the UA MAY continue with the initiation of a session without
contacting this policy server." However, if a policy server was not
contacted, the UA will not include the URI of that policy server in
the Policy-ID header in the SIP request or response. The UA
includes only the policy servers for which it received confirmation
that those policy servers contributed to the policy document.
[0108] Alternatively, the UA can contact all the policy servers
individually in parallel using the EAP/AAA infrastructure instead
of using the above consolidated approach.
[0109] In another embodiment, the P-CSCF or other SIP proxies
(e.g., S-CSCFs, etc.) may use the Also-Contact parameter to inform
their policy server of the Policy Contact URIs of other policy
servers upstream so that the policy server can obtain the other
policies or so that the P-CSCF or other SIP proxies (e.g., S-CSCFs,
etc.) may themselves obtain the policy documents from other policy
servers (e.g., using a SIP-based policy channel or DIAMETER or
RADIUS, etc.) and then provide that policy document to their policy
server. The policy server then creates an aggregated policy
document based on the aggregation of the policies of the other
policy servers and provides the aggregated policy document to the
UA when it requests the policy document over the policy channel.
The policy server may also include all the AAA URIs of all the
policy servers that contributed to the contained policy document in
a Policy-Contributor parameter in the PolicyOffer or PolicyAnswer
message.
[0110] An AAA URI has been used in the above for simplicity, but
the actual syntax of the URI scheme is not relevant to the above
embodiments as any URI scheme that allows the UA or the SIP proxies
(P-CSCF, S-CSCF, etc.) to contact the policy servers over an
EAP/DIAMETER/RADIUS infrastructure is sufficient.
[0111] FIG. 15 shows how multiple PCRFs in different domains may be
interconnected using DIAMETER (similar connections could be
provided using RADIUS) and how multiple SIP proxies (P-CSCF and
S-CSCF) in different domains may provide their PCRFs with
session-based input into the policies returned. For example, the
S-CSCF in the user's home network may influence the policies based
on the IMS Communication Service Identifier included in the SIP
request.
[0112] Using this technique, a single session policy request can be
made to a first policy server, and that policy server can relay the
session policy request to other policy servers. The first policy
server can then aggregate policy documents from the other policy
servers and deliver a single policy document to the UA. More
specifically, in an embodiment, since the DIAMETER and RADIUS
protocols allow AAA servers (such as policy servers) to interface
to each other across domains, a single policy server can supply a
composite policy of the policies from multiple domains that the SIP
session traverses in a single policy channel exchange. It might be
desirable for a policy channel mechanism to be based around the
IETF session policies framework that interfaces to the existing
3GPP PCC mechanism and DIAMETER- or RADIUS-based policy
servers.
[0113] FIG. 16 illustrates an embodiment of a method 600 for a UA
to access a session policy in a network. At block 610, the UA
contacts a plurality of network components via a single session
policy request to a single network component.
[0114] In an alternative implementation, when a SIP UA wants to
obtain service from the SIP infrastructure, for example an IMS
network, the SIP UA sends a message such as, but not limited to, a
SIP REGISTER. When a network node receives this SIP REGISTER, such
as an S-CSCF initial Filter Criteria (iFC) trigger, a third party
registration is made to another network node which could be, but is
not limited to, a SIP server or a policy server. The SIP server is
a node that contains the session policy information that is
required by the SIP UA. The SIP server then sends policy
information to the SIP UA via SIP push, SMS, USSD, Cellbroadcast,
or MBMS. In the above examples, the policy information might be
proprietary encoded or might be an OMA DM management object.
[0115] The SIP REGISTRATION could happen at any time, and the SIP
UA could be provisioned such that, when it changes radio access
technologies or changes its capabilities, it performs a
registration. This registration information, when received by the
SIP server as described above, can trigger an update of the policy
information. This update might be based on the new information,
such as SIP UA capabilities, or on P-Network-Access-info header
information that could possibly be sent either in the third party
registration or via the SIP server subscribing to the Reg Event
package.
[0116] In another embodiment, the SIP REGISTRATION and third party
register could trigger the SIP server to send a message to the SIP
UA to perform an EAP frame request resulting in the collection of
the policy information.
[0117] In yet another embodiment, when the network node, such as an
S-CSCF, sends back a 200OK, this 200OK could contain the policy
information or it could contain a URL that points to a location
where the policy information may be obtained from. The URL could
be, but is not limited to being, contained in a SIP header or
embedded in XML.
[0118] In yet another embodiment, the S-CSCF/Registrar may return
in the SIP 200OK to the REGISTER a Policy-Contact header containing
a policyContactURI to the policy document. Other SIP proxies such
as the P-CSCF on the path of the SIP REGISTER may include their own
Policy-Contact headers containing the policyContactURI of their own
policy server in the SIP 200OK to the SIP REGISTER directly or
directly in the SIP REGISTER itself. If the policyContactURI is
included in the SIP REGISTER, the S-CSCF/Registrar or other proxy
can then either obtain the policy document directly and provide it
to its own policy server to produce an aggregated policy document
or provide the policyContactURI of the other policy server(s) so
that an aggregated policy document can be produced by the policy
server using the mechanisms described above. The Policy-Contact
headers received in the SIP REGISTER may also be provided to the
SIP UA in the SIP 200OK to the SIP REGISTER.
[0119] The mechanisms described above for identifying that a
policyContactURI is an alternate URI (e.g., alt-uri parameter) and
that a policy document can be obtained via another policy (e.g.,
proxy-to parameter) can also be used with the SIP REGISTER and SIP
200OK embodiments to allow the SIP UA to obtain the aggregated
policies in an efficient manner without having to contact multiple
policy servers but only contact a single policy server using the
policy channel using the mechanisms described above.
[0120] draft-ietf-sip-session-policy-framework-05 does not
currently define the Policy-Contact header being used in a SIP
REGISTER or SIP 200OK, so this embodiment can be implemented as a
SIP extension to draft-ietf-sip-session-policy-framework-05. To
indicate support for this extension, the SIP UA can include a
Supported header containing an option-tag such as the option-tag
"policy" in the SIP REGISTER request. Based on this option-tag, the
proxies, the S-CSCF/Registrar, and/or an application server via
third party registration can determine that the SIP UA supports
receiving Policy-Contact headers in the SIP 200OK to the SIP
REGISTER.
[0121] In yet another embodiment, a UA can send a message of a
first authorization type to the network, where the first
authorization type could be, but is not limited to, EAP, GPRS
Activate PDP context, or SIP REGISTER. Within the first
authorization type message, a set of parameters can be present that
identify the information such as the SIP UA, InfoOffer information,
and the subscriber's identity, such as a Public User identity.
Those skilled in the art will realize that the term set is a
collection of well defined and distinct objects, where the number
of these defined and distinct objects or information elements can
be zero to many. The following is an example of such a message from
the UA to the network:
TABLE-US-00007 EAP Code: 1 (Request) Type: 125* SessionPolicy
Length: Variable Value: [NAI] [info offer] [info answer]
<MIC>
[0122] NAI is the identifier used by the UA to authenticate with
the network. The format of the identity is defined in RFC 4282. The
NAI content is used by the AAA server (RADIUS or DIAMETER) to route
the policy request to the appropriate policy server. The EAP "Type"
may also be used to route the EAP content.
[0123] The first authorization type message can be received by a
network node that could be, but is not limited to, an AM server, a
GGSN, or a CSCF. This network node can take a set of the first
authorization type information and put it into a second
authorization type message that could be, but is not limited to,
RADIUS, DIAMETER, or SIP REGISTER. The first lower layer message
could be placed in its entirety into the second one. This second
lower layer message can be sent to a second network node that can
return the necessary policy information to the first network node.
The first network node can do a reverse translation and send back
an acknowledgement of the first authorization type to the UA
containing the policy information. The following is an example of
such a message from the network to the UA:
TABLE-US-00008 EAP Code: 2 (Response) Type: 125* SessionPolicy
Length: Variable Value: [NAI] [policy offer] [policy answer]
<MIC>
[0124] Policy offer, policy answer, info offer, and info answer are
defined in
http://www.ieff.org/internet-drafts/draft-ietf-sipping-media-policy-datas-
et-06.txt
[0125] If the EAP method (such as EAP-SIM or EAP-AKA) used for
authentication is compliant with the EAP Keying Framework (RFC
5247), a MIC can be used to protect the session policy
request/response against forgery and replay attacks. Alternatively,
the session policy request/response could be protected with a
shared key.
[0126] FIG. 17 illustrates an embodiment of a method 700 for a UA
to access a session policy in a network. At block 710, the UA sends
a registration message to a first network node. At block 720, the
UA receives policy-related information.
[0127] The UA 110 and other components described above might
include a processing component that is capable of executing
instructions related to the actions described above. FIG. 18
illustrates an example of a system 1300 that includes a processing
component 1310 suitable for implementing one or more embodiments
disclosed herein. In addition to the processor 1310 (which may be
referred to as a central processor unit or CPU), the system 1300
might include network connectivity devices 1320, random access
memory (RAM) 1330, read only memory (ROM) 1340, secondary storage
1350, and input/output (I/O) devices 1360. These components might
communicate with one another via a bus 1370. In some cases, some of
these components may not be present or may be combined in various
combinations with one another or with other components not shown.
These components might be located in a single physical entity or in
more than one physical entity. Any actions described herein as
being taken by the processor 1310 might be taken by the processor
1310 alone or by the processor 1310 in conjunction with one or more
components shown or not shown in the drawing, such as a digital
signal processor (DSP) 1380. Although the DSP 1380 is shown as a
separate component, the DSP 1380 might be incorporated into the
processor 1310.
[0128] The processor 1310 executes instructions, codes, computer
programs, or scripts that it might access from the network
connectivity devices 1320, RAM 1330, ROM 1340, or secondary storage
1350 (which might include various disk-based systems such as hard
disk, floppy disk, or optical disk). While only one CPU 1310 is
shown, multiple processors may be present. Thus, while instructions
may be discussed as being executed by a processor, the instructions
may be executed simultaneously, serially, or otherwise by one or
multiple processors. The processor 1310 may be implemented as one
or more CPU chips.
[0129] The network connectivity devices 1320 may take the form of
modems, modem banks, Ethernet devices, universal serial bus (USB)
interface devices, serial interfaces, token ring devices, fiber
distributed data interface (FDDI) devices, wireless local area
network (WLAN) devices, radio transceiver devices such as code
division multiple access (CDMA) devices, global system for mobile
communications (GSM) radio transceiver devices, worldwide
interoperability for microwave access (WiMAX) devices, digital
subscriber line (xDSL) devices, data over cable service interface
specification (DOCSIS) modems, and/or other well-known devices for
connecting to networks. These network connectivity devices 1320 may
enable the processor 1310 to communicate with the Internet or one
or more telecommunications networks or other networks from which
the processor 1310 might receive information or to which the
processor 1310 might output information.
[0130] The network connectivity devices 1320 might also include one
or more transceiver components 1325 capable of transmitting and/or
receiving data wirelessly in the form of electromagnetic waves,
such as radio frequency signals or microwave frequency signals.
Alternatively, the data may propagate in or on the surface of
electrical conductors, in coaxial cables, in waveguides, in optical
media such as optical fiber, or in other media. The transceiver
component 1325 might include separate receiving and transmitting
units or a single transceiver. Information transmitted or received
by the transceiver component 1325 may include data that has been
processed by the processor 1310 or instructions that are to be
executed by processor 1310. Such information may be received from
and outputted to a network in the form, for example, of a computer
data baseband signal or signal embodied in a carrier wave. The data
may be ordered according to different sequences as may be desirable
for either processing or generating the data or transmitting or
receiving the data. The baseband signal, the signal embedded in the
carrier wave, or other types of signals currently used or hereafter
developed may be referred to as the transmission medium and may be
generated according to several methods well known to one skilled in
the art.
[0131] The RAM 1330 might be used to store volatile data and
perhaps to store instructions that are executed by the processor
1310. The ROM 1340 is a non-volatile memory device that typically
has a smaller memory capacity than the memory capacity of the
secondary storage 1350. ROM 1340 might be used to store
instructions and perhaps data that are read during execution of the
instructions. Access to both RAM 1330 and ROM 1340 is typically
faster than to secondary storage 1350. The secondary storage 1350
is typically comprised of one or more disk drives or tape drives
and might be used for non-volatile storage of data or as an
over-flow data storage device if RAM 1330 is not large enough to
hold all working data. Secondary storage 1350 may be used to store
programs that are loaded into RAM 1330 when such programs are
selected for execution.
[0132] The I/O devices 1360 may include liquid crystal displays
(LCDs), touch screen displays, keyboards, keypads, switches, dials,
mice, track balls, voice recognizers, card readers, paper tape
readers, printers, video monitors, or other well-known input/output
devices. Also, the transceiver 1325 might be considered to be a
component of the I/O devices 1360 instead of or in addition to
being a component of the network connectivity devices 1320.
[0133] Incorporated herein by reference as if reproduced in their
entirety are the following IETF internet drafts:
TABLE-US-00009
http://www.ietf.org/internet-drafts/draft-ietf-sip-session-policy-framewo-
rk- 05.txt
http://www.ietf.org/internet-drafts/draft-ietf-sipping-media-policy-datase-
t- 06.txt
http://www.ietf.org/internet-drafts/draft-ietf-sipping-config-framework-
15.txt
http://www.ietf.org/internet-drafts/draft-ietf-sipping-policy-package-05.t-
xt
[0134] Also incorporated herein by reference as if reproduced in
their entirety are the following 3GPP documents: RFC 2284, RFC
2661, RFC 3264, RFC 3265, RFC 3261, RFC 3312, RFC 3588, RFC 4282,
RFC 4482, RFC 4566, RFC 5108, RFC 5247, TS 23.203, TS 23.228, TS
23.229, and TS 24.229.
[0135] Also incorporated herein by reference as if reproduced in
their entirety are IEEE 802.11, IEEE 802.16, and IEEE 802.20.
[0136] In an embodiment, a method for sending a session policy
request to a network component is provided. The method comprises a
user agent sending the session policy request to the network
component using a lower layer protocol. The lower layer protocol is
at least one of Extensible Authentication Protocol (EAP), Point to
Point Protocol (PPP), and General Packet Radio Service (GPRS)
Activate Packet Data Protocol (PDP) context.
[0137] In an alternative embodiment, a user agent is provided. The
user agent comprises a processor configured to send a session
policy request to a network component using a lower layer protocol.
The lower layer protocol is at least one of Extensible
Authentication Protocol (EAP), Point to Point Protocol (PPP), and
General Packet Radio Service (GPRS) Activate Packet Data Protocol
(PDP) context.
[0138] In an alternative embodiment, a network component is
provided. The network component comprises an authentication
component configured to receive a session policy request sent a
lower layer protocol. The lower layer protocol is at least one of
Extensible Authentication Protocol (EAP), Point to Point Protocol
(PPP), and General Packet Radio Service (GPRS) Activate Packet Data
Protocol (PDP) context.
[0139] Additional information related to these topics can be found
in U.S. Provisional Patent Application No. 61/029,522, filed Feb.
18, 2008, by Andrew Allen, et al, entitled "System and Method for
Indicating Supported Session Policy URI Schemes Extensions" and in
U.S. Provisional Patent Application No. 61/029,523, filed Feb. 18,
2008, by Andrew Allen, et al, entitled "System and Method for
Resolving Extensions for the SIP Session Policy Framework," both of
which are incorporated herein by reference.
[0140] While several embodiments have been provided in the present
disclosure, it should be understood that the disclosed systems and
methods may be embodied in many other specific forms without
departing from the spirit or scope of the present disclosure. The
present examples are to be considered as illustrative and not
restrictive, and the intention is not to be limited to the details
given herein. For example, the various elements or components may
be combined or integrated in another system or certain features may
be omitted, or not implemented.
[0141] Also, techniques, systems, subsystems and methods described
and illustrated in the various embodiments as discrete or separate
may be combined or integrated with other systems, modules,
techniques, or methods without departing from the scope of the
present disclosure. Other items shown or discussed as coupled or
directly coupled or communicating with each other may be indirectly
coupled or communicating through some interface, device, or
intermediate component, whether electrically, mechanically, or
otherwise. Other examples of changes, substitutions, and
alterations are ascertainable by one skilled in the art and could
be made without departing from the spirit and scope disclosed
herein.
* * * * *
References