HK1108989A - Packet data filtering - Google Patents

Description

Packet data filtering

Priority as required in accordance with 35U.S.C § 119

Priority from U.S. provisional application No. 60/588,664 entitled "Service base bearer Control for Mobile IP Co-located Car of Address", filed on 7, 15, 2004, which is assigned to the assignee hereof and expressly incorporated herein by reference.

Reference to co-pending patent application

The present invention is related to U.S. patent application entitled "Bearer Control of Encrypted Data Flows in Packet Data communications" filed concurrently with the above-mentioned provisional application and entitled "Bearer Control of Encrypted Data Flows" at attorney docket number 040727, which is assigned to the assignee hereof and is hereby expressly incorporated by reference.

Technical Field

The present invention relates generally to packet data communications, and more particularly to monitoring and controlling packet data during packet data communications.

Background

The global interconnection of networks allows for quick access to information regardless of geographic distance. Fig. 1 shows a simplified schematic diagram of the global connections of a network, generally referred to as the internet, indicated by reference numeral 20. The internet 20 is essentially a number of networks with different hierarchical levels connected together. The internet 20 operates in accordance with 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 various individual networks, sometimes referred to as LANs (local area networks) or WANs (wide area networks) depending on the network size. Shown in fig. 1 are some of such networks 22, 24, and 26.

Within each network 22, 24, and 26, there may be various devices that are connected to and communicate with each other. Examples are computers, printers and servers, to name a few. 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 over its own network via the internet 20, it needs to be assigned an IP address.

The assignment of the IP address may be manual or automatic. The manual assignment of the IP address may be performed by, for example, a network administrator. More commonly, IP addresses are automatically assigned. For example, in a LAN, an IP address may be assigned by a server (not shown) called a DHCP (dynamic host control protocol) server located inside the node's LAN. Further, in a WAN that supports wireless technology, IP addresses may be automatically and remotely assigned.

Returning now to fig. 1, as an example, assume that a node 30 in network 22 attempts to send a data packet to another node 34 in network 24. In the case of 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. The destination address is the address of a node 34 in the network 24. When operating in this manner, the nodes 30 and 34 are said to be communicating in a simple IP communication mode in which both nodes 30 and 34 simply use their own IP addresses in the exchange of data packets to conform to IP.

The advent of wireless technology allows nodes to leave their originally registered network and reach another network. For example, referring back to FIG. 1, rather than being permanently wired to network 22, node 30 may be a wireless device, such as a PDA (personal device Assistant), a cellular telephone, or a mobile computer. The wireless node 30 may travel outside the boundaries of its home network 22. In this way, the node 30 may roam from its home network 22 to the foreign network 26. In this case, the initial address assigned to the node 30 will no longer be applicable to the node 30. Also, data packets destined for the address of node 30 may not reach node 30.

Mobile IP (mobile internet protocol) proposed by IETF is proposed to solve the node mobility problem. According to the IETF published RFC2002, whenever a node 30 leaves the home network 22 and roams in another network, the node 30 is assigned a "Care-of Address," abbreviated CoA (Care-of Address).

According to RFC2002, there are two types of coas, namely, FA CoA (Foreign Agent Care-of Address) and CCoA (Co-located Care-of Address).

The FA CoA is substantially an address of an FA (foreign agent) which is a designated server in a foreign network in which the node 30 is located. FA CoA is applicable in IPv 4.

A CCoA is a separate but temporary address assigned to the node 30 by the external network. CCoA can be applied in IPv4 and IPv 6.

In any case, whenever the node 30 is in the foreign domain, the node 30 must register a CoA (whether a FA CoA or CcoA) with its home network 22 so that the home network 22 is always aware of the whereabouts of the node 30. After registration, the CoA is stored in a routing table maintained by a designated server called HA (home agent) 25 of the home network 22.

Several examples are used for illustration.

For the case of an FA CoA, assume that the node 30 roams into the foreign network 26. Upon reaching the realm boundary of the foreign network 26, the node 30 receives an advertisement message from the foreign network 26 informing the node 30 that it is located in the foreign realm. From the advertisement message, the node 30 knows the address of the FA36 of the foreign network 26. The node 30 then registers the FA CoA with the HA25 in the home network 22.

