Assisted power-up and hand-off system and method

RELATED APPLICATION DATA

0001This application is the utility patent application related to provisional application Ser. No. 60/238,899 filed Oct. 10, 2000.

TECHNICAL FIELD OF THE INVENTION

0002A power-up and hand-off communication protocol in a packet-based communication system.

BACKGROUND OF THE INVENTION

0003Present-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.

0000The Internet

0004The 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.

0005While 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.

0006The 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.

0000Internet Protocols

0007The 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.

0008A 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.

0009A 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.

0010A 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.

0011The 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.

0012The 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.

0000The IP-Based Mobility System

0013The 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.

0014In 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.

0000Authenticate, Authorize, and Accounting

0015In 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.

0016When 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.

0017Authentication 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.

0018Functionally, 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.

0000IP Mobility Protocol

0019During 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 <figref idref="DRAWINGS">FIG. 1B</figref>, the address field size in an IPv4 packet is only 32 bits.

0020A 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.

0021In 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.

0022Current 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.

0023A new protocol for power-up and hand-off is also needed to satisfy the following criteria:

00241) Data transfer to a given mobile node should not be hampered by the introduction of additional functional architecture,

00252) The new protocol should require only minimal extensions and should exploit and track evolving routing and addressing capabilities,

00263) The new protocol should be generic and independent of the type of wireless technology or access medium,

00274) The protocol should fully support and be consistent with an AAA architecture,

00285) 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

00296) The protocol should also offer protection against overuse or monopolization of resources by certain mobile nodes.

SUMMARY OF THE INVENTION

0030The 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.

0031The 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.

0032The 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.

0033The 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.

0034The 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.

0035The 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.

0036The 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.

0037The 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.

BRIEF DESCRIPTION OF THE DRAWINGS

0038The 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:

0039<figref idref="DRAWINGS">FIG. 1</figref> is a communication network for the Intra-Domain Power-Up Registration embodiment where a mobile node powers-up on a foreign sub-network of its home network;

0040<figref idref="DRAWINGS">FIG. 1A</figref> is the information packet format used in the present invention;

0041<figref idref="DRAWINGS">FIG. 1B</figref> is the prior art information packet format;

0042<figref idref="DRAWINGS">FIG. 2</figref> is a message flow diagram for registration of the mobile node in the embodiment of <figref idref="DRAWINGS">FIG. 1</figref> for an Intra-Domain Power-Up Registration;

0043<figref idref="DRAWINGS">FIG. 3</figref> is a communication network for the Reactive Intra-Domain Hand-off with a mobile node moving from a sub-network, with no advance notice, to a foreign sub-network;

0044<figref idref="DRAWINGS">FIG. 4</figref> is a message flow diagram for the Reactive Intra-Domain Hand-off for a mobile node performing a hand-off in <figref idref="DRAWINGS">FIG. 2</figref>;

0045FIG. <b>5</b>. 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;

0046<figref idref="DRAWINGS">FIG. 6</figref> is a message flow diagram for a mobile performing a Reactive Intra-Domain Hand-off in <figref idref="DRAWINGS">FIG. 5</figref>;

0047<figref idref="DRAWINGS">FIG. 7</figref> shows a home communication and a foreign communication network with a mobile node powering up on the foreign network in an Inter-Domain Power-Up Registration;

0048<figref idref="DRAWINGS">FIG. 8</figref> is a message flow diagram for an Inter-Domain Power-Up Registration of the mobile node on the foreign network in <figref idref="DRAWINGS">FIG. 7</figref>;

0049<figref idref="DRAWINGS">FIG. 9</figref> shows a home communication network and two foreign communication networks, with a mobile node moving unexpectedly from one foreign network to another and performing a Reactive Inter-Domain Hand-off;

0050<figref idref="DRAWINGS">FIG. 10</figref> is a message flow diagram for the Reactive Intra-Domain Hand-off of the mobile node in <figref idref="DRAWINGS">FIG. 9</figref>;

0051<figref idref="DRAWINGS">FIG. 11</figref> shows a home communication network and two foreign communication networks, with a mobile node moving with advance notice from one foreign network to the other and performing a Proactive Inter-Domain Hand-off; and

0052<figref idref="DRAWINGS">FIG. 12</figref> is a message flow diagram for the Proactive Inter-Domain Hand-off of the mobile node in FIG. <b>11</b>.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

0053<figref idref="DRAWINGS">FIG. 1</figref> shows a Mobile Node (MN) <b>64</b> powering up on a foreign sub-network <b>50</b> of a home network <b>100</b>. The home network <b>100</b> has a central buss line <b>54</b> coupled to a home AAA server (HAAA) <b>20</b> by communication link <b>55</b>, a DHCPv6 server <b>30</b> coupled by communication link <b>56</b> to the buss line <b>54</b>, a home mobility manager (HMM) <b>40</b> coupled by communication link <b>17</b> to the buss line <b>54</b>, and a serving mobility manager (SMM) <b>10</b> coupled by communication link <b>15</b> to the buss line <b>54</b>. The home sub-network <b>51</b> of the MN <b>64</b> consists of the HMM <b>40</b> coupled to the home agent <b>25</b> by communication link <b>19</b>. The foreign sub-network <b>50</b> consists of the SMM <b>10</b>. MN <b>64</b> is linked to SMM <b>10</b> by a communication link <b>62</b>, which may be a wired or wireless connection.

