Patent Application
20090036152
The present invention relates generally to wireless networks and more particularly to mobility in wireless networks utilizing multicast communications.
Internet Protocol (IP) Mobility provides seamless roaming across disparate heterogeneous radio access networks (RANs). As mobile clients or entities (MEs) roam and visit different access networks they engage in communications, sending and receiving various types of data such as voice, text and video. These communications often utilize internet protocol (IP) packet type communication in either a unicast (point-to-point) format or an IP multicast (one point-to-many points) format. One type of data expected to play a significant role in future communication systems (e.g., public safety multimedia systems) is for instance group video that can be sourced to a multicast destination. Those skilled in the art will recognize that there are numerous networks that will not support native multicast since their design generally precludes communications in this format. As such, the router will not replicate this multicast data and it will be dropped by the RAN and thus will not be delivered to the ME. Those skilled in the art will recognize that these types of MEs might include a cellular telephone or two-way radio transceiver that will never receive a multicast packet that could lead to a poor user experience.
There are a number of approaches set forth in the prior art that work to enable mobile users to use multicast communications. One approach known as “bidirectional tunneling” delivers IP multicast packets to a mobile entity (ME) using a unicast tunneling technique. IP tunneling is the process of embedding one IP packet inside of another, for the purpose of simulating a physical connection between two remote networks across an intermediate network. An ME is defined as either a standalone wireless mobile node or a mobile router servicing a mobile network. Bidirectional tunneling operates by conveying the multicast packets inside the unicast Mobile IP (MIP) tunnel between the Mobile IP Home Agent (HA) of the ME and the ME. It should be recognized that this is a form of multicast-in-unicast tunneling. Each time the ME moves, the unicast MIP tunnel is updated with the new care-of address of the ME corresponding to its new attachment point, and the delivery of multicast packets to the ME is maintained.
Similarly, the ME can also source multicast packets by sending them over the unicast tunnel towards its HA. One advantage of this approach is that, thanks to the unicast tunneling, multicast packets can be delivered to/from the ME even when attaching to a non-multicast capable network. On the other hand it introduces significant processing overhead (due to packet replication) on the HA when a large number of MEs need to receive the same multicast group from the HA. The packet replication at the HA also introduces significant overhead in networks visited by multiple MEs listening to the same multicast group since multiple unicast-tunneled copies of the same multicast packet will be sent towards the same visited network.
Another technique for providing multicast communications uses a prior art multicast tunneling technique. By addressing the overheads of the multicast-in-unicast tunneling scheme over multicast-capable networks, U.S. Patent Publication US2007/0086458A1, which is herein incorporated by reference, proposes the use of multicast-in-multicast tunneling between the mobility server (e.g., HA or mobile virtual private network (MVPN) server) and the ME. Advantages of this scheme include the reduced overhead on the mobility server and in the visited network compared to the unicast tunneling scheme. It also allows to provide for an MVPN-like security for multicast traffic, for instance by allowing the use of IPsec to encrypt the multicast tunnel between the mobility server and the ME thus providing confidentiality over public RANs traversed by the multicast packets between the mobility server and the ME. However, this scheme is applicable only when the visited network is multicast-capable.
Still another technique for providing multicast communications uses a technique referred to as Application Layer Multicasting where internet protocol (IP) multicast packets are delivered to mobile users over disparate networks. This technique provides for a multicast proxy between a multicast source and a mobile receiver. The multicast proxy is located at the edge of the access network and delivers IP multicast packets from the source to the mobile receiver either by means of unicast tunneling if the access network does not support multicast or natively if the access network supports multicast. The multicast proxy is statically configured for using either unicast tunneling or native multicast when forwarding multicast packet over the access network it serves based on the multicast capability of the access network. When the mobile receiver moves from one access network to another, it changes a multicast proxy and receives IP multicast packets according to the means supported by the new access network and statically configured in the new multicast proxy. In particular, such a multicast proxy does not dynamically adapt the means by which it forwards multicast packets to a mobile receiver.
In that all of these prior art techniques do not address switching between multicast delivery modes (i.e., native multicasting, multicast-in-unicast tunneling, or multicast-in-multicast tunneling) it would be advantageous to offer a multicasting technique allowing mobile entities (nodes or routers) to seamlessly operate in the multicasting mode most optimal for the particular network being visited by the mobile entities.
The accompanying figures, where like reference numerals refer to identical or functionally similar elements throughout the separate views and which together with the detailed description below are incorporated in and form part of the specification, serve to further illustrate various embodiments and to explain various principles and advantages all in accordance with the present invention.
Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions of some of the elements in the figures may be exaggerated relative to other elements to help to improve understanding of embodiments of the present invention.
Before describing in detail embodiments that are in accordance with the present invention, it should be observed that the embodiments reside primarily in combinations of method steps and apparatus components related to a method and apparatus for enabling multicast traffic flows over hybrid multicast capable and non-multicast capable radio access networks (RANs). Accordingly, the apparatus components, and method steps have been represented where appropriate by conventional symbols in the drawings, showing only those specific details that are pertinent to understanding the embodiments of the present invention so as not to obscure the disclosure with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein.
In this document, relational terms such as first and second, top and bottom, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. The terms “comprises,” “comprising,” or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. An element proceeded by “comprises . . . a” does not, without more constraints, preclude the existence of additional identical elements in the process, method, article, or apparatus that comprises the element.
It will be appreciated that embodiments of the invention described herein may be comprised of one or more conventional processors and unique stored program instructions that control the one or more processors to implement, in conjunction with certain non-processor circuits, some, most, or all of the functions of a method and apparatus for enabling multicast traffic flows over hybrid multicast capable and non-multicast capable radio access networks (RANs) described herein. The non-processor circuits may include, but are not limited to, a radio receiver, a radio transmitter, signal drivers, clock circuits, power source circuits, and user input devices. As such, these functions may be interpreted as steps of a method to perform a method and apparatus for enabling multicast traffic flows over hybrid multicast capable and non-multicast capable radio access networks (RANs). Alternatively, some or all functions could be implemented by a state machine that has no stored program instructions, or in one or more application specific integrated circuits (ASICs), in which each function or some combinations of certain of the functions are implemented as custom logic. Of course, a combination of the two approaches could be used. Thus, methods and means for these functions have been described herein. Further, it is expected that one of ordinary skill, notwithstanding possibly significant effort and many design choices motivated by, for example, available time, current technology, and economic considerations, when guided by the concepts and principles disclosed herein will be readily capable of generating such software instructions and programs and ICs with minimal experimentation.
The MM server 105 is configured such that the multicast capabilities of each RAN (e.g., RAN 107, RAN 109, and RAN 111) for which it has a connection are identified. Mobile entities like ME 113 operate to communicate in a multicast format with a RAN upon which it is in range. This configuration can be done but is not limited to a port-by-port configurable basis or range of internet protocol (IP) addresses. The MM server maintains a state-full list of MEs and the groups to which they are subscribed. The MM server 105 can maintain this list in a number of different ways, for instance by intercepting subscriptions to multicast groups issued by the ME 113. More precisely, the ME 113 can send its multicast subscription requests (e.g., Internet Group Management Protocol (IGMP) Report messages) for a given group (GI) to the MM server 105, for instance by reverse-tunneling them in the MIP tunnel (or in a Mobile VPN tunnel) to the MM server 105. Using this information the MM server 105 can (1) create a state binding the ME to the group it has registered to and (2) activate multicast routing for this group (e.g., by sending multicast routing messages, or acting as IGMP-proxy) so that multicast packets for this group are routed towards the MM server 105. This enables the MM server 105 to receive the multicast data destined to the MEs apriority.
Those skilled in the art will recognize that the above description is only one example of a possible network configuration. Only key elements are described such as the multicast source, the MM server 105, the ME 113, and a multiplicity of RANs 109 (possibly with different multicast-capabilities) to which the ME 113 can communicate and receive multicast packets (source by the multicast source) from the MM server 105. One key aspect of this network configuration concerns its dynamic adaptation of its delivery mode. Depending on the multicast capabilities of the RAN 107, 109, 111 the ME 113 is attached to (or of the multicast capabilities of the path between MM server 105 and ME 113), the MM server 105 will dynamically adapt its multicast delivery mode to the ME 113 so as to (1) preserve multicast session continuity upon handoff (seamlessness); and (2) optimize MM server 105 and network/RAN resources. In addition, the MM server 105 may also take into account other RAN characteristics (such as whether it is a public or private RAN 109) to select the multicast delivery method to use (for instance preferring multicast-in-multicast tunneling-over native multicasting- in the case of a public multicast-capable RAN 109 since this mode may allow to provide VPN-like security by protecting the multicast tunnel between MM server 105 and ME 113 (e.g., with Internet Protocol Security (IPsec)).
Leveraging off the MM server 105 ability to receive multicast data before the MEs, the MM server 105 is able to use its knowledge of each RAN's multicast capability to either (1) forward the multicast natively outside of any tunnel; (2) forward the multicast inside of a unicast tunnel (for instance over a non-multicast capable access); or (3) forward the multicast inside a multicast tunnel (for instance over a multicast capable access). This intelligence allows all MEs (not shown) to receive multicast data regardless of their RAN's capability, and transparently to the multicast source. Data is routed via native multicast where and when possible (e.g., when an ME is attached to a private/secure multicast-capable network), or tunneled inside multicast (e.g., when ME is attached to a public/non-secure multicast capable network), or tunneled inside unicast elsewhere (e.g., when an ME is attached to a non multicast-capable network).
As noted herein, in one embodiment of the invention, the MM server 105 is statically configured with the multicast capabilities of each RAN 107, 109, 111 for which it has a connection. For instance, in a first enablement, the MM server 105 is configured with a table mapping the range of IP addresses pertaining to a specific RAN to the multicast capability of that RAN. The MM server 105 can then use the care-of address configured by the ME, and for instance communicated to the MM server 105 by the ME using MIP signaling messages, for determining whether the RAN 107, 109, 111 and the ME 113 are currently multicast-capable. As a consequence, the MM server 105 can determine and use the most appropriate multicast delivery method for the ME 113 (e.g., native multicasting, multicast-in-unicast tunneling, or multicast-in-multicast tunneling). In an alternative embodiment of the invention, the MM server 105 works to dynamically retrieves the multicast capabilities of the RAN where the ME 113 is attached by contacting a specific fixed entity in the network either located in the RAN or in another part of the network.
Finally, in yet another embodiment of the invention, an ME (not shown) will notify the MM server 105 of its current multicast capability based on its current RAN attachment. In this case, the present invention introduces a novel signaling message called Multicast Delivery Request used by the ME 113 to indicate to the MM server 105 the multicast delivery mode to be used for delivering multicast packets of a specific multicast group from the MM Server 105 to the ME. The Multicast Delivery Request will include the multicast address or range of multicast addresses for which the request is sent and the desired multicast delivery mode. If the request is sent without specifying the multicast address or a range of addresses, the request is considered as applying for any multicast groups the ME 113 is subscribed to.
The desired multicast delivery mode(s), can be, but are not limited to, any of the following modes: (1) a native multicasting mode is where the MM server 105 forwards the multicast packets using native multicast routing towards the ME; (2) a unicast tunneling mode is where the MM server 105 tunnels multicast packets inside a unicast tunnel towards the ME; (3) a multicast tunneling mode is where the MM server 105 tunnels multicast packets inside a multicast tunnel towards the ME; (4) any combination of the native multicasting, unicast tunneling, or multicast tunneling modes. For instance requesting simultaneous delivery of a multicast group via both unicast tunneling and multicast tunneling (i.e., “bicasting”) can allow MM server 105 to discover the multicast capabilities of its new attachment point while ensuring seamless continuation of its ongoing multicast sessions; or (5) a suspend mode is where MM Server 105 suspends the delivery of multicast packets to the ME (via any of the delivery modes) but maintains ME's multicast membership for the multicast group(s). This can be used for instance when the ME 113 anticipates a loss of radio connection (i.e., autonomous mode) in order to reduce the load at its temporary unreachable RAN while maintaining its multicast subscription for faster recovery of the multicast sessions as soon as the radio connectivity becomes available (i.e., return to connected mode).
Those skilled in the art will recognize that future extensions that may introduce new or more specific modes may also be possible. Reference to a “more-specific” mode refers to the ability of the ME 113 to indicate additional parameters for characterizing the mode requested. For example, the ME 113 could request multicast-in-multicast tunneling mode and in addition can request a specific tunneling scheme such as IP tunneling, UDP tunneling, or IPsec encapsulating security payload (ESP) tunneling.
The MM server 105 replies to the ME 113 with a Multicast Delivery Reply message indicating the multicast delivery mode that will actually be used for the multicast group(s) listed in the received Multicast Delivery Request. The reply message can also include additional information that may be required by the ME 113 for receiving multicast packets according to the indicated delivery mode. For instance, when multicast-in-multicast tunneling is to be used, the Reply may contain for instance the IP multicast address used for the multicast tunnel, the IP address of the source of the multicast tunnel (e.g., one of the IP addresses of the MM server), some security materials (e.g., encryption keys) used for securing the multicast tunnel, etc. It should also be recognized that the multicast delivery mode included in the reply may be different from the one requested by the ME 113, for instance if the requested mode cannot be offered to the ME 113 for any reason such as a policy, technical limitation of the MM server 105 or the like.
The MM server 105 can also at any time force a multicast delivery mode for a specific group to a specific ME 113. In this case, the MM server 105 would send a Multicast Delivery Notification message to the ME 113 containing the same type of information as a Multicast Delivery Reply. This can be useful when the MM server 105 detects a technical issue in its neighborhood preventing the use of a specific mode such as a broken multicast infrastructure in the network preventing the use of native multicasting or multicast tunneling modes. This may also be useful in the cases due to a policy based decision, such as taking network usage cost into consideration. In instances where networks may charge additional fees for multicast service, the MM server may base its decision on factors other than technical capability.
The Multicast Delivery Request, Response, and Notification messages can be implemented in a number of different ways; for instance as, but not limited to, extensions of an existing multicast group membership signaling (i.e., Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) protocols), or as extensions of IP mobility signaling (i.e., Mobile IPv4/v6, NEMOv4/v6 protocols). It should be recognized that these may also be implemented as a completely new protocol. The MM server 105 tracks information about which “multicast delivery mode” is used for each ME 113 and for each multicast groups of the ME 113 in case different modes need to be used for different groups.
An ME 113 can discover the multicast capability of its RAN in a number of different ways that include but are not limited to receiving specific messages from the RAN indicating the RAN multicast capabilities (e.g., in a beacon), by monitoring data traffic on its network interface for eventually detecting multicast packets sent by other nodes, by monitoring multicast signaling on its network interface such as receiving an IGMP Query for the access router; by a user configuration to the way the middleware can discover if it is multicast capable, by a user-configuration to the way the middleware can discover if it is multicast capable, or by retrieving multicast capability from a configuration file based on other characteristics of the RAN such as its type (e.g., its technology type, whether it is a public or private RAN, its operator, etc).
In yet another embodiment of the invention, the ME 113 can use a bicasting mode (i.e., simultaneous use of unicast tunneling and multicast tunneling modes, or simultaneous use of unicast tunneling and native multicast modes) between the MM server 105 and itself to determine the multicast capability at its current point of attachment. More precisely, when an ME 113 moves into a new IP subnet for which it does not know the multicast capability, the ME 113 sends a Multicast Delivery Request to the MM server 105 requesting for the use of the bicasting mode. By detecting multicast packets received over the unicast tunnel, the ME 113 can determine that at least one multicast session is ongoing, and start testing the reception of multicast-in-multicast tunneled packets e.g., for a configurable amount of time.
If no multicast-in-multicast tunneled packets are received, the ME 113 can take this as an indication that multicast is not supported at its current point of attachment, for example, on the path from MM server 105 to the ME 113, and thus send a new Multicast Delivery Request to the MM server 105 requesting for the unicast tunneling mode exclusively. On the other hand, if multicast-in-multicast tunneled packet are received, indicating support of multicast at the current attachment point, the ME 113 can send a Multicast Delivery Request to the MM server 105 requesting for use of the multicast tunneling mode exclusively. Hence, the advantages of the bicasting approach for ME 113 to detect multicast capability of its attachment point is that (1) it is usable in any type of RAN (no extensions in the RAN are needed), and (2) it provide indication on multicast availability on the complete path between MM server 105 and ME 113, and not only at the ME's edge of the path.
It will be recognized that the bicasting mode can also be used to minimize interruption of ongoing multicast sessions as an ME 113 moves between IP subnets. Indeed, even if the ME113 knows that its new point of attachment is multicast-capable (and thus allows the use of the multicast-tunneling mode or the native multicast mode), the re-establishment of the multicast delivery tree at the new attachment point may introduce some delay (depending on the network topology) and thus impact the ongoing multicast session. By requesting a bicasting mode when entering a new IP subnet, the ME 113 can minimize the interruption of its multicast session (thanks to reception of packets via the unicast tunnel) while the multicast delivery tree (for the multicast tunneling or native multicast modes) is being established.
The MEs and/or MM server can also build states on the multicast capabilities of the care-of-address network prefixes used by the MEs as they roam from one site to another. This allows bypassing the multicast discovery messaging (e.g., requesting of the bicasting mode for multicast capability discovery) for those points of attachment that have been previously visited. This ensures a slow but steady reduction over time in the amount of overhead associated with multicast capability discovery.
The multicast mobility server process 200 includes the steps of determining multicast capabilities at ME attachment point 201. This may include determining multicast capabilities of only a subpart of path between the MM server and the current location of the ME, or determining multicast capabilities of the entire path between the MM server and the current location of the ME. The multicast capabilities determined may include, but are not limited to, the knowledge of whether or not multicast forwarding or routing is supported. It may include other (optional) information such as the type of protocol (e.g., IPv4 or IPv6) for which multicast is supported, any metrics of the routing path from MM server to ME (e.g., in number of hops, or using other metrics), as well as any additional information characterizing the RAN, such as its technology (WiFi, WiMAX, etc.) or its type (public or private RAN) which may be useful in the subsequent step of selecting a multicast delivery mode 203. As noted herein, the process of determining multicast capabilities 201 can be realized through a number of separated embodiments, such as static configuration at an MM server, dynamic discovery from a specific entity in the network, or by receiving a message from the ME such as a Multicast Delivery Request.
The method then selects a multicast delivery mode 203 for delivering a multicast packet to the ME. This selection can be based on various criteria, including the determined multicast capabilities (at the previous step) as well as other information, such as policies (e.g., restriction or preferences in certain delivery modes for a given ME), knowledge of current capabilities of the MM server, or any information characterizing the RAN the ME is attached to. The step of selecting the multicast delivery mode can include another sub-step of informing the ME about the selected multicast delivery mode and communicating (as part of this “informing” step) some parameters to the ME for enabling it to be configured for receiving a multicast packet according to the selected multicast delivery mode. In the case of a multicast-in-multicast tunneling mode, such parameters may be the tunnel multicast address, the source address of the multicast tunnel (MM server address or another), security keys/materials, the type of multicast tunnel (IP tunneling, UDP tunneling, IPsec ESP tunneling), etc. Thereafter, the multicast packet is delivered 205 to the ME according to the selected delivery mode.
Next, the process involves notifying multicast capabilities 303 to the MM server. This step can be realized by sending the multicast capabilities or instead by requesting to the MM server the use of a specific multicast delivery mode for a set of and/or all of the multicast group(s). This refers to the use of a Multicast Delivery Request message and the various possible modes including native Multicasting, unicast tunneling, multicast tunneling or any combination thereof and a Suspend mode.
The ME is then configured 305 for receiving multicast packets according to the selected delivery mode and may include the sub-step of receiving from the MM server the selected multicast delivery mode and any specific parameters for the ME to configure itself for receiving multicast packets according to the selected multicast delivery mode. In the case of multicast-in-multicast tunneling mode, such parameters may be, for instance: the tunnel multicast address, the source address of the multicast tunnel (MM server address or another), some security keys/materials, the type of multicast tunnel such as IP tunneling, UDP tunneling, IPsec ESP tunneling etc. The configuring step would here also include the step for the MM of subscribing to the tunnel multicast address for receiving the multicast-in-multicast tunneled packets.
Detecting the arrival of multicast packets is started 409 and may for example involve setting a timer for detecting the arrival of multicast packets in the multicast tunnel. If the timer expires before a given amount of multicast packet(s) is received over the multicast tunnel, the ME can conclude 411 that multicast-in-multicast tunneling cannot be used and proceeds to send a request to the MM server for stopping multicast-in-multicast tunneling and using only multicast-in-unicast tunneling for multicast group to ME 415. Similarly, if before the timer expires a predetermined number of multicast packet(s) has been received over the multicast tunnel, the ME can conclude 411 that multicast-in-multicast tunneling can be used and proceeds to send a request to the MM server 413 for stopping multicast-in-unicast tunneling and using only multicast-in-multicast tunneling for multicast group to the ME. Those skilled in the art will recognize that during this detection process, the ME should drop any multicast packet possibly coming from the multicast tunnel until multicast-in-multicast tunneling is used exclusively in order to avoid processing duplicated packets from the unicast and the multicast tunnel. After sending the request to the MM server at step 413 or step 415, a confirmation is received from the MM server 417 about the selected multicast deliver mode. Thereafter the received multicast packet is continually processed 419 according to the selected multicast delivery mode.
Hence, an embodiment of the invention allows an ME (mobile node or mobile router) to maintain its IP multicast sessions while moving between different visited networks with disparate multicast capabilities. Especially, the invention allows always selecting the most appropriate multicast delivery mode between the MM server and the ME for (1) ensuring seamless continuation of multicast session upon a handoff, and (2) optimizing MM server and network resources when possible. This process enables multicast traffic flows over hybrid multicast capable and non-multicast capable RANs and relies on an intermediary device such as the MM server to have a working knowledge of disparate RAN types and their multicast capabilities, and having the intelligence to forward the multicast traffic to the ME either natively, or inside a unicast, or inside a multicast tunnel, or using any combination of these modes. The MM server works to dynamically adapt the delivery of multicast packets to an ME based on the multicast capability of the RAN the ME is attached to. In a delivery mode, the process can be dynamically adapted each time the ME performs a handoff to select an appropriate mode based on the multicast capability at the new attachment point. This process requires the MM server to intercept all multicast data ahead of the actual MEs/group members and in that it maintains states for each ME, the states refer to the multicast delivery mode to be used for a given ME and eventually multicast group of the ME.
In the foregoing specification, specific embodiments of the present invention have been described. However, one of ordinary skill in the art appreciates that various modifications and changes can be made without departing from the scope of the present invention as set forth in the claims below. Accordingly, the specification and figures are to be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of present invention. The benefits, advantages, solutions to problems, and any element(s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as a critical, required, or essential features or elements of any or all the claims. The invention is defined solely by the appended claims including any amendments made during the pendency of this application and all equivalents of those claims as issued.