For example, when a node 30 in the foreign network 26 sends out a data packet to a node 34 in the network 24, the data packet may be sent directly knowing the address of the node 34 in the network 24. That is, according to IP, in the data packet, 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. The direction of the data packets is shown as data path 38 shown in fig. 1.

This cannot be straightforward with respect to reverse data traffic. In reverse data routing, when a node 34 in the network 24 attempts to send a data packet to a node 30 that is now in the foreign network 26, both the source address and the destination address must be specified in the data packet according to IP, as described above. In this case, the source address is the IP address of the node 34 in the network 24. Regarding the destination address, the node 34 only knows the HoA of the node 30 without any update notification from 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 the node 30. However, since the FA CoA of the node 30 is stored in the routing table of the HA25 in the home network 22, when a data packet arrives at the home network 22, the HA25 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 FA36 simply strips off the encapsulated FACoA and delivers the initial packet to the mobile node 30. The routing of data packets is shown in fig. 1 as data path 40.

It should also be noted that the data paths, such as paths 38 and 40, actually traverse the internet 20 many times. For clarity so as not to obscure FIG. 1, the paths are only shown as passing through the relevant servers, such as HA25 and FA 36. That is, data paths 38 and 40 are shown as logical paths as shown in FIG. 1.

When operating in the manner described above, the mobile node 30 is said to be communicating with the correspondent node 34 in mobile IP tunneling mode using the FA CoA.

With respect to the CCoA case, when the node 30 roams away from the home network 22, the node 30 may not request the FA CoA, but request the CCoA from a foreign network. If the network 26 is a WAN that supports wireless technologies such as the cdma2000 standard promulgated by TIA/EIA (telecommunications industry association/electronic industry association), a CCoA may be requested and remotely assigned by the external network 26 via PPP (point-to-point protocol) between, for example, a PDSN (packet data serving node) 41 and the mobile node 30. PDSN 41 is essentially a server in network 26 that services and processes data traffic in the wireless portion of network 26. Further, it should also be noted that the PDSN 41 and FA36 may not be separate, but integrated into one entity. However, the node 30 may perform all of the functions of a foreign agent such as the FA36 described previously, except for the assignment of the CCoA by the foreign network 26. Likewise, the mobile node 30 needs to register a CCoA with the home network 22.

For example, to communicate with a node 34 in the network 24, the node 30 sends 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 HA25 strips off the outer address layer and transmits the data packet to the node 34 using the inner address layer. The logical path of the data packet is shown in fig. 1 as data path 42.

In the reverse data path, i.e., when node 34 sends a data packet to node 30, the data packet has only one address layer with the source address set to node 34 and the destination address set to the HoA of node 30. Upon receiving the data packet, the HA25 encapsulates the data packet with the CCoA as the destination address and the address of the HA25 as the source address, and sends the encapsulated data packet to the node 30. The node 30 performs decapsulation independently and not through the FA 36. The direction of the data packets is shown in fig. 1 as data path 44.

When operating in the manner described above, the roaming node 30 is said to be using CCoA to communicate with the correspondent node 34 in mobile IP tunneling mode.

An advantage of using CCoA for communication via mobile IP tunneling mode is that the mobile node 30 does not need to send any update notifications to the correspondent node 34, for example, when the mobile node 30 moves to another foreign network. Since the mobile node 30 always updates its whereabouts with the home network 22, data packets sent by the correspondent node 34 are always routed to the HA25, which in turn reroutes the data packets to the most current location of the mobile node 30, HA 25.

Operating via mobile IP tunneling mode using CCoA involves a significant degree of data traffic detour, as seen from the meandering logical data paths 42 and 44 in fig. 1.

Assume that the mobile node 30 roams to a foreign network 26 that is geographically close to the remote network 24 but far from the home network 22. In order for a mobile node 30 in a foreign network 26 to communicate with a corresponding network 34, data traffic needs to be looped through the remote home network 22 before reaching the nearby corresponding node 34, which results in inefficient utilization of resources.

