1. Field of the Invention
The invention generally relates to the use of Mobile Internet Protocol (“IP”) systems, methods and protocols in PCS systems and, more particularly, to a method for distributing and conditioning traffic for mobile networks based on differentiated services.
2. Description of the Related Art
FIG. 1 is an illustration of a network configured to support Differentiated Services. In such a network, Differentiated Services (DS) or Diff-serv (IETF RFC 2475) is predicated on the concept of classifying data packets, maintaining customer states at the edge of a network and permitting routers at the core of the network to handle aggregates of IP traffic.
IP Version 4 (IPv4) is an Internet Protocol (IP) implementation standard which is in widespread use for transport and control of data and/or voice traffic which is transmitted over wireless and/or wired networks. In IPv4, Diff-Serv utilizes an eight bit type of service (TOS) field in the IP header of transmitted data packets.
In operation, the TOS field (i.e., the DS byte) is set by Diff-Serv capable network interface cards, routers and switches, and is used to differentiate between traffic flow which belongs to different service classes. Diff-Serv operates at network layer (or layer 3). If each network utilizes IP as a common network layer protocol, the data packet scheme and quality of Service (QoS) parameters operate across different networks. DiffServ QoS specifications are recognizable by routers and switches, or any device which may read the IP header and DS byte. The DS byte contains a DS code point, and a tag which specifies the forwarding Per-Hop Behavior (PHB) for the DS byte. PHB is the forwarding treatment which is applied to a specific class of traffic, based on criteria defined in the Diff-Serv field. Routers and switches use PHBs to determine priorities for servicing various traffic flows. In this case, a PHB might specify routing precedence, or it may include other performance characteristics, such as query servicing or management policy.
When data packets enter the network, they pass through a Diff-Serv boundary node (i.e., an edge router or edge node), and then pass through a Diff-Serv core node (i.e., a core router). If the data packets are unclassified, the edge router handles and assigns each packet to a “behavior aggregate”. Here, a behavior aggregate is a collection of packets having the same DSCPs (DS code points, i.e., header values) which are members of the same DSCP group and cross a link in a particular direction, where the DSCP group is a set of related DSCPs which select the same PHB group.
Behavior aggregates are each associated with a specific PHB, and are thus subject to parameters described in a Traffic Conditioning Agreement (TCA) between their Diff-Serv domain and a customer access network, or to the peer domain to which they are connected. In addition, the edge router performs important conditioning functions to maintain each PHB such that it is “in profile” with the TCA, such as (i) metering (i.e., measuring the rate of flow of each traffic stream); (ii) marking/re-marking (i.e., resetting the Diff-Serv code point to downgrade any excess traffic); (iii) shaping (i.e., delaying data packets within a traffic stream to maintain conformity of the data flow with the traffic profile); and policing (i.e., discarding packets within a traffic stream such that the correct traffic profile is enforced).
When Diff-Serv is implemented in a wired network, the location of a user is easily obtained. As a result, it is easy to locate the edge/border routers that are needed to condition the traffic for a specific user. In wireless networks, however, users may freely roam anywhere throughout the network. Hence, all edge routers are potentially required to know the QoS profile of all users which are in the domain and those which may roam into the domain.
Typically, it is not feasible to permit each edge/border router to maintain a database which includes all potential mobile users in the world. One straightforward solution to this is to permit all edge/border routers in the domain to maintain QoS profiles for only those users currently within the domain. In this case, the databases are updated when a user enters and leaves the domain. Although this reduces the number of users that an edge/border router must maintain, it is inefficient to maintain identical copies of a potentially large database in all edge/border routers which are located in the same domain. In addition, once a mobile station moves into or out of a domain, or a user changes its Service Level Specification/Service Level agreement (SLS/SLA), the same transactions for updating the database must be performed for all edge/border routers.
Further, a mobile station usually possesses multiple addressees, such as a home address and a “Care-of-Address” (COA). In some mobility management schemes, the COA may also comprise multiple addresses which are different, such as a global COA (GCOA) and a local COA (LCOA). Due to security reasons and other concerns, a router should not change the IP address(es) in an IP packet. This is true even though the router may know the address(es) in an IP header and/or payload.
Of note, only the top header in the IP packet is visible to the router if IP Security Packet with Encapsulating Security Payload (ESP) (RFC 2406)), i.e., IPSec, is employed. That is, the router may only see the COA (or one of the COAs) when the mobile station roams. Therefore, in addition to updating the database when the mobile station moves into or out of the domain, an update is also required when a mobile station requires a new IP address. The mobile station will use this new address to send network traffic, i.e., IP packets.
Depending on the mobility management scheme employed, a corresponding host may use the old or new IP address to communicate with the mobile station. In many cases, an edge/border router must possess the new IP address to condition the traffic at the edge of the DS domain. If the QoS profiles of all users are maintained in the edge/border routers, an update of the database in all edge/border routers often becomes necessary each time a mobile station moves into a new IP subnet. However, at any given time, only a few edge/border routers require possession of the new IP address. Hence, it is apparent that there is a vast amount of unnecessary broadcast traffic and database transactions.
Generally, if the number of users and the number of edge/border routers within a domain is small, then the edge/border routers can maintain the same database for all users which are currently in the domain. Here, if a change in the address of the QoS profile or the arrival/departure of a user occurs, all databases are updated concurrently. As stated previously, on the other hand, it is inefficient to maintain the same database for all users in all edge/border routers. This is particularly true if the domain comprises many users and edge/border routers. This amounts to a waste of storage space, in that the same databases, consisting of all users in the domain, are maintained in all edge/border routers. This also causes unnecessary broadcast traffic and database transactions in all edge/border routers each time a mobile station moves to a new subnet or changes its service level specification or service level agreement (SLS/SLA). In addition, the mobile station is required to negotiate with the network of a conventional system each time a move to a new radio access network occurs, causing a long handoff period without service and increasing load (bandwidth) on the access network. Moreover, the mobile station is not permitted to obtain any service if the radio access network to which the mobile station moves is overloaded.