0054In <figref idref="DRAWINGS">FIG. 1</figref>, the MN <b>64</b> is powering up on a foreign sub-network <b>50</b>. <figref idref="DRAWINGS">FIG. 2</figref> shows the registration message flow for the situation where the MN <b>64</b> powers up on a foreign sub-network within the home network. This embodiment is referred to as an Intra-Domain Power-Up Registration. The MN <b>64</b> constructs a local IP address for use on the foreign sub-network <b>50</b> by sending a Registration Request message (Reg Req) <b>105</b> to the SMM <b>10</b>. This Reg Req <b>105</b> is for allocation of a co-located, globally routable long-term IP address for the MN <b>64</b> while it remains on the current sub-network <b>50</b>. The Reg Req <b>105</b> also contains coincidental information to verify the identity of the MN <b>64</b>. The SMM <b>10</b> will validate the identity of the MN <b>64</b>, and then send a DHCPv6 Request message (DHCPv6 Req) <b>110</b> to the DHCPv6 server <b>30</b> requesting a new address for MN <b>64</b>. The DHCPv6 server <b>30</b> allocates a new address to use as a care-of address and sends a DHCPv6 Reply message (DHCPv6 Rep) <b>115</b> back to the SMM <b>10</b> with the new address. The SMM <b>10</b> relays this new address to the MN <b>64</b> with a Registration Response message (Reg Res) <b>120</b>. The format of the IP header in the Registration Response message Reg Res <b>120</b> is shown in FIG. <b>1</b>A.

0055<figref idref="DRAWINGS">FIG. 1A</figref> shows the new information packet's IP header format with an expanded address field. The Version (V) field <b>71</b> is a 4-bit long data field that is used to designate the IP version number. The Priority (P) field <b>72</b> designates the desired delivery priority of the information packet. The Payload Length field (PL) <b>74</b> is the length of the rest of the packet following the IP header fields in octets. The Next Header field (NH) <b>76</b> identifies the type of header immediately following the IP header fields. The Hop Limit field (HL) <b>75</b> is an 8-bit integer value that is decremented by 1 for each node that forwards the packet. The Source Address field (SA) <b>77</b> is the 128-bit address of the source node of the information packet. The Destination Address field (DA) <b>78</b> is the 128-bit address of the intended destination node. Various message extension types, additional headers, and data fields can be found in the Payload fields (PLD) <b>79</b>, the Reg Res <b>120</b> and Reg Req <b>105</b> being two of the possible types. The 128-bit care-of address will be in one of these PLD fields <b>79</b> in Reg Res <b>120</b>.

0056<figref idref="DRAWINGS">FIG. 1B</figref> shows the prior art IPv4 information packet's IP header format. The Version (V) field <b>81</b> is a 4-bit long field that is used to designate the IP version number (version 4 in this case). The Internet Header Length field (IHL) <b>82</b> is 4-bits long and is the length of the IP header in 32-bit words. The Type of Service (TOS) field <b>83</b> is 8-bits long and is an abstract indication of the quality of service desired. The Total Length (TL) field <b>84</b> is 16-bits long and is the length of the information packet in octets.

0057The Identification field (ID) <b>85</b> 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) <b>86</b> is a 3-bit field with control bit flags. The Fragment Offset field (FO) <b>87</b> is a 13-bit long field that indicates where the information packet belongs in a multiple-packet message. The Time-to-Live (TTL) field <b>88</b> 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) <b>89</b> will indicate the next protocol level used in the Payload portion (PLD) <b>95</b> used in the information packet. The header Checksum field (CS) <b>90</b> is used to verify the information packet.

0058The Source Address field (SA) <b>91</b> is a 32-bit field identifying the source of the information packet. The Destination Address field (DA) <b>92</b> is a 32-bit field identifying the intended destination of the information packet. The Payload fields (PLD) <b>93</b> 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 <figref idref="DRAWINGS">FIG. 1A</figref> offers address fields four times larger than found in IPv4.

0059The new address allocated by Reg Res <b>120</b> is used by the MN <b>64</b> as the care-of address for routing data packet while it remains on the foreign sub-network <b>50</b>. After receiving the allocated new address, the MN <b>64</b> sends a Binding Update (BU) message <b>125</b> to the HMM <b>40</b> on the home sub-network <b>51</b>. The HMM: <b>40</b> may allocate a router, HA <b>25</b>, to provide routing and other services to the MN <b>64</b>. If the HMM <b>40</b> allocates HA <b>25</b>, a Binding Update (BU) message <b>130</b> is transmitted to HA <b>25</b>. The allocated HA <b>25</b> registers the MN <b>64</b> and responds with a Binding Acknowledgement (BA) message <b>135</b> to the HMM <b>40</b>. The HMM <b>40</b> will transmit a Binding Acknowledgement (BA) message <b>140</b> back to MN <b>64</b> confirming receipt of the BU <b>125</b> and binding.

