JP3780921B2 - リング型ネットワークの受信確認方法および端末装置 - Google Patents
リング型ネットワークの受信確認方法および端末装置Info
- Publication number
- JP3780921B2 JP3780921B2 JP2001367538A JP2001367538A JP3780921B2 JP 3780921 B2 JP3780921 B2 JP 3780921B2 JP 2001367538 A JP2001367538 A JP 2001367538A JP 2001367538 A JP2001367538 A JP 2001367538A JP 3780921 B2 JP3780921 B2 JP 3780921B2
- Authority
- JP
- Japan
- Prior art keywords
- terminal device
- transmission
- network
- frame
- counter
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Landscapes
- Small-Scale Networks (AREA)
Description
【発明の属する技術分野】
本発明は、複数の端末装置を含むリング型ネットワークにおける通信データの受信確認方法および端末装置に関する。
【0002】
【従来の技術】
従来、ネットワークの各端末装置(以下、ハブ等を含むノードの意として用いる)間を接続する形態(ネットワークトポロジ)として、10BASE−5等のバス型、10BASE−T等のスター型、IEEE(Institute of Electrical and Electronic Engineers)1394等のツリー型あるいはFDDI(Fiber Distributed Data Interface)等のリング型といったトポロジが知られている。
【0003】
このようなトポロジの中で、リング型のネットワークは、ネットワークに接続された複数の端末装置に所定の順序が設定され、特定の端末装置が送信したフレーム(データ)は、これら端末装置を所定の順序で中継されることによってネットワークを1周し、送信元の端末装置に戻るという特徴を有する。また、各端末装置は、受信したフレームに変更を加えて後続の端末装置に中継することが可能である。
【0004】
リング型ネットワークのこのような特徴を利用した技術として、以下の技術が挙げられる。
例えば、特開平11−284645号公報には、ネットワークに接続された各端末装置が、中継するフレームにデータの挿入あるいは削除を行い、それによって変化したフレームのデータサイズに関する情報も変更して、フレームを中継する技術が開示されている。この方式によると、送信元端末装置から送信されたフレームは、ネットワーク上を2周する間に、所定手順に従い、各端末装置がデータの挿入あるいは削除を施すことによって、全ての端末装置に変更されたフレームの情報を配信することが可能である。
【0005】
また、特開平11−127181号公報には、ネットワークに接続された特定の管理用端末装置が、中継するフレームの一部に所定の変更を加え、管理用端末装置が中継する各フレームについて、既に中継したフレームであるか否かを判定する技術が開示されている。この方式によると、いずれかの端末装置において、削除すべきフレームの削除に失敗した場合に、そのフレームがネットワークを巡回し続ける事態を回避することが可能となる。
【0006】
ところで、上述の各トポロジにおいて、ネットワークのアクセス制御方法は、トークン方式あるいはCSMA/CD等を適宜用いるものであるが、いずれのアクセス制御方法を用いる場合においても、通信の態様としては、ユニキャスト通信、ブロードキャスト通信およびマルチキャスト通信の3種類に大別される。
例えば、IEEE1394においては、これら3種類の通信のいずれをも行うことができる。ここで、ユニキャスト通信とは、特定の端末装置間で行われる1対1の通信、ブロードキャスト通信とは、特定の端末装置から全ての端末装置に対する通信、マルチキャスト通信とは、特定の端末装置から所定のグループに属する端末装置に対する通信である。
【0007】
以下、IEEE1394において、ネットワークに接続された各端末装置に“0”〜“62”の端末番号が付されているものとして、ユニキャスト通信、ブロードキャスト通信およびマルチキャスト通信の処理について概略を説明する。
ユニキャスト通信では、情報を送信する端末装置が、送信先端末番号と送信元端末番号を含むアシンクロナスパケット(非同期転送されるパケット)をネットワークに送信する。そして、パケットの送信先である端末装置がパケットを受信すると、送信元の端末装置にパケットの受信状況を示すアクノリッジパケットを送信し、アシンクロナスパケットを送信した端末装置は、アクノリッジパケットを受信することによって送信の成功/失敗を判定する。ここで、アクノリッジパケットには、パケットの受信の成功あるいは失敗等を示すアクノリッジコードが含まれており、具体的なアクノリッジコードとして、受信成功を示す“complete”、受信失敗を示す“busy”、受信データにエラーが発生していることを示す“data#error”等のコードがセットされる。
【0008】
なお、アシンクロナスパケットの送信元の端末装置では、アクノリッジパケットによって送信先の端末装置において情報が正常に受信されなかったことを確認した場合、再送信等を行い、確実に情報の送信を行うことができる。
また、ブロードキャスト通信では、送信元の端末装置は、ユニキャスト通信と同様のアシンクロナスパケットを送信するが、送信先端末番号として、“63”が付されている。この送信先端末番号“63”は、全ての端末装置を宛先とすることを示す特別の番号である。なお、ブロードキャスト通信では、送信先の端末装置はアクノリッジパケットを送信せず、送信元の端末装置は、アシンクロナスパケットの送信を行うことによって情報の送信処理を完了し、送信の成功/失敗の確認は行わない。
【0009】
さらに、マルチキャスト通信では、送信元の端末装置は、予め設定された“0”〜“63”のチャネル番号によって表されるグループを送信先としてアイソクロナスパケット(規則的な間隔で転送されるパケット)を送信する。また、各端末装置には、“0”〜“63”のチャネル番号が設定されており、送信元の端末装置によって送信されたアイソクロナスパケットのチャネル番号が自装置に設定されたチャネル番号と一致する場合、そのパケットを受信する。ここで、各端末装置には、上述のグループを表す1つ又は複数のチャネル番号が設定されている。なお、マルチキャスト通信では、ブロードキャスト通信と同様に、送信先の端末装置はアクノリッジパケットを送信せず、送信元の端末装置は、送信の成功/失敗の確認を行わない。
【0010】
【発明が解決しようとする課題】
しかしながら、上述の通り、マルチキャスト通信においては、特定の送信先に対する通信を行うにも関わらず送信の成功/失敗を確認しないため、ユニキャスト通信と異なり、情報の確実な送信は保証されないものである。このとき、以下のような事態が生ずる。
即ち、特定の端末装置から他の複数の端末装置に対し、スイッチ操作によるネットワーク構成の変化といった所定の情報を確実に送信するためには、送信先であるそれぞれの端末装置に対してユニキャスト通信を行うか、送信の失敗が発生することを想定して予めマルチキャスト通信を複数回行うか、スイッチ操作等が行われた場合に限らず、定期的に情報をマルチキャスト通信するといった対処を行う必要がある。
【0011】
これらいずれの場合にも、1つのデータを送信するのみの処理であるにも関わらず、同様の動作を複数回繰り返す必要があり、伝送効率あるいは通信レスポンスの低下を招くこととなる。また、スイッチ操作の頻度が増加すれば、それに伴って上述のような動作の回数が増し、伝送効率あるいは通信レスポンスがさらに低下することとなる。
また、情報の送信先の端末装置がネットワークから脱退した場合、ユニキャスト通信においては送信先端末装置からの応答時間を監視することにより、その端末装置の脱退を検出することができる。
【0012】
しかし、この場合、応答時間を監視している間は、ネットワークにおいて他の通信が行えないため、無駄時間が発生すると共に、端末装置の脱退を検出するのに一定の時間を要するため、対処が遅れることとなる。一方、マルチキャスト通信においては、送信の成功/失敗の確認を行わないことから、端末装置の脱退を検出することはできない。
さらに、脱退した端末装置がネットワークに再度加入した場合、ユニキャスト通信においては、上述の無駄時間の発生を避けるためにその端末装置への通信を停止していることから、再加入を直ちに検出することはできず、そのため、通信を直ちに再開することもできない。
【0013】
一方、マルチキャスト通信においては、端末装置が再加入した場合、その端末装置に通信データは送信されることとなるが、ネットワークに再加入したことは検出できないため、ネットワークへの再加入に対応する所定処理(再登録等)を行うことができない。
したがって、マルチキャスト通信の場合、定期的に加入している端末の検出を行う必要がある。しかし、ネットワークの伝送効率の都合上、この検出を高頻度に行うことはできず、そのため、再加入した端末装置の検出が遅れ、再加入に対応する所定処理が遅れることとなる。
【0014】
このような問題は、マルチキャスト通信において、送信の成功/失敗が確認されないことに起因している。また、この問題は、上述の特開平11−28465号公報あるいは特開平11−127181号公報に開示されたリング型のネットワークにおいても同様に発生する。
本発明の課題は、リング型のネットワークにおいて、マルチキャスト通信を行う際に送信先端末装置からの応答確認を可能とすることである。
【0015】
【課題を解決するための手段】
以上の課題を解決するため、請求項1記載の発明は、
ネットワークに接続された複数の端末装置が、その接続位置に応じた一定順序(例えば、図1におけるネットワーク50の時計回りの順序)にしたがって送信情報(例えば、図3に示すフレーム10a〜40a)を中継することにより、各端末装置間における通信を行うリング型ネットワークの受信確認方法であって、
送信元の端末装置(例えば、図1の端末装置10)は、送信先の受信要素(例えば、図1の端末装置20〜40あるいは各端末装置に含まれるオブジェクト)を指定する指定情報(例えば、図2のチャネル番号)と、送信先の受信要素に係る端末装置によって加算可能なACKカウンタおよびNACKカウンタとを含む送信情報を送信すると共に、ネットワークにおける該送信情報の送信先となる受信要素の数(例えば、発明の詳細な説明中の想定端末数)を予め把握し、
前記指定情報により指定される受信要素に係る端末装置(例えば、指定されたチャネル番号を受信するように設定されているオブジェクトを有する端末装置あるいは指定されたチャネル番号を受信するように設定されている端末装置)は、該受信要素が送信情報を正常に受信した場合には、ACKカウンタを所定値加算して後続の端末装置に中継し、該受信要素が送信情報を正常に受信しなかった場合には、NACKカウンタを所定値加算して後続の端末装置に中継し、
前記送信元の端末装置は、ネットワークを中継されて回帰した前記送信情報(例えば、発明の詳細な説明中の回帰フレーム)のACKカウンタと、予め把握している前記送信先の受信要素の数とに基づいて、送信先である全ての受信要素において、前記送信情報が正常に受信されたか否かを確認すると共に、ネットワークを中継されて回帰した前記送信情報のNACKカウンタに基づいて、送信先である受信要素のいずれかにおいて、前記送信情報が正常に受信されなかったことを確認することにより、前記送信先の受信要素の全てにおいて、送信情報が正常に受信されたか否かを判定可能であり、さらに、ネットワークを中継されて回帰した前記送信情報のACKカウンタおよびNACKカウンタの合計値(例えば、発明の詳細な説明中のカウンタ合計値)と、予め把握している前記送信先の受信要素の数とに基づいて、ネットワークの要素の構成の変化を検出可能であることを特徴としている。
【0016】
請求項2記載の発明は、
請求項1記載のリング型ネットワークの受信確認方法であって、
前記送信元の端末装置は、ネットワークを中継されて回帰した前記送信情報のACKカウンタおよびNACKカウンタの合計値を、ネットワークにおける前記送信情報の送信先となる受信要素の数として新たに把握することを特徴としている。
【0017】
請求項3記載の発明は、
ネットワークに接続された複数の端末装置が、その接続位置に応じた一定順序にしたがって送信情報を中継することにより、各端末装置間における通信を行うリング型ネットワークの端末装置(例えば、図3あるいは図7の端末装置10)であって、
送信先の受信要素を指定する指定情報と、送信先の受信要素に係る端末装置によって加算可能なACKカウンタおよびNACKカウンタとを含む送信情報を送信する送信手段と、
ネットワークを中継されて回帰した前記送信情報のACKカウンタと、予め把握している前記送信先の受信要素の数とに基づいて、送信先である全ての受信要素において、前記送信情報が正常に受信されたか否かを確認すると共に、ネットワークを中継されて回帰した前記送信情報のNACKカウンタに基づいて、送信先である受信要素のいずれかにおいて、前記送信情報が正常に受信されなかったことを確認することにより、該送信情報が前記送信先の受信要素の全てにおいて正常に受信されたか否かを判定する判定手段と、
ネットワークを中継されて回帰した前記送信情報のACKカウンタおよびNACKカウンタの合計値と、予め把握している前記送信先の受信要素の数とに基づいて、ネットワークの要素の構成の変化を検出する検出手段と、
を備えることを特徴としている。
【0018】
請求項4記載の発明は、
請求項3記載の端末装置であって、
ネットワークを中継されて回帰した前記送信情報のACKカウンタおよびNACKカウンタの合計値を、ネットワークにおける前記送信情報の送信先となる受信要素の数として新たに把握することを特徴としている。
【0019】
本発明によれば、送信元の端末装置において、送信情報が送信先の受信要素によって正常に受信されたか否かを確認することができる。また、そのため、送信先の受信要素によって送信情報が正常に受信されなかった場合にのみ送信情報の再送を行うこととでき、送信先の受信要素に確実に送信情報を送信するために複数回の送信を不必要に行うことを回避することができる。即ち、伝送効率あるいは通信レスポンスの低下を避けることができる。
【0020】
また、本発明によれば、送信先の受信要素がネットワークに加入している状態で送信情報の受信に失敗した場合にのみ、送信情報の再送を行うこととできる。そのため、送信先の受信要素がネットワークから脱退しているにも関わらず、送信情報の再送信を繰り返してしまう事態を回避することができ、伝送効率あるいは通信レスポンスの低下を避けることができる。さらに、ACKカウンタおよびNACKカウンタの合計値に基づいて、現在、ネットワークに含まれる受信要素の総数を把握することができる。
【0028】
【発明の実施の形態】
以下、図を参照して本発明に係るリング型ネットワークの実施の形態を詳細に説明する。
(第1の実施の形態)
図1は、本発明を適用した第1の実施の形態に係るリング型ネットワーク1の構成を示す図である。
【0029】
リング型ネットワーク1は、送信元の端末装置が、マルチキャスト通信するフレームにACKカウンタを含めて送信し、送信先の端末装置が、フレームを正常に受信した場合にACKカウンタをカウントアップして、そのフレームを中継する。したがって、送信元の端末装置において、送信対象のフレームが送信先の端末装置によって正常に受信されたか否かを検出できる。
まず、構成を説明する。
【0030】
図1において、リング型ネットワーク1は、端末装置10〜40と、伝送媒体50とを含んで構成される。
端末装置10〜40は、伝送媒体50と端末装置10〜40との間でのデータの送受信を行う通信部、データを記憶する記憶部、データを表示する表示部、これらの各機能部を管理し、端末装置全体の制御を行う制御部等を備えている。
これら端末装置10〜40には、リング型ネットワーク1における接続位置に応じた所定の順序が設定されており、いずれかの端末装置が送信したフレームは、各端末装置が順次、この所定順序にしたがって後続の端末装置に中継することにより、全ての端末装置に送信可能である。なお、図1においては、ネットワークに接続された各端末装置が時計回りの順にフレームを中継する。
【0031】
また、各端末装置には、自装置が受信する(即ち、コピーして中継する)フレームのチャネル番号および自装置が中継するフレームのチャネル番号が設定されている。例えば、図1において、端末装置20,40は、チャネル番号“7”のフレームを受信するように設定され、一方、端末装置10はチャネル番号“7”のフレームを中継するように設定されている。
そして、自装置が受信するように設定されたチャネル番号のフレームを受信した端末装置は、そのフレームを正常に受信した場合、フレームのACKカウンタ(後述)を“1”カウントアップして、後続の端末装置に中継する。
【0032】
なお、各端末装置は、各チャネル番号のフレームを受信するように設定されている端末装置の数(以下、「想定端末数」と言う。)を記憶しており、想定端末数と、自装置が送信し、ネットワークを1周して受信したフレーム(以下、「回帰フレーム」と言う。)のACKカウンタの値とに基づいて、送信対象のフレームが全ての送信先端末装置によって正常に受信されたか否かを判定する。
次に、リング型ネットワーク1において送受信されるフレームについて説明する。
【0033】
図2は、フレームの情報構成を示す図である。
図2において、フレームは、“フレーム種別”、そのフレームの “チャネル番号”、フレームの“データサイズ”、送信対象データの内容を表す“データ”、そのフレームが受信側端末装置で正常に受信された場合にカウントアップされる“ACKカウンタ”および“CRC(Cyclic Redundancy Check)コード”の各情報を含んで構成される。
【0034】
また、図2に示すフレームは、フレーム種別を先頭とする順序(図2に示す送信方向)で送信される。
ここで、図2に示すように、ACKカウンタがデータより後ろに位置しているのは、送信先の端末装置において、受信バッファの溢れ等により、データが正常に受信されない場合に、その事態が発生する前にACKカウンタがカウントアップされることを防ぐためである。また、CRCコードが最後に位置している構成(即ち、ACKカウンタがCRCコードより前に位置している構成)は、通常のフレームと同様の趣旨に基づくものであり、仮に、送信先の端末装置でACKカウンタがカウントアップされた後にCRCコードによりフレームの異常が判明した場合、端末装置はそのフレームを破棄(正常なフレームとして処理しない)するため、ACKカウンタをカウントアップしたことによる影響は生じない。また、送信元端末装置は、CRCコードが異常なフレームを受信した場合にも、ACKカウンタの値を参照することなく破棄するため問題とならない。
【0035】
なお、ACKカウンタをCRCコードの後ろに配置する構成としてもよいが、この場合、さらにACKカウンタ用のCRCコードが必要となる。
次に、リング型ネットワーク1におけるマルチキャスト通信処理について説明する。
図3は、端末装置10が送信した送信対象フレームが送信先の端末装置によって正常に受信・中継される場合の処理を表す図である。
【0036】
以下、端末装置10が送信する送信対象フレームをフレーム10aとし、端末装置20〜40によって中継される際のフレームをそれぞれフレーム20a〜40aと称する。また、図3において、端末装置20,40は、チャネル番号“7”のフレームを受信する設定であり、端末装置30は、チャネル番号“7”のフレームを中継するのみの端末装置である。さらに、端末装置10は、チャネル番号“7”のフレームを受信する端末装置の想定端末数として“2”を記憶している。
【0037】
初めに、端末装置10は、送信対象フレームであるフレーム10aを端末装置20に送信する(時刻T=1)。このとき、フレーム10aには、ACKカウンタ“0”が設定されている(ACKカウンタ=0)。
次に、端末装置20がフレーム10aを受信する。そして、端末装置20は、フレーム10aを正常に受信し、ACKカウンタを“1”カウントアップする(ACKカウンタ=1)。
【0038】
さらに、端末装置20は、ACKカウンタをカウントアップしたフレーム20aを端末装置30に中継する(時刻T=2)。
次に、端末装置30がフレーム20aを受信する。そして、端末装置30は、フレーム20aのACKカウンタを変化させず、そのままの内容のフレーム(フレーム30a)を端末装置40に中継する(ACKカウンタ=1、時刻T=3)。
【0039】
次に、端末装置40がフレーム30aを受信する。そして、端末装置40は、フレーム30aを正常に受信し、ACKカウンタを“1”カウントアップする(ACKカウンタ=2)。
さらに、端末装置40は、ACKカウンタを“1”カウントアップしたフレーム40aを端末装置10に中継する(時刻T=4)。
すると、端末装置10は、ACKカウンタの値が“2”であり、想定端末数“2”と一致するため、送信対象フレームの送信に成功したと判定し、端末装置40から受信したフレーム40aを破棄する。
【0040】
次に、図4は、端末装置10が送信した送信対象フレームが送信先の端末装置(端末装置40)によって正常に受信されない場合の処理を示す図である。
以下、端末装置10が送信する送信対象フレームをフレーム10bとし、端末装置20〜40によって中継される際のフレームをそれぞれフレーム20b〜40bと称する。また、図4において、図3の場合と同様に、端末装置20,40は、チャネル番号“7”のフレームを受信する設定であり、端末装置30は、チャネル番号“7”のフレームを中継するのみの端末装置である。
【0041】
初めに、端末装置10は、送信対象フレームであるフレーム10bを端末装置20に送信する(時刻T=5)。このとき、フレーム10bには、ACKカウンタ“0”が設定されている(ACKカウンタ=0)。
次に、端末装置20がフレーム10bを受信する。そして、端末装置20は、フレーム10bを正常に受信し、ACKカウンタを“1”カウントアップする(ACKカウンタ=1)。
【0042】
さらに、端末装置20は、ACKカウンタをカウントアップしたフレーム20bを端末装置30に中継する(時刻T=6)。
次に、端末装置30がフレーム20bを受信する。そして、端末装置30は、フレーム20bのACKカウンタを変化させず、そのままの内容のフレーム(フレーム30b)を端末装置40に中継する(ACKカウンタ=1、時刻T=7)。
【0043】
次に、端末装置40がフレーム30bを受信する。ここで、端末装置40は、フレームの受信に失敗し、正常に受信できなかったものとする。このとき、端末装置40は、ACKカウンタをカウントアップしない(ACKカウンタ=1)。
そして、端末装置40は、このフレーム(フレーム40b)を端末装置10に中継する(時刻T=8)。
すると、端末装置10は、ACKカウンタの値が“1”であり、想定端末数“2”と一致しないため、送信対象フレームの送信に失敗したと判定し、送信対象フレーム(フレーム10a)の再送信を行う。なお、このとき、ACKカウンタの値と想定端末数との差に相当する端末装置の数が、送信対象フレームを正常に受信できなかった端末装置の数に相当する。
【0044】
以上のように、本実施の形態に係るリング型ネットワーク1は、送信対象フレームの送信元の端末装置において、回帰フレームを受信した場合に、そのフレームのACKカウンタと、自装置が記憶している想定端末数とを比較し、これらが一致する場合には、送信先の全ての端末装置において、送信対象フレームが正常に受信されたと判定し、一致しない場合には、いずれかの送信先の端末装置において正常に受信されなかったと判定する。
【0045】
したがって、送信元の端末装置において、送信対象フレームが送信先の端末装置によって正常に受信されたか否かを確認することができ、正常に受信されなかった場合にのみフレームの再送を行うこととできる。これにより、送信先の端末装置に確実にフレームを送信するために複数回の送信を不必要に行うことを回避することができ、伝送効率あるいは通信レスポンスの低下を避けることができる。
(第2の実施の形態)
次に、本発明を適用した第2の実施の形態に係るリング型ネットワーク2について説明する。
【0046】
本実施の形態において、リング型ネットワーク2のネットワーク構成は、図1に示す第1の実施の形態における構成と共通するため、図1を参照し、端末装置等については同一の符号を用いて説明する。
本実施の形態において、リング型ネットワーク1は、送信元の端末装置が、マルチキャスト通信するフレームにACKカウンタおよびNACKカウンタを含めて送信し、送信先の端末装置が、フレームを正常に受信した場合にACKカウンタをカウントアップし、フレームを正常に受信しなかった場合に、NACKカウンタをカウントアップして、そのフレームを中継する。したがって、送信元の端末装置において、送信対象のフレームが送信先の端末装置によって正常に受信されたか否かを検出できる。また、送信対象のフレームが送信先の端末装置によって正常に受信されなかった場合に、その原因が、送信先端末装置がネットワークから脱退したことによるものであるか否かを検出することができ、そのフレームを受信した端末装置の数の増減も検出できる。
【0047】
まず、構成を説明する。
リング型ネットワーク2のネットワーク構成は、上述の通り、図1と同様である。
また、本実施の形態における端末装置10〜40の機能構成も第1の実施の形態における端末装置の機能構成と同様であるため、説明を省略する。
次に、リング型ネットワーク2において送受信されるフレームについて説明する。
【0048】
図5は、フレームの情報構成を示す図である。
図5において、フレームは、図2の構成と同様に、“フレーム種別”、そのフレームの “チャネル番号”、フレームの“データサイズ”、送信対象データの内容を表す“データ”、そのフレームが受信側端末装置で正常に受信された場合にカウントアップされる“ACKカウンタ”および“CRCコード”の各情報を含み、さらに、そのフレームが受信側端末装置で正常に受信されなかった場合にカウントアップされる“NACKカウンタ”を含んで構成される。
【0049】
また、図5に示すフレームは、フレーム種別を先頭とする順序(図5に示す方向)で送信される。
ここで、図5に示すように、CRCコードが最後に位置している構成(即ち、NACKカウンタがCRCコードより前に位置している構成)は、通常のフレームと同様の趣旨に基づくものである。
次に、リング型ネットワーク2におけるマルチキャスト通信処理について説明する。
【0050】
図6は、端末装置10が送信した送信対象フレームが送信先の端末装置において正常に受信・中継される場合の処理を表す図である。
以下、端末装置10が送信する送信対象フレームをフレーム10cとし、端末装置20〜40によって中継される際のフレームをそれぞれフレーム20c〜40cと称する。また、図6において、端末装置20,40は、チャネル番号“7”のフレームを受信する設定であり、端末装置30は、チャネル番号“7”のフレームを中継するのみの端末装置である。さらに、端末装置10は、チャネル番号“7”のフレームを受信する端末装置の想定端末数として“2”を記憶している。
【0051】
初めに、端末装置10は、送信対象フレームであるフレーム10cを端末装置20に送信する(時刻T=9)。このとき、フレーム10cには、ACKカウンタ“0”およびNACKカウンタ“0”が設定されている(ACKカウンタ=0、NACKカウンタ=0)。
次に、端末装置20がフレーム10cを受信する。そして、端末装置20は、フレーム10cを正常に受信し、ACKカウンタを“1”カウントアップする(ACKカウンタ=1)。また、フレーム10cが正常に受信されたため、NACKカウンタは“0”のままである(NACKカウンタ=0)。
【0052】
さらに、端末装置20は、ACKカウンタをカウントアップしたフレーム20cを端末装置30に中継する(時刻T=10)。
次に、端末装置30がフレーム20cを受信する。そして、端末装置30は、フレーム20cのACKカウンタを変化させず、そのままの内容のフレーム(フレーム30c)を端末装置40に中継する(ACKカウンタ=1)。また、NACKカウンタも“0”のままである(NACKカウンタ=0、時刻T=11)。
【0053】
次に、端末装置40がフレーム30cを受信する。そして、端末装置40は、フレーム30cを正常に受信し、ACKカウンタを“1”カウントアップする(ACKカウンタ=2)。また、フレーム30cが正常に受信されたため、NACKカウンタは“0”のままである(NACKカウンタ=0)。
さらに、端末装置40は、ACKカウンタを“1”カウントアップしたフレーム40aを端末装置10に中継する(時刻T=12)。
【0054】
すると、端末装置10は、ACKカウンタの値が“2”であり、想定端末数“2”と一致するため、送信対象フレームの送信に成功したと判定し、端末装置40から受信したフレーム40cを破棄する。
次に、図7は、端末装置10が送信した送信対象フレームが送信先の端末装置(端末装置40)によって正常に受信されない場合の処理を示す図である。
以下、端末装置10が送信する送信対象フレームをフレーム10dとし、端末装置20〜40によって中継される際のフレームをそれぞれフレーム20d〜40dと称する。また、図7において、図6の場合と同様に、端末装置20,40は、チャネル番号“7”のフレームを受信する設定であり、端末装置30は、チャネル番号“7”のフレームを中継するのみの端末装置である。
【0055】
初めに、端末装置10は、送信対象フレームであるフレーム10dを端末装置20に送信する(時刻T=13)。このとき、フレーム10dには、ACKカウンタ“0”およびNACKカウンタ“0”が設定されている(ACKカウンタ=0、NACKカウンタ=0)。
次に、端末装置20がフレーム10dを受信する。そして、端末装置20は、フレーム10dを正常に受信し、ACKカウンタを“1”カウントアップする(ACKカウンタ=1)。また、フレーム10dが正常に受信されたため、NACKカウンタは“0”のままである(NACKカウンタ=0)。
【0056】
さらに、端末装置20は、ACKカウンタをカウントアップしたフレーム20dを端末装置30に中継する(時刻T=14)。
次に、端末装置30がフレーム20dを受信する。そして、端末装置30は、フレーム20dのACKカウンタを変化させず、そのままの内容のフレーム(フレーム30d)を端末装置40に中継する(ACKカウンタ=1)。また、NACKカウンタも“0”のままである(NACKカウンタ=0、時刻T=15)。
【0057】
次に、端末装置40がフレーム30dを受信する。ここで、端末装置40は、フレームの受信に失敗し、正常に受信できなかったものとする。このとき、端末装置40は、ACKカウンタをカウントアップしない(ACKカウンタ=1)。一方、端末装置40は、フレーム30dの受信に失敗したため、NACKカウンタを“1”カウントアップする(NACKカウンタ=1)。
そして、端末装置40は、このフレーム(フレーム40d)を端末装置10に中継する(時刻T=16)。
【0058】
すると、端末装置10は、ACKカウンタの値が“1”であり、想定端末数“2”と一致しないため、送信対象フレームの送信に失敗したと判定する。さらに、想定端末数は“2”であり、フレーム40dのACKカウンタの値“1”とNACKカウンタの値“1”とを加えると、“2”となるため、送信失敗の原因が、いずれかの送信先端末装置がネットワークから脱退したことによるものではないと判定できる。したがって、フレーム10dの再送を繰り返すことにより、確実に全ての送信先端末装置に送信対象フレームを送信することができる。
【0059】
以上のように、本実施の形態に係るリング型ネットワーク2は、送信対象フレームの送信元の端末装置において、回帰フレームを受信した場合に、そのフレームのACKカウンタと、自装置が記憶している想定端末数とを比較し、これらが一致する場合には、送信先の全ての端末装置において、送信対象フレームが正常に受信されたと判定する。
また、ACKカウンタと、想定端末数とが一致しない場合には、ACKカウンタの値と、NACKカウンタの値とを合計し、合計値が想定端末数と一致する場合には、送信先端末装置がネットワークから脱退したための送信失敗ではないと判定し、送信対象フレームを再送信する。
【0060】
したがって、送信元の端末装置において、送信したフレームが送信先の端末装置に正常に送信できたか否かを確認することができる。また、送信先の端末装置がネットワークに加入している状態でフレームの受信に失敗した場合にのみ、フレームの再送を行うこととできる。そのため、送信先の端末装置がネットワークから脱退しているにも関わらず、フレームの再送信を繰り返してしまう事態を回避することができ、伝送効率あるいは通信レスポンスの低下を避けることができる。
【0061】
ここで、本実施の形態に係るリング型ネットワーク2は、端末装置10において、回帰フレームのACKカウンタおよびNACKカウンタの値を合計することによって、ネットワーク構成の変化を検出することが可能である。
以下、リング型ネットワーク2において、ネットワーク構成の変化が発生した場合について説明する。
リング型ネットワーク2では、上述の通り、端末装置40が送信対象フレームの受信に失敗した場合、端末装置10は、受信したフレームのACKカウンタとNACKカウンタとの合計値(以下、「カウンタ合計値」と言う。)を算出する。そして、端末装置10は、カウンタ合計値に基づいて、端末装置40がネットワークから脱退していない限り、フレームの再送を繰り返す。このとき、カウンタ合計値は“2”となっている。あるいは、端末装置20,40のいずれも、送信対象フレームの受信に成功している場合にも、カウンタ合計値は、“2”となる。
【0062】
端末装置10は、送信対象フレームを再送信する場合、このカウンタ合計値を保持し、再送信した後、回帰フレームのカウンタ合計値と比較して、双方が“2”で一致している場合、ネットワーク構成の変化を検出しない。
一方、端末装置40が、リング型ネットワーク2から脱退した場合、ACKカウンタあるいはNACKカウンタをカウントアップする端末装置が1つ減ることから、回帰フレームのカウンタ合計値は“1”となり、端末装置10が保持しているカウンタ合計値“2”と一致しないこととなる。即ち、端末装置10は、カウンタ合計値の変化に基づいて、ネットワーク構成の変化を検出する。そして、これに伴い、再送信の中止あるいは想定端末数の更新等、適切な対応を行うことが可能となる。
【0063】
なお、カウンタ合計値が“1”となった後は、端末装置10はカウンタ合計値“1”を新たに保持し、同様の処理(再送信等)を行うこととなる。
さらに、端末装置40がリング型ネットワーク2に再加入する等、端末装置が新たに加入した場合には、端末装置10が送信したフレームのACKカウンタあるいはNACKカウンタの値が“1”増加するため、回帰フレームのカウンタ合計値は“2”に変化する。
【0064】
したがって、端末装置10が保持しているカウンタ合計値“1”と、回帰フレームのカウンタ合計値“2”が一致しないため、端末装置10は、ネットワーク構成の変化を検出することができる。そして、この後は、端末装置10はカウンタ合計値“2”を新たに保持し、同様の処理を行うこととなる。
なお、端末装置10が保持するカウンタ合計値の初期値としては、リング型ネットワーク2のシステム起動時等、初期状態において、ネットワーク構成の変化が生じている場合は少ないと考えられるため、想定端末数を用いることが適当である。ただし、カウンタ合計値の初期値として“0”等、任意の値を用いることも可能である。
【0065】
また、上述のように、端末装置40がリング型ネットワーク2から脱退し、あるいは再加入した場合、端末装置10において、送信対象フレームが送信先端末装置によって正常に受信されたか否かの判定を行う処理は、以下のようになる。
なお、本実施の形態における、もう1つの送信先端末装置である端末装置20は、送信対象フレームを正常に受信するものとして説明する。
まず、端末装置40が送信対象フレームを正常に受信している場合、端末装置40はACKカウンタを“1”カウントアップし、回帰フレームのACKカウンタは“2”となるため、端末装置10は、送信対象フレームの送信に成功したと判定する。また、端末装置40が送信対象フレームを正常に受信できなかった場合、端末装置40はNACKカウンタを“1”カウントアップし、ACKカウンタはカウントアップせずに “1”のままであるため、端末装置10は、送信対象フレームの送信に失敗したと判定する。
【0066】
次に、端末装置40がリング型ネットワーク2から脱退した場合、端末装置40によってACKカウンタあるいはNACKカウンタがカウントアップされないこととなるため、端末装置10は、回帰フレームのACKカウンタの値に基づいて送信対象フレームの送信に失敗したと判定すると共に、カウンタ合計値に基づいて端末装置40の脱退を検出する。そして、この後、端末装置10は、回帰フレームのカウンタ合計値を想定端末数として更新し、以後、更新された想定端末数に基づいて同様の処理を行うこととなる。
【0067】
なお、以後の処理においては、想定端末数が“1”となるため、端末装置40がリング型ネットワーク2から脱退したネットワーク構成において、端末装置20が正常に送信対象フレームを受信した場合には、回帰フレームのACKカウンタは“1”となり、端末装置10は送信対象フレームの送信に成功したと判定する。
また、端末装置40がリング型ネットワーク2に再加入した場合、端末装置40によってACKカウンタあるいはNACKカウンタがカウントアップされることとなる。ここで、端末装置40がACKカウンタをカウントアップした場合、想定端末数は“1”であるのに対し、回帰フレームのACKカウンタは“2”となるため、この時点では、端末装置10は送信対象フレームの送信に失敗したと判定する。ただし、このとき、回帰フレームのカウンタ合計値に基づいて、想定端末数の更新が行われる。
【0068】
そして、この後に、端末装置10が送信対象フレームを再送信した場合、想定端末数は“2”であり、回帰フレームのACKカウンタの値も“2”となるため、端末装置10は、送信対象フレームの送信に成功したものと判定することとなる。
このように、本実施の形態に係るリング型ネットワーク2は、ネットワーク構成の変化を検出することが可能であり、また、ネットワーク構成の変化に対して、柔軟に対応することが可能である。
【0069】
なお、第1の実施の形態および第2の実施の形態において、リング型ネットワーク1,2を構成する端末装置を対象として、送信対象フレームの受信の成功/失敗を検出することとしたが、各端末装置に含まれるオブジェクト(フレームの受信を行う端末装置内の要素)を対象として、送信対象フレームの受信の成功/失敗を検出することとしてもよい。これにより、オブジェクト単位でのネットワーク構成の変化を検出し、それに対応することが可能となる。
【0070】
【発明の効果】
本発明によれば、送信元の端末装置において、送信情報が送信先の受信要素によって正常に受信されたか否かを確認することができる。また、そのため、送信先の受信要素によって送信情報が正常に受信されなかった場合にのみ送信情報の再送を行うこととでき、送信先の受信要素に確実に送信情報を送信するために複数回の送信を不必要に行うことを回避することができる。即ち、伝送効率あるいは通信レスポンスの低下を避けることができる。
【0071】
さらに、請求項3〜5、請求項8〜10および請求項13記載の発明によれば、送信先の受信要素がネットワークに加入している状態で送信情報の受信に失敗した場合にのみ、送信情報の再送を行うこととできる。そのため、送信先の受信要素がネットワークから脱退しているにも関わらず、送信情報の再送信を繰り返してしまう事態を回避することができ、伝送効率あるいは通信レスポンスの低下を避けることができる。さらに、ACKカウンタおよびNACKカウンタの合計値に基づいて、現在、ネットワークに含まれる受信要素の総数を把握することができる。
【図面の簡単な説明】
【図1】本発明を適用した第1の実施の形態に係るリング型ネットワーク1の構成を示す図である。
【図2】第1の実施の形態におけるフレームの情報構成を示す図である。
【図3】端末装置10が送信した送信対象フレームが送信先の端末装置によって正常に受信・中継される場合の処理を表す図である。
【図4】端末装置10が送信した送信対象フレームが送信先の端末装置(端末装置40)によって正常に受信されない場合の処理を示す図である。
【図5】第2の実施の形態におけるフレームの情報構成を示す図である。
【図6】端末装置10が送信した送信対象フレームが送信先の端末装置において正常に受信・中継される場合の処理を表す図である。
【図7】端末装置10が送信した送信対象フレームが送信先の端末装置(端末装置40)によって正常に受信されない場合の処理を示す図である。
【符号の説明】
1,2 リング型ネットワーク
10〜40 端末装置
50 伝送媒体
Claims (4)
- ネットワークに接続された複数の端末装置が、その接続位置に応じた一定順序にしたがって送信情報を中継することにより、各端末装置間における通信を行うリング型ネットワークの受信確認方法であって、
送信元の端末装置は、送信先の受信要素を指定する指定情報と、送信先の受信要素に係る端末装置によって加算可能なACKカウンタおよびNACKカウンタとを含む送信情報を送信すると共に、ネットワークにおける該送信情報の送信先となる受信要素の数を予め把握し、
前記指定情報により指定される受信要素に係る端末装置は、該受信要素が送信情報を正常に受信した場合には、ACKカウンタを所定値加算して後続の端末装置に中継し、該受信要素が送信情報を正常に受信しなかった場合には、NACKカウンタを所定値加算して後続の端末装置に中継し、
前記送信元の端末装置は、ネットワークを中継されて回帰した前記送信情報のACKカウンタと、予め把握している前記送信先の受信要素の数とに基づいて、送信先である全ての受信要素において、前記送信情報が正常に受信されたか否かを確認すると共に、ネットワークを中継されて回帰した前記送信情報のNACKカウンタに基づいて、送信先である受信要素のいずれかにおいて、前記送信情報が正常に受信されなかったことを確認することにより、前記送信先の受信要素の全てにおいて、送信情報が正常に受信されたか否かを判定可能であり、さらに、ネットワークを中継されて回帰した前記送信情報のACKカウンタおよびNACKカウンタの合計値と、予め把握している前記送信先の受信要素の数とに基づいて、ネットワークの要素の構成の変化を検出可能であることを特徴とするリング型ネットワークの受信確認方法。 - 前記送信元の端末装置は、ネットワークを中継されて回帰した前記送信情報のACKカウンタおよびNACKカウンタの合計値を、ネットワークにおける前記送信情報の送信先となる受信要素の数として新たに把握することを特徴とする請求項1記載のリング型ネットワークの受信確認方法。
- ネットワークに接続された複数の端末装置が、その接続位置に応じた一定順序にしたがって送信情報を中継することにより、各端末装置間における通信を行うリング型ネットワークの端末装置であって、
送信先の受信要素を指定する指定情報と、送信先の受信要素に係る端末装置によって加算可能なACKカウンタおよびNACKカウンタとを含む送信情報を送信する送信手段と、
ネットワークを中継されて回帰した前記送信情報のACKカウンタと、予め把握している前記送信先の受信要素の数とに基づいて、送信先である全ての受信要素において、前記送信情報が正常に受信されたか否かを確認すると共に、ネットワークを中継されて回帰した前記送信情報のNACKカウンタに基づいて、送信先である受信要素のいずれかにおいて、前記送信情報が正常に受信されなかったことを確認することにより、該送信情報が前記送信先の受信要素の全てにおいて正常に受信されたか否かを判定する判定手段と、
ネットワークを中継されて回帰した前記送信情報のACKカウンタおよびNACKカウンタの合計値と、予め把握している前記送信先の受信要素の数とに基づいて、ネットワークの要素の構成の変化を検出する検出手段と、
を備えることを特徴とする端末装置。 - ネットワークを中継されて回帰した前記送信情報のACKカウンタおよびNACKカウンタの合計値を、ネットワークにおける前記送信情報の送信先となる受信要素の数として新たに把握することを特徴とする請求項3記載の端末装置。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001367538A JP3780921B2 (ja) | 2001-11-30 | 2001-11-30 | リング型ネットワークの受信確認方法および端末装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001367538A JP3780921B2 (ja) | 2001-11-30 | 2001-11-30 | リング型ネットワークの受信確認方法および端末装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003169064A JP2003169064A (ja) | 2003-06-13 |
| JP3780921B2 true JP3780921B2 (ja) | 2006-05-31 |
Family
ID=19177274
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001367538A Expired - Lifetime JP3780921B2 (ja) | 2001-11-30 | 2001-11-30 | リング型ネットワークの受信確認方法および端末装置 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3780921B2 (ja) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20070124641A1 (en) * | 2005-11-10 | 2007-05-31 | Chih-Hao Yeh | Method of improving network layer performance for a wireless station |
| JP5713094B2 (ja) * | 2013-06-06 | 2015-05-07 | 株式会社豊田自動織機 | 電池監視装置 |
-
2001
- 2001-11-30 JP JP2001367538A patent/JP3780921B2/ja not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| JP2003169064A (ja) | 2003-06-13 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP0409578B1 (en) | Data communication method and system with cyclic sequence of acknowledgements | |
| CN101069378B (zh) | 数据单元发送器和数据单元中继装置 | |
| US5974028A (en) | System and method for improving transport protocol performance in communication networks having lossy links | |
| US20080195912A1 (en) | Method of communicatoin | |
| US9225473B2 (en) | System and method for improving transport protocol performance in communication networks having lossy links | |
| JP2880290B2 (ja) | ネットワークトラフィック管理 | |
| EP2001180B1 (en) | One-way message notification with out-of-order packet delivery | |
| EP2978171B1 (en) | Communication method, communication device, and communication program | |
| JP2006287981A (ja) | 網通信システムにおいてデータパケットを伝送するための誤り訂正通信方法 | |
| JPH07312597A (ja) | 無線ローカルエリアネットワーク・システム | |
| EP2001152B1 (en) | Reliable message transport network | |
| US8184650B2 (en) | Filtering of redundant frames in a network node | |
| US6925096B2 (en) | Method and apparatus for managing traffic flows | |
| US7496038B2 (en) | Method for faster detection and retransmission of lost TCP segments | |
| EP1944916A1 (en) | Method for acknowledgement of messages in a star network | |
| EP2525527B1 (en) | Network relay device and network relay method | |
| JP3780921B2 (ja) | リング型ネットワークの受信確認方法および端末装置 | |
| US6954890B2 (en) | System and method for increasing capacity in a noisy communication environment | |
| CN102082696B (zh) | 一种冗余网络系统以及基于该系统的报文发送方法 | |
| JP2003304273A (ja) | パケット中継装置、パケット中継プログラム、およびパケット中継方法 | |
| WO2012103724A1 (zh) | 一种进程组和进程组中的异常组成员离开的方法 | |
| JP5433262B2 (ja) | 通信システム | |
| JPH0482436A (ja) | パケット送信制御方式 | |
| JPH11252134A (ja) | 同報通信システム | |
| KR100683417B1 (ko) | 무선 네트워크에서의 패킷 중계 장치 및 중계 방법 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| RD03 | Notification of appointment of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7423 Effective date: 20040210 |
|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20040217 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040517 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20051111 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20051122 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060120 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20060214 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060227 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 3780921 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090317 Year of fee payment: 3 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313111 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090317 Year of fee payment: 3 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090317 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100317 Year of fee payment: 4 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110317 Year of fee payment: 5 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110317 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120317 Year of fee payment: 6 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120317 Year of fee payment: 6 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313111 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120317 Year of fee payment: 6 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120317 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130317 Year of fee payment: 7 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130317 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140317 Year of fee payment: 8 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| EXPY | Cancellation because of completion of term |