HK1105265A - Multimedia communication using co-located care of address - Google Patents

Description

Multimedia communication using collocated care-of addresses

Priority under claim 35 U.S.C § 119

The present application claims priority from U.S. provisional application, entitled "Service Based policy for Mobile IP Co-location Care of Address", filed on 13.4.2004, and having application number 60/561,955, assigned to the assignee hereof and incorporated herein by reference.

Technical Field

The present invention relates generally to packet data communications, and, more particularly, to wireless multimedia packet data communications using separate communication paths for signaling and for content transmission.

Background

The worldwide web interconnection allows information to be quickly accessed regardless of geographic distance. Fig. 1 shows a simplified schematic of the global network connection, generally referred to as the internet indicated by reference numeral 20. The internet 20 is actually many networks with different hierarchical levels of links to each other. The internet 20 operates under IP (internet protocol) promulgated by IETF (internet engineering task force). Details of IP can be found in RFC (request For comments)791 published by IETF.

Connected to the internet 20 are a variety of individual networks, sometimes referred to as LANs (local area networks) or WANs (wide area networks) depending on the size of the network. Shown in fig. 1 are some such networks 22, 24, 26, and 28 connected to the internet 20.

Within each network 22, 24, 26, and 28, there are a wide variety of devices connected to and in communication with each other. Such as computers, printers, and servers. Each device has a unique hardware address commonly referred to as a MAC (media access control) address. Devices with MAC addresses are sometimes referred to as nodes. When a 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 may be manual or automatic. For example, manual assignment of IP addresses may be performed by a network administrator. It is more common that IP addresses are automatically assigned. For example, in a LAN, an IP address may be assigned by a server called a DHCP (dynamic host control protocol) server located in the node's LAN. In a WAN that supports wireless technology, the IP address may even be assigned automatically or remotely.

Returning to fig. 1, as an example, assume a node 30 in network 22 attempts to send a data packet to another node 32 in network 28. To be assisted by 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 this address is called HoA (home address). The destination address is the address of a node 32 in the network 28.

As another example, when a node 30 in the network 22 attempts to retrieve information from a node 34 in another network 24, for example, in a web-hosting session in which the node 34 acts as a web server, the node 30 must provide the correct IP address of the node 34 in the network 24 for the session.

The advent of wireless technology allows nodes to move from the network they were originally registered with to other networks. For example, referring to FIG. 1, node 30, instead of being permanently wired to network 22, may be a wireless device, such as a PDA (personal device Assistant), a cellular telephone, a mobile computer. The wireless node 30 may move outside the boundaries of its home network 22. Thus, for example, the node 30 may roam from its home network 22 to the foreign network 26. In this case, the initial HoA assigned to node 30 is no longer applicable to node 30. Thus, a data packet targeting the HoA of node 30 may not reach node 30.

MIP (mobile internet protocol) proposed by IETF is intended to solve the node mobility problem. According to RFC 2002 issued by the IETF, nodes are assigned to "care-of addresses", shortly called coas (care-of addresses), whenever leaving the home network 22 and roaming in one network. Under RFC 2002, there are two types of CoA, namely, FA CoA (Foreign Agent Care-of Address) and CcoA (Co-located Care of Address) (Co-located Care-of Address).

The FA CoA is actually an address of an FA (foreign agent), which is a designated server in the foreign network in which the node 30 is located.

A CCoA is a separate but only temporary address assigned to the node 30 by the external network.

In any case, any time the node 30 is within the foreign region, the node 30 must register a CoA (FA CoA or CCoA) with the home network 22 so that the home network 22 always knows where the node 30 is. After registration, the CoA is stored in a routing table maintained by a designated server, referred to as HA (home agent) 25, of the home network 22.

Some examples are given below for illustration.

