Air H"カルト考察編

このページではDDIポケットのパケット接続サービス Air H" について、結構深く掘り下げつつ憶測を述べてみます。
1.Air H"カルトその1

実際問題AirH”の通信方式はわからないことだらけ。わかっているのは、「エアのインターフェースは制御チャネルを使用」「PIAFSベースのパケット」ということぐらい。たとえば、通常のPIAFSは4タイムスロットで1フレーム、ではAirH”のパケットはPIAFSの1フレーム単位なのか?それとも1スロット単位なのか?これがわからない。制御チャネルにPIAFSの1フレームを丸ごと流しちゃうのはまずい気がするし、とはいえ、PIAFS1.0と同等の速度が出ていることを考えるとスロット単位ではないような気もするし。答えはおそらく前者だと思うのですが、ではどこにDistinationを埋め込んであるのか?TCHフレームにはそんな物を入れる余裕はないし、とはいえ、他のチャネルを使えばPIAFS相当の速度は出ないし。唯一、UPCH(USCCH)が、よく仕様がわからないので、ひょっとしたらこれを使っているのかなあという感じもします。また、制御用スロットだけでなく、通信用スロットにもパケットを流して帯域をある程度確保する方法がある、という噂も。これに関してはまったくのなぞ。そして、もう一つわからないのが、有線(ISDN)回線の利用法。ISDNは64kbpsのBチャネルと16kbpsのDチャネルからなります。これを、通常の基地局は2回線引き込んでいます。で、そのDチャネル、パケット通信モードが用意されていて、その使用料も(聞いた話では)定額となる契約があるようです。これが、16x2で32kbps、AirH”を収容するにはぴったりの帯域。だから、このチャネルをパケット通信用に使っている・・・と思っていたのですが、いろいろなところからいろいろな噂は出るもので、Bチャネルをパケット通信用に定額契約している、という噂も流れています。
ということで、細かい話を抜きにして簡単にまとめると考えられるパターンはおおよそ4つ。

1、無線区間は制御スロットのみ、有線区間はDチャネルのみ。
制御スロットに流れる情報とDチャネルに流れる情報の量は(ほぼ)同程度なので、どちらかがボトルネックになる、というような相互の衝突がなく、もっともリーズナブルな方法。おそらくこれが本命。ただし、将来の拡張性は著しく低くなります。128kbpsパケットが、4基地局合成というところからも、この方法が使われている可能性が非常に高いです。

2、無線区間は制御・通信スロット併用、有線区間はDチャネルのみ
制御用スロットの帯域を確保して、制御情報のやり取りを阻害しないため&PS−CS間の制御情報のためにパケット通信速度が落ちてしまわないためには、この方法が考えられます。ただし、上位が32kbpsなので、それに制限され、将来の拡張性も0。通信用スロットを使うことによりビジー発生率もあがるので、あまりよろしくないかも。

3、無線区間は制御スロットのみ、有線区間はB、Dチャネル併用
こっちは逆に、有線区間の負荷を分散させる目的があります。元々Bチャネルは一本余っているので、それを使えば有線区間での輻輳は事実上0に出来ます(無線区間が32kbpsに制限されるので)。同じ基地局設備内に制御スロット通信機能のみを持つ簡易基地局を設置することで最大3台のAirH”を収容できるようになります(つまり、基地局としては3基、128kパケット通信では、一つの基地局設備(柱)だけで最大96kbpsまで対応可能)。1基地局32kbpsまで、それ以上は2基地局以上を束ねる、という言葉とも矛盾はしません。私の感覚ではこの方法が対抗か、という感じです。ただし、得られる帯域に対する維持費が最も高くなるのが難点。お金のないDポにこれが出来るか・・・!?(笑)

