goo blog サービス終了のお知らせ 

ウィリアムのいたずらの、まちあるき、たべあるき

ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです(たま~にコンピューター関係も)

クラウドとユビキタスの関係をそろそろまとめたほうが、よくね?

2009-05-15 14:20:26 | Weblog

ここのスラッシュドットニュース
政府の“国民電子私書箱”構想、ライフログのマーケティング目的利用を検討
http://slashdot.jp/yro/article.pl?sid=09/05/13/1523258


電子私書箱は、クラウドっぽい動きをするのに、
どーしてユビキタスのライフログ情報まで、クラウド上にアップさせちゃうの?
データがバブリーになっちゃうじゃん!!

(以下斜体は上記サイトより引用)

「このままでは,ライフログ・プラットフォームまで米国に制覇されてしまう」と危惧

そーやって、金融業でアメリカと似たようなことしたから、
アメリカのサブプライムで、日本もおかしくなっちゃったんじゃん。
どーして、アメリカのIT版サブプライムであるデータバブルに日本が付き合わないといけないんだよ・・・

やっぱ、こーいう発想がでてくるのは、クラウドとユビキタスをまとめてないからで、
そろそろ、偉い学者さんがまとめたほうがよくね?

ま、とりあえず、ウィリアムのいたずらがまとめとく。




■あちら側が何でもいいのがクラウド
 こちら側が何でもいいのがユビキタス

 クラウドとユビキタスの関係についての説明で秀逸だったのが、
 OracleOpenWorldExpoのNSSOLのセミナー(4月23日)
 「クラウド・コンピューティングがもたらす新たなパラダイム」
 だったので、そこからちょっと話をかりてくると、

 クラウドを論ずるとき、あちら側とこちら側という表現を使う。

 こちら側は、サービスを利用するユーザー側
 あちら側とは、サービスを提供する、サーバー、プロバイダ側。

 このとき、

 こちら側(ユーザー)からみて、
 あちら側(サーバー)は、なんでもいい、知らなくても扱える

 ようにするのが、クラウドコンピューティング。

 一方、
 あちら側(サーバー)からみて
 こちら側(ユーザー)は、いつでも、どこでも、だれでも、どんな機種でもいい
 っていうのが、ユビキタス。

つまり、こんなかんじ
ユーザー       サーバー
こちら側  ⇔    あちら側

ユビキタス      クラウドコンピューティング






■技術的には、データやプロセスは、どこでもいいことになる
 でも、経済性とかを考えると、適所適材がきまる。

 ここで、あちら側とこちら側がドーデもよくなれば、問題は、そこをつなぐ通信になる。
 もしこれも、同じくらいの速さになれば、もう、データにしろ、処理にしろ、どこにおいても、技術的にはよくなる。

 サービスはネット上にあればいいし、データもネット上でも、手元にあってもいい。

 そうなってくると、問題は、経済性や信頼性になる。

 サーバー上にあると、結局、サーバー会社がデータを管理し、その管理費用を、利用者が負担することになる。
 このとき、究極の形は、データ利用は、2:8の法則になるだろう。
 2割のヘビーユーザーのために、8割のあまり使わないユーザーが費用をはらう。
 そこで、サーバ上のディスクは、平均すると値段が高くなる。

 一方、個人が利用するデータであれば、ハードディスクよりもっと割安な大容量メディアにとっておくことが可能になる。
 (まー、やる気になれば、サーバー側でもできなくないが、アクセス頻度などを考えると、ハードディスクが現実的か?)
 
 そうすると、経済的に考えると、あまり利用しない個人データはDVD,ブルーレイなど大容量メディアに
 頻度が高く共有したいデータはクラウド。
 それ以外のものは、頻度とか信用度に応じて、適所適材・・・

 という感じで、信頼性、経済性に応じて、データ保存メディア、場所が選ばれる。
 すべて、雲の上がいいわけではない。




■データをどこにおくか?はデータの経済性に関係する

 そして、データをどこにおくか?はデータの経済性に関係する。

 ここでいうデータの経済性とは、そのデータが生み出す価値と、データを保存する価値を比較したとき、生み出す価値がどれくらい大きいかという話だ。大きくなければ、それは、データというよりガベージである。