However, according to mobile IP, another communication mode is available. To invoke this mode, once the mobile node 30 reaches the new foreign domain, the mobile node 30 needs to update its new location to any corresponding node, such as the corresponding node 34, in addition to updating its whereabouts to the home network 22.

When operating in this mode of communication, data traffic between the mobile node 30 and the corresponding node 34 is exchanged directly. Specifically, when the mobile node 30 transmits a data packet to the correspondent node 34, the source address is set to the CCoA of the mobile node 30, and the destination address is set to the address of the node 34 in the foreign network 24. With respect to reverse data traffic, for each data packet, the corresponding node 34 uses its address as a source address and the CCoA of the mobile node 30 as its destination address. The logical paths of the data packets are shown in fig. 1 as data paths 46 and 48. When operating in the manner described above, the mobile node 30 is said to be using CCoA to communicate with the correspondent node 34 in a mobile IP routing optimization mode.

It is very common that different communication modes of a node need to be determined and monitored for different reasons. For example, when the mobile node 30 and the correspondent node 34 are engaged in a VoIP (voice over IP) session, it needs to be determined that the parties, i.e., the mobile node 30 and the correspondent node 34 in this case, are authorized. If the VoIP session is charge-based, then data traffic between the parties needs to be monitored for billing purposes. Unauthorized data traffic is simply blocked or denied. The data packet format is different in different communication modes. Heretofore, monitoring of data traffic was performed by: each data packet is first examined, its communication mode determined, relevant information extracted, and appropriate criteria established thereafter to permit or deny passage of the data packet. Such practical operations are resource intensive, not to mention the additional latency added to the data traffic.

Therefore, there is a need to provide better data traffic monitoring for packet data communications.

Disclosure of Invention

In packet data communication systems where communication nodes employ different communication modes, there is a need for efficient and accurate monitoring of traffic packet data. According to an example embodiment of the present invention, rather than examining each data packet to derive the necessary information to derive a set of criteria for data traffic monitoring, the necessary information is sent directly to a monitoring intermediary (intermediary) to establish a data filter for performing data control and monitoring functions.

In an example embodiment, the mobile node sends its selected communication mode to the monitoring intermediary during initial signaling processing, along with other information required in each data packet. The correspondent node responds with similar information in its response signaling process. Working according to the configuration, the monitoring intermediary can relatively quickly and efficiently set up data filters to perform data control and monitoring functions.

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 reference numerals refer to like parts.

Drawings

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

FIG. 2 is a schematic diagram illustrating an embodiment of the present invention;

FIG. 3 is a flow chart illustrating steps for initial signaling and establishing content traffic according to an embodiment of the present invention;

fig. 4 is a schematic diagram of circuitry of a mobile node configured in accordance with the present invention; and is

Fig. 5 is a schematic diagram of a circuit of a monitoring agent according to the present invention.

Detailed Description

The following description is presented to enable any person skilled in the art to make and use the invention. The details set forth in the following description are for the purpose of illustration. It will be understood by those 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 set forth in detail in order 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 novel 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 thorough discussion of IMS/MMD can be found in the following published documents: title as "3^rdGeneration Partnership Project: technical Specification Group Services and System applications, IP Multimedia Subsystem (IMS), Stage 2, "3 GPP TS 23.228; title as "3^rdGenerationPartnership Project: technical Specification Group Core network, End-to-End Quality of Service (QoS) signalling Flows, "3 GPP TS 29.208; and the titles "IP Multimedia System, Stage 2," X.S0013-002 and 3GPP2 X.P0013-012.

IMS is applicable in standards such as cdma2000, WCDMA (wideband code division multiple access), GPRS (general packet radio service), and various other WANs.

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

For example, as shown in fig. 2, connected to the backbone network 52 are, among other networks, a HN (home network) 54, a FN (foreign network) 56, and an RN (remote network) 58.