4、無線区間は制御・通信用スロット併用、有線区間はB、Dチャネル併用
もっとも拡張性のあるタイプ。一基地局だけで最大96kbps(Bチャネルを追加すれば128kbps)まで対応可能です。ただし問題があって、この方法で128kbpsパケット通信を行うと、その基地局のカバーエリアが事実上「圏外」になってしまいます(発着信とも不可)。これはさすがにまずいので、この方法は取っていないかと思います。予想印(笑)で言えば大穴といったところ。お金がかかる割に御利益があまりないですね。
とまあ、こんなところなんですが。

後日注!:ISDNのDチャネルを使ったパケット通信モードは9600kbps限定でした!と言うわけで、選択肢としては3、4しかないようです。ただし、もしかすると、いや、ほんとーにもしかすると、なんですが、上りだけDチャネルを使っている可能性もあります。それは、Dチャネル9600bpsx2=19kbpsで、上りの制限速度17kbpsと結構近いからです。もちろん、現実にはこれはウソ(笑)で、上りもBチャネルでしょう、せっかくBチャネルをごっそり定額契約しているんですから。

2.Air H"の秘密その2
さて、これで大体パケットがどうやって流れていくのかがある程度予想できたので、次は無線リソースの管理方法について。以前、ちょっとした記事で読んだところでは、「一基地局に接続できるAirH”端末の最大数は4台が目安、もちろんそれ以上増やすことも出来るが、出来るだけ空いている基地局へ誘導する」という趣旨のことをDDIポケットの偉い人が言っているのを見ました。さて、そんな制御が本当に可能なのでしょうか?というのも、従来のPHSのハンドオフ手順にはそういうモードは(たしか)なかったはず(のような気がする)。とすると、ちょっとややこしいですが、次のような手順ぐらいしか思い付けません。

1、端末は基地局にパケット接続要求
2a、混んでいる基地局は「今混んでいるので」という信号を返す(これはパケット用に拡張されたシグナリング?)
3a、端末は他の基地局をサーチして再度試行(1へ)
2b、空いていればその基地局と通信開始

2c、一度接続を拒否した基地局のところへ一定時間内に2度目の接続要求がきたら仕方がないので繋いであげる

こんな感じ。しかし、そのためには端末は接続要求を出した基地局の履歴を保存しておく必要があり、無駄な複雑さを生んでしまいます。一方、次のような方法もありますが・・・

1、端末が接続要求
2a、混雑中の基地局は、ネットワークに周辺で空いている基地局の情報を問い合わせ
3aa、空いている基地局があれば、その情報を「混んでるから」信号とともに返す
4aa、端末は教えてもらった基地局へトライ(1へ)
3ab、空いている基地局が周囲になければ、仕方がないので繋いであげる
2b、空いていれば接続して通信開始

この方法は、たしかに確実に空いている基地局をGETできますが、一方、もし教えてもらった基地局が電波の届かないところにあった場合、そこで接続手順が頓挫してしまいます。端末のある場所によっては、いくらリダイヤルしても繋がらない、という場合だってあるわけです。ですからこの手順も怪しいもの。もう一つ、この二つの手順を組み合わせた方法も考えられます。