・・・ってこの話から、データのサブプライム(生み出す価値は小さいのに、あたかも大きな価値を生み出すように言われ、過剰なお金をつかって、データを蓄えている)という話に向かっていくのだが、この先長いのと、とりあえず、クラウドとユビキタスの関係は説明したので、今回はここまで。またこんど、データの経済性と、データのサブプライムについては書きます。



  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

微弱電波のワンセグ放送なんだけど・・・?

2009-05-14 20:54:32 | Weblog

 組み込みシステム開発技術展で、通りすがりに聞いたので、間違ってるかも知んないんだけど、NECのブースで、微弱電波のワンセグ放送、つまり免許不要レベルの数メートルしか届かないんだけど、ケータイでワンセグ放送ができるっていうやつの話をしていた。

 たしか、これ、富士通でもやってるよね。

 で、それはいいんだけど、そこで、「実験局免許をとれば、もっと出力を大きく・・・」って聞こえたんだけど(聞き間違いかも??)これ、実験局免許、下りるの?
 数メートルだったら、実用価値はあまりない(観光地の案内とかには使えるかも)けど、これが、セミナー会場一体とかだと、同時通訳レシーバー替わりとか、いろいろあるかも・・・

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

パワーポイントがハッカーの標的に?

2009-05-14 12:50:09 | Weblog

ここのニュース
パワーポイントがハッカーの標的に=マイクロソフト
http://headlines.yahoo.co.jp/hl?a=20090513-00000857-reu-bus_all

(以下斜体は上記サイトより引用)

米マイクロソフト<MSFT.O>は12日、プレゼンテーションソフトのウィンドウズ版パワーポイントがハッカーの標的になっているとして、パッチを公開した。


げんしょう


ウェブサイトからダウンロードしたり電子メールで受信したウィルスに汚染されたパワーポイントファイルを開くと、利用者のアカウントに許可されているすべての作業をハッカーが行うことが可能になる

とりあえず、ぱわぽは、ダウンロードしないほうが安全??

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

Java6と.NETにおけるXML署名

2009-05-13 18:14:43 | Weblog

 XMLコンソーシアムWeekの「セキュリティ部会」の「3.どうやって使うのか?」で聞いてきた話。




■対応状況
・Java6におけるXML署名
 Java6の標準で入っているXMLSignatureでできる

・.NETにおけるXML署名
 signedXMLクラスを使う。




■XML署名のJava6と.net間相互運用

1.外包(detached) 問題なし
2.同一ファイル内detached 問題なし
3.埋め込みenveloped 問題なし
4.enveloping
 名前空間を Java6で=""(空文字指定=なし)と指定すると、.netと互換性なくなる。
 .netにおける=""は、java6では、名前空間のパラメータごと指定しないものに相当




■.netにおける暗号化

CryptoAPI→CGN(Cryptography Next Generation)
      Vista/server2008から




■SHA

 現在SHA-1

 RSA2048/SHA-2
  米国 2010年 
  日本 2013年 




なかんじかな。。。勘違いとかあったらごめんなさい。



  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

気象庁とXMLコンソーシアムの防災情報XML実証実験だけど、キャリア的には?。。。

2009-05-13 14:26:31 | Weblog

 きのう、XMLコンソーシアムWeek、途中からなので、はじめのほうの、気象庁防災情報XMLの話を聞けなかった。
 なので、そこで説明されていたり、ウィリアムのいたずらの勘違いかもしれないけど、
 もし勘違いじゃなかったら、ちょっとやばそうなので、ここに書いておく。
 Webサービス実証部会の 「気象庁防災情報XMLを使った実証実験β版に向けての途中経過報告」についてで思ったこと。




■気象庁防災情報XMLを使った実証実験とは?

 まず、その話の前提である、「気象庁防災情報XMLを使った実証実験」についてなんだけど、
 (まったく関係のないウィリアムのいたずらが説明するのもへんだけど)
 ウィリアムのいたずらの理解では、こういうことを実験したいらしい。

(1)気象庁から防災情報を、XML形式で配信する
      ↓
(2)2次プロバイダがアンドロイド端末に向けて防災情報を発信
   (あらかじめ、端末から位置情報を受ける)
      ↓