In the case of an FA CoA, it is assumed that the node 30 roams into the foreign network 26. Upon reaching the regional boundary of the foreign network 26, the node receives an advertisement message from the foreign network 26 informing that the node 30 is located in the foreign region. 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 a node 30 located in the external network 26 sends out a data packet to a node 34 in the network 24, the data packet may be sent directly, for example, if the address of the node 34 in the network 24 is known. That is, the source address may be set to the HoA of the node 30 and the destination address may be set to the address of the node 34 in the network 24, depending on the IP in the data packet. The direction of the data packets is shown as data path 38 shown in fig. 1.

As a reverse data service, it is not straightforward. In reverse data routing, when a node 34 located in the network 24 attempts to send a data packet to a node 30 now located in the foreign network 26 according to IP, the source and destination addresses must be specified in the data packet as described above. In this case, the source address is the IP address of the node 34 in the network 24. As the destination address, the node 34 only knows the HoA of the node 30, and does not know the FA CoA of the node 30. Thus, the destination address will be set to the HoA of node 30, rather than the FA HoA of node 30. However, since the FA CoA of the node 30 is stored in the routing table of the HA 25 in the home network 22, when a data packet arrives at the home network 22, the HA 25 of the network 22 encapsulates the received data packet and 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 removes only the encapsulated FA CoA and transmits the original packet to the mobile node 30. The path of the data packet is shown as data path 40 in fig. 1.

It is also noted that the data paths, such as paths 38 and 40, actually traverse the internet 20 many times. For clarity and without obscuring FIG. 1, the paths are only shown as passing through the relevant servers, e.g., HA 25 and FA 36. That is, the data paths 38 and 40 are shown as logical paths as shown in FIG. 1.

Operating in the manner described above, the mobile node is said to communicate with the corresponding node 34 under MIP using the FA CoA.

As in the case of CCoA, when the node 30 roams from the home network 22, the node 30 may request a CCoA through a DHCP server in any foreign network where the node 30 is located, instead of requesting an FA CoA. It should be noted that if the network 26 is a WAN supporting wireless technologies such as the cdma2000 standard promulgated by TIA/EIA (telecommunications industry association/electronic industry association), the CCoA may be requested or remotely distributed by the external network 26 via PPP (point-to-point protocol) as set forth in MIP. However, in addition to the allocation of the CCoA by the foreign network 26, the node 30 performs the functions of all foreign agents, such as the FA 36. In addition, the MN 48 needs to register the CCoA with the HN 44.

For example, corresponding to node 34 in network 24, node 30 issues a data packet with two layers of addresses. In the outer layer, the source address is set to CCoA and the destination address is set to 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 receiving the data packet from the roaming node 30, the HA 25 removes the external address layer and sends the data packet to the node 34 having the internal 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 transmits a data packet to the node 30, the data packet has only one address layer having a source address set to the node 34 and a destination address set to the HoA of the node 30. Upon receiving the data packet, the HA 25 encapsulates the data packet and the CCoA as a destination address, the address of the HA 25 as a source address, and sends the encapsulated data packet to the node 30. The node 30 performs the decapsulation itself without going through the FA 36. The direction of the data packets is shown as data path 44 in fig. 1.

Operating in the manner described above, the roaming node 30 is said to communicate with the corresponding node 34 via MIP using the CCoA.

Whether node 30 uses FA CoA or CCoA, there should be sufficient traffic to bypass the data paths, as shown by logical data paths 40, 42 and 44 shown in fig. 1, in order to communicate with other networks via MIP when node 39 is roaming. That is, the data packet must traverse the intermediate network before reaching the destination. Such traffic detour paths do not pose much problem in some types of data, for example in file conversion. Under TCP (transmission control protocol) as specified in RFC 793, a data packet simply takes a longer time to reach the destination. It is well known that data packets traversing longer data paths are more prone to transmission errors. However, while slowing down the overall data transmission process further, erroneous packets can always be retransmitted. However, for other types of data, such as data in an audio or video call, accurate access to real-time information is important. Excessive bypassing of the data path creates additional delay in the data transfer process. Further, for a data packet transmitted under UDP (user datagram protocol) as specified in RFC 768, the erroneous packet is not normally retransmitted but is merely discarded. As a result, the quality of service may be compromised.

