JP5382109B2 - 通信装置、パケット同期方法 - Google Patents

通信装置、パケット同期方法 Download PDF

Info

Publication number
JP5382109B2
JP5382109B2 JP2011503562A JP2011503562A JP5382109B2 JP 5382109 B2 JP5382109 B2 JP 5382109B2 JP 2011503562 A JP2011503562 A JP 2011503562A JP 2011503562 A JP2011503562 A JP 2011503562A JP 5382109 B2 JP5382109 B2 JP 5382109B2
Authority
JP
Japan
Prior art keywords
packet
data
header
unit
length
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 - Fee Related
Application number
JP2011503562A
Other languages
English (en)
Other versions
JPWO2010103574A1 (ja
Inventor
大太郎 古田
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Publication of JPWO2010103574A1 publication Critical patent/JPWO2010103574A1/ja
Application granted granted Critical
Publication of JP5382109B2 publication Critical patent/JP5382109B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/004—Arrangements for detecting or preventing errors in the information received by using forward error control
    • H04L1/0045—Arrangements at the receiver end
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/004—Arrangements for detecting or preventing errors in the information received by using forward error control
    • H04L1/0056—Systems characterized by the type of code used
    • H04L1/0061—Error detection codes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L7/00—Arrangements for synchronising receiver with transmitter
    • H04L7/04—Speed or phase control by synchronisation signals
    • H04L7/041—Speed or phase control by synchronisation signals using special codes as synchronising signal
    • H04L7/042—Detectors therefor, e.g. correlators, state machines
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L7/00—Arrangements for synchronising receiver with transmitter
    • H04L7/04—Speed or phase control by synchronisation signals
    • H04L7/048—Speed or phase control by synchronisation signals using the properties of error detecting or error correcting codes, e.g. parity as synchronisation signal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L7/00—Arrangements for synchronising receiver with transmitter
    • H04L7/04—Speed or phase control by synchronisation signals
    • H04L7/10—Arrangements for initial synchronisation

Description

本発明は、データ転送において、入力データに含まれるパケットの同期をとる技術に関する。
３ＧＰＰ(3rd Generation Partnership Project)では、次世代無線通信システムとしてＬＴＥ（Long Term Evolution）が議論されている。ＬＴＥでは、Ｅ−ＵＴＲＡＮ(Evolved UMTS Terrestrial Radio Access Network)と呼ばれる無線アクセスネットワークを利用し、すべてＩＰ(Internet Protocol)ベースのトラフィックのサービスを提供することが予定されている。なお、Ｅ−ＵＴＲＡＮの仕様については、例えば非特許文献１等に開示されている。
3GPP TS 36.133 V8.4.0(2008-12) :3rd Generation Partnership Project;Technical Specification Group Radio Access Network; "Evolved UniversalTerrestrial Radio Access (E-UTRA); Requirements for support of radio resourcemanagement" (Release 8)
ところで、従来、携帯端末（ＵＥ：User Equipment）のような通信装置は、外部装置との間でＵＳＢ(Universal Serial Bus)通信によるデータ転送を行う場合、例えばＰＰＰ(Point to Point Protocol)等のプロトコルを利用して行ってきた。ＵＳＢ通信で比較的大量のデータを転送する場合には、一定量のデータ毎にバルク転送モードで転送される（いわば、レイヤを意識せずにデータが転送される）ことになるが、ＰＰＰでは、ＰＰＰフレームの先頭フラグを検出することにより、容易にフレームの同期をとることができる。
しかしながら、すべてＩＰパケットで処理することが前提の次世代無線通信システムに属する携帯端末等の通信装置が、外部装置からのＵＳＢ通信によるデータ転送を受ける場合には、上位レイヤにおける処理負荷を軽減する観点から、ＰＰＰによらずＩＰパケットの同期をとれるようにすることが好ましい。すなわち、通信装置において、外部装置との間で特別なプロトコルを用いることなく、その外部装置からの入力データからパケットの同期をとることができるようにすることが課題である。
第１の観点では、有線接続される外部装置からの入力データに対して、パケットの同期をとる通信装置が提供される。
この通信装置は、
（Ａ）前記外部装置からの入力データを１又は複数の単位データに変換する変換部と、
該単位データの入力毎に、所定量の第１入力データを検査符号とし、該第１入力データより前の入力データを検査対象データとした検査を行い、所望の検査結果を得ることをもって検査符号を検出する第１検出部と、
（Ｂ）前記第１検出部により検査符号が検出されたときの検査対象データの先頭位置が第１パケットのヘッダの先頭位置であると推定し、当該ヘッダから前記第１パケットのパケット長を読み出す第１ヘッダ解析部と、
（Ｃ）前記第１検出部により検査符号が検出されたときの検査対象データの長さが、前記第１ヘッダ解析部により読み出されるパケット長、と一致するかを判定する第１判定部と、
（Ｄ）第１検出部により検出される検査符号に続く入力データの先頭位置が、前記第１パケットに続く第２パケットのヘッダの先頭位置であると推定し、当該ヘッダから前記第２パケットのパケット長を読み出す第２ヘッダ解析部と、
を備える。
この通信装置では、第１判定部により読み出されるパケット長に相当する入力データとして、第１パケットが検出される。いったん第１パケットが検出されると、第２解析部により読み出されるパケット長に相当する後続の入力データとして、第２パケットが検出される。これにより、入力データに対するパケット同期がとられる。
他の観点では、この通信装置と同様の処理を行うパケット同期方法が提供される。
開示の通信装置およびパケット同期方法によれば、通信装置において、外部装置との間で特別なプロトコルを用いることなく、その外部装置からの入力データからパケットの同期をとることができる。
第１実施形態に係る携帯端末と外部ＴＥを含むシステム構成を示す図。 第１実施形態に係る携帯端末の構成の要部を示すブロック図。 ＣＲＣ検出処理を説明するための図。 第１実施形態に係る携帯端末内部のステートマシンの状態遷移図。 第１実施形態に係る携帯端末内部の処理を示すフローチャート。 第１実施形態に係る携帯端末内部の処理を示すフローチャート。 第１実施形態に係る携帯端末内部のデータフローを示すフロー図。 第１実施形態に係る携帯端末内部のデータフローを示すフロー図。 第１実施形態に係る携帯端末に対する外部ＴＥからの上りデータの転送のフローを示す図。 第２実施形態に係る携帯端末内部の処理を示すフローチャート。 第２実施形態に係る携帯端末に対する外部ＴＥからの上りデータの転送のフローを示す図。 第３実施形態に係る携帯端末の構成の要部を示すブロック図。 第３実施形態に係る携帯端末内部のステートマシンの状態遷移図。 第３実施形態に係る携帯端末内部のデータフローを示すフロー図。
符号の説明
２…ＣＰＵ、３…メモリ、４，４ａ…上りデータ処理部，５…下りデータ処理部、１１…ＵＳＢインタフェース、１２…Ｓ／Ｐインタフェース、１３，１６…セレクタ、１４…第１パケット検出部、１５，１５ａ…第２パケット検出部、１７…ＤＭＡコントローラ、１８…バスインタフェース、１９…ＣＲＣ処理部、２０，２０ａ…ステートマシン
（１）第１実施形態
以下、本発明の通信装置の一実施形態としての携帯端末について説明する。
（１−１）携帯端末（ＵＥ）と外部ＴＥの通信
図１は、実施形態に係る携帯端末（ＵＥ：User Equipment）と、パーソナルコンピュータ等の外部ＴＥ(Terminal Equipment)２とを含む通信システムを示す。図１において、携帯端末と外部ＴＥとは、ＵＳＢ(Universal Serial Bus)ケーブルで接続されている。
ここで、携帯端末が、外部ＴＥからＵＳＢケーブルを通して、例えば画像データ等の大量のデータをバルク転送モードにより送受信する場合を想定する。外部ＴＥから携帯端末へのＵＳＢによるバルク転送においては、転送データのレイヤが認識されることなく、一定の転送量（１〜５１２バイト）のデータ単位で順次、外部ＴＥから携帯端末へデータの転送がなされる。
図１に示す通信システムおいて、外部ＴＥでは、データ転送前にＩＰパケットの最後にＣＲＣ(Cyclic Redundancy Check)コードが付加される。そして、携帯端末と外部ＴＥとのＵＳＢ通信では、ＣＲＣコードが付加された状態でデータの送受信が行われる。ＣＲＣの種類は、携帯端末と外部ＴＥとの間で予め決めておけばよく、この実施形態では、例えばＣＲＣ−１６が使用される。これにより、実施形態に係る携帯端末では、外部ＴＥから転送されるバルクデータからＣＲＣコードを検出することにより、ＩＰパケットを検出する（以下の説明では適宜、「パケットの同期をとる」又は「同期検出する」と表記する。）ように構成されている。
（１−２）携帯端末（ＵＥ）の構成
次に、実施形態の携帯端末の構成について、図２を参照して説明する。図２は、実施形態の携帯端末の構成の要部を示すブロック図である。
図２に示すように、この携帯端末（ＵＥ）は、ＣＰＵ２、メモリ３、上りデータ処理部４、下りデータ処理部５を備えている。
上りデータ処理部４は、ＵＳＢインタフェース（ＵＳＢ Ｉ／Ｆ）１１、Ｓ／Ｐ(Serial/Parallel)インタフェース（Ｓ／Ｐ Ｉ／Ｆ）１２、セレクタ（ＳＥＬ）１３及び１６、第１パケット検出部１４、第２パケット検出部１５、ＤＭＡコントローラ（ＤＭＡＣ）１７、バスインタフェース（ＢＵＳ Ｉ／Ｆ）１８、ＣＲＣ処理部１９（第１検出部）、ステートマシン２０、を含む。
下りデータ処理部５は、ＵＳＢインタフェース（ＵＳＢ Ｉ／Ｆ）５１、Ｓ／Ｐ(Serial/Parallel)インタフェース（Ｓ／Ｐ Ｉ／Ｆ）５２、バッファ（ＢＵＦ）５５、ＣＲＣ付加部５６、ＤＭＡ(Direct Memory Access)コントローラ（ＤＭＡＣ）５７、バスインタフェース（ＢＵＳ Ｉ／Ｆ）５８、を含む。
なお、図２において、矢印付きの実線は転送データの処理の流れを示しており、矢印付きの点線は内部の制御データの処理の流れを示している。また、上りデータ処理部４及び下りデータ処理部５におけるデータ処理は、所定のクロック単位で順次行われる。
上りデータ処理部４の構成について、上りデータの処理の流れに沿って説明する。
ＵＳＢインタフェース１１は、ＵＳＢプロトコルに従って外部ＴＥからＵＳＢケーブルを通してデータを受信する。この実施形態の説明では、ＵＳＢによるデータ転送モードとしてバルク転送を想定する。このバルク転送では、外部ＴＥから比較的まとまった量のデータが非周期的に携帯端末へ転送される。
上りデータ処理部４では、第１パケット検出部１４又は第２パケット検出部１５からステートマシン２０に対して、パケットの検出可否を示す信号としてＰＡＣＫＥＴ＿ＲＣＶＤ信号（以下の説明では例えば、Ｈレベル：パケット検出不可，Ｌレベル：パケット検出可、とする。）が送信される。
上りデータ処理部４では、第１パケット検出部１４又は第２パケット検出部１５からステートマシン２０に対して、ＣＲＣ検出のＯＫ／ＮＯＫを示す信号としてＣＲＣ＿ＯＫ信号（以下の説明では例えば、Ｈレベル：ＣＲＣ検出ＮＯＫ，Ｌレベル：ＣＲＣ検出ＯＫ、とする。）が送信される。
Ｓ／Ｐインタフェース１２は、ＵＳＢインタフェース１１からのシリアルデータをＣＲＣ検出に適したデータサイズ、例えば１バイトの幅のパラレルデータに変換する。この１バイトデータ（単位データ量のデータ）が、セレクタ１３及びＣＲＣ処理部１９へ出力される。
セレクタ１３は、ステートマシン２０による制御指令に応じて、Ｓ／Ｐインタフェース１２からの１バイトデータを、第１パケット検出部１４又は第２パケット検出部１５のいずれかへ出力する。
ＣＲＣ処理部１９は、Ｓ／Ｐインタフェース１２からの１バイト幅のデータを１クロックで並列的にＣＲＣ演算が可能な構成を備えている。本実施形態において、ＣＲＣの生成多項式を限定するものではないが、ＣＲＣ処理部１９では、１６ビットのＣＲＣ（ＣＲＣ−１６）が適用され、例えば生成多項式としてＸ１６＋Ｘ１５＋Ｘ２＋１が使用される。ＣＲＣ処理部１９は、生成多項式を用いたモジュロ演算を行い、その検査結果をステートマシン２０へ通知する。具体的には、モジュロ演算の剰余が所望の値（典型的には「０」）であるときにはＣＲＣ検出ＯＫであるとして、ＬレベルのＣＲＣ＿ＯＫ信号がステートマシン２０へ送信される。
ＣＲＣ処理部１９は、Ｓ／Ｐインタフェース１２からの１バイトデータを順次蓄積するバッファ（図示しない）を備えている。ＣＲＣ処理部１９は、第１パケット検出部１４からの制御指令に応じてＣＲＣ検出を行うときには、バッファ内の検査対象データに対して順次、最後に入力する１６ビットデータがＣＲＣコード（検査符号）であると仮定して上記モジュロ演算（検査）を行う。その結果、ＣＲＣコードが検出されたとき、すなわちＣＲＣ検出がＯＫとなったときには、内部のバッファがリセットされる。
ここで、ＣＲＣ処理部１９における処理について、図３を参照してさらに説明する。
図３は、第１パケット検出部１４からの制御指令に応じてＣＲＣ検出を行うときのクロック毎のＣＲＣ検出処理を示す図である。図３では、連続するｋ番目〜ｋ＋２番目のクロックにおけるモジュロ演算処理を時系列で例示する図である。図３において、（ｂ）に示すｋ＋１番目のクロックの処理では、バッファ内の最後の１バイトと新たに入力する１バイトデータをＣＲＣコードと仮定し、バッファ内の残りのデータを検査対象データとしてモジュロ演算を行う。
（ｃ）に示すｋ＋２番目のクロックの処理では、さらに新たな１バイトデータを取り込み、その新たな１バイトデータを含む最新の２バイトデータをＣＲＣと仮定し、バッファ内の残りのデータを検査対象データとしてモジュロ演算を行う。このときの検査対象データは、ｋ＋１番目のクロックの処理と比較して１バイト分増加する。
同様にして、ＣＲＣ処理部１９は、新たに１バイトデータを取り込む毎に、検査対象データと、仮定するＣＲＣコードとを更新していき、モジュロ演算の剰余が例えば「０」となるときのＣＲＣコードを探索する。
図２に戻り、第１パケット検出部１４は、ヘッダ解析部１４１（第１ヘッダ解析部）とバッファ（ＢＵＦ）１４２を備えており、パケットの最後に付加されているＣＲＣコードを検出することでＩＰパケットの同期をとる。最初にパケットを検出するときには、第１パケット検出部１４においてパケット検出が行われる。
バッファ１４２には少なくとも、予定するパケットの大きさに相当する容量を備えており、セレクタ１３から転送される１バイトデータが順次蓄積される。このバッファ１４２には、各クロックにおいてＣＲＣ処理部１９における検査対象データと同一のデータが蓄えられる。
ＣＲＣ処理部１９によるＣＲＣ検出がＯＫであるときには、第１パケット検出部１４はステートマシン２０から、ＬレベルのＣＲＣ＿ＯＫ信号を受信する。このＬレベルのＣＲＣ＿ＯＫ信号を受信すると、ヘッダ解析部１４１は、バッファ１４２に蓄積されたデータがパケットであると認識し、蓄積データの先頭位置からヘッダを解析する。すなわち、ＩＰパケットの場合、ヘッダ内のフィールド構成は予め既知であるため、ヘッダ解析部１４１は、ヘッダからパケット長(Total Length)を読み出す。第１判定部としての第１パケット検出部１４は、この読み出したパケット長と、バッファ１４２内のデータの長さとが一致するか判定する。すなわち、パケット長の検証が行われる。
バッファ１４２内のデータの長さがパケット長と一致する場合には、ＬレベルのＰＡＣＫＥＴ＿ＲＣＶＤ信号をステートマシン２０へ送信する。この検出されたパケットは、ＤＭＡコントローラ１７による制御の下、バスインタフェース１８及びバスを通してメモリ３へ転送される。
図２に示すように、第２パケット検出部１５は、ヘッダ解析部１５１（第２ヘッダ解析部）、カウンタ１５２、バッファ（ＢＵＦ）１５３、を備えている。バッファ１５３には少なくとも、予定するパケットの大きさに相当する容量を備えている。
ステートマシン２０による制御の下、いったん第１パケット検出部１４によりパケットが検出された後に、第２パケット検出部１５の処理が開始される。すなわち、ステートマシン２０の制御によりセレクタ１３が切り替えられる。ここで、ヘッダ解析部１５１は、セレクタ１３から入力するデータの先頭位置が、既に検出されたパケットの次のパケットのヘッダの先頭位置であると推定し、そのヘッダの所定のフィールドからパケット長を読み出す。
カウンタ１５２は、セレクタ１３から１バイト入力する毎にカウントアップするバイトカウンタである。カウンタ１５２は、セレクタ１３からの１バイトデータを順次バッファ１５３に蓄積する。
第２パケット検出部１５は、カウンタ１５２の値が、読み出されたパケット長に相当する値（バイト数）に達したときにカウンタ１５２を停止させ、ＬレベルのＰＡＣＫＥＴ＿ＲＣＶＤ信号をステートマシン２０へ送信する。バッファ１５３に蓄積されるパケットは、ＤＭＡコントローラ１７による制御の下、バスインタフェース１８及びバスを通してメモリ３へ転送される。なお、ＬレベルのＰＡＣＫＥＴ＿ＲＣＶＤ信号が送信された後、カウンタ１５２はクリアされる。
ステートマシン２０は、所定の状態遷移を行いながら、上りデータ処理部４内の処理を制御するために設けられる。
ステートマシン２０における状態遷移図を図４に示す。以下、ステートマシン２０における状態遷移について、各状態における上りデータ処理部４内の動作と関連付けて説明する。
図４において、上りデータ処理部４の処理が開始されると（サービスイン）、第１パケット検出部１４によるパケット検出（第１パケット検出）を行う状態（状態ＳＡ）となる。これにより、セレクタ１３，１６が制御されて、Ｓ／Ｐインタフェース１２からの１ビットデータが順次、第１パケット検出部１４に入力されるとともに、第１パケット検出部１４においてパケット検出処理が行われることになる。
また、ＣＲＣ処理部１９によりＣＲＣが検出され、かつ第１パケット検出部１４によるパケット長の検証がＯＫとなると（同期検出ＯＫ）、ステートマシン２０は、第２パケット検出部１５によるパケット検出（第２パケット検出）を行う状態（状態ＳＢ）へ遷移する。これにより、セレクタ１３，１６が制御されて、Ｓ／Ｐインタフェース１２からの１ビットデータが順次、第２パケット検出部１５に入力されるとともに、第２パケット検出部１５においてパケット検出処理が行われることになる。
なお、第２パケット検出部１５では、読み出したパケット長が、パケット長として予定されている範囲内の値であるか等により、読み出したパケット長の検証を行うようにしてもよい。パケット長がＮＯＫ（ＯＫでない）である場合（すなわち、同期検出ＮＯＫの場合）には、図４に示すように、ステートマシン２０は、第２パケット検出を行う状態から第１パケット検出を行う状態へ遷移することが好ましい。
図２を再度参照すると、下りデータ処理部５では、ＤＭＡコントローラ５７による制御の下、ＰＤＣＰ(Packet Data Convergence Protocol)−ＳＤＵ(Service Data Unit)のデータがメモリ３からバス及びバスインタフェース５８を通して、ＣＲＣ付加部５６に入力される。ＣＲＣ付加部５６では、各ＰＤＣＰ−ＳＤＵに対してＣＲＣコードを生成し、ＣＲＣコードを付加した状態でバッファ５５へ転送する。ＣＲＣコードが付加されたＰＤＣＰ−ＳＤＵは、Ｓ／Ｐインタフェース５２を経由し、ＵＳＢインタフェース５１から例えばバルク転送により、一定量のデータ毎に非周期的に外部ＴＥへ転送される。
（１−３）上りデータの処理
次に、実施形態の携帯端末における上りデータの処理について、図５〜図８を参照して説明する。図５、図６はそれぞれ、ステートマシン２０が状態ＳＡ、ＳＢにあるときの処理を示すフローチャートである。図７、図８はそれぞれ、ステートマシン２０が状態ＳＡ、ＳＢにあるときのデータフローを示すフロー図である。
以下、（Ａ）ステートマシン２０が状態ＳＡにあるときの処理と、（Ｂ）ステートマシン２０が状態ＳＢにあるときの処理と、に場合を分けて説明する。
（Ａ）ステートマシン２０が状態ＳＡにあるときの処理
最初にパケットを検出しようとするときには、ステートマシン２０では状態ＳＡとなり（図４参照）、第１パケット検出部１４における処理が行われるように、セレクタ１３，１６が制御される。これにより、Ｓ／Ｐインタフェース１２からの１バイトデータがＣＲＣ処理部１９及び第１パケット検出部１４へ順次送出され（図７のステップＳ５０）、蓄積されていく。ＣＲＣ処理部１９は、１バイト単位で蓄積されるデータに対してクロック単位で逐次モジュロ演算を行うことでＣＲＣコードを検出すると（図５のステップＳ１０）、ＬレベルのＣＲＣ＿ＯＫ信号をステートマシン２０へ送信する。このＣＲＣ＿ＯＫ信号はさらに、ステートマシン２０から第１パケット検出部１４へ送信される（図７のステップＳ５２）。これにより、第１パケット検出部１４はＣＲＣコードが検出されたことを認識する。
次に、第１パケット検出部１４は、バッファ１４２内の蓄積データがパケットのヘッダの先頭位置であると推定し、そのヘッダからパケット長を読み出す（図５のステップＳ１２）。さらに、第１パケット検出部１４は、バッファ１４２内のデータの長さが、読み出したパケット長と一致するか（すなわち、「パケット長ＯＫ」であるか）判定する（図５のステップＳ１４、図７のステップＳ５４）。パケット長ＯＫである場合には、ＬレベルのＰＡＣＫＥＴ＿ＲＣＶＤ信号をステートマシン２０へ送信する（図７のステップＳ５６）。すなわち、ステートマシン２０へ同期検出通知が行われる（図５のステップＳ１６）。なお、図５のステップＳ１４でパケット長ＯＫでない場合には、再度ステップＳ１０からＣＲＣ検出が行われる。
ステートマシン２０では、サービス停止をＣＰＵ２から指示されない限りサービスを継続し（図５のステップＳ１８）、第１パケット検出部１４からＬレベルのＰＡＣＫＥＴ＿ＲＣＶＤ信号を受信すると（図７のステップＳ５６）、状態ＳＡから状態ＳＢへ遷移する（図７のステップＳ５８；図４参照）。これにより、ステートマシン２０は、第２パケット検出部１５の処理へ移行させるために、セレクタ１３，１６を制御する。その結果、Ｓ／Ｐインタフェース１２からの１バイトデータの転送先が、第１パケット検出部１４から第２パケット検出部１５へ切り替えられる（図７のステップＳ６０）。
第１パケット検出部１４は、ＬレベルのＰＡＣＫＥＴ＿ＲＣＶＤ信号をステートマシン２０へ送信した後、バッファ１４２内に保持するパケットをメモリ３へ転送するためのＤＭＡを要求するＤＭＡ＿ＲＱ信号をＤＭＡコントローラ１７へ送信する（図７のステップＳ６２）。そして、バッファ１４２内のパケットが１バイト単位で順次、バスインタフェース１８を通して、メモリ３へ転送される（図７のステップＳ６４）。メモリ３へのパケット転送が終了すると、ＤＭＡコントローラ１７は、第１パケット検出部１４及びＣＰＵ２に対して、ＤＭＡが完了したことを示すＤＭＡ＿ＣＯＭＰＬ信号を送信する。このＤＭＡ＿ＣＯＭＰＬ信号はさらに、第１パケット検出部１４からステートマシン２０へ送信される（図７のステップＳ６６）。
（Ｂ）ステートマシン２０が状態ＳＢにあるときの処理
いったん最初のパケットが検出されると、ステートマシン２０では状態ＳＢへ移行する（図４参照）。ステートマシン２０は第２パケット検出部１５に対して処理を開始するように指示し（図６のステップＳ２２）、セレクタ１３，１６が制御される。これにより、Ｓ／Ｐインタフェース１２からの１バイトデータがＣＲＣ処理部１９及び第２パケット検出部１５へ順次送出され（図８のステップＳ７０）、蓄積されていく。
Ｓ／Ｐインタフェース１２からデータが入力されると、第２パケット検出部１５では、カウンタ１５２が、入力されるバイト数のカウントを開始する（図６のステップＳ２４）。
第２パケット検出部１５は、セレクタ１３から入力するデータの先頭位置が、既に検出されたパケットの次のパケットのヘッダの先頭位置であると推定し、そのヘッダの所定のフィールドからパケット長を読み出す（図６のステップＳ２６）。そして、第２パケット検出部１５は、読み出したパケット長に相当するバイト数がカウンタ１５２でカウントされると、カウンタ１５２によるカウントを停止し（図６のステップＳ２８）、その時点でバッファ１５３に蓄積されたデータがパケットであると判断する。
好ましくは、読み出したパケット長が、パケット長として予定されている範囲の値であるかを判定することにより、パケット長の検証を行う（図６のステップＳ３０、図８のステップＳ７４）。パケット長がＯＫであれば、同期検出通知としてＬレベルのＰＡＣＫＥＴ＿ＲＣＶＤ信号をステートマシン２０へ送信し（図６のステップＳ３２、図８のステップＳ７６）、カウンタ１５２をクリアする（図６のステップＳ３６）。
なお、図６のステップＳ３０でパケット長がＯＫでない場合には、第２パケット検出部１５は、ＨレベルのＰＡＣＫＥＴ＿ＲＣＶＤ信号がステートマシン２０へ送信する。すなわち、ステートマシン２０へ非同期検出通知が行われる（図６のステップＳ３４）。
第２パケット検出部１５は、ＬレベルのＰＡＣＫＥＴ＿ＲＣＶＤ信号をステートマシン２０へ送信した後、バッファ１５３内に保持するパケットをメモリ３へ転送するためのＤＭＡを要求するＤＭＡ＿ＲＱ信号をＤＭＡコントローラ１７へ送信する（図８のステップＳ８２）。そして、バッファ１５３内のパケットが１バイト単位で順次、バスインタフェース１８を通して、メモリ３へ転送される（図８のステップＳ８４）。メモリ３へのパケット転送が終了すると、ＤＭＡコントローラ１７は、第２パケット検出部１５及びＣＰＵ２に対して、ＤＭＡが完了したことを示すＤＭＡ＿ＣＯＭＰＬ信号を送信する。このＤＭＡ＿ＣＯＭＰＬ信号はさらに、第２パケット検出部１５からステートマシン２０へ送信される（図８のステップＳ８６）。
以降、図６のステップＳ３８で、ＣＰＵ２の指示によりステートマシン２０のサービスが停止させられるまで、パケットの検出が第２パケット検出部１５において連続して行われる。
なお、ステートマシン２０が第２パケット検出部１５からＨレベルのＰＡＣＫＥＴ＿ＲＣＶＤ信号を受信した場合、すなわち、非同期検出通知が行われた場合（図６のステップＳ３２、図８のステップＳ７６）には、ステートマシン２０内で状態ＳＢから状態ＳＡへ遷移し（図４参照）、第１パケット検出部１４の処理が再開する（図５のステップＳ２０）。
（１−４）外部ＴＥから携帯端末（ＵＥ）への上りデータの転送
次に、外部ＴＥから携帯端末への上りデータの転送について、図９を参照して説明する。図９は、外部ＴＥから携帯端末への上りデータの転送のフローを示す図である。図９において、（ａ）〜（ｃ）は外部ＴＥにおけるデータ処理、（ｄ）〜（ｆ）は携帯端末におけるデータ処理、をそれぞれ示している。
先ず、図９（ａ）に示すように、一例として３個のＩＰパケットを外部ＴＥから携帯端末へ転送する場合を想定する。１個目のＩＰパケットは、ＩＰ／ＳＣＴＰヘッダとＬ３（レイヤ３）メッセージのペイロードからなる。２個目のＩＰパケットは、ＩＰ／ＵＤＰ／ＲＴＰと画像データ(1st data)のペイロードからなる。３個目のＩＰパケットは、ＩＰ／ＵＤＰ／ＲＴＰとＳＭＳ(Short Message Service)データ(2nd data)のペイロードからなる。
ここで、ＳＣＴＰ(Stream Control Transmission Protocol)は輻輳制御を行うためのトランスポートレイヤのプロトコルである。ＵＤＰ(User
Datagram Protocol)はＩＰプロトコルに実装されるトランスポートレイヤのプロトコルである。ＲＴＰ(Real-time Transport Protocol)は、音声や動画等のデータストリームをリアルタイムに配送するためのトランスポートレイヤのデータ転送プロトコルである。
なお、図９では、転送対象のＩＰパケットの内容は例示のために図示したに過ぎず、転送対象のＩＰパケットの内容は任意のものでよい。
図９（ｂ）に示すように、この実施形態において、外部ＴＥでは、携帯端末へデータを転送する前に、転送対象のＩＰパケットに対してＣＲＣコードを付加する。すなわち、外部ＴＥは、１〜３個目のＩＰパケットに相当するＳＤＵペイロード（ＵＳＢ用）＃１〜３に対するＣＲＣコードとして、それぞれＣＲＣ＃１〜３を生成して付加する。
次に、外部ＴＥは、図９（ｃ）に示すように、ＵＳＢプロトコルに従い、実施形態の携帯端末との間でＣＲＣコードが付加されたＳＤＵペイロードを固定サイズのデータ毎にバルク転送する。なお、図に示すように、バルク転送データで足りない部分は所定の値（例えば「０」）でパディング(Padding)される。図９（ｄ）は、携帯端末側で受信するＵＳＢバルク転送データを示している。ＵＳＢのバルク転送では、転送データのパケット構成とは無関係に固定長のデータ転送がなされるため、仮に携帯端末側で何らの処置も取っていないとすれば、パケットの同期をとることはできない。
図９（ｅ）において、携帯端末では、図７及び図８を参照して説明した上りデータの処理が行われる。すなわち、携帯端末の上りデータ処理部４では、第１パケット検出部１４が主として動作してＣＲＣ＃１を検出するとともに、ヘッダを推定してパケット長を読み出し、パケット長がＯＫ（正常）であるか確認する。これにより、ＣＲＣ＃１が付加された最初のＩＰパケットが検出される。
いったん最初のＩＰパケットが検出されると、第２パケット検出部１５が主として動作して、ＣＲＣ＃１に続くデータからヘッダを推定してパケット長を読み出すことで、ＣＲＣ＃２が付加された次のＩＰパケットが検出される。同様にして、ＣＲＣ＃３が付加された次のＩＰパケットが検出される。
図９（ｆ）に示すように、図（ｅ）で検出された各ＩＰパケットは、ＰＤＣＰ−ＳＤＵ（ＰＤＣＰペイロード）となる。実施形態の携帯端末では、このＰＤＣＰ−ＳＤＵ（ＰＤＣＰペイロード）に対して順に、ＰＤＣＰ(Packet Data Convergence Protocol)レイヤ、ＲＬＣ(Radio Link. Control)レイヤ、ＭＡＣ(Medium Access Control)レイヤにおいてそれぞれＰＤＣＰヘッダ、ＲＬＣヘッダ、ＭＡＣヘッダが付加されうる。
以上説明したように、本実施形態の携帯端末は、ＣＲＣコードを検出することによりＩＰパケットの同期をとることができるようになっている。よって、ＰＰＰ等のプロトコルを利用することなくＩＰパケットのまま上位レイヤの処理を行うことができる。
（２）第２実施形態
以下、本発明の通信装置の第２実施形態としての携帯端末について説明する。
第２実施形態の携帯端末は、第１実施形態の携帯端末に対して、第２パケット検出部１５におけるパケットの検出の信頼性を向上させるものである。なお、第２実施形態の携帯端末の構成は、図２に示した構成と概略同一であり、主として相違点について以下で説明する。
（２−１）携帯端末（ＵＥ）の構成
本実施形態の携帯端末において、ステートマシン２０が状態ＳＢ（図４参照）にあるときには、ＣＲＣ処理部１９（第２検出部）は、Ｓ／Ｐインタフェース１２から１バイトデータが入力される毎に、内部のバッファに順次蓄積されるデータから、所定の生成多項式に基づくＣＲＣコードを生成していく。そして、生成したＣＲＣコードが、ＣＲＣコードの生成の基礎となる入力データ（処理対象データ）に続く所定量の入力データ（ここで、「所定量」とはＣＲＣコードとして予定するデータ量である。）と一致するかを判定する。その結果、一致した場合には、ＣＲＣコードを検出したことを示す信号をステートマシン２０へ送信する。この信号はさらに、ステートマシン２０から第２パケット検出部１５へ送信される（ＣＲＣ検出通知）。
この実施形態において、第２パケット検出部１５では、以下の処理が行われる。すなわち、カウンタ１５２（測定部）は、セレクタ１３（Ｓ／Ｐインタフェース１２）からの入力とともに動作を開始する。セレクタ１３からの１バイトデータは順次バッファ１５３に蓄積される。ヘッダ解析部１５１は、セレクタ１３から入力するデータの先頭位置が、既に検出されたパケットの次のパケットのヘッダの先頭位置であると推定し、そのヘッダの所定のフィールドからパケット長を読み出す。
第２判定部としての第２パケット検出部１５は、ＣＲＣ検出通知を受けた時点におけるカウンタ１５２のカウント値に基づいて、読み出したパケット長が正しいか否かについての検証を行う。このパケット長の検証では、読み出したパケット長のバイト数がカウント値と一致するかについて判定される。一致する場合、第２パケット検出部１５は、正しくパケットが検出（同期検出）されたと判断する。
（２−２）携帯端末（ＵＥ）のデータ処理
次に、図１０を参照して、本実施形態の携帯端末のデータ処理について説明する。ステートマシン２０が状態ＳＡ（図４参照）にあるときの処理は第１実施形態のものと同一であるため、ステートマシン２０が状態ＳＢ（図４参照）にあるときの処理についてのみ説明する。なお、図１０のフローチャートにおいて、図６と同じステップの部位については同一の符号を付してある。
図１０において、先ず、ステートマシン２０は第２パケット検出部１５に対して処理を開始するように指示し（ステップＳ２２）、セレクタ１３，１６が制御される。これにより、Ｓ／Ｐインタフェース１２からの１バイトデータがＣＲＣ処理部１９及び第２パケット検出部１５へ順次送出され、蓄積されていく。
Ｓ／Ｐインタフェース１２からデータが入力されると、第２パケット検出部１５では、カウンタ１５２が、入力されるバイト数のカウントを開始する（ステップＳ２４）。第２パケット検出部１５は、セレクタ１３（Ｓ／Ｐインタフェース１２）から入力するデータの先頭位置が、既に検出されたパケットの次のパケットのヘッダの先頭位置であると推定し、そのヘッダの所定のフィールドからパケット長を読み出す（ステップＳ２６）。
第２パケット検出部１５は、ＣＲＣ処理部１９からＣＲＣ検出通知を受けると（ステップＳ２７）、カウンタ１５２を停止させる（ステップＳ２８）。そして、第２パケット検出部１５は、カウンタ１５２の値を読み取り、そのカウント値がステップＳ２６で読み出したパケット長のバイト数と一致するか判定することにより、読み出したパケット長が正しいか否かを判断する（ステップＳ２９）。すなわち、パケット長の検証が行われる。
第２パケット検出部１５は、ステップＳ２９においてパケット長が正しいと判断するときには、同期検出通知をステートマシン２０に対して行い（ステップＳ３２）、カウンタ１５２をクリアする（ステップＳ３６）。一方、ステップＳ２９においてパケット長が正しくないと判断するときには、第２パケット検出部１５に対して非同期検出通知を行う（ステップＳ３４）。
以降、ステップＳ３８で、ＣＰＵ２の指示によりステートマシン２０のサービスが停止させられるまで、第２パケット検出部１５においてパケットの検出が継続して行われる。
（２−３）外部ＴＥから携帯端末（ＵＥ）への上りデータの転送
外部ＴＥから本実施形態の携帯端末への上りデータの転送について、図１１に示してある。図１１は、第１実施形態で説明した図９と比較して、（ｅ）における処理のみが異なるものとなっている
図１１（ｅ）において、携帯端末の上りデータ処理部４では、第１パケット検出部１４が主として動作してＣＲＣ＃１を検出するとともに、ヘッダを推定してパケット長を読み出し、パケット長の正常性を確認する。これによりＣＲＣ＃１が付加された最初のＩＰパケットが検出される点は、図９に示した処理と同様である。
いったん最初のＩＰパケットが検出されると、第２パケット検出部１５が主として動作して、ＣＲＣ＃１に続くデータからヘッダを推定してパケット長を読み出す。さらに、ＣＲＣコードの検出、カウンタの値に基づくパケット長の検証を行うことで、ＣＲＣ＃２が付加された次のＩＰパケットが検出される。同様にして、ＣＲＣ＃３が付加された次のＩＰパケットが検出される。
以上説明したように、本実施形態の携帯端末では、いったん最初のパケットが検出された後に継続して行われるパケットの同期を、パケット長の読み出しのみに依存するのではなく、その読み出したパケット長を、ＣＲＣコードの検出に基づき逐次検証する。よって、パケットの検出の信頼性が向上する。
（３）第３実施形態
以下、本発明の通信装置の第３実施形態としての携帯端末について説明する。
第３実施形態の携帯端末は、第１又は第２実施形態の携帯端末に対して、データ処理の高速化を図ったものである。このデータ処理の高速化のため、本実施形態の携帯端末では、第２パケット検出部において、データの入出力が時間軸上で並列となるように制御（パイプライン処理）される。
（３−１）携帯端末（ＵＥ）の構成
第３実施形態の携帯端末の構成を図１２に示す。図１２において、第１実施形態と同一の構成部分については同一の符号を付し、重複説明を行わない。
図１２において、本実施形態の携帯端末において、上りデータ処理部４ａは、図２に示した上りデータ処理部４と比較して、第２パケット検出部１５ａとステートマシン２０ａが相違する。第２パケット検出部１５ａは、ダブルバッファ（いわゆるピンポンバッファ）を構成する１組のバッファ（ＢＵＦ）１５３ａ，１５３ｂを備える点で第２パケット検出部１５と相違する。１組のバッファ１５３ａ，１５３ｂはそれぞれ、予定するパケットの大きさに相当する容量を備えている。
第２パケット検出部１５ａは、パケットを検出する毎に、処理対象のバッファを１組のバッファ１５３ａ，１５３ｂの間で交互に切り替える。処理対象のバッファにセレクタ１３からの１バイトデータが蓄積されていき、処理対象のバッファ内のデータがヘッダ解析部１５１及びカウンタ１５２の処理対象となる。このとき、例えばバッファ１５３ａ（処理対象のバッファ）内にデータを入力している期間と並行して、バッファ１５３ｂからパケットが出力される。同様に、バッファ１５３ｂ（処理対象のバッファ）内にデータを入力している期間と並行して、バッファ１５３ａからパケットが出力される。
図１３は、ステートマシン２０ａの状態遷移図である。以下、ステートマシン２０ａにおける状態遷移について、各状態における上りデータ処理部４ａ内の動作と関連付けて説明する。なお、図１３では、第２パケット検出部１５ａの処理を１組のフェーズＰ＿ａ，Ｐ＿ｂに分けて記載してある。
図１３において、上りデータ処理部４ａの処理が開始されると（サービスイン）、第１パケット検出部１４によるパケット検出（第１パケット検出）を行う状態（状態ＳＡ）となる。これにより、セレクタ１３，１６が制御されて、Ｓ／Ｐインタフェース１２からの１ビットデータが順次、第１パケット検出部１４に入力されるとともに、第１パケット検出部１４においてパケット検出処理が行われることになる。
また、ＣＲＣ処理部１９によりＣＲＣが検出され、かつ第１パケット検出部１４によるパケット長の検証がＯＫとなると（同期検出ＯＫ）、ステートマシン２０ａは、第２パケット検出部１５ａのフェーズＰ＿ａによるパケット検出（第２パケット検出（フェーズＰ＿ａ））を行う状態（状態ＳＢ＿ａ）へ遷移する。これにより、セレクタ１３，１６が制御されて、Ｓ／Ｐインタフェース１２からの１ビットデータが順次、第２パケット検出部１５ａ内のバッファ１５３ａに蓄積されていく。そして、ステートマシン２０ａは、パケットの検出可であることを示す信号（ＬレベルのＰＡＣＫＥＴ＿ＲＣＶＤ信号）、及びＤＭＡが完了したことを示すＤＭＡ＿ＣＯＭＰＬ信号が与えられると（（同期検出ＯＫ）＆（ＤＭＡ完了））、第２パケット検出部１５ａのフェーズＰ＿ｂによるパケット検出（第２パケット検出（フェーズＰ＿ｂ））を行う状態（状態ＳＢ＿ｂ）へ遷移する。
状態ＳＢ＿ｂへ遷移すると、セレクタ１３，１６が制御されて、Ｓ／Ｐインタフェース１２からの１ビットデータが順次、第２パケット検出部１５ａ内のバッファ１５３ｂに蓄積されていく。そして、ステートマシン２０ａは、パケットの検出可であることを示す信号（ＬレベルのＰＡＣＫＥＴ＿ＲＣＶＤ信号）、及びＤＭＡが完了したことを示すＤＭＡ＿ＣＯＭＰＬ信号が与えられると（（同期検出ＯＫ）＆（ＤＭＡ完了））、再度状態ＳＢ＿ａへ遷移する。以後、ステートマシン２０ａは、パケットが検出される毎に、状態ＳＢ＿ａ，ＳＢ＿ｂの間で状態を遷移させる。
なお、ステートマシン２０ａは、状態ＳＢ＿ａ，ＳＢ＿ｂのいずれかの状態にあるときに、同期検出がＮＯＫとなった場合には、状態ＳＡへ遷移させる。
（３−２）上りデータの処理
次に、実施形態の携帯端末における上りデータの処理について、図１４を参照して説明する。図１４は、ステートマシン２０ａが状態ＳＢ＿ａ又はＳＢ＿ｂにあるときのデータフローを示すフロー図である。なお、ステートマシン２０ａが状態ＳＡにあるときのデータフローは、図７に示したものと同一である。図１４において、図８に示したものと同一の処理部位については、図８と同一の符号を付している。
なお、図１４では、第２パケット検出部１５ａの処理をフェーズ毎に区別するため、第２パケット検出部１５ａ（フェーズＰ＿ａ），第２パケット検出部１５ａ（Ｐ＿ｂ）に分けて記載してある。各フェーズが交互に実行される。
いったん最初のパケットが検出されると、ステートマシン２０ａでは状態ＳＢ＿ａへ移行する（図１３参照）。ステートマシン２０ａは第２パケット検出部１５ａ（フェーズＰ＿ａ）に対して処理を開始するように指示する。これにより、Ｓ／Ｐインタフェース１２からの１バイトデータがＣＲＣ処理部１９、及び第２パケット検出部１５ａ（フェーズＰ＿ａ）へ順次送出されていく（ステップＳ７０）。第２パケット検出部１５ａ（フェーズＰ＿ａ）内では、１バイトデータが順次、バッファ１５３ａに蓄積されていく。
ステップＳ７２において、ＣＲＣ処理部１９は、ＣＲＣ検出通知としてＣＲＣ＿ＯＫ信号をステートマシン２０ａを送信する。このＣＲＣ＿ＯＫ信号はさらに、第２パケット検出部１５ａ（フェーズＰ＿ａ）に送信される。第２パケット検出部１５ａ（フェーズＰ＿ａ）は、ＣＲＣ＿ＯＫ信号（ＣＲＣ検出通知）を受けるとパケット長の検証を行い（ステップＳ７５）、パケット長がＯＫであれば同期検出通知としてＬレベルのＰＡＣＫＥＴ＿ＲＣＶＤ信号をステートマシン２０ａへ送信する（ステップＳ７６）。
この時点で、ステートマシン２０ａは、ステップＳ７０より前に検出したパケットのＤＭＡ転送が完了したことを示すＤＭＡ＿ＣＯＭＰＬ信号を、第２パケット検出部１５ａ（Ｐ＿ｂ）から受信済みであるとする。その場合、ステートマシン２０ａでは、状態ＳＢ＿ａから状態ＳＢ＿ｂへ遷移する（図１３参照）。これにより、Ｓ／Ｐインタフェース１２からの１バイトデータがＣＲＣ処理部１９及び第２パケット検出部１５ａ（フェーズＰ＿ｂ）へ順次送出されていく。第２パケット検出部１５ａ（フェーズＰ＿ｂ）内では、Ｓ／Ｐインタフェース１２からの入力データの転送先から切り替えられ（ステップＳ８０）、１バイトデータが順次、ＣＲＣ処理部１９、及び第２パケット検出部１５ａ（フェーズＰ＿ｂ）のバッファ１５３ｂに蓄積されていく（ステップＳ９０）。そして、ＣＲＣ検出通知としてのＣＲＣ＿ＯＫ信号がＣＲＣ処理部１９からステートマシン２０ａへ、さらには第２パケット検出部１５ａ（フェーズＰ＿ｂ）へ送信される（ステップＳ９２）。
一方、第２パケット検出部１５ａは、ステップＳ７６の後、検出されたパケット（バッファ１５３ａ内の入力データ）をメモリ３へ転送するためのＤＭＡを要求するＤＭＡ＿ＲＱ信号をＤＭＡコントローラ１７へ送信する（ステップＳ８２）。その後、検出されたパケットが１バイトデータ毎に順次、バスインタフェース１８を介してメモリ３へ転送される（ステップＳ８４）。
ここで、ステップＳ８４とステップＳ９０については、異なるバッファに対する処理であるため、時間軸上で少なくとも一部を並列に行うことが可能である。
ステップＳ８４におけるデータ転送が完了すると、ＤＭＡ転送が完了したことを示すＤＭＡ＿ＣＯＭＰＬ信号が、ＤＭＡコントローラ１７からＣＰＵ２及び第２パケット検出部１５ａ（フェーズＰ＿ａ）へ送信される。このＤＭＡ＿ＣＯＭＰＬ信号はさらに、ステートマシン２０ａへ送信される（ステップＳ８６）。これにより、第２パケット検出部１５ａ（フェーズＰ＿ａ）は、第２パケット検出部１５ａ（フェーズＰ＿ｂ）による同期検出が終了すればいつでも処理が開始可能な状態となる。
以上説明したように、本実施形態の携帯端末では、いったん最初のパケットが検出された後に継続して行われるパケット検出処理において、データ入力とパケットの出力（転送）とが時間軸上で並列となるように制御される。よって、本実施形態の携帯端末では、パケットの同期のためのデータ処理が高速化される。
以上、本発明の実施形態について詳細に説明したが、本発明の通信装置、パケット同期方法は上記実施形態に限定されず、本発明の主旨を逸脱しない範囲において、種々の改良や変更をしてもよいのはもちろんである。
例えば、以上の各実施形態では、ＩＰパケットのパケット長を読み出す処理を行っているが、この処理は、ＩＰパケットのバージョン情報に応じて変更するようにしてもよい。より具体的には、ＩＰｖ４とＩＰｖ６では、ＩＰパケットのヘッダ内に含まれるパケット長の情報のフィールド位置が異なるため、ＩＰパケットのパケット長を読み出す処理では、先にバージョン情報を読み出し、バージョン情報を認識したうえで適切なフィールド位置からパケット長を読み出すようにする。なお、ＩＰｖ４とＩＰｖ６は共に、バージョン情報がヘッダの先頭に配置されている。
また、以上の実施形態は主としてＩＰパケットの同期をとる観点から説明してきたが、パケットの種類が限られないのは当然である。すなわち、このパケット同期方法は、隣接パケット間に付加されるＣＲＣコードの検出に依拠しており、既知の場所からパケット長の情報を読み取ることが可能であれば、パケット自体の種類は問わない。

Claims (8)

  1. 有線接続される外部装置からの入力データに対して、パケットの同期をとる通信装置であって、
    前記外部装置からの入力データを１又は複数の単位データに変換する変換部と、
    該単位データの入力毎に、所定量の第1入力データを検査符号とし、該第1入力データより前の入力データを検査対象データとした検査を行い、所望の検査結果を得ることをもって検査符号を検出する第1検出部と、
    前記第1検出部により検査符号が検出されたときの検査対象データの先頭位置が第1パケットのヘッダの先頭位置であると推定し、当該ヘッダから前記第1パケットのパケット長を読み出す第1ヘッダ解析部と、
    前記第1検出部により検査符号が検出されたときの検査対象データの長さが、前記第1ヘッダ解析部により読み出されるパケット長、と一致するかを判定する第1判定部と、
    第1検出部により検出される検査符号に続く入力データの先頭位置が、前記第1パケットに続く第2パケットのヘッダの先頭位置であると推定し、当該ヘッダから前記第2パケットのパケット長を読み出す第2ヘッダ解析部と、
    を備えた、通信装置。
  2. 前記第2パケットのヘッダの先頭位置からの入力データ長を、単位データ量毎のデータ入力毎に測定する測定部と、
    前記第2パケットのヘッダの先頭位置からの入力データを処理対象データとして、当該処理対象データに対応する所定量の検査符号を、単位データ量毎のデータ入力毎に生成し、生成した検査符号が処理対象データに続く前記所定量の入力データと一致することをもって検査符号を検出する第2検出部と、
    前記第2検出部により検査符号が検出されたときの前記処理対象データの長さが、前記測定部により測定される入力データ長と一致するかを判定する第2判定部と、
    を備えた、請求項1に記載の通信装置。
  3. 前記第1判定部により、検査対象データの長さがパケット長と一致すると判定した後は、前記第2ヘッダ解析部によりパケット長を順次読み出すことにより後続のパケットの同期をとる、
    請求項2に記載の通信装置。
  4. 前記第2判定部において、処理対象データの長さが入力データ長と一致しない場合には、前記第1検出部による検査符号の検出処理が行われるように制御される、
    請求項2に記載の通信装置。
  5. データ入力及び前記第2パケットの出力が時間軸上で並列となるように、ダブルバッファ構成からなる、
    請求項2に記載の通信装置。
  6. 前記パケットはIP(Internet Protocol)パケットであって、
    前記第1ヘッダ解析部及び前記第2ヘッダ解析部は、IPパケットのヘッダの所定位置に配置されるバージョン情報に応じて、当該ヘッダのパケット長を読み出す、
    請求項1に記載の通信装置。
  7. 有線接続される外部装置からの入力データに対して、パケットの同期をとるパケット同期方法であって、
    前記外部装置からの入力データを１又は複数の単位データに変換し、
    該単位データの入力毎に、所定量の第1入力データを検査符号とし、該第1入力データより前の入力データを検査対象データとした検査を行い、所望の検査結果を得ることにより検査符号を検出し、
    前記検査符号が検出されたときの検査対象データの先頭位置が第1パケットのヘッダの先頭位置であると推定し、当該ヘッダから前記第1パケットのパケット長を読み出し、
    前記検査符号が検出されたときの検査対象データの長さが、読み出された前記パケット長と一致するかを判定し、
    検出された前記検査符号に続く入力データの先頭位置が、前記第1パケットに続く第2パケットのヘッダの先頭位置であると推定し、当該ヘッダから前記第2パケットのパケット長を読み出す、パケット同期方法。
  8. 第1通信装置と、該第1通信装置と有線接続され、且つ該第1通信装置からの入力データに対してパケットの同期をとる第2通信装置とを含む通信システムであって、
    第1通信装置は、パケットに検査符号を付加してから第2通信装置へデータを出力し、
    第2通信装置は、
    前記第1通信装置からの入力データを１又は複数の単位データに変換する変換部と、
    該単位データの入力毎に、所定量の第1入力データを検査符号とし、該第1入力データより前の入力データを検査対象データとした検査を行い、所望の検査結果を得ることをもって検査符号を検出する第1検出部と、
    前記第1検出部により検査符号が検出されたときの検査対象データの先頭位置が第1パケットのヘッダの先頭位置であると推定し、当該ヘッダから前記第1パケットのパケット長を読み出す第1ヘッダ解析部と、
    前記第1検出部により検査符号が検出されたときの検査対象データの長さが、前記第1ヘッダ解析部により読み出されるパケット長、と一致するかを判定する第1判定部と、
    第1検出部により検出される検査符号に続く入力データの先頭位置が、前記第1パケットに続く第2パケットのヘッダの先頭位置であると推定し、当該ヘッダから前記第2パケットのパケット長を読み出す第2ヘッダ解析部と、
    を備えた、通信システム。
JP2011503562A 2009-03-12 2009-03-12 通信装置、パケット同期方法 Expired - Fee Related JP5382109B2 (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2009/001122 WO2010103574A1 (ja) 2009-03-12 2009-03-12 通信装置、パケット同期方法

Publications (2)

Publication Number Publication Date
JPWO2010103574A1 JPWO2010103574A1 (ja) 2012-09-10
JP5382109B2 true JP5382109B2 (ja) 2014-01-08

Family

ID=42727884

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2011503562A Expired - Fee Related JP5382109B2 (ja) 2009-03-12 2009-03-12 通信装置、パケット同期方法

Country Status (5)

Country Link
US (1) US8891558B2 (ja)
EP (1) EP2408139A1 (ja)
JP (1) JP5382109B2 (ja)
CN (1) CN102349261B (ja)
WO (1) WO2010103574A1 (ja)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104519525B (zh) * 2013-09-30 2018-02-06 日月光半导体制造股份有限公司 压缩封包的发送装置与接收装置与其发送方法及接收方法
US10749641B2 (en) 2016-10-11 2020-08-18 Qualcomm Incorporated Media access control header and transport block formats
CN112005508B (zh) * 2018-04-25 2023-02-17 三菱电机株式会社 信息处理装置、信息处理方法及计算机可读取的记录介质
US11831743B1 (en) * 2019-01-08 2023-11-28 Xilinx, Inc. Streaming architecture for packet parsing

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH06252874A (ja) * 1993-03-01 1994-09-09 Nec Corp ワード同期検出回路
JP2007089161A (ja) * 2005-09-16 2007-04-05 Samsung Electronics Co Ltd デジタルビデオ放送システムにおける、セクションの検出及び信頼性情報の取得のための多重巡回冗長検査装置及び方法
JP2007195185A (ja) * 2006-01-18 2007-08-02 Samsung Electronics Co Ltd 無線通信システムにおけるバースト処理装置及び方法
JP2008227875A (ja) * 2007-03-13 2008-09-25 Sanyo Electric Co Ltd データ再生装置及びデータ再生方法

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6298387B1 (en) * 1996-07-12 2001-10-02 Philips Electronics North America Corp System for detecting a data packet in a bitstream by storing data from the bitstream in a buffer and comparing data at different locations in the buffer to predetermined data
EP1104961A1 (en) * 1999-12-03 2001-06-06 Hewlett-Packard Company, A Delaware Corporation Deferral of transmissions in wireless local area network
GB2371954B (en) * 2001-02-01 2003-02-19 3Com Corp Interface system for wireless node and network node
CA2366397A1 (en) * 2001-12-31 2003-06-30 Tropic Networks Inc. An interface for data transfer between integrated circuits

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH06252874A (ja) * 1993-03-01 1994-09-09 Nec Corp ワード同期検出回路
JP2007089161A (ja) * 2005-09-16 2007-04-05 Samsung Electronics Co Ltd デジタルビデオ放送システムにおける、セクションの検出及び信頼性情報の取得のための多重巡回冗長検査装置及び方法
JP2007195185A (ja) * 2006-01-18 2007-08-02 Samsung Electronics Co Ltd 無線通信システムにおけるバースト処理装置及び方法
JP2008227875A (ja) * 2007-03-13 2008-09-25 Sanyo Electric Co Ltd データ再生装置及びデータ再生方法

Also Published As

Publication number Publication date
US8891558B2 (en) 2014-11-18
CN102349261A (zh) 2012-02-08
EP2408139A1 (en) 2012-01-18
JPWO2010103574A1 (ja) 2012-09-10
WO2010103574A1 (ja) 2010-09-16
CN102349261B (zh) 2014-06-04
US20110317724A1 (en) 2011-12-29

Similar Documents

Publication Publication Date Title
JP4675913B2 (ja) 無線通信システムにおけるバースト処理装置及び方法
JP5382109B2 (ja) 通信装置、パケット同期方法
US8261162B2 (en) Decoding device, decoding method, and media data delivery system
JP7041255B2 (ja) 送信デバイス、受信デバイス、及びアップリンクデータ圧縮を処理するためにそれらにおいて実行される方法
JP2015027100A (ja) パケット通信の伝送制御方法及びパケット通信システム
US8811180B2 (en) Communication apparatus and communication method
US20120163221A1 (en) Communication Device, Communication Method and Computer Program Product
JP2006197173A (ja) 無線通信装置、無線通信システム、及び無線通信方法
CN109673021B (zh) 业务时延确定方法
CN110248379A (zh) 无线局域网中基站的性能测试方法及装置
JP2007101457A (ja) 送信装置及び受信装置及び時刻通知方法及び時刻設定方法
JP2015023463A (ja) パケット解析装置、パケット解析方法、及びパケット解析プログラム
JP5924880B2 (ja) データ通信システム、プリアンブル長最適化方法、及び通信装置
JP5201265B2 (ja) 無線通信装置およびデータ受信方法
JP5489252B2 (ja) ｅＭＢＭＳ伝送のダウンリンク・データ同期を制御する方法および装置
CN107872357B (zh) 一种测量链路可用带宽的方法、设备及系统
EP3142277B1 (en) Fault tolerance method and apparatus for microwave transmission and computer readable storage medium
JP5283496B2 (ja) Ｌａｎ中継装置
JP2010118894A (ja) パケット生成装置、パケット生成方法及びパケット生成プログラム
JP4581925B2 (ja) データ転送装置およびデータ転送方法
JP2016005220A (ja) 送信装置、送信方法、プログラム
WO2015040833A1 (ja) 通信装置及び通信装置の制御方法
JP2012049883A (ja) 通信装置およびパケット処理方法
WO2016054911A1 (zh) 检测方法、发送端、接收端及检测系统
JP2015186087A (ja) 計測装置、制御装置、計測方法、制御方法

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20130521

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20130702

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: 20130903

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20130916

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees