以下に添付図面を参照して、この発明にかかる因果順序保存放送型通信方法およびシステムの好適な実施の形態を詳細に説明する。
実施の形態1.
図1は、この発明にかかる因果順序保存放送型通信システムの構成を模式的に示す図である。因果順序保存放送型通信システムは、所定のエリアにおいて通信端末4との間で所定の無線通信方式で無線通信を行うとともに、通信端末4が行う放送型通信の処理の一部を行う移動支援局2が相互に接続された固定ネットワーク3と、この固定ネットワーク3を介して通信を行う通信端末(以下、端末という)4と、を備えて構成される。
この発明において、固定ネットワーク3が複数のサブネットワークSNに分割され、サブネットワークSNが階層構造を有していることを特徴とする。具体的には、固定ネットワーク3を、属する移動支援局2の数が所定値以下となる1つ以上のサブネットワークSNに分割し、サブネットワークSNが複数存在する場合には、サブネットワークSNをツリー状に接続するように構成する。このとき、1つのサブネットワークSNに属する移動支援局2aか2つのサブネットワークSNに属する移動支援局2bのいずれかの種類の移動支援局2のみしか、固定ネットワーク3内に存在してはいけないものとする。なお、この明細書では、1つのサブネットワークSNに属する移動支援局2aと2つのサブネットワークSNに属する移動支援局2bとを特に分けて説明する必要がある場合には、前者を第1移動支援局と呼び、後者を第2移動支援局と呼ぶことにする。また、サブネットワークSN中に存在する移動支援局2は、サブネットワークSN中にどの様な移動支援局2が存在するかを認識しているものとする。
図2は、端末の概略構成を模式的に示すブロック図である。端末4は、放送通信用演算処理部41と、記憶部42と、移動支援局間通信処理部43と、アプリケーションプロセス処理部44と、を備えて構成される。
放送通信用演算処理部41は、図1に示されるサブネットワークSNがツリー状に接続されて構成される因果順序保存放送型通信システムにおける因果順序保存放送型通信方法で行われる処理のうち、端末4で実行する部分を処理する機能を有する。
記憶部42は、端末4が実行する因果順序保存放送型通信で使用される情報を格納する。この発明では、受信した放送メッセージに関する情報であるSENDER_LISTが格納される。SENDER_LISTは、送信者の識別子、その送信者から受信済みの放送メッセージに付されていたシーケンス番号の最大値の組を要素とする集合から成る情報である。このSENDER_LISTの初期値は空である。
移動支援局間通信処理部43は、たとえば既存のHLDC(High-level Data Link Control procedure)やPIAFS(Personal Handyphone System Internet Access Forum Standard)の様なARQ(Automatic Repeat Request)技術を利用して、移動支援局2との間での放送メッセージの転送を、欠落、重複無く、送信側が送信した順序で受信側が受信することを保証する機能を有する。
アプリケーションプロセス処理部44は、端末4上で放送メッセージの送受信機能を用いてアプリケーション処理を実行する機能を有する。
図3は、移動支援局の概略構成を模式的に示すブロック図である。移動支援局2は、端末4との間の通信の処理を行う端末間通信処理部21と、因果順序保存関係を保持して放送メッセージの送信処理を行うための演算を行う放送通信用演算処理部22と、因果順序保存関係を保持した通信を実行するための種々の情報を格納する記憶部23と、他の移動支援局2との間の通信処理を行う放送通信処理部24と、を備えて構成される。
端末間通信処理部21は、たとえば既存のHLDCやPIAFSの様なARQ技術を利用して、端末4と移動支援局2との間での放送メッセージの転送を、欠落、重複無く、送信側が送信した順序で受信側が受信することを保証する機能を有する。
放送通信用演算処理部22は、図1に示されるサブネットワークSNがツリー状に接続されて構成される因果順序保存放送型通信システムで、受信した放送メッセージについて因果順序保存放送型通信処理を行う機能を有する。
記憶部23は、移動支援局2が実行する因果順序保存放送型通信で使用される情報を格納する。この記憶部23に格納される情報は、SENDER_LISTのほかに、非特許文献1の従来の因果順序保存放送型通信で用いられるMH,SENT,DELIV,DELIV_MESを含むデータである。以下に、これらのデータについて説明する。SENDER_LISTは、端末4の有するSENDER_LISTと同様であり、送信者の識別子、その送信者から受信済みの放送メッセージに付されていたシーケンス番号の最大値の組を要素とする集合から成る情報である。また、MHは、移動支援局2に接続中の端末4の識別子の集合を示す情報である。このMHは、移動支援局2が接続するサブネットワーク数にかかわらず1つ存在する。
SENTは、各移動支援局2において放送メッセージの前後関係を管理するベクトル情報である。このSENTは、サブネットワークSN内の移動支援局2の要素数の次元を有する。第2移動支援局2bでは、この第2移動支援局2bに接続する2つのサブネットワークSNをそれぞれサブネットワークA,Bとすると、サブネットワークA,Bのいずれに対するデータかを示すためにSENTa,SENTbと記述する。この場合のベクトル情報の次数は、それぞれサブネットワークA上の移動支援局数、サブネットワークB上の移動支援局数となる。このSENTデータの初期値は0である。このSENTは、特許請求の範囲における送信情報に対応する。
DELIVは、サブネットワークSN内の移動支援局2の各要素となる移動支援局2からの放送メッセージのうち、自局で配達済みの放送メッセージ数を記録するベクトル情報である。このDELIVは、サブネットワークSN内の移動支援局2の要素数の次元を有する。第2移動支援局2bでは、サブネットワークA,Bのいずれに対するデータかを示すために、DELIVa,DELIVbと記述する。この場合のベクトル情報の次数は、それぞれネットワークA上の移動支援局数、ネットワークB上の移動支援局数となる。このDELIVデータの初期値は0である。このDELIVは、特許請求の範囲における配達済み情報に対応する。
DELIV_MESは、移動支援局2で配達済みの放送メッセージを配達順に保存するキューである。初期値は空である。このDELIV_MESは、移動支援局2が接続するサブネットワーク数にかかわらず1つ存在する。このDELIV_MESは、放送メッセージ格納情報に対応する。
放送通信処理部24は、移動支援局間での放送メッセージの転送を、欠落や重複なく、送信側が送信した順序で受信側が受信することを保証する機能を有する。このような機能を実現するためには、たとえばIETF(Internet Engineering Task Force)で議論されているReliable Multicast Transport Protocolを用いることができる。なお、因果順序保存放送型通信は、1つの移動支援局2が送信した放送メッセージ間の順序関係だけでなく、複数の異なる移動支援局2が送信した放送メッセージ間の順序関係についてもある範囲内で保証するものであり、この放送通信処理部24の機能だけでは因果順序保存放送型通信は実現できず、その他の処理部と合わせて実現することが可能となるものである。
つぎに、このような構成のシステムにおける端末4と移動支援局2による処理を説明する。端末4は、非特許文献1に記載の従来の通信方法と同様に放送メッセージを因果順序保存放送型通信プロトコルで送信するcbcast(放送メッセージ)処理と、送信元から放送メッセージを受信するreceive(移動支援局,放送メッセージ)処理を行う。図4は、端末による放送メッセージの送信処理(cbcast処理)の手順を示すフローチャートである。端末4が放送メッセージを送信する場合、送信すべき放送メッセージを現在端末4が接続している移動支援局2に送信し(ステップS41)、放送メッセージの送信処理が終了する。なお、送信される放送メッセージには、自らが送信する放送メッセージに、連番で増加するシーケンス番号と自らを識別する識別子が付与される。
図5は、端末が放送メッセージの受信処理(receive処理)の手順を示すフローチャートである。端末4が移動支援局2から放送メッセージを受信すると(ステップS51)、放送メッセージの送信者とシーケンス番号からSENDER_LISTのデータを用いて、その放送メッセージを既に受信済みか否かを判断する(ステップS52〜S53)。つまり、送信者とシーケンス番号から重複送信か否かを判断する。判断の結果、受信済みの場合(ステップS53でYesの場合)には、重複受信であるので受信した放送メッセージを廃棄して(ステップS54)、処理を終了する。一方、受信済みでない場合(ステップS53でNoの場合)には、放送メッセージの受信処理を行う(ステップS55)。また、受信した放送メッセージの送信者とシーケンス番号の組をSENDER_LISTに追加し(ステップS56)、受信処理が終了する。なお、端末4または移動支援局2が送信する放送メッセージには、放送メッセージの送信元である端末4または移動支援局2を示す識別子と、送信元が付与するシーケンス番号が含まれている。
一方、この実施の形態1による1つのサブネットワークSN内における各移動支援局2は、従来技術の非特許文献1に示される因果順序保存放送型プロトコルに基づいた処理を行うが、その範囲はその移動支援局2が属するサブネットワークSN内に限定される。そのため、移動支援局2が各放送メッセージに付加するベクトルの次元はサブネットワークSN内の移動支援局2の数となる。
また、固定ネットワーク3全体でも因果順序を保存した放送を可能とするために、第2移動支援局2bに、通常の第1移動支援局2aとは異なる処理を実行させる必要がある。2つのサブネットワークA,Bに接続する第2移動支援局2bは、サブネットワークA上で送受信する放送メッセージについては、サブネットワークBを自局に接続される端末とみなし、サブネットワークB上で送受信する放送メッセージについては、サブネットワークAを自局に接続される端末とみなし、自局に接続する端末4が送受信する放送メッセージについてはサブネットワークA,Bの両方を個別の送信対象として、配達処理を行う。
つまり、第2移動支援局2bは、サブネットワークA上から放送メッセージを受信した場合には、SENTとDELIVが所定の条件を満たしてその放送メッセージが配達可能となると、自局に接続する端末4に放送メッセージを送信すると同時に、ネットワークBに対しても放送メッセージを送信する。そして、DELIV_MESに(サブネットワークAで受信した時に付与されていたSENT,全要素0のベクトル,放送メッセージ)の組を追加する。また、サブネットワークB上から放送メッセージを受信した場合には、SENTとDELIVが所定の条件を満たしてその放送メッセージが配達可能となると、自局に接続する端末4に放送メッセージを送信すると同時に、ネットワークAに対しても放送メッセージを送信する。そして、DELIV_MESに(全要素0のベクトル,サブネットワークBで受信した時に付与されていたSENT,放送メッセージ)の組を追加する。さらに、自局に接続する端末4からの放送メッセージまたは自局が送信する放送メッセージの場合には、サブネットワークA,Bの両方を個別に送信対象として、両方のサブネットワークA,Bで配達可能となってはじめて自局に接続する端末4に配達可能とする。そして、DELIV_MESに(サブネットワークAで送信した時に付与したSENT,サブネットワークBで送信した時に付与したSENT,放送メッセージ)の組を追加する。
このような方法で、第2移動支援局2bに配達処理を実行させることによって、サブネットワークSN内だけでなくサブネットワークSNの集合からなる固定ネットワーク3全体でも因果順序保存放送型通信を端末が行うことを可能とする。
この実施の形態1によれば、固定ネットワーク3を所定の数以下の移動支援局2からなるサブネットワークSNに分割し、分割して生成された複数のサブネットワークSNを移動支援局2が接続するサブネットワークSNの数が最大で2つとなるようにツリー状に接続するとともに、2つのサブネットワークSNと接続する第2移動支援局2bは、一方のサブネットワークSN上からの放送メッセージを受信した場合には他方のサブネットワークSNを端末とみなし、自局からの放送メッセージの場合には2つのサブネットワークSNを送信対象とみなして、因果順序を保存した配達処理を実行するようにしたので、ツリー状の固定ネットワーク3全体でも因果順序保存放送型通信を保証することができるという効果を有する。また、複数のサブネットワークSNをツリー状に接続して、従来の因果順序保存放送型通信をサブネットワークSN内と限定したので、放送メッセージを送信する際に放送メッセージに付される移動支援局2の数に比例するヘッダ情報の量を抑えることができるという効果を有する。
実施の形態2.
実施の形態1では、端末のハンドオフについては考慮されていない因果順序保存放送型通信方法について説明した。そこで、この実施の形態2では、端末のハンドオフにも対応した因果順序保存放送型通信システムについて具体的に説明する。この実施の形態2でも図1に示されるネットワークの構成を用いて説明する。ただし、端末4は、移動しながら無線通信することが可能な通信端末である。
また、移動支援局2の記憶部23には、非特許文献1の従来の因果順序保存放送型通信で用いられるDELIV,SENT,RECV,RECV_RDC,REDUCE,WAITING,DELIV_MES,MOVINGの各データの他に、この発明で端末4のハンドオフを可能とするためのRECV_A,RECV_B,RECLIST_A,RECLIST_Bの各データが格納される。以下に、これらのデータのうち、実施の形態1に出てこなかったデータについて説明する。
RECVは、各移動支援局2に接続しているそれぞれの端末4で配達済みの放送メッセージの数を管理するベクトル情報であり、通常の移動支援局(1つのサブネットワークSNのみに接続する移動支援局)2aのみが保持する。このRECVは、属しているサブネットワークSNに存在する移動支援局2の要素数の次元を有する。
RECV_A,RECV_Bは、上記RECVと類似のデータであり、第2移動支援局2bでのみ使用されるデータである。RECV_Aは、サブネットワークA上で因果順序保存放送型通信を行うために使用するデータとして、サブネットワークB以遠のサブネットワーク群に存在する移動支援局2と、それらの移動支援局2に接続する端末4に配達済みの、サブネットワークA上で受信した放送メッセージに関する情報を記録するベクトル情報である。このRECV_Aは、サブネットワークA上の移動支援局数の次数を有する。同様に、RECV_Bは、サブネットワークB上で因果順序保存放送型通信を行うために使用するデータとして、サブネットワークA以遠のサブネットワーク群に存在する移動支援局2と、それらの移動支援局2に接続する端末4に配達済みの、サブネットワークB上で受信した放送メッセージに関する情報を記録するベクトル情報である。このRECV_Bは、サブネットワークB上の移動支援局数の次数を有する。このRECV−AとRECV−Bは、サブネットワークSNによる階層化の影響のため、配達されていることが保証される放送メッセージの情報となり、実際にはより多くの放送メッセージが配達済みの可能性はあるが、定常状態では、RECV−AとRECV−Bは、実際に配達済みの放送メッセージの情報と一致する。また、RECV−AとRECV−Bの使用目的が、全端末4と移動支援局2とに配達済みであるので廃棄可能な放送メッセージを判断するための入力であることから、一時的に配達済みの放送メッセージが未配達として扱われることに不都合はない。
REDUCEは、移動支援局2に接続しているすべての端末4で配達済みの放送メッセージの数を管理するベクトル情報である。このREDUCEは、属しているサブネットワークSNに存在する移動支援局2の要素数の次元を有する。第2移動支援局2bでは、サブネットワークA,Bのいずれに対するデータかを示すために、REDUCEa,REDUCEbと記述する。この場合のベクトル情報の次数は、それぞれネットワークA上の移動支援局数、ネットワークB上の移動支援局数となる。このREDUCEは、特許請求の範囲における削除可能メッセージ情報に対応する。
RECV_RDCは、各移動支援局2が受信したREDUCEを管理するための配列情報であり、他の移動支援局2から受信した放送メッセージのうちDELIV_MESから削除可能な放送メッセージの情報を表している。
WAITINGは、移動支援局2で受信したが、因果順序を保持するために配達を延期して、バッファに保持されている放送メッセージを示す情報である。第2移動支援局2bでは、2つのサブネットワークA,Bのそれぞれから受信するデータと、自局に接続する端末4または自局から受信するデータとを分けて管理する。サブネットワークA,B、自局(自局に接続する端末)のいずれに対するデータかを示すために、この明細書ではそれぞれWAITINGa,WAITINGb,WAITINGsと記述する。
MOVINGは、自局からハンドオフしていったがハンドオフ先の移動支援局2との接続を確認していない端末4の識別子と、その端末4に対するRECV(第2移動支援局2bの場合には、RECV_AとRECV_Bの2つ)の組を要素とする集合から成る情報である。初期値は空であり、移動支援局2が接続するサブネットワークSNの数にかかわらず1つ存在する。
RECLIST−A,RECLIST−Bは、第2移動支援局2bでのみ使用される情報である。RECLIST−Aは、サブネットワークAへの放送メッセージを送信する際に、その放送メッセージに付与するSENTaと、その時点でのサブネットワークB側でのDELIVbの組を記録するリストである。また、RECLIST−Bは、サブネットワークBへの放送メッセージを送信する際に、その放送メッセージに付与するSENTbと、その時点でのサブネットワークA側でのDELIVaの組を記録するリストである。これらのRECLIST−A,RECLIST−Bは、RECV−A,RECV−Bを更新するために使用される。
ここで、端末4のハンドオフに対応した因果順序保存放送型通信システムにおいて、端末4と移動支援局2が行う処理について説明する。端末4の行う処理として、実施の形態1で説明した処理のほかに、現在接続中の移動支援局との接続を切り、ハンドオフを開始するdisconnet(移動支援局)処理と、ハンドオフ後に移動支援局と接続し、ハンドオフを完了するconnect(移動支援局)処理がある。
図6は、端末がハンドオフする際の処理(disconnect処理とconnect処理)の手順を示すフローチャートである。たとえば、図1において端末4が移動して現在接続している移動支援局2a−1から他の移動支援局2b−1にハンドオフする場合、端末4は現在接続している移動支援局2a−1との通信を切断し(ステップS61)、移動後の新しい移動支援局2b−1と接続したか否かを確認する(ステップS62)。新しい移動支援局2b−1と接続できるまで、待ち状態となる(ステップS62でNoの場合)。その後、新たに移動支援局2b−1と接続すると(ステップS62でYesの場合)、新たに接続した移動支援局2b−1に自端末の識別子情報を通知する(ステップS63)。移動支援局2b−1からの通信許可があるまで待ち状態となる(ステップS64でNoの場合)。このとき、端末4から新たな移動支援局2b−1への放送メッセージの送信は止められた状態にある。そして、新たな移動支援局2b−1からの通信許可があると(ステップS64でYesの場合)、端末4のハンドオフ時の処理が終了し、以降新たな移動支援局2b−1への放送メッセージの送信が可能となる。
一方の移動支援局2の処理として、放送メッセージを因果順序保存放送型通信プロトコルで送信するcbcast(放送メッセージ)処理、送信元から放送メッセージを受信するreceive(送信元[端末か移動支援局],放送メッセージ)処理、自局に接続している端末がハンドオフを開始し、自局との間の接続を切断したことに対して行うremove(端末)処理、新たな端末がハンドオフを完了し、自局に接続してきたことに対して行うaccept(端末)処理などがある。
図7は、2つのサブネットワークに接続する第2移動支援局自身が送信元となって放送メッセージを因果順序保存放送型通信プロトコルで送信する際に実行する放送要求の処理(cbcast処理)の手順の一例を示すフローチャートである。最初に、第2移動支援局2bは、サブネットワークAに放送メッセージを送信する際に、サブネットワークAに属する移動支援局数を次数とするベクトル情報SENTaと、RECV−A,DELIVa,MOVINGに含まれるRECV−Aの最小値であるREDUCEaと、を放送メッセージに付与し、サブネットワークAに放送メッセージを送信する(ステップS71)。
同様に、第2移動支援局2bは、サブネットワークBへ放送メッセージを送信する際に、サブネットワークBに属する移動支援局数を次数とするベクトル情報SENTbと、RECV−B,DELIVb,MOVINGに含まれるRECV−Bの最小値であるREDUCEbと、を放送メッセージに付与し、サブネットワークBに放送メッセージを送信する(ステップS72)。
なお、上記のステップS71,S72で、第2移動支援局2bが送信する放送メッセージに付与するベクトルREDUCEの計算を行うための入力として、サブネットワークA上での送信時にはRECV−Aを、サブネットワークB上での送信時にはRECV_Bを追加して、REDUCEを求めることで、他方のサブネットワークで未配達の放送メッセージを廃棄することを防いでいる。
ついで、自局である第2移動支援局2bが放送した放送メッセージを自局に配達可能か否かの配達可能性をチェックする(ステップS73)。そして、第2移動支援局2bは、サブネットワークAへ放送メッセージを送信する際に、その放送メッセージに付与するSENTaと、その時点でのサブネットワークB側でのサブネットワークBに属する移動支援局数を次数とするベクトル情報DELIVbの組(SENTa,DELIVb)をRECLIST−Aに追加する。第2移動支援局2bがサブネットワークBへ放送メッセージを送信する際にも同様に、その放送メッセージに付与するSENTbと、その時点でのサブネットワークA側でのサブネットワークAに属する移動支援局数を次数とするベクトル情報DELIVaの組(SENTb,DELIVa)をRECLIST−Bに追加する(ステップS74)。以上で、第2移動支援局2bによる放送メッセージの送信処理が終了する。
図8は、図7のステップS73における配達可能性チェック処理と配達処理の手順を示すフローチャートである。この処理は、ireceive(SENTa,SENTb,放送メッセージ)のイベントの発生によって実行される。まず、第2移動支援局2bは自局に放送メッセージを配達可能か否かを判定する(ステップS81)。配達可能か否かは、SENTとDELIVを用いて非特許文献1に記載のアルゴリズムにしたがって求められる。ここでは、ある移動支援局のSENTが、その移動支援局のDELIVa+1となり、かつその移動支援局以外のSENTがその移動支援局以外のDELIVa以下となる場合に配達可能であると判断するものとする。その結果、配達可能でないとき(ステップS81でNoの場合)には、送信しようとする放送メッセージをWAITINGaに追加し(ステップS82)、図7のステップS74以降の処理に戻る。
また、ステップS81で第2移動支援局2bが自局に放送メッセージを配達可能である場合(ステップS81でYesの場合)には、他の移動支援局2から端末4がハンドオフすることを通知する移動通知メッセージを受けたか否かを判定する(ステップS83)。移動通知メッセージを受けていない場合(ステップS83でNoの場合)には、自局に接続される端末4に放送メッセージを送信し(ステップS84)、図7のステップS74以降の処理に戻る。また、移動通知メッセージを受けた場合(ステップS83でYesの場合)には、ハンドオフしてきた端末4に対して通信許可を与えるaccept処理を行い(ステップS85)、図7のステップS74以降の処理に戻る。
図9は、図8のステップS85におけるaccept処理の手順を示すフローチャートである。まず、第2移動支援局2bは、他の移動支援局2から移動通知メッセージを受信すると、自局にその移動通知メッセージに対応する端末が存在することを確認して、移動してきた端末に関する移動確認メッセージを送信する(ステップS91)。ついで、移動通知メッセージに格納されている端末4の情報を、自局に接続されている端末4の集合を示す情報であるMHに追加する(ステップS92)。そして、ハンドオフしてきた端末4に通信許可を与え、後述する移動通知メッセージに含まれるRECVから特定されるDELIV_MES中の未配達の放送メッセージを端末に送信し(ステップS93)、accept処理が終了する。
なお、上述した図7〜図9の説明では、2つのサブネットワークに接続する第2移動支援局2bによる放送メッセージの送信処理を説明したが、第2移動支援局2bが自局に接続する端末4からメッセージを受信した場合も、同様の処理が行われる。
つぎに、1つのサブネットワークに接続する第1移動支援局2aの放送メッセージの送信処理について説明する。図10は、1つのサブネットワークに接続する第1移動支援局自身が送信元となって放送メッセージを因果順序保存放送型通信プロトコルで送信する際に実行する放送要求の処理(cbcast処理)の手順の一例を示すフローチャートである。最初に、第1移動支援局2aは、自局の属するサブネットワークに放送メッセージを送信する際に、サブネットワークに属する移動支援局数を次数とするベクトル情報SENTと、RECV,DELIV,MOVINGに含まれるRECVの最小値であるREDUCEと、を放送メッセージに付与する(ステップS101)。そして、サブネットワークにその放送メッセージを送信して(ステップS102)、処理が終了する。なお、上述した図10の説明では、1つのサブネットワークに接続する第1移動支援局2aによる放送メッセージの送信処理を説明したが、第1移動支援局2aが自局に接続する端末4からメッセージを受信した場合も、同様の処理が行われる。
つぎに、2つのサブネットワークSNの接続点に位置する第2移動支援局2bによる受信した放送メッセージの処理(receive処理)について説明する。図11は、第2移動支援局によるサブネットワークAからの放送メッセージの受信処理の手順の一例を示すフローチャートである。第2移動支援局2bは、サブネットワークAから放送メッセージを受信すると(ステップS111)、放送メッセージに示されるベクトルREDUCE(サブネットワークAの移動支援局数の次数を有する)を用いて、非特許文献1と同じ方法でサブネットワークA用のRECV_RDCaの更新を行う(ステップS112)。具体的には、REDUCDとRECV_RDCaのうち最大となるものをサブネットワークA用のRECV_RDCaとする。ついで、RECV_RDCに含まれるベクトルの各要素の最小値を要素とするベクトルMIN_RA(サブネットワークAの移動支援局数の次数を有する)を求める(ステップS113)。その後、RECLIST−Aに含まれる(SENTa,DELIVb)の組の中で、MIN_RA以下となる最大のSENTaを含む(SENTa,DELIVb)の組を求め、見つかった場合にはそのDELIVbの値(サブネットワークBの移動支援局数の次数を有する)でRECV−Bの値を更新する(ステップS114)。
ついで、第2移動支援局2bは、受信した放送メッセージの送信元がサブネットワークAの他の移動支援局2であるか否かを判断する(ステップS115)。放送メッセージの送信元がサブネットワークAの他の移動支援局2である場合(ステップS115でYesの場合)には、放送メッセージの配達処理を実施し(ステップS116)、さらに記憶部23のWAITINIGa,WAITINGb,WAITINGsに保持されている放送メッセージが配達可能ならばそれらの放送メッセージを配達する(ステップS117)。
ついで、第2移動支援局2bは、サブネットワークB用のRECV_RDCに含まれるベクトルの各要素の最小値を要素とするサブネットワークBの移動支援局数の次数を有するベクトルMIN_RBを求める(ステップS118)。そして、DELIV_MESに含まれる(移動支援局,SENTa,SENTb,放送メッセージ)の組の中で、SENTaがMIN_RA以下で、かつSENTbがMIN_RB以下を満たすものを、DELIV_MESから削除する処理を行って(ステップS119)、受信した放送メッセージの処理が終了する。
図12は、図11のステップS116における放送メッセージの配達処理の詳細な手順を示すフローチャートである。この放送メッセージの配達処理は、deliver_check(移動支援局,SENT,放送メッセージ)のイベントの発生によって行われる。まず、第2移動支援局2bは、受信した放送メッセージが配達可能か否かの判定を行う(ステップS131)。この配達可能か否かの判定は、図8のステップS81の場合と同様に、ある移動支援局のSENTが、その移動支援局のDELIVa+1となり、かつその移動支援局以外のSENTがその移動支援局以外のDELIVa以下となる場合に配達可能であると判断するものとする。その結果、配達可能でない場合(ステップS131でNoの場合)には、サブネットワークAから受信した放送メッセージであるので、第2移動支援局2bは、その放送メッセージをWAITINGaに追加して(ステップS132)、図11に戻ってステップS117以降の処理を行う。一方、受信した放送メッセージが配達可能である場合(ステップS131でYesの場合)には、さらに自局が送信した放送メッセージか否かを判定する(ステップS133)。自局が送信した放送メッセージである場合(ステップS133でYesの場合)には、図11に戻ってステップS117以降の処理を行う。しかし、自局が送信した放送メッセージでない場合(ステップS133でNoの場合)には、他の移動支援局2から移動通知メッセージを受信したか否かを判定する(ステップS134)。
他の移動支援局2から移動通知メッセージを受信した場合(ステップS134でYesの場合)には、第2移動支援局2bは、ハンドオフしてきた端末4に通信許可を与え、DELIV_MESに保持されているメッセージを配達された順に端末4に送信する(ステップS135)。また、移動通知メッセージに対する移動確認メッセージを放送メッセージとして送信する(ステップS136)。一方、他の移動支援局2から移動通知メッセージを受信しなかった場合(ステップS134でNoの場合)には、受信した放送メッセージを自局に接続される端末4へと送信する(ステップS137)。ステップS136またはステップS137の後に、第2移動支援局2bは、SENTbと、RECV−B,DELIVb,MOVINGに含まれるRECV−Bの中の最小値であるREDUCEbと、を放送メッセージに付与し、サブネットワークBに送信する(ステップS138)。そして、RECLIST−Bに、(SENTb,DELIVa)の組を追加して(ステップS139)、図11に戻ってステップS117以降の処理が行われる。
なお、第2移動支援局2bがサブネットワークBから放送メッセージを受信した場合には、図11〜図12の処理において、サブネットワークBとサブネットワークAとこれらに関する変数を入れ替える処理を行えばよい。また、放送メッセージを受信した移動支援局2は、放送メッセージに示される(格納される)送信元とは別に、該送信メッセージを送信した移動支援局がどの移動支援局かという情報も受け取っている。
つぎに、1つのサブネットワークに接続する第1移動支援局2aの放送メッセージの受信処理について説明する。図13は、第1移動支援局の放送メッセージ受信処理(receive処理)の手順を示すフローチャートである。まず、第1移動支援局は、受信した放送メッセージが配達可能か否かの判定を行う(ステップS151)。この配達可能か否かの判定は、図8のステップS81の場合と同様に、ある移動支援局のSENTが、その移動支援局のDELIVa+1となり、かつその移動支援局以外のSENTがその移動支援局以外のDELIVa以下となる場合に配達可能であると判断するものとする。その結果、配達可能でない場合(ステップS151でNoの場合)には、受信した放送メッセージをWAITINGに追加する(ステップS152)。一方、受信した放送メッセージが配達可能である場合(ステップS151でYesの場合)には、さらに他の移動支援局2から移動通知メッセージを受信したか否かを判定する(ステップS153)。
他の移動支援局2から移動通知メッセージを受信した場合(ステップS153でYesの場合)には、第1移動支援局2aは、ハンドオフしてきた端末4に通信許可を与え、DELIV_MESに保持されているメッセージを配達された順に端末4に送信する(ステップS154)。また、移動通知メッセージに対する移動確認メッセージを放送メッセージとして送信する(ステップS155)。一方、他の移動支援局2から移動通知メッセージを受信しなかった場合(ステップS153でNoの場合)には、受信した放送メッセージを自局に接続される全ての端末4へと送信する(ステップS156)。ステップS152、S154またはステップS156の後に、第1移動支援局2aは、WAITINGに含まれる放送メッセージに対して、上述したステップS151〜S156の処理を行い、配達可能な放送メッセージを配達する(ステップS157)。その後、RECV_RDCに含まれるベクトルの各要素の最小値を要素とするMIN_Rを算出し(ステップS158)、DELIV_MESに含まれる(移動支援局,SENT,m)でSENTがMIN_R以下となるものを削除して(ステップS159)、第1移動支援局2aによる放送メッセージの受信処理が終了する。
つぎに、移動支援局2に接続する端末がハンドオフで自局から離れていく場合に行われる移動支援局の処理(remove処理)について、図14のフローチャートを参照しながら説明する。移動支援局2は、接続する端末4がハンドオフで自局から離れてゆくことを検出すると、移動していく端末4の情報をMHから除き(ステップS171)、その端末についての配達済みの放送メッセージ数であるRECV(RECV−A,RECV−B)をMOVINGに追加する(ステップS172)。たとえば、第1移動支援局2aでは(端末,RECV)の組をMOVINGに追加し、第2移動支援局2bでは(端末,RECV−A,RECV−B)の組をMOVINGに追加する。
ついで、移動支援局2は、移動する端末4を示す識別子と自局を示す識別子を含む移動通知メッセージを因果順序保存放送型通信の放送メッセージとして送信する(ステップS173)。移動支援局2は、因果順序保存放送型の放送メッセージとして送信される移動通知メッセージを、図7〜図9に示される通常の因果順序保存放送型通信の放送メッセージと同様の手順で送信する。ただし、移動通知メッセージを送信する場合には、端末4には配達せず、移動支援局2にのみ配達する点が異なる。
その後、端末4が新しい移動支援局との接続を開始し、新しい移動支援局から移動確認メッセージが自局に配達されると(ステップS174)、移動支援局2は、端末の移動が完了したとして、MOVINGから移動していった端末4の情報を削除する(ステップS175)。以上で、端末4が離れていった移動支援局2での端末4のハンドオフに伴う処理が終了する。
つぎに、他の移動支援局2に接続する端末4がハンドオフで自局に接続する場合に行われる移動支援局2の処理について説明する。この発明では、移動支援局2は、新しい端末4がハンドオフの結果自局に新たに接続してきたことを検出してきた際に、その端末4の識別子を含む移動通知メッセージが自局に対して配達されるまでの間は、端末4に対して通信許可を与えず、また、端末4への放送メッセージ配達も、端末4が送信する放送メッセージの転送処理も行わないようにしている。
図15は、ハンドオフの結果新しい端末が自局に接続してきた場合の移動支援局の処理手順を示すフローチャートである。移動支援局2が、新しい端末4がハンドオフの結果自局に新たに接続してきたことを検出してきた際にその端末4の識別子を含む移動通知メッセージを既に受信済みであるか、または端末4が自局に接続後にその端末4の識別子を含む移動通知メッセージを受信すると(ステップS181)、受信した移動通知メッセージに示される端末4の識別子と移動通知メッセージの送信元移動支援局の識別子を含む移動確認メッセージを、因果順序保存放送型の放送メッセージとして送信する(ステップS182)。このとき移動支援局2は、移動確認メッセージを、図7〜図9に示される通常の因果順序保存放送型通信の放送メッセージと同様の手順で送信するが、移動支援局2にのみ配達し、端末4には配達しない。そして、移動してきた端末4に対して通信許可を与え(ステップS183)、自局のDELIV_MESに含まれる全ての放送メッセージを、DELIV_MESに追加された順に端末4に配達し(ステップS184)、ハンドオフ時に移動支援局2が行う処理が終了する。これ以降は、新たに移動支援局2で配達される放送メッセージはこの端末4にも配達され、端末4が送信する放送メッセージの転送処理も行う。
一方、移動支援局2が、移動通知メッセージを受信した時に、現在自局にハンドオフしてきて接続している端末4で、対応する移動通知メッセージを未受信の端末4が存在しない場合には、受信した移動通知メッセージを記憶部23に記録しておき、対応する端末4が自局にハンドオフしてきた場合か、他の移動支援局2による移動通知メッセージに対応する移動確認メッセージが自局に配達された場合に、記録しておいた移動通知メッセージを廃棄する。
ところで、非特許文献1に記載の従来の通信方法では、端末がハンドオフした場合に、移動する端末に配達する放送メッセージの欠落と重複回避と、移動する端末が送信する放送メッセージの因果順序非保存の回避を目的として、端末がハンドオフ前に接続していた移動支援局から、端末がハンドオフ後に接続する移動支援局に対して、1対1通信で(移動した端末の識別子,移動した端末に対するRECVデータ,端末移動時のSENTデータ)の組からなる情報を送信していた。移動した端末に対するRECVデータは、移動する端末に配達する放送メッセージの欠落と重複回避のために用いられるものであり、端末移動時のSENTデータは、移動する端末が送信する放送メッセージの因果順序非保存回避のために用いられるものである。
しかし、この発明では、固定ネットワーク3をツリー状に結合されるサブネットワークSNに分割したことによって、端末が異なるサブネットワークSNに属する移動支援局間をハンドオフする場合が発生する。この場合には、非特許文献1の方法をそのまま適用したのでは、移動した端末に対するRECVデータと端末移動時のSENTデータの厳密な値を、移動元の移動支援局から移動先の移動支援局へ転送することができなくなる。
RECVデータについては、RECVデータの使用目的から、実際には移動した端末へ配達済みの放送メッセージが配達済みではないとして扱われることがあっても、移動した端末へ配達済みであることが保証可能な放送メッセージが何かという情報を転送できれば放送メッセージの欠落を回避することが可能である。これは、RECV−A,RECV−Bの追加と、それによるREDUCE値の補正により、移動先の移動支援局のDELIV_MESに、移動する端末に未配達である可能性がある放送メッセージが保存されることが保証されることにより満たされる。また、重複回避については、放送メッセージに各送信者が連番のシーケンス番号を付与し、端末側で送信者毎に受信済みシーケンス番号を管理することで、端末側で重複受信の検出処理を行うことで実現可能となる。以上により、移動する端末に対する放送メッセージの欠落、重複を回避することが可能になる。
SENTデータについては、SENTデータの使用目的から、移動した端末が送信済みの放送メッセージに対して移動先のサブネットワークSNで付与されるSENTデータ以上の値が移動先の移動支援局に伝えられ、移動先の移動支援局のSENTデータに反映されれば充分である。この条件は、この実施の形態2に示す様に、端末のハンドオフ時に、移動元の移動支援局が移動通知メッセージを因果順序保存放送型通信の放送メッセージとして送信することにより満たすことができる。
この実施の形態2によれば、端末4の移動性を考慮した因果順序保存放送型通信を行う固定ネットワーク3をサブネットワークSNに分割してセブネットワークSN同士をツリー状に接続した構成とすることが可能となり、固定ネットワーク3を構成する移動支援局2の数が増えても、放送メッセージに付与する必要があるベクトルデータの量を所定量以下に抑えることが可能となる。その結果、固定ネットワーク3の規模が拡大してもネットワーク帯域の利用効率が悪化を抑えることができるという効果を有する。
なお、実施の形態1,2のネットワークにおいて、端末4が送信するマルチキャストメッセージを、移動支援局2間では因果順序保存放送メッセージとして転送することによって、端末4による因果順序保存マルチキャスト通信を可能とすることができる。