In HN54 there is a HA (home agent) 62 which is responsible for the management of data traffic within HN54 and also for the control of inbound (inbound) and outbound (outbound) routing of data traffic for HN 54. If HN54 supports wireless technology, a RAN (radio access network) 55 is typically installed and the RAN55 is connected to a PDSN (packet data serving node) 64. For example, if the RAN55 operates in accordance with the cdma2000 standard, the RAN55 typically includes at least a BSC (base station controller) and a plurality of BSs (base stations). The PDSN64 is essentially an access gateway between the backbone network 52 and the RAN 55.

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

In addition to the above nodes, there are other nodes within HN54, which are not shown for clarity. Such 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 RN58 connected to backbone network 52. Furthermore, for simplicity and ease of illustration, FN56 and RN58 are illustrated as somewhat similar to HN 54. It should be understood that FN56 and RN58 may be constructed in very different ways depending on the application. Thus, in this case, the FN56 also includes, among other things, an FA (foreign agent) 66, a RAN76, a PDSN68, a P-CSCF71, and a PCRF (policy and charging rules function) 75. Also, RN58 includes PDSN78, P-CSCF80, S-CSCF82, and PCRF84, among others.

It should be noted that in fig. 2, the FA66 and PDSN68 in FN56 are shown as separate entities. Very commonly, the FA66 and the PDSN68 are integrated into one unit.

In the system 50, there is an MN (mobile node) 60 that initially registers an HoA (home address) with an HA62 in the HN 54. The MN60 is capable of moving to other foreign networks such as the FN56 and accessing the backbone network 52 via the FN56 or other networks under mobile IP (mobile internet protocol). MN60 may in practice be in the form of, for example, a PDA (personal digital assistant), a laptop computer, or a mobile telephone.

Assume that MN60 is roaming in FN 56. In this particular example, assume that a user of MN60 wants to have a videoconference session with another user of RN58 operating CN (correspondent node) 90. The nodes 90 may be mobile or non-mobile.

Upon reaching the domain of FN56, MN60 can acquire the address of FA66 through FN56 advertisement. MN60 then registers the FA CoA with HA62 in HN54, enabling HA62 to keep track of the location of MN 60. Alternatively, MN60 may request CCoA from FA 66. MN60 then also registers CCoA with HA62 for the same reason, i.e., to allow HA62 to maintain contact with MN 60.

MN60 needs to undergo signaling before any communication traffic is established. To accomplish this, MN60 sends out an invite message to CN90 via an intermediary as will be described below. Also, the CN90 needs to acknowledge the invite message by response signaling processing.

In this example, MN60 registers with S-CSCF72 in HN54 using the HoA initially allocated by HA62 in HN54 for accessing the SIP (session initiation protocol) network including S-CSCF72 in HN 54.

The MN60 then sends a SIP INVITE message 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 RAN76, PDSN68, FA66, backbone network 52, and HA62 before reaching the P-CSCF 70. Further, as is well known in the art, data traffic takes the form of electrical signals via a signal carrier wave passing through the system 50. For clarity, data traffic is simply illustrated as logical paths in a manner similar to that described above. That is, in the following description, only the logical path of the data traffic is described unless particularly emphasized.

It should also be noted that alternatively, the MN60 may send a SIP INVITE message to the P-CSCF71 in the FN56 to initiate the conference session. That is, alternatively, MN60 may not use P-CSCF70 in HN54 for signaling, but use P-CSCF71 in FN 56. For consistency and simplicity of illustration, in the following description, the SIP network in HN54 is used for signaling processing.

Returning to fig. 2, the SIP INVITE message includes a description portion called SDP (session description protocol) that essentially describes the basic requirements needed to properly execute the requested videoconference session. Included in the SDP are, for example, the IP address and port number of MN60, and the codec specification for the session. More importantly, in this embodiment, the SDP includes the communication mode employed by MN60 for carrier traffic. The carrier traffic is a content stream of audio and video signals of a conference session.

The P-CSCF70 in HN54 is the node that takes on the role of call session management. Upon receiving the SIP INVITE message, the P-CSCF70 sends a SIP INVITE message to the S-CSCF72 in the HN 54. The S-CSCF72 then sends a SIP INVITE message to the RN58 requesting acceptance.

