スキップしてメイン コンテンツに移動

LPWA @ モバイル通信展2018

モバイル通信展 = http://www.mobilenetwork.jp/
(通信放送Week2018内 = http://www.cbw-expo.jp/ )
会期は，2018年4月4日〜6日の3日間。参加したのは4月5日。

■LPWAセミナーが盛りだくさん
聴講したもの
・[LPWA-20]実際のLoRaWANの使い方, NTTアドバンステクノロジ（株）
・[LPWA-7]Sigfoxネットワークを活用した実証実験の紹介, アイ・サイナップ（株）
・[LPWA-22]LoRaネットワークを活用した自治体向け公共サービスの実証実験について, （株）Braveridge

■得られた知見
・1. LoRaWANの補充知識
・2. LoRaWANの特性(通信距離などの技術的課題)
・3. 適用アイデアと事例

●1. LoRaWANとは
・LoRaWANとLoRaの違い:
　LoRaは単なる変復調。
　LoRaWANは，LoRa＋ 端末管理，通信暗号化，あとなんか。
　LoRaWANは，デバイス⇔GWの通信 ＋ GWやLoRaWANサーバも含めたソリューション。
・LoRaWANは，アライアンス認証機器によるマルチベンダ構成が一般的。
　デバイス(センサ)〜GW機器〜LoRaWANサーバ。
　最近は1社で全部揃うケースも出てきたが，マルチベンダ構成は今後もつづくだろう。

●2. LoRaWANの特性(通信距離などの技術的課題)
・「LoRaWANは飛ばない？」
　“LoRaWANは数km〜数10km，100kmも飛ぶケースだってある”と言うけれど…
　都会は難しい。都市部で屋外→3回連送なら2〜3km。1回なら1km。SF11の場合。
　“2kmも飛んだらめちゃくちゃ良い方”。
　『SF11』って？　SFはSpreading Factor。拡散率→ノイズ耐性。
　サブギガ帯= (300MHzとかに比べると)回折性が無い
　→障害物の近くで隠れるとと繋がらない。でも少し離れると回折が効いたり。
・高速移動は不得意(LoRaWANだけじゃなくてLPWA全般の特徴)。
・「不安定？」
　設定まちがいも多いが，まちがいに気付きにくい(デバイスの設定確認がし難い)。
　チャネルが重複していることも(LoRaWAN同士以外にも)。
・無線通信の改善策はいろいろある。
　利得改善の方法(出力電力など)。送信タイミングの見直し(夜間に送信するなど)。
・マクロダイバーシティ構成 = GWをなるべく密に配置(エリアを重複させる)
　= 常に複数のGWと通信出来るようにしておく = LoRaの定石 = 力業の解決

●3. 適用アイデアと事例
[NTT-ATより]
・スマートメータ: 検針する人がとてつもないスピードで減っている (日本の事情)
　(「かつては5円／1軒で人が検針してくれるからスマートメータは要らないと言ってた」)
・人の監視: 子供や老人。日本では要望あり。中国ではそんな市場はない。
・パーキングロットやゴミ収集: 欧州では要望あり。日本では需要無し。
[アイ・サイナップより]
・車載系，とくに鉄道系が得意。
・物流でのGPSトラッカー。LPWAはトラックなどの移動中の通信が弱いけど，どれくらい使い物になるかの実証検証。
・飲食業(ナポリの窯): 冷蔵庫の温度監視。EnOcean＋Sigfox。
[Braveridgeより]
・糸島市での実証実験。GW設置する施設選定。自治体担当との調整要(難)。
　地方(≒田舎)だと，GW設置に向いた高い建物が少ない。
　{NTT-ATが“都会だと飛ばない”と言ってるのと合わせると，要は「どっちも難しい」？}
・見守りシステム(幼児・老人)
・監視間隔を短くするとバッテリ保ちが悪い。1週間だと「短い」と不満。
・水位系(河川) → 河川だけじゃなくて，道路の冠水なども。
　地方自治体が管理する河川は予算少なく数が多い。

・コミュニティバスの接近・通過情報: スマホを持ってない住民向け。
 

コメント

コメントを投稿

このブログの人気の投稿

5600ページのIEEE 802.3-2018が入手可能になった

IEEE 802.3の名称は今では「IEEE Standard for Ethernet」になっている。 「イーサネットとIEEE 802.3は別物なんだよ」という話は，今では昔話でしかない。もうひとつ“いまはむかし”な話をすると，「イーサネットはCSMA/CDだよ」なんて言うと恥をかくのでやめた方がいい。こちらは名称の問題では無く中身の話だが，ここでは詳しい説明は割愛する。 この「イーサネット標準」の2015年以来の改訂版が，2018年8月に発行。6ヶ月のIEEE会員限定期間が過ぎたので，一般にも入手可能になった。ただし個人アカウントは取得する必要がある。この話は以前に書いた ( https://nmizos.blogspot.com/2017/12/ieee802.html 参照)。 https://ieeexplore.ieee.org/document/8457469 このネタをブログにしようと思った動機はタイトルに記してしまった。この規格は改定されるたびにドンドン太って巨大になってきている。本編改訂の間に発行されたamendment (補遺と訳すのがいいのかな)が取り込まれるので，太るのはしょうがない面もある。でもねぇ，ついに5600ページ。もちろん通し読みするようなものじゃない。PDFファイルなので「厚さ」は無いが，印刷したらどれくらいになるんだろう。 参考までに，過去10年の本編のボリュームを比較してみた。 　2008 = 5分割，2977ページ 　2012 = 6分割，3748ページ 　2015 = 4017ページ，56Mバイト 　2018 = 5600ページ，98Mバイト 以前は数セクションにファイルを分割して公開されていた。ファイルが大きすぎるのを気にしてたんだろう。2018版も中身は8セクションに分かれている(ページ番号も別に付いている)のを，PDFファイルとしては合体してある。100Mバイト程度のPDFが「デカ過ぎて開けない」ってことも無いだろうから，1本になっていた方が全文検索ができて都合がいい。ちなみにiPadで開いて全文検索しても，今の98Mバイトなら困らない。 参考までに，無線LANのIEEE 802.11の方は，802.11-2016が3534ページ。こちらも結構なもんだ。 --
コメントを投稿
続きを読む

IEEE802標準文書の入手

■概要 入手方法が変わった。たぶん2017年のどこかから。 ダウンロードの都度メルアド等を入力するのではなくて，メンバ登録＆ログイン形式に。 個別の参照(入手)時点の操作も変わった。 概要の表示ページから“Download PDF”を選ぶとPDFファイルが呼び出されるが… 即ダウンロードでは無くて，(ブラウザ依存だと思うがFirefoxの場合は)インラインでPDF表示になるので，その後に表示しているPDFをダウンロードさせることになる。 802.3の場合は困ったことに文書がデカ過ぎる。従来は複数パート(セクション)にPDFが分割されていたが，参照方法が上記の様に変わったのに合わせて，802.3全体が1本のPDFに。なんと4000ページ超，50MB超の1本のPDFになり，それをまとめてインライン表示しようとするので，待ち時間がとても長い。メモリの少ないPCだと途中でアカンことになりそう。   ---- ■操作 入口=  http://ieeexplore.ieee.org/browse/standards/get-program/page/series?id=68 (  http://ieeexplore.ieee.org/  からでもたどれるだろう )。 メニューをたどって，例えばIEEE 802.11(無線LAN)の標準文書を参照しようとすると… “Download PDF”は選択できなくなっている。 画面最上部の“Personal Sign In”からログインすると… “Donwload PDF”が有効になる。 概要でも記したように標準文書フルテキストPDFのダウンロードは，Firefoxの場合にブラウザのインラインでの表示になるので，保存する場合にはブラウザの操作でファイル保存する。 ユーザ登録は“Create Account”から。 入力方法などは自助努力で。(画面のガイダンスや注意事項を読みましょう)。 --
コメントを投稿
続きを読む

RFCは番号を無駄遣いしていないか？

新規に発行されるRFCの番号が8000番台になっていて，その8000番台も1年くらいで食い潰しそうな勢いだ。実は8年ほど前にも同じ様に「なんと6000番台後半だよ」と思ったのだった。 ところで，RFCの番号って，几帳面にきっちりと順番に使っているわけでは無い。大物RFCにはキリ番を使うことがある様だし（RFC 8200とか），規格のバージョンアップの際には旧番号から覚えやすいものにすることがある（RFC 822 → RFC 2822など）。 …ということは，ところどころ虫食い状態で空き番号がたくさんあるんじゃないかな？と，ふと思った。 RFCの一覧ページはこれ: 　 https://tools.ietf.org/rfc/ これを眺めると，ところどころに「Not Issued」となっている番号があるので，虫食いになっているのはたしかなようだ。無効化（Obsoletes）されたRFCもたくさんあるけれど，一度は使われた番号だから，これについては「使った」ということでいいだろう。 もう1つの一覧形式で，Mini-Indexページなるものがあった: 　 https://tools.ietf.org/rfc/mini-index ぱっと見で，虫食い状態がわかる。言い換えるとそれしかわからない。 上記のMini-IndexのHTMLを解析して，具体的にどれくらい虫食いなのかを調べて見た。単なる酔狂でしかないけれど。 結果（RFC 8754まで） 個数 RFC番号  735 8000番台  996 7000番台  973 6000番台  971 5000番台  973 4000番台  982 3000番台 1000 2000番台  995 1000番台  933 999番以下 こうしてみると，最初の999番までが一番大雑把だ。 RFC化の検討に入ったけど最終的に発行されないものもあるから，2000番台の様に完全に埋まることは珍しいと思う。そういう意味では，まぁまぁ，几帳面に番号割当てをしていると思っていいのだろう。 さて，RFC 10000に到達するまで残り約1250。そこに達するのは，だいたい4年ちょっと後の2024年頃だろうか。 【参考: カウントスクリプト】 : count.sh #...
コメントを投稿
続きを読む