System and method for exchanging policy information in a roaming communications environment
An apparatus for optimizing roaming in a network environment is provided that includes a bearer manager operable to receive a registration request from a user. An identity of a visited network and access network information is included with the request, a bearer manager consulting the policy server for a policy decision as part of an IP-address assignment or mobile IP registration process. The policy server providing the assigned IP-address, a visited network provider identity and access network information to a home policy server via policy peering. The policy server authorizing the registration and remembering the identity of the visited network provider and the access network information, whereby when the user performs registration, an application manager can request authorization from the policy sever, which checks the identity of the visited network and possible the access network and determines whether to authorize the registration.
Latest Cisco Technology, Inc. Patents:
This Application claims priority under 35 U.S.C. §119 of provisional application No. 60/780,176 filed Mar. 6, 2006, entitled VERIZON WIRELESS MULTI-MEDIA PLUS (MMD+) PROGRAM SYSTEM ARCHITECTURE DOCUMENT. This Application also incorporates by reference that Provisional in its entirety.
TECHNICAL FIELD OF THE INVENTIONThis invention relates in general to the field of communications and, more particularly, to a system and a method for exchanging policy information in a roaming communications environment.
BACKGROUND OF THE INVENTIONNetworking architectures have grown increasingly complex in communications environments. In addition, the augmentation of clients or end users wishing to communicate in a network environment has caused many networking configurations and systems to respond by adding elements to accommodate the increase in networking traffic and the individualistic needs of new end users.
As the subscriber base of end users increases, proper routing and efficient management of communication sessions and data flows becomes even more critical. One significant area for any group of end users relates to peering and registration. The problem is particularly troubling in mobile service provider network architectures, where devices can roam from network to network.
Some solutions fail to properly account for all end users. For example, RFC 3455 defines P-Visited-Network-ID and the P-Access-Network-Info headers and associated procedures. However, these apply to SIP-based applications only and, further, are provided with various accompanying drawbacks. In addition, TIA-835-D defines a visited/home network based AAA RADIUS infrastructure and a Carrier-ID RADIUS attribute. This, however, is similarly flawed in that it applies to data (network level) access authentication only and does not allow for different roaming agreements at the application layer.
Thus, designing an effective network response for such roaming users provides a significant challenge to component manufacturers, system administrators, and network operators.
SUMMARY OF THE INVENTIONFrom the foregoing, it may be appreciated by those skilled in the art that a need has arisen for an improved communications approach that provides for an optimal response for one or more end users roaming in a network environment. In accordance with one embodiment of the present invention, a system and a method for providing an optimal information exchange in a communications environment are provided that greatly reduce disadvantages and problems associated with conventional network roaming techniques.
According to one embodiment of the present invention, an architecture for providing an optimal exchange for policy data is provided that includes a policy server operable to authorize a registration request from a user. An identity of a visited network is included with the request, a bearer manager consulting the policy server for a policy decision as part of an IP-address assignment or mobile IP registration process. The policy server providing both the assigned IP-address and a visited network provider to a home policy server via policy peering. The policy server authorizing the registration and remembering the identity of the visited network provider, whereby when the user performs application level registration, an application manager can request authorization from the policy sever, which checks the identity of the visited network and determines whether to authorize the application level registration. The registration request is via simple IP, Proxy Mobile IP, or Mobile IP on a Bearer Manager in the visited network or in a home network.
In more particular embodiments, specifically in a visited bearer manager scenario, the bearer manager includes the assigned IP-address with a policy request to the visited policy server, and the visited policy server furthermore includes the visited network identity in with a policy request to the home policy server. In a home bearer manager scenario, a Mobile IP Registration Request has visited network information appended by a visited bearer manager, which passes it to a home bearer manager, which contacts the policy server for a policy decision.
The authorization can also occur at time of call setup and, further, the authorization can allow emergency calls only.
In yet other embodiments, the authorization occurs when an application contacts the policy server for authorization to allow only some applications to be used when the user is roaming in certain provider networks. Access network information is provided using the Mobile IP and policy peering. Instead of using SIP signaling, information is passed as part of Mobile IP (MIP) registration requests from a visited to a home network, and also through policy events from the visited network to the home network.
In still other embodiments, through policy server peering, a home network can install policy facets into a visited network, which requests notifications on change in access network technologies or on location. Additionally, a home network can track access network information without requiring SIP signaling.
Some embodiments of the present invention may provide a number of technical advantages. For example, according to one embodiment of the present invention, a communications approach is offered that provides visited (roaming) network identity and access network information to the home network, irrespective of whether SIP is being used or not. This in turn enables a variety of location-based services to be provided. It also enables applications (SIP or non-SIP) to alter their behavior (and authorization) based on the visited network: for example, in allowing emergency calls only when roaming in certain networks.
Another potential advantage of certain embodiments of the present invention is that the proposed architectures enables visited (roaming) network identity and access network information to be used as input to the policy decision process for both SIP and non-SIP applications. For example, if an endpoint is on a known low-bandwidth access network, policy requests for high-bandwidth applications can be treated accordingly. Similarly, application requests where application level roaming agreements (such as for IMS/SIP) need to be enforced can have this done by the policy server. Other advantages are discussed below with reference to specific example call flows.
Note that certain embodiments of the present invention may enjoy some, all, or none of these advantages. Other technical advantages may be readily apparent to one skilled in the art from the following figure, description, and claims.
To provide a more complete understanding of the present invention and features and advantages thereof, reference is made to the following description, taken in conjunction with the accompanying figures, wherein like reference numerals represent like parts, in which:
In accordance with one embodiment of the present invention, communication system 10 uses policy server peering or appending Mobile IP messages to pass visited (roaming) network provider information and access network information to the home network. This data is stored in the home policy server and can be used to implement roaming policies for not only SIP, but also non-SIP applications. The current architecture can use policy server peering and MIP messages to pass access network information to the home network. There in the home network, such data is stored in the policy server and can be used as input to policy decisions for SIP and non-SIP applications. Communication system 10 also enables the information to be made generally available for all relevant SIP and non-SIP entities.
By implementing such a paradigm, communication system 10 provides visited (roaming) network identity and access network information to the home network and this benefit is independent of the protocol used (i.e. SIP or other protocols can be readily accommodated). In addition, communication system 10 enables a variety of location-based services to be provided. It also enables applications (SIP or non-SIP) to alter their behavior (and authorization) based on the visited network. For example, this ability would allow emergency calls only when roaming in certain networks.
Communication system 10 is also advantageous because it enables visited (roaming) network identity and access network information to be used as input to the policy decision process for both SIP and non-SIP applications. For example, if an endpoint is on a known low-bandwidth access network, policy requests for high-bandwidth applications can be treated accordingly. Similarly, application requests where application level roaming agreements (such as for IMS/SIP) need to be enforced can have this done by the policy server. Additional details related to specific flows are provided below with reference to
Access terminals (or ATs) are normally mobile devices, but the architecture provides for fixed device access as well. The terminals can access the network through a high-speed wireless data network, providing them with suitable IP connectivity. ATs can also access the network through CDMA or alternative mechanisms, such as WiFi or even 1xRTT data. In the case of EVDO Rev A, the RAN includes the RRM and the BTS. The RAN is responsible for providing layer-2 mobile access, Quality of Service (QoS) on the access network, mobility functions, and handoff services within the area of coverage for a particular RAN.
The RAN interfaces with the IPGW, which is the first IP component in the network. Its job, as the name implies, is to act as a gateway between the layer-2 RAN access and the IP layer-3 network. The IPGW is responsible for authentication of the mobile to the network. It accomplishes that through an EAP exchange with the mobile and the SM, which holds the keys. IPGW performs communications with the RAN using the A10, A11, and A12 interfaces defined in CDMA, handoff functions between RAN and between IPGW, and for facilitating registration of the mobile to the IP network, using Mobile IP v6 (MIPv6). MIPv6 is used as the primary mobility technology at layer-3, although the architecture does not change in any fundamental way with Mobile IPv4. The IPGW is also responsible for accounting and QoS functions for the packets it forwards.
Though the interfaces from the IPGW towards the RAN are RAN-specific, the interfaces from the IPGW towards the rest of the network are not. This allows for IPGW to be deployed whose access networks are based on other technologies, such as WiFi. Because the IPGW performs functions such as authentication, handoff, and context transfer in ways that are not access network specific, the network allows for roaming and handoff functions seamlessly across these different access network technologies.
Through the mobile IP registration procedures, the mobile can be connected to the Bearer Manager (BM), which acts as the IP anchor point and MIPv6 Home Agent (HA). Because of its role as the IP anchor point, the BM also serves as the natural enforcement point for a host of network policies, including QoS, accounting, and mobility. The BM also provides security functions, such as firewall, intrusion detection, and DDoS attack prevention. The BM provides Deep Packet Inspection (DPI) functions, which allow for detection of application layer traffic passing through the BM. The BM also acts as a repository for network presence, including the roaming states for the mobile, its cell site location, etc.
Co-resident with the BM is the Policy Server (PS), which is sometimes referred to as the Policy Manager (PM). The PS is responsible for implementing the operator policies that govern the way in which the underlying IP network (the IPGW, BM and RAN) is utilized in support of the applications that run on top of the network. To do that, the PS controls the BM and IPGW by providing it with policies, called facets, which the BM and IPGW execute. The PS is contacted by numerous elements in the network for decisions on how they should proceed, in cases where such decisions impact the underlying use of the IP network.
Since one of the primary purposes of the network is to support mobile voice services, the Session Initiation Protocol (SIP) plays a prominent role in the architecture. SIP is used between the mobile and the Application Manager (AM), which acts as the main SIP server in the network. The AM is responsible for basic SIP functions, such as SIP registration and SIP call routing. The AM provides the basic set of voice features, such as call forwarding and call screening. It is responsible for authorizing SIP calls to and from endpoints, and routing those calls to the right terminating component, whether it be another AM, a gateway to the PSTN, or a peer operator. The AM can use ENUM to facilitate the routing of calls between providers, and leverages configured routing tables to route calls to the PSTN. The AM is responsible for invocation of SIP-based application servers, which can provide services like IP centrex and Push-To-Talk. These application servers reside on top of the AM, and are accessed using the IMS Service Control (ISC) interface. The AM provides Service Capabilities Interaction Management (SCIM) functions, which perform feature interaction management amongst its internal features and ones invoked in application servers. The AM also interacts with the PS over a DIAMETER-based interface, informing it of SIP session requests so that the network can be properly configured to support those sessions in accordance with the providers policies. The AM also provides user presence services through SIP for Presence and Messaging Leveraging Extensions (SIMPLE).
Communication system 10 supports two different types of applications. One type is SIP-based applications. These application servers (AS) reside on top of the AM, using the ISC interface, and are invoked using SIP-based interactions. Communication System 10 also supports non-SIP applications. These applications are invoked directly by the AT (or through other triggers). However, access to these applications and coordination of underlying network resources in support of those applications is managed by the PS, to which the application server communicates. Indeed, the communications interface between the non-SIP AS and the PS is identical to the one between the AM and PS and can be based on DIAMETER.
Application servers can frequently need access to media processing functions, such as Interactive Voice Response (IVR), mixing functions, and messaging functions. Rather than have each application server implement these functions separately, they are extracted into a common set of servers, called media servers. These media servers represent coarse-grained application components that are not useful applications by themselves, but are useful when used by other applications. These servers are also known as service enablers.
Nearly all of the components in the network interface to the Security Manager (SM), also using a DIAMETER application, for example. The SM is the central access point for security services in the network. Authentication at all layers takes place through interactions with the SM, since the SM acts as the central repository and generation point for keying materials. The SM is the core of the Security Operations Center (SOC), which provides continuous management of threats in the network. The SM coordinates with the rest of the network to provide intrusion detection, network infrastructure security, establishment of traffic baselines, anomaly detection, etc. The SM owns the security policy for the network, pushing that security policy to various components, separately from the PS. This provides a clean separation between security and functional policies. The SM also performs posture assessment on mobiles, determining whether they can be permitted on the network, and with access to which services, based on the compliance of the mobile to standards for software compliance (such as OS versions, antivirus versions, etc.).
The Services Data Manager (SDM) acts as the central repository of subscriber data in the network. All components needing access to subscriber data, including AM, PS and application servers, obtain this data from the SDM, also using a DIAMETER application. Since numerous protocols and devices are used in the network, each with potentially different identifiers, the SDM acts as the repository for the subscriber data model, and is able to relate together the various identifiers used within the system. The SDM provides basic Create/Read/Update/Delete (CRUD) services on the data, and is responsible for highly reliable storage of the data. Caching is used extensively and SDM is responsible for providing network elements of updates to the data so that caches can be updated or invalidated. The SDM also serves as the repository of accounting records for subscriber usage on the network. These records are read by back-end billing systems for correlation and billing. The SDM also stores various pieces of non-subscriber data, such as PSTN routing logic. Provisioning systems interface with the SDM, pushing subscriber data into it and reading it out.
Interconnection with the PSTN is accomplished through traditional SIP-based PSTN gateways, whether composed or decomposed. The regulatory server provides an interface for installation of intercept orders from law enforcement agencies, and the collection of data from the network for delivery to law enforcement agencies.
Turning now to some of the problems that are being solved by the present invention, in current IMS-based architectures, part of the role of the I-CSCF and HSS is to authorize registrations. When a mobile registers, the P-CSCF inserts a P-Visited-Network-ID header [e.g., see RFC 3455] into the SIP REGISTER message identifying the visited network provider. The I-CSCF in the home network receives the REGISTER, extracts this header and passes it to the HSS. The HSS authorizes that this visited network identity is a valid roaming partner and that the user is authorized to roam there, and informs the I-CSCF of the result. The I-CSCF forwards the REGISTER to the S-CSCF if authorized, or rejects the request if not.
This mechanism suffers the drawback that it applies to roaming authorization for SIP only, and that it furthermore can only be used for registrations. There is no way to authorize the registration, but deny calls due to the identity of the roaming partner, or to authorize registrations of one or more other applications.
Similarly, TIA-835-D defines the Carrier-ID RADIUS attribute, which can be provided by the visited network AAA infrastructure to the home network AAA infrastructure during access network authentication in the visited network. This enables the home network to implement roaming restrictions at the network layer, however this suffers from limitations that are analogous to the current IMS solution. In particular, it does not allow for roaming restrictions to be applied at the application level: either the user endpoint is allowed access (and roaming access to all applications is inherently granted) or it is not (and access to all applications is inherently prohibited).
A second, but related, problem deals with access network information, which includes the type of network as well as location information for the user endpoint. In the IMS architecture, the P-CSCF conveys information about the type of network, cell location, etc in SIP messages towards the home network by use of the P-Access-Network-Info header [RFC 3455]. However, this mechanism applies to SIP only. It also presumes the existence of SIP messaging whenever such information changes, which is not always the case.
Communication system 10 addresses these problems, as well as others, in providing a generic solution to the problems cited above. In essence, communication system 10 leverages the notion that, in order to allow for different applications to have and to enforce different roaming agreements, policy and policy server peering is used instead of the IMS or legacy AAA infrastructure. Details about the proposed architecture are outlined below with reference to
Software and/or hardware may reside in policy server (30, 60/72) and/or bearer managers (e.g. 58 or 74) in order to achieve the teachings of the features of the present invention. For the Mobile IP part of the concept, the bearer manager adds the information in the MIP messages being sent by the V-BM to the H-BM. The V-BM in turn learns about the access network information from the IPGW.
Note that, due to their flexibility, these components may alternatively be equipped with (or include) any suitable component, device, application specific integrated circuit (ASIC), processor, microprocessor, algorithm, read-only memory (ROM) element, random access memory (RAM) element, erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), field-programmable gate array (FPGA), or any other suitable element or object that is operable to facilitate the operations thereof. Considerable flexibility is provided by the structure of policy server (30, 60/72) and/or bearer managers (e.g. 58 or 74) in the context of communications system 10 and, accordingly, they should be construed as such.
It should be noted that the internal structure of the system of
In regards to mobility, the policy server can make many decisions and install various facets related to mobility. Some of the decisions made by the PS include Roaming Authorization. When a subscriber roams, the PS can decide if the roaming operation is allowed. This can be based on the roaming partner, applications running for the subscriber, etc. A roaming authorization decision is made at the time of an IP-address assignment, Proxy Mobile IP registration or MIP registration, at which point the BM can ask the PS for a decision. Roaming policies can also be outsourced via facets installed into the BM at registration time.
The Mobility facets include Roaming. For example, instead of making a decision on roaming events as a subscriber moves, the policy server can compute a roaming facet and hand it to the BM. The roaming facet specifies, based on the identity of the roaming partner, whether or not roaming is permitted. Roaming facets can be used only when roaming decisions do not require any knowledge except for the identity of the roaming partner (and the subscriber identity of course).
Policy contexts are the set of states that the policy server uses to make decisions. A policy context can be thought of as a set of variables that the policy rules can check through comparisons (equality, greater-than, not-equal-to, etc.). There are generally two types of policy contexts: local or remote. A local policy context is a policy context that is actively stored and maintained by the PS. Events passed to the PS through questions from elements, or through simple event reports, update these policy contexts. Examples of local policy contexts include the set of SIP applications currently running (passed to the PS from the AM when it asks about proceeding with an application), the roaming network in which a subscriber resides (passed to the PS from the BM during MIP registration), and the time of day. Remote policy contexts are variables that, for various reasons, are not stored on the PS, but that the PS can “read” by doing a query to fetch the current value. One example of such a variable is the admission decision made in the RAN for a QoS request from the subscriber. These QoS requests are processed locally at the RAN, and the results told to the IPGW. They are not passed to the PS unless the authorization envelope has been exceeded. Another is the mode of the mobile, active or dormant. This information is also not normally passed to the policy server, unless an explicit request has been made by the PS to be informed of these changes. Much like configuration, policy contexts span mobility, access and connectivity, QoS, DPI, and accounting. They also include security and application policy contexts.
Mobility policy contexts can include Roaming Network Identity, which is the identity of the visited network provider. This is a local policy context, and is learned through both the access network login and the MIP registration process, where it is passed to the PS from the SM and BM respectively. The policy contexts can also include location. The location of the subscriber can be expressed as the serving IPGW and the serving cell identifier. The location helps in handling policies, which could indicate, whereby certain applications may be allowed only in certain regions for the subscriber. This is passed to the BM during IP-address assignment, Proxy Mobile IP or MIP registrations, and made available to the PS. The policy contexts can also include Subscriber Mode: active or idle or dormant, out of coverage. This is a context that is learnt via periodic updates about the subscriber.
Access policy contexts include Access Technology: the underlying technology used by the mobile, whether it is WiFi, 1xRTT, EVDO or others. This can be learned from the IPGW.
The location information regarding a subscriber can be structured into several parameters: the visited network, the region, the serving cell-identifier, the access-network type, and the geographic location of the subscriber in latitude/longitude. Information such as the cell-identifier is generally available and may be used towards the location of the subscriber, but it is very dependant on the cell size, the radius of coverage. The physical location information can be improved by additional techniques. The physical location of the subscriber depends on the type of device as well as the technology to identify the exact location. The location retrieval can occur via GPS enabled devices, or using network based techniques. GPS enabled devices can be queried to report the GPS information, and this information can be available regardless of the type of access (EVDO, WiFi, fixed network).
A location application can obtain information in two ways: by querying a mobile client directly, or by requesting the network. The location application can query GPS enabled devices directly to report the location information. In the absence of this information or to assist the information received via GPS, network based techniques can also be used. Network based techniques such as AFLT can be performed by the RAN, and this information can be reported to the network/location presence server in the BM. The location application can query the network/location presence server in the BM to request the location information for a given subscriber. The BM in turn sends this query to the RAN via the IPGW and obtains triangulation-based results for a subscriber. This information is then returned to the location application, along with additional network presence information.
The Bearer Manager can provide an open interface over which location, such as cell site for example, and presence information is made available.
Before turning to an example flow for communication system 10 in a given network, some preliminary information about a typical roaming protocol is provided. It is imperative to provide some overview as to the way in which the following invention operates. The following foundational information may be viewed as a basis from which the present invention may be properly explained. Such information is offered earnestly for purposes of explanation only and, accordingly, should not be construed in any way to limit the broad scope of the present invention and its potential applications.
When a user roams, some of the components of the architecture “split.” For each split component, some processing is being contributed by an instance of that component in the visited network, and some processing is being contributed by an instance in the home network. In communication system 10, the BM/PS and SM are split. The IPGW resides entirely in the visited network, and the SDM and AM reside entirely in the home network. In some cases, there may be local services provided in the visited network; those would involve the usage of an application server that resides entirely in the visited network.
The basic roaming procedure is as follows. The AT connects to the RAN in the visited network, and connects to its IPGW as its point of attachment. The IPGW proceeds to authenticate the AT using EAP procedures. The IPGW_passes the identity asserted by the mobile to the Visited SM (V-SM). The V-SM has no relationship with the subscriber. However, the identity of the subscriber is of the form user@domain. As such, the V-SM uses the domain part of the identifier to locate an SM in the home domain of the subscriber (the H-SM). This H-SM can either directly authenticate the client, and if not (because the client is served by a different H-SM), it can route the messaging to the correct H-SM. Authentication then proceeds as normal. At the end of the exchange, the IPGW knows the identity of the device, and if the device is integrated, of the subscriber. The EAP exchange can also provide the IPGW with the identity of several key services in the home network, including the BM and AM assigned to the subscriber in the home network.
At this point, the client obtains an address in the visited network. This may be obtained by the client using DHCP. The IPGW, on receipt of the DHCP query, uses ProxyMIP, and obtains an IP address from a V-BM. The IPGW selects a V-BM based on visited network policies. Since the visited network has no relationship with the subscriber, those policies are never subscriber specific. The V-BM contacts the V-PS for a policy decision regarding the registration. The V-PS contacts the H-PS for the subscriber by use of policy server peering, and includes the visited network identity and possibly access network information as part of the request. The H-PS can now make a policy decision based on the visited network identity, and possible access network information as well. If the H-PS allows the registration request in the visited network, it informs the V-PS of this, which in turn informs the V-BM of this. The V-BM then sends a ProxyMIP response to the IPGW, which includes the assigned IP-address. Once the IPGW obtains an address from the V-BM, this address is then provided to the AT in the DHCP response. The AT then proceeds with mobile IP procedures to obtain an address from the home BM. The AT can register its visited address (which it obtained via DHCP) as the point-of-attachment to the home BM. The MIP procedures require the mobile (in the case of IPv6) or the IPGW (in the case of IPv4) to provide the address of the H-BM. This identity was passed to the IPGW during the EAP authentication process, and then passed to the mobile in the DHCP reply. The V-BM can also pass other bootstrapping parameters to the AT in the DHCP reply. For example, the address of a configuration server for learning local dial plans is provided in the DHCP reply. When the AT sends the MIP request, the IPGW may append access network information to it, and the V-BM may append access network information and visited network identity information to the message, before forwarding it the H-BM. The H-BM upon receiving the MIP message interacts with the H-PS, and the H-BM may provide the supplied access network information and visited network identity information to the H-PS as part of this process, thereby enabling the H-PS to use this information for this and other policy requests related to the IP session.
By registering the visited address as the point-of-attachment, the bearer path towards the home BM can include the V-BM. This has the benefit of hiding mobility within the visited network from the home BM. MIP binding updates may not be needed until the AT moves to a different provider network entirely. This localization of mobility improves the performance of the network and reduces the load on the BM.
The H-BM can authenticate the mobile IP registration. That authentication can, for integrated clients, be based on keys derived from the EAP authentication, otherwise, it is based on a shared secret provisioned into the device for purposes of MIP authentication. In either case, the H-BM interacts with the H-SM to authenticate the MIP registration.
Both the V-BM and H-BM can contact their respective policy servers to obtain policies that apply to the subscriber. Obtaining these policies involves the usage of policy server peering.
Once the MIP registration completes, the mobile proceeds with SIP registration. The SIP REGISTER message is sent directly from the AT to the AM, which resides in the home network. The AT can know the AM address as a consequence of DHCP. If the AT is not integrated, its AM is known through configuration, since the AM is statically assigned to the subscriber. These procedures are equally applicable to IPv6 (in which case MIPv6 and PMIPv6 are used) and IPv4 (in which case PMIPv4 is used).
With regards to the roaming procedures, for Mobile IPv6, as part of the access authentication process, the Home Bearer Manager address is provided to the IPGW by the H-SM. The client receives a Visited Address via a DHCP exchange with an IPGW associated with its point of attachment. The assigned address is taken from a subnet that is ‘homed’ on a bearer manager in the same region as the IPGW where the client is attached. The Visited Bearer Manager is chosen based on regional configuration in the visited network. This address is termed the Visited Address. It is this address that is used as the Care of Address when establishing a mobility binding with a Home Bearer Manager.
Prior to informing the device of the Care of Address and the Home Bearer Manager, Proxy MIPv6 procedures are used to establish a bidirectional tunnel between the Visited Bearer Manager and the IPGW. This allows the Visited Bearer Manager to forward traffic destined to a given Care of Address via the correct IPGW. As a client's point of attachment changes, Proxy MIPv6 procedures are used to re-register the client via the new point of attachment.
When the PMIPv6 procedures are complete, the DHCP response, containing the Visited Address, Home Bearer Manager address and home AM address is sent to the client. The IPv6 client then initiates a MIPv6 binding with the Home Bearer Manager. The Care of Address supplied in the MIPv6 Binding Request is the address assigned to the client by the Visited Bearer Manager. This binding initiation is routed to the Home Bearer Manager via the Visited Bearer Manager. The Home Bearer Manager authenticates the subscriber identifier with the H-SM. Successful authentication results in the Home Bearer Manager sending a Binding Acknowledgement and assigning an IPv6 address to the client from a subnet ‘homed’ at the Home Bearer Manager. Subscriber policy can be fetched at this time.
As the Care of Address is owned by the Visited BM, the binding response can be routed to the Visited BM from the Home BM. The previous PMIPv6 sequence ensures that the Visited BM can forward the Binding Acknowledgement to the client via the correct IPGW.
The device now has an IPv6 address assigned by the Home Bearer Manager and an IPv6 Care of Address associated with the Visited Bearer Manager. A tunnel exists between the Visited Bearer Manager and the IPGW to ensure that the Visited Bearer Manager can ‘see’ the bearer and control paths and can enforce visited network policy. For Mobile IPv4, the steps taken are very similar to those for the IPv6 client. Indeed, it is an objective of the design that the architecture not fundamentally differ between v4 and v6. A Home Bearer Manager for the client is assigned as part of the Access Authentication procedures. A visited address is assigned using DHCP procedures, a tunnel is established between the IPGW and Visited Bearer Manager using Proxy registration techniques and then a mobility binding established between the client and a Home Bearer Manager, Similar to the IPv6 case, DHCP is used for visited address assignment.
The authentication steps are identical to those for MIPv6. Following successful access authentication, a Proxy Registration establishes a mobility binding with the Visited Bearer Manager on behalf of the client. The Visited Bearer Manager is chosen based on regional configuration. The Visited Bearer Manager assigns an IP address to the client, this being returned to the IPGW as part of mobility binding establishment.
The AT sends a DHCP Discover message to the IPGW, and the Visited Address is provided to the client in a DHCP Acknowledgement message. The DHCP acknowledgement can also contain the Home BM address and the home AM address. The Visited Bearer Manager sends a Foreign Agent Advertisement to the client via the IPGW.
The receipt of the Foreign Agent advertisement informs the client that the Foreign Agent for MIPV4 registration can be the V-BM. The client sends a MIPv4 Registration Request containing the Subscriber ID to the V-BM via the IPGW. The Registration Request is addressed to the V-BM. The Home Agent address field contains the address of the Home Bearer Manager identified in the DHCP Acknowledgement.
The V-BM, functioning as a MIPv4 Foreign Agent, sends the Registration Request to the Home Bearer Manager. The Care-of-Address in the MIPv4 Registration Request is the address of the Visited Bearer Manager. As the client has been assigned an address for which the Visited Bearer Manager acts as the Foreign Agent, all packets destined to the client traverse the Visited Bearer Manager. Hence, visited network policy can be applied at the Visited Bearer Manager. All traffic sent from the client is sent to the Visited Bearer Manager via the tunnel established between the IPGW and Visited Bearer Manager using the Proxy Mobility Registration procedures described above. This ensures that all traffic from the client is subject to visited network policy.
Layer-3 authentication of the Subscriber based on the subscriber ID is performed at the Home Bearer Manager, where a Home Address is assigned. The Home Address is returned in the MIPv4 Registration Reply, and that reply is sent to the Care-of-Address contained in the MIPv4 Registration Request. The Registration Reply is sent to the IPGW from the visited Bearer Manager and forwarded to the client. As a result of the Registration Request/Reply exchange, a path is established between the Home Bearer Manager and the Client. This path comprises a sequence of fixed paths, a Home Bearer Manager—Visited Bearer Manager path, the Visited Bearer Manager—IPGW path and the IPGW—Client path.
The device has an IPv4 address assigned by the Home Bearer Manager and a IPv4 Visited Address associated with the Visited Bearer Manager. A tunnel exists between the Visited Bearer Manager and the IPGW to ensure that the Visited Bearer Manager can ‘see’ the bearer and control paths and can enforce visited network policy Turning now to the features of the present invention,
In either case, at step 102, the Bearer Manager can consult the policy manager for a policy decision as part of the IP-address assignment or mobile IP registration process. In the visited bearer manager case, the bearer manager includes the assigned IP-address with the policy request to the policy manager, and the policy manager provides both the assigned IP-address and the visited network entity to the home policy server via policy peering. In the home bearer manager case, the Mobile IP Registration Request (or Binding Update) has the visited network information appended by the V-BM, which passes it to the H-BM, which again contacts the PM for a policy decision. This is illustrated by step 104.
In either case, the PM authorizes the IP or MIP registration and remembers the identity of the visited network provider for this subscriber/IP-address at step 106. When the subscriber performs his SIP registration, the AM (e.g., S-CSCF) can request authorization from the PM. The PM checks the identity of the visited network and authorizes or not the registration. Such authorization can also occur at time of call setup, e.g. to allow emergency calls only, or at the time any other application contacts the PM for authorization, e.g. to allow only some applications to be used when the user is roaming in certain provider networks. This is illustrated by step 108.
Access network information is provided using a similar strategy. Instead of using SIP signaling (or potentially AAA infrastructure) for this, the information is rather passed as part of MIP registration requests (or binding updates) from the visited to the home network, and also through policy events from visited to home network (the V-PS may learn about this via policy messages from the V-BM). When the UE changes its BM in the visited network, a MIP registration request (or binding update) is sent which conveys the identity of the new BM, provider identity and corresponding access network information (by the V-BM adding this information to the MIP registration request or binding update). Furthermore, through policy server peering, the home network can install policy facets into the visited network, which requests notifications from the visited network on change in access network technologies or location. The V-BM can delegate these facets to the IPGW. When the V-BM or IPGW in the visited network see a change, the H-PM (via the V-PM) is informed. Thus, the home network can now track access network information (such as access network type, location information in the form of cell sector ID or other, etc.) without requiring SIP signaling initiated from the mobile. Furthermore, access network information can now be made generally available (via the PM or the BM itself) to other (non-SIP) entities.
Some of the steps discussed with reference to
Although the present invention has been described in detail with reference to particular embodiments, communications system 10 may be extended to any scenario in which end user 12 is provided with call options in the context of a wired or a wireless connection or coupling. This may also be extended to any other network signaling protocols to achieve the teachings of the present invention.
Moreover, significant flexibility is provided by communications system 10 in that any suitable one or more components may be replaced with other components that facilitate their operations.
Additionally, although described in specific environments and contexts, the present invention could be used in countless applications. Numerous other changes, substitutions, variations, alterations, and modifications may be ascertained by those skilled in the art and it is intended that the present invention encompass all such changes, substitutions, variations, alterations, and modifications as falling within the spirit and scope of the appended claims. Moreover, the present invention is not intended to be limited in any way by any statement in the specification that is not otherwise reflected in the appended claims.
Claims
1. An apparatus for optimizing roaming in a network environment, comprising:
- a visited policy server consulted by a visited bearer manager of a visited network visited by an access terminal, the visited policy server configured to: receive a policy request from the visited bearer manager requesting a policy decision in response to the access terminal attempting a registration in the visited network via a registration request, the policy request comprising an assigned IP-address, a subscriber geographic location, and a visited network identity; provide the assigned IP-address, the subscriber geographic location, and the visited network identity to a home policy server via policy peering, the home policy server belonging to a home network of the access terminal; receive authorization from the home policy server authorizing the registration for the access terminal; authorize the registration for the access terminal in the visited network; receive an authorization request from an application manager requesting authorization for the access terminal to use a particular application in the visited network in response to the access terminal performing application level registration; receive authorization from the home policy server allowing the access terminal use of a first application for the subscriber geographic location in the visited network and denying use of a second application for the subscriber geographic location in the visited network; and authorize the application level registration based on the subscriber geographic location in the visited network and only when the application level registration is allowed for the subscriber geographic location in the visited network, the authorization allowing use of the first application at the subscriber geographic location in the visited network and denying use of the second application at the subscriber geographic location in the visited network.
2. The apparatus of claim 1, wherein the registration request is via simple IP, Proxy Mobile IP, or Mobile IP on a Bearer Manager in the visited network or in the home network.
3. The apparatus of claim 1, wherein in a visited bearer manager scenario, the visited bearer manager includes the assigned IP-address with the policy request to the visited policy server.
4. The apparatus of claim 1, wherein in a home bearer manager scenario, a Mobile IP Registration Request has visited network information appended by the visited bearer manager, which passes it to a home bearer manager, which contacts the home policy server for a policy decision, wherein the request to the home policy server includes the visited network information and assigned IP-address.
5. The apparatus of claim 1, wherein the authorization of the application level registration can also occur at time of call setup.
6. The apparatus of claim 5, wherein the authorization of the application level registration allows emergency calls only.
7. The apparatus of claim 1, wherein the authorization of the application level registration occurs when the application manager contacts the visited policy server for authorization to allow only some applications to be used when the access terminal is roaming in certain provider networks.
8. The apparatus of claim 1, wherein access network information is provided using the policy peering, and wherein the access network information is passed from the IP gateway to the visited bearer manager via PMIP or policy, and from the visited bearer manager to the visited policy manager via policy.
9. The apparatus of claim 8, wherein instead of using SIP signaling, information is passed as part of MIP registration requests or MIP binding updates from the visited to the home network, and also through policy events from the visited network to the home network.
10. The apparatus of claim 1, wherein through policy server peering, the home network can install policy facets into the visited network, which requests notifications on change in access network technologies or on location.
11. The apparatus of claim 1, wherein the home network can track access network information without requiring SIP signaling.
12. A method for optimizing roaming in a network environment, comprising:
- receiving at a visited policy server a policy request from a visited bearer manager requesting a policy decision in response to an access terminal attempting a registration in the visited network via a registration request, the policy request comprising an assigned IP-address, a subscriber geographic location, and a visited network identity, the visited policy server and the visited bearer manager belonging to a visited network visited by an access terminal;
- providing the assigned IP-address, the subscriber geographic location, and the visited network identity to a home policy server via policy peering, the home policy server belonging to a home network of the access terminal;
- receiving authorization from the home policy server authorizing the registration for the access terminal;
- authorizing the registration for the access terminal in the visited network;
- receiving an authorization request from an application manager requesting authorization for the access terminal to use a particular application in the visited network in response to the access terminal performing application level registration;
- receiving authorization from the home policy server allowing the access terminal use of a first application for the subscriber geographic location in the visited network and denying use of a second application for the subscriber geographic location in the visited network; and
- authorizing the application level registration based on the subscriber geographic location in the visited network and only when the application level registration is allowed for the subscriber geographic location in the visited network, the authorization allowing use of the first application at the subscriber geographic location in the visited network and denying use of the second application at the subscriber geographic location in the visited network.
13. The method of claim 12, wherein the registration request is via simple IP, Proxy Mobile IP or Mobile IP on a Bearer Manager in the visited network or in the home network.
14. The method of claim 12, wherein in a visited bearer manager scenario, the visited bearer manager includes the assigned IP-address with the policy request to the visited policy server.
15. The method of claim 12, wherein in a home bearer manager scenario, a Mobile IP Registration Request or Mobile IP Binding Update has visited network information appended by the visited bearer manager, which passes it to a home bearer manager, which contacts the home policy server for a policy decision, and where the request to the home policy server includes the visited network information and assigned IP-address.
16. The method of claim 12, wherein the authorization of the application level registration can also occur at time of call setup.
17. The method of claim 16, wherein the authorization of the application level registration allows emergency calls only.
18. The method of claim 12, wherein the authorization of the application level registration occurs when the application manager contacts the visited policy server for authorization to allow only some applications to be used when the access terminal is roaming in certain provider networks.
19. The method of claim 12, wherein access network information is provided using the policy peering, and wherein the access network information is passed from the IP gateway to the visited bearer manager via PMIP or policy, and from the visited bearer manager to the visited policy manager via policy.
20. The method of claim 19, wherein instead of using SIP signaling, information is passed as part of MIP registration requests or MIP binding updates from the visited to the home network, and also through policy events from the visited network to the home network.
21. The method of claim 12, wherein through policy server peering, the home network can install policy facets into the visited network, which requests notifications on change in access network technologies or on location.
22. The method of claim 12, wherein the home network can track access network information without requiring SIP signaling.
23. Software for optimizing roaming in a network environment, the software being embodied in a non-transitory computer readable medium and comprising code such that when executed is operable to:
- receive at a visited policy server a policy request from a visited bearer manager requesting a policy decision in response to an access terminal attempting a registration in the visited network via a registration request, the policy request comprising an assigned IP-address, a subscriber geographic location, and a visited network identity, the visited policy server and the visited bearer manager belonging to a visited network visited by an access terminal;
- providing the assigned IP-address, the subscriber geographic location, and the visited network identity to a home policy server via policy peering, the home policy server belonging to a home network of the access terminal;
- receive authorization from the home policy server authorizing the registration for the access terminal;
- authorize the registration for the access terminal in the visited network;
- receive an authorization request from an application manager requesting authorization for the access terminal to use a particular application in the visited network in response to the access terminal performing application level registration;
- receive authorization from the home policy server allowing the access terminal use of a first application for the subscriber geographic location in the visited network and denying use of a second application for the subscriber geographic location in the visited network; and
- authorize the application level registration based on the subscriber geographic location in the visited network and only when the application level registration is allowed for the subscriber geographic location in the visited network, the authorization allowing use of the first application at the subscriber geographic location in the visited network and denying use of the second application at the subscriber geographic location in the visited network.
24. The software of claim 23, wherein the registration request is via simple IP, Proxy Mobile IP, or Mobile IP on a Bearer Manager in the visited network or in the home network.
25. The software of claim 23, wherein in a visited bearer manager scenario, the visited bearer manager includes the assigned IP-address with the policy request to the visited policy server.
26. The software of claim 23, wherein in a home bearer manager scenario, a Mobile IP Registration Request or MIP Binding Update has visited network information appended by the visited bearer manager, which passes it to a home bearer manager, which contacts the home policy server for a policy decision, and where the request to the home policy server includes the visited network information and assigned IP-address.
27. The software of claim 23, wherein the authorization of the application level registration can also occur at time of call setup, and wherein the authorization allows emergency calls only.
28. The software of claim 23, wherein the authorization of the application level registration occurs when the application manager contacts the visited policy server for authorization to allow only some applications to be used when the access terminal is roaming in certain provider networks.
29. The software of claim 23, wherein access network information is provided using the policy peering, and wherein the access network information is passed from the IP gateway to the visited bearer manager via PMIP or policy, and from the visited bearer manager to the visited policy manager via policy.
30. The software of claim 29, wherein instead of using SIP signaling, information is passed as part of MIP registration requests or binding updates from the visited to the home network, and also through policy events from the visited network to the home network.
31. The software of claim 23, wherein through policy server peering, the home network can install policy facets into the visited network, which requests notifications on change in access network technologies or on location.
32. The software of claim 23, wherein the home network can track access network information without requiring SIP signaling.
5602907 | February 11, 1997 | Hata et al. |
5822411 | October 13, 1998 | Swale et al. |
5828737 | October 27, 1998 | Sawyer |
5905736 | May 18, 1999 | Ronen et al. |
5909238 | June 1, 1999 | Nagashima et al. |
5946670 | August 31, 1999 | Motohashi et al. |
5956391 | September 21, 1999 | Melen et al. |
5970477 | October 19, 1999 | Roden |
5987498 | November 16, 1999 | Athing et al. |
6016509 | January 18, 2000 | Dedrick |
6035281 | March 7, 2000 | Crosskey et al. |
6047051 | April 4, 2000 | Ginzboorg et al. |
6070192 | May 30, 2000 | Holt et al. |
6075854 | June 13, 2000 | Copley et al. |
6131024 | October 10, 2000 | Boltz |
6137791 | October 24, 2000 | Frid et al. |
6141684 | October 31, 2000 | McDonald et al. |
6175879 | January 16, 2001 | Shah et al. |
6208977 | March 27, 2001 | Hernandez et al. |
6229887 | May 8, 2001 | Albers et al. |
6282573 | August 28, 2001 | Darago et al. |
6295447 | September 25, 2001 | Reichelt et al. |
6330562 | December 11, 2001 | Boden et al. |
6332163 | December 18, 2001 | Bowman-Amuah |
6339832 | January 15, 2002 | Bowman-Amuah |
6434568 | August 13, 2002 | Bowman-Amuah |
6434628 | August 13, 2002 | Bowman-Amuah |
6438594 | August 20, 2002 | Bowman-Amuah |
6442748 | August 27, 2002 | Bowman-Amuah |
6466964 | October 15, 2002 | Leung et al. |
6477580 | November 5, 2002 | Bowman-Amuah |
6477665 | November 5, 2002 | Bowman-Amuah |
6480485 | November 12, 2002 | Kari et al. |
6490451 | December 3, 2002 | Denman et al. |
6493547 | December 10, 2002 | Raith |
6496850 | December 17, 2002 | Bowman-Amuah |
6502213 | December 31, 2002 | Bowman-Amuah |
6529909 | March 4, 2003 | Bowman-Amuah |
6529948 | March 4, 2003 | Bowman-Amuah |
6539396 | March 25, 2003 | Bowman-Amuah |
6549949 | April 15, 2003 | Bowman-Amuah |
6550057 | April 15, 2003 | Bowman-Amuah |
6571282 | May 27, 2003 | Bowman-Amuah |
6578068 | June 10, 2003 | Bowman-Amuah |
6601192 | July 29, 2003 | Bowman-Amuah |
6601234 | July 29, 2003 | Bowman-Amuah |
6606660 | August 12, 2003 | Bowman-Amuah |
6611821 | August 26, 2003 | Stahl et al. |
6615199 | September 2, 2003 | Bowman-Amuah |
6615253 | September 2, 2003 | Bowman-Amuah |
6615263 | September 2, 2003 | Dulai et al. |
6621820 | September 16, 2003 | Williams et al. |
6636242 | October 21, 2003 | Bowman-Amuah |
6640238 | October 28, 2003 | Bowman-Amuah |
6640244 | October 28, 2003 | Bowman-Amuah |
6647262 | November 11, 2003 | Demetrescu et al. |
6665537 | December 16, 2003 | Lioy |
6665718 | December 16, 2003 | Chuah et al. |
6671510 | December 30, 2003 | Kelly et al. |
6671675 | December 30, 2003 | Iwamura |
6684243 | January 27, 2004 | Euget et al. |
6684256 | January 27, 2004 | Warrier et al. |
6708225 | March 16, 2004 | Cho et al. |
6714515 | March 30, 2004 | Marchand |
6715145 | March 30, 2004 | Bowman-Amuah |
6725036 | April 20, 2004 | Faccin et al. |
6728266 | April 27, 2004 | Sabry et al. |
6728884 | April 27, 2004 | Lim |
6742015 | May 25, 2004 | Bowman-Amuah |
6742036 | May 25, 2004 | Das et al. |
6757371 | June 29, 2004 | Kim et al. |
6760444 | July 6, 2004 | Leung |
6768726 | July 27, 2004 | Dorenbosch et al. |
6769000 | July 27, 2004 | Akhtar et al. |
6771623 | August 3, 2004 | Ton |
6785256 | August 31, 2004 | O'Neill |
6804518 | October 12, 2004 | Core et al. |
6826173 | November 30, 2004 | Kung et al. |
6829709 | December 7, 2004 | Acharya et al. |
6834341 | December 21, 2004 | Bahl et al. |
6839338 | January 4, 2005 | Amara et al. |
6842906 | January 11, 2005 | Bowman-Amuah |
6854014 | February 8, 2005 | Amin et al. |
6856676 | February 15, 2005 | Pirot et al. |
6889321 | May 3, 2005 | Kung et al. |
6907501 | June 14, 2005 | Tariq et al. |
6910074 | June 21, 2005 | Amin et al. |
6915345 | July 5, 2005 | Tummala et al. |
6917605 | July 12, 2005 | Kakemizu et al. |
6920503 | July 19, 2005 | Nanji et al. |
6922404 | July 26, 2005 | Narayanan et al. |
6925160 | August 2, 2005 | Stevens et al. |
6947401 | September 20, 2005 | El-Malki et al. |
6961774 | November 1, 2005 | Shannon et al. |
6967941 | November 22, 2005 | Roy |
6978128 | December 20, 2005 | Raman et al. |
6980802 | December 27, 2005 | Jung |
6980962 | December 27, 2005 | Arganbright et al. |
6981047 | December 27, 2005 | Hanson et al. |
6982967 | January 3, 2006 | Leung |
6990337 | January 24, 2006 | O'Neill et al. |
6993333 | January 31, 2006 | Laroia et al. |
7003294 | February 21, 2006 | Singhai et al. |
7020697 | March 28, 2006 | Goodman et al. |
7024687 | April 4, 2006 | Chaudhuri et al. |
7028311 | April 11, 2006 | Roach et al. |
7039027 | May 2, 2006 | Bridgelall |
7054268 | May 30, 2006 | Parantainen et al. |
7079499 | July 18, 2006 | Akhtar et al. |
7082301 | July 25, 2006 | Jagadeesan et al. |
7103359 | September 5, 2006 | Heinonen et al. |
7127234 | October 24, 2006 | Ishii |
7130286 | October 31, 2006 | Koodli et al. |
7133386 | November 7, 2006 | Holur et al. |
7151758 | December 19, 2006 | Kumaki et al. |
7151772 | December 19, 2006 | Kalmanek et al. |
7154868 | December 26, 2006 | Sharma et al. |
7161914 | January 9, 2007 | Shoaib et al. |
7171555 | January 30, 2007 | Salowey et al. |
7184418 | February 27, 2007 | Baba et al. |
7187931 | March 6, 2007 | Trossen |
7190793 | March 13, 2007 | Hsu |
7197763 | March 27, 2007 | Hsu |
7212821 | May 1, 2007 | Laroia et al. |
7230951 | June 12, 2007 | Mizell et al. |
7233583 | June 19, 2007 | Asthana et al. |
7251733 | July 31, 2007 | Haverinen et al. |
7263371 | August 28, 2007 | Das et al. |
7269727 | September 11, 2007 | Mukherjee et al. |
7272122 | September 18, 2007 | Trossen et al. |
7272123 | September 18, 2007 | Wall |
7275156 | September 25, 2007 | Balfanz et al. |
7389106 | June 17, 2008 | Dawson et al. |
20010023428 | September 20, 2001 | Miyazaki et al. |
20020021681 | February 21, 2002 | Madour |
20020023174 | February 21, 2002 | Garrett et al. |
20020036982 | March 28, 2002 | Chen |
20020059114 | May 16, 2002 | Cockrill et al. |
20020091802 | July 11, 2002 | Paul et al. |
20020138601 | September 26, 2002 | Piponius et al. |
20020151312 | October 17, 2002 | Bos et al. |
20030021252 | January 30, 2003 | Harper et al. |
20030039237 | February 27, 2003 | Forslow |
20030154400 | August 14, 2003 | Pirttimaa et al. |
20030217165 | November 20, 2003 | Buch et al. |
20040114553 | June 17, 2004 | Jiang et al. |
20040162876 | August 19, 2004 | Kohavi |
20040162892 | August 19, 2004 | Hsu |
20040196821 | October 7, 2004 | Haddad et al. |
20040210524 | October 21, 2004 | Benenati et al. |
20040259562 | December 23, 2004 | Madour |
20050002407 | January 6, 2005 | Shaheen et al. |
20050025132 | February 3, 2005 | Harper et al. |
20050130659 | June 16, 2005 | Grech et al. |
20050149651 | July 7, 2005 | Doak et al. |
20050176428 | August 11, 2005 | Gabor et al. |
20050195766 | September 8, 2005 | Nasielski et al. |
20050201324 | September 15, 2005 | Zheng |
20050213606 | September 29, 2005 | Huang et al. |
20050220039 | October 6, 2005 | Hoshino et al. |
20050278420 | December 15, 2005 | Hartikainen et al. |
20050286709 | December 29, 2005 | Horton et al. |
20060014547 | January 19, 2006 | Walter |
20060018272 | January 26, 2006 | Mutikainen et al. |
20060077924 | April 13, 2006 | Rune |
20060116113 | June 1, 2006 | Gass |
20060126630 | June 15, 2006 | Shirazipour et al. |
20060171310 | August 3, 2006 | Ahluwalia et al. |
20060203791 | September 14, 2006 | Carrion-Rodrigo et al. |
20060251038 | November 9, 2006 | Tamura et al. |
20060264207 | November 23, 2006 | Tamura et al. |
20060268819 | November 30, 2006 | Chen et al. |
20070008882 | January 11, 2007 | Oran |
20070036312 | February 15, 2007 | Cai et al. |
20070086582 | April 19, 2007 | Tai et al. |
20070094712 | April 26, 2007 | Gibbs et al. |
20070121615 | May 31, 2007 | Weill et al. |
20070121642 | May 31, 2007 | Battin et al. |
20070153720 | July 5, 2007 | Baglin et al. |
20070254661 | November 1, 2007 | Chowdhury et al. |
WO 98/26381 | December 1997 | WO |
WO 99/31610 | December 1998 | WO |
WO 2005/107297 | November 2005 | WO |
- Draft—TR45—PN-3-4732-RV4 (to be published as TIA-835.1-D), 32 pages.
- Draft—TR45—PN-3-4732-RV4 (to be published as TIA-835.2-D), 93 pages.
- Draft—TR45—PN-3-4732-RV4 (to be published as TIA-835.3-D), 36 pages.
- Draft—TR45—PN-3-4732-RV4 (to be published as TIA-835.4-D), 70 pages.
- Draft—TR45—PN-3-4732-RV4 (to be published as TIA-835.5-D), 72 pages.
- Draft—TR45—PN-3-4732-RV4 (to be published as TIA-835.6-D), 36 pages.
- 3GPP2 C.S0067, 3rd Generation Partnership Project 2 ‘3GPP2’, “Generic Key Exchange Protocol for cdma2000 High Rate Packet Data Air Interface,” Version 1.0, 24 pages, Nov. 2005.
- 3GPP2 X.S0011-001-D, 3rd Generation Partnership Project 2 ‘3GPP2’, “cdma2000 Wireless IP Network Standard: Introduction,” Version 1.0, 33 pages, Feb. 2006.
- 3GPP2 C.S0063-0, 3rd Generation Partnership Project 2 ‘3GPP2’, “cdma2000 High Rate Packet Data Supplemental,” Version 1.0, 127 pages, Mar. 2006.
- 3GPP2 A.S0008-A v.1.0, 3rd Generation Partnership Project 2 ‘3GPP2,’ Interoperability Specification (IOS) for High Rate Packet Data (HRPD) Radio Access Network Interfaces with Session Control in the Access Network, 257 pages, Mar. 2006.
- 3GPP2 C.S0024-A, 3rd Generation Partnership Project 2 ‘3GPP2’, “cdma2000 High Rate Packet Data Air Interface Specification,” Version 2.0, 1,223 pages, Jul. 2005.
- B. Aboba, et al., “Extensible Authentication Protocol (EAP),” Network Working Group, RFC 3748, http://www.ietf.org/rfc/rfc3748.txt, 59 pages, Jun. 2004.
- B. Aboba, D. Simon, “PPP EAP TLS Authentication Protocol,” Network Working Group, RFC 2716, http://www.ietf.org/rfc/rfc2716.txt, 22 pages, Oct. 1999.
- W. Simpson, “PPP Challenge Handshake Authentication Protocol (CHAP),” Network Working Group, RFC 1994, http://www.ietf.org/rfc/rfc1994.txt, 12 pages, Aug. 1996.
- W. Simpson, “The Point-to-Point (PPP),” Network Working Group, RFC 1661, http://www.ietf.org/rfc/rfc1661.txt, 47 pages, Jul. 1994.
- P. Eronen, et al., “Diameter Extensible Authentication Protocol (EAP) Application,” Network Working Group, RFC 4072, http://www.ietf.org/rfc/rfc4072.txt, 29 pages, Aug. 2005.
- P. Calhoun, et al., “Diameter Base Protocol,” Network Working Group, RFC 3588, http://www.ietforg/rfc/rfc3588.txt, 129 pages, Sep. 2003.
- 3rd Generation Partnership Project 2 “3GPP2”; “All-IP Core Network Multimedia Domain: Service Based Bearer Control—Stage 2;www.3gpp2.org-”; Version 1.0. Draft Version 0.21.0, 49 pages.
- PCT Notification of Transmittal of the International Search Report and the Written Opinion of the International Searching Authority, or the Declaration, International Application No. PCT/US07/05847, 9 pages, Oct. 26, 2007.
- PCT Notification of Transmittal of the International Search Report and the Written Opinion of the International Searching Authority, or the Declaration, International Application No. PCT/US07/05849, 9 pages, Nov. 14, 2007.
- Yegani et al., “System and Method for Access Authentication in a Mobile Wireless Network,” U.S. Appl. No. 11/419,382, 20 pps, 3 pps drawings, filed May 19, 2006.
- Yegani et al., “System and Method for Handover of an Access Terminal in a Communication Network,” U.S. Appl. No. 11/682,735, 24 pps, 3 pps drawings, filed Mar. 6, 2007.
- Yegani et al., “Enforcement of User Level Policies from Visited Networks in a Mobile IP Environment,” U.S. Appl. No. 11/682,817, 22 pps, 2 pps drawings, filed Mar. 6, 2007.
- Yegani et al, Authentication of Access Terminals in a Cellular Communication Network,: U.S. Appl. No. 11/682,857, 28 pps, 5 pps drawings, filed Mar. 6, 2007.
- Andreasen et al., “System and Method of Consolidating Accounting Data for a Communication Session,” U.S. Appl. No. 11/714,974, 40 pps, 3 pps drawings, filed Mar. 6, 2007.
- Panda et al., “System and Method for Capturing Accounting Data for a Communication Session,” U.S. Appl. No. 11/715,018, filed Mar. 6, 2007.
- Rosenberg et al., “System and Method for Determining a Network for Processing Applications for a Communication Session,” U.S. Appl. No. 11/715,019, 40 pps, 3 pps drawings, filed Mar. 6, 2007.
- Rosenberg et al., “Determining a Policy Output for a Communication Session,” U.S. Appl. No. 11/715,032, 31 pps, 4 pps drawings, filed Mar. 6, 2007.
- Leung et al., “Communicating Packets Using a Home Anchored Bearer Path,” U.S. Appl. No. 11/715,033, 33 pps, 4 pps drawings, filed Mar. 6, 2007.
- Andreasen et al., “Posture-Based Network Authentication,” U.S. Appl. No. 11/715,040, 23 pages, 2 pps drawings, filed Mar. 6, 2007.
- Iyer et al., “Access Terminal for Communicating Packets Using a Home Anchored Bearer Path,” U.S. Appl. No. 11/715,041, 33 pps, 4 pps drawings, filed Mar. 6, 2007.
- Rosenberg et al., “Establishing Facets of a Policy for a Communication Session,” U.S. Appl. No. 11/715,065, 32 pps, 4 pps. drawings, filed Mar. 6, 2007.
- Rosenberg et al., “Performing Deep Packet Inspection for a Communication Session,” U.S. Appl. No. 11/715,073, 31 pps, 4 pps drawings, filed Mar. 6, 2007.
- Rosenberg et al., “Assigning a Serving—CSCF During Access Authentication,” U.S. Appl. No. 11/715,074, 22 pps, 2 pps drawings, filed Mar. 6, 2007.
- Rosenberg et al., “System and Method for Providing Emergency Services in a Visited Communications Environment,” U.S. Appl. No. 11/715,111, 39 pps, 2 pps drawings, filed Mar. 6, 2007.
- Panda et al., “Application-Aware Policy Enforcement,” U.S. Appl. No. 11/715,187, 28 pps, 2 pps drawings, filed Mar. 6, 2007.
- Andreasen et al., “System and Method for Generating a Unified Accounting Record for a Communication Session,” U.S. Appl. No. 11/715,210, 46 pps, 3 pps drawings, filed Mar. 6, 2007.
- Andreasen et al., “Network-triggered quality of service (QoS) Reservation,” U.S. Appl. No. 11/715,250, 21 pps, 2 pps drawings, filed Mar. 6, 2007.
- Andreasen et al.,; “Policy-Based Control of Content Intercept”, U.S. Appl. No. 11/715,251, 23 pps, 2 pps drawings.
- Rosenberg et al., “System and Method for Network Charging Using Policy Peering,” U.S. Appl. No. 11/715,256, 43 pps, 3 pps drawings, filed Mar. 6, 2007.
- C. Rigney, et al. “Remote Authentication Dial in User Service (RADIUS),” RFC 2865, The Internet Society, Jun. 2000, 71 pgs, Jun. 2000.
- USPTO, Office Action dated Oct. 9, 2008 for U.S. Appl. No. 11/715,256 in the name of Jonathan D. Rosenberg, 27 pages, Oct. 9, 2008.
- PCT Notification of Transmittal of the International Search Report and the Written Opinion of the International Searching Authority, or the Declaration with attached PCT International Search Report and Written Opinion of the International Searching Authority in International Application No. PCT/US2006/046800, dated Nov. 10, 2008, 10 pages, Nov. 10, 2008.
- USPTO Office Action dated Dec. 10, 2010 in U.S. Appl. No. 11/715,256, 14 pages.
- The Patent Office of The People's Republic of China, The Second Office Action and Text of the Second Office Action, Application No. 200780008341.1, Chinese Office Action and English translation transmitted to Baker Botts L.L.P. on Oct. 21, 2010, 8 pages.
- USPTO, Office Action, filed Mar. 6, 2007, U.S. Appl. No. 11/715,256, inventor Rosenberg, 13 pages.
- USPTO, Office Action dated Apr. 16, 2009 for U.S. Appl. No. 11/715,256 in the name of Jonathan D. Rosenberg, 19 pages.
- Communication from the State Intellectual Property Office of the People's Republic of China, The First Office Action, Filing No. 200780008341.1, transmitted to Baker Botts on Feb. 1, 2010, 8 pages.
- USPTO Office Action, U.S. Appl. No. 11/715,256, inventor Jonathan D. Rosenberg, 13 pages, Feb. 8, 2010.
- Online Inc., “Apogee Releases Content Usage-Based Billing Product Annotated Title—Software allows content usage-based billing,” EContent, vol. 24, No. 5, NDN 173-0356-6509-7, 1 pg, Jul. 2001.
- Centaur Communications, “Secret Bear platform allows paid-for SMS Annotated Title—Secret Bear introduced cross-network reverse billing platform allowing content providers to charge for SMS content,” New Media Age, NDN 173-0354-6130-3, 1 pg, Jun. 28, 2001.
- Karsten Lüttge, “E-Charging API: Outsource Charging to a Payment Service Provider,” NDN 174-0708-0924-8, pp. 216-227, 2001.
- A. Herzberg, “Safeguarding Digital Library Contents: Charging for Online Content,” D-Lib Magazine, NDN 174-0590-9051-8, 16 pgs., Jan. 1998.
- Business Wire, “Apogee Networks Introduces Industry's First Content Usage-Based Billing Solution for Web Hosters,” NDN 219-0281-6988-1, 2 pgs., May 8, 2001.
- Business Wire, “Apogee Networks Announces Investment by Cisco Systems; Combined Efforts Enhance Billing Capabilities for Content Delivery Network Providers,” NDN 219-0220-9035-0, 2 pgs., Jan. 23, 2001.
- Business Wire, “Key Analysts Predict Content Billing is the Internet's New Frontier; Content is the Asset of the Industry; Apogee Networks Seen as the Leader in New Internet Industry Space,” NDN 219-0162-6934-6, 3 pgs., Oct. 10, 2000.
- Business Wire, “Apogee Networks Unveils NetCountant Wireless Billing At SUPERCOMM; Company Demonstrates Industry First Wireless Content Usage Based Billing Solution,” NDN 218-0324-8075-6, 2 pgs., Jun. 5, 2001.
- Business Wire, “Apogee Networks Wins 2000 Communications ASP Product of the Year Award; Apogee Networks' NetCountant Billing Takes Top Honors for Innovative Content Usage Based Billing Solutions,” NDN 218-0282-3757-7, 2 pgs., Mar. 21, 2001.
- Business Wire, “Wireless Internet Content Billing and Settlement Capability Announced; Companies Announce Interoperability Between Wap Gateway and Content Billing System,” NDN 218-0220-0997-2, 2 pgs., Dec. 6, 2000.
- Business Wire, “Apogee Networks Joins Content Alliance; Billing Expert to Join Industry Group Aimed At Advancing Content Networking,” NDN 218-0181-2716-7, 3 pgs., Oct. 11, 2000.
- Business Wire, “Apogee Networks, Inc. and Paysys International, Inc. to Integrate Technologies to Create Advanced IP Content Billing Solutions,” NDN 218-0098-0623-9, 3 pgs., Jun. 19, 2000.
- Ylitalo, et al., Re-thinking Security in IP based Micro-Mobility, downloaded from www.tcs.hut.fi/Studies/T-79.5401/2005AUT/ISCO4-Vlitalo-e-al.pdf (12 pages).
- USPTO Office Action, U.S. Appl. No. 11/715,256, inventor Jonathan D. Rosenberg, 7 pages, Jul. 23, 2010.
- PCT Notification of Transmittal of the International Search Report and the Written Opinion of the International Searching Authority, or the Declaration with attached PCT International Search Report and Written Opinion of the International Searching Authority in International Application No. PCT/US 07/05937, dated Oct. 25, 2007, 6 pages.
Type: Grant
Filed: Mar 6, 2007
Date of Patent: Oct 23, 2012
Patent Publication Number: 20070207818
Assignee: Cisco Technology, Inc. (San Jose, CA)
Inventors: Jonathan D. Rosenberg (Freehold, NJ), Flemming S. Andreasen (Marlboro, NJ)
Primary Examiner: Patrick Edouard
Assistant Examiner: Fred Casca
Attorney: Baker Botts L.L.P.
Application Number: 11/715,056
International Classification: H04Q 7/00 (20060101);