WAP 2.0が2001年6月に発表され、2001年12月には、KDDIからこの技術を使ったEZwebサービスが開始された。いまとてもホットなWAP 2.0である。前回『携帯電話の新標準となるか「WAP 2.0」』では、その概要を紹介した。

　WAP 2.0の技術の真髄は、Webページの書き方などではなく、ネットワーク、つまり無線上に、どうやってデータ（ここではWebページの情報）を流すかにある。この部分を理解することで、どのようにWAPのネットワークが構築されているのか、そしてWAPの本質が何であるのかが見えてくることだろう。また、この背景を知っていれば、携帯電話向けサーバを運営する人にとっても役に立つだろう。

　今回は、WAP 1.xから大きく変わったWAP 2.0のネットワークとそのプロトコルについて紹介する。

●事業者ネットワークプロトコルの変遷

　携帯電話などの無線で使われているデータ通信の方式（プロトコル）は、電話会社（キャリア、事業者）ごとに違う。インターネットのような共通規格を使わなくても、「電話会社の中」と範囲が限られるため、コストと使いやすさに優れた、独自プロトコルを使っている。しかし、複数の電話会社で乗り入れをしたり、データ通信を行おうとすると、電話会社によらない決まり事を作る必要に迫られた。それが「WAPのネットワークプロトコル」である。

　iモードやEZwebのように、情報（コンテンツ／ホームページ）を提供するサーバをインターネット上に置いて、そこから携帯電話にデータを提供する仕組みが一般的になってきた。「インターネット上にある」というのは、Webと同じ仕組みというわけだ。つまり、この部分はインターネットの仕組みを使って、多くの人が手軽に情報（つまりWebページ）を提供できるようにしている。

　しかし、携帯電話側にPCと同じ、Webの仕組みが実装されているのだろうか？

　実はそうではない。携帯電話は無線通信だから、通信中に切断されることが当たり前に起こってしまう。また、電池容量や処理能力や画面サイズが劣るため、PCのフルスペックを入れることは非効率である。それでは携帯電話のこの部分はどのようになっているのだろうか？

　前回も紹介したが、このような携帯電話のネットワークの話をする際に、必ず出てくるのが次の「事業者網」と「インターネット（情報提供者側網）」の2つである（図1）。なぜならば、この2つのネットワークは、ポリシーも、実装も、プロトコルも違う「異質」なネットワークだからだ。

図1　WAP 2.0における2つの網

　インターネット網は、極言すればWebページを設置して情報提供を行う網である。一般的に携帯電話向け情報提供者（コンテンツ提供者）となる人が接するネットワークである。

　もう一つは電話会社側のネットワークの「事業者網」である。これは、電話会社の中のネットワークであり、携帯電話の無線通信部分からバックボーン（データを転送する大きな道）などまでが含まれる。この2つのネットワークを分けるのが「ゲートウェイ」である。特に、WAPの場合は「WAPゲートウェイ」と呼ばれる。またWAP 2.0からは「WAPプロキシ」と呼ばれるようになっている。

　一般の人は、インターネット網からWAPゲートウェイの部分までしか接することができない。そのため、事業者網については知らなくても、コンテンツの提供については何ら問題はないといえる。むしろ、事業者側としては、コンテンツ提供者が事業者網の特殊事情を意識することなく、コンテンツ開発ができるように、ゲートウェイを設けているといってもよい。

　しかし事業者網こそ、本来のWAPが活躍する部分であり、またこの技術の奥深さを知ることで、ケータイWeb運営にも参考になることだろう。

　また、網のオープン化もうたわれる昨今である。どのレベルからWAPの参入の可能性があるのかは、現在あまり語られていない。それには、事業者網側のWAPの知識が必要となる。それでは、この2つの網について説明を進めることにしよう。

　Webページ作成者など、一般のコンテンツ開発者は、このインターネット部分にしか接することはできない。インターネットそのものであるので、標準のTCP/IP上にあるHTTPで通信している。これは、WAP 1.xもWAP 2.0も変わらない。

　1つ変わったことといえば、（通信プロトコルではないのだが）コンテンツ記述言語が以前はWMLであったのに対して、WAP 2.0ではWMLもしくはXHTML-Basicベース（XHTML-MP）を利用するようになった点である。