(3)アンドロイド端末は、あらかじめ位置情報を2次プロバイダに送信
   位置情報にあった防災情報を2次プロバイダから受ける

 ここまでの話に関して、疑問はそんなにない(いや、厳密にはある。「問題2」として後述する)

 疑問点は、IPアドレスが変わるので・・・といっていたこと。。。(って言っていた気がした)。




■問題1のための推測

 IPアドレスが変わる=キャリヤはDHCP接続しているということ?

 たぶん、そうでしょう。

 そして、NATも使っているでしょう。

 ケータイ端末は、日本に何千万台もある。この1台1台に対してIPアドレスを振ったら、クラスAでも1700万台ぐらいまでしか
振れないので、1台1台IPアドレスを振るということは考えられず、当然、NATというかNAPTを使っているだろう。

 そうすると、複数台が同じIPアドレス。・・・・(1)

 かつ、IPアドレスが変わる、ということから、このIPアドレス&ポートの貸し出しは、一定期間で終わるということになる。
 そりゃーそうでしょう。ある端末はあるIP&ポート番号って決め付けちゃたら、そのあとずーっと使わないのに貸し出してたらもったいない。

 なので、DHCPで、

 あるIPアドレス&ポート番号が、ある一定期間貸し出される・・・(2)




■問題1

 そーすると、タイミングによっては、2次プロバイダ側から見ると、あたかも同じIPアドレス&ポート番号が2つあるように見えて、ぜんぜん関係ない人に、情報を送っちゃうことがないか?

 つまり、こんなタイミング

(あ)東京にいるAさん、朝10時、プロバイダへ位置情報通信。
  このときIPアドレス&ポート番号を取得し、2次プロバイダへ送信

  かりに、
  IPアドレス 210.230.128.225 ポート番号:10025
  だったとする。
  リース期間1日

(い)次の日、朝10時にAさんのIPアドレス貸し出し期間がきれる。
  上記(1)により、210.230.128.225:10025は、別の人に貸し出される可能性がある。

(う)大阪にいるBさんが、朝11時にプロバイダへ位置情報通信。
  (い)により、たまたま、Aさんと同じアドレス210.230.128.225:10025を割り当てられたとする。
  これを、プロバイダに送信

(え)この間、Aさんは(あ)以降、アクセスしなかったとすると、プロバイダには、

   Aさん 東京 210.230.128.225:10025
   Bさん 大阪 210.230.128.225:10025

 となる。あたかも同じIPアドレス&ポート番号が2つあるように見える。


(お)ここで、東京に地震!防災情報発令!!
 っていうので、東京にいるAさんあてに210.230.128.225:10025にデータを流すとこまる。
 そのアドレスは、大阪にいる、Bさんだ。大阪にいる、全然関係ないBさんに、
 なぜか、東京の地震の情報が流れる。

(か)それじゃー、最新のIPアドレスだけに送ればいいじゃん!と思うかもしれないが、
 これでは問題解決にならない。
 東京にいるAさんには、防災情報を流さないといけない。
 でも、サーバーは、AさんのIPアドレス情報は古いということはわかるが、
 Aさんは最新のアドレスを送ってきてくれてないので、Aさんには情報を流しようがない。




■問題2:そもそも、防災時にケータイを使って通信可能なのか?

 アンドロイド端末を使うということは、ケータイを使って通信するということになる。
 で、防災ということは、地震が起きたときにも、これを使って防災情報を流すということになる。

 はたして、地震が起きたときに、防災情報を、キャリアが各ケータイ端末(ここではアンドロイド)に流せるのだろうか?
 ケータイの通信、とまらない?

 だから防災にはMCA(無線)が使われるわけで・・・




 つまり、ケータイの通信部分も考えると、アンドロイドのようなケータイ端末で実現できるのかどうか?

 むしろ、マルチキャストで全地域の情報を流し、ケータイ側で地域の情報をマッシュアップするとか、
 MCA制御局にパソコンで防災情報を流し、それを音声変換してMCAに流すとかのほうが現実的?
 でも、マルチキャストでケータイ取れるのかなあ?

 Docomoとかauとか、ソフトバンクのキャリアの人とかを入れて話したほうがいいような気がする。
 これは、XMLコンソーシアムmatterというより、気象庁matterなのかしら・・・

 まったく、見当違いなこといってたら、ごめんなさい m(__)m