Therefore, there is a need to provide better real-time data access in wireless communication systems.

Disclosure of Invention

In a communication system, a mobile node requests a communication session with a correspondent node by first signaling to initiate the communication session over a first data path via an intermediate node. Thereafter, the contents of the communication session are established via a second data path in which the mobile node and the corresponding node communicate directly without passing through intermediate nodes.

According to one embodiment, a mobile node roams from its home network to a foreign network. Using the first address, the mobile node signals to initiate a communication session with the correspondent node through a home agent in the home network. The home agent then relays the initiation signaling to the corresponding node located in the remote network. Upon acceptance by the correspondent node, the mobile node uses the second address to transfer the contents of the communication session directly over a direct data path between the mobile node and the correspondent node, without going through the home agent. Thus, due to the shorter data path, transmission delays and transmission errors are reduced, resulting in a high quality of service. These and other features and advantages will be apparent to those skilled in the art from the following detailed description, taken in conjunction with the accompanying drawings, in which like numerals indicate like parts.

Drawings

FIG. 1 is a schematic diagram of a global connection of a network;

FIG. 2 is a schematic diagram showing one embodiment of the present invention;

FIG. 3 is a flow chart showing steps for initiating signaling and establishing content services according to an embodiment of the present invention;

FIG. 4 is a flow chart showing steps for continuing content flow through the process of updating signaling according to an embodiment of the present invention;

fig. 5 is a schematic diagram showing circuitry of a mobile node configured in accordance with the present 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 the purpose of illustration. It will be understood by one of ordinary skill in the art that the present invention may be practiced without these specific details. In other instances, well-known structures and processes are not described in detail so as not to obscure the description of the invention with unnecessary detail. Thus, the present invention is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features disclosed herein.

The embodiments described below are operable in accordance with the IMS/MMD (IP multimedia subsystem/multimedia domain) standards promulgated by the third generation partnership project (3GPP) and the third generation partnership project 2(3GPP 2). A general discussion of IMS/MMD, entitled "3", can be found in published documents^rdGeneration Partnership Project：Technical SpecificationGroup Services and System Aspects，IP Multimedia Subsystem(IMS)，Stage2，”3GPP TS 23.228“3^rd Generation Partnership Project：TechnicalSpecification 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 various standards such as cdma2000, proposed by TIA/EIA, WCDMA, proposed by 3GPP, and various other WANs.

Reference is now made to fig. 2, which schematically shows an exemplary embodiment of the invention. The overall system is generally designated by reference numeral 50 and includes a backbone network 52, such as an intranet or the internet.

As an 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 an RN (remote network) 58.

In the HN54, there is an HA (home agent) 62 for managing data traffic within the HN54 and for controlling data traffic of the HN54 routed inwards and outwards. In addition, there is a PDSN (packet data serving node) 64, which is effectively an access gateway between the backbone network 52 and the wireless access portion of HN 54.

In order to perform various different IMS/MMD functions and features, the service provider installs different servers in the HN 54. Examples of such servers include a P-CSCF (proxy call state session function) server 70, and an S-CSCF (serving call state session function) server 72. The functional description of these servers will be described later together with the operational description of the system 50.

In addition to the nodes described above, there are other nodes in HN54, but are not shown for clarity. These nodes may be computers of various sizes, printers, and any other device that may be mobile or non-mobile.

Shown in fig. 2 are FN56 and 57 coupled to backbone network 52. Furthermore, for simplicity and ease of illustration, FN56 and RN 58 are illustrated in a similar manner as HN 54. It should be appreciated that FN56 and RN 58 may be constructed in a considerably different manner depending on the use. Thus, in this case, the FN56 also includes an FA (foreign agent) 66, a PDSN68, a P-CSCF71, and a PDF (policy decision function) 75. Likewise, RN 58 also includes PDSN 78, P-CSCF80, S-CSCF 82, and PDF 84.