　このように、コンテンツを開発する人は、特殊なサーバや特殊なプロトコルを準備せずに、WAP 2.0向けのコンテンツの提供ができる。携帯電話向けWebページも、PC向けWebページも（記述言語とファイルタイプ以外は）同じように、しかも、新たに投資することなく（同じ設備で）提供できるのは大きなメリットといえる。インターネットプロバイダのホームページエリアからでも提供できるため、個人のコンテンツ提供者も多く、参入しやすい環境ができてきている。とはいえ、現実には、ファイルタイプが異なるだけで、つまずく初心者が多いのも事実ではあるが……。

　コンテンツの提供側から見ると、インターネットWebと携帯電話コンテンツの境目はない。コンテンツサーバから見ると、ネットワーク的には、すべての携帯電話は特定できるゲートウェイサーバからアクセスがくる。そのため、大企業などのProxyサーバからのアクセスと同じように見える。もちろん、携帯電話からきたかどうかを判定するためのUA情報（UserAgent）というものもあり、これで判別することもできる。

●WAP 2.0で求められたスペック

　それでは核心の事業者網側のプロトコルについて紹介しよう。WAP 2.0のスペックには、

• 大きいデータの転送ができるようにする
• E2E（end to end） SSLの実現
• 携帯電話の無線通信に特化した仕様の導入

ということが求められていた。

　データ量の削減よりも、大容量高速データ転送を使いやすくするように方針変更した背景には、高速化された無線データ通信（3G）のアプリケーションとしてWAP 2.0を使いたい意向があったからだ。

　これらのスペックを実現するためには、WAP 1.xのプロトコルスタックを排して、新しいものに置き換える必要があった。結論からいうと、WAP 2.0では、w-TCP、w-HTTPを使った通信を行うこととなった。そして、E2Eの実現のために、コンテンツをゲートウェイで圧縮転送するためのバイナリ変換の仕組みを捨てた（次回に詳細を説明）。

　まず図2を見てほしい。データ通信はプロトコル（通信手順、通信の約束事）を決めて行い、通常ネットワークでは7階層にプロトコルが分類されている。これが「プロトコルスタック」であり、下層に行くほど、レイヤが低いという。最下層の物理層は、イーサケーブルや、cdmaOneやPDCなどの無線の規格を決めている層である。

図2　インターネットで用いられるプロトコルスタック

　通常のインターネットだと「HTTP」「TCP」「IP」と積まれているのが分かるだろう。またゲートウェイを介したときは、ゲートウェイの内側と外側で使われるプロトコルスタックが異なる。WAP 2.0の例（図3）を見てほしい。ゲートウェイで隔てられた、2つのネットワークのプロトコルスタックが異なっているのが分かるだろう。ゲートウェイ右側の「TCP」の部分が、左側の電話会社内部のネットワークでは「w-TCP」となり、「HTTP」のところは「w-HTTP」となっている。

図3　WAP 2.0で用いられるプロトコルスタック

　WAP 1.x、EZwebネットワーク、WAP 2.0ネットワークについてまとめたのが図4である。au端末のC4xxシリーズまでのEZwebネットワークでは、「TCP/IP」ではなくて「UDP/IP」が使われている。また、「HTTP」の代わりに「HDTP」（Handheld Device Transport Protocol）という独自プロトコルを用いている。HDTPは、Openwave Systems社の記述言語「HDML」を転送するためのプロトコルである。正式なWAPでHTTPに相当するプロトコルは「WSP/WTP」（Wireless Session Protocol/Wireless Transaction Protocol）と決められている。

図4　WAP 1.x、EZwebネットワーク、WAP 2.0ネットワークの比較

　それでは、このw-TCPとw-HTTPの正体と、WAP 1.xからプロトコルが変更された理由を見てみよう。

　WAP1.xでは、UDP/IPというプロトコルを使っていた。これは、インターネット上のWebなどで利用されているTCP/IPとは異なる通信プロトコルである。UDPが採用された理由は、TCPほど通信のシーケンスが多くないため、トラフィックが狭い無線通信に向いているためである（詳しくは「携帯電話のデータダウンロードサービスの違いと通信プロトコル」で解説した）。