0060<figref idref="DRAWINGS">FIG. 3</figref> depicts the situation where a mobile node moves unexpectedly from one sub-network <b>281</b> to another sub-network <b>280</b> within a home network <b>300</b> and must perform a hand-off routine. The embodiment to handle this situation is referred to as a Reactive Intra-Domain Hand-off. <figref idref="DRAWINGS">FIG. 3</figref> shows a MN <b>264</b> linked to a transceiver <b>260</b> by a communication link <b>266</b>. The transceiver <b>260</b> is linked to a sub-network <b>280</b> on network <b>300</b> via new SMM (nSMM) <b>210</b> by communication link <b>259</b>. Although this link to the network <b>300</b> is a wireless connection, alternatively the connection could be a wired connection linking the MN <b>264</b> to the nSMM <b>210</b>. The sub-network <b>280</b> consists of nSMM <b>210</b>, and it is a foreign sub-network <b>280</b> for the MN <b>64</b> on the home network <b>300</b>. The nSMM <b>210</b> is linked to a central buss line <b>254</b> by communication link <b>215</b>. A home AAA server (HAAA) <b>220</b> is coupled to the buss line <b>254</b> by communication link <b>255</b>, and a DHCPv6 server <b>230</b> is coupled to buss line <b>254</b> by communication link <b>256</b>. The old SMM (oSMM) <b>212</b> is coupled to the buss Hue <b>254</b> by communication link <b>216</b>. A home agent (HAn) <b>226</b> is connected to oSMM <b>212</b> by communication link <b>263</b>. The oSMM <b>212</b> and HAn <b>226</b> form another foreign sub-network <b>281</b> on the home network <b>300</b>.

0061A HMM <b>240</b> is coupled to the buss line <b>254</b> by communication link <b>217</b>, and a home agent (HAm) <b>225</b> is coupled to HMM <b>240</b> by communication link <b>219</b>. The HMM <b>240</b> and HAn <b>225</b> are the MN <b>64</b>'s home sub-network <b>282</b> on the home network <b>300</b>. The network <b>300</b> is linked to the Internet <b>235</b> by communication link <b>271</b> connected to central buss line <b>254</b>. A correspondence node (CN) <b>274</b> is also linked to the Internet <b>235</b> by communication link <b>272</b>, which may be a wired or wireless link. MN <b>264</b>′ is the prior location of MN <b>264</b>, which is shifting connection on network <b>300</b> as shown.

0062In <figref idref="DRAWINGS">FIG. 3</figref>, the MN <b>264</b>′ is shown connected to the foreign sub-network <b>281</b> and is moving unexpectedly from an area covered by oSMM <b>212</b> on foreign sub-network <b>280</b> to an area covered by nSMM <b>210</b> on foreign sub-network <b>281</b>. <figref idref="DRAWINGS">FIG. 4</figref> shows the message flow for this embodiment where MN <b>264</b> is perforating hand-off from one foreign sub-network <b>281</b> to another foreign sub-network <b>280</b> within a home network <b>300</b> without prior notice. This new embodiment is referred to as a Reactive Intra-Domain Hand-off.

0063In <figref idref="DRAWINGS">FIG. 4</figref>, the MN <b>264</b> constructs a local IP address for use on the foreign sub-network by sending a Reg Req message <b>305</b> to the nSMM <b>210</b>. The Reg Req <b>305</b> is for allocation of a globally routable IP address for MN <b>264</b> to use on the current sub-network <b>280</b>. The format of the IP header for Reg Req <b>305</b> is the same as shown in FIG. <b>1</b>A. The MN <b>264</b> will also provide coincidental information to verify its identity in the Reg Req <b>305</b>. The nSMM <b>210</b> verifies the identity of the MN <b>264</b> and then transmits a DHCPv6 Req <b>310</b> to the DHCPv6 server <b>230</b> requesting allocation of an IP address. The DHCPv6 server <b>230</b> allocates a care-of address and transmits a DHCPv6 Res <b>315</b> back to the nSMM <b>210</b> with the care-of address. The nSMM <b>210</b> then transmits a Reg Res message <b>320</b> containing the allocated new address.

0064After forwarding the Reg Res <b>320</b> to the MN <b>264</b>, the nSMM <b>210</b> transmits a System Hand-off and Context Request message (SHC Req) <b>325</b> to the oSMM <b>212</b>. Upon receiving the SHC Req <b>325</b>, the oSMM <b>212</b> will task HAn <b>226</b> 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 <b>230</b>). To task HAn <b>226</b>, the oSMM <b>210</b> sends a Binding Update message (BU) <b>330</b> to HAn <b>226</b> along the same link the previous care-of address is located on. The HAn <b>226</b> responds with a Binding Acknowledgement message (BA) <b>335</b>. The oSMM <b>212</b> then sends a System Hand-off and Context Reply (SHC Rep) <b>340</b> back to nSMM <b>210</b> providing user context data, which is composed of information such as session keys for the type of services granted.

0065After being assigned a care-of address in the Reg Res <b>320</b> and receiving context data, the MN <b>264</b> sends a BU <b>345</b> to the HMM <b>240</b>, which includes a list of all IP addresses of all correspondent nodes the MN <b>264</b> is communicating with (e.g. CN <b>274</b>). When the HMM <b>240</b> receives the BU <b>345</b>, it allocates a home agentHAm <b>225</b>to serve the MN <b>264</b>, and sends a BU <b>350</b> to bind the designated HAm <b>225</b>. The HAm <b>225</b> processes and validates the BU <b>350</b>. After completing processing of the BU <b>350</b>, the HAm <b>225</b> sends a BA <b>355</b> to the HMM <b>240</b>.