In the system 50 there is also a MN (mobile node) 60 which is initially registered with an HoA (home address) with an HA 62 in the HN 54. The MN 60 can move to other external networks such as the FN56 or FN 57, and can obtain access to the backbone network 52 via the FN56 or FN 57 under MIP (mobile internet protocol).

Assume that the MN 60 is roaming in the FN 56. In this particular example, it is assumed that the user of the MN 60 wants to have a videoconference session with another user operating a CN (correspondent node) 90 in the RN 58. The nodes 90 may be mobile or non-mobile.

Typically, upon reaching the area of the FN56, the MN 60 obtains the address of the FA 66 via advertisements issued by the FN 56. The MN 60 then registers the FA CoA with the HA 62 in the HN54 so that the HA 62 can keep track of the location of the MN 60.

Thereafter, the MN 60 in the FN56 sends a message to the P-CSCF70 in the HN54 to initiate the conference session. The initialization signaling path for the request starts from the FN56 to the HN54 before reaching the RN 58. Likewise, if the conference session request is granted, the reply signaling path is the reverse of the request path, i.e., from the RN 58 to the HN54, and then to the FN 56. When the request is granted, the bearer traffic, i.e. the traffic of the media stream containing the audio and video content of the conference session, travels almost in the direction of the signaling path. That is, the logical path carrying the traffic then flows from the MN 60 in the FN56 to the HA 62 in the HN54 and finally to the RN 58 before reaching the CN90 and vice versa. As described above, the tortuous path of the data traffic increases the delay of the packet data. In addition, transmission errors are more prone to occur.

In the examples described below, different methods were employed. The data path for the bearer traffic is selected to be substantially different from the session initiation signaling path.

Referring to fig. 2, first, assume that the MN 60 roams from the HN54 to the FN 56. Upon reaching the area of the FN56, the MN 60 receives an advertisement message from the FN 56. According to the message, the MN 60 obtains the address of the FA 66. Thereafter, the MN 60 reports back to the HN54 by registering the address of the FA 66 with the HA 62. The registered address is referred to as the FA CoA, which is stored in the routing table of the HA 62 in the HN 54.

Further, assume that the user of MN 60 wants to have a videoconference session with the user of CN90 in RN 58.

First, the MN acquires the CCoA from the FN 56. Using the HoA initially assigned by the HA 62 in the HN54, the MN 60 registers the CCoA with the HA 62 in the HN 54. MN 60 also utilizes an S-CSCF 72 in HN54 with which the HoA for accessing a SIP (session initiation protocol) network in HN54 is registered.

The MN 60 then sends SIP INVITE (SIP request) messages to the P-CSCF70 in HN 54. It should be noted that in actual operation, as with all other data traffic, the sip invite message first passes through the PDSN68 and HA 62 before being routed to the P-CSCF 70. In addition, as is well known in the art, data traffic is in the form of electrical signals carried by carrier waves transmitted through the system 50. For clarity of explanation in a manner similar to that described above, data traffic is illustrated as logical paths. That is, in the following description, only a logical path of data traffic is described unless particularly emphasized.

It should also be noted that the MN 60 may alternatively send SIP INVITE a message to the P-CSCF71 in the FN56 to initiate the conference session. For simplicity of explanation, in the following description, the P-CSCF70 in HN54 is used for conference session initiation.

Referring to fig. 2, the SIP INVITE message includes a description portion called SDP (session description protocol) which essentially describes the basic requirements for a videoconference session in which the request is properly executed. Included in the SDP are, for example, the IP address and port number of the MN 60, and the codec specification of the session. More importantly, in this embodiment, the SDP includes the CCoA of the MN 60 of the media stream (bearer service).

The P-CSCF70 in the HN54 is the node that takes on the role of call session management. Upon receipt SIP INVITE of the message, the P-CSCF70 generates a token unique to the requested session. The P-CSCF70 then forwards the SIP INVITE message to the S-CSCF 72 in the HN 54. The C-CSCF 72 then sends an SIP INVITE message to the RN 58 for request acceptance.