1、端末が接続要求
2a、混んでいたら、「混んでるよ」信号を返す
3a、端末は到達可能な周辺の基地局IDを調べて基地局に返す
4a、基地局はもらったIDを使ってネットワークに問い合わせ
5aa、端末からもらったIDの中から空いている基地局を教えてもらい端末に返す
6aa、端末は教えてもらった基地局に接続、通信開始
5ab、もらったIDの中に空いている基地局がなければ仕方がないので接続
2b、空いていたら、接続、通信開始
このやり方が一番スマート(手順が基本的にストレートフォワード)ですが、一方、端末が接続するときにいちいち周辺の基地局情報を取得する必要があるため非常に時間がかかります。接続するときにそんなに時間がかかっているようには見えないので、この方法もやや怪しめ。
ということで、実際のところなぞだらけなAirH”接続手順。本当にそんな賢い制御をしてるの・・・?>Dポの偉い人。
3.Air H"カルトその3
AirH”の安定性を強力にサポートしているのが、「潜行モード」。いえ、こんな言葉があるわけじゃなく、私が勝手に命名してあちこちで使っているだけなんです。これは何のことかというと、サービスエリアの外に出てしまっても、仮想的に回線を繋ぎっぱなしにして、接続中のセッション(ダウンロードなど)が途切れてしまわないようにする機能です。たとえばPCで利用しているとき、普通の携帯・PHSは、圏外になると回線が切断され、PCも接続中のセッションを破棄します。こうなると、繋ぎ直してまた一から、と、大変面倒です。一方のAirH”、圏外になっても、PCから見れば回線は繋がっているように見えます(単にデータが流れないだけ)。ですから、PCとしては、「次のデータはまだかなあー。」とひたすら待っているだけ、つまり、圏内に復帰し次第止まったところから再開できるわけです。これは便利。
さて、この潜行モードがどのように実現されているのか。よーく考えてみると、何やら、怪しい雰囲気を感じてきます。まず、通常の回線交換で、切断されるメカニズムを考えてみます。電波が届かなくなると、まず気づくのは基地局です。なぜなら、基地局に比べて端末のほうがはるかに低い電力で送信しているので。となると、基地局としては、こりゃあ切るしかないなあ、と判断し、端末に向けて切るよ信号を出します。これで切断完了。この方法が一番スマートですが、一方、基地局からの切るよ信号が届かない場合も考えられます。そんな時は端末が一定時間基地局を捕まえられなかったので、ということで、切断(もちろん基地局にもその信号は通らない)、という手順になるでしょう。
では、AirH”潜行モードは?基本的に同じと考えていいのですが、こちらには、1、潜行モードタイマーの始動、2、再接続、という二つの厄介な問題を抱えています。まず、端末からの信号が通らなくなった片側通信状態。これは、実は怪しげで、回線交換なら常に信号が届いていますが、パケットでは信号が上っていかない時間帯がたくさんあります。こういう時間帯は、どうやって信号が通るかどうかを判断しているのでしょうか?一つの手としては、もしまったく流れるデータがなくても一定時間毎に端末から基地局へ、または逆方向に信号(以降パイロット信号)を送りあうことです。もしこの信号が一定時間以上途絶えてしまったら、基地局は「通らなくなったから潜行モードになりなさーい」といえば、同期して潜行モードに入れます。問題は、どちらの信号も通らなくなったとき。高速移動中では、これが結構ある可能性があります。片側通信が維持できるエリアをあっという間に通り過ぎてしまうため、基地局が端末からの信号が通らなくなったことを一定時間待ってから確認した上で潜行モード指示信号を出しても手後れの場合があります。このとき、端末がどのように判断するかもポイント。たとえば、自分が出したパイロット信号に対する返答が一定期間途絶えたら、自発的に潜行モードに入る、という制御が考えられます。もちろんこの時、パイロット信号が数回連続で通らなかったら、という条件付きです。一回だけ、たまたま通らなかっただけで圏外と判定してしまうのは、後々の復帰プロセスを考えると不経済ですし。また、ここまでの推測は、基地局と端末がまったく役割が逆になった場合も考えられます。つまり、基地局がパイロット信号のソースとなるような場合。元々基地局は一定周期(数秒?)で報知情報をセル内に送信しています。これを使えるかもしれませんが、それに対して端末が応答を返すという手順を新たに組み入れたと考えると、システムに影響を与えずにこのようなことを行うのはかなりの難業だったはず。ほんとにできるかな?
さて、このようにパイロット信号の応答既着・未着で判断していると、必ずタイムラグが生じます。これはどの程度か、というと、ちょっとわからないのですが、最大でパイロット信号1周期分になると考えていいでしょう。パイロット信号はどの程度の周期で送出されているのか、これについては微妙なところですが、通信速度への影響を最小限にするためには1秒から数秒は必要なのではないかと思います。つまり、潜行モードタイマーの開始にはこの程度のタイムラグが生じ、潜行モードのまま切断に至った場合はこの秒数分損(得)をしている可能性があるわけです。たかが数秒、されど数秒。馬鹿には出来ません(ほんとか?)。実際はもろもろの理由で、もう少しタイムラグはあるでしょう。
潜行モードもう一つのポイントは、網への復帰。これは、実は考えてみれば意外と簡単な話で、回線自体は(仮想的に)繋がったままですので、端末が新しい基地局を見つけた時点でハンドオーバと同じ手順を開始すればいいだけ、つまり、ほとんど端末主導で話を進められるというわけです。もちろんそこには問題があります。たとえば、ハンドオーバ前の基地局とは絶対に交信できない、ということ。しかし、これも、従来のハンドオーバでも起こりうるシチュエーションであることを考えれば、さほど手順を複雑化する必要はなさそうです。と言うことで、潜行モードからの復帰は一件落着。ふう、よかった。
4.Air H"カルトその4
最大128kの速度が出るという、話題の128kパケット方式。基本は、32kパケットを4つ束ねて実現するとのこと。ですが、これは単純そうに見えて意外といろんななぞを含んでいます。
まず、一番大きな謎、それは、4本の32kチャネルの間のマネージメントです。話を単純にするために、ここに4パケット分、送信すべきデータがあるとしましょう。これはまずはパケット網のバッファに溜まります。その後、パケット網はどのパケットをどの基地局から送信するか決定しなければなりません。この場合、1基地局に1パケットずつ割り当てれば最大効率が得られることになります。では、5パケットあったら?余った一つは、どう割り振られるのか、興味あるところ。たとえば、一番簡単なのは、処理上一番最初に現れる基地局(CSIDが若い、など)に振ってしまうというもの。しかし、これにしても不都合な点が出てきます。基地局としても、突然の電波状況の悪化などで通信速度が低下したときのためにバッファを用意しているはず。で、たとえば網から4基地局に10パケットずつ送信し、基地局がそれを処理することになったとしましょう。そのとき、実際にある基地局からの通信速度が落ちてしまったとします。基地局それぞれの残りパケット数は8、5、5、5となったとします。ここで、新しいパケットを6パケット送ることにしましょう。すると、残りは10、7、6、6。なぜかと言うと処理上若い方(この場合早く出てきた順)に割り当てるからです。このまま処理が続いて、残りが5、2、1、1となったとき。そうです、最後の二つの基地局バッファの1パケットは紛れもなくあとから送った方のデータを構成するパケット。なのに、最初の基地局には1回目40パケットに含まれていたパケットがまだ残っています。ですから、そこが終わるまでは次に進めません。つまり、もっとも通信速度が遅い基地局に足を引っ張られる可能性があるということです。これではいけません。と言うことで、実際は残りバッファ数の少ない順に都度割り振っていると考えるのが普通でしょう。
ところで、それじゃあ、ある基地局との接続が(エリアを出るなどして)切れてしまったらどうしましょう?その時は、まずは基地局に残っているバッファをすべて他の基地局に送り込まなければなりません。ハンドオーバなら、ハンドオーバ先にすべて転送(つまり従来の32kパケットと同じ処理)すればいいだけ。しかし、ハンドオーバに失敗したときは、やっぱり他の基地局に割り付け直す必要が生じてきます。そうなると、網上の処理としては一度パケットを引き上げて、それから改めて残りの基地局に送信し直すわけですから、タイムラグも生じ、いなくなった基地局バッファに溜まっていたパケットに関わるデータの到着は特に遅れることになりそうです(最後に送信するべく要求されたパケットが転送先基地局に残っているため)。もちろんこの辺はいろいろと最適な制御を考えてあると思いますし、なにより、もし制御方式を変えるとなっても、ネットワークと基地局だけ変えればいいのでユーザには影響がないと言うのが利点。基地局のアップデートもオンラインで可能なので、使っているうちに不思議と転送効率がよくなっていく・・・なんてことも!?

続く・・・!?

Air H"インデックスへ戻る