Patent Document

CLAIM OF PRIORITY UNDER 35 U.S.C §119 
     The present Application for Patent claims priority to U.S. Provisional Application No. 60/561,955, entitled “Service Based Policy for Mobile IP Co-location Care of Address,” filed Apr. 13, 2004, and assigned to the assignee hereof and hereby expressly incorporated by reference herein. 
    
    
     BACKGROUND 
     I. Field 
     The present invention generally relates to packet data communications, and more particularly, to wireless multimedia packet data communications using separate communication paths for signaling and for content transmitting. 
     II. Background 
     Interconnecting of networks globally allows information to be swiftly accessed irrespective of geographical distances.  FIG. 1  shows a simplified schematic drawing of the global connection of networks, commonly referred to as the Internet signified by the reference numeral  20 . The Internet  20  is in essence many networks with different levels of hierarchy linked together. The Internet  20  is operated under the IP (Internet Protocol) promulgated by the IETF (Internet Engineering Task Force). Details of the IP can be found in RFC (Request For Comments) 791 published by the IETF. 
     Connected to the Internet  20  are various individual networks, sometimes called LANs (Local Area Networks) or WANs (Wide Area Networks) depending on the network sizes. Shown in  FIG. 1  are some of such networks  22 ,  24 ,  26  and  28  tied to the Internet  20 . 
     Within each of the networks  22 ,  24 ,  26  and  28 , there can be various pieces of equipment connected to and in communication with each other. Examples are computers, printers, and servers, to name just a few. Each piece of equipment has a unique hardware address, commonly called the MAC (Media Access Control) address. The piece of equipment with the MAC address is sometimes called a node. When the node communicates beyond its own network via the Internet  20 , an IP address needs to be assigned to the node. 
     The assignment of the IP address can be manual or automatic. The manual assignment of the IP address can be performed by a network administrator, for example. More often, the IP address is automatically assigned. For instance, in a LAN, the IP address can be assigned by a server called the DHCP (Dynamic Host Control Protocol) server residing inside in the node&#39;s LAN. In a WAN which supports wireless technologies, IP address can even be assigned automatically and remotely. 
     Returning now to  FIG. 1 , as an example, suppose a node  30  in the network  22  attempts to send a data packet to another node  32  in the network  28 . Under the IP, each data packet needs to have a source address and a destination address. In this case, the source address is the address of the node  30  in the network  22 , and the address is called the HoA (Home Address). The destination address is the address of the node  32  in the network  28 . 
     As another example, when the node  30  in the network  22  tries to retrieve information from the node  34  in another network  24 , such as in a web hosting session in which the node  34  serves as a web server, the node  30  must provide a proper IP address of the node  34  in the network  24  for such a session. 
     Advent in wireless technologies allows nodes to move away from their originally registered network to another network. For instance, referring back to  FIG. 1 , the node  30 , instead of permanently wired to the network  22 , can be a wireless device, such as a PDA (Personal Device Assistant), a cellular phone, or a mobile computer. The wireless node  30  can travel beyond the boundary of its home network  22 . Thus, for instance, the node  30  may roam away from its home network  22  to a foreign network  26 . Under such scenario, the original HoA assigned to the node  30  would no longer be applicable to the node  30 . As such, data packets destined to the HoA of the node  30  may not be reachable to the node  30 . 
     The MIP (Mobile Internet Protocol) set forth by the IETF is intended to address the node mobility problems. In accordance with the RFC 2002 published by the IETF, whenever away from the home network  22  and roaming in another network, the node  30  is assigned a “care-of address,” abbreviated as CoA (Care-of Address). Under the RFC 2002, there are two types of CoA, namely, the FA CoA (Foreign Agent Care-of Address) and the CCoA (Co-located Care of Address). 
     The FA CoA is in essence the address of a FA (Foreign Agent) which is a designated server in the foreign network where the node  30  is located at. 
     The CCoA is an individual but temporary address assigned to the node  30  by the foreign network. 
     In any case, anytime the node  30  is in a foreign territory, the node  30  must register the CoA, be it the FA CoA or the CCoA, with its home network  22 , so that the home network  22  always knows the whereabouts of the node  30 . After registration, the CoA is stored in the routing table maintained by a designated server, called the HA (Home Agent)  25  of the home network  22 . 
     Take a couple of examples for illustration. 
     For the case of the FA CoA, suppose the node  30  roams into the foreign network  26 . Upon reaching the territorial limit of the foreign network  26 , the node receives an advertisement message from the foreign network  26  informing the node  30  of its presence in the foreign territory. From the advertisement message, the node knows the address of the FA  36  of the foreign network  26 . The node  30  then registers the FA CoA with the HA  25  in the home network  22 . 
     When the node  30  in the foreign network  26  sends out a data packet to the node  34  in the network  24 , for example, knowing the address of the node  34  in the network  24 , the data packet can be sent straightforwardly. That is, in accordance with the IP, in the data packet, the source address can be set to the HoA of the node  30  and the destination address can be set to the address of the node  34  in the network  24 . The direction of the data packet is shown as data path  38  shown in  FIG. 1 . 
     As for the reverse data traffic, it is not as straightforward. In the reverse data route, when the node  34  in the network  24  attempts to send a data packet to the node  30 , now in the foreign network  26 , as mentioned above, in conformance with the IP, both the source and the destination addresses must be specified in the data packet. In this case, the source address is the IP address of the node  34  in the network  24 . As for the destination address, the node  34  only knows the HoA of the node  30 , not the FA CoA of the node  30 . Thus, the destination address will be set to the HoA of the node  30 . Nevertheless, since the FA CoA of the node  30  is stored in the routing table of the HA  25  in the home network  22 , when the data packet reaches the home network  22 , the HA  25  of the network  22  encapsulates the received data packet with the stored FA CoA and sends it to the node  30  in the foreign network  26 . That is, the encapsulated data packet utilizes the FA CoA as the destination address. Once the foreign network  26  receives the encapsulated data packet, the FA  36  merely strips away the encapsulated FA CoA and delivers the original packet to the mobile node  30 . The route of the data packet is shown as data path  40  in  FIG. 1 . 
     It also be noted that the data paths, such as paths  38  and  40 , in reality pass through the Internet  20  many times. For the sake of clarity so as not to obscure  FIG. 1 , the paths merely are shown as passing through the relevant servers, such as the HA  25  and the FA  36 . That is, the data paths  38  and  40  are shown as logical paths as shown in  FIG. 1 . 
     Operating in the manner as described above, the mobile node is said to be communicating with the correspondent node  34  under the MIP using FA CoA. 
     As for the case of the CCoA, when the node  30  roams away from the home network  22 , instead of requesting for a FA CoA, the node  30  can instead request a CCoA via a DHCP server in any foreign network where the node  30  is located at, for example. It should be noted that, if the network  26  is a WAN supporting wireless technologies such as the cdma2000 standards promulgated by the TIA/EIA (Telecommunications Industry Association/Electronic Industries Association), the CCoA can be requested and assigned remotely by the foreign network  26  via a PPP (Point to Point Protocol) as set forth in the MIP. However, other than the assignment of the CCoA by the foreign network  26 , the node  30  performs all the functions of a foreign agent, such as the FA  36 . Again, the MN  48  needs to register the CCoA with the HN  44 . 
     For instance, to correspond with node  34  in the network  24 , the node  30  sends out a data packet with two layers of addresses. In the outer layer, the source address is set as the CCoA, and the destination address is set as the HA  25 . In the inner layer, the source address is the HoA of the node  30  and the destination address is the address of the node  34  in the foreign network  24 . Upon receipt of the data packet from the roaming node  30 , the HA  25  strips off the outer address layer and sends the data packet to the node  34  with the inner address layer. The logical path of the data packet is shown as data path  42  in  FIG. 1 . 
     In the reverse data path, that is, when the node  34  sends a data packet to the node  30 , the data packet has only one address layer with the source address set to the node  34  and the destination address set to the HoA of the node  30 . Upon receipt of the data packet, the HA  25  encapsulates the data packet with the CCoA as the destination address and the address of the HA  25  as the source address and sends the encapsulated data packet to the node  30 . The node  30  performs the de-encapsulating on its own without going through the FA  36 . The direction of the data packet is shown as data path  44  in  FIG. 1 . 
     Operating in the manner as described above, the roaming node  30  is said to be communicating with the correspondent node  34  under the MIP using the CCoA. 
     Irrespective of whether the node  30  uses the FA CoA or the CCoA, to communicate with other networks under the MIP while the node  39  is roaming, there are considerable traffic detours of data paths as exemplified by the logical data paths  40 ,  42 , and  44  shown in  FIG. 1 . That is, data packets have to pass through intermediate networks before reaching the destination. Such traffic detours do not pose much of a problem in certain types of data, such as data in a file transfer. Under the TCP (Transmission Control Protocol) as set forth in the RFC 793, the data packets merely take a longer time to reach the destination. It is also well known that data packets passing through longer data paths are more susceptible to transmission errors. Nevertheless, the defective packets can always be resent, albeit further slowing down the overall data transmission process. However, for other types of data, such as in an audio or video call, accurate access of real-time information is of significant importance. Excessive detours of data routes introduce additional latency during the data delivery processes. Furthermore, for data packet sent under the UDP (User Datagram Protocol) as set forth in the RFC 768, erroneous packets are not normally re-transmitted but simply dropped. As a consequence, quality of service can be undermined. 
     Accordingly, there is need to provide better real-time data access in a wireless communication system. 
     SUMMARY 
     In a communication system in which a mobile node seeks a communication session with a correspondent node by first signaling for initialization of the communication session through a first data path via an intermediate node. Thereafter, contents of the communication session is established through a second data path in which the mobile node and the correspondent node communicate straightforwardly without going through the intermediate node. 
     In accordance with one embodiment, the mobile node roams from its home network to a foreign network. Using a first address, the mobile node signals for initiation of the communication session with the correspondent node via a home agent in the home network. The home agent in turn relays the initiation signaling to the correspondent node locating at a remote network. Upon acceptance by the correspondent node, the mobile node uses a second address to transmit contents of the communication session straightforwardly through a direct data path between the mobile node and the correspondent node, without passing through the home agent. Consequently, with the shorter data path, transmission latency and transmission errors are curtailed, resulting in higher quality of service. These and other features and advantages will be apparent to those skilled in the art from the following detailed description, taken together with the accompanying drawings, in which like reference numerals refer to like parts. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is a schematic drawing of the global connection of networks; 
         FIG. 2  is a schematic drawing showing an embodiment of the invention; 
         FIG. 3  is a flowchart showing the steps for initiation signaling and establishing content traffic in accordance with the embodiment of the invention; 
         FIG. 4  is a flowchart showing the steps of continuating with the content flow by the process of update signaling in accordance with the embodiment of the invention; and 
         FIG. 5  is a schematic drawing of the circuitry of a mobile node configured in accordance with the invention. 
     
    
    
     DETAILED DESCRIPTION 
     The following description is presented to enable any person skilled in the art to make and use the invention. Details are set forth in the following description for purpose of explanation. It should be appreciated that one of ordinary skill in the art would realize that the invention may be practiced without the use of these specific details. In other instances, well-known structures and processes are not elaborated in order not to obscure the description of the invention with unnecessary details. Thus, the present invention is not intended to be limited by the embodiments shown, but is to be accorded with the widest scope consistent with the principles and features disclosed herein. 
     The embodiments described below are operable according to the IMS/MMD (IP Multimedia Subsystem/Multimedia Domain) standards promulgated by the 3 rd  Generation Partnership Project (3GPP) and the 3 rd  Generation Partnership Project 2 (3GPP2). A general discussion of the IMS/MMD can be found in published documents, entitled “3 rd   Generation Partnership Project: Technical Specification Group Services and System Aspects, IP Multimedia Subsystem  ( IMS ),  Stage  2,” 3GPP TS 23.228 “3 rd   Generation Partnership Project: Technical Specification Group Core Network, End - to - end Quality of Service  ( QoS )  Signaling Flows,”  3GPP TS 29.208; and  “IP Multimedia System, Stage  2,” TIA-873-002 and 3GPP2 X.P0013-012. 
     IMS is applicable in a wide variety of standards such as the cdma2000 by the TIA/EIA, WCDMA by the 3GPP, and various other WANs. 
     Reference is now directed to  FIG. 2  which schematically shows an exemplary embodiment of the invention. The overall system is generally signified by the reference numeral  50  which includes a backbone network  52 , such as an intranet or the Internet. 
     By way of example, as shown in  FIG. 2 , connected to the backbone network  52 , among other networks, are a HN (Home Network)  54 , a FN (Foreign Network)  56 , another FN  57 , and a RN (Remote Network)  58 . 
     In the HN  54 , there is a HA (Home Agent)  62  which assumes the duty of managing data traffic within the HN  54  and also for controlling the data traffic of the HN  54  for inbound and outbound routing. Furthermore, there is a PDSN (Packet Data Serving Node)  64  which in essence is an access gateway between the backbone network  52  and the radio access portion of the HN  54 . 
     To execute the various IMS/MMD functions and features, service providers installed different servers in the HN  54 . Examples of such servers include a P-CSCF (Proxy Call State Session Function) server  70 , and a S-CSCF (Serving Call State Session Function) server  72 . The functional description of these servers will be depicted later along with the operational illustration of the system  50 . 
     In addition to the nodes described above, there are other nodes within the HN  54  but are not shown for purpose of clarity. Such nodes can be computers of various scales, printers, and any other devices which can be mobile or non-mobile. 
     Shown in  FIG. 2  are FNs  56  and  57  linked to the backbone network  52 . Furthermore, for simplicity and ease of explanation, the FN  56  and the RN  58  are illustrated as somewhat similar to the HN  54 . It should be appreciated that, depending on usage, the FN  56  and RN  58  can be structured very differently. Thus, in this case, the FN  56  also includes, among other things, a FA (Foreign Agent)  66 , a PDSN  68 , a P-CSCF  71 , and a PDF (Policy Decision Function)  75 . Likewise, the RN  58  also includes, among other things, a PDSN  78 , a P-CSCF  80 , a S-CSCF  82 , and a PDF  84 . 
     In the system  50 , there is a MN (Mobile Node)  60  which is originally registered with the HA  62  in the HN  54  with a HoA (Home Address). The MN  60  is capable of migrating to other foreign networks, such as the FN  56  or the FN  57 , and can gain access to the backbone network  52  via the FN  56  or the FN  57  under the MIP (Mobile Internet Protocol). 
     Suppose the MN  60  is roaming in the FN  56 . In this specific example, assume the user of the MN  60  wants to have a video conferencing session with a another user operating a CN (Correspondent Node)  90  in the RN  58 . The node  90  can be mobile or non-mobile. 
     Conventionally, upon reaching the territory of the FN  56 , the MN  60  acquires the address of the FA  66  via advertisement by the FN  56 . The MN  60  then registers the FA CoA with the HA  62  in the HN  54  so that the HA  62  can keep track of the locality of the MN  60 . 
     Thereafter, the MN  60  in the FN  56  sends a message to the P-CSCF  70  in the HN  54  to initiate the conferencing session. The initial signaling path for the request starts from the FN  56  to the HN  54  before reaching the RN  58 . Likewise, if the conferencing session request is approved, the response signaling path is the reverse of the request path, that is, from the RN  58 , to the HN  54  and then the FN  56 . Upon approval of the request, the bearer traffic, that is, the traffic of the media flow which contains the audio and video contents of the conferencing session propagates more or less along the directions of the signaling paths. That is, the logical path of the bearer traffic flows from MN  60  in the FN  56 , and then to the HA  62  in the HN  54  and finally to the RN  58  before reaching the CN  90 , and vice versa. As mentioned above, such meandering of data traffic adds latency to the packet data. Furthermore, transmission errors are also more prone to occur. 
     In the embodiment described below, a different approach is adopted. The data paths for the bearer traffic are chosen to be substantially different from the session initiation signaling paths. 
     With reference to  FIG. 2 , to begin with, suppose the MN  60  roams away from the HN  54  toward the FN  56 . Upon reaching the territory of the FN  56 , the MN  60  receives an advertisement message from the FN  56 . From the message, the MN MN  60  derives the address of the FA  66 . Thereafter, the MN  60  reports back to the HN  54  by registering the address of the FA  66  with the HA  62 . The registered address is called the FA CoA which is stored in the routing table of the HA  62  in the HN  54 . 
     Again, suppose the user of the MN  60  wants to have a video conferencing session with the user of the CN  90  in the RN  58 . 
     First, the MN obtains a CCoA from the FN  56 . Using the HoA originally assigned by the HA  62  in the HN  54 , the MN  60  registers the CCoA with the HA  62  in the HN  54 . The MN  60  also registers with the S-CSCF  72  in the HN  54  using the HoA for the access of the SIP (Session Initiation Protocol) network in the HN  54 . 
     The MN  60  then sends a SIP INVITE message to the P-CSCF  70  in the HN  54 . It should be noted that in actual operation, as with all other data traffic, the SIP INVITE message first goes through the PDSN  68  and the HA  62  before routing to the P-CSCF  70 . Furthermore, as well known in the art, the data traffic is in the form of electrical signals via a carrier wave traveling through the system  50 . For the sake of clarity in a manner similarly described above, the data traffic is illustrated as logical paths. That is, in the following description, unless specifically highlighted, only the logical paths of the data traffic are depicted. 
     It further should be noted that the MN  60  can send the SIP INVITE message to the P-CSCF  71  in the FN  56  to initiate the conferencing session as an alternative. For conciseness in explanation, in the following description, the P-CSCF  70  in the HN  54  is used for the conference session initiation. 
     Returning to  FIG. 2 , the SIP INVITE message includes a description portion called the SDP (Session Description Protocol) which in essence describes the basic requirements for the proper execution of the requested video conferencing session. For instance, included in the SDP are the IP address and port numbers of the MN  60 , and the codec specification for the session. More importantly, in this embodiment, the SDP includes the CCoA of the MN  60  for the media flow, that is the bearer traffic. 
     The P-CSCF  70  in the HN  54  is a node assuming the duty of call session management. Upon receipt of the SIP INVITE message, the P-CSCF  70  generates a token unique to the requested session. The P-CSCF  70  then forward the SIP INVITE message to the S-CSCF  72  in the HN  54 . The C-CSCF  72  in turn sends the SIP INVITE message to the RN  58  for request of acceptance. 
     Upon approval of the session by the S-CSCF  72  and the acceptance of the conferencing session by the CN  90  in the RN  58 , the P-CSCF  70  sends the token to the MN  60 . With the token in hand, the MN  60  in turn sends the token along with the requested QoS (Quality of Service) to the PDSN  68  in the FN  56  to set up the bearer traffic, that is, the media flow of audio and video signals of the conferencing session. 
     The PDSN  68  then requests the authorized QoS for the conferencing session from the PDF  75 , which then relays the request to the P-CSCF  70  in the HN  54 . Any parameters granted by the PDF  75  have to be in conformance with certain mandated polices. Such policies may include rules dictated under the IMS/MMD standards, specific agreements among networks, such as agreements between the HN  54  and the FN  56  relating to the handling of the bearer traffic, policies particular to a network, such as policies unique only to the FN  56 . 
     The PDF  75  is installed for the decision of all the imposed polices. In the decision process, the PDF  75  is interposed between the P-CSCF  71  and the PDSN  68  in the FN  56 . Furthermore, there is a Go interface  92  interposed between the PDSN  68  and the PDF  75 . There is yet another Gq interface  94  disposed between the PDF  75  and the P-CSCF  71 . The Go and Gq interfaces  92  and  94  are used for policy control between the conferencing session and the bearer traffic. Details of the Go and Gq interfaces can be found in the documents, 3GPP TS 23.107 published by 3GPP, and 3GPP2 X.P0013-012 published by 3GPP2. 
     Returning now to  FIG. 2 , the requested session parameters, if authorized, are passed to the PDSN  68  from the P-CSCF  70  and the PDF  75 . 
     In this embodiment, the CN  90  is assumed to have a CCoA which is assigned by the RN  58 . Thus, upon receipt of the SIP INVITE messages, the CN  90  responds back with a SIP  200  OK message. The SIP  200  OK message basically reaffirms the parameters of the original SIP INVITE message. The SIP  200  OK follows the same data path as the SIP INVITE message but in the reverse order. 
     The MN  60  then confirms the receipt of the SIP  200  OK message by sending an acknowledge message (ACK) back along the same data path as the original SIP INVITE MESSAGE. 
     Bearer traffic is thereafter established by the PDSN  68  in the FN  56  in accordance with the authorized parameters as set forth in the SIP INVITE message. In  FIG. 2 , the bearer data paths are shown as the video path  100  and the audio path  102  directly linking the nodes  60  and  90  via their respective CCoA addresses. The bearer traffic in the manner as described can sometimes be labeled as establishing data traffic using the CCoA under the simple IP, as different from the data paths  42  and  44  in which the data paths are said to be set up using the CCoA under the MIP, as shown and described in  FIG. 1 . 
     In this embodiment, in the SIP INVITE, to specify the proper traffic flow, both the MN  60  and the CN  90  use their corresponding CCoAs. The CCoA of the CN  90  can be assigned by the PDSN  78  of the RN  58 , for example. The CCoA of the MN  60  is assigned by and via a request to the PDSN  68  in the FN  56 , for instance. A CCoA acquired in the manner as aforementioned is very often referred to as the “simple IP address.” 
     The process as stated above is shown in the flowchart of  FIG. 3 . 
     When the MN  60  roams to yet another network away from the FN  56 , for instance, to the FA  57 , the MN  60  obtains a new CCoA from the new FN  57 . Thereafter, the MN  60  registers the new CCoA with the HA  62  in the HN  54 . Since the MN  60  has previously used the HoA to register with the S-CSCF  72 , the MN need not perform another SIP registration. In this embodiment, the MN  60  merely sends a SIP UPDATE message with the new CCoA to the CN  90  in a manner substantially similar to the sending of the SIP INVITE message as previously described. For the sake of conciseness, the logical flow of the SIP UPDATE message is not further repeated here, but is shown in the flowchart of  FIG. 4 . 
     Reference is now returned to  FIG. 2 . Once the bearer traffic identified by the data paths  100  and  102  is established, in accordance with the IMS standards, the PDSN  68  enforces a set of policies called the SBBC (Service Based Bearer Control) under the directions of the PDF  75 . The enforcement of the SBBC is continuous until the session between the MN  60  and the CN  90  is terminated. 
     The policies include in the SBBC can be, among other things, authorization of the requested QoS for the session, charging of the individual bearer flows, and policing of bearer traffic. To meet this end, the PDSN  68  monitors the media flow in the bearer paths  100  and  102 . The operational details of the SBBC can be found in the document entitled, “3 GPP 2 MMD Service Based Bearer Control Document, Work in Progress,”  3GPP2 X.P0013-012. Descriptions of the SDP can be found in the document, entitled “IP Multimedia Call Control Protocol Based on Sip and SDP), Stage 3: TIA-873-004; and RFC 2327. 
     Operating in the manner as described above, contents of the media flow can be sent and received straightforwardly as identified by the bearer traffic paths  100  and  102  shown in  FIG. 2 . Unnecessary detours of the data paths can be curtailed, resulting in faster and more accurate real-time data access. 
       FIG. 5  schematically shows the part of the hardware implementation of a mobile node apparatus signified by the reference numeral  120  in accordance with the invention. The apparatus  120  can be built and incorporated in various devices, such as a laptop computer, a PDA (Personal Digital Assistant) or a cellular phone. 
     The apparatus  120  comprises a central data bus  122  linking several circuits together. The circuits include a CPU (Central Processing Unit) or a controller  124 , a receive circuit  126 , a transmit circuit  128 , and a memory circuit  130 . 
     The receive and transmit circuits  126  and  128  can be connected to a RF (Radio Frequency) circuit but is not shown in the drawing. The receive circuit  126  processes and buffers received signals before sending out to the data bus  122 . On the other hand, the transmit circuit  128  processes and buffers the data from the date bus  122  before sending out of the device  120 . The CPU/controller  124  performs the function of data management of the data bus  122  and further the function of general data processing, including executing the instructional contents of the memory circuit  130 . 
     The memory circuit  130  includes a set of instructions generally signified by the reference numeral  131 . In this embodiment, the instructions include, among other things, portions such as the MIP client  132  and the SIP client  134 . The SIP client  134  includes the instructional sets in accordance with the invention as described previously. The MIP client  132  includes the instructional sets for allowing the apparatus  120  to operate under the IP and the MIP, such as acquiring various types of addresses for various uses, also as described above. 
     In this embodiment, the memory circuit  130  is a RAM (Random Access Memory) circuit. The exemplary instruction portions  132  and  134  are software modules. The memory circuit  130  can be tied to another memory circuit (not shown) which can either be of the volatile or nonvolatile type. As an alternative, the memory circuit  130  can be made of other circuit types, such as an EEPROM (Electrically Erasable Programmable Read Only Memory), an EPROM (Electrical Programmable Read Only Memory), a ROM (Read Only Memory), a magnetic disk, an optical disk, and others well known in the art. 
     Finally, described in the embodiments are only few networks tied to a backbone network. It should be apparent that a multiplicity of networks can be involved. Furthermore, described in the embodiment, the node  60  is depicted as a mobile device roaming through different foreign networks. It should be understand that the corresponding network node  90  can be stationary. The node  90  can also be mobile, and when reaching another foreign network, performs procedures and status update in a manner similar to that required of the node  60 . Moreover, the process of signaling for initiation of the communication session need not be confined to the use of the HoA as described in the embodiment. A CCoA can be used instead of the HoA in the signaling process. In addition, any logical blocks, circuits, and algorithm steps described in connection with the embodiments can be implemented in hardware, software, firmware, or combinations thereof. It will be understood by those skilled in the art that theses and other changes in form and detail may be made therein without departing from the scope and spirit of the invention.

Technology Category: 5