携帯電話のデータダウンロードサービスの違いと
通信プロトコル

嶋　是一
2001/5/29

　Webサイトの中でも、携帯電話対応のWebサイトは花形である。そして、その中でも特に輝いているのがメディアデータサイトである。携帯電話の着信メロディや、待ち受け画面の壁紙に利用する画像データに大変な人気があり、アクセスも集中する。エンターテインメントコンテンツでは、これらを客引きと割り切って利用することも多いほどだ。サイトにアクセスが集中し、サーバ管理に苦労しているという話もよく聞く。

　ところが、この人気のダウンロードのデータサイトを作ろうとすると、途端につまずいてしまう。というのは、NTT DoCoMoのiモードと、KDDIのEZwebで違うからなのだ。何が違うかというと、画像の形式に始まり、実際のダウンロードの方式までもが違っている。なぜ、そんなに違うのだろうか？　これは通信プロトコル（TCP/IP）に根っこがある。本稿を読めば、これらが氷解するだろう。

　さて、携帯電話でページを見るデータ通信には「パケット方式」が用いられていることは有名だ。そして、このパケットの量で料金が決まることは、皆さんも知っていることだろう。しかし、このパケットを送り届ける仕組み（プロトコル）はどうなっているのだろう？　知っている人は少ないのではないだろうか。ここに、携帯電話ならではのちょっと面白い事情がある。

　実は、この送り届ける仕組みは携帯電話会社（キャリア）ごとに違うのだ。送り届ける仕組みの代表的なものとしては、TCP/IPとUDP/IPの2つがある。そして、iモードではTCP/IPを使っていて、EZwebではUDP/IPを使っているのである。普通のインターネットではどこでも同じTCP/IPを使っているが、携帯電話ではキャリアごとに異なる。では、どうして異なるのだろうか？　ここに、ダウンロードの仕組みの違いと、そして2つのプロトコルにある本質的な違いを、垣間見ることができるのだ。

　通信プロトコルとは、コンピュータ同士でデータをやりとりするための言葉と取り決めである。例えば、Webページを見るときにプラウザに「http://」と入力するが、この「http」がプロトコルである。HTTPはHyperText Transfer Protocolの略で、Webページを見るときに使っている。またメールを送信するときにはSMTP（Simple Mail Transfer Protocol）というプロトコルを使っている。このようにインターネットのサービスを利用するときには、必ず何かのプロトコルを使っている。

　すべての取り決めを、1つの決まりにまとめようとすると収集がつかなくなるため、段階的に決まり事を作っている。図1のように決まっていて、その具体例が右側に書いてある。この図より、HTTPを使うときには、下側に積まれているTCP/IPが使われていることが分かるだろう。そして、EZwebを見るためのプロトコル（HDTP（Handheld Device Transport Protocol））を使うときにはUDP/IPが使われていることも分かる。

図1　プロトコルのレイヤー図

　iモードで採用されているTCP/IPは、片方のコンピュータからもう片方のコンピュータ（この場合は携帯電話）に、大きなファイルを送り届ける（ことができる）仕組みだと思ってほしい。大きなファイルもネットワーク上ではパケットという単位に分割されて送られている。通常、このパケットというのは、流れている間になくなってしまったり、順番が入れ替わったりしてしまうことがある。そのため、TCPでは、この分割したパケットに次のようなことをしている。

• 届いたデータが正しいかどうかを確かめる
• 届かないパケットを、もう一度送るように（再送）要求する（図2）
• 正しい順番にパケットを並べ替える（図3）
• パケットを連結してファイル（などのデータの固まり）に戻す

図2　TCP/IPのデータ再送

図3　TCP/IPのパケット並べ替え

　このおかげで、TCP/IPの上にあるアプリケーション（HTTPやFTPなど）が「データをくれ」といえば、どんなに大きいファイルでも、パケットを連結して取得できる。従って、iモードでは、リンクをクリックするだけでダウンロードを行うことができる。つまり、PCで行うWebとまったく同じ方式である。

　それでは、EZwebで採用されているUDP/IPではどうだろうか？　これは、TCP/IPと比べると何もしてくれない方式だ。「届いたデータが正しいものかどうかを確かめる」ことはするが、送ったら送りっぱなしで、データが消えても知らんぷりだ。また、パケットの連結もしてくれない（図4）。これだけを聞くと「役立たずのプロトコルだな」と思うだろう。しかし、ここに携帯電話ならではの事情があるのだ。

図4　UDPにおけるデータの流れ

　携帯電話はPCに比べて、スペックが貧弱である。画面が小さい、CPUは遅い、メモリは少ない。そして何よりも転送速度が遅い。PCで使っている仕組みを、そのまま携帯電話で利用していたのでは、まともに動かないか効率が悪い。そこで「WAP FORUM」という団体が、無線アクセスに効率的な方式「WAP（Wireless Application Protocol）」を決めている。