Once the S-CSCF72 agrees to the session and CN90 in RN58 accepts the conference session, P-CSCF70 then sends policy related information such as charging rules, authorized QoS (quality of service) and flow identifiers to PCRF74 in HN 54.

Meanwhile, i.e., after the CN90 accepts, the MN60 sends a TFT (traffic flow template) to the PDSN68 in the FN56 along with the requested QoS to establish carrier traffic.

The PDSN68 then requests the same policy related information as previously described, namely the authorized QoS, charging rules and flow identifier for the conference session, from the PCRF75 in the FN 56. PCRF75 then relays the request to PCRF74 in HN 54. Any parameters permitted by PCRF75 must be consistent with some approved policy. Such policies may include rules specified under the IMS/MMD standard, specific agreements between networks, such as agreements between HN54 and FN56 regarding handling of carrier traffic, network specific policies, such as being unique to FN56 only. If the requested conference session is charge-based, the policy may include some tracking procedure for billing purposes. In particular, unauthorized traffic will be blocked via a process called packet data filtering, described further below. Under the IMS/MMD standard, the enforcement of policies is called SBBC (service based carrier control).

Details of SBBC operation can be found in 3GPP2 X.S0013-012, entitled "3 GPP2 MMDService Based Bearer Control Document, Work in Progress". The description of SDP can be found in Stage 3: 3GPP2-X.S0013-0004 is found in the document entitled "IPMultimedia Call Control Protocol Based on SIP and SDP".

The PCRF75 in FN56 is installed for deciding all imposed policies. In the decision process, PCRF75 is placed between PCRF74 in HN54 and PDSN68 in FN 56. In addition, a Ty interface 92 is disposed between the PDSN68 and the PCRF 75. There is also a Tx interface 94 placed between PCRF74 and P-CSCF70 in HN54, as shown in fig. 2. The aforementioned Ty and Tx interfaces are used for policy control between conference sessions and carrier traffic. Details of the Ty and Tx interfaces can be found in the 3GPP TS23.107 published by 3GPP and the 3GPP2x.p0013-012 documents published by 3GPP 2.

Returning now to fig. 2, if the requested session parameters declared in the SIP INVITE message are authorized, they will be passed from P-CSCF70 to PDSN68 via PCRF74 in HN54 and PCRF75 in FN 56.

In this example, CN90 is assumed to have a CCoA assigned by RN 58. Thus, upon receiving the SIP INVITE message, CN90 responds back with a SIP200 OK message. The SIP200 OK message basically reconfirms the parameters of the original SIP INVITE message. In addition, in this embodiment, CN90 includes a communication mode to be assumed by CN90 for carrier traffic in the SDP of the SIP200 OK message. The SIP200 OK flows along the same data path as the SIP INVITE message but in the reverse order.

MN60 then acknowledges receipt of the SIP200 OK message by sending an acknowledgement message (ACK) back along the same path as the initial SIP INVITE message.

Carrier traffic is then ready for establishment by the PDSN68 in the FN56 in accordance with the authorization parameters set forth in the SIP INVITE message.

Under the IMS/MMD standard, carrier traffic needs to be monitored and controlled by the network via SBBC. In this example, as previously described, implementation of SBBC by PDSN68 directed by PCRF75 in FN56 is consistent with the aforementioned policies.

During SBBC implementations, each data packet needs to be screened before it is allowed to pass. This process is called packet data filtering. The mechanism implemented to perform the filtering process is called a filter. Details of packet data filtering may be found in the above-mentioned Document entitled "3 GPP2MMD Service Based Bearer Control Document, Work in Progress".

