Network system and method for processing ip multicast by means of radio atm
Abstract
[Task] Provides IP multicast for use on wireless ATMs.
Solution.A wireless ATM system consists of a fixed core network and a shared wireless access link to mobile terminals. Unlike point-to-point ATM links in fixed / wired networks, wireless ATM links use a common VC space for all mobile terminals. The medium access (MAC) protocol allows multiple access over the downlink, but only supports unicast transmission over the uplink. The present invention also provides a method by which IP multicast can be simply supported on such WATM links by extending the Internet Group Management Protocol (IGMP). In addition, it provides a cell-level error recovery method at the DLC (Data Link Control) layer to improve the (IP) packet level output of the transport layer.

Term
Term ended
Projected expiry passed 14 April 2019, 7.4 years ago.
- Priority
- Filed
- Published
- Projected expiry
- Today
27 claims: 10 independent, 17 dependent
- 1【特許請求の範囲】 【請求項1】 ATMネットワークを介して宛先にパケットフローを伝送するための予め定められたプロトコルを有し、 未使用仮想チャネル識別子(VCI)を用いてATMセルシーケンスを伝送するためのソースと、 ルータ及びATMスイッチを有するノードとを備えたネットワークシステムにおいて、 上記ルータは、ホップバイホップでシグナリングを行うことなく、複数個の出力ポートの一つを上記未使用VCIと関連付け、これにより、切換パスを設定し、 上記ATMスイッチは、上記ATMセルの各々が上記未使用VCIと同一のVCIを有する場合には、上記ルータの制御によらずに、上記複数個の出力ポートのうち、上記一つを介してATMセルを転送し、 マルチキャスト仮想チャネル(VC)が、IPマルチキャストグループに対応するアドレスを、上記マルチキャストVCに対応するVC番号にマッピングすることにより得られ、 少なくとも一つの基地局が、上記マッピングを用いて、上記IPマルチキャストグループの一つに加入する新たな移動体にVC番号を付与することを特徴とするシステム。
- 2【請求項2】 上記基地局は、VCと移動体との間の対応関係を決定することを特徴とする請求項1に記載のシステム。
- 3【請求項3】 上記基地局から移動体への単一方向ブロードキャストVCと、上記基地局と上記移動体の間の制御メッセージを送信するための双方向制御VCが予め構築されていることを特徴とする請求項1に記載のシステム。
- 4【請求項4】 上記基地局と移動体の間の制御プロトコルはVC REQUESTおよびVC RECLAIM制御メッセージを有し、 上記VC REQUESTメッセージは、データを送出すべきVCを上記基地局に要求するために移動体により用いられ、 上記VC RECLAIMメッセージは、上記移動体に割り当てられた上記VCを再要求するために基地局により用いられることを特徴とする請求項1に記載のシステム。
- 5【請求項5】 上記基地局は、パケット境界を検出し、複数個のフローをひとつのVC内にマージすることを特徴とする請求項1に記載のシステム。
- 6【請求項6】 上記基地局は、送信元IPアドレス、マルチキャストグループアドレス、及び、VC番号の間のマッピング関係を保持していることを特徴とする請求項1に記載のシステム。
- 7【請求項7】 ダウンリンクIGMPメッセージの形式でのクエリーがブロードキャストVC上に伝送されるように、インターネットグループ管理プロトコル(IGMP)を拡張し、 マルチキャスト移動体が上記IGMPメッセージを受信して適切なレポートを生成し、 非マルチキャスト移動体がIPレベルにおいて上記IGMPメッセージを廃棄することを特徴とする請求項1に記載のシステム。
- 8【請求項8】 基地局に対するアップリンクIGMPメッセージの形式でのレポートが、ユニキャスト制御VC上に伝送されるように、インターネットグループ管理プロトコル(IGMP)を拡張し、 すべての移動体が上記IGMPメッセージを受信するように、上記基地局が上記IGMPメッセージを再ブロードキャストし、 IGMPメッセージを送出する移動体以外の移動体が、さらなるレポートが生成されるのを防ぐためにタイマをリセットすることを特徴とする請求項1に記載のシステム。
- 9【請求項9】 上記基地局は、VCの活性状態において活性判定のためにタイマを用い、上記タイマがタイムアウトすると、上記VCを再要求することを特徴とする請求項4に記載のシステム。
- 10【請求項10】 上記基地局は、周期的に上記マッピングをブロードキャストし、メッセージに関与しない移動体はIPレベルにおいて上記メッセージを廃棄し、メッセージに関与する移動体は、上記メッセージに対応するVCをオープンすることを特徴とする請求項6に記載のシステム。
- 11【請求項11】 上記ブロードキャストは、IGMPホストメンバーシップ照会(クエリー)メッセージとともに送出されることを特徴とする請求項10に記載のシステム。
- 12【請求項12】 無線レイヤを介してマルチキャストトラフィックを転送するためのマルチキャストフローシステムにおいて、データリンク制御プロトコル(DLC)は否定応答(NACK)方式を用い、受信先が、セルを紛失した場合もしくは上記受信先が破損セルを受信した場合にのみ、ビットマップベクトルとともにNACKを送出することを特徴とするシステム。
- 13【請求項13】 デッドロックを避けるためにタイマが用いられ、伝送されたセルは上記タイマがタイムアウトするまでバッファに格納され、上記バッファは上記タイマがタイムアウトした後にクリアされることを特徴とする請求項12に記載のシステム。
- 14【請求項14】 損失を検出すると、受信先は受信先タイマを維持し、上記受信先タイマは、デッドロックを防ぐために用いられるタイマのタイムアウト値とほぼ同じタイムアウト値を有することを特徴とする請求項13に記載のシステム。
- 15【請求項15】 上記受信先は上記受信先タイマがタイムアウトするまで再送を要求することを特徴とする請求項14に記載のシステム。
- 16【請求項16】 送信元は、上記受信先タイマに結びつけられたタイムアウト値のほぼ半分のタイムアウト値をもつ付随的な確認応答タイマを有し、 上記送信元は、送信すべきデータがある場合には、付随的な確認応答タイマをリセットし、 上記送信元は、上記送信元が最後のグループのセルを伝送した後に、付随的なACK(確認)メッセージを送出することを特徴とする請求項14に記載のシステム。
- 17【請求項17】 上記受信先が伝送セルのシーケンス番号を含む附随的なACKメッセージを受信すると、上記受信先はセル損失が生じたかどうかを判定し、セル損失が生じた場合、NACKメッセージを返送することを特徴とする請求項16に記載のシステム。
- 18【請求項18】 VC空間が、ユニキャストVC、ブロードキャストVC、及び、マルチキャストVCに分割されていることを特徴とする無線ATMシステム。
- 19【請求項19】 ユニキャストIPアドレスは、上記ユニキャストVCにマッピングされることを特徴とする請求項18に記載のシステム。
- 20【請求項20】 マルチキャストIPアドレスは、上記マルチキャストVCにマッピングされることを特徴とする請求項18に記載のシステム。
- 21【請求項21】 ブロードキャストIPアドレスは、上記ブロードキャストVCにマッピングされることを特徴とする請求項18に記載のシステム。
- 22【請求項22】 移動体のためのマルチキャストグループ加入方法において、 (a) 無線制御チャネル上で基地局との接続を開始するステップと、 (b) 上記移動体において、ブロードキャストVC番号と上記移動体が使用すべきユニキャスト制御VC番号を含む応答を受信するステップと、 (c) 上記制御VCを介して、IGMP加入メッセージを送出するステップと、 (d) マルチキャストグループ、VC番号 のマッピングが存在するかどうかを調べるために基地局データベースを検索するステップと、 (e) 利用可能なVCプールからVCをとり出し、上記VCに対して マルチキャストグループ、VC番号 のマッピングを作成し、ステップdにおいて上記マッピングが存在しなければ、上記データベース内に情報を格納するステップと、 (f) ステップdにおいて上記マッピングが存在する場合には、既存のマッピングされたVCを提供するステップと、 (g) ブロードキャストVC上で、上記移動体に マルチキャストグループアドレス、VC番号 を伝送するステップと、 (h) データ受信のために上記 マルチキャストグループアドレス、VC番号 のマッピングに対応するVCをオープンするステップとを備えたことを特徴とする方法。
- 23【請求項23】 上記方法は、さらに、 (i) 上記ブロードキャストVC上にホストメンバーシップクエリーを送出するステップと、 (j) 移動体がマルチキャストグループに属さない場合、メッセージを廃棄するステップと、 (k) 移動体が上記対応するマルチキャストグループに属する場合、ランダムに選択されたタイムアウト値を有するレポート遅延タイマをスタートさせるステップと、 (l) 上記タイマがタイムアウトすると、上記ブロードキャストVC上にホストメンバーシップレポートを送出するステップと、 (m) 上記ホストメンバーシップレポートを再ブロードキャストするステップと、 (n) ステップmの再ブロードキャストを受信すると、タイマをリセットし、レポートを生成しないステップとを備えたことを特徴とする請求項22に記載の方法。
- 24【請求項24】 移動体のためのマルチキャストグループ離脱方法において、 (a) 制御VCを用いて基地局にIGMP離脱メッセージを送出するステップと、 (b) 対応するVCに結合されたカウンタの値を減少させるステップと、 (c) 上記カウンタがゼロに達したかどうかをチェックするステップと、 (d) ステップcにおいて、上記カウンタがゼロに達しなかった場合、ステップbにおける上記VC上の伝送を続行するステップと、 (e) 上記移動体に対して対応するVCをクローズするステップと、 (f) 全てのカウンタがゼロ以下になると、切断メッセージを送出するステップとを備えたことを特徴とする方法。
- 25【請求項25】 移動体をマルチキャストグループにマッピングし、且つ、上記マルチキャストグループから上記移動体を削除するために用いられる方法において、上記マルチキャストグループに関連したすべての移動体のデータベースを維持するステップと、上記マルチキャストグループに加入しているすべての移動体の群をマルチキャストグループにマッピングするステップとを備えたことを特徴とする方法。
- 26【請求項26】 移動体をマルチキャストグループにマッピングし、且つ、上記マルチキャストグループから上記移動体を削除するために用いられる方法において、マルチキャストグループをカウンタにマッピングするステップを備え、移動体が上記マルチキャストグループに加入すると、上記カウンタの値を増加させ、上記移動体が上記マルチキャストグループを離脱すると、上記カウンタの値を減少させることを特徴とする方法。
- 27【請求項27】 移動体をマルチキャストグループにマッピングし、且つ、上記マルチキャストグループから上記移動体を削除するために用いられる方法において、切断メッセージが上流側に送出された場合、移動体の不存在を暗示的に推定するステップを備えたことを特徴とする方法。
Independent claims27
215 paragraphs in 1 section, as filed
Description: TECHNICAL FIELD [Detailed description of the invention]
【0001】
[Technical field to which the invention belongs]
The present invention relates to a wireless asynchronous transfer mode (ATM) network. Specifically, the present invention relates to computer communication and networking, and more particularly to a method of transmitting a packet formed according to a protocol different from that of ATM on a wireless ATM network, and a network system for transmitting the packet.
【0002】
[Conventional technology]
Since wireless ATMs are useful for providing wideband wireless services, research and development are being actively carried out. This wireless ATM is about to be standardized by the ATM forums of related organizations and the European Telecommunications Standards Institute (ETSI). Conventionally, as a wireless ATM system, for example, there is a WATM net, and this WATM net has two main components. That is, it is provided with (a) a fixed core network and (b) a shared wireless access link that extends ATM cell transmission to the mobile host. For WATM net, "WATM net: A prototype wireless ATM system for multimedia personal communication" by D.Raychaudhuri, LJFrench, RJSiracusa, SKBiswas, R.Yuan, P.Narasimhan, CA Johnston (IEEE Journ. Select. See Areas Commun., January 1997).
【0003】
Other traditional wireless ATM systems are also "WATMnet: A prototype wireless ATM system for multimedia personal communication" (IEEE Journ. Select. Areas Commun) by D. Raychaudhuri, LJ French, RJ Siracusa, SKBiswas, R. Yuan, P. Narasimhan, CA Johnston. , January 1997).
【0004】
Furthermore, the technology for mobile communication using conventional mobile ATMs is "Mobility management in wireless ATM networks" (IEEE Commun. Mag., 1997) by A.Acharya, J.Li, B.Rajagopalan, and D.Raychaudhuri. ).
【0005】
Also, on providing Internet Protocol (IP) support within the core network, Arup Acharya, Rajiv Dighe, and Furquan Ansari, "IP switching over fast ATM cell transport (IPSOFACTO): Switching multicast flows" (Proc. IEEE Globecom, 1997). In a paper entitled "A framework for IP switching over fast ATM cell transport (IPS OF ACTO)" (Proc. SPIE, 1997) by Arup Acharya, RajivDighe, and Furquan Ansari.
【0006】
Regarding the method called IPoATM (IPoverATM) and IPSO FACTO, US Patent Application No. 08 / 771,559 (corresponding Japanese patent application number, Japanese Patent Application No. 09), which is being simultaneously pending by Acharya et al., The inventor of the present invention. -350411), as well as in US Patent Application No. 09 / 080,208, which is also pending simultaneously by Acharya et al., Which is also referred to herein as necessary.
【0007】
Here, in order to facilitate the understanding of the present invention, a method called IPSO FACTO will be described.
【0008】
IPSOFACTO (IP Switching Over Fast ATM Cell Transport) is an aspect of a method of mapping an IP flow to a switching path (virtual connection) within a network of ATM switches.
【0009】
On the other hand, as a standard IPoATM method, for example, "NBMA next hop resolution protocol (NHRP)" by James V. Luciani, Dave Katz, David Piscitello, Bruce Cole (Internet Draft, jdraft-ietf-rolc-nhrp-13. txtj, Work in Progress; Techniques outlined in "Classical IP and ARP over ATM" (ATM Forum) by Mark Laubach; "Multiprotocol over ATM version 1.0 (baseline text version 16)" (ATM Forum) by Andre N. Fredette (editor) There is.
【0010】
The IPSO FACTO method described above differs from the standard IPoATM method in that it does not use the ATM signaling stack to set up connections between endpoints.
【0011】
In IPSOFACTO, the first datagram of a new IP flow sets up a hop-by-hop connection between endpoints as it passes through an ATM switch. "IPSO-FACTO: IP switching over fast ATM cell transport" by Arup Acharya, Rajiv Dighe, Furquan Ansari (Internet Draft, jdraft-acharya-ipsw-fast-cell-00.txtj, 1997); Arup Acharya, Rajiv Dighe, "A framework for IP switching over fast ATM cell transport (IPSOFACTO)" by Furquan Ansari (Proc.SPIE, 1997); See "IP switching over fast ATM cell transport (IPSOFACTO): Switching multicast flows" (Proc. IEEE Globecom, 1997) by Arup Acharya, Rajiv Dighe, and Furquan Ansari.
【0012】
A.1 (a). Basic operation of IPSO FACTO The operation in IPSOFACTO is based on mapping all IPSOFACTOVC in the input port to either the switch control processor or the output port. Here, VC, ATM signaling, etc. for IPSO FACTO are provided in the switch. There is no VC that cannot be used for IPSO FACTO that makes it impossible to transfer data. Unused VCs on the switch's input ports are mapped to the switch control processor. Data transmitted using unused VCs is always given to the controller, which runs a traditional IP protocol stack that includes the required IP routing protocols.
【0013】
FIG. 1 is for explaining the basic operation of IPSO FACTO described above. Each port on the switch constitutes an IP interface. The illustrated IP routing table defines routes to destination networks 1.2 and 4.1.2 using the output interfaces configured on interfaces 2 and 3, respectively. VC82 on input port i is first mapped to the control processor.
【0014】
The cell level switching path for transferring data in the above system is set as follows. The source selects an unused VC on the output link and forwards the first packet of the new flow. This packet is received by the switch processor downstream of the link, which then selects the egress link based on its IP routing table. This first packet is then forwarded by the processor on the selected output link by choosing an unused VC on each link.
【0015】
In the example shown in Figure 1, the upstream router has selected the VC82 to replace the new flow. The first packet of this flow is received by the router shown, which then examines the IP routing table and selects the egress interface (3 in this case). On interface 3, VC51 is selected to forward the packet to the downstream router. Since the switch control processor has all the information <input port, input VC, output port, output VC> necessary to switch the flow, add an entry in the switch VC table. All subsequent cells are exchanged. At this time, the control processor does not need to transmit at the packet level thereafter.
【0016】
Unlike data packets exchanged at the cell level, no switching path is formed for IP control messages. Normally, the control message is sent and received on a predetermined control VC. Therefore, such control messages are forwarded through all switch control processors. This mechanism is used to set the transfer state for each flow. Changes in the transfer state, such as disconnecting the output interface, are used to change the switching path (eg, remove the <outside port, VC> from the VC table). When the control processor is released from the transfer state, the corresponding switching path is released by marking the input and output VCs as unused.
【0017】
B. Wireless ATM system Figure 2 shows the configuration of a conventional wireless ATM system. In such a network architecture, the base station allows the mobile terminal to be connected via a wireless link. In addition, the base station is connected to the core network via a wired link. Data from the wired interface to the wireless interface is exchanged at the base station, and the ATM cell is transmitted to the mobile terminal via the wireless link within the TDMA (Time Division Multiple Access) frame. This makes an end-to-end ATM connection. Each base station can support a predetermined number of mobiles within its domain.
【0018】
Dynamic TDMA / TDD (Time Division Duplexing) (Fig. 3) protocol with centralized control is used for wireless access over WATM links. The downlink (downlink) information from the base station including the control information and the ATM cell is multiplexed into a single burst and transmitted to the beginning of the TDMA frame following the preamble and the frame header. The base station controls slot allocation to the mobile within the uplink (uplink). The uplink control information includes a bandwidth allocation request and is slotted and transmitted in ALOHA contention mode. For more information on TDMA / TDD frame formats, see "Design and Performance of radio access protocol in WATMnet, a prototype wireless ATM network" (Proc. ICUPC, 1997) by P. Narasimhan, SKBiswas, CA Johnston, RJSiracusa, and H. Kim. Are listed.
【0019】
For IPSOFACTO, the important thing is that all cells on the downlink burst are received at the radio layer on all mobile terminals. However, the MAC (Media Access Control) layer of each mobile terminal filters the received cells based on the VC number and transfers the cells to the DLC (Data Link Control) layer for the terminal previously opened by the VC. .. Uplink transmission is point-to-point, with cells being transmitted from the terminal to the base station through each slot. At the MAC layer at the base station, cells are sent to the DLC layer only if the corresponding VC is already open. The space allocated to VCs in both directions is common to all mobile terminals. In the case of a conventional wireless ATM system, the access link is shared among all mobiles, but a separate control VC is used for each mobile.
【0020】
B.1. Background Transmission of IP packets to a subset of hosts on a network is called multicasting. The main advantage of multicasting is low network and host overhead when sending packets to a group of recipients. Class D addresses in the IP (IPV4) address space (224.0.0.0 to 239.255.255.255) are reserved for multicast operation. Multicast addresses do not identify an IP interface on the Internet, but instead identify an interface group. Multicast is well supported by local area networks such as Ethernet with efficient broadcast delivery and large multicast address spaces.
【0021】
Hardware-level filters on network interface cards remove unwanted datagrams before they reach the IP layer. In order for the hardware filter to work, the network interface must translate the IP multicast group destination into a link-layer multicast address that can be recognized by the network hardware. In practice, an Ethernet multicast address is created by mapping the lower 27 bits of the IP multicast address to the last 23 bits of the Ethernet address. For this conversion, see "TCP / IP illustrated, Volume 1:" by Gary R. Wright and W. Richard Stevens. See The protocols (Addisson-Wesly Publishing Co., Reading, Massachusetts, 1995). In addition, a multicast routing protocol is required within the network to copy packets and forward them to multiple destinations within the network.
【0022】
B.2. Multicast on point-to-point links Multicast operation on point-to-point links using IPSOFACTO is also relatively easy. The first IP packet of the multicast flow arriving at the switch controller causes the transmit cache entry to be installed in the multicast transmit cache. The VC number and port number (selected by the upstream switch controller) of the incoming packet are obtained. In addition, for each output interface in the newly created multicast transmit cache, IPSO FACTO selects an unused VC and sends the packet to the downstream switch controller. It then enters the switch hardware VC table that corresponds to mapping the input ports and input VCs to the list of output ports and output VCs. All subsequent packets in the flow are switched at the cell level using the hardware multicast feature of the ATM switching structure.
【0023】
B.3. Multicast on WATM Link: Problem Definition Multicast on shared wireless access links presents some new problems. One of these problems is logically caused by the link in this case being broadcast on the downlink and unicast on the uplink. When multicasting to a group of mobiles, it is necessary to map the IP multicast address to the link layer address as in the case of Ethernet. Mobiles that do not belong to the multicast group need to remove unwanted data as appropriate at the hardware level. The link layer identifier for (wireless) ATM is the virtual channel (VC) number. Mapping the IP multicast address to the VC number is required to achieve the desired result.
【0024】
Another problem with wireless ATM systems is the need to improve execution throughput at the transport layer. Since the bit error rate (BER) of wireless links is much higher than the bit error rate of fixed ATM networks, a cell-level error recovery mechanism that prevents a decrease in packet-level throughput is required. Cell-level recovery mechanisms for different traffic classes of unicast connections are discussed in "Data link control protocols for wireless ATM access channels" (Proc. ICUPC, 1995) by H.Xie, P.Narasimhan, R.Yuan, and D.Raychaudhuri. Has been done. In order to map IP multicast flows to multicast VCs (UBRs), cell-level error recovery (and cell sequencing) mechanisms must be extended to handle multiple recipients.
【0025】
[Problems to be Solved by the Invention]
The conventional method has at least the following problems.
【0026】
The conventional method cannot handle wireless ATM links to mobile terminals. Thus, being able to handle wireless ATM links is essential to fully realize the potential of prior art such as IPSO FACTO.
【0027】
Internet Group Management Protocol (IGMP) is inadequate, as stated in W. Fenner's "Internet group management protocol, version 2" (Internet Working Group Request for Comments 2236, November 1997). is there. Therefore, more effective improvements and methods are needed to reduce unnecessary multicast traffic between the base station and the mobile.
【0028】
The cell-level error recovery mechanism is insufficient to handle multiple recipients.
【0029】
An object of the present invention is to provide multicasting on a wireless ATM link to a mobile terminal to solve the above problems.
【0030】
[Means for solving problems]
In order to achieve the above object, the present invention has a predetermined protocol for transmitting a packet flow to a destination via an ATM network, and transmits an ATM cell sequence using an unused virtual channel identifier (VCI). In a network system with a source to do so and a router and a node with an ATM switch, the router associates one of a plurality of egress ports with the unused VCI without hop-by-hop signaling. As a result, the switching path is set, and when each of the ATM cells has the same VCI as the unused VCI, the ATM switch does not control the router and has the plurality of output ports. Of these, the ATM cell is transferred via one of the above, and the multicast virtual channel (VC) is obtained by mapping the address corresponding to the IP multicast group to the VC number corresponding to the multicast VC, and at least one of them. A system is obtained in which one base station uses the above mapping to assign a VC number to a new mobile unit that joins one of the above IP multicast groups.
【0031】
As the above improvement, in the above system, a system is obtained in which the base station determines the correspondence between the VC and the mobile body. Further, in the further improvement, in the above system, a unidirectional broadcast VC from the base station to the mobile body and a bidirectional control VC for transmitting a control message between the base station and the mobile body are constructed in advance. A system characterized by the fact that it is used is obtained.
【0032】
Preferably, the control protocol between the base station and the mobile has VC REQUEST and VC RECLAIM control messages, which are used by the mobile to request the base station to send data to the VC. , The VC RECLAIM message is used by the base station to reclaim the VC assigned to the mobile.
【0033】
As a further improvement, in the system, the base station uses a timer for activity determination in the VC active state, and when the timer expires, the system reclaims the VC.
【0034】
As yet another improvement, in the system, the base station can detect a packet boundary and merge a plurality of flows into one VC.
【0035】
As yet another improvement, in the system, the base station obtains a system characterized in that the mapping relationship between the source IP address, the multicast group address, and the VC number is maintained.
【0036】
Preferably, the base station periodically broadcasts the mapping, mobiles not involved in the message discard the message at the IP level, and mobiles involved in the message open the VC corresponding to the message. More preferably, the broadcast is sent with an IGMP host membership query message.
【0037】
As yet another improvement, the system extends the Internet Group Management Protocol (IGMP) so that queries in the form of downlink IGMP messages are transmitted over broadcast VCs so that multicast mobiles receive the IGMP messages. Produces appropriate reports, resulting in a system characterized by non-multicast mobiles abandoning the above IGMP messages at the IP level.
【0038】
As yet another improvement, in the above system, the Internet Group Management Protocol (IGMP) has been extended so that reports in the form of uplink IGMP messages are transmitted over unicast control VCs, and all moving objects are said to be IGMP. It is characterized in that the base station rebroadcasts the IGMP message so as to receive the message, and the mobile body other than the mobile body sending the IGMP message resets the timer to prevent further reports from being generated. You get a system to do.
【0039】
According to another aspect of the invention, in a multicast flow system for forwarding multicast traffic over the wireless layer, the data link control protocol (DLC) uses a negative response (NACK) scheme and the recipient receives a cell. A system can be obtained that sends out a NACK with a bitmap vector only if it is lost or if the recipient receives a corrupted cell.
【0040】
As yet another improvement, in the system, a timer is used to avoid deadlock, the transmitted cell is stored in a buffer until the timer expires, and the buffer is cleared after the timer expires. A system characterized by is obtained.
【0041】
Preferably, when a loss is detected, the receiver maintains a receiver timer, which has a timeout value that is approximately the same as the timer timeout value used to prevent deadlock. More preferably, the receiver requests retransmission until the receiver timer expires.
【0042】
As a further improvement, in the system, the source has an accompanying acknowledgment timer with a timeout value that is approximately half the timeout value associated with the destination timer, and the source has additional data to be transmitted. If there is, the system is characterized in that the incidental acknowledgment timer is reset and the source sends an incidental ACK message after the source has transmitted the cells of the last group. can get. Preferably, when the recipient receives an accompanying ACK message containing the sequence number of the transmission cell, the recipient determines if a cell loss has occurred and returns an NACK message indicating that the cell loss has occurred. ..
【0043】
According to another aspect of the present invention, in a wireless ATM system, a system characterized in that the VC space is divided into unicast VC, broadcast VC, and multicast VC can be obtained. As a further improvement, in the above system, a system characterized in that the unicast IP address is mapped to the above unicast VC is obtained.
【0044】
As yet another improvement, in the above system, a system characterized in that the multicast IP address is mapped to the above-mentioned multicast VC can be obtained.
【0045】
As yet another improvement, in the system, a system is obtained in which the broadcast IP address is mapped to the broadcast VC.
【0046】
According to another aspect of the present invention, in the multicast group joining method for a mobile body, a step of initiating a connection with a base station on a radio control channel, and in the mobile body, a broadcast VC number and the mobile body A base station to check if there is a <group, VC number> mapping, a step to receive a response containing a unicast control VC number to use, a step to send an IGMP join message on the control VC, and a <group, VC number> mapping. Step to search the database, take the VC from the available VC pool, create a mapping of <multicast group, VC number> to the above VC, and if the above mapping does not exist, put the information in the above database. A step to store, a step to provide an existing mapped VC if the above mapping exists, a step to transmit <group address, VC number> to the moving body on the broadcast VC, and data reception. Therefore, a method characterized by having a step of opening a VC corresponding to the mapping of the above <multicast group address, VC number> can be obtained.
【0047】
As a further improvement, in the above method, the above method further includes a step of sending a host membership query on the broadcast VC, a step of discarding the message if the mover does not belong to the multicast group, and a move. When the body belongs to the corresponding multicast group, a step of starting a report delay timer having a randomly selected expiration value, and a step of sending a host membership report on the broadcast VC when the timer times out. A method can be obtained that includes a step of rebroadcasting the host membership report and a step of resetting the timer and not generating the report when the rebroadcast is received.
【0048】
As another aspect of the present invention, in a method of leaving a multicast group for a mobile, a step of sending an IGMP leave message to a base station using a control VC and a step of reducing the value of a counter bound to the corresponding VC. And, a step of checking whether the counter has reached zero, a step of continuing transmission on the VC if the counter has not reached zero, and closing the corresponding VC for the mobile body. A method is obtained characterized in that a step and a release message are sent when all counters are below zero.
【0049】
In another aspect of the invention, the method used to map a mobile to a multicast group and remove the mobile from the multicast group maintains a database of all mobiles associated with the multicast group. A method is obtained, which comprises a step of mapping all the mobiles subscribed to the multicast group to the multicast group.
【0050】
According to yet another aspect of the invention, the method used to map a mobile to a multicast group and remove the mobile from the multicast group comprises the step of mapping the multicast group to a counter. A method is obtained in which the value of the counter is increased when the mobile unit joins the multicast group, and the value of the counter is decreased when the mobile unit leaves the multicast group.
【0051】
Also, according to another aspect of the invention, in a method used to map a mobile to a multicast group and remove the mobile from the multicast group, the presence of the mobile from the multicast outing protocol. A method is obtained that is implicitly estimated and features a disconnect message being sent upstream if the mobile is not associated with a multicast group.
【0052】
BEST MODE FOR CARRYING OUT THE INVENTION
Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.
【0053】
Preferred embodiments of the present invention are described in detail in U.S. Patent Application No. 08 / 771,559 (Japanese Patent Application No. 09-350411) and U.S. Patent Application No. 09 / 080,208 by Acharya et al., The inventor of the present invention. It is an extension of the existing IPSO FACTO system. An important factor in traditional IPSO FACTO is the ability to select unused VCs for new IP flows. In the case of a bidirectional point-to-point link, all unused VCs point only to the terminal / switch at the other end of the link, making selection easy.
【0054】
On the other hand, the wireless ATM link in the WATM net system supports multiple mobile terminals. Such wireless links have broadcast downlinks and unicast uplinks. In this regard, "WATM net: A prototype wireless ATM system for multimedia personal communication" by D. Raychaudhuri, LJ French, RJ Siracusa, SKBiswas, R. Yuan, P. Narasimhan, and CA Johnson (IEEE Journ. Select. Areas Commun., 1997). Please refer to.
【0055】
A. IPSO FACTO extension to WATM: IPSO FACTO<sup>+ W</sup>According to the present invention, IPSO FACTO VCs on wireless links are classified into Nicast VCs, Multicast VCs, and Broadcast VCs to support different traffic types. The data transmitted by the unicast VC is received by only one mobile. Similarly, the data transmitted by the broadcast VC is received by all mobiles. On the other hand, the data transmitted on the multicast VC is received only by a group of mobiles.
【0056】
Multicast VCs are obtained by mapping IP multicast group addresses to VC numbers. Such mapping is done when the mobile first joins the multicast group. With this mapping of <IP multicast group address, VC>, the base station gives the VC number even when other mobiles join the same IP multicast group. A one-to-one mapping is maintained between VC and IP multicast group addresses.
【0057】
Due to the asymmetry of wireless ATM access links, the IPSO FACTO protocol needs to be modified for proper multicast operation. Since the same VC space is used by all mobiles in a given base station, VCs cannot be prepared in advance for data reception. A control protocol between the base station and the mobile is used, in which the base station determines the VC that the mobile should use.
【0058】
Here, such a control protocol may not be required to support unicast traffic. This is because the VC space is divided and assigned to each moving body without causing conflict. During multicasting, the VC space is not divided. This is because the mobile can dynamically join and / or leave the multicast session.
【0059】
When IPSO FACTO is set up on a WATM terminal, the following VC is given in advance.
【0060】
-One-way broadcast VC from the base station to the mobile.
【0061】
-Bidirectional unicast control VC between the base station and the mobile body. These control VCs are used to send control messages.
【0062】
The control protocol between the base station and the mobile includes VC REQUEST and VC RECLAIM control messages. The VC REQUEST message is used by the mobile to request the base station to give the VC to send the data. The VC RECLAIM message is used by the base station to reclaim the VC given to the mobile. The base station normally uses a timer to determine the VC active state, and sends out a VC RECLAIM when the timer times out, that is, when the VC is not in the active state.
【0063】
If there are multiple sources in the same multicast group, other features will be incorporated. If the same VC is used for the multicast group regardless of the number of sources, a base station that can detect packet (frame) boundaries and merge multiple flows into one VC is required. Become. When such a VC mergeable base station is not available, a different VC is used for each source in the multicast group. In such a case, the base station maintains the mapping of <source IP address, multicast group address, VC #>. This means that each mover currently has multiple VCs open for the same IP multicast group.
【0064】
To improve reliability, the base station periodically broadcasts the mapping. Such broadcasts are typically sent with an IGMP host membership query message. A mobile that is not involved in this message simply discards the message at the IP level. Having a mapping of <source (source), group, VC> is useful when the recipient uses IGMPv3, which can select and receive multicast traffic only from a specific set of sources. A mover involved in a particular set of sources need only open the corresponding receiving VC.
【0065】
B. IGMP extension: IGMP<sup>+ W</sup>According to the present invention, the Internet Group Management Protocol (IGMP) is modified and modified so that it can operate in a wireless ATM environment. IGMP is traditionally used by IP hosts to report host group membership to directly adjacent multicast routers. In a wireless ATM system, the base station itself may be a multicast router, or it may be an alternative that can operate as a hop different from conventional IP routers. (hop = passage of a data packet between two network nodes (for example, between two routers) proxy = Entity that, in the interest of efficiency, essentially stands in for another entity (from internet materials) The case where the base station itself is a multicast router will be described below.
【0066】
The multicast router sends a host membership query message to find out which host group has members on the local network to which it is connected. The query is issued to a group of all hosts (address 224.0.0.1) and IP TTL (Time-To-Live) = 1 [(Field in an IP header that indicates how long a packet is) Considered valid.)] And sent. By creating a host membership report, a host responds to a query and reports on each host group to which it belongs on the network interface that receives the query. Two techniques have been used in traditional IGMP to avoid congestion due to simultaneous reports and to reduce the total number of reports transmitted.
【0067】
1. Randomly select the delay timer value. The response to the query is generated when the timer times out. This helps to distribute the response over time.
【0068】
2. The response report is sent to the host group address with the TTL set to 1. On the same network, other members of the same group can see the report and prevent another report from being created for that group. This makes it possible to reduce the load on IGMP.
【0069】
In order to achieve similar operation on wireless ATM systems, the present invention makes the following changes / extensions to IGMP.
【0070】
1. A downlink IGMP message (query) is transmitted over the broadcast VC (from the base station to the mobile). All multicast-capable mobiles (hosts) receive IGMP and query messages and produce appropriate reports. Non-multicast mobiles can also receive these messages, but these messages are dropped at the IP level.
【0071】
2. Uplink IGMP messages (reports) are transmitted on the same unicast control VC. Upon receiving this report, the base station rebroadcasts the report so that other mobiles can receive reports created by hosts (mobiles) that belong to the multicast group. If another host is a member of the same group, reset its timer to refrain from writing another report.
【0072】
C. Joining or leaving a new mobile multicast group A step of performing a multicast operation when a mobile body newly joins the wireless ATM system according to the preferred embodiment will be described. In FIG. 2, M1, M2, and M3 are the three mobiles currently connected to the base station. The case where the mobiles M1 and M2 join a multicast group, for example, 225.1.1.1, receive multicast data, and finally leave the group will be described.
【0073】
The base station needs to determine when to add and remove mappings from the database so that the mobile can properly join or leave. Adding a new entry is relatively easy. When a mobile joins a multicast group, a new entry is added if the mapping for this group does not already exist in the database. However, once deciding when to delete an entry from the database, the base station must ensure that no mobile station is linked to that particular multicast group address. To obtain such information, the base station can maintain the mapping database in three different ways.
【0074】
1. Map the source IP address, ie <multicast group address, VC number>, a list of mobile IP addresses that join this group.
【0075】
2. Map the source IP address, <multicast group address, VC number>, counter (or flag).
【0076】
3. Map the source (source) IP address, <multicast group address, VC number>.
【0077】
In the first case, a complete database of all mobiles associated with the multicast group will be maintained. Having a perfect mapping gives you a great deal of flexibility and functionality, but it also complicates database maintenance.
【0078】
In the second case, the base station only needs to hold a counter that counts up when the mobile joins the group and counts down when it leaves the group. When all the movers leave the group, the counter goes to zero and the entry can be safely removed from the group. Now you don't even have to keep an eye on how many mobiles are currently linked to the group address. All you have to do is use the flags (state 0 and state 1), which are set to 1 as long as there is at least one move, and set to zero (reset) if no move is present.
【0079】
In the third case, information about the existence of a mobile attached to a particular multicast group address can be implicitly inferred from the multicast routing protocol. When the mobile is not attached to a multicast group, the base station (which is also a multicast router) sends a release message to the upstream router to disconnect multicast traffic for that group. This message is generated by the multicast routing protocol only if there are no hosts (mobiles) attached to that multicast group. This message can be used as a trigger to delete an entry from the database.
【0080】
Assuming an IGMPv2 or higher protocol, the following operation sequence is executed.
【0081】
-When a mobile unit enters an area controlled by a base station (usually called a cell), it starts a connection operation with the base station via a wireless control channel. This is a wireless level communication mechanism.
【0082】
The base station responds by giving the broadcast VC number and the unicast control VC number that the mobile should use, along with other information.
【0083】
-The mobile M1 decides to join the IP multicast group 225.1.1.1, for example, and sends an IGMP join message on the control VC.
[Personal Information manager] When using the dense mode multicast routing protocol, the base station creates a Graft message and sends it to the upstream router.
【0084】
The base station then searches its database to see if a <group, VC number> mapping exists. If it does not exist, the base station selects a VC from the pool of available VCs, maps this VC to the multicast group address, and stores the information in the database. This information (<group address, VC number>) is transmitted to the mobile via the broadcast VC.
【0085】
-Receiving this mapping, the mover opens a given VC for data reception. Here, other mobiles that receive this information simply discard it.
【0086】
-If the mobile M2 decides to join the same group (225.1.1.1), it sends a join message to the base station. When the base station receives this message, it searches the database for <group, VC> mappings. Since such a mapping already exists, the same VC number is given to the mover. The mobile M2 opens this VC to receive data.
【0087】
-The base station periodically sends out a host membership query on the broadcast VC (255). Hosts other than M1 and M2 will drop this message. When M1 and M2 receive this message, they start a report delay timer with a randomly selected timeout value. To reduce the probability that a host will choose the same delay value, RFC (Request For Comment) recommends that the host's own IP address be used as part of the seed for the pseudo-random number generator. See "TCP / IP illustrate, Volume 1: The Protocols" by Gary R. Wright and W. Richard Stevens (Addison-Wesley Publishing Company, Reading, Massachusetts, 1995).
【0088】
-When the timer times out on one mobile, a host membership report is created and sent on the broadcast VC. The base station receives this message and (re) broadcasts it. When another mobile receives this message, it resets its timer and does not produce a report.
【0089】
-The base station transmits multicast data to the group of VCs (225.1.1.1) obtained from the <group, VC> mapping. Since both mobiles M1 and M2 have the same VC open for reception, they both receive multicast data. All other mobiles discard this data.
【0090】
-The IGMP withdrawal operation is performed in the same manner.
【0091】
D. Data link control for multicast flow Preferred embodiments of a data link control (DLC) protocol for transmitting multicast traffic over a wireless (physical) link are described below. Such protocols perform sequential cell delivery that can reduce cell error rates and provide high throughput at the transport layer. It has been shown that the effective throughput of unicast traffic can be improved by using a data link control protocol. "Design and performance of radio access protocol in WATMnet," by P.Narasimhan, SKBiswas, CAJohnston, RJSiracusa, H.Kim, "aprototype wireless ATM network" (Proc.ICUPC, 1997) and "Data link control protocols for wireless ATM access channels" by H.Xie, P.Narasimhan, R.Yuan, D.Raychaudhuri (Proc. ICUPC, 1995) Please refer to.
【0092】
IP multicast traffic is based on UDP (User Datagram Protocol), and packet loss is irrelevant, but if recovery is performed at the cell level, execution throughput will be significantly improved. Such an improvement in throughput is due to the fact that even if one of the ATM cells is lost, the entire UDP datagram is treated as a code error and discarded in packet corruption and CRC (Cyclic Redundancy Check). By recovering lost cells, the entire packet can be repaired and the total transport layer throughput can be improved.
【0093】
The data link control protocol for unicast flow uses a positive group confirmation method for error recovery. The recipient sends a group confirmation packet with a bitmap vector indicating the error state of the received cell. Upon receiving the confirmation packet, the source analyzes the bitmap vector and selectively resends the lost cell. However, using such a mechanism for multicast traffic imposes a burden on the source for confirmed traffic. To avoid this situation, a negative response (NACK) method is used, in which case NACK is sent from the recipient along with the bitmap vector only when the cell is lost or damaged. It is sent (Fig. 4). Upon receiving the negative response packet, the source executes a selective retransmission algorithm to recover the erroneous cell. Here, DLC execution is performed in the mode for each VC, and it is required that both the base and the terminal hold individual DLC status information for each VC. In addition, base stations can distinguish between unicast VCs and multicast VCs, so they are aware of the correct mechanism (ACK or NACK-based) to use for error recovery.
【0094】
When a large number of mobiles belong to the same multicast group and operate under various error-prone conditions (fading, etc.), the base station may be burdened with repeated retransmission requests. In this case, since the load for responding to the retransmission request is added, the base station may not be able to transmit new multicast data. According to the present invention, a timer is used to prevent deadlock from occurring. The transmitted cells are buffered until the timer times out, after which the buffer is cleared (Figure 6). The recipient requests the resend of the cell to be received unless the source timer times out. All retransmission requests are discarded when the source timer times out. The recipient maintains its own timer. This timer is started when it detects a cell loss. The timeout value of this timer is almost the same as the timeout value of the source timer. The recipient requests cell retransmissions unless the recipient timer times out, after which the recipient no longer requests retransmissions for cells in that group, assuming data has been lost. This is necessary. As a result, the source does not respond to any retransmission request when the timer times out, but it is possible to prevent the recipient from continuously and wastefully sending the request for retransmission of the lost cell.
【0095】
The source has an additional timer with a timeout value equal to about half the timeout value of the retransmission timer. This timer is used to send an incidental acknowledgment when it times out. This is useful when there are no more cells left to send, or when there are long gaps in the data stream. When using a NACK-based mechanism for error recovery, a method is needed to notify the recipient that the cell has been transmitted. Normally, the source resets the accompanying acknowledgment timer when there is more data to send. This is because the recipient indicates that the cell of the previous group has been lost by receiving the subsequent cell. The recipient creates an appropriate NACK packet with the correct bitmap vector to recover the lost cell. Nevertheless, cell loss may not be detected by the recipient when the source sends cells in the last group (or the group before the long gap). This is because it is completely unknown that the cell has been sent. In such a case, the source sends an incidental confirmation message indicating that the cells of the group have been transmitted. When the recipient receives an accompanying confirmation message containing the sequence number of the transmitted cell, it can determine if a cell loss has occurred and return a NACK display. Here, the reason for having a smaller timeout value is to give the recipient a chance to create a NACK and recover the lost cell before the retransmission timer times out.
【0096】
The present invention provides a mechanism for providing IP multicast for wireless ATM systems. To distinguish between different traffic types, VCs are categorized as unicast VCs, multicast VCs and broadcast VCs. The control protocol between the base station and the mobile is used to give the mobile an appropriate multicast VC number to use when joining a particular IP multicast group. In particular, small changes / extensions to the IGMP protocol used in wireless ATM systems can be obtained. Finally, a data link control protocol with a negative response was described to improve the effective throughput at the transport layer.
【0097】
Other modifications and variations of the present invention will be apparent to those skilled in the art from the above description. That is, although the present invention has been described only for a few examples, it goes without saying that many changes can be made without departing from the gist and scope of the present invention.
[Simple explanation of drawings]
[Figure 1]
It is a figure which shows the example of the conventional IPSO FACTO operation.
[Figure 2]
It is a figure which shows the conventional structure of a wireless ATM system.
[Fig. 3]
It is a figure which shows the TDMA / TDD frame format used for a wireless ATM.
[Fig. 4]
It is a logical diagram of the data link control protocol for multicast traffic.
[Fig. 5]
It is a figure which shows the selective retransmission mechanism.
[Fig. 6]
It is a figure which shows the timing information about the NACK-based mechanism.
[Explanation of symbols]
A few interfaces 51,82 VC
7 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7
Every citation, both ways
| Document | Relation | Office | Cited during |
|---|---|---|---|
| CN1309226C | Cited by | China | Search report |
| US7161958B2 | Cited by | United States of America | Applicant |
| CN100440967C | Cited by | China | Search report |
| US7929475B2 | Cited by | United States of America | Applicant |
| US7221660B1 | Cited by | United States of America | Applicant |
| JP2013247587A | Cited by | Japan | Examiner |
| CN108370322A | Cited by | China | Search report |
| US7254409B2 | Cited by | United States of America | Applicant |
| JP2013247587A | Cited by | Japan | Search report |
| US7254132B2 | Cited by | United States of America | Applicant |
| US9252924B2 | Cited by | United States of America | Applicant |
| CN100421520C | Cited by | China | Search report |
| KR100512755B1 | Cited by | Republic of Korea | Examiner |
| JP5460743B2 | Cited by | Japan | Search report |
| JPWO2011096009A1 | Cited by | Japan | Search report |
| WO0180590A1 | Cited by | World Intellectual Property Organization (WIPO) | International search |
5 members in 4 offices
Priority claims10
| Document | Office | Kind | Date |
|---|---|---|---|
| 60081628 | United States of America | – | |
| 8162898 | United States of America | P | |
| 8162898 | United States of America | P | |
| 09154507 | United States of America | – | |
| 15450798 | United States of America | A | |
| 15450798 | United States of America | A | |
| 81628 | – | – | – |
| 154507 | – | – | – |
| US19980081628P | – | – | – |
| US19980154507 | – | – | – |
Members5
| Document | Office | Kind | |
|---|---|---|---|
| CA2265293A1 | Canada | A1 | |
| EP0951198A2 | European Patent Office (EPO) | A2 | |
| AU2039399A | Australia | A | |
| JP2000032007AThis record | Japan | A | |
| JP3430966B2 | Japan | B2 |
10 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Cancellation because of no payment of annual feesLAPS | LAPS | |
| Renewal fee payment (event date is renewal date of database)FPAY | FPAY | |
| Renewal fee payment (event date is renewal date of database)FPAY | FPAY | |
| Renewal fee payment (event date is renewal date of database)FPAY | FPAY | |
| Renewal fee payment (event date is renewal date of database)FPAY | FPAY | |
| Renewal fee payment (event date is renewal date of database)FPAY | FPAY | |
| Renewal fee payment (event date is renewal date of database)FPAY | FPAY | |
| Renewal fee payment (event date is renewal date of database)FPAY | FPAY | |
| Renewal fee payment (event date is renewal date of database)FPAY | FPAY | |
| Written decision to grant a patent or to grant a registration (utility model)JAPANESE INTERMEDIATE CODE: A01A01 | A01 |
Numbers
- Publication
- 2000-32007
- Publication, DOCDB
- 2000032007
- Publication, EPODOC
- JP2000032007
- Application
- 11106187
- Application, DOCDB
- 10618799
- Application, EPODOC
- JP19990106187
Titles2
- Japanese
- 無線ATMを使用してIPマルチキャストを処理できるネットワ―クシステム及び方法
- English
- INDUSTRIAL APPLICABILITY A network system and method capable of processing IP multicast using a wireless ATM.
Classification
- CPC, 6
- H04L1/1883
- H04L2001/0093
- H04L2012/562
- H04L2012/5642
- H04L2012/5667
- H04Q11/0478
- IPC, 3
- H04B7 26
- H04L12 70
- H04Q11 04