　ここでは、無線区間のデータ転送はWDP（Wireless Datagram Protocol）という規格を用いることになっている（図5）。このWDPの規格の中で、特にインターネット網を利用する場合はUDP/IPを使うことと規定されている。その理由は、UDP/IPが軽い（シンプルで負荷がない）点にある。つまり、何もしないUDP/IPは、何でもしてくれるTCP/IPに比べて、通信回数（シーケンス回数）が半分以下で済んでしまう（図6）。つまり、TCP/IPを使わずにUDP/IPで済むならば、ユーザーのパケット料の負担も減るし、何よりも電話会社の見かけの回線収容数が多く取れるため、コスト削減ができるのだ。特に、携帯電話の無線区間（電話機から基地局までの間）の通信コストは比べものにならないくらい高価なものだ（設備が高いから）。もしも、パケット量が2/3になるのならば、基地局の収容数を2/3にすることだってできるわけだ（単純にそうではないが）。収容数で設備投資する電話会社からすると、無駄を省いた通信がしたい。しかも、TCP/IPはデータがエラーになると再送要求を行う。ネットワークは混雑し始めると、途端にエラーが増える。その中でTCPなどが再送要求を始めると、対数的にエラーが跳ね上がり、高価な無線区間がパンクしてしまう。その点UDP/IPは安心して効率的に使うことができるのだ。

図5　WAPのプロトコルスタック

図6　パケットシーケンス

　IPパケットのデフォルトのサイズは1500バイトである。EZwebで、画像のサイズの上限が1500bytesだったのはこの理由による（現在は、サイズの上限は8000bytesに変わっている）。一方iモードでは、1500バイトを幾つでも連結してくれるので1500bytesを超えることができ、公称20000bytes、実際にはかなり大きなデータまで取得できるようになっている。

　UDP/IPが無線に適しているのは分かった。しかし、だからといって、散り散りになったパケットのままでよいか？ というとそうではない。iモードならば、パケットは連結して、どこまででも大きなデータを携帯電話に送り込むことができる。しかし、EZwebだと連結できないため「パケット1発分の大きさ」である8000bytesしか送り込めない。これでは、カラーの画像や、カラオケ、音声ファイルなどは転送できない。軽く8000bytesを超えてしまうからだ。

■download.cgi

　そこで、考え出されたのがdownload.cgiという仕組みである（図7）。これは、UDP/IPで連結してくれないのならば、その上にあるアプリケーション（プログラム／CGI）で連結してしまうというものである。かなり強引な発想だが、背に腹は変えられない。流れとしては、以下のようになる。

• サーバにdownload.cgiというプログラムを置き、データを8000bytesに分割して携帯電話に送り込む
• 携帯電話機の中にdownload.cgiに対応するプログラムを入れておき、download.cgiから送られてくるファイルを、電話機内で連結する（ただし、このプログラムは端末メーカにより電話機に実裝されている）

図7　download.cgiのネットワークレイヤー

　このdownload.cgiは、Openwave Sytems社が提供しているUP.SDKにサンプルスクリプトとして含まれており、実際に使用する際には改良を加えるといいだろう。従って、EZwebでダウンロードサイトを構築するときにはダウンロード専用のCGIを設置する必要があるので、iモードでファイルをサーバに置くのに比べると面倒である。

　また、この仕組みを利用したダウンロードサービスとして「EZget」が公式コンテンツとして提供されている。

　こうして、EZwebでも、無事に8000bytes以上のファイルのダウンロードができるようになった。ただし、ブラウザの画面上に表示する画像などはdownload.cgiの恩恵にあずかれないので、やはり8000bytesの限界がある。従って、au携帯電話のブラウザメニューからの「画像の保存」は8000bytesまでしかできない。

■MIMEタイプ

　Webの仕組みに、Content-Typeというものがある。これは、転送するデータの種類を決めるものである。種類は「MIMEタイプ」と呼び、HTMLならば「text/html」、gif画像ならば「image/gif」などと指定する。

　これは、サーバから送り出すときに指定し、ブラウザに転送する。ブラウザは、そのタイプにあったアプリケーションを起動して表示しようとする。もしも、MS-WordのMIMEタイプが送られてきた場合は、ブラウザはMS-Wordを（もしもインストールされているならば）起動して表示する。Microsoft Windows系では、ファイルの拡張子で起動するアプリケーションを決めるが、インターネットではこのMIMEタイプで決定される。

　iモードもEZwebも、ブラウザ上にデータを表示するときには、このContent-Typeを見てデータを判別している。音楽ならば「application/x-smaf」、HDMLならば「text/x-hdml;charset=Shift_JIS」などといった具合である。