0066Upon receipt of the BA <b>355</b>, the HMM <b>240</b> sends a BA <b>360</b> to the MN <b>264</b>, and the HMM <b>240</b> updates all the correspondence nodes listed by the MN <b>264</b> in the BU <b>345</b> (e.g. CN <b>274</b>) with the care-of address. This is accomplished by sending a BU <b>365</b> to CN <b>274</b> (and any other node), which will reply with a BA <b>370</b>. After a specified period of time to allow forwarding of all messages, the allocation of HAn <b>226</b> expires, because all future messages are forwarded to the care-of address and/or the HAm <b>225</b>.

0067<figref idref="DRAWINGS">FIG. 5</figref> depicts a MN <b>464</b> linked to a foreign sub-network <b>481</b> on its home network <b>500</b>. The MN <b>464</b> is aware it will move to a new foreign sub-network <b>480</b>, which consist of an nSMM <b>410</b>, but the MN <b>464</b> does not yet have a link layer connectivity established with the new sub-network <b>480</b>. The home network <b>500</b> consists of a HAAA server <b>420</b>, a DHCPv6 server <b>430</b>, nSMM <b>410</b>, a HMM <b>440</b>, a HAm <b>425</b>, an oSMM <b>412</b>, and a HAn <b>426</b>.

0068The MN <b>464</b> is connected to a transceiver <b>460</b> by wireless link <b>466</b>. The transceiver <b>460</b> is connected to the oSMM <b>412</b> by communication link <b>459</b>. Although this communication link from the MN <b>464</b> to the oSMM <b>416</b> includes a wireless connection, this link could alternatively be a wired connection linking MN <b>264</b> to oSMM <b>412</b>. The oSMM <b>412</b> is coupled to a HAn <b>426</b> by communication link <b>463</b> and to bus line <b>454</b> by communication link <b>416</b>. Foreign sub-network <b>481</b> consists of oSMM <b>412</b> and HAn <b>426</b>.

0069The DHCPv6 server <b>430</b> is connected to buss line <b>454</b> by communication link <b>456</b>. The HAAA <b>420</b> is connected to buss line <b>454</b> by communication link <b>455</b>. The HMM <b>440</b> is connected to buss line <b>454</b> by communication link <b>417</b>. HMM <b>440</b> is also connected to HAm <b>425</b> by communication link <b>419</b>. Home sub-network <b>482</b> consists of nHMM <b>440</b> and HAm <b>425</b>. The nSMM <b>410</b> is connected to the buss line <b>454</b> by communication link <b>415</b>, and foreign sub-network <b>480</b> consists of nSMM <b>410</b>. The home network <b>500</b> is connected to the Internet <b>435</b> by communication link <b>471</b> to buss line <b>454</b>. Correspondence node (CN) <b>474</b> is connected to the Internet <b>435</b> by communication link <b>472</b>, which may or may not include a wireless link. The MN <b>464</b>′ connected to nSMM <b>410</b> is the future location of MN <b>464</b>.

0070<figref idref="DRAWINGS">FIG. 6</figref> shows the message flow for the embodiment in <figref idref="DRAWINGS">FIG. 5</figref>, referred to as a Proactive Intra-Domain Hand-off. When the MN <b>464</b> detects that it will move to new sub-network <b>480</b> on the home network <b>500</b>, it sends a System Hand-off Request message (SHO Req) <b>505</b> to the oSMM <b>412</b>, the current serving mobility manager on sub-network <b>481</b>. The format of EP header for SHO Req <b>505</b> is the same as shown in FIG. <b>1</b>A. The oSMM <b>412</b> transmits a Hand-off and Context Transfer Request message (HCT Req) <b>510</b> to the nSMM <b>410</b> on the sub-network <b>480</b>, the future serving mobility manager. The nSMM <b>410</b> sends a DHCPv6 Req <b>515</b> to the DHCPv6 <b>430</b> requesting a new address to allocate as a care-of address. The DHCPv6 <b>430</b> transmits the care-of address to the nSMM <b>410</b> in a DHCPv6 Res <b>520</b>.

0071The nSMM <b>410</b> transmits a Hand-off and Context Transfer Response (HCT Res) <b>525</b> allocating a care-of address to the oSMM <b>412</b>. The oSMM <b>412</b> allocates HAn <b>426</b> to bi-cast the data destined to MN <b>464</b> to both the old and new care-of address. To accomplish this, a BU <b>530</b> is transmitted from the oSMM <b>412</b> to HAn <b>426</b>, which will respond with a BA <b>535</b> to oSMM <b>412</b>. The oSMM <b>412</b> will then send a System Hand-off Response message (SHO Res) <b>540</b> to confirm execution of the hand-off procedures and transmit the allocated care-of address to MN <b>464</b>.