P.S 昔だったら、キャリアさーん、XMLコンソーシアムでこれにかかわれば、将来・・・
 とかいう話もあっただろうけど、この不景気のさなか、コンソーシアム入会して・・とかに 
 お金も時間も使えませんよね・・・




  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

EXIって何?XMLの圧縮にいいの?

2009-05-12 22:20:00 | Weblog

 きょうXMLコンソーシアムWeekにいってきたら、(ちょっと用事があって、途中参加)、ちょーど、EXIっていうのを説明している最中に着いて(ということで、EXIって、何というところを聞き逃した)、その後から聞いたんだけど・・・

 なんか、XMLのバイナリ形式みたいなんだけど、高い圧縮もできるらしく(GZIPより圧縮可能)他にも、いろいろ使えるらしい・・・

おお、なんかすごそう・・・

商用では、AgileDeltaのEfficient XML、フリーでは、EXIficient、評価に、exi-evaluationとかあるらしいけど、途中からなんで、よくわからん。

P.S で、途中から入って、講師は??とおもったら、新型インフルエンザの影響で、これなかったらしい(米国富士通研究所の人らしい)。おお、こんなところにも、新型インフル!!

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

薬ネット販売、2年の経過措置

2009-05-12 01:19:26 | Weblog

ここのニュース
改正案で継続使用認める=薬ネット販売、2年の経過措置-厚労省
http://headlines.yahoo.co.jp/hl?a=20090511-00000121-jij-pol

によると(以下斜体は上記サイトより引用)

厚生労働省が市販薬のインターネット販売を規制する省令を公布した問題で、同省は11日、風邪薬など「第二類医薬品」については2年間に限り、以前からの使用者に対する販売を認める改正省令案をまとめた。漢方薬など伝統薬の通信販売も同様に2年間認める内容で、有識者検討会に提示した。


ひとまず安心、なのか?
でも、また2年後同じ問題??

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

INPUTのradioに、TABキーでフォーカス、行く??

2009-05-11 17:27:10 | Weblog

へ??tabindexって書いてるのに・・・
以下のHTML

<html>
<head>
</head>
<body>
<form action="http://127.0.0.1" method="GET">
  <input type="text" name="t1"  tabindex="1"/>
<br>
  <input type="radio" name="r1"  tabindex="2" value="1" checked />1
  <input type="radio" name="r1"  tabindex="3" value="2"/>2
  <input type="radio" name="r1"  tabindex="4" value="3"/>3
<br>
  <input type="checkbox" name="c1" tabindex="5" value="10" />10
  <input type="checkbox" name="c1" tabindex="6" value="20" />20
  <input type="checkbox" name="c1" tabindex="7" value="30" />30
<br>
  <input type="submit" tabindex="8" value="送信" />

</form>
</body>
</html>


(上記< >は、本当は半角)
で、tabキーで移動すると、チェックボックスは、正常に各項目、タブでフォーカスが移動するんだけど、
その上のラジオボタン、タブキーで、はじめのものには、行くんだけど、もうひとつタブを打っても、横に行かないで、
下のチェックボックスに移動してしまう。横には、いかない。

なーぜー??バグ??(実験したのはIE6)

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

新型インフルエンザのために会社を休んだ場合、有給?で、その場合、その人の人件費は?

2009-05-11 13:51:36 | Weblog

 ところで、新型インフルエンザで、会社を休んだ場合(隔離されて待機とか)

  病欠なの(いや、病気じゃないぞ??)
  有給なの?
  まさか、その期間、給料ナシ(@_@!)

 で、有給だとすると、その期間の人件費は、開発費で負担するの?
 負担する・・・となると、パンデミックになって、もっと病気が深刻になると、開発費が大変なことに・・

(いや、給料ナシで待機になったら、自分がもっと大変なことになるんだけど・・・)

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

「プレイステーションケータイ」も「起こりうる」?。。。

2009-05-10 21:38:52 | Weblog

ここのGIGAZINEの記事
ソニーが「プレイステーションケータイ」を発売か、複数のスマートフォンも
http://gigazine.net/index.php?/news/comments/20090508_ps_phone/

によると(以下斜体は上記サイトより引用)