The P-CSCF70 sends a token to the MN 60 when the session is agreed to by the S-CSCF 72 and the conference session is accepted by the CN90 in the RN 58. With the token, the MN 60 then sends the token along with the requested QoS (quality of service) to the PDSN68 in the FN56 to establish a bearer service, i.e., a media stream of audio and video signals for the conference session.

The PDSN68 then requests the authorized QoS for the conference session from PDF 75, and PDF 75 then relays the request to the P-CSCF70 in HN 54. Any parameters granted by PDF 75 must comply with certain mandate policies. Such policies may include rules specified under the IMS/MMD standard; specific protocols in the network, e.g. protocols between the HN54 and the FN56 related to the handling of bearer traffic; a policy specific to the network, such as a policy unique to the FN56 only.

The PDF 75 is installed to decide all enforced policies. In the decision process, a PDF 75 is placed between the P-CSCF71 and the PDSN68 in the FN 56. Further, there is a Go interface 92 interposed between the PDSN68 and the PDF 75. There is also another Gq interface 94 interposed between PDF 75 and P-CSCF 71. The Go and Gq interfaces 92 and 94 are used for policy control between conference sessions and bearer traffic. Details of the Go and Gq interfaces may be found in 3GPP TS23.107 published by 3GPP and in documents published by 3GPP2 at 3GPP2 x. p 0013-012.

Returning now to fig. 2, if authorized, the requested conference parameters are sent from the P-CSCF70 and PDF 75 to the PDSN 68.

In this embodiment, the CN90 is considered to have a CCoA allocated by the RN 58. Thus, upon receiving the SIP INVITE message, the CN90 replies to the SIP 200 OK message. The SIP 200 OK message basically reconfirms 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 direction.

MN 60 then acknowledges receipt of the SIP 200 OK message by sending an acknowledgement message (ACK) back along the same data path as the initial SIP INVITE message.

The bearer service is then established by the PDSN68 in the FN56 according to the authorization parameters described in the SIP INVITE message. In fig. 2, the media data path is shown as a video path 100 and an audio path 102 directly linking nodes 60 and 90 via their respective CCoA addresses. Bearer traffic in the manner described is sometimes indicated to use CCoA to establish data traffic in the simple IP case, unlike data paths 42 and 44 as shown and described in fig. 1 where the data paths are considered to be established using CCoA under MIP.

In this embodiment, in SIP INVITE, the MN 60 and the CN90 use their respective ccoas in order to specify the correct traffic flow. For example, the CCoA of the CN90 may be allocated by the PDSN 78 of the RN 58. For example, the CCoA of the MN 60 is assigned by a request to the PDSN68 in the FN 56. The CCoA acquired as described above is often referred to as a "simple IP address".

The process described above is shown as a flow chart in fig. 3.

When the MN 60 roams from the FN56 to another network (e.g., to the FA 57), the MN 60 acquires a new CCoA from the new FN 57. Thereafter, MN 60 registers the new CCoA with HA 62 in HN 54. Since the MN 60 has previously registered with the S-CSCF 72 using the HoA, the MN need not perform other SIP registrations. In this embodiment, the MN 60 sends only SIP UPDATE messages with the new CCoA to the CN90 in a manner substantially similar to sending SIP INVITE messages as described previously. For the sake of brevity, the logical flow of the SIP UPDATE message is not repeated further here, but is shown by the flow chart in fig. 4.

Returning now to fig. 2. Once the bearer traffic identified by the data paths 100 and 102 is established according to the IMS standard, the PDSN68 implements a set of policies referred to as SBBC (service based bearer control) under the decision of PDF 75. The execution of SBBC is continued until the session between MN 60 and CN90 is terminated.