0072After the MN <b>464</b> receives SHO Res <b>540</b> from oSMM <b>412</b> and establishes a Layer-2 connectivity with the nSMM <b>410</b> on new sub-network <b>480</b>, it will send BU <b>545</b> to HMM <b>440</b> to update the current binding on the home sub-network <b>482</b> with the new care-of address. The HMM <b>440</b> will update the binding to HAm <b>425</b> by sending a BU <b>550</b> to HAm <b>425</b>, which in turn will transmit a BA <b>555</b> to the HMM <b>440</b>. The HMM <b>440</b> will transmit a BA <b>560</b> to the MN <b>440</b> acknowledging the BU <b>545</b>. The HMM <b>440</b> will also update the binding on CN <b>474</b> with the care-of address by transmitting a BU <b>565</b> to the CN <b>474</b>, and the CN <b>474</b> will acknowledge with a BA <b>570</b>. If the MN <b>464</b> does not receive a SHO Res <b>540</b> from oSMM <b>412</b> because it has Layer-2 disconnection with the current foreign sub-network <b>481</b>, the MN <b>464</b> will initiate the Reactive Intra-Domain Hand-off protocol.

0073<figref idref="DRAWINGS">FIG. 7</figref> shows MN <b>664</b> powering up on a foreign network <b>700</b>. The MN <b>664</b> is connected to the foreign network <b>700</b> by communication link <b>659</b>. The foreign network <b>700</b> includes the FAAA <b>621</b>, the DHCPv6 <b>631</b>, and the nSMM <b>610</b>. The communication link <b>659</b> can be a wired or wireless connection. Communication link <b>659</b> is connected to the nSMM <b>610</b>. The nSMM <b>610</b> is coupled to a buss line <b>653</b> by communication link <b>615</b>. The foreign AAA server (FAAA) <b>621</b> is coupled to the buss line <b>653</b> by communication link <b>652</b>, and the DHCPv6 server <b>631</b> is coupled to the buss line <b>653</b> by communication link <b>633</b>.

0074The foreign network <b>700</b> is coupled to the Internet <b>670</b> by communication link <b>673</b>, which is coupled to buss line <b>653</b>. The Internet <b>670</b> is coupled to the home network <b>699</b> by communication link <b>671</b>, which is connected to buss line <b>654</b>.

0075The home network <b>699</b> includes the HAAA <b>620</b>, the HMM <b>640</b>, and the HAm <b>625</b>. A home AAA (HAAA) server <b>620</b> is coupled to buss line <b>654</b> by communication link <b>656</b>. A HMM <b>640</b> is connected to buss line <b>654</b> by communication link <b>617</b>, and HMM <b>640</b> is connected to HAm <b>625</b> by communication link <b>619</b>.

0076When the MN <b>664</b> powers up on foreign network <b>700</b>, <figref idref="DRAWINGS">FIG. 8</figref> shows the message flow under the new embodiment. This embodiment is referred to as an Inter-Domain Power Up Registration. The MN <b>664</b> sends a Reg Req <b>705</b> to the nSMM <b>610</b> on the foreign sub-network <b>700</b> to obtain a co-located, globally routable address. The format of the IP header for Reg Req <b>705</b> is the same as shown in FIG. <b>1</b>A. The nSMM <b>610</b> validates the identity of the MN <b>664</b> using coincidental information in the Reg Req <b>705</b>. After validation, the nSMM <b>610</b> transmits a DHCPv6 Req <b>710</b> to the DHCPv6 server <b>631</b>. The DHCPv6 server <b>631</b> allocates a co-located IP address to use as a care-of address and sends a DHCPv6 Res <b>715</b> back to the nSMM <b>610</b> with the new care-of address.

0077At this point, the nSMM <b>610</b> may generate and transmit an optional IP Offer message <b>720</b> to the MN <b>664</b> containing the care-of address for temporary use while registration is completed. The nSMM <b>610</b> will generate and transmit an AAA Registration and Authentication Request message (AAA Reg Req) <b>725</b> to the FAAA <b>621</b>. The FAAA <b>621</b> receives the AAA Reg Req <b>725</b> and forwards an AAA Registration and Authentication Response message (AAA Reg Res) <b>730</b> to the HAAA <b>620</b> based on the network access identifier extension (NAI) contained in the AAA Reg Req <b>725</b>.

0078When the HAAA <b>620</b> receives an AAA Reg Req <b>730</b>, it authenticates the identification and authorization of the MN <b>664</b>. If the MN <b>664</b> authentication and authorization are affirmative, the HAAA <b>620</b> forwards the AAA Reg Req <b>735</b> to the HMM <b>640</b>. The HMM <b>640</b> will process the AAA Reg Req <b>735</b>. If the MN <b>664</b> lacks a home IP address, the MN <b>664</b> will have requested allocation of one. If requested, the HMM <b>640</b> will allocate a home IP address for the MN <b>664</b>. If the home network <b>699</b> is provisioned with multiple home agents for load distribution, the HMM <b>640</b> may designate HAn <b>625</b> to serve the MN <b>664</b>. The HMM <b>640</b> will then construct an AAA Registration and Authentication Response message (AAA Reg Res) <b>740</b> with this information on the designated HAn <b>625</b> and the authentication data and transmit an AAA Reg Res <b>740</b> to the FAAA <b>620</b>.