In particular, the criteria need to be built into the filter. In particular the source and destination addresses of each data packet need to be determined. As previously mentioned, the format and configuration of the address in each data packet is different in different communication modes. For example, in a communication mode according to the mobile IP tunneling mode, each data packet has two layers of addresses. The PDSN68 may examine each data packet to determine the different formats and configurations of addresses in order to establish the filters. Such a checking and determining process involves considerable resources. Furthermore, this is a relatively complex task. For example, there are three modes of communication available for MN30 to select from. As previously described, they are the simple IP mode, the mobile IP tunnel mode, and the mobile IP route optimization mode. The same applies to CN 90. That is, CN90 may also assume one of three modes of communication. Thus, there should be at least 9 sets of filters in total for the PDSN68 to decide and process.

According to this embodiment, rather than requesting the PDSN68 to examine data packets for the correct filter set, the PDSN68 is directly informed of the communication mode of the correspondent node.

Thus, as previously described, in the SDP part of SIP INVITE, MN60 includes in the SDP, in addition to the requested information, such as source and destination addresses and destination ports, etc., a communication mode to be implemented by MN60 for the requested communication session.

Also, in the SIP200 OK message, the CN90 includes, in addition to the requested information, such as source and destination addresses and destination ports, the communication mode to be used by the CN90 in the SDP.

The PDSN68 then easily knows in advance the communication mode of the correspondent nodes MN60 and CN90 from the SIP INVITE and SIP200 OK messages, respectively. Thereafter, once authorized by PCRF75 in FN56, the appropriate filters are established accordingly. The carrier traffic is then established through the filter. Only data packets that meet the criteria of the filter are allowed to pass through the PDSN 68. On the other hand, inconsistent data packets are simply dropped.

When operating in the manner described above, i.e., in a communication mode directly included in the SDP, the PDSN can quickly establish filters to implement SBBC for the requested video conference session. The implementation of SBBC is continued until the session between MN60 and CN90 is terminated.

The above-described process is shown in the flowchart of fig. 3.

Fig. 4 schematically shows a part of a hardware implementation of a mobile node arrangement according to the invention, denoted by reference numeral 120. The apparatus 120 may be, for example, constructed and embodied in various devices, such as a laptop computer, PDA, or cellular telephone.

The device 120 includes a central data bus 122 that connects several circuits together. These circuits include a CPU (central processing unit) or controller 124, receive circuits 126, transmit circuits 128, and memory units 130.

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

The memory unit 130 includes a set of instructions, generally indicated by reference numeral 131. In this embodiment, the instructions include, among other things, components such as a mobile IP client 132 and a SIP client 134. SIP client 134 includes a set of instructions in accordance with the present invention as previously described. Mobile IP client 132 includes a set of instructions for allowing device 120 to operate under IP or mobile IP, such as a set of instructions for obtaining various types of addresses for various communication modes, as also previously described.

In this embodiment, the memory unit 130 is a RAM (random access memory) circuit. The exemplary instruction portions 132 and 134 are software routines or modules. The memory unit 130 may be connected to another memory circuit (not shown) which may be of a volatile or non-volatile type. Alternatively, the memory unit 130 may be constituted by other circuit types, such as an EEPROM (electrically erasable programmable read only memory), an EPROM (electrically programmable read only memory), a ROM (read only memory), a magnetic disk, an optical disk, and other circuit types known in the art.

Fig. 5 schematically illustrates a portion of a hardware implementation of a PDSN apparatus, generally designated by reference numeral 140, in accordance with the present invention. PDSN device 140 includes a central data bus 142 that connects several circuits together. These circuits include a CPU (central processing unit) or controller 144, receive circuits 146, transmit circuits 148, and a memory unit 150.

The receive and transmit circuits 146 and 148 may be connected to a network data bus (not shown) to which the PDSN device 140 is connected. The receive circuit 146 processes and buffers signals received from a network data bus (not shown) before routing them to the internal data bus 142. The transmit circuit 148 processes and buffers data from the data bus 142 before sending the data from the data bus 142 out of the device 140. The CPU/controller 144 performs the duties of data management of the data bus 142 and performs the functions of general data processing, including executing the instructional contents of the memory unit 150.

The memory circuit 150 includes a set of instructions, generally indicated by reference numeral 154. In this embodiment, the instructions include portions of the PDSN function 156 and the SBBC function 158, among others. The memory circuit may be constructed of the type of memory circuit described above and will not be repeated.

