JP4396639B2 - 路車間通信システム、基地局装置、及び移動局装置 - Google Patents
路車間通信システム、基地局装置、及び移動局装置 Download PDFInfo
- Publication number
- JP4396639B2 JP4396639B2 JP2005514730A JP2005514730A JP4396639B2 JP 4396639 B2 JP4396639 B2 JP 4396639B2 JP 2005514730 A JP2005514730 A JP 2005514730A JP 2005514730 A JP2005514730 A JP 2005514730A JP 4396639 B2 JP4396639 B2 JP 4396639B2
- Authority
- JP
- Japan
- Prior art keywords
- data
- transaction
- application
- port
- transmission
- 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.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/40—Support for services or applications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
Description
この発明は、道路上を走行する移動局と、道路上に設置された基地局装置との間で行われる路車間通信を利用して、前記移動局に対して応用サービスを提供する路車間通信システムに関するものである。また、このような路車間通信システムに使用される基地局装置及び移動局装置に関するものである。
従来の路車間通信システムの一例としては、社団法人 電波産業会にて定められた標準規格「狭域通信（ＤＳＲＣ）システム標準規格 ＡＲＩＢＳＴＤ−Ｔ７５」（平成１３年９月６日 策定）が知られている。この標準規格は通信ゾーンを限定したスポット通信による路車間通信方式を定めたものであり、アプリケーション毎にＡＩＤとよばれる識別子を用いることでマルチアプリケーションに対応している。
しかしながら、前記従来技術では、常に基地局がマスター、移動局がスレーブであり、マスター・スレーブ型のアプリケーションしか実現できず、移動局側から通信を起動したり、移動局と基地局が対等に通信するようなアプリケーションには適用できなかった。また、このＡＩＤと呼ばれる識別子は３２個しか規定できないため、アプリケーションの種類が増大した場合に対応が困難であるという問題もあった。さらに、一度に送受信可能なデータサイズが、数百バイト程度と小さく、数十キロバイト以上の大容量のデータ通信を必要とするアプリケーションに利用することは困難であった。
しかしながら、前記従来技術では、常に基地局がマスター、移動局がスレーブであり、マスター・スレーブ型のアプリケーションしか実現できず、移動局側から通信を起動したり、移動局と基地局が対等に通信するようなアプリケーションには適用できなかった。また、このＡＩＤと呼ばれる識別子は３２個しか規定できないため、アプリケーションの種類が増大した場合に対応が困難であるという問題もあった。さらに、一度に送受信可能なデータサイズが、数百バイト程度と小さく、数十キロバイト以上の大容量のデータ通信を必要とするアプリケーションに利用することは困難であった。
これらの課題を解決するための手法の一例として、前記標準規格（狭域通信（ＤＳＲＣ）システム標準規格 ＡＲＩＢ ＳＴＤ−Ｔ７５）上に、双方向に通信可能なプロトコルである拡張通信制御プロトコル（ＡＳＬ−ＥＬＣＰ）を配置し、基地局が定期的に移動局からの通信の有無をポーリングすることで、移動局からの通信を実現している。さらに、前記拡張通信制御プロトコル（ＡＳＬ−ＥＬＣＰ）にアクセス点識別子と呼ばれる識別子を定義し、前記標準規格（狭域通信（ＤＳＲＣ）システム標準規格 ＡＲＩＢ ＳＴＤ−Ｔ７５）と前記拡張通信制御プロトコル（ＡＳＬ−ＥＬＣＰ）とからなる階層上に複数のプロトコルの動作を可能とし、この複数のプロトコルの一つとしてインターネットプロトコルを利用することで、マルチアプリケーションへの対応を実現している。また、バルク転送とよばれる分割・組立機構を有することで、最大で５０キロバイト程度のメッセージの送受信が可能である。さらに、同報通信においては、同一データを複数回連続して送信することで通信の誤り率を小さく抑えることを実現している（例えば、非特許文献１参照。）。
情報処理学会ＩＴＳ研究会「ＤＳＲＣ（ＡＲＩＢ ＳＴＤ−Ｔ７５準拠）システムの実装及び評価」（２００２−ＩＴＳ−１０−１０）
しかしながら、前記従来技術においては、マルチアプリケーションを実現するために、前記拡張通信制御プロトコル（ＡＳＬ−ＥＬＣＰ）上で、ネットワーク型のプロトコルであるインターネットプロトコルを利用するため、ＩＰアドレスの割当やＴＣＰのセットアップに要する時間などの初期接続に係わるオーバヘッドの問題から、走行中のアプリケーションに対して適用が困難であるという問題があった。また、同様の問題により、走行中に送信するデータサイズが１００キロバイトを超えるようなアプリケーションへの適用は依然として困難であった。さらに前記バルク転送機能では、データを単に分割しているだけなので、分割データの再送を下位レイヤであるＤＳＲＣに依存しており、ＤＳＲＣ通信以外の理由で欠落したデータへの対応に問題があった。また、シャドーイングや電波が弱いなど、所定の時間通信不可能な領域では、再送した個々のデータや連送したデータすべてが欠落する可能性があるため、誤り率を改善できないという問題があった。
本発明はかかる問題点を解決するためになされたもので、道路上を走行及び停止する移動局と、前記道路上に設置された基地局装置との間で行われる路車間通信を利用して、前記移動局に対して応用サービスを提供する路車間通信システムにおいて、走行中においても様々なアプリケーションを実行可能とするため、複数のアプリケーション間のデータ転送のためのメカニズムと、１００キロバイトを超えるような大容量のデータ送信のメカニズムと、一定時間通信できない場合においても、通信誤り率を改善可能なメカニズムとを備えた非ネットワーク型の通信プロトコルを提供するものである。
この発明に係る路車間通信システムは、道路上を走行する移動局と、前記道路上に設置された基地局装置との間で行われる路車間の狭域通信を利用して、前記移動局に対して応用サービスを提供する路車間通信システムにおいて、前記移動局及び前記基地局装置は、各々、複数のアプリケーション間のデータ転送のためのメカニズムを提供する転送サービス処理部、及び未達データの再送信機構と、メッセージ単位のデータ送受信機構と、前記メッセージの分割・組立機構とを有し、単方向のデータ送信とリクエスト・レスポンス型のトランザクションサービスを提供するトランザクション管理部を備え、前記転送サービス処理部は、アプリケーション識別子であるポート番号を用いて送信元および送信先のアプリケーションを識別してデータの転送先を決定し、前記トランザクション管理部は、前記メッセージを複数のデータに分割し、分割された各データにトランザクションの単位を識別するために前記アプリケーションから送信毎に指定された識別子と順序番号を付与し、受信側で前記アプリケーションから指定された識別子が同一の各データを前記順序番号をもとに組み立て順を判別してもとのメッセージへ組み立てるものである。
また、この発明に係る基地局装置は、道路上に設置され、前記道路上を走行する移動局に対して、路車間の狭域通信を利用して応用サービスを提供する基地局装置において、複数のアプリケーション間のデータ転送のためのメカニズムを提供する転送サービス処理部、及び未達データの再送信機構と、メッセージ単位のデータ送受信機構と、前記メッセージの分割・組立機構とを有し、単方向のデータ送信とリクエスト・レスポンス型のトランザクションサービスを提供するトランザクション管理部を備え、前記転送サービス処理部は、アプリケーション識別子であるポート番号を用いて送信元および送信先のアプリケーションを識別してデータの転送先を決定し、前記トランザクション管理部は、前記メッセージを複数のデータに分割し、分割された各データにトランザクションの単位を識別するために前記アプリケーションから送信毎に指定された識別子と順序番号を付与し、受信メッセージに対しては前記アプリケーションから指定された識別子が同一の各データを前記順序番号をもとに組み立て順を判別してもとのメッセージへ組み立てるものである。
また、この発明に係る移動局装置は、走行する道路上に設置された基地局装置より、路車間の狭域通信を利用して応用サービスを受け取る移動局装置において、複数のアプリケーション間のデータ転送のためのメカニズムを提供する転送サービス処理部、及び未達データの再送信機構と、メッセージ単位のデータ送受信機構と、前記メッセージの分割・組立機構とを有し、単方向のデータ送信とリクエスト・レスポンス型のトランザクションサービスを提供するトランザクション管理部を備え、前記転送サービス処理部は、アプリケーション識別子であるポート番号を用いて送信元および送信先のアプリケーションを識別してデータの転送先を決定し、前記トランザクション管理部は、前記メッセージを複数のデータに分割し、分割された各データにトランザクションの単位を識別するために前記アプリケーションから送信毎に指定された識別子と順序番号を付与し、受信メッセージに対しては前記アプリケーションから指定された識別子が同一の各データを前記順序番号をもとに組み立て順を判別してもとのメッセージへ組み立てるものである。
この発明に係る路車間通信システムは、基地局装置および移動局内の双方のローカルアプリケーションが非ネットワーク型のプロトコルを利用して通信を行うシステムであり、前記非ネットワーク型のプロトコルを、転送サービス処理部とトランザクション管理部とで構成したので、走行中においても様々なアプリケーションが実行可能となる。また、一定時間通信できない場合においても、通信誤り率が改善可能となる。
また、転送サービス処理部とトランザクション管理部とをそれぞれ独立した構成としたため、最も単純なアプリケーションでは転送サービス処理部を直接使用することで実現が可能であり、高速接続性、低オーバヘッドといった走行中の路車間通信に必要な要件を満たすことができる。さらに、プロトコルを拡張する際には拡張箇所をトランザクション管理部に局所化でき、拡張を容易に行うことができる。
トランザクション管理部においては、アプリケーションから指定された識別子（送信データ識別子）により送信データの単位を識別する。またこのプロトコルは、送信データ単位が下位層のプロトコルで一度に送信可能なサイズよりも大きい場合には、送信可能なサイズに分割し、順序番号を付けて送信し、受信側でその順序番号を元に組み立てる機能を有する。このとき、個別通信の場合には、最終データの受信時に未受信のデータの順序番号を送信側に通知することで、送信側は未受信のデータのみを再送信する。これにより通信誤り率が改善できる。
また、個別通信・同報通信の場合には、送信元のアプリケーション識別子（送信元ポート番号）とそのアプリケーションが指定した送信データ識別子の組が同一の場合には、受信側で既受信の同一識別子のデータと同一のデータとして扱う。これにより送信側は任意のタイミングでデータの再送信が可能となり、一定時間通信できない場合においても、通信誤り率を改善できる。
また、個別通信・同報通信の場合には、送信元のアプリケーション識別子（送信元ポート番号）とそのアプリケーションが指定した送信データ識別子の組が同一の場合には、受信側で既受信の同一識別子のデータと同一のデータとして扱う。これにより送信側は任意のタイミングでデータの再送信が可能となり、一定時間通信できない場合においても、通信誤り率を改善できる。
実施の形態１．
図１はこの発明の実施の形態１による路車間通信システムにおけるコネクション識別の概念を示す図である。また、図３は本発明の実施の形態１による路車間通信システムにおけるデータの流れの概要を示す図である。図１、図３を用いて、基地局装置と移動局との基本構成を説明する。
基地局装置及び移動局において使用する通信プロトコルは、狭域通信（ＤＳＲＣ）プロトコル（ＡＲＩＢ ＳＴＤ−Ｔ７５）と、双方向に通信可能なプロトコルである拡張通信制御プロトコル（ＡＳＬ−ＥＬＣＰ）と、転送サービス処理部（ローカルポート制御プロトコル（ＬＰＣＰ：Ｌｏｃａｌ Ｐｏｒｔ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ））と、トランザクション管理部（ローカルポートプロトコル（ＬＰＰ：Ｌｏｃａｌ Ｐｏｒｔ Ｐｒｏｔｏｃｏｌ））とからなる階層構造をなしており、この通信プロトコルの上で複数のアプリケーションが実行される。
転送サービス処理部は、狭域通信（ＤＳＲＣ）プロトコル（ＡＲＩＢ ＳＴＤ−Ｔ７５）および拡張通信制御プロトコル（ＡＳＬ−ＥＬＣＰ）上でアプリケーションの多重化を実現するための制御プロトコルであり、マルチアプリケーションを実現するための最小限の機能を有している。
一方、トランザクション管理部は前記転送サービス処理部とアプリケーションの間に介在し、転送サービス処理部の通信サービスを拡張する通信プロトコルであり、大容量データ通信などより高度な通信サービスをアプリケーションに対して提供する。
以下ではこの転送サービス処理部とトランザクション管理部について詳細に説明する。
図１はこの発明の実施の形態１による路車間通信システムにおけるコネクション識別の概念を示す図である。また、図３は本発明の実施の形態１による路車間通信システムにおけるデータの流れの概要を示す図である。図１、図３を用いて、基地局装置と移動局との基本構成を説明する。
基地局装置及び移動局において使用する通信プロトコルは、狭域通信（ＤＳＲＣ）プロトコル（ＡＲＩＢ ＳＴＤ−Ｔ７５）と、双方向に通信可能なプロトコルである拡張通信制御プロトコル（ＡＳＬ−ＥＬＣＰ）と、転送サービス処理部（ローカルポート制御プロトコル（ＬＰＣＰ：Ｌｏｃａｌ Ｐｏｒｔ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ））と、トランザクション管理部（ローカルポートプロトコル（ＬＰＰ：Ｌｏｃａｌ Ｐｏｒｔ Ｐｒｏｔｏｃｏｌ））とからなる階層構造をなしており、この通信プロトコルの上で複数のアプリケーションが実行される。
転送サービス処理部は、狭域通信（ＤＳＲＣ）プロトコル（ＡＲＩＢ ＳＴＤ−Ｔ７５）および拡張通信制御プロトコル（ＡＳＬ−ＥＬＣＰ）上でアプリケーションの多重化を実現するための制御プロトコルであり、マルチアプリケーションを実現するための最小限の機能を有している。
一方、トランザクション管理部は前記転送サービス処理部とアプリケーションの間に介在し、転送サービス処理部の通信サービスを拡張する通信プロトコルであり、大容量データ通信などより高度な通信サービスをアプリケーションに対して提供する。
以下ではこの転送サービス処理部とトランザクション管理部について詳細に説明する。
１． 転送サービス処理部（ローカルポート制御プロトコル）
１．１ 概要
以下に転送サービス処理部（ローカルポート制御プロトコル）について詳細に説明する。ローカルポート制御プロトコル（ＬＰＣＰ）は、非ネットワーク系アプリケーションに通信手段を提供するために、アプリケーション等の上位プロトコルに対してデータ転送のためのデータ転送サービスと、管理制御のための管理サービスを提供する制御プロトコルである。
転送サービス処理部では、ローカルポート番号とよぶ識別子を用いて、送信元および送信先のアプリケーションを識別する。また上位層であるアプリケーションやトランザクション管理部などの上位層プロトコルに対してデータ転送と管理サービスのためのサービスプリミティブ（インタフェース）を提供する。さらに内部データとしてデータ転送サービスおよび管理サービスを実現するための制御情報を有するとともに、路車の転送サービス処理部間でやりとりされるデータ（ＰＤＵ）にも制御情報を付加することで各種サービスを実現している。
１．１ 概要
以下に転送サービス処理部（ローカルポート制御プロトコル）について詳細に説明する。ローカルポート制御プロトコル（ＬＰＣＰ）は、非ネットワーク系アプリケーションに通信手段を提供するために、アプリケーション等の上位プロトコルに対してデータ転送のためのデータ転送サービスと、管理制御のための管理サービスを提供する制御プロトコルである。
転送サービス処理部では、ローカルポート番号とよぶ識別子を用いて、送信元および送信先のアプリケーションを識別する。また上位層であるアプリケーションやトランザクション管理部などの上位層プロトコルに対してデータ転送と管理サービスのためのサービスプリミティブ（インタフェース）を提供する。さらに内部データとしてデータ転送サービスおよび管理サービスを実現するための制御情報を有するとともに、路車の転送サービス処理部間でやりとりされるデータ（ＰＤＵ）にも制御情報を付加することで各種サービスを実現している。
１．２ ローカルポート番号
１．２．１ アクセス点識別
発信元となるアプリケーションから対向するアプリケーションに対して正しくデータを送り届けるために、ローカルポート制御プロトコル（ＬＰＣＰ）では図１に示すようにＬＰＣＰ上のアプリケーションを識別するためのアクセス点としてローカルポート番号を設け、車両ＩＤ（リンクアドレス等）とローカルポート番号の組で、それぞれのアプリケーションに対して相手先との接続を識別する。
１．２．１ アクセス点識別
発信元となるアプリケーションから対向するアプリケーションに対して正しくデータを送り届けるために、ローカルポート制御プロトコル（ＬＰＣＰ）では図１に示すようにＬＰＣＰ上のアプリケーションを識別するためのアクセス点としてローカルポート番号を設け、車両ＩＤ（リンクアドレス等）とローカルポート番号の組で、それぞれのアプリケーションに対して相手先との接続を識別する。
１．２．２ ローカルポート番号の分類
図２はローカルポート番号の分類の例を示す図である。ローカルポート番号は非ネットワーク系アプリケーションにおけるコネクション識別子として使用され、ローカルポート番号を以下のように規定する。０〜０ｘ０ＦＦＦを番号予約ポート、０ｘ１０００〜０ｘＦＦＦＦを任意ポートとする。このようにポート番号を規定することで、６５５３６種類のポート番号を規定でき、今後のアプリケーション種類の増大にも十分に対応が可能となる。
図２はローカルポート番号の分類の例を示す図である。ローカルポート番号は非ネットワーク系アプリケーションにおけるコネクション識別子として使用され、ローカルポート番号を以下のように規定する。０〜０ｘ０ＦＦＦを番号予約ポート、０ｘ１０００〜０ｘＦＦＦＦを任意ポートとする。このようにポート番号を規定することで、６５５３６種類のポート番号を規定でき、今後のアプリケーション種類の増大にも十分に対応が可能となる。
１．２．３ アプリケーションとローカルポート番号の関係
アプリケーションと前節で規定されたローカルポート番号との関係を説明する。
アプリケーションの形態は、クライアント／サーバモデルおよびピアツーピアモデルを前提とする。従って、クライアント／サーバモデルにおいては大域的に一意であるサーバプロセスのポートは番号予約ポート、局内で一意であるクライアントプロセスのポートは任意ポートを利用することを基本とする。またピアツーピアモデルにおいては双方のプロセスが番号予約ポートを利用することを基本とする。独自アプリの場合は、任意ポートをサーバ・クライアント共に使用することも可能である。
アプリケーションと前節で規定されたローカルポート番号との関係を説明する。
アプリケーションの形態は、クライアント／サーバモデルおよびピアツーピアモデルを前提とする。従って、クライアント／サーバモデルにおいては大域的に一意であるサーバプロセスのポートは番号予約ポート、局内で一意であるクライアントプロセスのポートは任意ポートを利用することを基本とする。またピアツーピアモデルにおいては双方のプロセスが番号予約ポートを利用することを基本とする。独自アプリの場合は、任意ポートをサーバ・クライアント共に使用することも可能である。
１．２．４ ローカルポート番号の番号設定
ローカルポート番号の番号設定については、以下の規則に従う。
（１）予約番号については、グローバルに重複のない付番を行うこと。
（２）アプリケーションは複数の受信ポートを持つことができる。
（３）基地局、移動局を単位とし、各アプリケーションは、局内で重複の無いように受信ポート番号を使用すること。
（４）送信元の特定が不要な場合や送信元が既知の場合には、送信元ポートを省略することができる。
ローカルポート番号の番号設定については、以下の規則に従う。
（１）予約番号については、グローバルに重複のない付番を行うこと。
（２）アプリケーションは複数の受信ポートを持つことができる。
（３）基地局、移動局を単位とし、各アプリケーションは、局内で重複の無いように受信ポート番号を使用すること。
（４）送信元の特定が不要な場合や送信元が既知の場合には、送信元ポートを省略することができる。
１．３ ＬＰＣＰの機能
次にＬＰＣＰの機能について詳細に説明する。
１．３．１ データ転送機能データグラム伝送サービス
図３はデータグラム伝送サービスの例を示す図である。ＤＳＲＣ−ＡＳＬにおけるローカルポート系アプリケーションの構成は、ＬＰＣＰ上に複数のアプリケーションが存在する階層構造となっており、ＬＰＣＰはデータの転送先アプリケーションの識別を行う必要がある。
そこで、ＬＰＣＰに、送信元及び送信先ポート番号を付与し、これによりデータの転送先を決定する。
次にＬＰＣＰの機能について詳細に説明する。
１．３．１ データ転送機能データグラム伝送サービス
図３はデータグラム伝送サービスの例を示す図である。ＤＳＲＣ−ＡＳＬにおけるローカルポート系アプリケーションの構成は、ＬＰＣＰ上に複数のアプリケーションが存在する階層構造となっており、ＬＰＣＰはデータの転送先アプリケーションの識別を行う必要がある。
そこで、ＬＰＣＰに、送信元及び送信先ポート番号を付与し、これによりデータの転送先を決定する。
なお、ＬＰＣＰが提供する通信サービスは、高速、低オーバヘッドなコネクションレス型のデータグラム伝送サービスであり、ＬＰＣＰとアプリケーション（上位層プロトコル）間での具体的な動作は、以下の通りである。
１：データを受け取る受信ポートをアプリケーション（上位層プロトコル）がＬＰＣＰに依頼して新しく作成し、
２：その受信ポートを通して、ＬＰＣＰから車両ＩＤ（リンクアドレス等）、送信元ポート番号および受信データを受け取り、
また逆に
３：アプリケーション（上位層プロトコル）は送信データ、リンクアドレスおよび送受信ポート番号をＬＰＣＰに渡し、ＬＰＣＰがその情報からＬＰＣＰデータグラムを生成して相手へ送信する。
１：データを受け取る受信ポートをアプリケーション（上位層プロトコル）がＬＰＣＰに依頼して新しく作成し、
２：その受信ポートを通して、ＬＰＣＰから車両ＩＤ（リンクアドレス等）、送信元ポート番号および受信データを受け取り、
また逆に
３：アプリケーション（上位層プロトコル）は送信データ、リンクアドレスおよび送受信ポート番号をＬＰＣＰに渡し、ＬＰＣＰがその情報からＬＰＣＰデータグラムを生成して相手へ送信する。
１．３．２ 管理サービス
管理サービス処理では、以下のサービスをアプリケーションや上位層プロトコルに対して提供する。
・ＡＳＬ−ＥＬＣＰ（拡張通信制御プロトコル）の管理サービスで通知されるエラーやイベント（通信の接続、非接続の通知等）を、自局のアプリケーションに対して透過的に通知するサービス。
・ＬＰＣＰ内で発生したエラーやイベントを相手局や自局のアプリケーションに対して通知するサービス。
管理サービス処理では、以下のサービスをアプリケーションや上位層プロトコルに対して提供する。
・ＡＳＬ−ＥＬＣＰ（拡張通信制御プロトコル）の管理サービスで通知されるエラーやイベント（通信の接続、非接続の通知等）を、自局のアプリケーションに対して透過的に通知するサービス。
・ＬＰＣＰ内で発生したエラーやイベントを相手局や自局のアプリケーションに対して通知するサービス。
ＬＰＣＰとアプリケーション（または上位層プロトコル）間での具体的な動作は、以下の通りである。
１．イベントを受け取るポートをアプリケーション（または上位層プロトコル）がＬＰＣＰに依頼して新しく作成し、
２．そのポートを通して、ＬＰＣＰからリンクアドレス、状態識別子、イベント付加情報を受け取る。
１．イベントを受け取るポートをアプリケーション（または上位層プロトコル）がＬＰＣＰに依頼して新しく作成し、
２．そのポートを通して、ＬＰＣＰからリンクアドレス、状態識別子、イベント付加情報を受け取る。
１．４ アプリケーションとのインタフェース
次に、ＬＰＣＰとアプリケーションとのインタフェースについて説明する。
１．４．１ 記法の説明
本発明で規定されるプリミティブ種別の一覧を図４に、プリミティブの定義テーブルで用いられるパラメータ種別の一覧を図５に示す。
１．４．２ データ転送サービスインタフェース
図６にデータ転送サービスの論理関係を示す。
ローカルポート制御プロトコルはデータ転送サービスとして、アプリケーション（または上位層プロトコル）に対して、以下の１種類のプリミティブを用意する。
１．４．２．１ 転送プリミティブ（ＴｒａｎｓｆｅｒＤａｔａ）
本プリミティブはＤＳＲＣ−ＡＳＬのＥＬＣＰと非ＩＰアプリケーションや上位層プロトコルとの間でデータ転送を行うためのプリミティブである。図７に転送プリミティブの定義を示す。図７において、
Ｌｉｎｋ Ａｄｄｒｅｓｓ：本送信で使用するＤＳＲＣのＬＩＤまたはＬＩＤと１対１でマッピング可能なＩＤ
Ｓｏｕｒｃｅ Ｐｏｒｔ：送信元アプリケーションのポート番号
Ｄｅｓｔｉｎａｔｉｏｎ Ｐｏｒｔ：送信先アプリケーションのポート番号
Ｕｓｅｒ Ｄａｔａ：伝送データ本体
Ｕｓｅｒ Ｄａｔａ Ｓｉｚｅ：伝送データサイズ
次に、ＬＰＣＰとアプリケーションとのインタフェースについて説明する。
１．４．１ 記法の説明
本発明で規定されるプリミティブ種別の一覧を図４に、プリミティブの定義テーブルで用いられるパラメータ種別の一覧を図５に示す。
１．４．２ データ転送サービスインタフェース
図６にデータ転送サービスの論理関係を示す。
ローカルポート制御プロトコルはデータ転送サービスとして、アプリケーション（または上位層プロトコル）に対して、以下の１種類のプリミティブを用意する。
１．４．２．１ 転送プリミティブ（ＴｒａｎｓｆｅｒＤａｔａ）
本プリミティブはＤＳＲＣ−ＡＳＬのＥＬＣＰと非ＩＰアプリケーションや上位層プロトコルとの間でデータ転送を行うためのプリミティブである。図７に転送プリミティブの定義を示す。図７において、
Ｌｉｎｋ Ａｄｄｒｅｓｓ：本送信で使用するＤＳＲＣのＬＩＤまたはＬＩＤと１対１でマッピング可能なＩＤ
Ｓｏｕｒｃｅ Ｐｏｒｔ：送信元アプリケーションのポート番号
Ｄｅｓｔｉｎａｔｉｏｎ Ｐｏｒｔ：送信先アプリケーションのポート番号
Ｕｓｅｒ Ｄａｔａ：伝送データ本体
Ｕｓｅｒ Ｄａｔａ Ｓｉｚｅ：伝送データサイズ
１．４．３ 管理サービスインタフェース
図８に管理サービスインタフェースの論理関係を示す。ローカルポート制御プロトコルは管理サービスとして、アプリケーション（または上位層プロトコル）に対して、以下の３種類のプリミティブを用意する。
・Ｅｖｅｎｔ Ｒｅｐｏｒｔ（イベント通知プリミティブ）
・Ｏｐｅｎ Ｐｏｒｔ（ポート生成プリミティブ）
・Ｃｌｏｓｅ Ｐｏｒｔ（ポート破棄プリミティブ）
図８に管理サービスインタフェースの論理関係を示す。ローカルポート制御プロトコルは管理サービスとして、アプリケーション（または上位層プロトコル）に対して、以下の３種類のプリミティブを用意する。
・Ｅｖｅｎｔ Ｒｅｐｏｒｔ（イベント通知プリミティブ）
・Ｏｐｅｎ Ｐｏｒｔ（ポート生成プリミティブ）
・Ｃｌｏｓｅ Ｐｏｒｔ（ポート破棄プリミティブ）
１．４．３．１ イベント通知プリミティブ（Ｅｖｅｎｔ Ｒｅｐｏｒｔ）
本プリミティブは非ＩＰアプリケーションや上位層プロトコルに対してイベントの発生やエラーを報告するためのプリミティブである。ＡＳＬ−ＥＬＣＰの管理サービスで通知されたイベントをローカルポートプロトコルに対して透過的に転送するものと、相手局の管理サービスからの通知を透過的に転送するものの２種類がある。図９にイベント通知プリミティブの定義を示す。図９において、
Ｌｉｎｋ Ａｄｄｒｅｓｓ：通知相手が使用する（中の）ＬＩＤを指定する。
Ｅｖｅｎｔ Ｃｏｄｅ：イベントコードとして状態識別子（図１７）を格納する。
Ｅｘｔｅｎｔｉｏｎ Ｐａｒａｍｅｔｅｒ：各イベントコードに対応するイベント付加情報。
本プリミティブは非ＩＰアプリケーションや上位層プロトコルに対してイベントの発生やエラーを報告するためのプリミティブである。ＡＳＬ−ＥＬＣＰの管理サービスで通知されたイベントをローカルポートプロトコルに対して透過的に転送するものと、相手局の管理サービスからの通知を透過的に転送するものの２種類がある。図９にイベント通知プリミティブの定義を示す。図９において、
Ｌｉｎｋ Ａｄｄｒｅｓｓ：通知相手が使用する（中の）ＬＩＤを指定する。
Ｅｖｅｎｔ Ｃｏｄｅ：イベントコードとして状態識別子（図１７）を格納する。
Ｅｘｔｅｎｔｉｏｎ Ｐａｒａｍｅｔｅｒ：各イベントコードに対応するイベント付加情報。
１．４．３．２ ポート生成プリミティブ（Ｏｐｅｎ Ｐｏｒｔ）
本プリミティブはＬＰＣＰに対して、データおよびイベントの受信ポートを生成するためのプリミティブである。図１０にポート生成プリミティブの定義を示す。図１０において、
Ｐｏｒｔ：通知を要求するポート番号
Ｔｙｐｅ：通知が必要なプリミティブ種別の指定
１：ＴｒａｎｓｆｅｒＤａｔａ
２：Ｅｖｅｎｔ Ｒｅｐｏｒｔ
このパラメータが省略された場合は、全てのプリミティブ通知を要求する。
Ｃｏｄｅ：Ｔｙｐｅ＝２（Ｅｖｅｎｔ Ｒｅｐｏｒｔ）の場合に通知が必要なイベントの種別
このパラメータが省略された場合は全てのイベントの通知を要求する。
イベント種別の詳細は図１７を参照。
本プリミティブはＬＰＣＰに対して、データおよびイベントの受信ポートを生成するためのプリミティブである。図１０にポート生成プリミティブの定義を示す。図１０において、
Ｐｏｒｔ：通知を要求するポート番号
Ｔｙｐｅ：通知が必要なプリミティブ種別の指定
１：ＴｒａｎｓｆｅｒＤａｔａ
２：Ｅｖｅｎｔ Ｒｅｐｏｒｔ
このパラメータが省略された場合は、全てのプリミティブ通知を要求する。
Ｃｏｄｅ：Ｔｙｐｅ＝２（Ｅｖｅｎｔ Ｒｅｐｏｒｔ）の場合に通知が必要なイベントの種別
このパラメータが省略された場合は全てのイベントの通知を要求する。
イベント種別の詳細は図１７を参照。
１．４．３．３ ポート破棄プリミティブ（Ｃｌｏｓｅ Ｐｏｒｔ）
本プリミティブはポート生成プリミティブで生成した受信ポートを破棄するためのプリミティブである。
図１１はポート破棄プリミティブの定義を示す図である。図１１において、
Ｐｏｒｔ：破棄するポート番号
本プリミティブはポート生成プリミティブで生成した受信ポートを破棄するためのプリミティブである。
図１１はポート破棄プリミティブの定義を示す図である。図１１において、
Ｐｏｒｔ：破棄するポート番号
１．５ 制御情報
１．５．１ 概要
次に、前記管理サービスにおいて用いるＬＰＣＰの制御情報について説明する。
ＬＰＣＰの管理サービスでは、ＬＰＣＰで使用する通信パラメータを管理する。
ＬＰＣＰの管理サービスでは以下の情報を管理する。
（１）受信可能ポートリスト
（２）通信制御情報
１．５．１ 概要
次に、前記管理サービスにおいて用いるＬＰＣＰの制御情報について説明する。
ＬＰＣＰの管理サービスでは、ＬＰＣＰで使用する通信パラメータを管理する。
ＬＰＣＰの管理サービスでは以下の情報を管理する。
（１）受信可能ポートリスト
（２）通信制御情報
１．５．２．１ 受信可能ポートリスト
基地局／移動局が受信可能なポート番号の情報で、受信ポート生成プリミティブ受信時にリストに追加し、受信ポート破棄プリミティブ受信時にリストから削除する。
受信可能ポートリストの構成例を図１２に示す。
１．５．２．２ 通信制御情報
基地局／移動局において通信中のアプリケーションに関する情報で、ＡＳＬ−ＥＬＣＰの通信制御管理からのＤＳＲＣ接続通知の受信時にリストに追加し、ＤＳＲＣ切断通知の受信時にリストから削除する。通信制御情報の構成例を図１３に示す。
略語解説：
ＬＩＤ：リンクアドレス
Ｐｏｒｔ Ｎｏ：受信可能ポート番号
Ｐｒｉｍｉｔｉｖｅ Ｔｙｐｅ ：受信するプリミティブ種別
Ｅｖｅｎｔ Ｃｏｄｅ：受信するイベントコードの種別
Ｅｑｕｉｐｍｅｎｔ ＩＤ：車載器固有情報
基地局／移動局が受信可能なポート番号の情報で、受信ポート生成プリミティブ受信時にリストに追加し、受信ポート破棄プリミティブ受信時にリストから削除する。
受信可能ポートリストの構成例を図１２に示す。
１．５．２．２ 通信制御情報
基地局／移動局において通信中のアプリケーションに関する情報で、ＡＳＬ−ＥＬＣＰの通信制御管理からのＤＳＲＣ接続通知の受信時にリストに追加し、ＤＳＲＣ切断通知の受信時にリストから削除する。通信制御情報の構成例を図１３に示す。
略語解説：
ＬＩＤ：リンクアドレス
Ｐｏｒｔ Ｎｏ：受信可能ポート番号
Ｐｒｉｍｉｔｉｖｅ Ｔｙｐｅ ：受信するプリミティブ種別
Ｅｖｅｎｔ Ｃｏｄｅ：受信するイベントコードの種別
Ｅｑｕｉｐｍｅｎｔ ＩＤ：車載器固有情報
１．６ プロトコルデータユニット（ＰＤＵ）
次に、データグラム伝送サービスおよび管理サービスで用いられるＬＰＣＰのプロトコルデータユニット（ＰＤＵ）について説明する。
ＬＰＣＰのＰＤＵはローカルポート制御プロトコルヘッダとアプリケーションデータ部から構成される。
１．６．１ データグラム伝送サービスのプロトコルデータユニット
図１４にデータグラム伝送サービスで用いられるＬＰＣＰのＰＤＵの形式を示す。
アクセス点識別子：ネットワーク制御プロトコルを識別するための識別子。常にｌｏｃａｌ Ｐｏｒｔ Ｃｏｎｔｒｏｌ（１）を格納する。
プロトコル識別子：ＰＤＵ種別を表す。データグラム伝送サービスでは、ｍｅｓｓａｇｅ（０）を格納する。詳細は図１５を参照。
送信元ポート番号：送信元アプリケーションのポート番号
送信先ポート番号：送信先アプリケーションのポート番号
ユーザデータ部の長さ：後続するユーザデータ部のデータ長を指示する。単位はオクテット。なお、このエリアのサイズは、ＡＳＮ．１符号化規則に従い拡張する。付加するユーザデータがない（ＮＵＬＬの）場合、この領域に０が指定される。なお、ＬＰＣＰがＡＳＬ−ＥＬＣＰに渡すことができるデータの最大長、ＬＰＣＰのＭＴＵ（Ｍａｘｉｍ ｕｍ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｕｎｉｔ）は、５２２オクテット（アクセス制御情報含む）とする。
ユーザデータ部の内容：伝送データ本体。ＯＣＴＥＴ ＳＴＲＩＮＧ型の不定長データを格納する。
図１５はＬＰＣＰのプロトコル識別子を示す図である。
次に、データグラム伝送サービスおよび管理サービスで用いられるＬＰＣＰのプロトコルデータユニット（ＰＤＵ）について説明する。
ＬＰＣＰのＰＤＵはローカルポート制御プロトコルヘッダとアプリケーションデータ部から構成される。
１．６．１ データグラム伝送サービスのプロトコルデータユニット
図１４にデータグラム伝送サービスで用いられるＬＰＣＰのＰＤＵの形式を示す。
アクセス点識別子：ネットワーク制御プロトコルを識別するための識別子。常にｌｏｃａｌ Ｐｏｒｔ Ｃｏｎｔｒｏｌ（１）を格納する。
プロトコル識別子：ＰＤＵ種別を表す。データグラム伝送サービスでは、ｍｅｓｓａｇｅ（０）を格納する。詳細は図１５を参照。
送信元ポート番号：送信元アプリケーションのポート番号
送信先ポート番号：送信先アプリケーションのポート番号
ユーザデータ部の長さ：後続するユーザデータ部のデータ長を指示する。単位はオクテット。なお、このエリアのサイズは、ＡＳＮ．１符号化規則に従い拡張する。付加するユーザデータがない（ＮＵＬＬの）場合、この領域に０が指定される。なお、ＬＰＣＰがＡＳＬ−ＥＬＣＰに渡すことができるデータの最大長、ＬＰＣＰのＭＴＵ（Ｍａｘｉｍ ｕｍ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｕｎｉｔ）は、５２２オクテット（アクセス制御情報含む）とする。
ユーザデータ部の内容：伝送データ本体。ＯＣＴＥＴ ＳＴＲＩＮＧ型の不定長データを格納する。
図１５はＬＰＣＰのプロトコル識別子を示す図である。
１．６．２ 管理サービスのプロトコルデータユニット
図１６に管理サービスで用いられるＬＰＣＰのＰＤＵの形式を示す。以下に示すＰＤＵは相手局のＬＰＣＰへイベント通知を行う場合に用いられるものである。
図１６はイベント通知のメッセージの形式を示す図である。
アクセス点識別子：ネットワーク制御プロトコルを識別するための識別子。常にｌｏｃａｌ Ｐｏｒｔ Ｃｏｎｔｒｏｌ（１）を格納する。
プロトコル識別子：ＰＤＵ種別を表す。管理サービスでは、常にｅｖｅｎｔ Ｒｅｐｏｒｔ（１）を格納する。
イベントコード：発生したイベント内容を指示する識別子。０〜１２７は通信制御プロトコルの状態識別子であり、１２８〜２５５がＬＰＣＰの状態識別子である。図１７はイベントコード（ｅｖｅｎｔ Ｃｏｄｅ）の内容を示す図である。
イベント付加情報の長さ：後続するイベント付加情報のデータ長を指示する。単位はオクテット。なお、このエリアのサイズは、ＡＳＮ．１符号化規則に従い拡張する。付加するイベント情報がない（ＮＵＬＬの）場合、この領域に０が指定される。
イベント付加情報の内容：イベント付加情報の内容。ＯＣＴＥＴ ＳＴＲＩＮＧ型の不定長データを格納する。
図１６に管理サービスで用いられるＬＰＣＰのＰＤＵの形式を示す。以下に示すＰＤＵは相手局のＬＰＣＰへイベント通知を行う場合に用いられるものである。
図１６はイベント通知のメッセージの形式を示す図である。
アクセス点識別子：ネットワーク制御プロトコルを識別するための識別子。常にｌｏｃａｌ Ｐｏｒｔ Ｃｏｎｔｒｏｌ（１）を格納する。
プロトコル識別子：ＰＤＵ種別を表す。管理サービスでは、常にｅｖｅｎｔ Ｒｅｐｏｒｔ（１）を格納する。
イベントコード：発生したイベント内容を指示する識別子。０〜１２７は通信制御プロトコルの状態識別子であり、１２８〜２５５がＬＰＣＰの状態識別子である。図１７はイベントコード（ｅｖｅｎｔ Ｃｏｄｅ）の内容を示す図である。
イベント付加情報の長さ：後続するイベント付加情報のデータ長を指示する。単位はオクテット。なお、このエリアのサイズは、ＡＳＮ．１符号化規則に従い拡張する。付加するイベント情報がない（ＮＵＬＬの）場合、この領域に０が指定される。
イベント付加情報の内容：イベント付加情報の内容。ＯＣＴＥＴ ＳＴＲＩＮＧ型の不定長データを格納する。
１．７ 処理手順
ＬＰＣＰにおける処理手順について説明する。
１．７．１ 初期接続手順
（ａ）アプリケーションがＬＰＣＰに対して、ポート生成プリミティブにより、ＤＳＲＣ接続通知の要求をあらかじめ行っておく。
（ｂ）車両のＤＳＲＣ覆域への進入により、ＡＳＬ−ＥＬＣＰの管理サービスイベント通知プリミティブ（Ｅｖｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ．ｉｎｄ）で状態「通信接続の通知」を受領する。
（ｃ）ポート生成プリミティブで、ＤＳＲＣ接続通知を要求されているポートに対して、イベント通知プリミティブ（Ｅｖｅｎｔ Ｒｅｐｏｒｔ．ｉｎｄ）でイベントコード「ＤＳＲＣ接続通知（９６）」を通知する。
図１８にＤＳＲＣ接続時の処理シーケンス例を示す。
ＬＰＣＰにおける処理手順について説明する。
１．７．１ 初期接続手順
（ａ）アプリケーションがＬＰＣＰに対して、ポート生成プリミティブにより、ＤＳＲＣ接続通知の要求をあらかじめ行っておく。
（ｂ）車両のＤＳＲＣ覆域への進入により、ＡＳＬ−ＥＬＣＰの管理サービスイベント通知プリミティブ（Ｅｖｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ．ｉｎｄ）で状態「通信接続の通知」を受領する。
（ｃ）ポート生成プリミティブで、ＤＳＲＣ接続通知を要求されているポートに対して、イベント通知プリミティブ（Ｅｖｅｎｔ Ｒｅｐｏｒｔ．ｉｎｄ）でイベントコード「ＤＳＲＣ接続通知（９６）」を通知する。
図１８にＤＳＲＣ接続時の処理シーケンス例を示す。
１．７．２ 通信終了手順
（ａ）アプリケーションがＬＰＣＰに対して、ポート生成プリミティブにより、ＤＳＲＣ切断通知の要求をあらかじめ行っておく。
（ｂ）ＡＳＬ−ＥＬＣＰの管理サービスイベント通知プリミティブ（ＥｖｅｎｔＩｎｆｏｒｍａｔｉｏｎ．ｉｎｄ）で状態「通信切断の通知」を受領する。
（ｃ）ＬＰＰの接続管理サービスに対して、イベント通知プリミティブ（ＥｖｅｎｔＲｅｐｏｒｔ．ｉｎｄ）でイベントコード「ＤＳＲＣ切断通知」を通知する。
図１９に通信終了時の処理シーケンス例を示す。
（ａ）アプリケーションがＬＰＣＰに対して、ポート生成プリミティブにより、ＤＳＲＣ切断通知の要求をあらかじめ行っておく。
（ｂ）ＡＳＬ−ＥＬＣＰの管理サービスイベント通知プリミティブ（ＥｖｅｎｔＩｎｆｏｒｍａｔｉｏｎ．ｉｎｄ）で状態「通信切断の通知」を受領する。
（ｃ）ＬＰＰの接続管理サービスに対して、イベント通知プリミティブ（ＥｖｅｎｔＲｅｐｏｒｔ．ｉｎｄ）でイベントコード「ＤＳＲＣ切断通知」を通知する。
図１９に通信終了時の処理シーケンス例を示す。
１．７．３ メッセージ転送手順
（１）送信処理
（ａ）データ転送要求プリミティブ（ＴｒａｎｓｆｅｒＤａｔａ．ｒｅｑ）が発行される。
（ｂ）通信制御情報を参照し、指定されたＬｉｎｋ Ａｄｒｅｓｓがプライベートリンクアドレスであり、かつそのリンクアドレスでＤＳＲＣが接続されていない場合は、データ転送要求プリミティブで指定されていた送信元ポート番号に対して、状態識別子が「ＤＳＲＣが接続されていない（１２８）」であるイベント通知プリミティブを発行し、送信処理を完了する。ただし、この手順はローカルポート生成プリミティブにより、イベント通知の要求が行われていた場合とし、イベント通知の要求が行われていない場合には、上位プロトコルに対するイベント通知は行わない。イベント通知の有無は受信可能ローカルポートリストにより判別する。
（ｃ）ＤＳＲＣが接続している場合は、アクセス点識別子がｌｏｃａｌ Ｐｏｒｔ Ｐｒｏｔｏｃｏｌ（１）、プロトコル識別子がｍｅｓｓａｇｅ（０）である、パケットを生成し、ＡＳＬ−ＥＬＣＰのデータ転送プリミティブ（Ｓｅｎｄ Ｕｎｉｔ Ｄａｔａ．ｒｅｑ）で送信し、送信処理を完了する。
（ｄ）送信処理完了後、データ転送メッセージを送信した相手局からイベント通知メッセージを受領した場合には、そのメッセージで渡されたイベントコードを確認し、イベントコードの内容が「送信先ローカルポートが有効でない」の場合、そのメッセージのイベント付加情報に指定されている送信元ローカルポート番号に対して、イベント通知プリミティブ（Ｅｖｅｎｔ Ｒｅｐｏｒｔ．ｉｎｄ）により「送信先ローカルポートが有効でない」を通知する。ただし、この手順はローカルポート生成プリミティブにより、イベント通知の要求が行われていた場合とし、イベント通知の要求が行われていない場合には、上位プロトコルに対するイベント通知は行わない。イベント通知の有無は受信可能ローカルポートリストにより判別する。
（１）送信処理
（ａ）データ転送要求プリミティブ（ＴｒａｎｓｆｅｒＤａｔａ．ｒｅｑ）が発行される。
（ｂ）通信制御情報を参照し、指定されたＬｉｎｋ Ａｄｒｅｓｓがプライベートリンクアドレスであり、かつそのリンクアドレスでＤＳＲＣが接続されていない場合は、データ転送要求プリミティブで指定されていた送信元ポート番号に対して、状態識別子が「ＤＳＲＣが接続されていない（１２８）」であるイベント通知プリミティブを発行し、送信処理を完了する。ただし、この手順はローカルポート生成プリミティブにより、イベント通知の要求が行われていた場合とし、イベント通知の要求が行われていない場合には、上位プロトコルに対するイベント通知は行わない。イベント通知の有無は受信可能ローカルポートリストにより判別する。
（ｃ）ＤＳＲＣが接続している場合は、アクセス点識別子がｌｏｃａｌ Ｐｏｒｔ Ｐｒｏｔｏｃｏｌ（１）、プロトコル識別子がｍｅｓｓａｇｅ（０）である、パケットを生成し、ＡＳＬ−ＥＬＣＰのデータ転送プリミティブ（Ｓｅｎｄ Ｕｎｉｔ Ｄａｔａ．ｒｅｑ）で送信し、送信処理を完了する。
（ｄ）送信処理完了後、データ転送メッセージを送信した相手局からイベント通知メッセージを受領した場合には、そのメッセージで渡されたイベントコードを確認し、イベントコードの内容が「送信先ローカルポートが有効でない」の場合、そのメッセージのイベント付加情報に指定されている送信元ローカルポート番号に対して、イベント通知プリミティブ（Ｅｖｅｎｔ Ｒｅｐｏｒｔ．ｉｎｄ）により「送信先ローカルポートが有効でない」を通知する。ただし、この手順はローカルポート生成プリミティブにより、イベント通知の要求が行われていた場合とし、イベント通知の要求が行われていない場合には、上位プロトコルに対するイベント通知は行わない。イベント通知の有無は受信可能ローカルポートリストにより判別する。
（２）受信処理
（ａ）アプリケーションがＬＰＣＰに対して、ポート生成プリミティブにより、転送通知の要求を行い、受信ポートをオープンする。
（ｂ）ＡＳＬ−ＥＬＣＰからデータ転送通知プリミティブ（Ｓｅｎｄ Ｕｎｉｔ Ｄａｔａ．ｉｎｄ）で、プロトコル識別子がｍｅｓｓａｇｅ（０）であるパケットを受信すると、そのパケットから、プロトコル識別子、送信先ローカルポート番号、送信元ローカルポート番号、ユーザデータを取り出す。
（ｃ）受信可能ポートリストを参照し、（ｂ）で受信した送信先ポート番号が有効な場合は、送信先ポート番号で指定された上位エンティティに対して、データ転送プリミティブ（ＴｒａｎｓｆｅｒＤａｔａ．ｉｎｄ）で相手局からのデータの受信を通知し、受信処理を完了する。
（ｄ）リンクアドレスがプライベートアドレスであり、かつ（ｂ）で受信した送信先ポート番号が有効でない場合は、プロトコル識別子がｅｖｅｎｔ Ｒｅｐｏｒｔ（１）、状態識別子が「送信先ポートが有効でない（１２９）」であるパケットを作成し、ＡＳＬ−ＥＬＣＰのデータ転送プリミティブで相手局に送信し、受信処理を完了する。すなわち、相手局からのメッセージ受信時に自局に送信先アプリケーションが存在しない場合は、その旨を相手局に対して即座に通知する。またリンクアドレスがグループ同報アドレスであり、かつ（ｂ）で受信した送信先ポート番号が有効でない場合は、受信データを破棄し、受信処理を完了する。
図２０にメッセージ転送の基本処理シーケンス例を、図２１にＤＳＲＣが接続されていない場合の処理シーケンス例を、図２２に送信先ローカルポート番号が有効でない場合の処理シーケンス例を示す。
（ａ）アプリケーションがＬＰＣＰに対して、ポート生成プリミティブにより、転送通知の要求を行い、受信ポートをオープンする。
（ｂ）ＡＳＬ−ＥＬＣＰからデータ転送通知プリミティブ（Ｓｅｎｄ Ｕｎｉｔ Ｄａｔａ．ｉｎｄ）で、プロトコル識別子がｍｅｓｓａｇｅ（０）であるパケットを受信すると、そのパケットから、プロトコル識別子、送信先ローカルポート番号、送信元ローカルポート番号、ユーザデータを取り出す。
（ｃ）受信可能ポートリストを参照し、（ｂ）で受信した送信先ポート番号が有効な場合は、送信先ポート番号で指定された上位エンティティに対して、データ転送プリミティブ（ＴｒａｎｓｆｅｒＤａｔａ．ｉｎｄ）で相手局からのデータの受信を通知し、受信処理を完了する。
（ｄ）リンクアドレスがプライベートアドレスであり、かつ（ｂ）で受信した送信先ポート番号が有効でない場合は、プロトコル識別子がｅｖｅｎｔ Ｒｅｐｏｒｔ（１）、状態識別子が「送信先ポートが有効でない（１２９）」であるパケットを作成し、ＡＳＬ−ＥＬＣＰのデータ転送プリミティブで相手局に送信し、受信処理を完了する。すなわち、相手局からのメッセージ受信時に自局に送信先アプリケーションが存在しない場合は、その旨を相手局に対して即座に通知する。またリンクアドレスがグループ同報アドレスであり、かつ（ｂ）で受信した送信先ポート番号が有効でない場合は、受信データを破棄し、受信処理を完了する。
図２０にメッセージ転送の基本処理シーケンス例を、図２１にＤＳＲＣが接続されていない場合の処理シーケンス例を、図２２に送信先ローカルポート番号が有効でない場合の処理シーケンス例を示す。
２．トランザクション管理部（ローカルポートプロトコル）
以下に、トランザクション管理部（ローカルポートプロトコル）について詳細に説明する。
以下に、トランザクション管理部（ローカルポートプロトコル）について詳細に説明する。
２．１ 概要
ローカルポートプロトコル（ＬＰＰ：Ｌｏｃａｌ Ｐｏｒｔ Ｐｒｏｔｏｃｏｌ）は、ローカルポート制御プロトコル（ＬＰＣＰ）と非ネットワーク系アプリケーションの間に介在し、ローカルポート制御プロトコルの機能を拡張し、ＤＳＲＣ車載器／路側機上の非ネットワーク系アプリケーションに対して、以下のトランザクションサービスと接続管理サービスを提供することで、アプリケーション構築の効率化を図ることを目的としたトランザクション指向のプロトコルである（図２３参照）。本プロトコルは、ローカルポート制御プロトコルの通信機能を拡張するトランザクションサービス処理部と、初期接続や切断などの通信状況を管理する接続管理サービス処理部から構成されている。各サービス処理部が有する機能は以下の通り。
トランザクションサービス処理部
・トランザクション単位のデータ交換機能
・単方向データ送信トランザクションサービス
・リクエスト・レスポンス型トランザクションサービス
・データ再送機能
・メッセージの分割・組み立て機能
・トランザクションの破棄機能
接続管理サービス処理部
・ＤＳＲＣ接続問い合わせサービス
・ＤＳＲＣ切断通知サービス
・受信可能ポート問い合わせサービス
またトランザクション管理部は、アプリケーションに対して前記機能を利用するためのサービスプリミティブ（アプリケーションとのインタフェース）を提供する。さらに上記機能を実現するため、路車のトランザクション管理部間でやりとりされるデータ（ＰＤＵ）の構造を規定している。トランザクション管理部では、送信側がサービスプリミティブで要求された機能（またはトランザクション管理部内部で発生したイベント）に応じた制御情報を付加するとともに、受信側ではＰＤＵに付加された制御情報を解析、利用することで前記機能を実現する。
ローカルポートプロトコル（ＬＰＰ：Ｌｏｃａｌ Ｐｏｒｔ Ｐｒｏｔｏｃｏｌ）は、ローカルポート制御プロトコル（ＬＰＣＰ）と非ネットワーク系アプリケーションの間に介在し、ローカルポート制御プロトコルの機能を拡張し、ＤＳＲＣ車載器／路側機上の非ネットワーク系アプリケーションに対して、以下のトランザクションサービスと接続管理サービスを提供することで、アプリケーション構築の効率化を図ることを目的としたトランザクション指向のプロトコルである（図２３参照）。本プロトコルは、ローカルポート制御プロトコルの通信機能を拡張するトランザクションサービス処理部と、初期接続や切断などの通信状況を管理する接続管理サービス処理部から構成されている。各サービス処理部が有する機能は以下の通り。
トランザクションサービス処理部
・トランザクション単位のデータ交換機能
・単方向データ送信トランザクションサービス
・リクエスト・レスポンス型トランザクションサービス
・データ再送機能
・メッセージの分割・組み立て機能
・トランザクションの破棄機能
接続管理サービス処理部
・ＤＳＲＣ接続問い合わせサービス
・ＤＳＲＣ切断通知サービス
・受信可能ポート問い合わせサービス
またトランザクション管理部は、アプリケーションに対して前記機能を利用するためのサービスプリミティブ（アプリケーションとのインタフェース）を提供する。さらに上記機能を実現するため、路車のトランザクション管理部間でやりとりされるデータ（ＰＤＵ）の構造を規定している。トランザクション管理部では、送信側がサービスプリミティブで要求された機能（またはトランザクション管理部内部で発生したイベント）に応じた制御情報を付加するとともに、受信側ではＰＤＵに付加された制御情報を解析、利用することで前記機能を実現する。
２．２ ＬＰＰの機能
次に上述のＬＰＰにおける各サービス処理部の機能について、各々詳細に説明する。
２．２．１ トランザクションサービス処理
２．２．１．１ トランザクション単位のデータ交換機能
ローカルポートプロトコルでは、トランザクション単位でアプリケーションデータを交換する。
トランザクションＩＤにより、各々のトランザクションを区別する（図２４参照）。これにより、同一アプリケーション間で複数トランザクションが同時に存在する状況への対応も可能になる。
図２４はＬＰＰにおけるトランザクション間データ交換例を示す図である。
なおトランザクションＩＤの付番方式は以下の通りとする。
（１）１６ビット構成
（２）先頭ビットはトランザクションの開始側を表す（車載側が０、 路側側が１）。
（３）トランザクションの発行（Ｉｎｖｏｋｅ．ｒｅｑ）毎に１インクリメントされる。
次に上述のＬＰＰにおける各サービス処理部の機能について、各々詳細に説明する。
２．２．１ トランザクションサービス処理
２．２．１．１ トランザクション単位のデータ交換機能
ローカルポートプロトコルでは、トランザクション単位でアプリケーションデータを交換する。
トランザクションＩＤにより、各々のトランザクションを区別する（図２４参照）。これにより、同一アプリケーション間で複数トランザクションが同時に存在する状況への対応も可能になる。
図２４はＬＰＰにおけるトランザクション間データ交換例を示す図である。
なおトランザクションＩＤの付番方式は以下の通りとする。
（１）１６ビット構成
（２）先頭ビットはトランザクションの開始側を表す（車載側が０、 路側側が１）。
（３）トランザクションの発行（Ｉｎｖｏｋｅ．ｒｅｑ）毎に１インクリメントされる。
２．２．１．２ ２種類のトランザクションサービス提供機能
本プロトコルは以下の２種類のトランザクションサービスを提供する。
・単方向データ送信トランザクションサービス
・リクエスト・レスポンス型トランザクションサービス
これらの各トランザクションサービスは、アプリケーション個々の通信要件に応じて、必要なレベルのものが用いられ、アプリケーション毎に最適な通信サービスを利用できる。
本プロトコルは以下の２種類のトランザクションサービスを提供する。
・単方向データ送信トランザクションサービス
・リクエスト・レスポンス型トランザクションサービス
これらの各トランザクションサービスは、アプリケーション個々の通信要件に応じて、必要なレベルのものが用いられ、アプリケーション毎に最適な通信サービスを利用できる。
２．２．１．２．１ 基本トランザクション
（１）データ送信サービス
路車双方の非ネットワーク系アプリケーションに対して、データ送信サービスを提供する。（図２５参照）図２５はデータ送信サービスの例を示す図である。
（２）リクエスト・レスポンス型トランザクションサービス
メッセージを相手に対して通知すると共に、そのメッセージに対する返り値を取得する。リモートに対するメソッド呼び出しなどの用途に利用する。（図２６参照）
図２６はリクエスト・レスポンス型トランザクションサービスの例を示す図である。
（１）データ送信サービス
路車双方の非ネットワーク系アプリケーションに対して、データ送信サービスを提供する。（図２５参照）図２５はデータ送信サービスの例を示す図である。
（２）リクエスト・レスポンス型トランザクションサービス
メッセージを相手に対して通知すると共に、そのメッセージに対する返り値を取得する。リモートに対するメソッド呼び出しなどの用途に利用する。（図２６参照）
図２６はリクエスト・レスポンス型トランザクションサービスの例を示す図である。
２．２．１．２．２ データ再送機能
本機能は、通信の信頼性を確保するための機能であり、再送タイマーと再送カウンタにより再送の制御を行う。再送タイマーのタイムアウト時に再送を行う（最大再送回数以下）ことで、通信の信頼性を確保する（図２７参照）。データの送信や返信に適用が可能であり、適用するかどうかはアプリケーションが指定する。処理シーケンスを以下に示す。
図２７はデータ再送の例を示す図である。
・パケット送信時に、再送タイマをスタートさせ、再送カウンタを０にセットする。
・再送タイマのタイムアウト前にレスポンスデータを受信できなかった場合には再送カウンタをインクリメントし、パケットを再送する。
・再送カウンタが最大再送回数を超えた場合には、トランザクションを終了し、その旨をアプリケーションに通知する。
また、データ再送機能を使用するトランザクションにおいては、送達確認の未到達などの理由により、以前に受信したＰＤＵを再度受信する可能性がある。この重複受信はトランザクションＩＤを用いて検知する（図２８参照）。具体的なチェック方法に関しては、実装要件とし、ここでは特に規定しない。
図２８は重複受信チェックの例を示す図である。
本機能は、通信の信頼性を確保するための機能であり、再送タイマーと再送カウンタにより再送の制御を行う。再送タイマーのタイムアウト時に再送を行う（最大再送回数以下）ことで、通信の信頼性を確保する（図２７参照）。データの送信や返信に適用が可能であり、適用するかどうかはアプリケーションが指定する。処理シーケンスを以下に示す。
図２７はデータ再送の例を示す図である。
・パケット送信時に、再送タイマをスタートさせ、再送カウンタを０にセットする。
・再送タイマのタイムアウト前にレスポンスデータを受信できなかった場合には再送カウンタをインクリメントし、パケットを再送する。
・再送カウンタが最大再送回数を超えた場合には、トランザクションを終了し、その旨をアプリケーションに通知する。
また、データ再送機能を使用するトランザクションにおいては、送達確認の未到達などの理由により、以前に受信したＰＤＵを再度受信する可能性がある。この重複受信はトランザクションＩＤを用いて検知する（図２８参照）。具体的なチェック方法に関しては、実装要件とし、ここでは特に規定しない。
図２８は重複受信チェックの例を示す図である。
２．２．１．２．３ メッセージ分割・組み立て機能
本機能は、メッセージの分割・組み立て処理を行うことで、アプリケーションに対して、ＬＰＣＰのＭＴＵ を越えるメッセージの送信インタフェースの提供を可能とする機能である。
図２９は、分割・組み立て機能を利用したメッセージ通信の手順を示したものである。ＬＰＰはアプリケーションから、ＬＰＣＰのＭＴＵを越えるメッセージを受け取った場合には、ＬＰＰ内でＰＤＵをＬＰＣＰのＭＴＵのサイズに分割し、順次ＬＰＣＰに渡すように操作する。これにより分割されたパケットは、ＤＳＲＣ−ＡＳＬの送信キューに積み上げられ、順次レイヤ７に転送される。この際、ＤＳＲＣ−ＡＳＬの送信キューがオーバフローすることが想定されるため、ＬＰＰでは送信を失敗したパケットの再送や、フロー制御を行うことで、すべてのパケットが送信されることを保証する。
受信側は、ＬＰＣＰから渡された分割されたパケットを順次取り込み、受信側のアプリケーションが用意した受信キューへ積み上げる。この際、レイヤ２の再送処理などの要因により、受信キューには送信順に各パケットが格納される保証はなく、受信側は、各パケットに付番されたシーケンス番号で組み立て順を判別してＰＤＵへ組み上げる。受信側では、全てのパケットを受信後、送信側に対して到達確認を返す。
本機能は、メッセージの分割・組み立て処理を行うことで、アプリケーションに対して、ＬＰＣＰのＭＴＵ を越えるメッセージの送信インタフェースの提供を可能とする機能である。
図２９は、分割・組み立て機能を利用したメッセージ通信の手順を示したものである。ＬＰＰはアプリケーションから、ＬＰＣＰのＭＴＵを越えるメッセージを受け取った場合には、ＬＰＰ内でＰＤＵをＬＰＣＰのＭＴＵのサイズに分割し、順次ＬＰＣＰに渡すように操作する。これにより分割されたパケットは、ＤＳＲＣ−ＡＳＬの送信キューに積み上げられ、順次レイヤ７に転送される。この際、ＤＳＲＣ−ＡＳＬの送信キューがオーバフローすることが想定されるため、ＬＰＰでは送信を失敗したパケットの再送や、フロー制御を行うことで、すべてのパケットが送信されることを保証する。
受信側は、ＬＰＣＰから渡された分割されたパケットを順次取り込み、受信側のアプリケーションが用意した受信キューへ積み上げる。この際、レイヤ２の再送処理などの要因により、受信キューには送信順に各パケットが格納される保証はなく、受信側は、各パケットに付番されたシーケンス番号で組み立て順を判別してＰＤＵへ組み上げる。受信側では、全てのパケットを受信後、送信側に対して到達確認を返す。
また、ＤＳＲＣ−ＡＳＬでの受信キューオーバフローやＤＳＲＣでのデータの欠落などで、パケットの欠落が発生することが想定され、送信された全てのパケットが相手局のＬＰＰまで到達される保証はない。この場合、１つのパケットの欠落がメッセージ全体のデータの欠落となってしまうため、最終パケット受信時に受信できていないパケットを、否定応答により通知し、欠落したパケットの再送を行う（選択的再送処理）ことにより、メッセージ全体の到着を保証する。また最終パケットの欠落については、通常の再送処理により、到達を保証する。なお、選択的再送によって送信するパケット群についても同様の制御を行う。図３０に選択的再送処理の例を示す。
なお、アプリケーション毎に必要となる受信キューのサイズが大きく異なることが予想されることから、本機能では受信キューをアプリケーションが用意する。そのため、分割・組立が必要なトランザクションは、送信先（リンクアドレスと送信先ポート番号で識別）毎に、同時には１つしか発行できないものとする。
また同報アドレスに対するデータ送信の場合には、到達確認の返信、選択的再送処理や最終セグメントの再送制御を行わず、トランザクションの再実行要求により、必要とされる通信の信頼性を確保する。図３２にトランザクションの再実行処理の例を示す。
なお、アプリケーション毎に必要となる受信キューのサイズが大きく異なることが予想されることから、本機能では受信キューをアプリケーションが用意する。そのため、分割・組立が必要なトランザクションは、送信先（リンクアドレスと送信先ポート番号で識別）毎に、同時には１つしか発行できないものとする。
また同報アドレスに対するデータ送信の場合には、到達確認の返信、選択的再送処理や最終セグメントの再送制御を行わず、トランザクションの再実行要求により、必要とされる通信の信頼性を確保する。図３２にトランザクションの再実行処理の例を示す。
２．２．１．３ トランザクションの廃棄機能
リクエスト・レスポンス型のトランザクションでは、アプリケーションからの要求により、トランザクションの破棄を要求できる（図３３参照）。要求時のトランザクションの状態に応じて、以下の処理が実施される。
・メッセージが送信されていない場合は、そのメッセージを破棄する。
・メッセージを送信済みもしくは送信中の場合は、そのトランザクションに関連する全てのデータを破棄し、相手側に対してそのトランザクションが破棄されたことを通知する。
・相手側でのトランザクション破棄要求により、トランザクションの破棄要求を受信した場合は、アプリケーションに対して、トランザクション破棄を通知すると共に、そのトランザクションに関連する全てのデータを破棄する。
図３３はトランザクション破棄通知の例を示す図である。
また、
・ＤＳＲＣ通信路が切断されている。
・宛先ポートが受信可能ポートではない。
といった場合は、無駄な通信を抑制するために、トランザクションを開始せず、要求が失敗したことをアプリケーションに通知する。
リクエスト・レスポンス型のトランザクションでは、アプリケーションからの要求により、トランザクションの破棄を要求できる（図３３参照）。要求時のトランザクションの状態に応じて、以下の処理が実施される。
・メッセージが送信されていない場合は、そのメッセージを破棄する。
・メッセージを送信済みもしくは送信中の場合は、そのトランザクションに関連する全てのデータを破棄し、相手側に対してそのトランザクションが破棄されたことを通知する。
・相手側でのトランザクション破棄要求により、トランザクションの破棄要求を受信した場合は、アプリケーションに対して、トランザクション破棄を通知すると共に、そのトランザクションに関連する全てのデータを破棄する。
図３３はトランザクション破棄通知の例を示す図である。
また、
・ＤＳＲＣ通信路が切断されている。
・宛先ポートが受信可能ポートではない。
といった場合は、無駄な通信を抑制するために、トランザクションを開始せず、要求が失敗したことをアプリケーションに通知する。
２．２．２ 接続管理サービス処理
接続管理サービスでは、以下のサービスをアプリケーションに対して提供することで、アプリケーションに通信開始・終了のトリガーを提供する。
・ＤＳＲＣの接続状況を管理、監視し、アプリケーションからの要求に応じて、接続状況の報告や新規接続、切断を通知するサービス。
・路車間の接続管理サービス間で受信可能ポート番号を通知しあうことで、相手局が有する受信可能ポート番号を管理し、アプリケーションからの要求に応じて、それらの状況を報告したり、あるポートが受信可能となったことを通知するサービス。
なお、接続管理サービスは、ローカルポート制御プロトコル上のアプリケーションと同様の位置づけとし、路車の接続管理サービス間でのイベントの送受信は、ローカルポート制御プロトコルのデータ転送サービスを利用する。接続管理サービスが利用するポート番号は、当面、０ｘ０ＦＦＦとする。
接続管理サービスでは、以下のサービスをアプリケーションに対して提供することで、アプリケーションに通信開始・終了のトリガーを提供する。
・ＤＳＲＣの接続状況を管理、監視し、アプリケーションからの要求に応じて、接続状況の報告や新規接続、切断を通知するサービス。
・路車間の接続管理サービス間で受信可能ポート番号を通知しあうことで、相手局が有する受信可能ポート番号を管理し、アプリケーションからの要求に応じて、それらの状況を報告したり、あるポートが受信可能となったことを通知するサービス。
なお、接続管理サービスは、ローカルポート制御プロトコル上のアプリケーションと同様の位置づけとし、路車の接続管理サービス間でのイベントの送受信は、ローカルポート制御プロトコルのデータ転送サービスを利用する。接続管理サービスが利用するポート番号は、当面、０ｘ０ＦＦＦとする。
２．２．２．１ ＤＳＲＣ接続問い合わせサービス
ＤＳＲＣが接続しているかどうかを問い合わせる機能。
問い合わせ時にＤＳＲＣの接続状況を即座に回答を行う参照サービスと、接続していない場合に、接続するまで待ち、接続した時点で通知をおこなう通知サービスの２種類のサービスを規定する。
２．２．２．２ ＤＳＲＣ切断通知サービス
切断通知を要求するアプリケーションに対して、ＤＳＲＣの切断を通知する機能。
ＤＳＲＣが接続しているかどうかを問い合わせる機能。
問い合わせ時にＤＳＲＣの接続状況を即座に回答を行う参照サービスと、接続していない場合に、接続するまで待ち、接続した時点で通知をおこなう通知サービスの２種類のサービスを規定する。
２．２．２．２ ＤＳＲＣ切断通知サービス
切断通知を要求するアプリケーションに対して、ＤＳＲＣの切断を通知する機能。
２．２．２．３ 受信可能ポート問い合わせサービス
相手局にある受信ポートが存在しているかどうかを問い合わせる機能。ポートの状態には以下の３種類がある。
・受信可能ポート：相手局がこのポートをデータ受信ポートとしてオープンしているポート。
・受信不可ポート：相手局がこのポートをデータ受信ポートとしてオープンしていないポート。
・不明ポート：相手局がこのポートをデータ受信ポートとしてオープンしているかどうかわからないポート。初期状態がこの状態。
なお、受信可能ポート問い合わせサービスには、問い合わせ時にそのポートがどの状態であるかを即座に回答を行う参照サービスと問い合わせたポートが受信可能ポートになるまで待ち、相手局からの受信可能ポート通知を受け取った時点で通知を行う通知サービス（すでに問い合わせたポートが受信可能ポートであることが判明している場合は即座に回答する）の２種類のサービスを規定する。
前記サービスを可能とするため、路車間のローカルポートプロトコルの管理サービスは、ＤＳＲＣ通信接続時や受信可能ポート変更時に相手局に対して、自局が受信可能なポート番号や受信不可となったポート番号を通知する機能を有する。
相手局にある受信ポートが存在しているかどうかを問い合わせる機能。ポートの状態には以下の３種類がある。
・受信可能ポート：相手局がこのポートをデータ受信ポートとしてオープンしているポート。
・受信不可ポート：相手局がこのポートをデータ受信ポートとしてオープンしていないポート。
・不明ポート：相手局がこのポートをデータ受信ポートとしてオープンしているかどうかわからないポート。初期状態がこの状態。
なお、受信可能ポート問い合わせサービスには、問い合わせ時にそのポートがどの状態であるかを即座に回答を行う参照サービスと問い合わせたポートが受信可能ポートになるまで待ち、相手局からの受信可能ポート通知を受け取った時点で通知を行う通知サービス（すでに問い合わせたポートが受信可能ポートであることが判明している場合は即座に回答する）の２種類のサービスを規定する。
前記サービスを可能とするため、路車間のローカルポートプロトコルの管理サービスは、ＤＳＲＣ通信接続時や受信可能ポート変更時に相手局に対して、自局が受信可能なポート番号や受信不可となったポート番号を通知する機能を有する。
２．３ アプリケーションとのインタフェース
次に、ＬＰＰとアプリケーションとのインタフェースについて説明する。
２．３．１ 記法の説明
本発明で規定されるプリミティブ種別の一覧を図３４に示す。
また、本発明でのプリミティブの定義テーブルで用いられるパラメータ種別の一覧を図３５に示す。
２．３．２ トランザクションサービスプリミティブ
トランザクションサービスとして、ＬＰＰはアプリケーションに対して、以下の２種類のプリミティブを用意する。
・Ｉｎｖｏｋｅ：（トランザクション開始プリミティブ）
・Ａｂｏｒｔ：（トランザクション破棄プリミティブ）
次に、ＬＰＰとアプリケーションとのインタフェースについて説明する。
２．３．１ 記法の説明
本発明で規定されるプリミティブ種別の一覧を図３４に示す。
また、本発明でのプリミティブの定義テーブルで用いられるパラメータ種別の一覧を図３５に示す。
２．３．２ トランザクションサービスプリミティブ
トランザクションサービスとして、ＬＰＰはアプリケーションに対して、以下の２種類のプリミティブを用意する。
・Ｉｎｖｏｋｅ：（トランザクション開始プリミティブ）
・Ａｂｏｒｔ：（トランザクション破棄プリミティブ）
２．３．２．１ Ｉｎｖｏｋｅ（トランザクション開始プリミティブ）
処理概要：
Ｉｎｖｏｋｅプリミティブは新しいトランザクションを生成するためのプリミティブである。全てのトランザクションはこのプリミティブの発行により開始される。
定義：
図３６はＩｎｖｏｋｅプリミティブの引数を示す図である。
Ｌｉｎｋ Ａｄｄｒｅｓｓ：ＤＳＲＣのＬＩＤもしくはＬＩＤと１対１でマッピング可能なＩＤ
Ｓｏｕｒｃｅ Ｐｏｒｔ：送信元アプリケーションのポート番号
Ｄｅｓｔｉｎａｔｉｏｎ Ｐｏｒｔ：送信先アプリケーションのポート番号
Ｕｓｅｒ Ｄａｔａ Ｓｉｚｅ：送信データサイズ（オクテット単位）
Ｕｓｅｒ Ｄａｔａ：送信データ本体
Ｔｒａｎｓａｃｔｉｏｎ Ｔｙｐｅ：トランザクションサービスのタイプ
０：データ送信トランザクションサービス
１：リクエスト・レスポンス型トランザクションサービス
Ｒｅｑｕｉｒｅ Ａｃｋ：再送処理を有効にするかどうかのフラグ（０：再送処理不要、１：再送処理必要）
Ｒｅｓｕｌｔ Ｔｉｍｅｏｕｔ：リクエスト・レスポンス型トランザクションサービスでＲｅｓｕｌｔ ＰＤＵ受信までのタイムアウト時間。Ｉｎｖｏｋｅ．ｒｅｑ発行後、この時間までにＲｅｓｕｌｔ ＰＤＵを受信しなければ、このトランザクションは破棄される。
Ｈａｎｄｌｅ：ローカルでトランザクションを区別するためのＩＤ。アプリケーションから指定される。ここで指定されるＨａｎｄｌｅは以下の条件を満たす必要がある。Ｉｎｖｏｋｅ．ｒｅｑの発行側では、トランザクションＩＤにより、ＨａｎｄｌｅとＳｏｕｒｃｅ Ｐｏｒｔが一意に特定できなければならない。Ｉｎｖｏｋｅ．ｒｅｓの発行側では、ＨａｎｄｌｅによりＬｉｎｋＡｄｄｒｅｓｓ、 Ｓｏｕｒｃｅ Ｐｏｒｔ、 トランザクションＩＤが一意に特定できなければならない。また、同報通信において、直前の実行済みの同報通信と同一のＨａｎｄｌｅが指定された場合には、トランザクションの再実行要求として扱われる。
処理概要：
Ｉｎｖｏｋｅプリミティブは新しいトランザクションを生成するためのプリミティブである。全てのトランザクションはこのプリミティブの発行により開始される。
定義：
図３６はＩｎｖｏｋｅプリミティブの引数を示す図である。
Ｌｉｎｋ Ａｄｄｒｅｓｓ：ＤＳＲＣのＬＩＤもしくはＬＩＤと１対１でマッピング可能なＩＤ
Ｓｏｕｒｃｅ Ｐｏｒｔ：送信元アプリケーションのポート番号
Ｄｅｓｔｉｎａｔｉｏｎ Ｐｏｒｔ：送信先アプリケーションのポート番号
Ｕｓｅｒ Ｄａｔａ Ｓｉｚｅ：送信データサイズ（オクテット単位）
Ｕｓｅｒ Ｄａｔａ：送信データ本体
Ｔｒａｎｓａｃｔｉｏｎ Ｔｙｐｅ：トランザクションサービスのタイプ
０：データ送信トランザクションサービス
１：リクエスト・レスポンス型トランザクションサービス
Ｒｅｑｕｉｒｅ Ａｃｋ：再送処理を有効にするかどうかのフラグ（０：再送処理不要、１：再送処理必要）
Ｒｅｓｕｌｔ Ｔｉｍｅｏｕｔ：リクエスト・レスポンス型トランザクションサービスでＲｅｓｕｌｔ ＰＤＵ受信までのタイムアウト時間。Ｉｎｖｏｋｅ．ｒｅｑ発行後、この時間までにＲｅｓｕｌｔ ＰＤＵを受信しなければ、このトランザクションは破棄される。
Ｈａｎｄｌｅ：ローカルでトランザクションを区別するためのＩＤ。アプリケーションから指定される。ここで指定されるＨａｎｄｌｅは以下の条件を満たす必要がある。Ｉｎｖｏｋｅ．ｒｅｑの発行側では、トランザクションＩＤにより、ＨａｎｄｌｅとＳｏｕｒｃｅ Ｐｏｒｔが一意に特定できなければならない。Ｉｎｖｏｋｅ．ｒｅｓの発行側では、ＨａｎｄｌｅによりＬｉｎｋＡｄｄｒｅｓｓ、 Ｓｏｕｒｃｅ Ｐｏｒｔ、 トランザクションＩＤが一意に特定できなければならない。また、同報通信において、直前の実行済みの同報通信と同一のＨａｎｄｌｅが指定された場合には、トランザクションの再実行要求として扱われる。
２．３．２．２ Ａｂｏｒｔ（トランザクション破棄プリミティブ）
処理概要：
Ａｂｏｒｔプリミティブは生成されているトランザクションを破棄するためのプリミティブである。
定義：
図３７はＡｂｏｒｔプリミティブの引数を示す図である。
Ａｂｏｒｔ Ｔｙｐｅ：破棄理由がシステムエラー（０）か、ユーザ要求（１）かを表す。
Ａｂｏｒｔ Ｃｏｄｅ：トランザクションが破棄された理由を示す。（システムエラーの詳細は図３８参照）
Ｈａｎｄｌｅ：ローカルでトランザクションを区別するためのＩＤ。
図３８はＡｂｏｒｔ Ｔｙｐｅ＝０の場合（システムエラー）のＡｂｏｒｔ Ｃｏｄｅ一覧を示す図である。
処理概要：
Ａｂｏｒｔプリミティブは生成されているトランザクションを破棄するためのプリミティブである。
定義：
図３７はＡｂｏｒｔプリミティブの引数を示す図である。
Ａｂｏｒｔ Ｔｙｐｅ：破棄理由がシステムエラー（０）か、ユーザ要求（１）かを表す。
Ａｂｏｒｔ Ｃｏｄｅ：トランザクションが破棄された理由を示す。（システムエラーの詳細は図３８参照）
Ｈａｎｄｌｅ：ローカルでトランザクションを区別するためのＩＤ。
図３８はＡｂｏｒｔ Ｔｙｐｅ＝０の場合（システムエラー）のＡｂｏｒｔ Ｃｏｄｅ一覧を示す図である。
２．３．３ 接続管理サービス
接続管理サービスとして、ＬＰＰはアプリケーションに対して、以下の４種類のプリミティブを用意する。
・Ｃｏｎｎｅｃｔ：（トランザクション開始可能問い合わせ／通知プリミティブ）
・Ｄｉｓｃｏｎｎｅｃｔ：（ＤＳＲＣ切断通知プリミティブ）
・Ｒｅｇｉｓｔｅｒ Ｐｏｒｔ（ポート登録プリミティブ）
・Ｄｅｒｅｇｉｓｔｅｒ Ｐｏｒｔ（ポート登録削除プリミティブ）
接続管理サービスとして、ＬＰＰはアプリケーションに対して、以下の４種類のプリミティブを用意する。
・Ｃｏｎｎｅｃｔ：（トランザクション開始可能問い合わせ／通知プリミティブ）
・Ｄｉｓｃｏｎｎｅｃｔ：（ＤＳＲＣ切断通知プリミティブ）
・Ｒｅｇｉｓｔｅｒ Ｐｏｒｔ（ポート登録プリミティブ）
・Ｄｅｒｅｇｉｓｔｅｒ Ｐｏｒｔ（ポート登録削除プリミティブ）
２．３．３．１ Ｃｏｎｎｅｃｔ （トランザクション開始可能問い合わせ／通知プリミティブ）
処理概要：
Ｃｏｎｎｅｃｔ．ｒｅｑプリミティブは、トランザクションが開始可能かどうかを問い合わせるためのプリミティブである。Ｃｏｎｎｅｃｔ．ｃｎｆプリミティブはＣｏｎｎｅｃｔ．ｒｅｑによる問い合わせに対し、ＤＳＲＣの接続とＬＩＤおよび（そのＬＩＤが指し示す）相手局が有する受信可能ポート番号を問い合わせ元のアプリケーションに通知するためのプリミティブである。
定義：
図３９はＣｏｎｎｅｃｔプリミティブの引数を示す図である。
Ｑｕｅｒｉｓｔ Ｐｏｒｔ：問い合わせ元のＰｏｒｔ番号で、問い合わせを行ったアプリを特定するために使用する。
Ｑｕｅｒｙ ＬＩＤ：問い合わせを行うＬＩＤ。ＬＩＤ指定時は、既接続済みのリンクに対する問い合わせとして扱う。一方指定が無い場合は、新規接続待ちとして扱う。ＱｕｅｒｙＰｏｒｔとともに省略された時はＤＳＲＣ接続後すぐにＣｏｎｎｅｃｔ．ｃｎｆが発行される（高速接続）。一方、ＱｕｅｒｙＰｏｒｔが指定された場合は、受信可能ポート通知受信後にＣｏｎｎｅｃｔ．ｃｎｆが発行される（通常接続）。
Ｑｕｅｒｙ Ｐｏｒｔ：問い合わせを行う宛先ポート番号。
Ｔｉｍｅ Ｏｕｔ：ＤＳＲＣ未接続時にＣｏｎｎｅｃｔ．ｃｎｆを発行するまでのウェイト時間。ウェイト中に接続された場合は、即座にＣｏｎｎｅｃｔ．ｃｎｆを発行する。このパラメータを省略時はタイムアウト時間＝∞として扱う。
Ｃｏｎｎｅｃｔｅｄ ＬＩＤ：Ｑｕｅｒｙ ＬＩＤが指定され、かつそのＬＩＤが接続中の場合は、ＱｕｅｒｙＬＩＤと同じＬＩＤが指定さる。Ｑｕｅｒｙ ＬＩＤが指定されかつそのＬＩＤが未接続の場合、およびＱｕｅｒｙ ＬＩＤが未指定で、ＴｉｍｅＯｕｔパラメータで指定される時間内に新規接続が無い場合は−１が指定される。
Ａｃｃｅｐｔ Ｐｏｒｔ：Ｃｏｎｎｅｃｔｅｄ ＬＩＤで表される相手局が有する受信可能ポート番号。Ｑｕｅｒｙ Ｐｏｒｔにて指定があった場合は、そのポート番号のみを通知する。なお、指定されたＰｏｒｔ番号が受信拒否ポート番号の場合は、−１が指定される。またＱｕｅｒｙ Ｐｏｒｔが省略されている場合は、０が指定される。
処理概要：
Ｃｏｎｎｅｃｔ．ｒｅｑプリミティブは、トランザクションが開始可能かどうかを問い合わせるためのプリミティブである。Ｃｏｎｎｅｃｔ．ｃｎｆプリミティブはＣｏｎｎｅｃｔ．ｒｅｑによる問い合わせに対し、ＤＳＲＣの接続とＬＩＤおよび（そのＬＩＤが指し示す）相手局が有する受信可能ポート番号を問い合わせ元のアプリケーションに通知するためのプリミティブである。
定義：
図３９はＣｏｎｎｅｃｔプリミティブの引数を示す図である。
Ｑｕｅｒｉｓｔ Ｐｏｒｔ：問い合わせ元のＰｏｒｔ番号で、問い合わせを行ったアプリを特定するために使用する。
Ｑｕｅｒｙ ＬＩＤ：問い合わせを行うＬＩＤ。ＬＩＤ指定時は、既接続済みのリンクに対する問い合わせとして扱う。一方指定が無い場合は、新規接続待ちとして扱う。ＱｕｅｒｙＰｏｒｔとともに省略された時はＤＳＲＣ接続後すぐにＣｏｎｎｅｃｔ．ｃｎｆが発行される（高速接続）。一方、ＱｕｅｒｙＰｏｒｔが指定された場合は、受信可能ポート通知受信後にＣｏｎｎｅｃｔ．ｃｎｆが発行される（通常接続）。
Ｑｕｅｒｙ Ｐｏｒｔ：問い合わせを行う宛先ポート番号。
Ｔｉｍｅ Ｏｕｔ：ＤＳＲＣ未接続時にＣｏｎｎｅｃｔ．ｃｎｆを発行するまでのウェイト時間。ウェイト中に接続された場合は、即座にＣｏｎｎｅｃｔ．ｃｎｆを発行する。このパラメータを省略時はタイムアウト時間＝∞として扱う。
Ｃｏｎｎｅｃｔｅｄ ＬＩＤ：Ｑｕｅｒｙ ＬＩＤが指定され、かつそのＬＩＤが接続中の場合は、ＱｕｅｒｙＬＩＤと同じＬＩＤが指定さる。Ｑｕｅｒｙ ＬＩＤが指定されかつそのＬＩＤが未接続の場合、およびＱｕｅｒｙ ＬＩＤが未指定で、ＴｉｍｅＯｕｔパラメータで指定される時間内に新規接続が無い場合は−１が指定される。
Ａｃｃｅｐｔ Ｐｏｒｔ：Ｃｏｎｎｅｃｔｅｄ ＬＩＤで表される相手局が有する受信可能ポート番号。Ｑｕｅｒｙ Ｐｏｒｔにて指定があった場合は、そのポート番号のみを通知する。なお、指定されたＰｏｒｔ番号が受信拒否ポート番号の場合は、−１が指定される。またＱｕｅｒｙ Ｐｏｒｔが省略されている場合は、０が指定される。
２．３．３．２ Ｄｉｓｃｏｎｎｅｃｔ（ＤＳＲＣ切断通知プリミティブ）
処理概要：
ＤＳＲＣの切断をアプリケーションに通知するためのプリミティブである。
定義：
図４０はＤｉｓｃｏｎｎｅｃｔプリミティブの引数を示す図である。
２．３．３．３ Ｒｅｇｉｓｔｅｒ Ｐｏｒｔ（ポート登録プリミティブ）
処理概要：
Ｒｅｇｉｓｔｅｒ Ｐｏｒｔプリミティブは、ＬＰＰに対して受信ポートを登録するためのプリミティブである。
定義：
図４１はＲｅｇｉｓｔｅｒＰｏｒｔプリミティブの引数を示す図である。
Ｐｏｒｔ Ｎｏ：受信ポート番号
Ｂｕｌｋ Ａｒｅａ：分割されたメッセージを組み立てるエリア
Ｂｕｌｋ Ａｒｅａ Ｓｉｚｅ：Ｂｕｌｋ Ａｒｅａのサイズ
処理概要：
ＤＳＲＣの切断をアプリケーションに通知するためのプリミティブである。
定義：
図４０はＤｉｓｃｏｎｎｅｃｔプリミティブの引数を示す図である。
２．３．３．３ Ｒｅｇｉｓｔｅｒ Ｐｏｒｔ（ポート登録プリミティブ）
処理概要：
Ｒｅｇｉｓｔｅｒ Ｐｏｒｔプリミティブは、ＬＰＰに対して受信ポートを登録するためのプリミティブである。
定義：
図４１はＲｅｇｉｓｔｅｒＰｏｒｔプリミティブの引数を示す図である。
Ｐｏｒｔ Ｎｏ：受信ポート番号
Ｂｕｌｋ Ａｒｅａ：分割されたメッセージを組み立てるエリア
Ｂｕｌｋ Ａｒｅａ Ｓｉｚｅ：Ｂｕｌｋ Ａｒｅａのサイズ
２．３．３．４ Ｄｅｒｅｇｉｓｔｅｒ Ｐｏｒｔ（ポート登録削除プリミティブ）
処理概要：
Ｄｅｒｅｇｉｓｔｅｒ Ｐｏｒｔプリミティブは、ＬＰＰに対して受信ポートを削除するためのプリミティブである。
定義：
図４２はＤｅｒｅｇｉｓｔｅｒＰｏｒｔプリミティブの引数を示す図である。
Ｐｏｒｔ Ｎｏ：登録を削除する受信ポート番号
処理概要：
Ｄｅｒｅｇｉｓｔｅｒ Ｐｏｒｔプリミティブは、ＬＰＰに対して受信ポートを削除するためのプリミティブである。
定義：
図４２はＤｅｒｅｇｉｓｔｅｒＰｏｒｔプリミティブの引数を示す図である。
Ｐｏｒｔ Ｎｏ：登録を削除する受信ポート番号
２．４ プロトコルデータユニット（ＰＤＵ）
次に、トランザクションサービスおよび接続管理サービスで用いられるＬＰＰのプロトコルデータユニット（ＰＤＵ）について説明する。
２．４．１ トランザクションサービスのプロトコルデータユニット
トランザクションサービスで用いられる、プロトコルデータユニットはその利用シーンに応じて図４３に示す７種類存在する。トランザクションサービスで用いられるＰＤＵはＰＤＵ種別毎に定義されるヘッダ部とアプリケーションデータが格納されるデータ部から構成される。ＰＤＵの基本構造を図４４に示す。
次に、トランザクションサービスおよび接続管理サービスで用いられるＬＰＰのプロトコルデータユニット（ＰＤＵ）について説明する。
２．４．１ トランザクションサービスのプロトコルデータユニット
トランザクションサービスで用いられる、プロトコルデータユニットはその利用シーンに応じて図４３に示す７種類存在する。トランザクションサービスで用いられるＰＤＵはＰＤＵ種別毎に定義されるヘッダ部とアプリケーションデータが格納されるデータ部から構成される。ＰＤＵの基本構造を図４４に示す。
２．４．１．１ Ｉｎｖｏｋｅ ＰＤＵ
図４５はＩｎｖｏｋｅ ＰＤＵのヘッダ情報を示す図である。
ＰＤＵ Ｔｙｐｅ：ＰＤＵのタイプ。Ｉｎｖｏｋｅ ＰＤＵでは常にＩｎｖｏｋｅ（１）。
Ｖｅｒｓｉｏｎ：ローカルポートプロトコルのバージョンを表す。現バージョンは０ｘ００。
ＴＴ：Ｔｒａｎｓａｃｔｉｏｎ Ｔｙｐｅの略。トランザクションのタイプを指定する。０：データ送信トランザクションサービス、１：リクエスト・レスポンス型トランザクションサービス。
ＲＡ：Ｒｅｑｕｉｒｅ Ａｃｋの略。再送処理が有効かどうかを表すフラグ。再送処理有効時は１。
ＲＤ：Ｒｅｔｒａｎｓｍｉｔｔｅｄ Ｄａｔａの略。再送されたデータかどうかを表すフラグ。再送時は１。
ＴＩＤ：トランザクションＩＤ。
ＲＥＳ：予約。
図４５はＩｎｖｏｋｅ ＰＤＵのヘッダ情報を示す図である。
ＰＤＵ Ｔｙｐｅ：ＰＤＵのタイプ。Ｉｎｖｏｋｅ ＰＤＵでは常にＩｎｖｏｋｅ（１）。
Ｖｅｒｓｉｏｎ：ローカルポートプロトコルのバージョンを表す。現バージョンは０ｘ００。
ＴＴ：Ｔｒａｎｓａｃｔｉｏｎ Ｔｙｐｅの略。トランザクションのタイプを指定する。０：データ送信トランザクションサービス、１：リクエスト・レスポンス型トランザクションサービス。
ＲＡ：Ｒｅｑｕｉｒｅ Ａｃｋの略。再送処理が有効かどうかを表すフラグ。再送処理有効時は１。
ＲＤ：Ｒｅｔｒａｎｓｍｉｔｔｅｄ Ｄａｔａの略。再送されたデータかどうかを表すフラグ。再送時は１。
ＴＩＤ：トランザクションＩＤ。
ＲＥＳ：予約。
２．４．１．２ Ｒｅｓｕｌｔ ＰＤＵ
図４６はＲｅｓｕｌｔ ＰＤＵのヘッダ情報を示す図である。
ＰＤＵ Ｔｙｐｅ：ＰＤＵのタイプ。Ｒｅｓｕｌｔ ＰＤＵでは常にＲｅｓｕｌｔ （２）。
ＲＡ：Ｒｅｑｕｉｒｅ Ａｃｋの略。再送処理が有効かどうかを表すフラグ。再送処理有効時は１。
ＲＤ：再送されたデータかどうかを表すフラグ。再送時は１。
ＴＩＤ：トランザクションＩＤ。
ＲＥＳ：予約。
図４６はＲｅｓｕｌｔ ＰＤＵのヘッダ情報を示す図である。
ＰＤＵ Ｔｙｐｅ：ＰＤＵのタイプ。Ｒｅｓｕｌｔ ＰＤＵでは常にＲｅｓｕｌｔ （２）。
ＲＡ：Ｒｅｑｕｉｒｅ Ａｃｋの略。再送処理が有効かどうかを表すフラグ。再送処理有効時は１。
ＲＤ：再送されたデータかどうかを表すフラグ。再送時は１。
ＴＩＤ：トランザクションＩＤ。
ＲＥＳ：予約。
２．４．１．３ Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ ＰＤＵ
図４７はＡｃｋｎｏｗｌｅｄｇｅｍｅｎｔ ＰＤＵのヘッダ情報を示す図である。
ＰＤＵ Ｔｙｐｅ：ＰＤＵのタイプ。 Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ ＰＤＵでは常にＡｃｋ （３）。
ＲＤ：再送されたデータかどうかを表すフラグ。再送時は１。
ＴＩＤ：トランザクションＩＤ。
ＲＥＳ：予約。
図４７はＡｃｋｎｏｗｌｅｄｇｅｍｅｎｔ ＰＤＵのヘッダ情報を示す図である。
ＰＤＵ Ｔｙｐｅ：ＰＤＵのタイプ。 Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ ＰＤＵでは常にＡｃｋ （３）。
ＲＤ：再送されたデータかどうかを表すフラグ。再送時は１。
ＴＩＤ：トランザクションＩＤ。
ＲＥＳ：予約。
２．４．１．４ Ａｂｏｒｔ ＰＤＵ
図４８はＡｂｏｒｔ ＰＤＵのヘッダ情報を示す図である。
ＰＤＵ Ｔｙｐｅ：ＰＤＵのタイプ。 Ａｂｏｒｔ ＰＤＵでは常にＡｂｏｒｔ（４）。
ＡＴ：破棄理由がシステムエラー（０）、ユーザ要求（１）のどちらによるものかを表すフラグ。
ＴＩＤ：トランザクションＩＤ。
Ａｂｏｒｔ Ｃｏｄｅ：トランザクションの破棄理由をコードとして指定。（図３８を参照）
ＲＥＳ：予約。
図４８はＡｂｏｒｔ ＰＤＵのヘッダ情報を示す図である。
ＰＤＵ Ｔｙｐｅ：ＰＤＵのタイプ。 Ａｂｏｒｔ ＰＤＵでは常にＡｂｏｒｔ（４）。
ＡＴ：破棄理由がシステムエラー（０）、ユーザ要求（１）のどちらによるものかを表すフラグ。
ＴＩＤ：トランザクションＩＤ。
Ａｂｏｒｔ Ｃｏｄｅ：トランザクションの破棄理由をコードとして指定。（図３８を参照）
ＲＥＳ：予約。
２．４．１．５ ＩｎｖｏｋｅＳｅｇｍｅｎｔ ＰＤＵ
図４９はＩｎｖｏｋｅ Ｓｅｇｍｅｎｔ ＰＤＵのヘッダ情報を示す図である。
ＰＤＵ Ｔｙｐｅ：ＰＤＵのタイプ。 Ｉｎｖｏｋｅ Ｓｅｇｍｅｎｔ ＰＤＵでは常にＩｎｖｏｋｅ Ｓｇｍ（５）。
Ｖｅｒｓｉｏｎ：ローカルポートプロトコルのバージョンを表す。現バージョンは０ｘ００。
ＴＴ：Ｔｒａｎｓａｃｔｉｏｎ Ｔｙｐｅの略。トランザクションのタイプを指定する。０：データ送信トランザクションサービス、１：リクエスト・レスポンス型トランザクションサービス。
ＦＩＮ：最終セグメントかどうかを表すフラグ。最終セグメントでは１。
ＲＤ：Ｒｅｔｒａｎｓｍｉｔｔｅｄ Ｄａｔａの略。再送されたデータかどうかを表すフラグ。再送時は１。
ＴＩＤ：トランザクションＩＤ。
Ｓｅｇｍｅｎｔ Ｎｏ：ＰＤＵの順序番号。
図４９はＩｎｖｏｋｅ Ｓｅｇｍｅｎｔ ＰＤＵのヘッダ情報を示す図である。
ＰＤＵ Ｔｙｐｅ：ＰＤＵのタイプ。 Ｉｎｖｏｋｅ Ｓｅｇｍｅｎｔ ＰＤＵでは常にＩｎｖｏｋｅ Ｓｇｍ（５）。
Ｖｅｒｓｉｏｎ：ローカルポートプロトコルのバージョンを表す。現バージョンは０ｘ００。
ＴＴ：Ｔｒａｎｓａｃｔｉｏｎ Ｔｙｐｅの略。トランザクションのタイプを指定する。０：データ送信トランザクションサービス、１：リクエスト・レスポンス型トランザクションサービス。
ＦＩＮ：最終セグメントかどうかを表すフラグ。最終セグメントでは１。
ＲＤ：Ｒｅｔｒａｎｓｍｉｔｔｅｄ Ｄａｔａの略。再送されたデータかどうかを表すフラグ。再送時は１。
ＴＩＤ：トランザクションＩＤ。
Ｓｅｇｍｅｎｔ Ｎｏ：ＰＤＵの順序番号。
２．４．１．６ Ｒｅｓｕｌｔ Ｓｅｇｍｅｎｔ ＰＤＵ
図５０はＲｅｓｕｌｔ Ｓｅｇｍｅｎｔ ＰＤＵのヘッダ情報を示す図である。
ＰＤＵ Ｔｙｐｅ：ＰＤＵのタイプ。ＲｅｓｕｌｔＳｅｇｍｅｎｔＰＤＵでは常にＲｅｓｕｌｔＳｇｍ （６）。
ＦＩＮ：最終セグメントかどうかを表すフラグ。最終セグメントでは１。
ＲＤ：再送されたデータかどうかを表すフラグ。再送時は１。
ＴＩＤ：トランザクションＩＤ。
ＲＥＳ：予約。
Ｓｅｇｍｅｎｔ Ｎｏ：ＰＤＵの順序番号。
図５０はＲｅｓｕｌｔ Ｓｅｇｍｅｎｔ ＰＤＵのヘッダ情報を示す図である。
ＰＤＵ Ｔｙｐｅ：ＰＤＵのタイプ。ＲｅｓｕｌｔＳｅｇｍｅｎｔＰＤＵでは常にＲｅｓｕｌｔＳｇｍ （６）。
ＦＩＮ：最終セグメントかどうかを表すフラグ。最終セグメントでは１。
ＲＤ：再送されたデータかどうかを表すフラグ。再送時は１。
ＴＩＤ：トランザクションＩＤ。
ＲＥＳ：予約。
Ｓｅｇｍｅｎｔ Ｎｏ：ＰＤＵの順序番号。
２．４．１．７ Ｎａｃｋ ＰＤＵ
図５１はＮａｃｋ ＰＤＵのヘッダ情報を示す図である。
ＰＤＵ Ｔｙｐｅ：ＰＤＵのタイプ。Ｎａｃｋ ＰＤＵでは常にＮａｃｋ （７）。
ＲＤ：再送されたデータかどうかを表すフラグ．再送時は１。
ＴＩＤ：トランザクションＩＤ。
ＲＥＳ：予約。
Ｎｕｍ Ｓｅｇ：未受信のＰＤＵの順序番号の数
Ｓｅｇｍｅｎｔ Ｎｕｍｂｅｒ Ｌｉｓｔ：未受信のＰＤＵの順序番号のリスト
図５１はＮａｃｋ ＰＤＵのヘッダ情報を示す図である。
ＰＤＵ Ｔｙｐｅ：ＰＤＵのタイプ。Ｎａｃｋ ＰＤＵでは常にＮａｃｋ （７）。
ＲＤ：再送されたデータかどうかを表すフラグ．再送時は１。
ＴＩＤ：トランザクションＩＤ。
ＲＥＳ：予約。
Ｎｕｍ Ｓｅｇ：未受信のＰＤＵの順序番号の数
Ｓｅｇｍｅｎｔ Ｎｕｍｂｅｒ Ｌｉｓｔ：未受信のＰＤＵの順序番号のリスト
２．４．２ 接続管理サービスのプロトコルデータユニット
ローカルポートプロトコルの接続管理サービスは、ＤＳＲＣの新規接続時や、受信可能ポートが増減した場合に、相手局の接続管理サービスに対して、ローカルポート制御プロトコルの転送サービスを利用し、受信可能ポートリストや受信不可ポートを通知する。以下に示すＰＤＵはこれらの通知で用いられるプロトコルデータユニットであり、ローカルポート制御プロトコルのユーザデータ部に格納される。
ローカルポートプロトコルの接続管理サービスは、ＤＳＲＣの新規接続時や、受信可能ポートが増減した場合に、相手局の接続管理サービスに対して、ローカルポート制御プロトコルの転送サービスを利用し、受信可能ポートリストや受信不可ポートを通知する。以下に示すＰＤＵはこれらの通知で用いられるプロトコルデータユニットであり、ローカルポート制御プロトコルのユーザデータ部に格納される。
２．４．２．１ 受信可能ポートリスト通知におけるプロトコルデータユニット
図５２は受信可能ポートリスト通知におけるプロトコルデータユニットを示す図である。
Ｓｔａｔｕｓ：イベントの種別を表す。受信可能ポートリスト通知の場合は、ａｃｃｅｐｔ Ｐｏｒｔ Ｌｉｓｔ（１）を常に格納する。
Ｎｕｍ Ｐｏｒｔｓ：受信可能ポート番号の数を格納する。
Ａｃｃｅｐｔ Ｐｏｒｔ Ｌｉｓｔ：受信可能ポート番号のリストを格納する。
図５２は受信可能ポートリスト通知におけるプロトコルデータユニットを示す図である。
Ｓｔａｔｕｓ：イベントの種別を表す。受信可能ポートリスト通知の場合は、ａｃｃｅｐｔ Ｐｏｒｔ Ｌｉｓｔ（１）を常に格納する。
Ｎｕｍ Ｐｏｒｔｓ：受信可能ポート番号の数を格納する。
Ａｃｃｅｐｔ Ｐｏｒｔ Ｌｉｓｔ：受信可能ポート番号のリストを格納する。
２．４．２．２ 受信不可ポート通知におけるプロトコルデータユニット
図５３は送信不可ポート通知におけるプロトコルデータユニットを示す図である。
Ｓｔａｔｕｓ：イベントの種別を表す。受信不可ポート通知の場合は、ｒｅｊｅｃｔＰｏｒｔ（２）を常に格納する。
Ｒｅｊｅｃｔ Ｐｏｒｔ：受信不可ポート番号を格納する。
図５３は送信不可ポート通知におけるプロトコルデータユニットを示す図である。
Ｓｔａｔｕｓ：イベントの種別を表す。受信不可ポート通知の場合は、ｒｅｊｅｃｔＰｏｒｔ（２）を常に格納する。
Ｒｅｊｅｃｔ Ｐｏｒｔ：受信不可ポート番号を格納する。
２．５ 処理手順
ＬＰＰにおける処理手順について説明する。
２．５．１ 初期接続手順
（１）通常アプリの初期接続手順
図５４はローカルポートプロトコルの初期接続手順を示す図である。
（ａ） 移動局及び基地局の各アプリケーションは受信可能なポート番号をポート登録プリミティブ（Ｒｅｇｉｓｔｅｒ Ｐｏｒｔ）を用いて、ＬＰＰに登録する。
（ｂ） ＬＰＰは接続管理テーブルを更新し、前記（ａ）で登録された受信可能ポート番号および接続管理サービスポートをデータ受信ポートとしてＬＰＣＰに登録する。また、管理サービスポートはイベント受信ポートとしてもＬＰＣＰに登録する。
（ｃ） 各アプリはＱｕｅｒｙ ＬＩＤパラメータを未指定、Ｑｕｅｒｙ Ｐｏｒｔパラメータを指定し、ＤＳＲＣ接続問い合わせプリミティブ（Ｃｏｎｎｅｃｔ．ｒｅｑ）を発行し、ＤＳＲＣ接続を待ち合わせる（ブロッキング呼出）。
（ｄ） ＬＰＰの接続管理サービスは、ＬＰＣＰからイベント通知プリミティブ（Ｅｖｅｎｔ Ｒｅｐｏｒｔ）で、イベント「ＤＳＲＣ接続通知（９６）」を受領する。
（ｅ） ＬＰＰの接続管理サービスは同プリミティブで受信したＬＩＤの接続管理テーブルを作成するとともに、相手局の接続管理サービスポートに対して、受信可能ポートリストを送信する。
（ｆ） ＬＰＰの接続管理サービスが、ＬＰＣＰからデータ転送プリミティブ（Ｓｅｎｄ Ｕｎｉｔ Ｄａｔａ．ｉｎｄ）で、受信可能ポートリストを受領すると、同プリミティブで通知されたＬＩＤの接続管理テーブルに受信可能ポートを登録する。以降は同ＬＩＤに対するトランザクション開始要求はこの受信可能ポートに対してのみ受け付ける。
（ｇ） 前記（ｅ）で受信した受信可能ポートリストに含まれるポート番号に対して、ＤＳＲＣ接続問い合わせプリミティブ（Ｃｏｎｎｅｃｔ．ｒｅｑ）を発行しているアプリケーションに対して、ＤＳＲＣ接続通知プリミティブ（Ｃｏｎｎｅｃｔ．ｃｎｆ）にて、ＬＩＤおよび送信可能ポート番号を通知する。
（ｈ） アプリケーションがＤＳＲＣ接続通知プリミティブ（Ｃｏｎｎｅｃｔ．ｃｎｆ）で通知されたＬＩＤもしくは同報アドレス、および送信先ポート番号に対して、トランザクション開始要求プリミティブ（Ｉｎｖｏｋｅ．ｒｅｑ）を発行することで、トランザクションが開始される。
ＬＰＰにおける処理手順について説明する。
２．５．１ 初期接続手順
（１）通常アプリの初期接続手順
図５４はローカルポートプロトコルの初期接続手順を示す図である。
（ａ） 移動局及び基地局の各アプリケーションは受信可能なポート番号をポート登録プリミティブ（Ｒｅｇｉｓｔｅｒ Ｐｏｒｔ）を用いて、ＬＰＰに登録する。
（ｂ） ＬＰＰは接続管理テーブルを更新し、前記（ａ）で登録された受信可能ポート番号および接続管理サービスポートをデータ受信ポートとしてＬＰＣＰに登録する。また、管理サービスポートはイベント受信ポートとしてもＬＰＣＰに登録する。
（ｃ） 各アプリはＱｕｅｒｙ ＬＩＤパラメータを未指定、Ｑｕｅｒｙ Ｐｏｒｔパラメータを指定し、ＤＳＲＣ接続問い合わせプリミティブ（Ｃｏｎｎｅｃｔ．ｒｅｑ）を発行し、ＤＳＲＣ接続を待ち合わせる（ブロッキング呼出）。
（ｄ） ＬＰＰの接続管理サービスは、ＬＰＣＰからイベント通知プリミティブ（Ｅｖｅｎｔ Ｒｅｐｏｒｔ）で、イベント「ＤＳＲＣ接続通知（９６）」を受領する。
（ｅ） ＬＰＰの接続管理サービスは同プリミティブで受信したＬＩＤの接続管理テーブルを作成するとともに、相手局の接続管理サービスポートに対して、受信可能ポートリストを送信する。
（ｆ） ＬＰＰの接続管理サービスが、ＬＰＣＰからデータ転送プリミティブ（Ｓｅｎｄ Ｕｎｉｔ Ｄａｔａ．ｉｎｄ）で、受信可能ポートリストを受領すると、同プリミティブで通知されたＬＩＤの接続管理テーブルに受信可能ポートを登録する。以降は同ＬＩＤに対するトランザクション開始要求はこの受信可能ポートに対してのみ受け付ける。
（ｇ） 前記（ｅ）で受信した受信可能ポートリストに含まれるポート番号に対して、ＤＳＲＣ接続問い合わせプリミティブ（Ｃｏｎｎｅｃｔ．ｒｅｑ）を発行しているアプリケーションに対して、ＤＳＲＣ接続通知プリミティブ（Ｃｏｎｎｅｃｔ．ｃｎｆ）にて、ＬＩＤおよび送信可能ポート番号を通知する。
（ｈ） アプリケーションがＤＳＲＣ接続通知プリミティブ（Ｃｏｎｎｅｃｔ．ｃｎｆ）で通知されたＬＩＤもしくは同報アドレス、および送信先ポート番号に対して、トランザクション開始要求プリミティブ（Ｉｎｖｏｋｅ．ｒｅｑ）を発行することで、トランザクションが開始される。
（２）高速接続アプリの初期接続手順
高速接続とは初期接続のための処理を一部省略することにより、高速な初期接続を実現する手法である。図５５は高速接続アプリの初期接続シーケンス例を示す図である。
（ａ） 移動局及び基地局の各アプリケーションは受信可能なポート番号をポート登録プリミティブ（Ｒｅｇｉｓｔｅｒ Ｐｏｒｔ）を用いて、ＬＰＰに登録する。
（ｂ） ＬＰＰは接続管理テーブルを更新し、受信可能ポート番号をＬＰＣＰに登録する。
（ｃ） 各アプリはＱｕｅｒｙＬＩＤおよびＱｕｅｒｙ Ｐｏｒｔを共に未指定で、トランザクション開始可能問い合わせプリミティブ（Ｃｏｎｎｅｃｔ．ｒｅｑ）を発行し、ＤＳＲＣ接続を待ち合わせる。
（ｄ） ＬＰＣＰからイベント通知プリミティブ（ＥｖｅｎｔＲｅｐｏｒｔ．ｉｎｄ）で、イベント「ＤＳＲＣ接続通知（９６）」を受領する。
（ｅ） ＬＰＰは同プリミティブで受信したＬＩＤの接続管理テーブルを作成する。高速接続を必要とするアプリのため、以後、相手局のＬＰＰ接続管理サービスから、相手局側の受信可能ポートリストを受信するまでは、このＬＩＤおよび同報アドレスの全てのポートに対するトランザクションの開始要求を受け付ける。
（ｆ） ＤＳＲＣ接続問い合わせプリミティブ（Ｃｏｎｎｅｃｔ．ｒｅｑ）を発行しているアプリケーションに対して、ＤＳＲＣ接続通知プリミティブ（Ｃｏｎｎｅｃｔ．ｃｎｆ）にて、ＬＩＤを通知する。
（ｇ） 各アプリはＤＳＲＣ接続通知プリミティブで通知されたＬＩＤもしくは同報アドレスに対するトランザクション開始要求プリミティブ（Ｉｎｖｏｋｅ．ｒｅｑ）を発行し、トランザクションを開始する。
（ｈ） 前記（ｇ）で指定したポート番号が相手局に存在する場合は、このトランザクションは成功する。前記（ｇ）で指定したポート番号が相手局に存在しない場合は、相手局のＬＰＣＰからイベント通知プリミティブで、イベント「送信先ローカルポートが有効でない（１２９）」が通知され、このＬＩＤの接続管理テーブルを更新する。Ｔｒａｎｓａｃｔｉｏｎ Ｔｙｐｅ＝１の場合は、該当するアプリケーションにトランザクション破棄通知プリミティブ（Ａｂｏｒｔ．ｉｎｄ）でトランザクションの失敗を通知する。これ以後に、このＬＩＤとポートの組に対し、Ｔｒａｎｓａｃｔｉｏｎ Ｔｙｐｅ＝１のトランザクション開始要求（Ｉｎｖｏｋｅ．ｒｅｑ）があった場合は、トランザクション破棄プリミティブ（Ａｂｏｒｔ．ｉｎｄ）にてトランザクションの破棄を通知する。
高速接続とは初期接続のための処理を一部省略することにより、高速な初期接続を実現する手法である。図５５は高速接続アプリの初期接続シーケンス例を示す図である。
（ａ） 移動局及び基地局の各アプリケーションは受信可能なポート番号をポート登録プリミティブ（Ｒｅｇｉｓｔｅｒ Ｐｏｒｔ）を用いて、ＬＰＰに登録する。
（ｂ） ＬＰＰは接続管理テーブルを更新し、受信可能ポート番号をＬＰＣＰに登録する。
（ｃ） 各アプリはＱｕｅｒｙＬＩＤおよびＱｕｅｒｙ Ｐｏｒｔを共に未指定で、トランザクション開始可能問い合わせプリミティブ（Ｃｏｎｎｅｃｔ．ｒｅｑ）を発行し、ＤＳＲＣ接続を待ち合わせる。
（ｄ） ＬＰＣＰからイベント通知プリミティブ（ＥｖｅｎｔＲｅｐｏｒｔ．ｉｎｄ）で、イベント「ＤＳＲＣ接続通知（９６）」を受領する。
（ｅ） ＬＰＰは同プリミティブで受信したＬＩＤの接続管理テーブルを作成する。高速接続を必要とするアプリのため、以後、相手局のＬＰＰ接続管理サービスから、相手局側の受信可能ポートリストを受信するまでは、このＬＩＤおよび同報アドレスの全てのポートに対するトランザクションの開始要求を受け付ける。
（ｆ） ＤＳＲＣ接続問い合わせプリミティブ（Ｃｏｎｎｅｃｔ．ｒｅｑ）を発行しているアプリケーションに対して、ＤＳＲＣ接続通知プリミティブ（Ｃｏｎｎｅｃｔ．ｃｎｆ）にて、ＬＩＤを通知する。
（ｇ） 各アプリはＤＳＲＣ接続通知プリミティブで通知されたＬＩＤもしくは同報アドレスに対するトランザクション開始要求プリミティブ（Ｉｎｖｏｋｅ．ｒｅｑ）を発行し、トランザクションを開始する。
（ｈ） 前記（ｇ）で指定したポート番号が相手局に存在する場合は、このトランザクションは成功する。前記（ｇ）で指定したポート番号が相手局に存在しない場合は、相手局のＬＰＣＰからイベント通知プリミティブで、イベント「送信先ローカルポートが有効でない（１２９）」が通知され、このＬＩＤの接続管理テーブルを更新する。Ｔｒａｎｓａｃｔｉｏｎ Ｔｙｐｅ＝１の場合は、該当するアプリケーションにトランザクション破棄通知プリミティブ（Ａｂｏｒｔ．ｉｎｄ）でトランザクションの失敗を通知する。これ以後に、このＬＩＤとポートの組に対し、Ｔｒａｎｓａｃｔｉｏｎ Ｔｙｐｅ＝１のトランザクション開始要求（Ｉｎｖｏｋｅ．ｒｅｑ）があった場合は、トランザクション破棄プリミティブ（Ａｂｏｒｔ．ｉｎｄ）にてトランザクションの破棄を通知する。
２．５．２ データ送信トランザクションサービスのデータ転送手順
（１）送信処理
（ａ） アプリケーションがＴｒａｎｓａｃｔｉｏｎ Ｔｙｐｅ＝０でトランザクション開始要求プリミティブ（Ｉｎｖｏｋｅ．ｒｅｑ）を発行することでデータ送信サービスのトランザクションが開始される。
（ｂ） 指定されたＬＩＤと送信元ポート番号の組が受信拒否ポートの場合は、アプリケーションに対してＡｂｏｒｔ．ｉｎｄにて、状態「受信拒否ポート通知」を通知し、このトランザクションは完了する。
（ｃ） 指定されたメッセージがＭＴＵを越えており、分割・組立処理をサポートしていない場合は、アプリケーションに対してＡｂｏｒｔ．ｉｎｄにて、状態「ＭＴＵエラー」を通知し、このトランザクションは完了する。分割・組立処理をサポートしている場合の処理については２．５．５節に記述する。
（ｄ） 前記（ｂ）と前記（ｃ）以外の場合は、ＴＴ＝０であるＩｎｖｏｋｅ ＰＤＵを作成し、ＬＰＣＰの転送プリミティブ（ＴｒａｎｓｆｅｒＤａｔａ．ｒｅｑ）を用いて、相手局に送信する。なお、再送処理が有効な場合の処理については、２．５．４節に記述する。
（２）受信処理
（ａ） ＬＰＣＰの転送プリミティブ（ＴｒａｎｓｆｅｒＤａｔａ．ｉｎｄ）により、前記（１）−（ｄ）で送信されたＩｎｖｏｋｅ ＰＤＵを受信すると、アプリケーションに対して、トランザクション通知プリミティブ（Ｉｎｖｏｋｅ．ｉｎｄ）を用いて、受信データを通知する。
図５６にデータ送信トランザクションサービスのデータ転送手順の処理シーケンス例を示す。
（１）送信処理
（ａ） アプリケーションがＴｒａｎｓａｃｔｉｏｎ Ｔｙｐｅ＝０でトランザクション開始要求プリミティブ（Ｉｎｖｏｋｅ．ｒｅｑ）を発行することでデータ送信サービスのトランザクションが開始される。
（ｂ） 指定されたＬＩＤと送信元ポート番号の組が受信拒否ポートの場合は、アプリケーションに対してＡｂｏｒｔ．ｉｎｄにて、状態「受信拒否ポート通知」を通知し、このトランザクションは完了する。
（ｃ） 指定されたメッセージがＭＴＵを越えており、分割・組立処理をサポートしていない場合は、アプリケーションに対してＡｂｏｒｔ．ｉｎｄにて、状態「ＭＴＵエラー」を通知し、このトランザクションは完了する。分割・組立処理をサポートしている場合の処理については２．５．５節に記述する。
（ｄ） 前記（ｂ）と前記（ｃ）以外の場合は、ＴＴ＝０であるＩｎｖｏｋｅ ＰＤＵを作成し、ＬＰＣＰの転送プリミティブ（ＴｒａｎｓｆｅｒＤａｔａ．ｒｅｑ）を用いて、相手局に送信する。なお、再送処理が有効な場合の処理については、２．５．４節に記述する。
（２）受信処理
（ａ） ＬＰＣＰの転送プリミティブ（ＴｒａｎｓｆｅｒＤａｔａ．ｉｎｄ）により、前記（１）−（ｄ）で送信されたＩｎｖｏｋｅ ＰＤＵを受信すると、アプリケーションに対して、トランザクション通知プリミティブ（Ｉｎｖｏｋｅ．ｉｎｄ）を用いて、受信データを通知する。
図５６にデータ送信トランザクションサービスのデータ転送手順の処理シーケンス例を示す。
２．５．３ リクエスト・レスポンス型トランザクションサービスのデータ転送手順
（１）送信処理
（ａ） アプリケーションがＴｒａｎｓａｃｔｉｏｎ Ｔｙｐｅ＝１でトランザクション開始要求プリミティブ（Ｉｎｖｏｋｅ．ｒｅｑ）を発行することでリクエスト・レスポンス型トランザクションサービスのトランザクションが開始される。
（ｂ） 指定されたＬＩＤと送信元ポート番号の組が受信拒否ポートの場合は、アプリケーションに対してＡｂｏｒｔ．ｉｎｄにて、状態「受信拒否ポート通知」を通知し、このトランザクションは完了する。
（ｃ） 同時に実行可能なトランザクション数を越える場合は、アプリケーションに対してＡｂｏｒｔ．ｉｎｄにて、状態「トランザクションが開始できなかった」を通知し、このトランザクションは完了する。
（ｄ） 指定されたメッセージがＭＴＵを越えており、分割・組立処理をサポートしていない場合は、アプリケーションに対してＡｂｏｒｔ．ｉｎｄにて、状態「ＭＴＵエラー」を通知し、このトランザクションは完了する。分割・組立処理をサポートしている場合の処理については２．５．５節に記述する。
（ｅ） 前記（ｂ）と前記（ｃ）と前記（ｄ）以外の場合は、ＴＴ＝１であるＩｎｖｏｋｅ ＰＤＵを作成し、ＬＰＣＰの転送プリミティブ（ＴｒａｎｓｆｅｒＤａｔａ．ｒｅｑ）を用いて、相手局に送信後、Ｒｅｓｕｌｔタイマー（Ｒｅｓｕｌｔタイマーのタイムアウト値はＩｎｖｏｋｅ．ｒｅｑにより指定）を起動し、相手局からのＲｅｓｕｌｔ ＰＤＵの受信を待ちうける。
（ｆ） 前記（ｅ）で起動したＲｅｓｕｌｔタイマーがタイムアウトすると、ＡＴ＝０、Ａｂｏｒｔ Ｃｏｄｅ＝０ｘ０８であるＡｂｏｒｔ ＰＤＵを生成し、相手局に対して状態「Ｒｅｓｕｌｔタイマータイムアウト」を通知するとともに、トランザクション破棄通知プリミティブ（Ａｂｏｒｔ．ｉｎｄ）でトランザクションの失敗をアプリケーションに対して通知する。
（ｇ） Ｒｅｓｕｌｔタイマーのタイムアウト前に、ＬＰＣＰの転送プリミティブ（ＴｒａｎｓｆｅｒＤａｔａ．ｉｎｄ）により、相手局から送信されたＲｅｓｕｌｔ ＰＤＵを受信すると、前記（ｅ）で起動したＲｅｓｕｌｔタイマーを停止するとともに、応答通知プリミティブ（Ｉｎｖｏｋｅ．ｃｎｆ）により応答データをアプリケーションに対して通知する。
（１）送信処理
（ａ） アプリケーションがＴｒａｎｓａｃｔｉｏｎ Ｔｙｐｅ＝１でトランザクション開始要求プリミティブ（Ｉｎｖｏｋｅ．ｒｅｑ）を発行することでリクエスト・レスポンス型トランザクションサービスのトランザクションが開始される。
（ｂ） 指定されたＬＩＤと送信元ポート番号の組が受信拒否ポートの場合は、アプリケーションに対してＡｂｏｒｔ．ｉｎｄにて、状態「受信拒否ポート通知」を通知し、このトランザクションは完了する。
（ｃ） 同時に実行可能なトランザクション数を越える場合は、アプリケーションに対してＡｂｏｒｔ．ｉｎｄにて、状態「トランザクションが開始できなかった」を通知し、このトランザクションは完了する。
（ｄ） 指定されたメッセージがＭＴＵを越えており、分割・組立処理をサポートしていない場合は、アプリケーションに対してＡｂｏｒｔ．ｉｎｄにて、状態「ＭＴＵエラー」を通知し、このトランザクションは完了する。分割・組立処理をサポートしている場合の処理については２．５．５節に記述する。
（ｅ） 前記（ｂ）と前記（ｃ）と前記（ｄ）以外の場合は、ＴＴ＝１であるＩｎｖｏｋｅ ＰＤＵを作成し、ＬＰＣＰの転送プリミティブ（ＴｒａｎｓｆｅｒＤａｔａ．ｒｅｑ）を用いて、相手局に送信後、Ｒｅｓｕｌｔタイマー（Ｒｅｓｕｌｔタイマーのタイムアウト値はＩｎｖｏｋｅ．ｒｅｑにより指定）を起動し、相手局からのＲｅｓｕｌｔ ＰＤＵの受信を待ちうける。
（ｆ） 前記（ｅ）で起動したＲｅｓｕｌｔタイマーがタイムアウトすると、ＡＴ＝０、Ａｂｏｒｔ Ｃｏｄｅ＝０ｘ０８であるＡｂｏｒｔ ＰＤＵを生成し、相手局に対して状態「Ｒｅｓｕｌｔタイマータイムアウト」を通知するとともに、トランザクション破棄通知プリミティブ（Ａｂｏｒｔ．ｉｎｄ）でトランザクションの失敗をアプリケーションに対して通知する。
（ｇ） Ｒｅｓｕｌｔタイマーのタイムアウト前に、ＬＰＣＰの転送プリミティブ（ＴｒａｎｓｆｅｒＤａｔａ．ｉｎｄ）により、相手局から送信されたＲｅｓｕｌｔ ＰＤＵを受信すると、前記（ｅ）で起動したＲｅｓｕｌｔタイマーを停止するとともに、応答通知プリミティブ（Ｉｎｖｏｋｅ．ｃｎｆ）により応答データをアプリケーションに対して通知する。
（２）受信処理
（ａ） ＬＰＣＰの転送プリミティブ（ＴｒａｎｓｆｅｒＤａｔａ．ｉｎｄ）により、相手局から送信されたＩｎｖｏｋｅ ＰＤＵを受信すると、アプリケーションに対して、トランザクション通知プリミティブ（Ｉｎｖｏｋｅ．ｉｎｄ）を用いて、受信データを通知し、アプリケーションからの応答プリミティブ（Ｉｎｖｏｋｅ．ｒｅｓ）の受信を待つ。
（ｂ） ＬＰＣＰの転送プリミティブ（ＴｒａｎｓｆｅｒＤａｔａ．ｉｎｄ）により、相手局から送信されたＡｂｏｒｔ ＰＤＵを受信した場合は、トランザクション破棄通知プリミティブ（Ａｂｏｒｔ．ｉｎｄ）を発行し、トランザクションの失敗をアプリケーションに対して通知し、このトランザクションは完了する。
（ｃ） アプリケーションが応答プリミティブ（Ｉｎｖｏｋｅ．ｒｅｓ）を発行し、ＬＰＰに対して応答の送信を要求する。
（ｄ） Ｒｅｓｕｌｔ ＰＤＵ を生成し、ＬＰＣＰの転送プリミティブ（ＴｒａｎｓｆｅｒＤａｔａ．ｒｅｑ）により、相手局に対して送信する。
図５７にリクエスト・レスポンス型トランザクションサービスの基本処理シーケンス例を、図５８にＲｅｓｕｌｔタイマーがタイムアウトした場合の処理シーケンス例を示す。
（ａ） ＬＰＣＰの転送プリミティブ（ＴｒａｎｓｆｅｒＤａｔａ．ｉｎｄ）により、相手局から送信されたＩｎｖｏｋｅ ＰＤＵを受信すると、アプリケーションに対して、トランザクション通知プリミティブ（Ｉｎｖｏｋｅ．ｉｎｄ）を用いて、受信データを通知し、アプリケーションからの応答プリミティブ（Ｉｎｖｏｋｅ．ｒｅｓ）の受信を待つ。
（ｂ） ＬＰＣＰの転送プリミティブ（ＴｒａｎｓｆｅｒＤａｔａ．ｉｎｄ）により、相手局から送信されたＡｂｏｒｔ ＰＤＵを受信した場合は、トランザクション破棄通知プリミティブ（Ａｂｏｒｔ．ｉｎｄ）を発行し、トランザクションの失敗をアプリケーションに対して通知し、このトランザクションは完了する。
（ｃ） アプリケーションが応答プリミティブ（Ｉｎｖｏｋｅ．ｒｅｓ）を発行し、ＬＰＰに対して応答の送信を要求する。
（ｄ） Ｒｅｓｕｌｔ ＰＤＵ を生成し、ＬＰＣＰの転送プリミティブ（ＴｒａｎｓｆｅｒＤａｔａ．ｒｅｑ）により、相手局に対して送信する。
図５７にリクエスト・レスポンス型トランザクションサービスの基本処理シーケンス例を、図５８にＲｅｓｕｌｔタイマーがタイムアウトした場合の処理シーケンス例を示す。
２．５．４ 再送処理が有効な場合のデータ転送手順
再送処理は、Ｉｎｖｏｋｅ．ｒｅｑおよびＩｎｖｏｋｅ．ｒｅｓにおいてＲｅｑｕｉｒｅ Ａｃｋ＝１を指定した場合に適用する。以下ではデータ送信トランザクションのＩｎｖｏｋｅ．ｒｅｑに再送処理を適用した場合のシーケンスを記述する。リクエスト・レスポンス型トランザクションサービスにおいては、Ｉｎｖｏｋｅ．ｒｅｓについても同様の処理が適用可能である。
（１）送信処理
（ａ） アプリケーションがＲｅｑｕｉｒｅ Ａｃｋ＝１でトランザクション開始要求プリミティブ（Ｉｎｖｏｋｅ．ｒｅｑ）を発行することで再送処理が有効なデータ転送サービスが開始される。
（ｂ） ＲＡ＝１であるＩｎｖｏｋｅ ＰＤＵを作成し、ＬＰＣＰの転送プリミティブ（ＴｒａｎｓｆｅｒＤａｔａ．ｒｅｑ）を用いて、相手局に送信後、再送タイマーを起動し、相手局からのＡｃｋｎｏｗｌｅｄｇｅｍｅｎｔ ＰＤＵの受信を待つ。
（ｃ） 前記（ｂ）で送信されたＩｎｖｏｋｅ ＰＤＵが到達しないなど何らかの理由により、Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ ＰＤＵ受信前に、前記（ｂ）で起動した再送タイマーがタイムアウトした場合は、前記（ｂ）で送信したＩｎｖｏｋｅ ＰＤＵのＲＤフラグを１にセットして、相手局に再送信後、再送タイマーを再起動し、再送カウンタをインクリメントする。
（ｄ） 何度か再送を繰り返した後、再送カウンタが最大再送回数を超えた場合は、ＡＴ＝０、Ａｂｏｒｔ Ｃｏｄｅ＝０ｘ０７であるＡｂｏｒｔ ＰＤＵ（２．４．１．４節参照）を生成し、状態「再送タイマタイムアウト」を相手局に対して通知するとともに、トランザクション破棄通知プリミティブ（Ａｂｏｒｔ．ｉｎｄ）でトランザクションの失敗をアプリケーションに対して通知し、このトランザクションを完了する。
（ｅ） 再送タイマーのタイムアウト前に、ＬＰＣＰの転送プリミティブ（ＴｒａｎｓｆｅｒＤａｔａ．ｉｎｄ）により、相手局から送信されたＡｃｋｎｏｗｌｅｄｇｅｍｅｎｔ ＰＤＵを受信すると、前記（ｂ）または前記（ｃ）で起動した再送タイマーを停止し、このトランザクションを完了する。
再送処理は、Ｉｎｖｏｋｅ．ｒｅｑおよびＩｎｖｏｋｅ．ｒｅｓにおいてＲｅｑｕｉｒｅ Ａｃｋ＝１を指定した場合に適用する。以下ではデータ送信トランザクションのＩｎｖｏｋｅ．ｒｅｑに再送処理を適用した場合のシーケンスを記述する。リクエスト・レスポンス型トランザクションサービスにおいては、Ｉｎｖｏｋｅ．ｒｅｓについても同様の処理が適用可能である。
（１）送信処理
（ａ） アプリケーションがＲｅｑｕｉｒｅ Ａｃｋ＝１でトランザクション開始要求プリミティブ（Ｉｎｖｏｋｅ．ｒｅｑ）を発行することで再送処理が有効なデータ転送サービスが開始される。
（ｂ） ＲＡ＝１であるＩｎｖｏｋｅ ＰＤＵを作成し、ＬＰＣＰの転送プリミティブ（ＴｒａｎｓｆｅｒＤａｔａ．ｒｅｑ）を用いて、相手局に送信後、再送タイマーを起動し、相手局からのＡｃｋｎｏｗｌｅｄｇｅｍｅｎｔ ＰＤＵの受信を待つ。
（ｃ） 前記（ｂ）で送信されたＩｎｖｏｋｅ ＰＤＵが到達しないなど何らかの理由により、Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ ＰＤＵ受信前に、前記（ｂ）で起動した再送タイマーがタイムアウトした場合は、前記（ｂ）で送信したＩｎｖｏｋｅ ＰＤＵのＲＤフラグを１にセットして、相手局に再送信後、再送タイマーを再起動し、再送カウンタをインクリメントする。
（ｄ） 何度か再送を繰り返した後、再送カウンタが最大再送回数を超えた場合は、ＡＴ＝０、Ａｂｏｒｔ Ｃｏｄｅ＝０ｘ０７であるＡｂｏｒｔ ＰＤＵ（２．４．１．４節参照）を生成し、状態「再送タイマタイムアウト」を相手局に対して通知するとともに、トランザクション破棄通知プリミティブ（Ａｂｏｒｔ．ｉｎｄ）でトランザクションの失敗をアプリケーションに対して通知し、このトランザクションを完了する。
（ｅ） 再送タイマーのタイムアウト前に、ＬＰＣＰの転送プリミティブ（ＴｒａｎｓｆｅｒＤａｔａ．ｉｎｄ）により、相手局から送信されたＡｃｋｎｏｗｌｅｄｇｅｍｅｎｔ ＰＤＵを受信すると、前記（ｂ）または前記（ｃ）で起動した再送タイマーを停止し、このトランザクションを完了する。
（２）受信処理
（ａ） ＬＰＣＰの転送プリミティブ（ＴｒａｎｓｆｅｒＤａｔａ．ｉｎｄ）により、Ｉｎｖｏｋｅ ＰＤＵを受信すると、アプリケーションに対して、トランザクション通知プリミティブ（Ｉｎｖｏｋｅ．ｉｎｄ）を用いて、受信データを通知する。
（ｂ） 前記（ａ）で受信したＰＤＵのＲＡフラグが有効な場合は、Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ ＰＤＵを生成し、ＬＰＣＰの転送プリミティブ（ＴｒａｎｓｆｅｒＤａｔａ．ｒｅｑ）により、相手局に対してＡｃｋｎｏｗｌｅｄｇｅｍｅｎｔ ＰＤＵを送信し、ウェイトタイマーを起動する。
（ｃ） 前記（ｂ）で送信したＡｃｋｎｏｗｌｅｄｇｅｍｅｎｔ ＰＤＵが到達しないなどの理由で、前記（ａ）で受信したＩｎｖｏｋｅ ＰＤＵを再受信した場合は、このＰＤＵを破棄し、再度Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ ＰＤＵを生成し、ＬＰＣＰの転送プリミティブ（ＴｒａｎｓｆｅｒＤａｔａ．ｒｅｑ）により、相手局に対して送信し、ウェイトタイマーを再起動する。
（ｄ） 前記（ｂ）もしくは前記（ｃ）で起動したウェイトタイマーがタイムアウトすると、このトランザクションを完了する。
図５９に再送処理が有効な場合の処理シーケンス例を、図６０に再送が成功した場合の処理シーケンス例を、図６１に再送処理が失敗した場合の処理シーケンス例を示す。
（ａ） ＬＰＣＰの転送プリミティブ（ＴｒａｎｓｆｅｒＤａｔａ．ｉｎｄ）により、Ｉｎｖｏｋｅ ＰＤＵを受信すると、アプリケーションに対して、トランザクション通知プリミティブ（Ｉｎｖｏｋｅ．ｉｎｄ）を用いて、受信データを通知する。
（ｂ） 前記（ａ）で受信したＰＤＵのＲＡフラグが有効な場合は、Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ ＰＤＵを生成し、ＬＰＣＰの転送プリミティブ（ＴｒａｎｓｆｅｒＤａｔａ．ｒｅｑ）により、相手局に対してＡｃｋｎｏｗｌｅｄｇｅｍｅｎｔ ＰＤＵを送信し、ウェイトタイマーを起動する。
（ｃ） 前記（ｂ）で送信したＡｃｋｎｏｗｌｅｄｇｅｍｅｎｔ ＰＤＵが到達しないなどの理由で、前記（ａ）で受信したＩｎｖｏｋｅ ＰＤＵを再受信した場合は、このＰＤＵを破棄し、再度Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ ＰＤＵを生成し、ＬＰＣＰの転送プリミティブ（ＴｒａｎｓｆｅｒＤａｔａ．ｒｅｑ）により、相手局に対して送信し、ウェイトタイマーを再起動する。
（ｄ） 前記（ｂ）もしくは前記（ｃ）で起動したウェイトタイマーがタイムアウトすると、このトランザクションを完了する。
図５９に再送処理が有効な場合の処理シーケンス例を、図６０に再送が成功した場合の処理シーケンス例を、図６１に再送処理が失敗した場合の処理シーケンス例を示す。
２．５．５ 分割・組立処理が有効な場合のメッセージ転送手順
分割・組立処理は、Ｉｎｖｏｋｅ．ｒｅｑおよびＩｎｖｏｋｅ．ｒｅｓにおいてＭＴＵを越えるメッセージを指定した場合に適用する。以下では、Ｉｎｖｏｋｅ．ｒｅｑに分割・組立処理を適用した場合のシーケンスを記述する。
（１）送信手順
（ａ） アプリケーションがＭＴＵよりも大きいサイズのメッセージを指定し、トランザクション開始要求プリミティブ（Ｉｎｖｏｋｅ．ｒｅｑ）を発行することで分割・組立処理が有効なデータ送信サービスのトランザクションが開始される。
（ｂ） 指定されたＬＩＤと送信元ポート番号の組が受信拒否ポートの場合は、アプリケーションに対してＡｂｏｒｔ．ｉｎｄにて、状態「受信拒否ポート通知」を通知する。
（ｃ） 指定されたＬＩＤと送信元ポート番号の組に対して、すでに分割・組立処理が必要なトランザクションが実行されている場合は、アプリケーションに対してＡｂｏｒｔ．ｉｎｄにて、状態「分割転送中」を通知する。
（ｄ） 前記（ｂ）と前記（ｃ）以外の場合、送信データを先頭から順にＭＴＵで分割して、分割したセグメント毎にＩｎｖｏｋｅ Ｓｅｇｍｅｎｔ ＰＤＵ（２．４．１．５節参照）の規定に従ったヘッダを付加して、ＬＰＣＰの転送プリミティブ（ＴｒａｎｓｆｅｒＤａｔａ．ｒｅｑ）を用いて、順次送信要求を行う。
（ｅ） ＡＳＬの送信キューがオーバフローし、ＬＰＣＰからＥｖｅｎｔ Ｒｅｐｏｒｔ．ｉｎｄにて、状態「送信キューに空きがない、送信に失敗した」が通知されると、一定時間ウェイトし、送信が失敗したデータを含め、再度送信を開始する。
（ｆ） 最後のセグメントデータを送信後、再送タイマーを起動し、相手局からのＡｃｋｎｏｗｌｅｄｇｅｍｅｎｔ ＰＤＵ（２．４．１．３節参照）またはＮａｃｋ ＰＤＵ（２．４．１．７節参照）の受信を待つ。
（ｇ） ＬＰＣＰの転送プリミティブ（ＴｒａｎｓｆｅｒＤａｔａ．ｉｎｄ）により、相手局から送信されたＮａｃｋ ＰＤＵを受信すると、Ｎａｃｋ ＰＤＵのＳｅｇｍｅｎｔ Ｎｕｍｂｅｒ Ｌｉｓｔに指定されているセグメントを再送する。この際、再送するすべてのセグメントのＲＤフラグは１に、最後に再送するセグメントのＦＩＮフラグは１にセットする。全てのセグメントを再送信後、再送タイマーを起動し、相手局からのＡｃｋｎｏｗｌｅｄｇｅｍｅｎｔ ＰＤＵ（２．４．１．３節参照）、またはＮａｃｋ ＰＤＵの受信を待つ。
（ｈ） 前記（ｆ）または前記（ｇ）で起動した再送タイマーがタイムアウトした場合は、再度最終セグメントを送信し、再送タイマーを再起動する。
（ｉ） ＬＰＣＰの転送プリミティブ（ＴｒａｎｓｆｅｒＤａｔａ．ｉｎｄ）により、相手局から送信されたＡｃｋｎｏｗｌｅｄｇｅｍｅｎｔ ＰＤＵを受信すると、上位（ｆ）、前記（ｇ）、または前記（ｈ）で起動した再送タイマーを停止し、このトランザクションを完了する。
分割・組立処理は、Ｉｎｖｏｋｅ．ｒｅｑおよびＩｎｖｏｋｅ．ｒｅｓにおいてＭＴＵを越えるメッセージを指定した場合に適用する。以下では、Ｉｎｖｏｋｅ．ｒｅｑに分割・組立処理を適用した場合のシーケンスを記述する。
（１）送信手順
（ａ） アプリケーションがＭＴＵよりも大きいサイズのメッセージを指定し、トランザクション開始要求プリミティブ（Ｉｎｖｏｋｅ．ｒｅｑ）を発行することで分割・組立処理が有効なデータ送信サービスのトランザクションが開始される。
（ｂ） 指定されたＬＩＤと送信元ポート番号の組が受信拒否ポートの場合は、アプリケーションに対してＡｂｏｒｔ．ｉｎｄにて、状態「受信拒否ポート通知」を通知する。
（ｃ） 指定されたＬＩＤと送信元ポート番号の組に対して、すでに分割・組立処理が必要なトランザクションが実行されている場合は、アプリケーションに対してＡｂｏｒｔ．ｉｎｄにて、状態「分割転送中」を通知する。
（ｄ） 前記（ｂ）と前記（ｃ）以外の場合、送信データを先頭から順にＭＴＵで分割して、分割したセグメント毎にＩｎｖｏｋｅ Ｓｅｇｍｅｎｔ ＰＤＵ（２．４．１．５節参照）の規定に従ったヘッダを付加して、ＬＰＣＰの転送プリミティブ（ＴｒａｎｓｆｅｒＤａｔａ．ｒｅｑ）を用いて、順次送信要求を行う。
（ｅ） ＡＳＬの送信キューがオーバフローし、ＬＰＣＰからＥｖｅｎｔ Ｒｅｐｏｒｔ．ｉｎｄにて、状態「送信キューに空きがない、送信に失敗した」が通知されると、一定時間ウェイトし、送信が失敗したデータを含め、再度送信を開始する。
（ｆ） 最後のセグメントデータを送信後、再送タイマーを起動し、相手局からのＡｃｋｎｏｗｌｅｄｇｅｍｅｎｔ ＰＤＵ（２．４．１．３節参照）またはＮａｃｋ ＰＤＵ（２．４．１．７節参照）の受信を待つ。
（ｇ） ＬＰＣＰの転送プリミティブ（ＴｒａｎｓｆｅｒＤａｔａ．ｉｎｄ）により、相手局から送信されたＮａｃｋ ＰＤＵを受信すると、Ｎａｃｋ ＰＤＵのＳｅｇｍｅｎｔ Ｎｕｍｂｅｒ Ｌｉｓｔに指定されているセグメントを再送する。この際、再送するすべてのセグメントのＲＤフラグは１に、最後に再送するセグメントのＦＩＮフラグは１にセットする。全てのセグメントを再送信後、再送タイマーを起動し、相手局からのＡｃｋｎｏｗｌｅｄｇｅｍｅｎｔ ＰＤＵ（２．４．１．３節参照）、またはＮａｃｋ ＰＤＵの受信を待つ。
（ｈ） 前記（ｆ）または前記（ｇ）で起動した再送タイマーがタイムアウトした場合は、再度最終セグメントを送信し、再送タイマーを再起動する。
（ｉ） ＬＰＣＰの転送プリミティブ（ＴｒａｎｓｆｅｒＤａｔａ．ｉｎｄ）により、相手局から送信されたＡｃｋｎｏｗｌｅｄｇｅｍｅｎｔ ＰＤＵを受信すると、上位（ｆ）、前記（ｇ）、または前記（ｈ）で起動した再送タイマーを停止し、このトランザクションを完了する。
（２）受信手順
（ａ） アプリケーションがポート登録プリミティブ（Ｒｅｇｉｓｔｅｒ Ｐｏｒｔ）により、受信データ組立バッファ領域を指定しておく。
（ｂ） ＬＰＣＰの転送プリミティブ（ＴｒａｎｓｆｅｒＤａｔａ．ｉｎｄ）により、Ｉｎｖｏｋｅ Ｓｅｇｍｅｎｔ ＰＤＵを受信すると、アプリケーションから指定された受信キューに順次格納する。
（ｃ） 最終セグメントデータを受信すると、未受信のセグメントがないかどうかを確認し、未受信のセグメントデータが存在する場合は、Ｎａｃｋ ＰＤＵ（２．４．１．７節参照）を作成し、ＬＰＣＰの転送プリミティブ（ＴｒａｎｓｆｅｒＤａｔａ．ｒｅｑ）を用いて、相手局に送信し、以後受けるべき最終セグメント番号を記憶しておく。
（ｄ） 前記（ｃ）でＮａｃｋ ＰＤＵを送信後に、到着順の入れ替わりなどの理由で、ＲＤフラグがセットされていないデータを受信した場合は、そのデータを破棄する。
（ｅ） 最終セグメントデータを受信時に、全てのセグメントデータを受信していれば、トランザクション通知プリミティブ（Ｉｎｖｏｋｅ．ｉｎｄ）を用いて、アプリケーションに対して、受信データを通知するとともに、Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ ＰＤＵを生成し、ＬＰＣＰの転送プリミティブ（ＴｒａｎｓｆｅｒＤａｔａ．ｒｅｑ）により、相手局に対して送信する。
図６２に分割・組立処理が有効な場合の基本処理シーケンス例を、図６３に分割データの一部が欠落し、選択的再送処理が行われる場合の処理シーケンス例を、図６４に最終セグメントデータが欠落し、再送処理が行われる場合の処理シーケンス例を示す。
（ａ） アプリケーションがポート登録プリミティブ（Ｒｅｇｉｓｔｅｒ Ｐｏｒｔ）により、受信データ組立バッファ領域を指定しておく。
（ｂ） ＬＰＣＰの転送プリミティブ（ＴｒａｎｓｆｅｒＤａｔａ．ｉｎｄ）により、Ｉｎｖｏｋｅ Ｓｅｇｍｅｎｔ ＰＤＵを受信すると、アプリケーションから指定された受信キューに順次格納する。
（ｃ） 最終セグメントデータを受信すると、未受信のセグメントがないかどうかを確認し、未受信のセグメントデータが存在する場合は、Ｎａｃｋ ＰＤＵ（２．４．１．７節参照）を作成し、ＬＰＣＰの転送プリミティブ（ＴｒａｎｓｆｅｒＤａｔａ．ｒｅｑ）を用いて、相手局に送信し、以後受けるべき最終セグメント番号を記憶しておく。
（ｄ） 前記（ｃ）でＮａｃｋ ＰＤＵを送信後に、到着順の入れ替わりなどの理由で、ＲＤフラグがセットされていないデータを受信した場合は、そのデータを破棄する。
（ｅ） 最終セグメントデータを受信時に、全てのセグメントデータを受信していれば、トランザクション通知プリミティブ（Ｉｎｖｏｋｅ．ｉｎｄ）を用いて、アプリケーションに対して、受信データを通知するとともに、Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ ＰＤＵを生成し、ＬＰＣＰの転送プリミティブ（ＴｒａｎｓｆｅｒＤａｔａ．ｒｅｑ）により、相手局に対して送信する。
図６２に分割・組立処理が有効な場合の基本処理シーケンス例を、図６３に分割データの一部が欠落し、選択的再送処理が行われる場合の処理シーケンス例を、図６４に最終セグメントデータが欠落し、再送処理が行われる場合の処理シーケンス例を示す。
２．５．６ 通信終了手順
（ａ） ＬＰＣＰからイベント通知プリミティブ（ＥｖｅｎｔＲｅｐｏｒｔ．ｉｎｄ）で、イベント「ＤＳＲＣ切断通知（９８）」を受領する。
（ｂ） 当該ＬＩＤを使用中のアプリケーションに対し、ＤＳＲＣ切断通知プリミティブ（Ｄｉｓｃｏｎｎｅｃｔ．ｉｎｄ）を発行する。
（ｃ） ＬＰＰは同プリミティブで受信したＬＩＤの接続管理テーブルを削除する。以後同ＬＩＤに対するトランザクション開始要求は受け付けない。
図６５はＤＳＲＣ切断時の手順を示す図である。
（ａ） ＬＰＣＰからイベント通知プリミティブ（ＥｖｅｎｔＲｅｐｏｒｔ．ｉｎｄ）で、イベント「ＤＳＲＣ切断通知（９８）」を受領する。
（ｂ） 当該ＬＩＤを使用中のアプリケーションに対し、ＤＳＲＣ切断通知プリミティブ（Ｄｉｓｃｏｎｎｅｃｔ．ｉｎｄ）を発行する。
（ｃ） ＬＰＰは同プリミティブで受信したＬＩＤの接続管理テーブルを削除する。以後同ＬＩＤに対するトランザクション開始要求は受け付けない。
図６５はＤＳＲＣ切断時の手順を示す図である。
２．５．７ トランザクションの破棄手順
ローカルポートプロトコルでは、トランザクションが以下の状態にあるとき、アプリケーションからトランザクションの破棄を要求できる。
図６６はトランザクション破棄手順を示す図である。
送信側
・リクエスト・レスポンス型のトランザクションでＩｎｖｏｋｅ．ｒｅｑ受付後、Ｒｅｓｕｌｔ ＰＤＵの受信により、Ｉｎｖｏｋｅ．ｃｎｆを発行するまでの間。
受信側
・リクエスト・レスポンス型のトランザクションで、Ｉｎｖｏｋｅ．ｉｎｄ発行後、Ｉｎｖｏｋｅ．ｒｅｓ受付により、Ｒｅｓｕｌｔ ＰＤＵを送信するまでの間。
以下に処理シーケンスを記述する。
（ａ）アプリケーションからトランザクション破棄要求プリミティブ（Ａｂｏｒｔ．ｒｅｑ）を受信することで、このシーケンスは開始される。
（ｂ）ＬＰＰは同プリミティブで指定されたトランザクションに対するＡｂｏｒｔ ＰＤＵを生成し、ＬＰＣＰの転送要求プリミティブ（ＴｒａｎｓｆｅｒＤａｔａ．ｒｅｑ）を用いて、相手局に送信する。
（ｃ）要求元のアプリケーションに対してトランザクション破棄通知プリミティブ（Ａｂｏｒｔ．ｉｎｄ）を発行し、トランザクションの破棄完了を通知する。
（ｄ）ＬＰＰがＬＰＣＰの転送通知プリミティブ（ＴｒａｎｓｆｅｒＤａｔａ．ｉｎｄ）により、Ａｂｏｒｔ ＰＤＵを受信すると、自局内に同ＰＤＵのＴＩＤにより指定されたトランザクションが実行中の場合は、そのトランザクションに関するリソースをすべて破棄した後、アプリケーションに対して、トランザクション破棄通知プリミティブ（Ａｂｏｒｔ．ｉｎｄ）を発行し、トランザクション破棄を通知する。
ローカルポートプロトコルでは、トランザクションが以下の状態にあるとき、アプリケーションからトランザクションの破棄を要求できる。
図６６はトランザクション破棄手順を示す図である。
送信側
・リクエスト・レスポンス型のトランザクションでＩｎｖｏｋｅ．ｒｅｑ受付後、Ｒｅｓｕｌｔ ＰＤＵの受信により、Ｉｎｖｏｋｅ．ｃｎｆを発行するまでの間。
受信側
・リクエスト・レスポンス型のトランザクションで、Ｉｎｖｏｋｅ．ｉｎｄ発行後、Ｉｎｖｏｋｅ．ｒｅｓ受付により、Ｒｅｓｕｌｔ ＰＤＵを送信するまでの間。
以下に処理シーケンスを記述する。
（ａ）アプリケーションからトランザクション破棄要求プリミティブ（Ａｂｏｒｔ．ｒｅｑ）を受信することで、このシーケンスは開始される。
（ｂ）ＬＰＰは同プリミティブで指定されたトランザクションに対するＡｂｏｒｔ ＰＤＵを生成し、ＬＰＣＰの転送要求プリミティブ（ＴｒａｎｓｆｅｒＤａｔａ．ｒｅｑ）を用いて、相手局に送信する。
（ｃ）要求元のアプリケーションに対してトランザクション破棄通知プリミティブ（Ａｂｏｒｔ．ｉｎｄ）を発行し、トランザクションの破棄完了を通知する。
（ｄ）ＬＰＰがＬＰＣＰの転送通知プリミティブ（ＴｒａｎｓｆｅｒＤａｔａ．ｉｎｄ）により、Ａｂｏｒｔ ＰＤＵを受信すると、自局内に同ＰＤＵのＴＩＤにより指定されたトランザクションが実行中の場合は、そのトランザクションに関するリソースをすべて破棄した後、アプリケーションに対して、トランザクション破棄通知プリミティブ（Ａｂｏｒｔ．ｉｎｄ）を発行し、トランザクション破棄を通知する。
なお、上記実施の形態では、狭域通信（ＤＳＲＣ）プロトコル（ＡＲＩＢ ＳＴＤ−Ｔ７５）と、双方向に通信可能なプロトコルである拡張通信制御プロトコル（ＡＳＬ−ＥＬＣＰ）と、転送サービス処理部（ＬＰＣＰ）と、トランザクション管理部（ＬＰＰ）とからなる階層構造を示したが、拡張通信制御プロトコル（ＡＳＬ−ＥＬＣＰ）の代わりに他の双方向に通信可能なプロトコルを用いても良い。
以上のように、本発明に係る路車間通信システムは、路側システムおよび移動局内の双方のローカルアプリケーションが非ネットワーク型のプロトコルを利用して通信を行うシステムであって、前記非ネットワーク型のプロトコルを、マルチアプリケーションを実現するための転送サービス処理部と、未達データの再送信機構、メッセージ単位のデータ送受信機構、メッセージの分割・組立機構を有し、単方向のデータ送信とリクエスト・レスポンス型のトランザクションサービスを提供するトランザクションサービスを行うトランザクション管理部とで構成することを特徴とする。
また、本発明の路車間通信システムにおいては、送受信双方のアプリケーションを識別するためにポート番号を利用することで、非ネットワーク型のプロトコルにおいても、複数のアプリケーションの同時実行を可能にする。
また、最も単純なアプリケーションは転送サービス処理部を直接使用することで実現が可能であり、高速接続性、低オーバヘッドといった走行中の路車間通信に必要な要件を満たすことができる。
また、停止中や低速走行中などでは、トランザクション管理部を使用することによって、大容量データの送受信やリクエスト・レスポンス型のサービスのような高度な通信サービスを必要とするアプリケーションに対しても容易に対応できるようになる。
また、プロトコルを拡張する際に、拡張箇所をトランザクション管理部に局所化することで、拡張を容易にすることができる。
さらに、アプリケーションから指定された識別子（送信データ識別子）により送信データの単位を識別する。またこのプロトコルは、送信データ単位が下位層のプロトコルで一度に送信可能なサイズよりも大きい場合には、送信可能なサイズに分割し、順序番号を付けて送信し、受信側でその順序番号を元に組み立てる機能を有する。
このとき、最終データの受信時に未受信のデータの順序番号を送信側に通知することで、未受信のデータのみを再送信することで通信誤り率を改善する。
また、送信元のアプリケーション識別子（送信元ポート番号）とそのアプリケーションが指定した送信データ識別子の組が同一の場合には、受信側で既受信の同一識別子のデータと同一のデータとして扱うことで、任意のタイミングでのデータの再送信を可能とする。このため、一定時間通信できない場合においても、通信誤り率を改善できる。
また、最も単純なアプリケーションは転送サービス処理部を直接使用することで実現が可能であり、高速接続性、低オーバヘッドといった走行中の路車間通信に必要な要件を満たすことができる。
また、停止中や低速走行中などでは、トランザクション管理部を使用することによって、大容量データの送受信やリクエスト・レスポンス型のサービスのような高度な通信サービスを必要とするアプリケーションに対しても容易に対応できるようになる。
また、プロトコルを拡張する際に、拡張箇所をトランザクション管理部に局所化することで、拡張を容易にすることができる。
さらに、アプリケーションから指定された識別子（送信データ識別子）により送信データの単位を識別する。またこのプロトコルは、送信データ単位が下位層のプロトコルで一度に送信可能なサイズよりも大きい場合には、送信可能なサイズに分割し、順序番号を付けて送信し、受信側でその順序番号を元に組み立てる機能を有する。
このとき、最終データの受信時に未受信のデータの順序番号を送信側に通知することで、未受信のデータのみを再送信することで通信誤り率を改善する。
また、送信元のアプリケーション識別子（送信元ポート番号）とそのアプリケーションが指定した送信データ識別子の組が同一の場合には、受信側で既受信の同一識別子のデータと同一のデータとして扱うことで、任意のタイミングでのデータの再送信を可能とする。このため、一定時間通信できない場合においても、通信誤り率を改善できる。
Claims (8)
- 道路上を走行する移動局と、前記道路上に設置された基地局装置との間で行われる路車間の狭域通信を利用して、前記移動局に対して応用サービスを提供する路車間通信システムにおいて、前記移動局及び前記基地局装置は、各々、複数のアプリケーション間のデータ転送のためのメカニズムを提供する転送サービス処理部、及び未達データの再送信機構と、メッセージ単位のデータ送受信機構と、前記メッセージの分割・組立機構とを有し、単方向のデータ送信とリクエスト・レスポンス型のトランザクションサービスを提供するトランザクション管理部を備え、前記転送サービス処理部は、アプリケーション識別子であるポート番号を用いて送信元および送信先のアプリケーションを識別してデータの転送先を決定し、前記トランザクション管理部は、前記メッセージを複数のデータに分割し、分割された各データにトランザクションの単位を識別するために前記アプリケーションから送信毎に指定された識別子と順序番号を付与し、受信側で前記アプリケーションから指定された識別子が同一の各データを前記順序番号をもとに組み立て順を判別してもとのメッセージへ組み立てることを特徴とする路車間通信システム。
- トランザクション管理部は、トランザクションの破棄をトランザクションの単位を識別する識別子により行うことを特徴とする請求項１に記載の路車間通信システム。
- トランザクション管理部は、分割送信の際、下位層の送信キューの状態により、送信間隔を制御することを特徴とする請求項１に記載の路車間通信システム。
- トランザクション管理部は、分割されたメッセージの最終データの受信時に、未受信のデータの順序番号を送信側に通知し、送信側は前記未受信のデータのみを再送信することを特徴とする請求項１に記載の路車間通信システム。
- 送信側のアプリケーションは、再実行要求を行う場合には、データに同一のトランザクションの単位を識別する識別子を付与し、受信側のトランザクション管理部は、トランザクションの単位を識別する識別子が、受信済みのデータと同一の場合には、既受信の同一識別子のデータと同一のデータとして扱うことを特徴とする請求項１に記載の路車間通信システム。
- トランザクション管理部は、メッセージの組立を行うバッファ領域の場所を示すバルクエリアおよび前記バッファ領域のサイズを示すバルクエリアサイズをアプリケーション毎に指定されることを特徴とする請求項１に記載の路車間通信システム。
- 道路上に設置され、前記道路上を走行する移動局に対して、路車間の狭域通信を利用して応用サービスを提供する基地局装置において、複数のアプリケーション間のデータ転送のためのメカニズムを提供する転送サービス処理部、及び未達データの再送信機構と、メッセージ単位のデータ送受信機構と、前記メッセージの分割・組立機構とを有し、単方向のデータ送信とリクエスト・レスポンス型のトランザクションサービスを提供するトランザクション管理部を備え、前記転送サービス処理部は、アプリケーション識別子であるポート番号を用いて送信元および送信先のアプリケーションを識別してデータの転送先を決定し、前記トランザクション管理部は、前記メッセージを複数のデータに分割し、分割された各データにトランザクションの単位を識別するために前記アプリケーションから送信毎に指定された識別子と順序番号を付与し、受信メッセージに対しては前記アプリケーションから指定された識別子が同一の各データを前記順序番号をもとに組み立て順を判別してもとのメッセージへ組み立てることを特徴とする基地局装置。
- 走行する道路上に設置された基地局装置より、路車間の狭域通信を利用して応用サービスを受け取る移動局装置において、複数のアプリケーション間のデータ転送のためのメカニズムを提供する転送サービス処理部、及び未達データの再送信機構と、メッセージ単位のデータ送受信機構と、前記メッセージの分割・組立機構とを有し、単方向のデータ送信とリクエスト・レスポンス型のトランザクションサービスを提供するトランザクション管理部を備え、前記転送サービス処理部は、アプリケーション識別子であるポート番号を用いて送信元および送信先のアプリケーションを識別してデータの転送先を決定し、前記トランザクション管理部は、前記メッセージを複数のデータに分割し、分割された各データにトランザクションの単位を識別するために前記アプリケーションから送信毎に指定された識別子と順序番号を付与し、受信メッセージに対しては前記アプリケーションから指定された識別子が同一の各データを前記順序番号をもとに組み立て順を判別してもとのメッセージへ組み立てることを特徴とする移動局装置。
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003355354 | 2003-10-15 | ||
| JP2003355354 | 2003-10-15 | ||
| PCT/JP2004/014490 WO2005039075A1 (ja) | 2003-10-15 | 2004-10-01 | 路車間通信システム |
Related Child Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2008293392A Division JP4697490B2 (ja) | 2003-10-15 | 2008-11-17 | 路車間通信システム、基地局装置および移動局装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPWO2005039075A1 JPWO2005039075A1 (ja) | 2007-02-08 |
| JP4396639B2 true JP4396639B2 (ja) | 2010-01-13 |
Family
ID=34463167
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2005514730A Active JP4396639B2 (ja) | 2003-10-15 | 2004-10-01 | 路車間通信システム、基地局装置、及び移動局装置 |
| JP2008293392A Active JP4697490B2 (ja) | 2003-10-15 | 2008-11-17 | 路車間通信システム、基地局装置および移動局装置 |
Family Applications After (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2008293392A Active JP4697490B2 (ja) | 2003-10-15 | 2008-11-17 | 路車間通信システム、基地局装置および移動局装置 |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US7843869B2 (ja) |
| JP (2) | JP4396639B2 (ja) |
| KR (1) | KR100733196B1 (ja) |
| CN (1) | CN1846375B (ja) |
| WO (1) | WO2005039075A1 (ja) |
Families Citing this family (54)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4615399B2 (ja) * | 2005-08-31 | 2011-01-19 | 三菱電機株式会社 | 移動局装置及び外部端末 |
| JP4765917B2 (ja) * | 2005-12-08 | 2011-09-07 | 三菱電機株式会社 | Ｄｓｒｃ無線装置および車載器 |
| KR101268200B1 (ko) | 2006-01-05 | 2013-05-27 | 엘지전자 주식회사 | 이동통신 시스템에서의 무선자원 할당방법 |
| ES2459371T3 (es) * | 2006-01-05 | 2014-05-09 | Lg Electronics Inc. | Transmisión de información en un sistema de comunicaciones móviles |
| KR20070080552A (ko) | 2006-02-07 | 2007-08-10 | 엘지전자 주식회사 | 이동 통신 시스템에서의 응답 정보 전송 방법 |
| KR101211807B1 (ko) | 2006-01-05 | 2012-12-12 | 엘지전자 주식회사 | 이동통신 시스템에서 무선단말의 동기상태 관리방법 |
| WO2007078171A2 (en) | 2006-01-05 | 2007-07-12 | Lg Electronics Inc. | Method of transmitting feedback information in a wireless communication system |
| CN101682557A (zh) * | 2006-01-05 | 2010-03-24 | Lg电子株式会社 | 在移动通信系统中发送数据 |
| KR101333918B1 (ko) | 2006-01-05 | 2013-11-27 | 엘지전자 주식회사 | 이동 통신 시스템의 점-대-다 서비스 통신 |
| KR101203841B1 (ko) | 2006-01-05 | 2012-11-21 | 엘지전자 주식회사 | 무선 통신 시스템에서의 페이징 메시지 전송 및 수신 방법 |
| JP4806030B2 (ja) | 2006-01-05 | 2011-11-02 | エルジー エレクトロニクス インコーポレイティド | 移動通信システムで信号を転送する方法 |
| KR101319870B1 (ko) | 2006-01-05 | 2013-10-18 | 엘지전자 주식회사 | 이동 통신 시스템에서의 핸드오버 방법 |
| KR101265628B1 (ko) | 2006-01-05 | 2013-05-22 | 엘지전자 주식회사 | 이동 통신 시스템에서의 무선 자원 스케줄링 방법 |
| KR101216751B1 (ko) | 2006-02-07 | 2012-12-28 | 엘지전자 주식회사 | 이동 통신 시스템에서 식별자를 이용한 충돌 회피 방법 |
| KR101358469B1 (ko) | 2006-02-07 | 2014-02-06 | 엘지전자 주식회사 | 무선 네트워크(ｎｅｔｗｏｒｋ) 안에서 상향(ｕｐｌｉｎｋ)및 하향(ｄｏｗｎｌｉｎｋ) 대역폭(ｂａｎｄｗｉｄｔｈ)의선택 및 신호 방법 |
| US8493854B2 (en) | 2006-02-07 | 2013-07-23 | Lg Electronics Inc. | Method for avoiding collision using identifier in mobile network |
| KR101387475B1 (ko) | 2006-03-22 | 2014-04-22 | 엘지전자 주식회사 | 복수의 네트워크 엔터티를 포함하는 이동 통신시스템에서의 데이터 처리 방법 |
| WO2007148935A1 (en) | 2006-06-21 | 2007-12-27 | Lg Electronics Inc. | Method of transmitting and receiving radio access information using a message separation in a wireless mobile communications system |
| KR20070121505A (ko) * | 2006-06-21 | 2007-12-27 | 엘지전자 주식회사 | 무선링크 재설정 방법 |
| KR101369135B1 (ko) | 2006-06-21 | 2014-03-05 | 엘지전자 주식회사 | 이동통신 시스템에서의 멀티미디어 및 방송서비스의 품질보장 방법 및 그 단말 |
| KR20070121513A (ko) | 2006-06-21 | 2007-12-27 | 엘지전자 주식회사 | 이동통신 시스템의 상향 접속 방법 |
| EP2030359B1 (en) | 2006-06-21 | 2017-12-20 | LG Electronics Inc. -1- | Method of supporting data retransmission in a mobile communication system |
| JP2008072287A (ja) * | 2006-09-13 | 2008-03-27 | Mitsubishi Electric Corp | 路車間通信装置 |
| JP4697804B2 (ja) * | 2006-10-13 | 2011-06-08 | パナソニック株式会社 | 路車間通信方法及び路車間通信装置 |
| KR100881419B1 (ko) * | 2006-11-02 | 2009-02-05 | 한국전자통신연구원 | Ｓｃａ 기반 시스템의 애플리케이션 컴포넌트 통신 장치 및방법 |
| US7953895B1 (en) | 2007-03-07 | 2011-05-31 | Juniper Networks, Inc. | Application identification |
| DE102007053255B4 (de) * | 2007-11-08 | 2009-09-10 | Continental Automotive Gmbh | Verfahren zum Bearbeiten von Nachrichten und Nachrichtenbearbeitungsvorrichtung |
| DE112009001028B4 (de) | 2008-04-30 | 2017-05-04 | Mitsubishi Electric Corp. | Verfahren zur Bordkommunikation, Bordkommunikationsvorrichtung und Kooperatives Strasse-Fahrzeug/Auto-Auto Kommunikationssystem |
| JP5374929B2 (ja) * | 2008-06-05 | 2013-12-25 | 富士通株式会社 | 移動通信システム、移動通信方法および通信装置 |
| US8315930B2 (en) | 2008-12-22 | 2012-11-20 | General Electric Company | Systems and methods for charging an electric vehicle using broadband over powerlines |
| US20100161517A1 (en) * | 2008-12-22 | 2010-06-24 | Nathan Bowman Littrell | Systems and methods for electricity metering for vehicular applications |
| US9505317B2 (en) | 2008-12-22 | 2016-11-29 | General Electric Company | System and method for electric vehicle charging and billing using a wireless vehicle communication service |
| US20100161518A1 (en) * | 2008-12-22 | 2010-06-24 | Nathan Bowman Littrell | Electricity storage controller with integrated electricity meter and methods for using same |
| US9396462B2 (en) | 2008-12-22 | 2016-07-19 | General Electric Company | System and method for roaming billing for electric vehicles |
| US9030153B2 (en) | 2008-12-22 | 2015-05-12 | General Electric Company | Systems and methods for delivering energy to an electric vehicle with parking fee collection |
| US8583551B2 (en) | 2008-12-22 | 2013-11-12 | General Electric Company | Systems and methods for prepaid electric metering for vehicles |
| US7881324B2 (en) * | 2009-03-25 | 2011-02-01 | International Business Machines Corporation | Steering data communications packets for transparent bump-in-the-wire processing among multiple data processing applications |
| US8213990B2 (en) * | 2009-06-05 | 2012-07-03 | Mediatek Inc. | System for providing remote subscriber identity card to mobile station and methods thereof |
| CN102014530A (zh) * | 2009-09-04 | 2011-04-13 | 中兴通讯股份有限公司 | 一种配置更新失败后的处理方法和网元设备 |
| JP2012199816A (ja) * | 2011-03-22 | 2012-10-18 | Denso Corp | データ受信装置、およびデータ受信プログラム |
| CN103562979B (zh) * | 2011-05-12 | 2014-11-19 | 丰田自动车株式会社 | 路车间通信系统和驾驶支援系统 |
| EP2760228B1 (en) * | 2011-09-22 | 2018-07-25 | Nec Corporation | In-vehicle device, communication system, communication method |
| US9077752B2 (en) * | 2011-12-23 | 2015-07-07 | Cirrus Data Solutions, Inc. | Systems, apparatus, and methods for identifying stored data that may be accessed by a host entity and providing data management services |
| US9686190B2 (en) * | 2012-03-29 | 2017-06-20 | Intel Corporation | Techniques for forwarding or receiving data segments associated with a large data packet |
| US20150271225A1 (en) * | 2014-03-18 | 2015-09-24 | Qualcomm Incorporated | Transport accelerator implementing extended transmission control functionality |
| US20170279924A1 (en) | 2016-03-27 | 2017-09-28 | International Business Machines Corporation | Cancellation management with respect to a web application |
| JP6801074B2 (ja) * | 2016-07-12 | 2020-12-16 | 華為技術有限公司Ｈｕａｗｅｉ Ｔｅｃｈｎｏｌｏｇｉｅｓ Ｃｏ．，Ｌｔｄ． | 車両外部通信方法及び装置並びに端末 |
| CA3033714C (en) | 2016-09-21 | 2021-04-27 | Mitsubishi Electric Corporation | Roadside communication apparatus and in-vehicle communication apparatus |
| KR101915944B1 (ko) * | 2017-05-08 | 2018-11-08 | 주식회사 애포샤 | 클러스터 시스템에서의 클라이언트 요청 처리 방법, 상기 클라이언트 요청에 따른 입출력 처리 방법 및 장치 |
| US10606604B2 (en) * | 2017-08-22 | 2020-03-31 | Bank Of America Corporation | Predictive queue control and allocation |
| WO2020175604A1 (ja) * | 2019-02-27 | 2020-09-03 | パナソニックＩｐマネジメント株式会社 | 無線通信端末装置及びその無線通信方法 |
| JP7373737B2 (ja) * | 2019-02-27 | 2023-11-06 | パナソニックＩｐマネジメント株式会社 | 無線通信端末装置及びその無線通信方法 |
| EP3941020B1 (en) * | 2020-07-16 | 2023-06-14 | Volkswagen Aktiengesellschaft | A method for controlling a communication between a vehicle and a backend device |
| DE102021208802A1 (de) | 2021-08-11 | 2023-02-16 | Robert Bosch Gesellschaft mit beschränkter Haftung | Verfahren zur Absicherung einer Kommunikation zwischen einer straßenseitigen Funkeinheit und Fahrzeugen, Computerprogramm und System zur Unterstützung von Fahrzeugen, Verfahren zur Überwachung der straßenseitigen Funkeinheit und Überwachungseinheit |
Family Cites Families (27)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5424727A (en) * | 1994-03-22 | 1995-06-13 | Best Network Systems, Inc. | Method and system for two-way packet radio-based electronic toll collection |
| JP3208305B2 (ja) * | 1995-11-14 | 2001-09-10 | シャープ株式会社 | 通信装置および通信方法 |
| JP3211674B2 (ja) * | 1996-08-22 | 2001-09-25 | 株式会社デンソー | 車両用通信装置 |
| US6496502B1 (en) * | 1998-06-29 | 2002-12-17 | Nortel Networks Limited | Distributed multi-link trunking method and apparatus |
| US6560229B1 (en) * | 1998-07-08 | 2003-05-06 | Broadcom Corporation | Network switching architecture with multiple table synchronization, and forwarding of both IP and IPX packets |
| JP3053181B1 (ja) * | 1999-01-28 | 2000-06-19 | 日本電気株式会社 | 無線デ―タ通信装置及び無線デ―タ通信方法 |
| JP3764016B2 (ja) | 1999-05-10 | 2006-04-05 | 財団法人流通システム開発センタ− | 統合ｉｐ転送網 |
| JP4131056B2 (ja) * | 1999-06-15 | 2008-08-13 | 株式会社デンソー | 移動体通信装置および固定局通信装置ならびに移動体通信装置の通信方法 |
| JP3669619B2 (ja) | 1999-09-06 | 2005-07-13 | 富士通株式会社 | 無線端末装置のソフトウェア更新方法及びその装置 |
| JP3651381B2 (ja) | 1999-10-15 | 2005-05-25 | 株式会社デンソー | 移動体通信装置、固定局通信装置、アプリケーション処理装置および移動体通信装置の通信方法 |
| FI19992470A (fi) * | 1999-11-17 | 2001-05-18 | Nokia Mobile Phones Ltd | Tiedonsiirto |
| US6834326B1 (en) * | 2000-02-04 | 2004-12-21 | 3Com Corporation | RAID method and device with network protocol between controller and storage devices |
| JP2001298397A (ja) | 2000-04-13 | 2001-10-26 | Denso Corp | 通信システム及び車載装置並びに記録媒体 |
| JP3514228B2 (ja) * | 2000-10-25 | 2004-03-31 | 日本電気株式会社 | 狭域無線連続通信方法とシステム |
| KR100400549B1 (ko) * | 2000-12-22 | 2003-10-08 | 엘지전자 주식회사 | 단거리 무선전용 통신망을 이용한 지리정보 서비스 장치 |
| DE10104713A1 (de) * | 2001-02-02 | 2002-08-08 | Siemens Ag | Verfahren und Vorrichtungen zum Zugreifen auf Nachrichten |
| JP3777996B2 (ja) | 2001-03-13 | 2006-05-24 | 株式会社Ｋｄｄｉ研究所 | 路車間通信システムにおけるハンドオーバのデータ制御方法 |
| JP3666406B2 (ja) * | 2001-04-04 | 2005-06-29 | 日本電気株式会社 | ノンストップ料金課金方法及びシステム |
| WO2002096133A1 (en) * | 2001-05-22 | 2002-11-28 | Nokia Corporation | Method, network device, and terminal device for controlling context activation |
| JP3804477B2 (ja) | 2001-06-27 | 2006-08-02 | 三菱電機株式会社 | Ａｔｍ終端装置およびｐｏｎシステム |
| US20030033418A1 (en) * | 2001-07-19 | 2003-02-13 | Young Bruce Fitzgerald | Method of implementing and configuring an MGCP application layer gateway |
| JP3564665B2 (ja) * | 2001-07-19 | 2004-09-15 | 日本電気エンジニアリング株式会社 | 大容量狭域通信システム |
| KR100798597B1 (ko) * | 2001-08-29 | 2008-01-28 | 엘지전자 주식회사 | 노변기지국의 채널정보 제공방법 |
| KR100431003B1 (ko) | 2001-10-31 | 2004-05-12 | 삼성전자주식회사 | 데이터 송수신 시스템 및 방법 |
| JP4062489B2 (ja) | 2002-02-07 | 2008-03-19 | 独立行政法人情報通信研究機構 | 通信方法、基地局および端末 |
| US7146427B2 (en) * | 2002-04-23 | 2006-12-05 | Lsi Logic Corporation | Polling-based mechanism for improved RPC timeout handling |
| US7277449B2 (en) * | 2002-07-29 | 2007-10-02 | Freescale Semiconductor, Inc. | On chip network |
-
2004
- 2004-10-01 CN CN2004800252613A patent/CN1846375B/zh not_active Expired - Fee Related
- 2004-10-01 KR KR20067007142A patent/KR100733196B1/ko active IP Right Grant
- 2004-10-01 WO PCT/JP2004/014490 patent/WO2005039075A1/ja active Application Filing
- 2004-10-01 US US10/568,346 patent/US7843869B2/en not_active Expired - Fee Related
- 2004-10-01 JP JP2005514730A patent/JP4396639B2/ja active Active
-
2008
- 2008-11-17 JP JP2008293392A patent/JP4697490B2/ja active Active
Also Published As
| Publication number | Publication date |
|---|---|
| KR20060095868A (ko) | 2006-09-04 |
| JP4697490B2 (ja) | 2011-06-08 |
| CN1846375B (zh) | 2011-04-20 |
| CN1846375A (zh) | 2006-10-11 |
| JP2009077422A (ja) | 2009-04-09 |
| US7843869B2 (en) | 2010-11-30 |
| KR100733196B1 (ko) | 2007-06-28 |
| JPWO2005039075A1 (ja) | 2007-02-08 |
| WO2005039075A1 (ja) | 2005-04-28 |
| US20060193282A1 (en) | 2006-08-31 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4396639B2 (ja) | 路車間通信システム、基地局装置、及び移動局装置 | |
| US9674832B2 (en) | Method and apparatus for layer 2 ARQ for packets | |
| JP4818374B2 (ja) | 車両用通信装置 | |
| US7466708B2 (en) | Method for operating a mobile radio network | |
| RU2289204C2 (ru) | Способ и система мобильной связи | |
| JP3183343B2 (ja) | データ通信方法、端末装置、中継装置、データ通信システム及びその記録媒体 | |
| US8958411B2 (en) | Method of transmitting RLC data | |
| KR101187076B1 (ko) | 이동 통신 시스템에 있어서 신호 전송 방법 | |
| CN101491005A (zh) | 用于无线通信系统中的策略执行的方法和装置 | |
| US6415331B1 (en) | Method of updating accumulated data with middleware and server system performing the same | |
| CN106210924B (zh) | 视频网络传输控制方法和系统 | |
| WO2011020233A1 (zh) | 多跳中继通信系统中对下行数据传输控制的方法和装置 | |
| KR20040061079A (ko) | 이동 노드들로 구성된 무선망에서의 세션 설정 장치 및 방법 | |
| WO2011100911A2 (zh) | 探测处理方法、数据发送端、数据接收端以及通信系统 | |
| Morneault et al. | Signaling system 7 (SS7) message transfer part 2 (MTP2)-User adaptation layer | |
| CN114124316A (zh) | 一种数据传输方法、装置、节点设备及数据传输网络 | |
| KR20030024237A (ko) | 티씨피/아이피 프로토콜 계층 2에서 리라이어블 서비스제공장치 및 그 방법 | |
| CN107968754B (zh) | 流表下发方法、接收方法、控制器、交换机及转发系统 | |
| Ennis et al. | Overview of a broad-band local area network protocol architecture | |
| KR100370060B1 (ko) | 차세대 이동 통신 시스템의 통신 운용 방법 | |
| JP2001308936A (ja) | データ通信方法、中継装置、データ通信システム及びその記録媒体 | |
| KR20030094974A (ko) | 이동통신 시스템의 데이터 호 트래픽 프레임 제어방법 | |
| TW588535B (en) | Data transmission confirmation in a wireless communication system | |
| KR100291021B1 (ko) | 광 가입자 분배망에서 호스트 디지털 터미널과 광 네트워크 유니트의 프로세서간 통신 프로토콜방법 | |
| JP2001103557A (ja) | データ転送方法、マルチキャストデータ転送方法、無線通信システム、無線基地局及び無線移動局 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080916 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20081114 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20090407 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090608 |
|
| 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: 20090929 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20091012 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121030 Year of fee payment: 3 |
|
| R151 | Written notification of patent or utility model registration |
Ref document number: 4396639 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R151 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131030 Year of fee payment: 4 |
|
| 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 |