0079The HAAA <b>620</b> will transmit an AAA Reg Res message <b>745</b> to the FAAA <b>621</b>, which will contain a care-of address for use by the MN <b>664</b> allocated by the DHCPv6 sever <b>631</b> and any home IP address allocated by the HMM <b>640</b> as well as affirmative confirmation of AAA. The FAAA <b>621</b> will transmit an AAA Reg Res <b>750</b> to nSMM <b>610</b>, and the nSMM <b>610</b> will generate and transmit a Reg Res <b>755</b> to the MN <b>664</b> containing the allocated care-of address and any home IP address. Once the MN <b>664</b> receives the Reg Res <b>755</b>, it sends a BU <b>760</b> to the HMM <b>640</b> or any assigned HAm <b>625</b>. The HMM <b>640</b> or HAm <b>625</b> will then respond with a BA <b>765</b>, completing the registration.

0080<figref idref="DRAWINGS">FIG. 9</figref> depicts the situation where a MN <b>864</b> has moved and does a hand-off from one foreign network <b>899</b> to a new foreign network <b>900</b>. <figref idref="DRAWINGS">FIG. 9</figref> shows three networks <b>898</b>, <b>899</b>, and <b>900</b>. The old foreign network <b>899</b> has an old FAAA server (oFAAA) <b>845</b>, an old SMM (oSMM) <b>810</b>, and a foreign agent (FA) <b>830</b>. The new foreign network <b>900</b> has a new FAAA server (nFAAA) <b>850</b>, a DHCPv6 server <b>860</b>, and a new SMM (nSMM) <b>815</b>. The home network <b>898</b> has a home AAA server (HAAA) <b>840</b>, a home mobility manager (HMM) <b>820</b>, and a home agent (HA) <b>825</b>.

0081On the old foreign network <b>899</b>, the FA <b>830</b> is connected to the oSMM <b>810</b> by communication link <b>831</b>. The oSMM <b>810</b> is connected to a central buss line <b>877</b> by communication link <b>811</b>, and the oFAAA <b>845</b> is connected to the central buss line <b>877</b> by communication link <b>812</b>. Although a wireless connection is shown linking MN <b>864</b> to nSMM <b>815</b>, alternatively the link connecting MN <b>864</b> to nSMM <b>815</b> could be a wired connection.

0082On the new foreign network <b>900</b>, the MN <b>864</b> is connected to transceiver <b>860</b> by wireless link <b>866</b>. The transceiver <b>860</b> is connected to the nSMM <b>815</b> by communication link <b>859</b>, and the nSMM <b>815</b> is connected to central buss line <b>871</b> by communication link <b>817</b>. The central buss line <b>871</b> is connected to nFAAA <b>850</b> by communication link <b>821</b> and to DHCPv6 server <b>860</b> by communication link <b>819</b>. On the home network <b>898</b>, the HAAA <b>840</b> is coupled to a central buss line <b>873</b> by communication link <b>841</b>. The HMM <b>820</b> is connected to the central buss line <b>873</b> by communication link <b>823</b>, and the HA <b>825</b> is connected to the HMM <b>820</b> by communication link <b>827</b>.

0083The three networks, <b>898</b>, <b>899</b>, and <b>900</b> are also connected to the Internet <b>870</b>. The old foreign network <b>899</b> is connected to the Internet <b>870</b> by communication link <b>881</b>, which is coupled to the central buss line <b>877</b>. The new foreign network <b>900</b> is connected to the Internet <b>870</b> by communication link <b>883</b>, which is coupled to the central buss line <b>871</b>. The home network <b>898</b> is connected to the Internet <b>870</b> by communication link <b>882</b>, which is coupled to central buss line <b>873</b>. MN <b>864</b>′ is shown moving from a location connected to oSMM <b>810</b> to a new location connected to nSMM <b>815</b>.

0084<figref idref="DRAWINGS">FIG. 10</figref> depicts the message flow for the embodiment where the MN <b>864</b> moves unexpectedly from one foreign network <b>899</b> to another foreign network <b>900</b> and performs a hand-off. This embodiment is referred to as a Reactive Inter-Domain Hand-off. The MN <b>864</b> sends a Reg Req <b>905</b> to the nSMM <b>815</b> to obtain a co-located, globally routable address. The format of the EP header for the Reg Req <b>905</b> is the same as shown in FIG. <b>1</b>A. The nSMM <b>815</b> validates the identity of the MN <b>864</b>, and then transmits a DHCPv6 Req <b>910</b> to the DHCPv6 server <b>860</b>. The DHCPv6 server <b>860</b> allocates a new address to use as a care-of address and sends a DHCPv6 Res <b>915</b> back to the nSMM <b>815</b>. At this point, an optional IP Offer message <b>920</b> containing the care-of address for temporary use until the registration process is complete may be sent to the MN <b>864</b> by nSMM <b>815</b>. The nSMM <b>815</b> sends an AAA System Hand-off and Context Request message (AAA SHC Req) <b>925</b> to oSMM <b>810</b> to allocate an agent, FA <b>830</b>, in the old foreign network <b>899</b>.

0085The oSMM <b>810</b> will allocate FA <b>830</b> to forward information packets to the MN <b>860</b> by generating and transmitting a BU <b>930</b> to the FA <b>830</b>. This will cause the FA <b>830</b> 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 <b>830</b> will respond with a BA <b>935</b> back to the oSMM <b>810</b> acknowledging the BU <b>930</b>.