ソニー・エリクソン初のスマートフォン「XPERIA X1」ですが、「XPERIA X1」について小宮山氏は「一種の実験」であるとしており、2010年4月末までにNOKIAのSymbian OSやマイクロソフトのWindows Mobile、GoogleのAndroidなどのOSを採用したスマートフォンを少なくとも2台発売するほか、サイバーショットやウォークマンといったブランド名を冠した携帯電話のほかに、ソニーの強みであるゲーム機能を搭載した「プレイステーションケータイ」の登場を登場させる可能性についても「起こりうる」と述べています。


ただ、この記事の元記事
Struggling handset maker needs to get smart - and fast
http://www.ft.com/cms/s/0/63e29ce8-3aa1-11de-8a2d-00144feabdc0.html

は、こう書いてある(以下太字は、上記記事から引用)

He expresses interest in Sony Ericsson carving out a niche for itself based on Sony's strength in gaming. He says a PlayStation mobile, building on the Walkman and Cybershot phones, "could happen".


ま、どっちにしろ、「プレイステーションケータイ」も「起こりうる」?


  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

仕様ベースのシステムと進化ベースのシステム

2009-05-09 02:55:44 | Weblog

 昨日書いた、S-ProgramとE-Programというのは(いや、資料にそう書いてあったので、そのまま書いたのだが)、ふつう、S-Type System,E-Type Systemというみたいだ。

 ここ(PDF)の8ページに
S-Type(Specification based software)、仕様ベースのシステム
E-Type(Evolution Based Software)、進化ベースのシステム
の説明がある。

もちょっとしらべてみるつもり

P.S どうも、Program Evolution. Processes of Software Change
っていう本が重要らしく、それが、ここPDFに丸ごとあるんだけど(^^;)

そして、そのあとFeedback in the Software Evolution Process(リンク先、PDF)となるみたいね。

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

Vista普及率、23%

2009-05-08 22:43:08 | Weblog

ここのニュース
Vista普及率が23%に 1年半で17%増も主流はやはりXP
http://headlines.yahoo.co.jp/hl?a=20090508-00000011-zdn_ep-sci


ここまで売れないWindowsってのも、すごいよね(^^;)



  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

デジタルMCA VS ケータイ(運行管理とデジタルサイネージ)

2009-05-08 17:53:55 | Weblog

 ケータイと無線のせめぎあいみたいな話をこの前書いたけど、どーもMCA VS ケータイの世界では、まさに勃発している?ようだ。
 この前は簡易無線のデジタル化について書いたけど、MCAもデジタル化されていて、バスの運行に利用されているようだ。

 バスの運行管理は、デジタルMCAを使っているらしい(日本電気)
No.250 都営バスの運行情報システム
http://www.f-banchan.net/tokyo/tobussys/tobussys.htm


 もちろん、この分野、KDDIのGPSMAPによる運行管理の分野と、もろバッティングする。

KDDIの通信モジュールを搭載した除排雪車両運行管理システムを開発
http://www.kddi.com/corporate/news_release/2006/0222/index.html


ただ、この技術って、いままで、車両→指令局の流れ中心で考えてたけど、逆に指令局→車両っていう流れも実現できるはずで、そーなってくると、一斉配信できる、デジタルMCA、ケータイ以上に(ま、ケータイでもできるんだけど)面白いことできるんじゃないか。




 デジタルMCAでは、車両(移動局)から、指令局(会社側)に対して、画像を送ることもできるようだ。
画像伝送装置「DARWIN(ダーウィン)システム」
http://www.mrc.or.jp/top/application/post.html#more


じゃ、逆向きに、会社からバスやタクシー、駅にデジタルMCAを使って、広告の画像などを配信し、
バスやタクシー、駅では、その画像をデジタルサイネージ(=山手線のトレインチャンネルのようなCM)として表示する

ってこともできるんじゃないか?

 まあ、MCAで送れる量の問題もあるけど、デジタルサイネージは”ぱたぱたアニメ”っぽくてもいいので、何回かに分けておくると、いっせいにデジタルサイネージの画像(=CM)を送れる。
 そうすると、MCAを使ったデジタルサイネージによるCM、それによる、バスやタクシーの広告収入の増加などが考えられそうだ。




 てなわけで、MCA VS ケータイは、さらに、デジタルサイネージとか、あらたな市場でさらに起こってくるような気がする。



  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

