Tech Blog
組み込み機器におけるネットワーク通信の基礎とOKIアイディエスのTCP／IPスタック その2
こんにちは、小野です。
前回のブログでは、私たちの生活に身近な情報家電から工場で活躍する産業用ロボットまであらゆる組み込み機器に普及しているネットワーク通信を特集しました。
まだ前回を読んでいない方は、まずこちらからお読みください。
さあ、コーナーキック！ここがチャンスだ…！あれ、映像が止まった。せっかくいいところなのに…。
何を見てるの？
FIFAワールドカップの試合中継です。ここでシュートが決まれば、同点に追いついてさらに熱い試合展開になるはずが、映像が固まって見れなくなっちゃったんですよ。一緒に直すのを手伝ってください！
もちろん！早く私たちも「トラブルシュート」を決めなければ！まずは、受信側のテレビの問題か、それとも通信自体が途切れたのかを見てみよう。…ケーブルの状態も確認して…。あ、映ったよ。そうそう、テレビも組み込み機器なんだよね。
「シュート」と「トラブルシュート」をかけたギャグですね。そういえば、前回のブログでは、組み込み機器におけるネットワーク通信の基礎を紹介しました。組み込み機器の通信って、ただつながればいいわけではないんですよね。
その通り。限られたCPUやメモリーの中で、遅延や揺らぎ、パケットロスをどう抑えるかが重要になる。
遅延はなんとなくイメージできますが、揺らぎってあまりなじみがないですね。パケットロスは前回のブログで少し出てきました。試合の行方も気になるところですが、通信品質の話も気になってきました。
ということで、今回はその続編として、OKIアイディエスのTCP／IPスタックを使った開発事例と、通信品質の課題・対策を解説するよ。実際の開発事例を見ながら、どんな課題があり、どう対策しているのかを紹介していこう。
開発事例：監視カメラシステムの開発
今回は過去にOKIアイディエスで開発していた監視カメラシステムを例に取って、TCP／IPスタックの開発事例を紹介しよう。
なるほど、こんなシステムなんですね。監視カメラが複数台あります。
監視カメラ→ネットワーク（LAN／WAN）→録画装置や管理端末という流れで映像データが送信されています。
監視カメラ→ネットワーク（LAN／WAN）→録画装置や管理端末という流れで映像データが送信されています。
ここでポイントになるのは、安定した通信とリアルタイム性の確保だよ。カメラや録画装置、監視端末など複数の機器を接続するために、OKIアイディエスのTCP／IPスタックを活用したんだ。
TCP／IPスタックで、カメラや録画機器などの低リソースのデバイスでも安定した通信を実現しているんですね。当社のTCP／IPスタックは、組み込み機器でよくある低リソースのデバイスでも安定して通信できるのが特徴でしたね。
前回のブログでは、TCP／IPスタックやTCP／IPのルールについて説明したね。今度は映像データをどのように送るのかを詳しく見ていくよ。
パケット化とは
映像や画像のデータはサイズが大きすぎて、そのままでは一度の通信で送れないんだ。だから、通信で扱える大きさに分割する。分割したものをパケットというよ。
上の図は、送信側で映像をどのように処理しているかを表した図ですね。なるほど、複数のパケットを順番に送ることで、1つのデータを相手に届ける仕組みなんですね。
そう。受信側でパケットを並び替えて元の映像を作るんだけど、パケットは順番に届くとは限らないんだ。そこで、パケットの順番を確認するための情報として、パケットにヘッダーを付けているんだ。
受信側がヘッダーを確認すれば元の映像を作れるっていう寸法ですね。これなら、受信側が届いたパケットの順番を整理して、正しい映像をつくることができるんですね。
通信データ処理のポイント
データを受信した側でも、データを正しく扱うために、当社で開発するときのポイントってあるんですか？
うん。単に受信できればいいというわけではない。通信相手が正しいデータを送ってくれても、受信側で間違って解釈してしまうと本末転倒だからね。
確かにそうですね。どんなところに気を付けたらいいんですか？
1つ目はエンディアンといって、複数バイトのデータをどう並べるかという順番に要注意！
通信の送信側と受信側でCPUが違うと、複数バイトの解釈の仕方が変わってしまうので、こういうときは変換処理が必要になるよ。
通信の送信側と受信側でCPUが違うと、複数バイトの解釈の仕方が変わってしまうので、こういうときは変換処理が必要になるよ。
補足
- リトルエンディアン：一般的なPC環境であるWindowsやLinux、x86系CPUで使われるエンディアン
- ビッグエンディアン：ネットワーク分野や一部のRISC系CPUで使われるエンディアン
ネットワーク通信ではビッグエンディアンがネットワークバイトオーダーとして用いられる
2つ目のポイントはアライメント。データの整列のさせ方だよ。
データの配置、つまりアドレスの境界はCPUやOS、コンパイラで異なるからね。境界がずれると、性能低下やアクセスエラーの原因になるんだ。
データの配置、つまりアドレスの境界はCPUやOS、コンパイラで異なるからね。境界がずれると、性能低下やアクセスエラーの原因になるんだ。
補足
- 構造体：関連する複数のデータをひとまとめにして扱うためのデータ形式
- バッファ：データを一時的に保存しておくための領域
そして、3つ目はパディング（空き領域）だよ。
構造体のサイズやレイアウトをそろえるために入ることがあるんだけど、意図しないデータのずれにつながることがあるから要注意なんだ。
構造体のサイズやレイアウトをそろえるために入ることがあるんだけど、意図しないデータのずれにつながることがあるから要注意なんだ。
データの送信側だけに目がいきがちでしたけれど、受信側でもいろいろ工夫が大事なのか…。でもこれって、データを受け取れる前提の話ですよね。通信品質を考えると、通信の遅延の対策も必要なんじゃないんですか？
その通り！ その通り。遅延は通信品質に大きく関わる課題の1つなんだ。ここからは、実際にどんな通信の不具合が起こるのかを見ていこう。
実際の開発で考慮すべき通信品質のポイント
パソコンやスマホで動画を視聴するときに、たまにフリーズしたり、映像と音声がずれたりすることがあります。安定して通信できるって大事ですよね。
通信品質にはさまざまな課題があるけど、ここでは代表的なものとして「遅延」「揺らぎ」「パケットロス」の3つを取り上げるよ。ここでは、それぞれがどんな通信の不具合につながるのか、簡単にまとめたよ。
- 遅延：映像や操作が遅れること。
⇒映像や制御のリアルタイム性が損なわれてしまう。 - 揺らぎ：受信側のパケット到着間隔が不安定になること。
⇒再生が不安定になり、映像のカクツキや音声の乱れが発生する。 - パケットロス：通信の途中でパケットが失われてしまうこと。
⇒映像データが欠け、画面や音声の乱れが発生する。
ひとくちに通信が安定しないといっても、遅延だけじゃなくて、揺らぎやパケットロスというものが発生するんですね。通信品質の悪化につながるものは防ぎたいものですが、どんな対策があるんですか？
それぞれには、対策があるから順番に見ていこう！
まず、遅延を抑えるためにはQoS（Quality of Service）という仕組みが使われるよ。
まず、遅延を抑えるためにはQoS（Quality of Service）という仕組みが使われるよ。
QoSは特定の通信を優先して処理するという手法だよ。リアルタイム性が求められる監視カメラシステムでは、映像データが特に重要なので映像データを優先して転送する設定にしたんだ。
よくよく考えれば、通信データのすべてがリアルタイム性を必要とするとは限りませんよね。設計の段階で、どの通信を優先して処理するのかを作り込むことで、遅延対策をするということか！
続いて、揺らぎへの対策としては、ジッタバッファを用いる方法があるよ。
受信したパケットを一時保存して一定のタイミングで再生することで、揺らぎを吸収するんだ。
受信したパケットを一時保存して一定のタイミングで再生することで、揺らぎを吸収するんだ。
再生する前にワンクッションを置くことで、一定間隔でパケットを処理すれば、映像や音声の乱れもなく、途切れずになめらかに再生できるってことですね。
最後に、パケットロスに対しては、QoSと受信側からのフィードバック制御（RTCP：RTP Control Protocol）を組み合わせて、通信状況を把握しながら対策するよ。さらに、万が一パケットが欠落したときを考慮して、そのパケットを再送する制御も組み合わせる設計手法もあるよ。
3つの合わせ技だ！
なるほど、RTCPの役割は、受信側が送信側に受信したパケット数などの状況を伝えて、送るペースを調整してもらう、というイメージですね。
なるほど、RTCPの役割は、受信側が送信側に受信したパケット数などの状況を伝えて、送るペースを調整してもらう、というイメージですね。
原因の切り分けと特定が大切
前に監視カメラを開発したときは、対策を講じても、評価の段階で映像の乱れが発生していたんだよ…。
そうだったんですね。その原因がわからないと、実はなかなか難しい…？
その時は受信側に原因があることが判明したので、ジッタバッファの設定を調整することで対策できたんだ。でも、問題が発生したときに一番大切なことは、どこに原因があるのかを切り分けることなんだ。
送信側に問題があるのか、それとも受信側に問題があるのか、ということですか？
その通り。たとえば送信側に問題がある場合は、パケットの送信間隔や送信処理、通信負荷などを確認する。受信側に原因がある場合は、ジッタバッファの設定や処理能力、再生タイミングの乱れなどを確認するんだ。
どこで問題が起きているのかを切り分け、その根本原因を特定する。そして、原因にあった設計・対策を行うことが重要なんですね。
その通りだよ。それが通信品質を確保する第一歩なんだ。OKIアイディエスでは、実運用を見据え、後から問題が発生しないよう設計・対策を行っているんだ。
FPGAで実現するTCP／IP高速化ソリューション iTOE™
ここまで、TCP／IPスタックを使ったソフトウェア側の通信処理や、通信品質を安定させるための設計上の工夫を紹介してきたね。
ただし、さらに高速な通信処理が求められる場合には、ハードウェア側で処理を分担する方法もあるんだ。
たとえば、TCP／IP通信の処理の一部をCPUの代わりにFPGAに処理させるIPがあって…。
ただし、さらに高速な通信処理が求められる場合には、ハードウェア側で処理を分担する方法もあるんだ。
たとえば、TCP／IP通信の処理の一部をCPUの代わりにFPGAに処理させるIPがあって…。
はい！その答えはOKIアイディエスのiTOE™ （intelligent TCP／IP Offloading Engine）ですね？
ピンポン、大正解だね。そう、iTOEはTCP／IP通信処理の一部をFPGAにオフロードさせることで通信を高速化するIPだよ。実は、このFPGAの中にMicroBlazeというソフトコアプロセッサを実装し、そこにOKIアイディエスのTCP／IPスタックを組み込んでいるんだ。高速通信だけでなく、制御データのような低速の通信も同時に行えるのだ。
そうだったのですか？！前に紹介していたのに全然知りませんでした。FPGAでTCP／IPスタックを使いたい、という場合にはiTOEをご提案しているんですね。
マイコンやCPUだけでは実現が難しい通信速度が求められる場合にも、iTOEはおすすめだよ。
1G、10G、25G、100Gと、必要な帯域に応じてラインナップしているので、気になった方はぜひチェックしてください！
1G、10G、25G、100Gと、必要な帯域に応じてラインナップしているので、気になった方はぜひチェックしてください！
最後に
…そういえば、さっき止まったサッカー中継も、通信が安定していればあの大事な場面を見逃さずに済んだかもしれませんね。
まさにそうだね。必要な情報を、必要なタイミングで受け取れないと困る という点では、組み込み機器のネットワーク通信も同じなんだ。
データを正しくやりとりすることと、通信を安定させることの両方が大事なんだよ。
データを正しくやりとりすることと、通信を安定させることの両方が大事なんだよ。
はい！単にデータをやりとりするといっても、安定してパケットを送受信するための仕組みや設計のポイントがたくさんあるんですね。
エンディアンやアライメント、パディングを正しく設計することで、正しくデータを送信したり受信したりできるようになるんだ。
遅延や揺らぎ、パケットロスといった通信の課題には、それぞれ適切な対策を行うことが重要です。
まずどこに問題があるのか切り分けることも大事だよ。OKIアイディエスでは、課題と対策の関係を整理しながら、実運用を見据えて設計や対策を行っているのだよ。
それから、TCP／IPスタックによるネットワーク通信をさらに高速化したい場合は、TCP／IP通信処理の一部をCPUの代わりにFPGAに処理させるiTOEを利用することで、さらなる高速化もできるのは、大きなアピールポイントです。ソフトウェア、ハードウェアの両面から、通信品質が確保できますね。
その通り。組み込み機器の通信品質改善や高速化でお困りの際は、ぜひご相談ください！
次回のブログ更新は9月を
予定しています。お楽しみに！
予定しています。お楽しみに！
おまけ：専門用語解説コーナー
「この記事、専門用語てんこ盛りだな～」と思ったあなたのために、簡単に解説します！
- パケット：ネットワークで送受信する、まとまったデータの単位。
- MTU （Maximum Transmission Unit）：1回の通信で送れるデータの最大サイズ。
- エンディアン：複数バイトのデータを、どの順番で並べて扱うかを表す方式。
- アライメント：データをCPUが扱いやすい位置にそろえること。
- パディング：データの配置をそろえるために入れる空き領域。
- QoS （Quality of Service）：通信の種類に応じて、優先度や品質を調整する仕組み。
- RTP （Real-time Transport Protocol）：音声や映像などのデータを、リアルタイムに送受信するための通信プロトコル。
- RTCP （RTP Control Protocol）：RTPで送る音声や映像の状態を、送信側と受信側でやり取りするための制御プロトコル。
- ※記載されている会社名、製品名は、各社の商標または登録商標です。
- ※ここに記載されている仕様、デザインなどは予告なしに変更する場合があります。