The policies included in the SBBC may also be authorization for a session to request QoS, charging of a single bearer flow, and policies for bearer traffic. To achieve this, PDSN68 monitors the media flow in bearer paths 100 and 102. Details of SBBC's operation can be found in Document 3GPP 2X. P0013-012, entitled "3 GPP2 MMD Service Based Bearer Control Document, Work in progress". The description of SDP may be found in the title "IP Multimedia Call Control Protocol Based on Sip and SDP), Stage 3: TIA-873-004 and RFC 2327.

Operating in the above manner, the content of the media stream may be directly transmitted and received, as identified by the bearer traffic paths 100 and 102 shown in fig. 2. Unnecessary detours of the data path may be shortened, resulting in faster and more accurate real-time data access.

Fig. 5 schematically shows a part of a hardware implementation of a mobile node arrangement according to the invention, indicated by reference numeral 120. The device 120 may be configured and included in a variety of devices, such as a laptop, a PDA (personal digital assistant), or a cellular telephone.

The device 120 includes a central data bus 122 linking some of the circuits together. The circuitry includes a CPU (central processing unit) or controller 124, receive circuitry 126, transmit circuitry 128, and memory circuitry 130.

The receiving and transmitting circuits 126 and 128 may be connected to RF (radio frequency) circuits, but are not shown in the figure. The receive circuit 126 processes and buffers the received signal before issuing it to the data bus 122. On the other hand, the transmission circuit 128 processes and buffers data from the data bus 122 before sending the data out of the device 120. The CPU/controller 124 performs data management functions of the data bus 122 and further performs functions of general data processing, including executing instructional contents of the memory circuit 130.

The memory circuit 130 includes a set of instructions generally represented by reference numeral 131. In this embodiment, these instructions include, for example, portions of MIP client 132 and SIP client 134, and the like. SIP client 134 includes a set of instructions in accordance with the present invention as previously described. MIP client 132 includes a set of instructions for allowing device 120 to operate with IP and MIP, for example, to obtain various types of addresses for various purposes, as also described above.

In this embodiment, the memory circuit 130 is a RAM (random access memory) circuit. Exemplary instruction portions 132 and 134 are software modules. The memory circuit 130 may be connected to other memory circuits (not shown) which may be of a volatile or non-volatile type. As an alternative embodiment, the memory circuit 130 may be formed from other circuit types, such as EEPROM (electrically erasable programmable read Only memory), EPROM (electrically programmable read Only memory), ROM (read Only memory), magnetic disks, optical disks, and other types known in the art.

Finally, only a few networks connected to the backbone network are illustrated in these embodiments. It will be apparent that a variety of networks may be included. Further, as described in this embodiment, node 60 is depicted as a mobile device roaming through different foreign networks. It should be understood that the respective network node 90 may be stationary. Node 90 may also be mobile and perform steps and status updates when arriving at another external network in a similar manner as required by node 60. Furthermore, the process of signaling to initiate a communication session need not be limited to using the HoA, as described in this embodiment. Instead of the HoA, a CCoA may be used in the signaling process. Furthermore, any logic blocks, circuits, and algorithm steps described in connection with the embodiments disclosed herein may be implemented as hardware, software, middleware, or combinations thereof. It will be understood by those skilled in the art that these and other changes in form and details may be made therein without departing from the scope and spirit of the invention.

Claims (26)

1. A method in a wireless communication system, comprising:

obtaining first and second addresses;

signaling with the first address to initialize a communication session; and

transmitting content of the communication session with the second address.

2. The method of claim 1, further comprising signaling to initialize the communication session via a first communication path and transmitting the content of the communication session via a second communication path.

3. The method of claim 1, further comprising providing a home address as the first address and providing a co-located care-of address as the second address.

4. The method of claim 3 wherein said transmitting said content comprises transmitting said content in a first network, said method further comprising updating said collocated care-of address during said transmitting said content in a second network.

5. A method of communicating with a corresponding node in a communication system supported by IP (internet protocol), comprising:

(a) signaling via a first communication path to initiate a communication session by sending a request message to the respective node via a proxy entity;