　ところが、EZwebでdownload.cgiを使ったときには、ダウンロードをするプログラムを動かすためにこのMIMEタイプを利用している。そのため、実際にダウンロードする（画像やカラオケデータなどの）データの種類を指定できない。そのため、EZwebのダウンロードでは、MIMEタイプの代用として、ダウンロードを起動するときのリンクにDATATYPE（データタイプ）を入れるようにしている。これがダウンロード時のファイルの種類を示し、EZwebでのMIMEタイプとしての役割を果たす。例えば、PNG画像だと「DATATYPE=DEV8WLW」などの文字列を指定する。このデータタイプとダウンロードサイト構築については、「EZwebで自作画像をダウンロード」のページに詳細が紹介されている。

　さて、ここまで解説してきて、勘のいい人は気が付いて疑問に思ったかもしれないポイントがある。

　それは、iモードもEZwebも、インターネット上にあるWebサーバで提供しているということだ。つまり、TCP/IP上のHTTPで動いているということ。どう見ても、EZwebのUDP/IPを使っているように見えない。いや、本当にUDP/IPを使っているのならば、EZwebのコンテンツ配信には専用サーバプログラムが必要になってしまう。もちろん、実際にはそんなことはなく、普通のWebサーバで提供可能だ。

　携帯電話のシステムは、大きくコンテンツ網と事業者網の2つに分離される（図8）。そして、この網の間にはゲートウェイサーバというサーバが必ず用意され、ここでプロトコルが変換される。

図8　コンテンツ網と事業者網

　コンテンツ網とは、まさにインターネットのことを指し示す。コンテンツは、ここに配置されたWebサイト（HTTP、TCP/IP）で配信される。これは一般のWebサイトとまったく同じシステムだ。

　一方、ゲートウェイで隔てられた事業者網といわれるのが、電話会社内部のネットワークである。こちらは、電話会社内部のネットワークと、電波局（基地局）から携帯電話までの無線区間を含んだネットワークだ。この区間はインターネットから見られることなく、携帯電話に対してデータをどれだけ適切に送り届けるかを最重要に設計される。そのため、インターネット規格を用いる必要はなく、携帯電話会社ごとに独自のフォーマットで実装されている。つまり、この部分がEZwebではUDP/IPとなっているのだ。

　ここで大切なことは、コンテンツ網は「インターネットと同じ」という点。そして事業者網は「データ効率優先」という点だ。コンテンツを広げるには、独自仕様ではそれが難しい。しかもサーバを立てる必要があるため、それなりのコストがかかってしまう。それ故「同じである」というオープン性が大切になっている。

　一方、事業者網は、電話会社からすると、決まった回線数でどれだけの通信ができるかによって、設備投資がそのまま決まる。つまり、通信量が小さくできるネットワークならば、それなりの利益が出てくる。そのため、オープンであるよりも、効率がよい方を追求する。

　この結果、事業者ごとにコンテンツ網の通信はWebのTCP/IPを利用できるようにして、事業者網のプロトコルは独自に採用（UDP/IP、TCP/IP）し、その間の変換はゲートウェイが受け持っている。特にEZwebのようなWAPシステムの場合は、WAPゲートウェイと呼ばれる。

　iモードの場合は、双方ともほぼTCP/IPを用いているため、Proxyサーバのような働きをしているだけである。

　時代は変わる。特に携帯電話の動きは、PCの世界以上に速い。電話機は、1年に数十機種が発売され、大きなラインアップ変更も1年程度で行われている状況だ。そのたびにサーバのスペックやサービスの内容が変わっていく。本当についていくのだけでも大変である。

　そういった流れの中で、今年後半から来年にかけて大きな移り変わりがありそうだ。WAP 2.0という規格である（編注：5月末時点ではWAP 2.0は正式に発表されていない）。特にEZwebでは秋口にかけて、この対応のサービスが予定されているようだ。本稿で説明した「WAPはUDP/IP」と言う説明も、WAP2.0になると「Wireless TCP/IP」となり、事実上プロトコルがTCP/IPとなってしまうので、ダウンロードの仕組みなども変わってくると思われる。もちろん、コンテンツ提供者からすると楽な方へ移行するわけだ。

　またWAP 2.0の一番のウリは、記述言語がHTML 4.0の事実上の後継であるXHTMLのサブセットであるXHTML basicとなる点である。これによりiモードサイトも見えるようになる。今後iモードもXMLになれば、お互いXMLの仕組みの上で、トランスレートをかけ（XSLT）、共通コンテンツとして公開できるようになるだろう。まさに、iモードとEZwebの融合はプロトコルレベルから、言語レベルまで広がってきているといえる。