Finally, described in the embodiments is MN60 operating under mobile IP using CCoA. As previously mentioned, MN60 may work well in other communication modes and employ other types of addresses. For example, MN60 may deterministically use CCoA in mobile IP routing optimization mode. As another example among many alternatives, MN60 may use FA CoA and communicate with CN90 in mobile IP tunneling mode. In addition, the filter need not be bi-directional as described in the embodiments. It is conceivable to have a one-way filter. For example, MN60 may include its communication mode in the SDP to establish a filter for one direction without requiring CN90 to provide a filter for the opposite direction. Further, as described above, node 60 is described as a mobile device roaming to a foreign network. It should be understood that node 60 may suitably be a stationary node. Furthermore, any of the logical blocks, circuits, and algorithm steps described in connection with the embodiments disclosed herein may be implemented as hardware, software, firmware, 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 spirit and scope of the invention.

Claims (26)

1. A method for conducting a communication session of packet data through a monitoring intermediary, comprising:

determining a communication mode for the communication session;

sending, by the monitoring intermediary, a signal for the communication mode during the communication session; and

communicating the packet data through the monitoring intermediary using the communication mode during the communication session.

2. The method of claim 1 wherein said signaling through said monitoring intermediary comprises preparing an invitation message including parameters of said communication mode and sending said invitation message through said monitoring intermediary.

3. The method of claim 1 wherein said sending, by said monitoring intermediary, a signal for said communication session comprises responding, by said monitoring intermediary, to an invitation to said communication session.

4. A method for a communication session of packet data through a monitoring intermediary in a communication system supported by IP (internet protocol), comprising:

determining a communication mode selected from the group consisting of a simple IP mode, a mobile IP tunnel mode, and a mobile IP routing optimization mode;

including the communication mode in a signaling message selected from the group consisting of an SIP INVITE message and a SIP200 OK message; and

sending a signal for the communication session by sending the signaling message with the communication mode via the monitoring intermediary to allow the monitoring intermediary to use the information of the communication mode for packet data monitoring.

5. A method for a communication session of packet data, comprising:

receiving a communication mode from a signaling message of the communication session; and

a set of policies is enforced for the communication session that require information provided by the communication mode.

6. The method of claim 5, wherein the signaling message is a first signaling message and the communication mode is a first communication mode, the method further comprising receiving a second communication mode from a second signaling message.

7. The method of claim 6, wherein the first signaling message is an invite message for the communication session and the second signaling message is a response message for the invite message.

8. A method for conducting a communication session of packet data in a communication system supported by IP (internet protocol), comprising:

receiving a signaling message selected from the group consisting of an SIP INVITE message and a SIP200 OK message;

obtaining a communication mode selected from the group consisting of a simple IP mode, a mobile IP tunnel mode, and a mobile IP routing optimization mode from the signaling message; and

a set of policies is enforced for the communication session that require information provided by the communication mode.

9. An apparatus for conducting a communication session of packet data through a monitoring intermediary, comprising:

means for determining a communication mode for the communication session;

means for transmitting, by the monitoring intermediary, a signal for the communication mode during the communication session of packet data; and

means for communicating the packet data through the monitoring intermediary using the communication mode during the communication session.

10. The apparatus of claim 9, wherein the means for sending a signal comprises means for sending an invitation message with the communication mode through the monitoring intermediary.

11. The apparatus of claim 9, wherein the means for signaling comprises means for responding to an invitation to the communication session through the monitoring intermediary.

12. An apparatus for a communication session of packet data through a monitoring intermediary in a communication system supported by IP (internet protocol), comprising:

means for determining a communication mode selected from the group consisting of a simple IP mode, a mobile IP tunnel mode, and a mobile IP routing optimization mode;

means for including the communication mode in a signaling message selected from the group consisting of an SIP INVITE message and a SIP200 OK message; and

means for transmitting a signal for the communication session by transmitting the signaling message with the communication mode via the monitoring intermediary to allow the monitoring intermediary to use the information of the communication mode for packet data monitoring.