0086The oSMM <b>810</b> will verify the AAA SHC Req <b>925</b> by sending an AAA System Hand-off and Context Response message (AAA SHC Res) <b>940</b> to the nSMM <b>815</b>. The nSMM <b>815</b> will verify the message and allocate a co-located care-of address for the MN <b>864</b>, which it will transmit to the MN <b>864</b>. The nSMM <b>815</b> will generate and transmit an AAA Registration and Authorization Request message (AAA Reg Req) <b>945</b> to the nFAAA <b>850</b>, which forwards the message to the HAAA <b>840</b> based on the network access identifier (NAI) extension in the MN <b>864</b> Reg Req <b>905</b>.

0087When the HAAA <b>840</b> receives the AAA Reg Req <b>945</b>, it authenticates the identification and authorization of the MN <b>864</b>. If the MN <b>864</b> authentication and authorization are affirmative, the HAAA <b>840</b> forwards an AAA Reg Req <b>950</b> to the HMM <b>820</b>. The HMM <b>820</b> will process the AAA Reg Req <b>950</b>. If the MN <b>864</b> lacks a home IP address, the MN <b>664</b> will have requested allocation of one. If requested, the HMM <b>820</b> will allocate a home IP address for the MN <b>864</b>. If the home network <b>699</b> supports more than one HA <b>825</b> for load distribution and balancing, the HMM <b>820</b> may designate a HA <b>825</b> to serve the MN <b>864</b>.

0088The HMM <b>820</b> will construct an AAA Registration and Authorization Response (AAA Reg Res) <b>955</b> with this information on the designated HA <b>825</b> and the authentication data and transmit the message back through the HAAA <b>840</b> and nFAAA <b>850</b> to nSMM <b>815</b>. The HAAA <b>840</b> will forward the AAA Reg Res <b>960</b> to nSMM <b>815</b>. The nSMM <b>815</b> will generate and transmit a Reg Res <b>965</b> to the MN <b>864</b> containing the allocated, co-located care-of address, any home address for the MN <b>864</b>, and confirmation of authorization and authentication. After receiving the Reg Res <b>965</b>, the MN <b>864</b> completes the registration by sending a BU <b>970</b> to the HMM <b>820</b> or any assigned HA <b>825</b>, which will acknowledge with a BA <b>975</b>.

0089<figref idref="DRAWINGS">FIG. 11</figref> shows an embodiment where MN <b>1064</b> is aware of moving prior to moving from old foreign network <b>999</b> to new foreign network <b>1000</b> and requests a hand-off prior to moving. <figref idref="DRAWINGS">FIG. 11</figref> shows three networks <b>998</b>, <b>999</b>, <b>1000</b>. The old foreign network <b>999</b> includes an oFAAA <b>1045</b>, an oSMM <b>1010</b>, and a FA <b>1030</b>. The new foreign network <b>1000</b> has an nFAAA <b>1050</b>, a DHCPv6 server <b>1060</b>, and an nSMM <b>1015</b>. The home network <b>998</b> has a HAAA <b>1040</b>, a HMM <b>1020</b>, and a HA <b>1025</b>.

0090On the old foreign network <b>999</b>, the FA <b>1030</b> is connected to the oSMM <b>1010</b> by communication link <b>1031</b>. The oSMM <b>1010</b> is connected to a central buss line <b>1077</b> by communication link <b>1011</b>, and the oFAAA <b>1045</b> is connected to the central line buss <b>1077</b> by communication link <b>1012</b>. The MN <b>1064</b> is connected to a transceiver <b>1060</b> by wireless link <b>1066</b>, and the transceiver <b>1060</b> is connected to the oSMM <b>1010</b> by communication link <b>1059</b>. Although a wireless link <b>1066</b> is shown, alternatively, MN <b>1064</b> could be connected to the oSMM <b>1010</b> by a wired communication link.

0091On the new foreign network <b>1000</b>, the nSMM <b>1015</b> is connected to a central line buss <b>1071</b> by communication link <b>1017</b>. The DHCPv6 <b>1060</b> is connected to the central buss line by communication link <b>1019</b>, and an nFAAA <b>1050</b> is connected to the central buss line <b>1071</b> by communication link <b>1021</b>.

0092On the home network <b>998</b>, the HAAA <b>1040</b> is coupled to a central buss line <b>1073</b> by communication link <b>1041</b>. The HMM <b>1020</b> is connected to the central buss line <b>1073</b> by communication link <b>1023</b>, and the HA <b>1025</b> is connected to the HMM <b>1020</b> by communication link <b>1027</b>.

0093The three networks <b>998</b>, <b>999</b>, and <b>1000</b> are also connected to the Internet <b>1070</b>. The old foreign network <b>999</b> is connected to the Internet <b>1070</b> by communication link <b>1081</b>, which is coupled to the central buss line <b>1077</b>. The new foreign network <b>1000</b> is connected to the Internet <b>1070</b> by communication link <b>1083</b>, which is coupled to the central buss line <b>1071</b>. The home network <b>998</b> is connected to the Internet <b>1070</b> by communication link <b>1082</b>, which is coupled to the central buss line <b>1073</b>. The MN <b>1064</b>′ connected to nSMM <b>1015</b> is the location the MN <b>1064</b> is moving to.