アジャイルとウォーターホールの位置づけと限界を30年前に指摘したLehmanって、すげー!

2009-05-08 02:22:06 | Weblog

M.M.Lehman(りーまん?)という人がいるそうだ。
 この人が、
Programs, life cycles, and laws of software evolutionという論文を書いているそうなのだが、そこで、S-ProgramとE-Programというのを議論しているそうだ。

S-Programは、ちゃんとした仕様書があるもの
E-Programは、仕様が現実を組みこんでしまっているため、現実が変化すると、
      仕様も変化しちゃうというものらしい。

論文を直接読んだわけではなく、ある人から聞いた話を自分で理解した範囲なので、まちがってるかもしれないけど、ま、そーだそーな。。。




おお、この考えはすごいっす!

仕様がはっきりしているかどうかで、開発方法論をわけてしまうと、

S-Programは、仕様がはっきりしているのであるから、ウォーターフォールが向いていて、
(仕様が柔軟でないなら、柔軟に開発できるアジャイルをわざわざ使うことはない)
自動化やソフトウエアファクトリー的な開発も考えられる。
(ソフトウエア「ファクトリー」の場合、工場ラインを途中で変えると面倒なように、
 ソフトウエアファクトリーも画一的な開発手法である程度のスケールでやらないと、
 メリットがでにくい)

一方
E-Programは、仕様が現実にともなって変化してしまうなら、これは
アジャイルがむいている。俊敏性によって、現実の変化に追いついて
いけるからという意味もあるけど、それ以前に、ウォーターフォール
のように逆戻りしない場合、変化されてしまっては困る。
 そして、現実が変化する場合、お互いの現状の意思を確認することは
重要で、その意味でテストファーストにして、結果の確認をしたり、
プロトタイプ、モックアップを作成し、共通認識を得ることは、意義深い。




つまり、Lehmanは仕様がどれだけ決まっているかによって、S-Programと
E-Programにわけているけど、それは、今現在の時点で考えると、この違いが
まさにウォーターフォールとアジャイルの2つの開発方法論に対応していて、
このLehmanの視点によって、かなりの開発や周辺事項が整理され、不要な
(不毛な?)議論をしなくて済むようになる。

これを約30年前にだした、Lehman、すごすぎです。。。


  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

無線(MCA、簡易無線)とケータイの奪い合いなんでしょうかね。。。

2009-05-07 15:40:20 | Weblog

 昨日は、デジタル化された簡易無線によるデータ転送とケータイの話を書きました。
 デジタル化された簡易無線の場合、現場側と操作側に簡易無線機をおき、その間でデータ転送する。
 そして、操作側をインターネットで結べば、ランニングコストがかからず、
遠隔操作ができる。無線LANより広い範囲(1Kmとか)で・・・

 ってお話でした。

 じゃあ、ケータイは無線に負けてばかりかというと・・・
 微妙なのが、今のMCAだとおもいます。

 MCAは、マイクロソフト認定アソシエイトではなく、ってくどいですね、
Multi Channel Access Systemという、タクシー無線などで行われている
方法なんだけど、

・制御局(事業主体:(財)移動無線センターなど)があって、
・企業などは、その制御局にMCA通信したい!!と申し込むと
・企業側には、指令局と移動局がつくれて
   指令局:タクシー会社
   移動局:個々のタクシー
 みたいなかんじ
・で通信ができるというもの。
・制御局は3陸特以上の資格が要るけど、借りる企業側は、
 別に資格は要らない・・・が、利用料金がかかる。

くわしくは、ここ
MCA無線システム(Multi Channel Access System)
http://www.tele.soumu.go.jp/j/system/ml/mca.htm


 MCAは、ケータイでもおなじことができる(ただし、自動車のばあい、
ハンズフリーにしないといけないけど、ケータイのハンズフリー機は、
あるのかあ?)
 そうすると、通話可能圏内(純粋なエリアの広さの問題以外に、電波の届きやすさなど)とか
価格とか、いろんな問題で、場合によっては今のMCAより、ケータイのほうがいいっていうことも
あるかもしれない。
 もちろん、逆もあるかもしれないけど・・・

 簡易無線がデジタルになったり、ケータイ通話料が安くなったり、ということで、
MCAと簡易無線とケータイで、いろいろな選択肢が出てきたように思う。


  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする