(57)【特許請求の範囲】
【請求項１】
アロハ・タイプのプロトコルに従った共有リソースへのユーザによるランダム・アクセス方法であって、
特定の時間範囲が前記リソースへのアクセスのために既に予約されており、
ユーザによるデータ・パケットの送信時刻が少なくとも１つのランダム変数によって与えられ、
前記送信時刻での送信が前記予約を侵害することにつながるときには、前記ランダム変数は、平均は同じで分散が大きい他のランダム変数に一時的に変更される
ことを特徴とする共有リソースへのランダム・アクセス方法。
【請求項２】
前記予約の侵害は、
前記データ・パケットの前記送信時刻が、予約されている時間範囲内に入ることである
ことを特徴とする請求項１に記載の共有リソースへのランダム・アクセス方法。
【請求項３】
前記予約の侵害は、
前記データ・パケットに対する受信確認を、予約されている時間範囲内に受信することが予想されることである
ことを特徴とする請求項２に記載の共有リソースへのランダム・アクセス方法。
【請求項４】
前記アロハ・プロトコルは離散的アロハ・プロトコルであり、
前記予約されている時間範囲の時間的長さが、送信間隔である
ことを特徴とする請求項２または３記載の共有リソースへのランダム・アクセス方法。
【請求項５】
前記ランダム変数が少なくとも１つの第１のランダム変数を含むものであって、
前記第１のランダム変数は、第１の送信時刻（ＴTransmit）を与え、
前記第１の送信時刻での送信が前記予約の侵害につながるときには、前記第１のランダム変数は、平均は同じで分散は大きい他のランダム変数に一時的に変更される
ことを特徴とする請求項１ないし４のいずれかに記載の共有リソースへのランダム・アクセス方法。
【請求項６】
前記第１のランダム変数を変更するステップは、
当該第１のランダム変数に、均衡のとれたランダム変数を付加することからなることを特徴とする請求項５に記載の共有リソースへのランダム・アクセス方法。
【請求項７】
変更済みの前記第１のランダム変数によって与えられる前記送信時刻が、前記予約の侵害にあたる場合には、前記均衡のとれたランダム変数を付加するステップは、前記第１のランダム変数によって与えられる前記送信時刻が前記予約を侵害しなくなるまで繰り返されることを特徴とする請求項６に記載の共有リソースへのランダム・アクセス方法。
【請求項８】
前記ランダム変数が第１のランダム変数と第２のランダム変数とを含むものであって、
前記第１のランダム変数によって与えられる前記第１の時刻に送信されたパケットが他のパケットの送信と衝突した場合には、前記第２のランダム変数（ＴRetransmit）によって第２の送信時刻が与えられ、
前記第２の送信時刻での送信が前記予約の侵害につながるときに、前記第２のランダム変数は、平均は同じで分散が大きい他のランダム変数に一時的に変更されることを特徴とする請求項５ないし７のいずれかに記載の共有リソースへのランダム・アクセス方法。
【請求項９】
前記第２のランダム変数を変更する前記ステップは、
当該第２のランダム変数に、均衡のとれたランダム変数を付加することからなることを特徴とする請求項８に記載の共有リソースへのランダム・アクセス方法。
【請求項１０】
変更済みの前記第２のランダム変数によって与えられる前記送信時刻が、前記予約の侵害にあたる場合には、前記均衡のとれたランダム変数を付加するステップは、前記第２のランダム変数によって与えられる前記送信時刻が前記予約を侵害しなくなるまで繰り返されることを特徴とする請求項９に記載の共有リソースへのランダム・アクセス方法。
【請求項１１】
ユーザは、ネットワークまたは他のアクセス・ネットワーク上でパラメータ計測のために確保された予約される時間範囲の少なくとも１つにおいて、計測を実行することを特徴とする、請求項１ないし１０のいずれかに記載の共有リソースへのランダム・アクセス方法。
【請求項１２】
ユーザは移動局であることを特徴とする請求項１ないし１１のいずれかに記載の共有リソースへのランダム・アクセス方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、複数のユーザの間で共有されているリソースへのランダム・アクセスの方法に関する。特に、本発明は、アロハ・タイプ（ＡＬＯＨＡ）の、更に言えば離散的アロハ・タイプ（スロッテド・アロハ（Slotted ALOHA）とも呼ばれる）のアクセス方法に関する。
【０００２】
【従来の技術】
複数のユーザが同じリソース（たとえば、ローカル・エリア・ネットワーク、無線または衛星周波数帯、フレームなど）を共有する場合には、各ユーザの送信要求と最も合致する可能性がある条件の下で、リソースへの各ユーザ・アクセスに関する規則を定めることが必要である。かかる共有を可能にするアクセス方法には２つの大きなグループがある。１つは、各ユーザの要求に応じて、リソースが事前の割り当ての対象である、予約によるアクセス方法であり、もう１つは、各ユーザが、他のユーザとの事前の相談なしに望むままに送信して、コンフリクトは事後に管理されるランダム・アクセス方法である。
【０００３】
図１は、送信チャネル（ＲＡＣＨ）が、ランダム・アクセスの方法に従ってシステムＳにデータ・パケットを送信する複数のユーザＵ1（符号１１）、Ｕ2（符号１２）、．．．ＵN（符号１３）の間で共有されているシステム（符号１５）の例を示している。データ・パケットを受信すると、システムはその完全性をチェックし（たとえば、エラー検出方法で）、完全であれば、制御チャネル（ＣＣ）上で受信確認を返信する。
【０００４】
図２は、ユーザＵiとシステムＳとの間の対話の単純化されたタイミング・チャートを示している。ユーザＵiはパケットを時刻ｔ1に送信する。データの完全性は、そのシステムＳによる受信時にチェックされ、完全であれば、システムによって受信確認が返信される。この受信確認は、図のように、パケットの送信後、所定の時間ＴACKが経過した時点でユーザＵiによって受信される。一方、たとえば、他のユーザによって送信されたパケットと衝突してしまったなどの理由で、（時刻ｔ3に送信された）パケットがシステムＳによって不正であると検出された場合には、上述の所定の時間ＴACKが経過しても受信確認がないことがユーザによって検出されて、当該パケットは、最初にそれを送信した時点から時間ＴRetransmitの経過後に再度送信される。
【０００５】
送信の完全性のチェックを可能にする他の技術も知られており、特に、制御チャネル上での受信確認を必要としないＣＳＭＡ／ＣＤ技術（キャリア検出多重アクセス衝突検出）が知られている。この技術によれば、ユーザは、送信を行う前に共有チャネルを聞き、送信中にも聞き続ける。衝突があれば、パケットの送信は中断されて、後に新たな送信が試みられる。一方、この技術は各ユーザごとに干渉検出回路を必要とする。
【０００６】
共有リソースへのランダム・アクセスのよく知られた方法は、アロハ・プロトコルである。
【０００７】
単なるランダム・アロハと呼ばれる第１のバージョンによれば、各ユーザは、希望どおりにかつ任意の送信時刻に送信を行う。このプロトコルによる送信シーケンスを図３に示す。何れか２人のユーザＵiおよびＵjによって送信されるパケットが重複するときに、衝突（Ｃ）が起こり、衝突したそれらのパケットは、それぞれ遅延ＴRiおよびＴRjの後に再度送信される。衝突およびそれによるブロッキング状況（動作持続性の名称の下に知られている現象）を回避するために、送信の遅延はそれぞれのユーザについて個別に選択される。更に正確に言えば、各ユーザはこの遅延を与える独自のランダム変数を利用可能であり、これらランダム変数は、異なった手段を有するように選択される。
【０００８】
離散的アロハと呼ばれる第２のバージョンにおいては、送信間隔（スロット）が定期的に繰り返され、ユーザは、送信間隔を尊重するということを条件にしながら、希望どおりに送信することができる。共有リソースのユーザは、その送信時刻を同期させなければならない。この制約によって、単なるランダム・アロハ・プロトコルの送信能力の２倍の送信能力を得ることが可能になっている。離散的アロハ・プロトコルによる送信シーケンスを図４に示す。チャネルＲＡＣＨ上での衝突（Ｃ）は、２人のユーザが同じ時間間隔中に送信するときに発生する。衝突が発生すると、衝突したパケットは後に再度送信しなければならない。前述の場合と同様に、送信遅延は離散的な手段でランダム変数によって与えられるが、これは、動作持続性を削減するためである。
【０００９】
ランダム変数は、（ｋ*Ｔrec）においても離散的な値でなければならず、ここでｋは全体であり、Ｔrecは再送信が間隔と一致するような、送信間隔の反復の周期である。
【００１０】
図５は、アロハ・プロトコルに従って共有リソースにアクセスしているユーザの操作のフローチャートを示している。そのアイドル状態（ステップＳ５０）から始まって、ユーザは、データ・パケットが送信されることになっているかどうかを定期的にテストする（ステップＳ５１）。送信されることになっている場合には、第１のランダム変数が送信時刻ＴTransmitを（離散的アロハの場合には（ｋ*Ｔrec）における値で）与える（ステップＳ５２）。ユーザは、共有チャネル上でデータ・パケットを当該時刻ＴTransmitに送信し（ステップＳ５３）、受信確認を待つ。受信確認を受信すると（ステップＳ５４）、ユーザはステップＳ５０のアイドル状態に戻る。受信確認を受信しなければ、衝突があったものと結論され（ステップＳ５４）、第２のランダム変数が遅延時間ＴRetransmitを与え（ステップＳ５５）（離散的アロハの場合には（ｋ*Ｔrec）における値でも与え）、当該遅延時間経過後に再度送信を試みる（ステップＳ５６）。
【００１１】
共有リソースへのランダム・アクセスのポリシーは、予約に沿って編成することができ、これは異なった理由によるものである。
【００１２】
まず、送信の際にユーザが並行操作を実行しなければならない可能性がある。ユーザが当該ネットワーク上または他のアクセスネットワーク上でパラメータ計測を実行するために、自らの送受信リソースを使用しなければならないときなどの、いくつかのケースにおいては、これらの操作は共有チャネルへのアクセスを除外し、あるいは、必要であれば、制御チャネル上で受信確認を読み取ることを除外する。次に時間範囲が予約されるが、これは、優先的タスク用にアクセスを自由にしておくために、共有リソースへのアクセスはユーザに対して拒否される範囲である。離散的アロハ・プロトコルに従ってアクセスが行われれば、予約された時間範囲の時間的長さは送信間隔となり得る。
【００１３】
ユーザが、送信要求あるいは、リソースの一部の一時的または恒久的予約を正当化する優先権を有している可能性もある。そのような特権を有するユーザは、予約した時間範囲にリソースにアクセスすることができ、他のユーザはこれらの範囲にはあらゆるランダム・アクセスから排除される。
【００１４】
【発明が解決しようとする課題】
上記で説明した予約の両方の場合において、リソースの全てのユーザは、アクセスできない時間範囲を事前に知っている。しかし、これらの予約された時間範囲は、ランダム・アクセスの作業の妨げとなり、特に、動作持続性の解決の妨げとなる。実際に、比較的小さい予約範囲の密度についてさえ、ランダム変数のサンプリングを介して得られる送信／再送信時刻は、おそらく反復して、これらの範囲内に入ることがあり得る。するとユーザは、その任意の値のサンプリングによって得られた値から逸れようという気になることがある。しかし、これはリソースへのアクセスの統計的特性を無制御に変更する偏りを導入することになり、特に、システムが繰り返しの衝突を伴う状況から速やかに抜け出ることをもはや保証しなくなるであろう。
【００１５】
この発明の目的は、時間範囲を予約してランダムアクセスを行うシステムにおいて、トラフィックのチェックと動作持続性の解決を可能とすることである。
【００１６】
【課題を解決するための手段】
この目的は、平均は同じであるが分散が大きいランダム変数の中で、送信／再送信時刻を与えるランダム変数を一時的に変更することによって達成される。
【００１７】
予約の侵害は、データ・パケットの送信時刻が予約されている時間範囲に入るときに成立することが有利である。しかし、予約の侵害は、予約された時間範囲内にデータ・パケットの受信確認があることが予期されるときにも成立し得る。
【００１８】
アロハ・プロトコルは、離散的アロハ・プロトコルであることが有利であり、予約された時間範囲は送信間隔である。
【００１９】
上記の本発明の特徴、ならびに他の特徴は、実施例に関する以下の説明を読めば更に明らかになるであろう。この説明は付属の図面を参照して行う。
【００２０】
【発明の実施の形態】
図１に示し既に説明した、複数のユーザによって共有されるリソースの前提を再び使用する。このリソースへのユーザのアクセスは、ランダム・モードに従ってパケットにおいて行われる。特定の時間範囲は所与のユーザに対して予約されるが、これは、そのユーザがこれらの時間範囲の間に特別なタスク（たとえば、ネットワークまたは他のアクセス・ネットワーク上でのパラメータ計測）を実行しなければならないか、または、特権を与えられたユーザがリソースの予約された部分を有しているからである。予約は一時的または確定的なものにすることができるが、各ユーザが事前に、リソースにアクセスできない時間範囲のプログラムを知っている（または、システムを介して再び受信する）ものと仮定する。また、ユーザは、移動局（モバイル・ステーション）であってもよく、または、ネットワーク等に接続された固定されたパソコン等であってもよい。
【００２１】
図６は、本発明に従って変更された、離散的アロハ・プロトコルを使用する予約された時間範囲内における送信シーケンスの例を示している。ユーザＵiに関する予約された時間範囲は、線Ｒiによって示されており、（Ｍ）と符号を付された時間範囲の間に、ユーザＵiは優先的タスクを実行しなければならず、（Ｘ）と符号を付された時間範囲の間に、特権を与えられたユーザはリソースへのアクセスを禁ずる。線Ｕiは、データ・パケットを送信するユーザＵiによる試みを示している。線ＵjはユーザＵjによって送信されたパケットを示しており、線ＡＣＫは、制御チャネル上で制御システムによって返信された受信確認を示している。ユーザＵiによって実行されるタスクは、線Ｔi上に示されている。（Ｔ）と符号を付された間隔は、衝突なしの送信に対応しており、（Ｃ）は衝突のある送信に対応しており、（Ｍ）は優先的タスクに対応している。
【００２２】
パケットが送信されると、ユーザＵiは、その第１のランダム変数によって与えられる送信時刻ＴTransmitをそれに割り当てる。ここで２つの選択肢があり得る。割り当てられた送信時刻が予約を侵害していなければ、パケットはこの時刻に送信される。一方、送信時刻が予約された範囲（ＸまたはＭ）内に当たるか、または、優先的タスク（Ｍ）の実行されている時間範囲に送信したパケットに対応する受信確認が受信されるかにより、割り当てられた送信時刻が予約を侵害するものであれば、パケットは割り当てられた時刻には送信できない。ここで、本発明によれば、（第１の）ランダム変数を、平均が同じで分散がより大きいランダム変数へ一時的に変更する処理に進む。平均が変化しないことは、システムによる遂行の制御を確実にし、分散が大きいことは、もはや予約を侵害しない送信時刻の値を得ることを可能にする。修正された任意の値は、再び試みられる新たな送信時刻を与える。新たな時刻が再び予約を侵害することにつながると、ランダム変数の変更ステップが繰り返される。
【００２３】
有利な実施形態によれば、変更は、均衡がとれており、所与の原則（離散的アロハについては離散的であり、単なるランダム・アロハについては継続的）であるランダム変数の付加により実行される。
【００２４】
図６の例を取り上げると、第１のランダム変数Ｕiがパケット６０−１の送信に時刻ｔ16の値を与えており、この時刻が予約（優先的タスク（Ｍ）（符号６１））を侵害するものであると、このランダム変数６２は変更されて、新たなサンプル６０−２が取られる。得られた新たな時刻ｔ21が同じ理由（優先的タスク（Ｍ）（符号６３））で再び予約を侵害するものであると、以前の変数変更ステップが繰り返され、新たなサンプル６０−３が取られる。得られた時刻ｔ19が予約を侵害していなければ、パケットはその時刻に送信される。
【００２５】
予約を侵害していないある送信時刻にデータ・パケットが送信されても（おそらく、上記のように第１のランダム変数の変更後に）、それにもかかわらず、データ・パケットは衝突してしまうことがあり得る。たとえば、所与の時間ＴACKの間に受信確認が受信されなければ、衝突はユーザによって検出される。パケットが衝突していれば、その第１の送信後の時間ＴRetransmitの期間の終わりに再度送信する必要があり、遅延ＴRetransmitは、第２のランダム変数によって与えられる。このようにして得られた再送信時刻は、予約との両立性を検証するためにテストされなければならない。侵害していなければ、パケットは得られた時刻に再度送信され、侵害していれば、本発明に従って、処理は、平均は同じで分散が大きいランダム変数への第２のランダム変数の一時的変更へと進む。上記のように、新たな時刻が再び予約を侵害することにつながれば、変数変更ステップが繰り返される。変更は、均衡がとれていて、所与の原則（離散的アロハについては離散的で、単なるランダム・アロハについては継続的）であるランダム変数の付加による同じ方法で行うことができる。したがって、各ユーザは、システムによって最初に設定されたＴRetransmitの変更されていない平均値を保持する。特に、それぞれのユーザの平均値は異なったままであり、このことが動作持続性を削減する。
【００２６】
再び図６の例を取り上げれば、時刻ｔ6に送信されたパケット６５−１はユーザＵjによって送信されたパケット６６と衝突しており、第１の遅延ＴRetransmitがユーザＵiの第２のランダム変数によって与えられている。対応する時刻ｔ11は、予約（時間範囲（Ｘ）（符号６７））を侵害している。次にランダム変数が変更されて、遅延値を得るために新たなサンプリング６５−３が実行される。しかしながら、当該サンプリングの送信時刻ｔ13に送信すると、それに対応する受信確認は、優先的タスク（時間範囲（Ｍ）（符号６１））の予約時間帯の時刻ｔ16になることが予期されるので、この遅延ｔ13に対応する新たな送信時刻も、予約を侵害することになる。したがって、ランダム変数は再度変更される。この新たなサンプリングを介して得られた遅延は、予約を侵害しない送信時刻ｔ12を与える。
【００２７】
本発明による方法は、離散的アロハ・プロトコルの枠組み内で図６に示したが、単なるランダム・アロハ・プロトコルにも適用されることは明らかである。
【００２８】
本発明の方法に従ったユーザの操作は、図７のフローチャートに図式的に示した。
【００２９】
アイドル状態（ステップＳ７００）から始めて、ユーザは、データ・パケットが送信されることになっているかどうかを定期的にテストする（ステップＳ７０１）。送信されることになっている場合には、ユーザの第１のランダム変数は、送信時刻ＴTransmitを提供する（ステップＳ７０２）。この値は、予約を侵害していないか否かを検証するためにテストされる（ステップＳ７０３）。侵害している場合には、第１のランダム変数は変更され（ステップＳ７０４）、得られた新たな送信時刻ＴTransmit（ステップＳ７０４）が、再び、予約を侵害しているか否かの試験を受ける（ステップＳ７０３）。予約を侵害していない場合には、ユーザは共有リソース上でＴTransmitにデータ・パケットを送信し（ステップＳ７０５）、受信確認を待つ。受信確認を受信すれば（ステップＳ７０６）、ユーザはステップＳ７００のアイドル状態に戻る。受信確認を受信しなければ、衝突があるものと結論し（ステップＳ７０６）、第２のランダム変数が遅延時間ＴRetransmitを与える。予約を侵害しているか否かをチェックするために、対応する再送信時刻がテストされる（ステップＳ７１１）。予約を侵害している場合には、第２のランダム変数が変更され（ステップＳ７１２）、新たな遅延時間が得られる（ステップＳ７１２）。対応する送信時刻が、侵害か否かのテストを受ける順番になる（ステップＳ７１２）。該時刻に侵害しない可能性があれば、ユーザはこの時刻にパケットを再度送信して（ステップＳ７１３）、受信確認を待つ。
【００３０】
上記の説明において、ランダム変数の変更は一時的なものである。ランダム変数は、最小の固定状態を確実にするために、特定の時間経過または特定のサンプル数の後に、最初の原則に戻ることができる。ランダム変数は、予約の制約に従って、ある程度には順応性のある変数を有する。
【００３１】
【発明の効果】
この発明は、アロハ・タイプのプロトコルに従った共有リソースへのユーザによるランダム・アクセス方法であって、特定の時間範囲がリソースへのアクセスのために既に予約されており、ユーザによるデータ・パケットの送信時刻が少なくとも１つのランダム変数によって与えられ、送信時刻での送信が予約を侵害することにつながるときには、ランダム変数は、平均は同じで分散が大きい他のランダム変数に一時的に変更されるようにしたので、トラフィックのチェックと動作持続性の解決とを可能にすることができる。
【図面の簡単な説明】
【図１】  数人のユーザ間で共有されたリソースへのランダム・アクセスのシステムの略図である。
【図２】  図１のシステムにおける送信タイミング・チャートである。
【図３】  単なるランダム・アロハ・プロトコルによる送信シーケンスの図である。
【図４】  離散的アロハ・プロトコルによる送信シーケンスの図である。
【図５】  アロハ・タイプのプロトコルによるユーザ操作のフローチャートである。
【図６】  本発明によるランダム・アクセス方法を使用した送信シーケンスの図である。
【図７】  本発明によるランダム・アクセス方法を使用したユーザ操作のフローチャートである。
【符号の説明】
１１  ユーザ（Ｕ1）、１２  ユーザ（Ｕ2）、１３  ユーザ（ＵN）、１５  システム（Ｓ）、３０−１，３０−２，３１−１，３１−２，３２−１，３２−２，３３−１，３３−２，６０−１，６０−２，６０−３，６５−１，６５−２，６５−３，６５−４，６６  データ・パケット。
【図１】
0004467777.tif 000002
【図２】
0004467777.tif 000003
【図３】
0004467777.tif 000004
【図４】
0004467777.tif 000005
【図５】
0004467777.tif 000006
【図６】
0004467777.tif 000007
【図７】
0004467777.tif 000008