13. An apparatus for a communication session of packet data, comprising:

means for receiving a communication mode from a signaling message of the communication session; and

means for enforcing a set of policies for the communication session, the set of policies requiring information provided by the communication mode.

14. The apparatus of claim 13, wherein the signaling message is a first signaling message and the communication mode is a first communication mode, the apparatus further comprising means for receiving a second communication mode from a second signaling message.

15. The device of claim 14, wherein the first signaling message is an invite message for the communication session, and the second signaling message is a response message for the invite message.

16. An apparatus for conducting a communication session of packet data in a communication system supported by IP (internet protocol), comprising:

means for receiving a signaling message selected from the group consisting of an SIP INVITE message and a SIP200 OK message;

means for obtaining from the signaling message a communication mode selected from the group consisting of simple IP mode, mobile IP tunnel mode, and mobile IP routing optimization mode; and

means for enforcing a set of policies for the communication session, the set of policies requiring information provided by the communication mode.

17. An apparatus for conducting a communication session of packet data through a monitoring intermediary, comprising:

a memory unit having computer-readable instructions for determining a communication mode for the communication session, sending a signal for the communication mode through the monitoring intermediary during the communication session, and communicating the packet data through the monitoring intermediary using the communication mode during the communication session; and

a processor circuit, coupled to the memory unit, for processing the computer-readable instructions.

18. The apparatus of claim 17, wherein the memory unit further comprises computer readable instructions for preparing parameters including the communication mode in an invitation message and sending the invitation message through the monitoring intermediary.

19. The apparatus of claim 17, wherein the memory unit further comprises computer readable instructions for sending a signal through the monitoring intermediary in response to an invitation to the communication session.

20. An apparatus for a communication session of packet data through a monitoring intermediary in a communication system supported by IP (internet protocol), comprising:

a memory unit having computer readable instructions for determining a communication mode selected from the group consisting of simple IP mode, mobile IP tunnel mode, and mobile IP routing optimization mode, including the communication mode in a signaling message selected from the group consisting of SIP INVITE message and SIP200 OK message, and sending a signal for the communication session by sending the signaling message with the communication mode via the monitoring intermediary, so as to allow the monitoring intermediary to use information of the communication mode for packet data monitoring; and

a processor circuit, coupled to the memory unit, for processing the computer-readable instructions.

21. An apparatus for a communication session of packet data, comprising:

a memory unit having computer-readable instructions for receiving a communication mode from a signaling message of the communication session and enforcing a set of policies for the communication session of packet data that require information provided by the communication mode.

A processor circuit, coupled to the memory unit, for processing the computer-readable instructions.

22. The device of claim 21, wherein the signaling message is a first signaling message and the communication mode is a first communication mode, the memory unit further comprising computer readable instructions for receiving a second communication mode from a second signaling message.

23. The apparatus of claim 22, wherein the first signaling message is an invite message for the communication session of packet data, and the second signaling message is a response message to the invite message.

24. An apparatus for packet data communication in a communication system supported by an IP (internet protocol), comprising:

a memory unit having computer readable instructions for receiving a signaling message selected from the group consisting of an SIP INVITE message and a SIP200 OK message, obtaining from the signaling message a communication mode selected from the group consisting of a simple IP mode, a Mobile IP tunneling mode, and a Mobile IP routing optimization mode, and enforcing a set of policies on the communication session of packet data that require information provided by the communication mode; and

a processor circuit, coupled to the memory unit, for processing the computer-readable instructions.

25. An electrical signal transmitted via a signal carrier in a communication system, the electrical signal comprising computer-readable instructions for:

determining a communication mode for a communication session of packet data; and

transmitting, by a monitoring intermediary, a signal for the communication mode during the communication session of packet data.

26. An electrical signal transmitted via a signal carrier in a communication system, the electrical signal comprising computer-readable instructions for:

receiving a communication mode from a signaling message of a communication session of packet data; and

enforcing a set of policies for the communication session of packet data that require information provided by the communication mode.