　特に、WAPでは無線通信が前提であるため、通信中の切断（電波断）は当たり前のように発生する。TCPは切断されると、失ったデータの再送要求を出し、正しいデータをくまなく取得しようとする。これが頻繁に起こると、ネットワークが再送要求だらけになり、正常の通信を圧迫する可能性がある。

　一方UDPは、送ったら送りっぱなしで再送はしない。どうしても失えないデータは、その上位のレイヤで、必要なときだけ再送を行うようにしている。再送パケットによって生じるネットワークの能力低下を回避するようになっている。

　しかし、このUDPを利用することによるデメリットもある。大きなデータを転送することができないのだ。

　TCPの場合は、送信されたパケットが順番どおり届かなくても、正しい順番に並べ替えて、データを復元してくれる。これに対して、UDPではパケットの正しい順番を知ることも、パケットが失われたことも知ることができない。UDPで一度に送れるパケットサイズは1.5Kbytesであり、それを超えるものは転送できなかった（EZwebでは、カラー対応の端末において制限が8Kbytesまでとなった）。この制限は非常に厳しいもので、WAPサービス自体の限界を感じさせる原因の1つとなってしまった。カラー画像になれば、携帯電話の画面に入る小さいサイズのものでも、あっという間に1.5Kbytesは超えてしまう。これではWAPサービス自体の魅力を低下させる原因になってしまう。

　この弱点を改善するため、WAP 2.0では、WAP 1.xのUDP/IPを捨て、TCP/IPを利用できるようにした。しかし、TCP/IPをそのまま使うと再送地獄にはまってしまうため、通常のTCP/IPネットワーク機器とは異なる、特別なTCPパラメータ設定を与えて、無線に強いTCP/IPを規定した。これが「Wirelss Profiled TCP（w-TCP）」である。

　つまり、w-TCPは普通のTCPと同じで、基本的には相互接続可能である。もともと、TCPにはいくつかの設定パラメータが存在する。この値を無線通信（WAP）用にチューニングしたのがw-TCPである。「新たに作成したプロトコル」ではなくて「TCPに無線に適したデフォルト値を与えて作ったもの」と思えばよい。w-TCPは、次の問題（通信障害となる原因）を回避するように策定されている。

• パケットロス（データの消失）
• 大きいデータ遅延
• 帯域の変動と遅延の変動

　これらを回避するために、次のようなことを行う（表1）。

1. 「split-TCPとして利用可能であること」[RFC2757]
   　これは、ゲートウェイを介したTCPの運用ができることを前提としている。ブリッジのようなデータの垂れ流しではなく、確実にTCPレベルで網を分ける。これで、ゲートウェイと携帯電話の間は無線の状況で再送を多発しても、ゲートウェイとコンテンツサーバの間で再送が起こることはない（図5）。つまり信頼性が異なる網を分けることで、悪い信頼性の網に、良い信頼性の網が引きずられることがないようにしている。
   
   

   図5 split-TCPの仕組み

   
   
2. 「windowスケールオプションの有効化」[RFC1323]
   　windowとは、データ転送を独立して非同期に処理できる数や大きさと思ってもらえばよい。このwindowの大きさが大きい場合には（64Kbytes以上）、このスケールオプションを有効にすることが必須として決められている。もともとwindowサイズを記述する領域が16bits分しかないため、64Kbytesを超えるwindowデータを扱えない。これ以上のwindowサイズを扱う場合は、このオプションを用いて16bits以上（つまり64Kbytes以上）の表記ができるようにしてから扱う。このような事情のため、windowサイズが小さい場合は推奨はされているものの、実際にこのオプションが使われることはない。従って、スケールオプションとwindowサイズはトレードオフの関係にある。
   
   
3. 「輻輳制御の最適化」[RFC2414]
   　輻輳制御（フローコントロール）を行うため、スロースタートアルゴリズムを用いるならば、cwnd（congestion window）を初期値2以上として動作させる（つまり初回のデータは分割して送出する）。もしも2以下ならば「Large Initial window」が必須となる。初期window数は、輻輳に対しての敏感さを決める値となる。
   
   