(b) transmitting the content of the communication session directly to the corresponding node over a second communication path.

6. The method of claim 5, further comprising obtaining first and second addresses prior to step (a), and wherein step (a) further comprises signaling to initialize the communication session using the first address, and step (b) further comprises transmitting the contents of the communication session using the second address.

7. The method of claim 6, wherein step (b) further comprises transmitting the content in a first network, the method further comprising (c) updating the second address during the transmitting the content in a second network.

8. The method of claim 7, wherein step (a) further comprises signaling via mobile IP to initiate the communication session, and step (b) further comprises transmitting the contents of the communication session via simple IP.

9. An apparatus in a wireless communication system, comprising:

means for obtaining first and second addresses;

means for signaling using the first address for a communication session; and

means for transmitting content of the communication session using the second address.

10. The apparatus of claim 9, further comprising means for signaling to initiate the communication session via a first communication path, and means for transmitting the content of the communication session via a second communication path.

11. The apparatus of claim 9, further comprising means for providing a home address as the first address, and means for providing a co-located care-of address as the second address.

12. The apparatus of claim 11, further comprising means for updating the collocated care-of address as the apparatus moves from one network to another network in the wireless communication system.

13. An apparatus in a wireless communication system supported by an IP (internet protocol), comprising:

means for sending a request message to the correspondent node over the first communication path by the proxy entity to initiate the communication session; and

means for transmitting content of the communication session directly to the corresponding node over a second communication path.

14. The apparatus of claim 13, further comprising means for obtaining first and second addresses to cause the apparatus to use the first address for sending the request message over the first communication path and the second address for transmitting the content of the communication session over the second communication path.

15. The apparatus of claim 14, further comprising means for updating the second address when the apparatus moves from one network to another network in the wireless communication system.

16. An apparatus in a communication system, comprising:

a memory circuit having computer-readable instructions for obtaining first and second addresses, signaling with the first address to initiate a communication session, and transmitting contents of the communication session with the second address; and

a processor circuit connected to the memory circuit for processing the computer-readable instructions.

17. The device of claim 16, wherein the memory circuit further comprises computer-readable instructions for signaling to initialize the communication session via a first communication path and to transmit the content of the communication session via a second communication path.

18. The apparatus of claim 17, further comprising a home address as the first address, and a co-located care-of address as the second address.

19. The apparatus of claim 18, wherein the memory circuit further comprises computer readable instructions for updating the collocated care-of address when the apparatus moves from a first network to a second network in the communication system.

20. An apparatus for communicating with a corresponding node in a wireless communication system supported by IP (internet protocol), comprising:

memory circuitry having computer-readable instructions for signaling to initiate a communication session over a first communication path by sending a request message to the respective node through a proxy entity, and for transmitting content of the communication session directly to the respective node over a second communication path; and

a processor circuit connected to the memory circuit for processing the computer-readable instructions.

21. The apparatus of claim 20, wherein the memory circuit further comprises computer readable instructions for obtaining first and second addresses and using the first and second addresses in conjunction with the first and second communication paths, respectively.

22. The apparatus of claim 21, wherein the memory circuit further comprises computer readable instructions for updating the second address when the apparatus moves from one network to another network in the wireless communication system.

23. The apparatus of claim 21, wherein the first and second addresses comprise a HoA (home address) and a CCoA (co-located care-of address), respectively.

24. The apparatus of claim 23, wherein the computer-readable instructions further comprise issuing the request message via mobile IP and transmitting content of the communication session via simple IP.

25. An electrical signal transmitted between first and second nodes over a carrier wave in a wireless communication system, the electrical signal comprising computer readable instructions for:

obtaining first and second addresses;

signaling to initiate a communication session over a first communication path using the first address; and

transmitting content of the communication session over a second communication path using the second address.

26. The electrical signals of claim 25, further comprising computer readable instructions for updating the second address when one of the first and second nodes moves from one network to another network in the wireless communication system.