0094<figref idref="DRAWINGS">FIG. 12</figref> shows the message flow for the embodiment where the MN <b>1064</b> lacks Layer-2 connectivity to a new foreign network <b>1000</b> it is aware it is moving to and performs a hand-off to move to the new foreign network <b>1000</b>. This embodiment is referred to as a Proactive Inter-Domain Hand-off. The MN <b>1064</b> sends a System Hand-off Request message (SHO Req) <b>1105</b> to the oSMM <b>1010</b> when it detects that it is moving to new foreign network <b>1000</b>. The format of the IP header for SHO Req <b>1105</b> is the same as shown in FIG. <b>1</b>A. The oSMM <b>1010</b> sends an AAA Hand-off and Context Transfer Request message (AAA HCT Req) <b>1110</b> to the future nSMM <b>1015</b> via the oFAAA <b>1045</b> on the old foreign network <b>999</b> and nFAAA <b>1050</b>. The nSMM <b>1015</b> transmits a DHCPv6 Req <b>1115</b> to the DHCPv6 <b>1060</b> to obtain a new address to use as a care-of address. The DHCPv6 <b>1060</b> allocates an EP address and sends a DHCPv6 Res <b>1120</b> back to the nSMM <b>1015</b> with a care-of address. The nSMM <b>1015</b> then generates and transmits an AAA Hand-off and Context Transfer Response message (AAA HCT Res) <b>1125</b> to the oSMM <b>1010</b> again via the nFAAA <b>1050</b> and oFAAA <b>1045</b> with the care-of address.

0095The oSMM <b>1010</b> allocates a FA <b>1030</b> to bi-cast data destined for the MN <b>1064</b> to both the old and new care-of address by transmitting a BU <b>1130</b>, and the FA <b>1030</b> will transmit a BA <b>1135</b> back to the oSMM <b>1010</b>. The oSMM <b>1010</b> will then send a System Hand-off Response message (SHO Res) <b>1140</b> back to the MN <b>1064</b> to confirm executing the hand-off and transmitting the co-located care-of address to the MN <b>1064</b>.

0096When the MN <b>1064</b> receives the SHO Res <b>1140</b> from the oSMM <b>1010</b> and establishes Layer 2 connectivity to the new foreign network <b>1000</b>, it will transmit a Reg Req <b>1145</b> to the nSMM <b>1015</b>. The nSMM <b>1015</b> will then construct and transmit an AAA Registration Request message (AAA Reg Req) <b>1150</b> to the HAAA <b>1040</b> via nFAAA <b>1050</b>. The HAAA <b>1040</b> will authenticate the MN <b>1064</b>. If the MN <b>1064</b> authentication and authorization is affirmative, the request is forwarded to the HMM <b>1020</b> for further processing by an AAA Reg Req <b>1155</b>.

0097The HMM <b>1020</b> updates the user state information, allocates HA <b>1025</b> to serve MN <b>1064</b>, and constructs an AAA Registration Response message (AAA Reg Res) <b>1160</b> to transmit to the HAAA <b>1040</b> conveying the data. When the HAAA <b>1040</b> receives the Reg Res <b>1160</b>, it in turn generates and transmits an AAA Reg Res <b>1165</b> to the nSMM <b>1015</b> via nFAAA <b>1050</b>. The nSMM <b>1015</b> then sends a Reg Res <b>1170</b> to the MN <b>1064</b> conveying the information. Once the MN <b>1064</b> receives a Reg Res <b>1170</b>, it proceeds to complete registration by sending a BU <b>1175</b> containing the care-of address to the HA <b>1025</b>, which acknowledges with a BA <b>1180</b>.

0098As a further alternative embodiment in each of these embodiments the mobility managers (SMM <b>10</b>, HMM <b>40</b>, nSMM <b>210</b>, oSMM <b>212</b>, HMM <b>240</b>, nSMM <b>410</b>, oSMM <b>412</b>, HMM <b>440</b>, nSMM <b>610</b>, HMM <b>640</b>, oSMM <b>810</b>, nSMM <b>815</b>, HMM <b>820</b>, oSMM <b>1010</b>, nSMM <b>1015</b>, and HMM <b>1020</b>) 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 (<b>110</b>, <b>310</b>, <b>615</b>, <b>710</b>, <b>910</b> and <b>1115</b>) and the DHCPv6 Response message (<b>115</b>, <b>315</b>, <b>620</b>, <b>715</b>, <b>915</b>, and <b>1120</b>) are eliminated. In place of these messages (<b>110</b>, <b>115</b>, <b>310</b>, <b>315</b>, <b>615</b>, <b>620</b>, <b>710</b>, <b>715</b>, <b>910</b>, <b>915</b>, <b>1115</b>, and <b>1120</b>) the SMM <b>10</b>, nSMM <b>210</b>, nSMM <b>410</b>, nSMM <b>610</b>, nSMM <b>815</b>, and nSMM <b>1015</b> will periodically request a new pool of addresses from the DHCPv6 server to allocate as care-of addresses.

0099While 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.