4. 「SACKの対応」[RFC2018]
   　window中で複数のセグメントが失われたときに、Selective Acknowledgement Option（SACK）の効果がある。

以上1〜4の項目は必須事項であるが、以下に挙げる事項も推奨されている。

5. 「BDPに基づいたLarger windowサイズ制御」
   　Bandwidth Delay Product（BDP）に基づいて、windowサイズを決定する機構を推奨している。windowサイズが大きくなれば、一時的なパケットの乱れをwindowの仕組みで一時的に吸収し、次のデータ通信処理を、先へ先へと行うことができる。
   
   
6. 「RTTMのタイムスタンプオプション」[RFC1323]
   　RTTM（Round Trip Time Measurement）再送までの、タイムアウト時間を調整する機構。windowサイズが64Kbytes以上の場合は有効にすべきとしている。64Kbytes以下の場合は推奨である。
   
   
7. 「MTUサイズの経路上サイズ検出機構のサポート」[RFC1191]
   　MTUは、データを送受する単位の大きさのこと。途中に複数の機器を経由してデータを送受信する場合、途中の機器で設定されているMTUの最小サイズを検出し、そのサイズでデータ送信を行う。この検出機能（Path MTU Discovery）が備わっていることが望ましいとされている。もしも大きいサイズで出すと、途中の機器でデータが分割されて送信され、転送効率の低下が起きる。最近の話題だと、ADSLのプロバイダの機器のMTUサイズが微妙にモデムと異なり、スループットが出ないケースなどがあった。もしもサポートされていなければ、初期IPのMTUよりもサイズを大きくすることが推奨されている。
   
   
8. 「ECNのサポート」[RFC2481]
   　ECN（Explicit Congestion Notification）がサポートされていることが望ましい。ECNエコーフラグを立てて輻輳状態を知り、送信側に輻輳windowを減らすことができる。

　WAP 1.xまでは、下位レイヤとしてUDPを主に使っていた。ところが、WAP 2.0では、下位層がTCP/IPとなったため、その上位プロトコルとしてHTTPが利用できるようになった。

　しかし、無線ならではの仕様があったり、オーバースペックの部分は推奨項目としたり、無線に使いやすい「HTTP案」を規定した。これが「Wireless Profiled HTTP（w-HTTP）」である。

　w-TCPと同様に、新しく作ったプロトコルではなくて、HTTPを基に、無線ならではの仕様をw-HTTPとして、規定し直したと思ってもらえばよいだろう（表2）。

　 w-HTTPの規定は大きく「サーバ側」と「クライアント側」の2つに分かれる。最小限の必須事項は、当たり前のようだが、

• 「サーバProxy側」HTTPサーバの実装
• 「クライアント側」HTTPクライアントの実装

となっている。そして、Connectメソッドを用いたトンネル接続サポートや、応答メッセージの圧縮サポートも求められている。

　オプション扱いであるが、なんとクライアント側（つまり携帯電話側）にもHTTPサーバの実装が求められている。同時に、サーバProxy側にも、HTTPクライアントの実装が求められている（こちらも必須ではないが）。

　これらは、WAPにあるプッシュアーキテクチャを実現させるための仕組みとして推奨されている。WAPでプッシュを実現するには、

• WSPを用いたプッシュ
• w-TCP上のw-HTTPで実現するプッシュ

の2つがある。WSPを用いたものは、プロトコル的に実装されているものだ。w-HTTPを用いる方式は、サーバProxyから、携帯電話に向けてHTTPリクエストを発行し、処理させることでプッシュシステムを実現できるようにしている（逆サーバ）。この後者を実現する場合に、オプション扱いで、携帯電話にHTTPサーバの実装を行うことになっている。

　今回は、プロトコルの下位レイヤの話を中心にWAPの仕組みを紹介した。プロトコル部分の工夫は、通常のコンテンツ開発を行っている人からは、なかなか見ることができない部分である。そういう意味ではなかなか話題にならないところだ。しかし、WAPの技術はここに詰まっているといってもよいだろう。

　次回以降では、今回のプロトコルの話をベースとして、セキュリティ、プッシュ、UAプロファイルについて解説しようと思う。

「連載 ネットワークから見たWAP 2.0」