|Publication number||USRE42003 E1|
|Application number||US 11/903,347|
|Publication date||Dec 21, 2010|
|Priority date||Oct 10, 2000|
|Also published as||US7218634|
|Publication number||11903347, 903347, US RE42003 E1, US RE42003E1, US-E1-RE42003, USRE42003 E1, USRE42003E1|
|Inventors||Mohamed Khalil, Haseeb Akhtar, Krishnakumar Pillai, Emad A. Qaddoura|
|Original Assignee||Ericsson Ab|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (31), Non-Patent Citations (8), Classifications (14), Legal Events (4)|
|External Links: USPTO, USPTO Assignment, Espacenet|
This application is the utility patent application related to provisional application Ser. No. 60/238,899 filed Oct. 10, 2000.
A power-up and hand-off communication protocol in a packet-based communication system.
Present-day Internet communications represent the synthesis of technical developments begun in the 1960s. During that time period, the Defense Department developed a communication system to support communications between different United States military computer networks, and later a similar system was used to support communications between research computer networks at United States universities.
The Internet, like so many other high tech developments, grew from research originally performed by the United States Department of Defense. In the 1960s, Defense Department officials wanted to connect different types of military computer networks. These different computer networks could not communicate with each other because they used different types of operating systems or networking protocols.
While the Defense Department officials wanted a system that would permit communication between these different computer networks, they realized that a centralized interface system would be vulnerable to missile attack and sabotage. To avoid this vulnerability, the Defense Department required that the interface system be decentralized with no vulnerable failure points.
The Defense Department developed an interface protocol for communication between these different network computers. A few years later, the National Science Foundation (NSF) wanted to connect different types of computer networks located at research institutions across the country. The NSF adopted the Defense Department's interface protocol for communication between the research computer networks. Ultimately, this combination of research computer networks would form the foundation of today's Internet.
The Defense Department's interface protocol was called the Internet Protocol (IP) standard. The IP standard now supports communication between computers and networks on the Internet. The IP standard identifies the types of services to be provided to users and specifies the mechanisms needed to support these services. The IP standard also describes the upper and lower system interfaces, defines the services to be provided on these interfaces, and outlines the execution environment for services needed in this system.
A transmission protocol, called the Transmission Control Protocol (TCP), was developed to provide connection-oriented, end-to-end data transmission between packet-switched computer networks. The combination of TCP with IP (TCP/IP) forms a system or suite of protocols for data transfer and communication between computers on the Internet. The TCP/IP standard has become mandatory for use in most packet switching networks that connect or have the potential for utilizing connectivity across networks or sub-network boundaries.
A computer operating on a network is assigned a unique physical address under the TCP/IP protocols. This is called an IP address. The IP address can include: (1) a network ID and number identifying a network, (2) a sub-network IP number identifying a substructure on the network, and (3) a host IP number identifying a particular computer on the sub-network. A header data field in the information packet will include source and destination addresses. The IP addressing scheme imposes a sensible addressing scheme that reflects the internal organization of the network or sub-network.
A router is located on a network and is used to regulate the transmission of information packets into and out of computer networks and sub-networks. A router interprets the logical address of an information packet and directs the information packet to its intended destination. Information packets addressed between computers on the sub-network do not pass through the router to the greater network, and as such, these sub-network information packets will not clutter the transmission lines of the greater network. If data is addressed to a computer outside the sub-network, the router forwards the data onto the greater network.
The TCP/IP network includes protocols that define how routers will determine the transmission path for packets through the network. Routing decisions are based upon information in the IP header and entries in a routing table maintained on the router. A routing table possesses information for a router to make a determination on whether to accept the communicated information packet on behalf of a destination computer or pass the information packet onto another router.
The routing table can be configured manually with routing table entries or with a dynamic routing protocol. In a dynamic routing protocol, routers update routing information with periodic information packet transmissions to other routers on the network. The dynamic routing protocol accommodates changing network topologies, network architecture, network structure, layout of routers, and interconnection between hosts and routers.
The IP-Based Mobility System
The Internet protocols were originally developed with an assumption that Internet users would be connected to a single, fixed network. With the advent of portable computers and cellular wireless communication systems, the movement of Internet users within a network and across network boundaries has become common. Because of this highly mobile Internet usage, the implicit design assumption of the Internet protocols has been violated.
In an IP-based mobile communication system, the mobile communication device (e.g. cellular phone, pager, computer, etc) can be called a mobile node. Typically, a mobile node maintains connectivity to its home network through a foreign network. The mobile node will always be associated with its home networks for IP addressing purposes and will have information routed to it by routers located on the home and foreign networks. The routers can be referred to by a number of names including Home Agent, Home Mobility Manager, Home Location Register, Foreign Agent, Serving Mobility Manager, Visited Location Register, and Visiting Serving Entity.
Authenticate, Authorize, and Accounting
In an IP-based mobile system, the mobile node maintains its connectivity to the home system through a foreign network. While coupled to a foreign network, the mobile node will be assigned a temporary IP address, so information packets addressed to the mobile node can be routed to the temporary EP address for the mobile node on the foreign network.
When a mobile node is operating on a foreign network, specialized servers are used to authenticate, authorize, and collect accounting information for services rendered to the mobile node. This authentication, authorization, and accounting activity is called “AAA,” and AAA computer servers on the home and foreign network perform the AAA activities.
Authentication is the process of proving one's claimed identity, and security systems on a mobile IP network will often require authentication of the system user's identity before authorizing a requested activity. The AAA server authenticates the identity of an authorized user and authorizes the mobile node's requested activity. Additionally, the AAA server performs the accounting functions by tracking usage on the network.
Functionally, a mobility manager will communicate with the AAA server in the current domain, allocating another router to route information packets destined for a mobile node while it is located away from its home sub-network. The mobility manager may have access to authentication and key generation AAA functions to authenticate and generate session keys. The mobility manager may also perform agent functions to forward packets to the mobile node until registration is completed.
IP Mobility Protocol
During the formative years since the Internet was first established, Internet Protocol version 4 (IPv4) was recognized and adopted as the standard Internet protocol. With the advent of mobile IP and proliferation of computers and computer systems linked to the Internet, various limitations in the IPv4 standard and associated procedures have developed and emerged. The most pressing limitation in IPv4 is the restriction on number of IP addresses. As shown in
A number of benefits emerge from having a larger address field. First, there is little chance of exhausting the number of possible IP addresses. Second, a large address field allows aggregation of many network-prefix routers into a single network-prefix router. Finally, large addresses allow nodes to auto configure using simple mechanisms. More efficient system designs are thus possible with an expanded address space. Thus, there is a need for an IP standard with a larger IP address space.
In wireless IP networks and sub-networks (divisions of a network), mobile nodes can be physically located anywhere on the network or sub-network. Wireless IP networks handle the mobile nature of mobile nodes with power-up and hand-off procedures designed to inform the mobile node's home network and sub-network of the location of the mobile node for packet routing purposes. Because mobile nodes can move within sub-networks and between networks, hand-off procedures need to be implemented to insure that packets are continually routed to the mobile node as it moves from one network to another or from one sub-network to another.
Current protocols for obtaining a care-of address and procedures for power-up registration and hand-off procedures are insufficient to handle current packet-based communication demands. For example, the prior power-up and hand-off protocols utilize system architecture that was designed to operate within the constraints of IPv4's limited address space. These constraints are insufficient for supporting a standard that needs a larger address space and the associated network design architecture. Therefore, a need exists to establish a new user protocol for power-up and hand-off procedures for mobile IP networks using an expanded address space.
A new protocol for power-up and hand-off is also needed to satisfy the following criteria:
1) Data transfer to a given mobile node should not be hampered by the introduction of additional functional architecture,
2) The new protocol should require only minimal extensions and should exploit and track evolving routing and addressing capabilities,
3) The new protocol should be generic and independent of the type of wireless technology or access medium,
4) The protocol should fully support and be consistent with an AAA architecture,
5) The new protocol should optimize air interface usage for efficiency, reducing the number of required overhand messages, such as Binding Update and Binding Acknowledgement messages, and
6) The protocol should also offer protection against overuse or monopolization of resources by certain mobile nodes.
The present invention offers new methodologies or protocols for establishing a communication link with a mobile node at power-up and maintaining that link with hand-off procedures on or between networks. The invention uses care-of addressing located in an expanded address field in request and response messages. The invention also, at times, uses Dynamic Host Configuration Protocol (DHCP) servers and AAA computer servers to facilitate power-up registration and hand-off procedures involving a mobile node. Using the DHCP server streamlines the procedure, reducing packet transmission overhead and improving the efficiency of the system.
The first embodiment of the invention is called Intra-Domain Power-Up Registration. This embodiment specifies registration message flow when a mobile node powers-up in a foreign sub-network located on a home domain, sending registration message through a serving mobility manager (SMM) to a DHCP server.
The second embodiment is for Reactive Intra-Domain Hand-off, and this embodiment is used when the mobile node is performing hand-off from a sub-network to another sub-network within the home network. In this embodiment, the mobile node has no forewarning of the move from one sub-network to another.
The third embodiment is a Proactive Intra-Domain Hand-off. This embodiment is used where the mobile node has knowledge that it will move to a new sub-network, but the mobile node does not yet have a link layer connectivity established with the new sub-network.
The fourth embodiment of the invention is the Inter-Domain Power-Up Registration protocol, which is used when the mobile node powers up on a foreign domain. In this embodiment, the mobile node registers through the AAA server on the foreign network.
The fifth embodiment of the invention is the Reactive Inter-Domain Hand-off protocol, which is used when the mobile node moves into a new foreign domain. The mobile node in this embodiment must use the AAA server to register on the foreign network.
The sixth embodiment of the invention is the Proactive Inter-Domain Hand-off and covers the situation where the mobile node is aware that it will move to a new sub-network that is part of a foreign network, but the mobile node does not have a link connectivity established with the new foreign sub-network.
The present invention uses an expanded address format over IPv4, and is intended to reduce the amount of registration control, management messages (e.g. Request and Response messages), and information messages (e.g. Binding Update and Binding Acknowledgement). This invention will increase efficiency of transmission and speed up the mobile IP systems because it reduces the amount of overhead message transmission and routing.
The objects and features of the invention will become more readily understood from the following detailed description and appended claims when read in conjunction with the accompanying drawings in which like numerals represent elements and in which:
FIG. 5. is a communication network with a mobile node performing a Proactive Intra-Domain Hand-off moving, with advance notice, from a sub-network to a foreign sub-network on a home network;
The Identification field (ID) 85 is 16-bits long and is assigned by the source node to aid in assembling fragments of an information packet at the destination node. The Flag field (F) 86 is a 3-bit field with control bit flags. The Fragment Offset field (FO) 87 is a 13-bit long field that indicates where the information packet belongs in a multiple-packet message. The Time-to-Live (TTL) field 88 is an 8-bit long field that indicates the maximum time the information packet will be allowed to exist in the system before deletion. The time unit indicated is seconds. The Protocol field (P) 89 will indicate the next protocol level used in the Payload portion (PLD) 95 used in the information packet. The header Checksum field (CS) 90 is used to verify the information packet.
The Source Address field (SA) 91 is a 32-bit field identifying the source of the information packet. The Destination Address field (DA) 92 is a 32-bit field identifying the intended destination of the information packet. The Payload fields (PLD) 93 are found after the IP header and include various message extensions, additional headers, and data fields. Compared to the IPv4 address fields, which include possible care-of addresses, the new message format shown in
The new address allocated by Reg Res 120 is used by the MN 64 as the care-of address for routing data packet while it remains on the foreign sub-network 50. After receiving the allocated new address, the MN 64 sends a Binding Update (BU) message 125 to the HMM 40 on the home sub-network 51. The HMM: 40 may allocate a router, HA 25, to provide routing and other services to the MN 64. If the HMM 40 allocates HA 25, a Binding Update (BU) message 130 is transmitted to HA 25. The allocated HA 25 registers the MN 64 and responds with a Binding Acknowledgement (BA) message 135 to the HMM 40. The HMM 40 will transmit a Binding Acknowledgement (BA) message 140 back to MN 64 confirming receipt of the BU 125 and binding.
A HMM 240 is coupled to the buss line 254 by communication link 217, and a home agent (HAm) 225 is coupled to HMM 240 by communication link 219. The HMM 240 and HAn 225 are the MN 64's home sub-network 282 on the home network 300. The network 300 is linked to the Internet 235 by communication link 271 connected to central buss line 254. A correspondence node (CN) 274 is also linked to the Internet 235 by communication link 272, which may be a wired or wireless link. MN 264′ is the prior location of MN 264, which is shifting connection on network 300 as shown.
After forwarding the Reg Res 320 to the MN 264, the nSMM 210 transmits a System Hand-off and Context Request message (SHC Req) 325 to the oSMM 212. Upon receiving the SHC Req 325, the oSMM 212 will task HAn 226 to forward information packets from the previous care-of address to the new care-of address (e.g. the new address allocated by DHCPv6 server 230). To task HAn 226, the oSMM 210 sends a Binding Update message (BU) 330 to HAn 226 along the same link the previous care-of address is located on. The HAn 226 responds with a Binding Acknowledgement message (BA) 335. The oSMM 212 then sends a System Hand-off and Context Reply (SHC Rep) 340 back to nSMM 210 providing user context data, which is composed of information such as session keys for the type of services granted.
After being assigned a care-of address in the Reg Res 320 and receiving context data, the MN 264 sends a BU 345 to the HMM 240, which includes a list of all IP addresses of all correspondent nodes the MN 264 is communicating with (e.g. CN 274). When the HMM 240 receives the BU 345, it allocates a home agentHAm 225to serve the MN 264, and sends a BU 350 to bind the designated HAm 225. The HAm 225 processes and validates the BU 350. After completing processing of the BU 350, the HAm 225 sends a BA 355 to the HMM 240.
Upon receipt of the BA 355, the HMM 240 sends a BA 360 to the MN 264, and the HMM 240 updates all the correspondence nodes listed by the MN 264 in the BU 345 (e.g. CN 274) with the care-of address. This is accomplished by sending a BU 365 to CN 274 (and any other node), which will reply with a BA 370. After a specified period of time to allow forwarding of all messages, the allocation of HAn 226 expires, because all future messages are forwarded to the care-of address and/or the HAm 225.
The MN 464 is connected to a transceiver 460 by wireless link 466. The transceiver 460 is connected to the oSMM 412 by communication link 459. Although this communication link from the MN 464 to the oSMM 416 includes a wireless connection, this link could alternatively be a wired connection linking MN 264 to oSMM 412. The oSMM 412 is coupled to a HAn 426 by communication link 463 and to bus line 454 by communication link 416. Foreign sub-network 481 consists of oSMM 412 and HAn 426.
The DHCPv6 server 430 is connected to buss line 454 by communication link 456. The HAAA 420 is connected to buss line 454 by communication link 455. The HMM 440 is connected to buss line 454 by communication link 417. HMM 440 is also connected to HAm 425 by communication link 419. Home sub-network 482 consists of nHMM 440 and HAm 425. The nSMM 410 is connected to the buss line 454 by communication link 415, and foreign sub-network 480 consists of nSMM 410. The home network 500 is connected to the Internet 435 by communication link 471 to buss line 454. Correspondence node (CN) 474 is connected to the Internet 435 by communication link 472, which may or may not include a wireless link. The MN 464′ connected to nSMM 410 is the future location of MN 464.
The nSMM 410 transmits a Hand-off and Context Transfer Response (HCT Res) 525 allocating a care-of address to the oSMM 412. The oSMM 412 allocates HAn 426 to bi-cast the data destined to MN 464 to both the old and new care-of address. To accomplish this, a BU 530 is transmitted from the oSMM 412 to HAn 426, which will respond with a BA 535 to oSMM 412. The oSMM 412 will then send a System Hand-off Response message (SHO Res) 540 to confirm execution of the hand-off procedures and transmit the allocated care-of address to MN 464.
After the MN 464 receives SHO Res 540 from oSMM 412 and establishes a Layer-2 connectivity with the nSMM 410 on new sub-network 480, it will send BU 545 to HMM 440 to update the current binding on the home sub-network 482 with the new care-of address. The HMM 440 will update the binding to HAm 425 by sending a BU 550 to HAm 425, which in turn will transmit a BA 555 to the HMM 440. The HMM 440 will transmit a BA 560 to the MN 440 acknowledging the BU 545. The HMM 440 will also update the binding on CN 474 with the care-of address by transmitting a BU 565 to the CN 474, and the CN 474 will acknowledge with a BA 570. If the MN 464 does not receive a SHO Res 540 from oSMM 412 because it has Layer-2 disconnection with the current foreign sub-network 481, the MN 464 will initiate the Reactive Intra-Domain Hand-off protocol.
The foreign network 700 is coupled to the Internet 670 by communication link 673, which is coupled to buss line 653. The Internet 670 is coupled to the home network 699 by communication link 671, which is connected to buss line 654.
The home network 699 includes the HAAA 620, the HMM 640, and the HAm 625. A home AAA (HAAA) server 620 is coupled to buss line 654 by communication link 656. A HMM 640 is connected to buss line 654 by communication link 617, and HMM 640 is connected to HAm 625 by communication link 619.
When the MN 664 powers up on foreign network 700,
At this point, the nSMM 610 may generate and transmit an optional IP Offer message 720 to the MN 664 containing the care-of address for temporary use while registration is completed. The nSMM 610 will generate and transmit an AAA Registration and Authentication Request message (AAA Reg Req) 725 to the FAAA 621. The FAAA 621 receives the AAA Reg Req 725 and forwards an AAA Registration and Authentication Response message (AAA Reg Res) 730 to the HAAA 620 based on the network access identifier extension (NAI) contained in the AAA Reg Req 725.
When the HAAA 620 receives an AAA Reg Req 730, it authenticates the identification and authorization of the MN 664. If the MN 664 authentication and authorization are affirmative, the HAAA 620 forwards the AAA Reg Req 735 to the HMM 640. The HMM 640 will process the AAA Reg Req 735. If the MN 664 lacks a home IP address, the MN 664 will have requested allocation of one. If requested, the HMM 640 will allocate a home IP address for the MN 664. If the home network 699 is provisioned with multiple home agents for load distribution, the HMM 640 may designate HAn 625 to serve the MN 664. The HMM 640 will then construct an AAA Registration and Authentication Response message (AAA Reg Res) 740 with this information on the designated HAn 625 and the authentication data and transmit an AAA Reg Res 740 to the FAAA 620.
The HAAA 620 will transmit an AAA Reg Res message 745 to the FAAA 621, which will contain a care-of address for use by the MN 664 allocated by the DHCPv6 sever 631 and any home IP address allocated by the HMM 640 as well as affirmative confirmation of AAA. The FAAA 621 will transmit an AAA Reg Res 750 to nSMM 610, and the nSMM 610 will generate and transmit a Reg Res 755 to the MN 664 containing the allocated care-of address and any home IP address. Once the MN 664 receives the Reg Res 755, it sends a BU 760 to the HMM 640 or any assigned HAm 625. The HMM 640 or HAm 625 will then respond with a BA 765, completing the registration.
On the old foreign network 899, the FA 830 is connected to the oSMM 810 by communication link 831. The oSMM 810 is connected to a central buss line 877 by communication link 811, and the oFAAA 845 is connected to the central buss line 877 by communication link 812. Although a wireless connection is shown linking MN 864 to nSMM 815, alternatively the link connecting MN 864 to nSMM 815 could be a wired connection.
On the new foreign network 900, the MN 864 is connected to transceiver 860 by wireless link 866. The transceiver 860 is connected to the nSMM 815 by communication link 859, and the nSMM 815 is connected to central buss line 871 by communication link 817. The central buss line 871 is connected to nFAAA 850 by communication link 821 and to DHCPv6 server 860 by communication link 819. On the home network 898, the HAAA 840 is coupled to a central buss line 873 by communication link 841. The HMM 820 is connected to the central buss line 873 by communication link 823, and the HA 825 is connected to the HMM 820 by communication link 827.
The three networks, 898, 899, and 900 are also connected to the Internet 870. The old foreign network 899 is connected to the Internet 870 by communication link 881, which is coupled to the central buss line 877. The new foreign network 900 is connected to the Internet 870 by communication link 883, which is coupled to the central buss line 871. The home network 898 is connected to the Internet 870 by communication link 882, which is coupled to central buss line 873. MN 864′ is shown moving from a location connected to oSMM 810 to a new location connected to nSMM 815.
The oSMM 810 will allocate FA 830 to forward information packets to the MN 860 by generating and transmitting a BU 930 to the FA 830. This will cause the FA 830 to forward information packets from the old care-of address to the new care-of address. This binding will last until registration is complete and then expire. The FA 830 will respond with a BA 935 back to the oSMM 810 acknowledging the BU 930.
The oSMM 810 will verify the AAA SHC Req 925 by sending an AAA System Hand-off and Context Response message (AAA SHC Res) 940 to the nSMM 815. The nSMM 815 will verify the message and allocate a co-located care-of address for the MN 864, which it will transmit to the MN 864. The nSMM 815 will generate and transmit an AAA Registration and Authorization Request message (AAA Reg Req) 945 to the nFAAA 850, which forwards the message to the HAAA 840 based on the network access identifier (NAI) extension in the MN 864 Reg Req 905.
When the HAAA 840 receives the AAA Reg Req 945, it authenticates the identification and authorization of the MN 864. If the MN 864 authentication and authorization are affirmative, the HAAA 840 forwards an AAA Reg Req 950 to the HMM 820. The HMM 820 will process the AAA Reg Req 950. If the MN 864 lacks a home IP address, the MN 664 will have requested allocation of one. If requested, the HMM 820 will allocate a home IP address for the MN 864. If the home network 699 supports more than one HA 825 for load distribution and balancing, the HMM 820 may designate a HA 825 to serve the MN 864.
The HMM 820 will construct an AAA Registration and Authorization Response (AAA Reg Res) 955 with this information on the designated HA 825 and the authentication data and transmit the message back through the HAAA 840 and nFAAA 850 to nSMM 815. The HAAA 840 will forward the AAA Reg Res 960 to nSMM 815. The nSMM 815 will generate and transmit a Reg Res 965 to the MN 864 containing the allocated, co-located care-of address, any home address for the MN 864, and confirmation of authorization and authentication. After receiving the Reg Res 965, the MN 864 completes the registration by sending a BU 970 to the HMM 820 or any assigned HA 825, which will acknowledge with a BA 975.
On the old foreign network 999, the FA 1030 is connected to the oSMM 1010 by communication link 1031. The oSMM 1010 is connected to a central buss line 1077 by communication link 1011, and the oFAAA 1045 is connected to the central line buss 1077 by communication link 1012. The MN 1064 is connected to a transceiver 1060 by wireless link 1066, and the transceiver 1060 is connected to the oSMM 1010 by communication link 1059. Although a wireless link 1066 is shown, alternatively, MN 1064 could be connected to the oSMM 1010 by a wired communication link.
On the new foreign network 1000, the nSMM 1015 is connected to a central line buss 1071 by communication link 1017. The DHCPv6 1060 is connected to the central buss line by communication link 1019, and an nFAAA 1050 is connected to the central buss line 1071 by communication link 1021.
On the home network 998, the HAAA 1040 is coupled to a central buss line 1073 by communication link 1041. The HMM 1020 is connected to the central buss line 1073 by communication link 1023, and the HA 1025 is connected to the HMM 1020 by communication link 1027.
The three networks 998, 999, and 1000 are also connected to the Internet 1070. The old foreign network 999 is connected to the Internet 1070 by communication link 1081, which is coupled to the central buss line 1077. The new foreign network 1000 is connected to the Internet 1070 by communication link 1083, which is coupled to the central buss line 1071. The home network 998 is connected to the Internet 1070 by communication link 1082, which is coupled to the central buss line 1073. The MN 1064′ connected to nSMM 1015 is the location the MN 1064 is moving to.
The oSMM 1010 allocates a FA 1030 to bi-cast data destined for the MN 1064 to both the old and new care-of address by transmitting a BU 1130, and the FA 1030 will transmit a BA 1135 back to the oSMM 1010. The oSMM 1010 will then send a System Hand-off Response message (SHO Res) 1140 back to the MN 1064 to confirm executing the hand-off and transmitting the co-located care-of address to the MN 1064.
When the MN 1064 receives the SHO Res 1140 from the oSMM 1010 and establishes Layer 2 connectivity to the new foreign network 1000, it will transmit a Reg Req 1145 to the nSMM 1015. The nSMM 1015 will then construct and transmit an AAA Registration Request message (AAA Reg Req) 1150 to the HAAA 1040 via nFAAA 1050. The HAAA 1040 will authenticate the MN 1064. If the MN 1064 authentication and authorization is affirmative, the request is forwarded to the HMM 1020 for further processing by an AAA Reg Req 1155.
The HMM 1020 updates the user state information, allocates HA 1025 to serve MN 1064, and constructs an AAA Registration Response message (AAA Reg Res) 1160 to transmit to the HAAA 1040 conveying the data. When the HAAA 1040 receives the Reg Res 1160, it in turn generates and transmits an AAA Reg Res 1165 to the nSMM 1015 via nFAAA 1050. The nSMM 1015 then sends a Reg Res 1170 to the MN 1064 conveying the information. Once the MN 1064 receives a Reg Res 1170, it proceeds to complete registration by sending a BU 1175 containing the care-of address to the HA 1025, which acknowledges with a BA 1180.
As a further alternative embodiment in each of these embodiments the mobility managers (SMM 10, HMM 40, nSMM 210, oSMM 212, HMM 240, nSMM 410, oSMM 412, HMM 440, nSMM 610, HMM 640, oSMM 810, nSMM 815, HMM 820, oSMM 1010, nSMM 1015, and HMM 1020) may maintain a pool of addresses to allocate as care-of addresses to mobile nodes. If there is a pool of addresses to allocate, then the DHCPv6 Request messages (110, 310, 615, 710, 910 and 1115) and the DHCPv6 Response message (115, 315, 620, 715, 915, and 1120) are eliminated. In place of these messages (110, 115, 310, 315, 615, 620, 710, 715, 910, 915, 1115, and 1120) the SMM 10, nSMM 210, nSMM 410, nSMM 610, nSMM 815, and nSMM 1015 will periodically request a new pool of addresses from the DHCPv6 server to allocate as care-of addresses.
While the invention has been particularly shown and described with respect to preferred embodiments, it will be readily understood that minor changes in the details of the invention may be made without departing from the spirit of the invention.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US5550984 *||Dec 7, 1994||Aug 27, 1996||Matsushita Electric Corporation Of America||Security system for preventing unauthorized communications between networks by translating communications received in ip protocol to non-ip protocol to remove address and routing services information|
|US5793763 *||Nov 3, 1995||Aug 11, 1998||Cisco Technology, Inc.||Security system for network address translation systems|
|US6038233 *||Jul 2, 1997||Mar 14, 2000||Hitachi, Ltd.||Translator for IP networks, network system using the translator, and IP network coupling method therefor|
|US6118784 *||Oct 28, 1997||Sep 12, 2000||Hitachi, Ltd.||Communicating method between IPv4 terminal and IPv6 terminal and IPv4-IPv6 converting apparatus|
|US6157950 *||Dec 5, 1997||Dec 5, 2000||Encanto Networks, Inc.||Methods and apparatus for interfacing a computer or small network to a wide area network such as the internet|
|US6434134 *||Dec 11, 1998||Aug 13, 2002||Lucent Technologies, Inc.||Dynamic address assignment for wireless devices accessing packet-based wired networks|
|US6445922 *||Dec 15, 1999||Sep 3, 2002||Lucent Technologies Inc.||Method and system for support of overlapping IP addresses between an interworking function and a mobile IP foreign agent|
|US6535493 *||Jan 15, 1998||Mar 18, 2003||Symbol Technologies, Inc.||Mobile internet communication protocol|
|US6549522 *||Dec 11, 1998||Apr 15, 2003||British Telecommunications Public Limited Company||Mobile data rate enhancement via foreign agent load balancing|
|US6567664 *||Jun 2, 1999||May 20, 2003||Nokia Corporation||Registration for mobile nodes in wireless internet protocols|
|US6578085 *||Aug 6, 1999||Jun 10, 2003||Nortel Networks Limited||System and method for route optimization in a wireless internet protocol network|
|US6654359 *||Dec 11, 1998||Nov 25, 2003||Lucent Technologies Inc.||Wireless access to packet-based networks|
|US6681259 *||May 10, 1999||Jan 20, 2004||Nokia Mobile Phones Ltd||Method for coupling a wireless terminal to a data transmission network and a wireless terminal|
|US6763007 *||Dec 11, 1998||Jul 13, 2004||Lucent Technologies Inc.||Two phase local mobility scheme for wireless access to packet based networks|
|US6769000 *||Sep 7, 2000||Jul 27, 2004||Nortel Networks Limited||Unified directory services architecture for an IP mobility architecture framework|
|US6771609 *||Nov 30, 1999||Aug 3, 2004||Caterpillar Inc||Method and apparatus for dynamically updating representation of a work site and a propagation model|
|US6804221 *||Jun 26, 2000||Oct 12, 2004||Alcatel||Micromobility using multicast|
|US6822971 *||May 28, 1999||Nov 23, 2004||Nokia Corporation||Apparatus, and association method, for identifying data with an address|
|US6842456 *||Feb 24, 2000||Jan 11, 2005||Lucent Technologies Inc.||Non-encapsulation mobile IP|
|US6862274 *||Oct 26, 2000||Mar 1, 2005||Industrial Technology Research Institute||Method and system capable of providing mobility support for IPv4/IPv6 inter-networking|
|US6892069 *||Dec 11, 1998||May 10, 2005||British Telecommunications, Plc||Proxy routing|
|US6915345 *||Oct 2, 2000||Jul 5, 2005||Nortel Networks Limited||AAA broker specification and protocol|
|US6987771 *||May 29, 2001||Jan 17, 2006||Mitsubishi Denki Kabushiki Kaisha||Route optimization method and agent apparatus|
|US7072339 *||Oct 23, 2001||Jul 4, 2006||Hitachi, Ltd.||Communicating method between IPv4 terminal and IPv6 terminal and IPv4-IPv6 converting apparatus|
|US7218634 *||Oct 9, 2001||May 15, 2007||Nortel Networks Limited||Assisted power-up and hand-off system and method|
|US7310351 *||Sep 5, 2002||Dec 18, 2007||Hitachi, Ltd.||Method and apparatus for translating protocol|
|US20010036164 *||Jan 25, 2001||Nov 1, 2001||Fujitsu Limited||Mobile network system and service control information changing method|
|US20030185236 *||Sep 5, 2002||Oct 2, 2003||Hitachi, Ltd.||Method and apparatus for translating protocol|
|US20040037260 *||Aug 7, 2003||Feb 26, 2004||Mitsuaki Kakemizu||Virtual private network system|
|US20040179508 *||Jul 11, 2003||Sep 16, 2004||Pascal Thubert||Arrangement for traversing an IPv4 network by IPv6 mobile nodes via a mobility anchor point|
|US20050243820 *||Mar 23, 2005||Nov 3, 2005||Xiaobao Chen||Method and apparatus for data transfer in a packet-switched network|
|1||*||Chao et al, "The Implication of the next generation wireless network design cellular mobile IPv6", IEEE Transaction on Consumer Electronics, vol. 46, No. 3, Jun. 19, 2000, pp. 656-663.|
|2||*||Ernst et al, "Extending Mobile IPv6 with Multicast to Support Mobile Networks in IPv6", IEEE 2000, pp. 114-121.|
|3||Glass, S. et al.; "Mobile IP Authentication, Authorization, and Accounting Requirements"; Network Working Group (Oct. 2000).|
|4||*||Han-Chieh Chao, Yen-Ming Chu, and Mu-Tai Lin, "The Cellular Mobile IPv6 Using Low Latency Handoff Algorithm for the Packet-Based Cellular Network", Jun. 13-15, 2000, IEEE, pp. 292-293.|
|5||*||Jacobs, "Security of Current Mobile IP Solutions", IEEE 1997, pp. 1122-1128.|
|6||Johnson, D. et al.; "Mobility Support in IPv6"; Internet Engineering Task Force (Apr. 2000).|
|7||Malki, K. and Hesham Soliman, "Hierarchical Mobile IPv4/v6 and Fast Handoffs"; Mobile IP Working Group (Mar. 2000).|
|8||Narten, T. et al.; "Neighbor Discovery for IP Version 6 (IPv6)"; Network Working Group (Dec. 1998).|
|U.S. Classification||370/392, 370/401|
|Cooperative Classification||H04L69/161, H04W80/04, H04L29/12216, H04W8/26, H04W60/00, H04L61/2007, H04W36/00|
|European Classification||H04W8/26, H04L29/12A3A, H04L29/06J3, H04L61/20A|
|Nov 24, 2009||AS||Assignment|
Owner name: ERICSSON AB, SWEDEN
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:NORTEL NETWORKS LIMITED;REEL/FRAME:023565/0191
Effective date: 20091113
|Apr 29, 2010||AS||Assignment|
Owner name: ERICSSON AB, SWEDEN
Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE ERRONEOUSLY RECORDED PATENT APPLICATION NUMBERS 12/471,123 AND12/270,939 PREVIOUSLY RECORDED ON REEL 023565 FRAME 0191. ASSIGNOR(S) HEREBY CONFIRMS THE ASSIGNMENT OF RIGHT, TITLE AND INTEREST IN PATENTS FROM NORTEL NETWORKS LIMITED TO ERICSSON AB;ASSIGNOR:NORTEL NETWORKS LIMITED;REEL/FRAME:024312/0689
Effective date: 20100331
|Aug 30, 2011||CC||Certificate of correction|
|Nov 17, 2014||FPAY||Fee payment|
Year of fee payment: 8