縁側 > その他 > 備忘録いろいろ
「縁側」-みんなが作る掲示板-からのお知らせ
縁側からのお知らせ

縁側をご利用いただく際のルール&マナー集を用意いたしました
ユーザーの皆様に楽しくご参加いただけるよう、主に投稿時の注意点などをまとめています。
ご投稿の前には必ずご一読をお願いいたします。詳しくはこちら⇒「縁側 ルール&マナー

紹介文

スマホのg07の不具合を確認する為に始めましたが、ログを眺めるのも飽きたので機器を限定せずに思う事を書いておきます。

カテゴリもその他に変更しましたが、過去の書込はそのままにしてあるので、違和感ありますが…

最近はGoogle Homeを手に入れたので気付いた事を書き留めておこうと思います。

  • 備忘録いろいろの掲示板
  • 備忘録いろいろの伝言板
  • 備忘録いろいろの投稿画像
この掲示板は閲覧専用です(運営者のみが投稿できます)。

このページのスレッド一覧

前のページへ次のページへ


久しぶりに更新

10月下旬にエリアマップが更新されてわが家も濃いピンク色になった。
少し前までは12月末予定のエリアだったのだけど…前倒しされたのかなと、早速申込。

リスト(自治体名)には記載が無いのが少し不安だったけど、自宅から200m程度の場所に基地局を確認済みなので期待しつつ…

最初にスマホ(P30 lite)で確認
 バンド18(パートナー回線)しか掴まない
ダメ元でルータ(MR05LN)でも確認
 最初はバンド18だったけど、いつの間にかバンド3(楽天回線)に接続
 (後日確認したときはバンド18のまま)

初日の感想
 たった200m程度も安定して通信できないなんて使い物にならない

別の日に最寄り基地局周辺で確認すると、なんと未稼働っぽい。
確認にはNetwork Cell Info Lite(後日有料版購入)を利用。

ここから楽天基地局探しが始まった。

初日にルータが掴んだバンド3はどこから来たのか?
わが家は市境にあって約1q程度の隣の市にも基地局を見つけていたので、そこから来たと推測。

Network Cell Infoは掴んだバンド以外にも情報が表示される。
どうやら、TAC-ECIと表示されているのが基地局情報らしい。

TAC
 Tracking Area Code : 位置登録エリアを示すコード
ECI
 E-UTRAN Cell Identifier : 無線ネットワークのセルの識別子

それによると、隣市の基地局近くで確認したECIと自宅で確認出来るECIは違う。

Network Cell InfoのMAPタグを利用すると現在地と掴んでいる電波の情報が表示される。
これを見ながらウロウロ(端から見ると怪しい人)してみたが、よく分からず。

MAP上には移動軌跡も表示されるが、別のアプリを操作するなどしていると消えていたりする。
その時点ではログが残るのかどうかもよく分からず。

仕方ないので移動しながら定期的に画面スクショを保存して帰宅後に確認することにした。
ただ、人気の無い場所は良いけど、人のいるところでのスクショは大きな誤解を招く可能性があって出来ない。

スクショを見ながらGoogleマイマップを利用して受信状況をマッピングしてみた。
その結果、駅前の商業施設屋上に発見したアンテナからの電波が届いていることが判明。

とりあえずスッキリはしたが、他の基地局も気になる。
でも、スクショからの転記はかなり疲れる。

マニュアルらしきものを発見しマップのログは保存可能らしいことが判明。
スマホをPCに接続してスマホ内を確認するとcsvファイルを発見。
とりあえず、必要と思われる項目は保存されている感じ。

なんとか、Googleマイマップへのマッピング情報を生成できないかと試行錯誤で丸1日費やした。
とりあえず、EXCEL VBAを利用してcsvファイルからkmlファイル(Googleマイマップ等で読込可能)を生成する事に成功。

ちなみに、Network Cell Info(有料版)だとアプリ終了しても前回記録されたマップ上の軌跡はそのまま残っている。
また、保存可能なログ件数が1000件(Liteは200件)になっているみたいだ。

マップの軌跡に関してはマニュアルに記載の比較表で「Map memory cache」が有料版にのみ有効となっていた。
ログ件数に関しての記載は発見できず。

楽天の基地局とNetwork Cell Infoのログの内容については別途記載しておくつもり。

2020/11/27 22:42  [2048-117]   

亜都夢 さん  

2020/11/28 21:54  [2048-118]  削除

発見した基地局の殆どがこの形態

基地局について

発見した楽天モバイルの基地局は基本的には同じ形態で、他のキャリアのアンテナとは形状が異なるので目立つ(見つけやすい)。
たぶん利用している周波数帯(バンド)は一つだけなので、アンテナも1種類なのだと思う。

高層の建物が少ないところなので、写真の様にコンクリート柱の上に3つのアンテナがあるタイプが殆ど。
建物屋上に設置されている場合は、アンテナが1本ずつまたは1本と2本に分割されている。

かなり目立つので、サービスエリア内なら少し上を見ながら散策すれば発見できるかもしれない。
基地局のコンクリート柱にはアンテナ部から接続されていると思われる箱状の装置が3個設置されている。
箱にはRマークがついている。

稼働中の基地局に関しては、Network Cell Infoなどを使えば、受信強度が一定以上強くなった時点で周りを見渡せば発見可能。
-70dBm程度になれば基地局はかなり近いはず。

Network Cell Infoで確認した範囲ではアンテナ毎にECIが違う。
また、同一基地局のECIは連番になっている。

2020/11/28 21:54  [2048-119]   

相変わらず最寄りの基地局は稼働していないらしい。
最近、電波強度を確認しているスマホでは家の中では、殆どバンド18しか掴まない。
ログを確認すると短時間はバンド3を掴んでいるらしいが…

今日は天気も悪いので屋内でMR05LNの受信状況を確認することにした。
何とかバンド3を掴む場所に設置して1時間強(通信量1GB強)確認した範囲では安定している。

実際にはMR05LN statusの表示を見ていると時々バンド更新しているので、2ヶ所の楽天基地局が切り替わっている感じ。

速度測定してみるとは下りの20Mbps程度は仕方ないとしても、上りが1未満なのは遅すぎる。
以前確認したときはもっと速かったので、天候とかも影響しているのかも。

とりあえず動画配信サービスで視聴確認してみたが、画質を高めに設定してもほぼ問題は無さそう。

現時点では使えない事は無いけど、安心して使えるか?って考えると微妙。

2020/12/5 13:37  [2048-120]   

先日、MR05LNでバンド3で安定した再テストした。
でも、何故かバンド18のまま。
少し場所を変えたらバンド3に切り替わった。

週末には、スマホにSIMを入れてNetwork Cell Infoで移動しながら受信状況を確認してみた。
結果は、かなりの範囲でバンド3を確認できた。
でも、自宅から3軒隣くらいでバンド18に…本当にギリギリの場所らしい。

現在は2階の窓際に設置しているが、スピードテストは先日より高速(下り30Mbps、上り3Mbps程度)。
この数値以上が安定的に出るならWiMAXから乗り換えても良いかも。

Network Cell Infoのログについて次に書く。

2020/12/7 20:20  [2048-121]   

Network Cell Infoのログについて

スマホの内部ストレージ(PCとファイル転送モードでUSB接続)にNetwork Cell Infoというそのままのフォルダが作成されている。
ログはその中で、Liteの場合はフォルダ名もLite付き。

ログのファイル名は下記形式
CMWF_YYYYMMDD_HHMMSS_cell_ainf_dxxxx_n1.
csv

CMWFは形式の規定値で設定で他に5種類選択可能だが未確認
YYYYMMDDは日付でHHMMSSは時刻で、ログ保存時の値
xxxxは保存件数

csvファイル内は下記項目行を先頭にログがカンマ区切りで件数分保存されている
sim,radiotype,radio,mcc,mnc,area,cellid,
unit,lat,lon,signal,extra,acc,time,speed
,bearing,alt,api,device

詳細は下記に説明がある
http://wilysis.com/networkcellinfo/25-nc
i-export-db


この中で下記項目のみに注目すれば良い(はず)。
mnc
 11(楽天)または53(auの楽天ローミング用)
area
 キャリア(楽天またはau)の決めた範囲で切り替わる
cellid
 アンテナ毎(1基地局に3アンテナ)に違うらしい(楽天の場合)
lat
 緯度
lon
 経度
signal
 電波強度(dBm)
time
 UTC timeのシリアル値なので変換が必要

2020/12/8 14:51  [2048-122]   

Googleマイマップにデータをプロットする為にはいくつかの方法があるが、とりあえずkmlに変換する。

kmlはxml形式で記述されている。
細かい約束事(必ず記述する内容やマーカ部分から参照する部分)は脇に置いて、計測地点をマーカとしてプロットする場合の様式は下記。

<Placemark>
<name>マーカの名前</name>
<description>マーカの説明</description>
<styleUrl>アイコンのスタイル</styleUrl>
<Point>
<coordinates>
経度,緯度
</coordinates>
</Point>
</Placemark>

Network Cell Infoのログから必要数分だけ上記形式を繰り返して生成すれば良い。

若干補足
・マーカの名前
 通常は1行
 複数行にしたい場合は改行すれば良いが、自動化するならお勧めしない(処理数が可変になるので)

・マーカの説明
 1行ならそのまま記述だが、複数行の場合は下記の何れかで可能
 改行コードを記述する
  例: 1行目&&#xA;2行目
 CDATAセクションを利用し、HTML(改行は<br>)で記述する
  例: <![CDATA[1行目<br>2行目]]>

・アイコンのスタイル
 説明を飛ばした約束毎でXMLの最初に記述したスタイルに対応した記述をする。

・経度,緯度(,高度)
 高度は省略可能なので省略

最後に終了の約束事を記述して完了

2020/12/8 20:05  [2048-123]   

kmlの約束事について

必ず書くこと
1.ヘッダ部分(1行目がXMLヘッダ、2行目がkml名前宣言)
<?xml version="1.0" encodin
g="UTF-8"?>
<kml xmlns="http://www.opengis.n
et/kml/2.2">


※内容に無関係でコピペで良い

2.オブジェクトの定義
<Document>と</Document>で囲まれた部分でKMLのほぼ全体
↑で書いたマーカ部分はここに含まれる

<Document>の次に下記(レイヤで表示する名前)を記述
<name>表示したい名前</name>

2-1.スタイル定義
<StyleMap id="識別子">
<Pair>
<key>normal</key>
<styleUrl>#識別子-normal</styleUrl>
</Pair>
<Pair>
<key>highlight</key>
<styleUrl>#識別子-highlight</styleUrl>
</Pair>
</StyleMap>
<Style id="識別子-normal">
<IconStyle>
<color>ff5b18c2</color>
<scale>1</scale>
<Icon>
<href>https://www.gstatic.com/maps
pro/images/stock/503-wht-blank_maps.png&
lt;/href>

</Icon>
</IconStyle>
<LabelStyle>
<scale>0</scale>
</LabelStyle>
</Style>
<Style id="識別子-highlight">
<IconStyle>
<color>色番号?</color>
<scale>1</scale>
<Icon>
<href>https://www.gstatic.com/maps
pro/images/stock/503-wht-blank_maps.png&
lt;/href>

</Icon>
</IconStyle>
<LabelStyle>
<scale>1</scale>
</LabelStyle>
</Style>

-nomalは通常の表示、-highlightはマウスオーバーしたときの表示
colorは16進表示らしい
Iconはマイマップでデフォルトで選択可能なアイコンの中で○の中に×表示のもの(とりあえず)

複数有る場合ははこれの繰り返し。

今回は楽天回線とパートナー回線が区別できれば良いので2種類指定

こんな感じ(例)…と貼り付けようと思ったけど、ここは相変わらず意図しないところで勝手に改行されてよく分からなくなるので止めた。

この後にマーカ部分の繰り返しを記述し、最後に下記で終了

</Document>
</kml>


2020/12/11 09:57  [2048-124]   

とりあえず、Network Cell Infoのログを利用するのは出来た。
できれば、MR05LNでも同様のことがしたい。

AndroidアプリのMR05LN statusでは取得できているみたいだけど、ログは残ってくれない。
正確にはフォルダ固定(SDカード)で可能みたい。
でも、通常はSDカード使ってない。
しかも、一度試したが、何も記録されなかった。
たぶん、以前のAndroidバージョンとはパスが違うのだと思う
内蔵ストレージがあるのか不明だけど、仮にあってもスマホのようにUSB接続で参照可能なのかも不明。

少し調べたら、MR05LN statusはコールログというMR05LNの標準機能の内容をわかりやすく表示しているだけらしいことが判明。
Androidアプリを作るスキルは無いけど、ログさえ手に入るならPCで加工できるはず。

PCから「クイック設定Web」を開いてコールログを表示し、コピペ…でも良いけどスマートじゃない。
ソースを確認して試行錯誤した結果、コールログを直接ダウンロードする事に成功した。

具体的には書いて良いのかどうか分からないので書かないけど、ログ名を直接指定すれば取得できる。

まずはコールログの形式を把握しないと処理できないので、別途確認して整理するつもり。

2020/12/11 10:25  [2048-125]   

よく見たらクイック設定webにログのダウンロード機能があった。
しかも、ボタンとかじゃ無くて、ハイパーリンクで丸見え。
ソース確認とか必要なかったらしい。

ちなみに、EXCEL VBAでログを直接シート上に表示出来るので、後は内容を見ながら必要な項目を抽出とかすれば良い。

その前に苦労したのはログインする事。
単にログファイルへのパスを指定しても認証画面で止まる。

1日くらい掛けて試行錯誤した結果、XMLHTTPオブジェクトを利用すれば認証可能な事が分かった。

こんな感じで認証を済ませておけば、ログファイルを直接指定しても認証を求められることは無い。

Dim httpReq As Object
Set httpReq = CreateObject("MSXML2.
XMLHTTP")
Call httpReq.Open("POST", URL,
False, USER, PASS)
Call httpReq.Send

2020/12/12 00:33  [2048-126]   

MR05LNのコールログについて

まず、最大500行でローテーションするらしい。
起動(再起動)時にはクリアされる。

各行の最初は下記で始まる
YYYY-MM-DD HH:MM:SS ril- 2.inf:

日付と時刻はそのままだけど、ril-2の意味は不明
infはinformationの意味だと思うけど。

処理する際には下記として扱う
 1〜10文字 日付(10桁)
 12〜19文字 時刻(8桁)
 20〜32文字 不要(13桁)

これ以降がログ部分だが、字下げされている部分がある。
上の行に付随する内容だと思うが判断に必要なら字下げを意識して処理する必要がありそう。

起動時のログは下記

modem start
modem mode(Shutting down)
modem mode(Low power)
pin1 status(disabled)
modem mode(Online)
area information(area out)
area information(area in, LTE, 44053[Rak
uten], Home, connection enabled)
signal level(4)
RF Band Information List[0]: radio_if=8
active_band=143 active_channel=5900
RF Band Information List(Extended)[0]: r
adio_if=8 active_band=143 active_channel
=5900
Cell Info(LTE Intra): plmn=44050 tac=xxx
xxx g_cell_id=yyyyyyyy earfcn=5900 s_cel
l_id=242
Neighbor Cell[0]: pci=242 rsrq=-65 rsr
p=-719 rssi=-483 srxlev=0
IPv4v6 connection start
IPv4 connection status(connected)
IPv6 connection status(connected)

30分くらい待っても楽天回線に切り替わらなかった時のログはこれだけだった。
切り替わった時のログは上記の1分後くらいに下記の記録が残っている。

packet status(IPv4, dormant)
packet status(IPv6, dormant)
area information(area in, LTE, 44011[Rak
uten], Home, connection enabled)
signal level(3)
RF Band Information List[0]: radio_if=8
active_band=122 active_channel=1500
RF Band Information List(Extended)[0]: r
adio_if=8 active_band=122 active_channel
=1500
Cell Info(LTE Intra): plmn=44011 tac=XXX
XXX g_cell_id=YYYYYYYY earfcn=1500 s_cel
l_id=34
Neighbor Cell[0]: pci=34 rsrq=-108 rsr
p=-1090 rssi=-783 srxlev=15

両方とも同じ位置に設置したのだけど、何故差異がでたのかは不明。

接続回線を判断するだけなら、「area information」に記録されている44053か44010を見れば良い。
但し、areaが変わらない場合は「area information」は出力されない。
その場合は、「Cell Info」で記録されているplmn(※)の値を見るしか無さそう。
電波強度は「Neighbor Cell[0]」に記録されているrsrpの値(単位は0.1dBm)で分かる。

tac(※)はエリア、g_cell_idは基地局がカバーするセル(範囲?)が分かる。
でも、Network Cell Infoでは記録されている位置情報は無い。

もっと問題なのは、ログが500行分しか残らないこと。
記録内容にも依存するけど、固定設置した状態でも20分間分にも満たない。
これでは外で利用して帰宅後にログ解析は不可能。

やはり位置情報取得も考えると接続したスマホ上で動作させて、スマホのストレージに記録しないと駄目っぽい。
MR05LN Statusがバージョンアップしてくれれば良いのだけど…(他力本願)

※ログ表示の意味(補足)
plmn(Public Land Mobile Network)
 移動通信システム識別子
 前3桁がMCC(Mobile Country Code)で日本の場合は440または441
 後2桁がMNC(Mobile Network Code)で事業者コード
 
 楽天の場合は44011(楽天回線)または44053(パートナー回線)になる。
 
tac(Tracking Area Code)
 トラッキングエリアコード
 キャリアが決めた範囲らしく、市町村とかの範囲とは違う
 
earfcn(E-UTRA Absolute Radio Frequency Channel
Number)
 直訳すると、「E-UTRA絶対無線周波数チャネル番号」だけど、E-UTRAって何だ?
 
 調べてみるとE-UTRAはWikipedia(英語)によると下記の何れからしい。
 Evolved UMTS Terrestrial Radio Access
  UMTS(Universal Mobile Telecommunications Syst
em)
 Evolved Universal Terrestrial Radio Acce
ss
 
 日本のサイトでは後者で説明しているケースが多いみたいだ。
 3GPPで規定された第3.9世代(LTE)の無線インタフェース技術の事らしい。
 
 earfcn全体ではLTEのチャネル番号って感じなのだと思う。
 たぶん、一般的に利用されるバンドもこの値から導けるのだと思う。
 
pci(Physical Cell Identifier)
 セル識別子
 
rsrp(Reference Signal Received Power)
 基準信号受信電力
 このログではほぼ4桁で表示されているので、実際の値は1/10になるらしい。
 
rssi(Received Signal Strength Indicator)
 受信電力強度
 

2020/12/12 20:02  [2048-127]   

MR05LNに関しては進展無し。
Android Studioに挑戦してみたけど直ぐにリタイア。

java固有?の宣言が多すぎて覚えきれない。
大昔にCOBOLを勉強したときに宣言部分が多いって思ったけど、COBOLの宣言は主に形式に関する内容だった気がする。
javaの場合は必要なライブラリの宣言は理解できるのだけど、COBOLでいう手続き部でも再度定義しなければいけない部分があるらしくて、内容が頭に入らない。

最近ではKotlinという言語もあるらしくjavaよりは簡単らしいので、次回は…いつになるやら…

仕方ないので当面はNetwork Cell Infoを活用して基地局(利用可能エリア)の確認をすることにした。

でも、近所の稼働中の基地局は殆ど発見済みなので少し遠征する必要がある。
面倒なのは1回で発見するのは難しいケースもあって、複数回の遠征は少しキツいかも。

1回目で適当にある程度広い範囲を移動しつつログ採取
帰宅後にログの確認(※)
 新規(或いは基地局位置不明)のセルIDのみを抽出して受信強度から基地局位置を推定
2回目で推定位置近辺を捜索

って感じかな…

面白いというより困るのは、必ずしも距離が近いセルからの電波を受信するとは限らないって事。
なので、移動しつつ連続した複数地点で確認する必要がある。
殆どのケースでは条件の良い近場の基地局の受信点の方が多くなる。

あとは、アプリのバグかもしれないけど、不思議なエリアコードとセルIDが記録されていることがある。
とりあえず現時点では異常として除外することにする。

※ログの確認

目視だと大変なので、EXCEL上で抽出し、Googleマイマップで確認
手順(2と3はExcel VBAで処理)
 1.基地局リスト(セルIDと座標:何でも良い)を作成
 2.ログから楽天回線で基地局リストに存在しないセルIDまたは座標の無いセルIDのみ抽出
  この時、リストに存在しないセルID(座標は無し)は基地局リストに追加
 3.受信地点でのエリアコードとセルIDを地点名、受信強度と受信時刻を説明(?)として座標を指定しkmlファイルを生成
 4.Googleマイマップに描画
 5.描画された内容から確認候補を選定し、基地局の位置を推定

2020/12/18 10:10  [2048-128]   

Network Cell Infoや類似アプリには基地局の位置を示す機能がある。
でも、確認した範囲では殆ど表示されない。

マニュアルによると、Mozilla Location Service (MLS) のデータが利用されているらしい。
データがCSVで公開されているので確認してみた。

全件数は約1200万件(全世界)でMCCが440は約49万件だった。(441は約2.7万件)

大凡の内訳は下記
ドコモ 約25.4万件
au 約13.5万件
ソフトバンク 約9.5万件
楽天 約0.6万件

半分強がドコモって事らしい。

但し、データをよく見ると少しだけ明らかなゴミが混じっている。
既に停波したはずの2Gの基地局データが存在してたりする。
8件だけだが楽天ではサービスしていないはずの3Gの基地局もある。
一見だけでは判断できないが、たぶん他にも無意味なデータも含まれているのだと思う。

ちなみに、このデータ数は物理的な基地局数とは違って、セル数なのだ。
楽天の場合は1基地局で3セル(確認した範囲)になっている。
ドコモの場合は不明だけど、多くの場合は楽天と同様に物理的なアンテナ数は3に見える。
3と仮定すると物理的な基地局数は1/3って事になる。

ドコモの統合報告書2020を見ると、2019年度末の基地局数は下記の記載がある。
 「PREMIUM 4G」対応基地局数168,800局
  LTEサービス基地局数228,100局
単純に合算して良いのかどうか分からないが、合計で39.7万局。

MLSに一番データの多いドコモの場合でも、カバー率を単純計算すると…
(25.4÷3)÷39.7=約21%って事になる。

楽天の現在の基地局数は不明だが、6月末時点で5739局が稼働し、建設数は1万局以上と発表している。
少し乱暴だが、間を取って8千局が稼働しているとすると…
(0.6÷3)÷0.8=25%

殆ど意味の無い計算。
圧倒的に件数が少ないって事の方が重要かも。
6千件の中にはいつも見るエリアコードは存在しないので、当然基地局はプロットされない。

ざっくりだけど、集計してみた。
100件以上のエリアコードのみで合計で約5千件
とりあえず、場所は座標の平均値の位置で集計

東京23区 2500件
名古屋近辺 933件
千葉湾岸エリア 509件
大阪 251件
横浜 243件
奈良 199件
埼玉南部 151件
三重北部 134件

やはり大都市圏じゃ無いとデータが無いって感じだ。

MLSは有志が提供したデータで成り立っているらしい。
サービスが先行した大都市圏にはデータ提供者が存在したって事。

アプリのレビューに基地局が表示されないとか不正確だとか書いている人がいるけど、MLSのデータが存在しないか不正確なのだと思う。
正確にするには自らデータ提供しろって事なのだろう。

あと、登録済みデータを見ると座標値は小数点2桁までなので、実際の位置とはズレて当然かも。

2020/12/20 00:37  [2048-129]   

MLSプロット

MLSのデータをGoogleマイマップ上にプロットしてみた。

最初はkml変換する必要があると思っていたのだけど、単にExcelファイルをドロップすれば良いだけだった。
ただ、1レイヤで2000件しかプロットできないので、セルID毎に4分割した。

セルIDの200番台までは隠れてしまったけど、下町エリアを除いた東京23区を中心に埼玉(京浜東北線の西側)から横浜辺りまでプロットされている。
300番台は東京23区の下町エリアを中心に埼玉(京浜東北線の東側)から千葉市辺りまで。
1000番以降は見ての通り。

ちなみに、画像からはカットしたけど北海道や沖縄にも数件プロットされている。

前にアプリのバグかもしれないと書いたセルIDだけど、もしかするとフェムトセル基地局のものかもしれない。
64000番及び近辺の値だけど、全国に数件存在する様に見える。

ただ、前に書いたように座標データが小数点2桁(0.01度)しかないので、北緯35℃近辺だと経度で900m、緯度で1100m程度の間隔のタイル状にしかプロットされない。
MLSの座標の決め方は知らないけど、実際の位置とは1q四方の範囲で異なっているって事?

1qを近いとみるか遠いとみるかは人によって異なると思うけど、実際の楽天の基地局の設置状況や測定地点での受信状況を見る限りは、仮に今の条件でプロットされても殆ど意味をなさない気がする。

Network Cell Infoでも測定データをMLSに提供する(別アプリ経由?)ことは可能みたいだけど、意味の無いデータになるなら無駄だよね。

2020/12/21 11:58  [2048-130]   

とりあえず自宅から半径3qの範囲の稼働している基地局はほぼ全て発見した。
ほぼと書いたのは数地点で検出したセルIDが残っているから。
でも、それはたぶんフェムトセル基地局(楽天Casa)のものだと思う。

最近は3qの範囲外の隣の市まで行ってるけど、結構苦労している。
道がよく分からないのもあるけど、高層の建物が多くて、単純に受信強度だけ見てても発信地が推測できないから。

単に接続するだけなら-100〜-110dBm程度あれば良いみたいで、この範囲が結構広い。
しかも、ビルの隙間や反射もあるのか、飛び地があったりする。
基地局が見つかった後で分かることだけど、時々考えられないくらい遠方(5q程度)で受信記録が残ってる。

感覚的には-90とか-80台になれば基地局が近いと思えるけど、実際にはそうでもない。
建物等の影響なのか、突然全く別の基地局の電波を拾ったりもするし、受信しているセルIDをよく見て判断しないと駄目。

1基地局で3セル(アンテナ)が普通なので、連続した3つのセルIDが発見できれば、それぞれの検出エリアから中心点を推定は出来る。
最後は運かも、気づくといきなり-60dBmとかで見上げると基地局があったりするので。

現状の楽天はデータ通信回線としてはありだと思う。
比較対象はWiMAXだけど。
楽天もWiMAXも建物内とか郊外とかは結構圏外が多い。

まあ、楽天は基地局整備を始めてから短いので仕方ないと思うけど、WiMAXは4万局も整備してて今の状況だから。

エリア外での利用が多いケースや通話用だと、今のままでは厳しいと思う。
でも、圏内の場所で固定的に利用するならWiMAXよりも安価だし、ある程度の強度のエリアなら上り速度もWiMAXより速い。

auを除く既存キャリアが2980円で攻勢を掛けてきたのは少し驚いた。
auは系列のUQがあるから単純に安価なプランは出せなかった気がする。

楽天も当面はUQやソフトバンクAirのシェアを奪うことは可能だと思うけど、それだけで事業として成立するのかな。

2020/12/25 13:15  [2048-131]   

基地局探しをするツールは色々あるみたいで、ググってて気づいた。
Network Cell InfoのログはセルIDは出力されているけど、基地局(eNB)IDが無い。
マニュアル見直すとPROバージョン(サブスク)では提供されているらしい。

画面には表示されているので、単に課金狙い?
良いアプリだと思ってたけど、一気に冷めた。

まあ足で探せる範囲なら無くても困らないけど、eNBが分かった方が絶対良い。
eNBだけの為にスクショ取るのも面倒だ。

少し確認した範囲ではTower CollectorというアプリならログにeNBがありそうなので、少し使い勝手を確認してみようと思う。
画面とかは面白みが無いけど。



2021/1/2 10:42  [2048-132]   

Tower Collectorを使ってみたけど、単に記録するだけのアプリらしい。
使い方が悪いのかもしれないけど、Network Cell Infoの様にマップ上で受信強度が分からない。
このアプリでは画面確認しながら基地局探しはできない。

仕方ないので両方のアプリを起動し、Tower Collectorはバックグラウンド動作にしてみた。
でも、記録はまばらになったり、止まったりする。
eNBがわかれば良いので、時々フロントにして記録って感じで使ってみた。

帰宅後に記録をPCに吸い出して、eNBとセルIDの関係を確認した。
ただ、Tower Collectorのサイトには先人が調査したデータがあるので、わざわざアプリで確認しなくても良い気がする。

前に書いたように、楽天の基地局(物理的な設置場所)にはセルが3個ある。
でも、同一のeNBIDのセルは3個以上存在する。
要するに物理的には複数の基地局が同一IDになっているって事。

Tower Collectorは同一eNBIDの記録から基地局位置を推定しているらしい。
本来は別の場所にある基地局を同一に扱うので、当然推定位置には何も存在しない。

結局、正しい位置は足で探すしかないみたいだ。

2021/1/5 01:16  [2048-133]   

いつの間にか、自宅で別の基地局(セル)に接続するようになった。
どこかの基地局が稼働したらしい。

でも、強度は今までの2ヶ所よりは若干強い程度。
最寄り基地局ならもっと強くて良いはず。
たぶん、今までの局より若干条件(距離と途中の障害物)が良さそうなもう一つの未稼働局だと思う。

変動するけど今までのセルも含めて常時3〜5セルを認識している感じ。
それは良いのだけど、万一、最寄り局だったとしたら、自宅回線としては厳しいかな…

2021/1/7 23:48  [2048-134]   

昨日から稼働したセルの所在地を確認。
予想通り最寄りとは違う方だったので、少しほっとした。

現状で3ヶ所の基地局からの電波を受信可能だけど、こんな感じ。
・距離1.1qの5階建ての建物屋上にある基地局で、間に7〜9階建ての建物が数軒
・距離940mの高度差が-15m程度の場所のコンクリート柱の基地局で、間に森や住宅地
・距離810mで高度差無しの場所のコンクリート柱の基地局で、間に大きな建物は無い

最初の2ヶ所は-110dBm前後、最後の1ヶ所は-104dBm程度

最寄り基地局は高度差無しで距離240mのコンクリート柱で、間には大きな建物は無い。
たぶん、-80dBm程度は期待できると思うのだけど、どうだろうか。

2021/1/9 00:00  [2048-135]   

アプリで近隣セルの情報を見ていたら、ときどき未確認のPCIが出現することに気づいた。

早速探索に出掛けたら2.2qも先に稼働している基地局を発見。
基地局の設置場所の高度は自宅より少しだけ高く、途中の殆どは低地だからかもしれない。

帰りに別の新たな基地局と、以前は未稼働だった基地局の稼働も確認。
わが生活圏内では楽天はかなり頑張っているように見える。

市内の確認済み基地局数は総務省が公開している認可数より多い。
地図上にプロットしてみるとまだ未発見と思われるエリアもあるから、最終的には現在の認可数の2倍以上になりそう。
認可数は公開までにタイムラグがあるのだと思うけど、他の地域はどうなのだろう。

2021/1/12 10:13  [2048-136]   

MLSデータの差分(ファイルが小さい)を確認してみたら、座標は細かく設定されてる。
以前確認したフルデータはEXCELで開けなかったので、LibreOfficeで抽出・分割したのだけど、それがいけなかったらしい。

でも、自分でやらなくても先人が情報公開(しかも随時更新)してくれてるので、ありがたく利用させて貰う。
ただ、自分の行動範囲はほぼ空白地帯だけど。

ところで、Network Cell Infoで取得したログを確認してたら、新たなセル情報が記録されている場所があったり、自宅でも数日前から近隣セルに未確認の物理セルIDが時々出現するのだけど、探しに行きたい衝動を抑えてる。

2021/1/22 12:04  [2048-137]   

念願だった最寄りの基地局が稼働し始めた。

でも、基地局の状態をよく見ると自宅は2つのアンテナの中間方向らしい。
実際に自宅ではほぼ同程度の強度で2つのアンテナからの電波を検出できる。

以前は窓際がベストポジションだったけど、現在は確認した範囲では大きな差が無い。
屋内では概ね-90dBm前後(悪くても-100未満)で受信できている。
但し、速度測定してみると今までのベストポジションでは微妙に遅いので場所の変更が必要なようだ。

速度は下りで40Mbps程度は出ているみたいなので、実用上は問題は無さそう。
WiMAXと違って上りも30Mbps以上と高速だけど、今の利用なら無意味な速さだ。

2021/2/13 10:54  [2048-138]   



最近はCMやニュースでも目にする事が増えてます。
価格の掲示板でも5Gを意識した発言は散見されるけど、イメージが先行しすぎてる気がします。

5Gの前に…
例示して悪いですが、ソフトバンクAirって一部ユーザを除くと評判が良くないのは歴然としています。
レビューでもかなりの低評価になってますが、何が悪いのかを分かっている人は少ない気がします。

かなり単純化すると、高評価の人は運良く受信環境が良くて、低評価の人は悪いって事だと思います。
まあ、こう書くと当たり前だろってなりますが、ソフトバンクだって対策(主に基地局設置)をサボっている訳じゃ無いと思います。

実際に街を歩くとソフトバンクの小型基地局(ポール上や建物屋上のオムニアンテナ)は多数見つかり、他のキャリアの比じゃ無いです。

なのに、何故受信環境が改善されないのでしょうか?
それは建物などの障害物で電波が減衰しているからだと思います。

少し話は変わりますが、今の携帯電話(スマホ)で受信環境の問題が起きにくいのは利用可能な周波数帯(バンド)が違うからだと思います。

少し(かなり)前のソフトバンクは繋がりにくいキャリアとして有名だったと思いますが、プラチナバンドを獲得してからは大幅に改善しているはずです。
獲得前に利用できたバンドはメインが1(2.1GHz帯)でサブが11(1.5GHz帯)って感じだったと思います。

Airで利用可能なバンドはモデルによって差はありますが、無印と2はバンド41(2.5GHz帯)で、3と4は41に加えてバンド42(3.5GHz帯)とバンド1(2.1GHz帯)が使えます。

要するに3と4でも昔の携帯電話が繋がりにくかった状況とほぼ同じバンドしか使えないって事です。

そして、もし建物などの障害物が無いとしても電波は減衰します。
それは距離の二乗と周波数の二乗に比例します。

例えば、ソフトバンクの場合で考えてみます。
プラチナバンド(バンド8)は900MHz(0.9GHz)帯でバンド1は2.1GHzとして計算してみます。
(2.1/0.9)~2=5.4となります。

単純化する為に電波強度を1〜5で表現可能だったとして、バンド8で強度5だった場所はバンド1では強度1を少し下回るって事になります。
そして距離が2倍の位置なら周波数が同じでも電波強度は1/4になるので、バンド1はバンド8の1/20以下の強度でしか受信できない事になります。

実際にはこれに加えて障害物があるので、別の特性も考える必要があります。

波は波長が長い(周波数が低い)ほど回折特性(波が障害物の影の部分に回込む現象)が高いので伝わりやすくなります。
電波も波なので、仮(前述の減衰を無視して)に同じ強度の電波が届くはずの位置だったとしても、途中に障害物が存在するとより周波数の高い波は届きにくくなります。

結論としては周波数の高い電波は減衰しやすく、障害物の影響を受けやすいって事です。
長く書いた意味なかったかも…(^_^;)

5Gの前に一旦休憩…

2020/1/7 15:40  [2048-114]   

では、そもそも5Gって何?ですが…

総務省などの資料を見ると3つの特長で説明されているみたいです。

1.超高速
 最高伝送速度10Gbps (現行LTEの100倍)

2.多数同時接続
 100万台/kuの接続機器数(現行LTEの100倍)

3.超低遅延(リアルタイム)
 1ミリ秒程度の遅延(現行LTEの1/10)
 
分かりやすく(わざとらしく?)LTEとの比較までしているので、数値だけ見れば凄く良いもの様な感じはしますね。

でも…

1.超高速

10GbpsでLTEの100倍なら、LTEは100Mbpsって事だと思います。
これって実効速度(実際に確認出来る値)なのでしょうか?
キャリア各社とも理論値ならもっと高速な値を謳っていると思います。

一方で5Gの10Gbpsは実効速度?それとも理論値???
まさか実効速度と理論値を比較しているなんて事は無いですよね。

どちらにしても、そんな高速な通信が必要な場面って個人レベルでは不要ですよね。

2.多数同時接続

100万台/kuってイメージがわかないので、通分?してみます。
1uだと1台って事で良いのかな。

例えば床面積が100uの家なら100台の端末が同時接続可能って事になります。
全ての家電が同時接続したとしても100台は必要ないと思います。

一方で現行LTEが1/100なら同時接続1台って事になります。
単身世帯を除けば1家庭で接続端末が1台しかケースは少ないでしょうし、実際にそれ以上ある方が多いと思います。
実際には色々な方式で擬似的に同時接続している様に見えるのだと思いますが、それで問題は起きていないです(たぶん)。

問題が起きるとしたら災害時とかに一斉に利用するケースだと思いますが、そもそも災害時にインフラが健在である保証があるのでしょうか?
それ以外だとイベント会場とかで多くの人が集まるケースかも知れないですが、現状で問題って起きているのでしょうか?

3.超低遅延

これが、どの部分を言っているのかよく分かりません。。
回線部分だけだとしたら、意味ある数値なのでしょうか?

実際には通信先のインフラや処理能力による遅延の方が大きいはずです。
だから回線部分の遅延が10ミリ秒から1ミリ秒になっても全体ではあまり意味が無いと思います。

5Gに合わせてバックボーンも増強すれば良いって事なのかもしれないですが、それでも殆どのサービスでは意味が無い気がします。
CMで取り上げている様にスポーツ観戦がリアルタイムに可能って事なのでしょうか。
でも現地観戦には劣るし、普通の人はTV放送や現行の動画配信サービスで十分な気もします。

結局、普通の人にはメリットがよく分からないサービスにいくら投資できますか?って話にしか見えません。

まあ、キャリア側が頑張って投資するのは構いませんが、利用者の負担増だけは勘弁して欲しいです。
スマホ等の受信機も当面は高いと思いますが、普及すればコスト面のデメリットは減ってくるとは思います。

私は当面は様子見するので、イノベータやアーリー○○の人たちに頑張って欲しいです。

でも、最大の問題はソフトバンクAir以上に受信環境に依存するはずって事を皆さん分かっているのでしょうか?

再度休憩…

2020/1/7 16:17  [2048-115]   

日本で5Gに割り当てられている周波数帯はキャリアによって多少差はありますが、3.7,4.5,28GHz帯の3つです。

全て現行LTEよりも、当然ソフトバンクAirよりも高周波数帯です。
なので、今のままなら5Gが万人に快適に利用できるはずがないと思います。
たぶん、キャリア各社は基地局整備をしているのだとは思うけど…

前述の様に電波は周波数の二乗に比例して減衰します。

現行LTEのバンド1(2.1GHz帯)と比較して考えると28GHzは約13倍です。
従って、計算上の電波の到達距離は約1/170になると思います。
単純に面で考えると170の二乗分の基地局が無いとカバーしきれないはずですが、現実的な値じゃ無いですね。

なので、出力を大きくしたり、人がいないエリアは除外するって事になるのか、そもそも28GHz帯は限定的な利用なのだと思います。

一番現行LTEに近い3.7GHz帯の場合で考えると1.76倍なので、約3倍の基地局が必要になる計算になります。
28GHz帯と比べれば現実味のある数値に見えます。

でも、プラチナバンドに未対応のソフトバンクAirでさえ圏外や安定的な通信が出来ないケースが多いのに5Gで解決できるとは思えません。

加えて障害物の問題は更に厄介です。
単純に言うと建物内や別の構造物の陰になるケースなどで、キャリアが基地局設置を頑張っても解決不能な問題だと思います。

と、思って調べてみると、ローカル5Gなんて言葉がありました。
でも、それならWi-Fiでも良いのでは?って単純に思ってしまいます。
Wi-Fi6なんて規格の機器も既に市場に出始めているし、それじゃ駄目なのでしょうか?

よく見るとローカル5Gでも免許が必要みたいだから個人じゃ無理ですね。
だとすると、基地局が近いとか基地局と受信機の間に障害物が少ないとか、かなり恵まれた環境じゃ無い限りは自宅内では5Gは使えないって気もします。

それよりも東京中心部や重要施設内などを除くと普及までにはかなりの時間が掛かりそうですね。
個人的には5Gより4Gの利用料が安くなる方がありがたいですけど。

2020/1/7 17:32  [2048-116]   



久しぶりに…

その1(いくつまで続くか分かりませんが)

Google Homeの掲示板に在宅を条件に指定した時刻にスマートリモコンを動作させたいとの書込がありました。

Google Homeアプリのスケジュール設定では曜日や時刻指定は可能ですが現在地は利用できません。
普通に考えてGoogle Homeが存在する場所で実行なので当然ですけど。

IFTTTを利用すれば位置情報は入手可能ですが、指定エリアへの入出をトリガーにした動作しか出来ません。
常に同じ場所にいた場合にはトリガーは発動しないので利用できません。

基本的にスマホレベルで認識可能な位置情報には精度の問題があると思います。
実際の位置と検出位置のズレは当然としても、検出位置には多少ブレがあり本当の移動との区別ができません。
なので、IFTTTでもピンポイントや狭い範囲でのエリア指定はできない様になっています。

位置情報の精度については考えても解決しないので、とりあえず無視して考えます。

位置情報を認識する方法を考えてみました。

最初に考えたのは、Google Apps Scriptを利用しGoogle Maps APIで位置情報を取得する事です。

単純に考えるとスクリプトを常時動作させれば良い気もしますが、状態が変化しない場合でも無駄に動作しているって事になります。
スマホ上で動作しているならバッテリーが心配です。

結局、何かをトリガーにしてスクリプトを起動する方が合理的だと考えを改めました。
IFTTTで出来る範囲は最大限活用する事にしました。

IFTTTで出来るのは指定したエリアへの入出をトリガーとする事です。
このトリガーで入なら在宅、出なら不在であると記録しておけば良いと考えました。

記録先は何でも良いのですが、最終目的は指定した時刻のリモコン動作なので、時刻の記録も可能なカレンダーを利用する事にします。
単純に予定を記録するだけならIFTTTにはカレンダーへ記録するサービスが存在します。

なので、IFにはLocation、thatにはGoogle Calendarを指定します。

Locationの選択肢は以下の3種類ですが、単純に記述の通りです。
You enter an area
You exit an area
You enter or exit an area

Google Calendarには以下の2種類ですが、細かい時間指定は2番目の方しか出来ません。
Quick add event
Create a detailed event

今回は自宅にいるときの予定なので、以下のようにします。
IF
You enter an area
THEN
Create a detailed event

詳細は割愛しますが、実際に設定して記録できる事を確認しました。

この方法の利点と欠点は、以下の通りです。

利点
・カレンダーを見れば予定が一目瞭然
・カレンダーをトリガーとしたアプレットが利用可能

欠点
・カレンダーへの新規登録しか出来ない
・予定を自動記入する期間(当日だけか否か)が決められない?



2019/6/18 15:06  [2048-108]   

その1(続き)

IFTTTだけでは限界があるので、Googleカレンダーへのアクセス部分をGASで記述する事にしました。

準備としてはGASの開発環境…といってもChromeにアドインを加えるだけですが。
GAS自体はJAVA Scriptベースなので、その知識が多少は必要かも知れません。

エディタで記述して、デバッグまたは実行しながら確認出来ます。
今回はGoogleカレンダーへのアクセスなのでGASからのアクセスを許諾する必要があります。
まあ、IFTTTの場合も同じですけど。

新規登録は必定な項目をセットした上でcreateEvent、削除はdeleteEventで可能です。

流れとしては以下の通りです。

・新規登録
 getCalendarByIdメソッドでカレンダーを指定
 タイトル、開始時間、終了時間をセットしてcreateEventメソッドで予定書き込み

・削除
 getCalendarByIdメソッドでカレンダーを指定
 getEventsForDayメソッドで今日の予定を取得
 予定数分、以下の処理を繰り返す
  タイトル、開始時間、終了時間を取得
  タイトルが指定したものならdeleteEventで予定を削除

纏めて書くと簡単ですが、初めての利用なので試行錯誤してやっとって感じです。

記述したGASはエディタから実行できますが、実際の利用はIFTTTから呼ぶ必要があるのでWebアプリケーション化します。
それをIFTTTのWebhooksで指定して実行すれば連携完了です。

2019/6/18 15:27  [2048-109]   

試行錯誤しながら作成したのが下記です。

新規追加(18時に「帰宅」を記入)

function create_event(){

//カレンダーIDを取得
var myCalendar = CalendarApp.getCalend
arById('xxxxxx@gmail.com');

//予定名称を指定
var title = '帰宅'

//予定の開始時間を指定
//現在の日時を取得
var start_time = new Date();
var end_time = new Date();

//時間を変更
start_time.setHours(18);
start_time.setMinutes(00);
start_time.setSeconds(00);

//時間を変更
end_time.setHours(19);
end_time.setMinutes(00);
end_time.setSeconds(00);

//指定したタイトルと開始・終了時間で予定登録
myCalendar.createEvent(title, start_ti
me, end_time);
}

削除(タイトル「帰宅」があれば削除)

function delete_event(){

//カレンダーIDを取得
var myCalendar = CalendarApp.getCalend
arById('xxxxxx@gmail.com');

 //本日のイベントを取得
var myEvents=myCalendar.getEventsForDa
y(new Date());

//イベント数の取得
var count_Events=myEvents.length;

//
for(i=0;i<count_Events;i++){
var title=myEvents[i].getTitle();
var start_time=myEvents[i].getStartT
ime();
var end_time=myEvents[i].getEndTime(
);

//指定したタイトルを削除
if(title=='帰宅'){

//指定したタイトルと開始時間で予定削除
myEvents[i].deleteEvent();
}
}
}

削除で悩んで後で気づきましたが、作成時も同様に検索すれば多重登録は防げますね。

また、今のままだと予定はソース内に書いているので、複数予定だと大変な事になるし、単純な時間変更等でも大事になります。

なので、記入する内容一覧は別途スプレッドシートに記入し、それを参照して追加や削除をする事にします。
スプレッドシートに関する記述を学ばないと駄目ですが、EXCEL VBAの知識は役に立つのかな…

2019/6/19 07:59  [2048-110]   

その2

予定を記入してあるスプレッドシートを参照してGoogleカレンダーへ転記する事が出来ました。

今まではGoogleドライブに独立したスクリプトを保存していたのですが、今回からは使用するスプレッドシートに付随する形で作成する事にしました。

最初は独立したスクリプトからスプレッドシートを参照すれば良いと考えたのですが、添付形式の方が指定が簡単だと判明したので方針転換しました。

最初に用意したシートの形式は、こんな感じ
タイトル,開始時間,終了時間
機器1,18,19
機器2,20,21
機器3,9,10

作成したスクリプトは3種類
1.カレンダーに予定を転記する
2.カレンダーから予定を削除する
3.前日のカレンダーを参照して予定があれば、当日にも予定を転記する

1は帰宅時、2は外出時、3は在宅時を想定した動作です。

それぞれはWebアプリケーション化して、IFTTTからWebhooksで呼び出します。
1.Locationで指定エリア内に入った時にカレンダーに予定を転記
2.Locationで指定エリア外に出た時にカレンダーから予定を削除
3.Date & Timeで毎日0時になった時に前日のカレンダーを参照して予定があれば当日も予定を転記

これで基本的な動作は記述できました。
細かい点では帰宅時にはカレンダーの予定を確認し、多重登録を回避しました。
これは、1または2の位置の移動が正常に認識できないケース(実際に発生するかどうかは?)への対応です。

現状の課題としては以下の通り
・毎日0時の実行に関しては位置情報と違い必ず実行されるものとして多重登録のチェックはしていない。
 → 多分問題なし
・平日と休日、曜日などの区別はしていない。
 → これは面倒そうなので当面は無視

他にもありそうな気もしますが、とりあえず…



2019/6/26 01:21  [2048-111]   

暫く毎日の動作状況を確認してみました。
意図した動作をする事は確認できましたが、課題が分かりました。

最大の課題はIFTTTのタイムラグです。
最大?15分程度の遅延が発生する可能性がある…というのが仕様らしいです。

確かに、エリア移動時にも時刻指定でもかなり遅れる事は分かりました。
実際に動作時にカレンダー記入に加えて動作時刻を記載したメール送信をしてみました。

結果は、殆どは30秒から数分程度でしたが、最短で15秒程度で最長で26分程度(1回だけ)でした。
全てがIFTTTの問題とは限りませんが、動作時刻に意味がある様なケース(例えば帰宅直後に動作)の利用には無理があります。

もう一つの課題はLocationのエリア設定範囲です。
アプリ上ではかなり広範囲しか指定できませんが、PCのブラウザ上では一軒家を囲む程度の指定が可能です。

ただ、本当に指定範囲を超えた場合に動作しているのか判断できませんでした。
なぜなら、前述の遅延がLocationでも発生するからです。
エリア外に出る際は動作確認できた時には指定範囲の遙か彼方って感じです。

ちなみに、GAS自体は動作指示から結果確認出来るまでは長くて数秒でした。

結論としては、IFTTTについては遅延が許容できる範囲で利用するしかないと思います。
より即応性を求めたいなら別の方法を考えるしかありません。

流行?のラズパイでそれが可能なのか試してみようか思案中。

2019/7/10 09:54  [2048-112]   

設定したまましばらくの動作状況を確認してました。

結論としてはIFTTTのLocationの動作はタイムラグだけじゃ無く不安定だと分かりました。
正確な位置情報の取得手段としては使えません。

具体的には、以下の事象が数回ありました。
・移動時に明らかに指定範囲からExitしてるのに動作しない
・移動していない時(就寝中)にExitしてEnterした形跡がある

また、Exitは未動作でも同範囲を指定したEnterは動作するなど、単純に境界を越えただけで判断されている訳じゃ無さそうです。
判断条件が分からないと使えないです。

2019/7/23 08:01  [2048-113]   



2ヶ月前に車載用に購入Amazon Echo Dotを購入しました。
でも、移動中の不安定なモバイル回線だと満足に使えませんでした。

結局持ち出すのが面倒になり、自宅で放置状態になりました。
接続設定はモバイルルータのままで、時々Google Homeとの応答の違いを確認する程度の存在でした。

今回、別のスマートリモコンを購入したので、Echoも自宅ネットワークの仲間入りをさせてあげる事にしました。
その際に、少し?苦労しました。

仕様ではWi-Fiはデュアルバンド対応なのは知っていたので、迷いも無く5GHz帯に接続する事にしました。
自宅では基本は静的IPを使用し、ステルス&MACアドレスフィルタリングになっています。

設定はiPhoneを使用し、当然MACアドレスフィルタリングは解除した状態で実施しました。
結果は、何度トライしても失敗。

調べてみたら、利用可能な5GHz帯に制限があるらしい事が判明。
まず、W52しか対応していない事。
 自宅もW52利用なので、これは問題ありません。
使用可能チャネルは、36,40,44,48chのみである事。
 これもW52自体の仕様なので問題は無いはずです。
 
自宅の5GHzは802.11acにも対応していて、クワッドチャネル有効で設定してあります。
普通の接続端末なら、自身の接続可能な仕様で接続できるはずです。
でも、Echoは違うみたいで、念の為ステルスも解除して、何度もリトライしても駄目でした。

諦めて、2.4GHz帯に接続する事にしました。
5GHzと同様にMACアドレスフィルタリングは解除した状態で設定開始。
でも、何故か接続できません。

仕方なく、ステルスも解除して設定すると、問題無く完了。
安心して、ステルスだけ有効に戻しました。

暫くしてから、「Alexa〜」と呼びかけると、赤いリングが回転…
まさか、ステルスに未対応???と調べたら、気になる情報を発見しました。

iOS系端末アプリで設定すると駄目らしい。
本当?とは思いましたが、ステルス状態のままでAndroidから再度設定。
結果、問題無く完了。本当らしいです。

もし、iOS端末しか持ってなかったら使えないの烙印押して終わりになる可能性もありますね。
未確認ですが、Android端末を使えば5GHz帯でも問題無いかも知れません。

最後にMACアドレスのリストにEchoのアドレスを追加して完了しました。

ただ、一つだけ気に入らない事があります。
それは、EchoがPingに応答してくれない事です。
仕様っぽいですがトラブル時には生存確認の基本手段なので困ります。

2018/8/17 07:12  [2048-106]   

Android端末で再設定してみました。
5GHz帯でステルス&MACアドレスフィルタリング(解除対象に登録)状態でも問題無く完了しました。

結論としては、設定はAndroid端末でやるべきと言う事みたいです。

2018/8/17 11:12  [2048-107]   



無線LANの電波が乱立しているけど、ふと「そもそもの仕組みって?」と思いました。
周波数帯の種類や接続手順等は分かりますが、もっと根本的な部分です。

少しずつ調べて記録しておこうと思います…気まぐれですが。

色々調べると大きくは2つの手順で接続される事がわかりました。
1.接続できる相手を探す
2.決められた手順で接続する

これって、以前g07に関連してログを調べた時に確認した様な気がします。

1については大きく2つの方法がある様です。
a.APが出す信号を受信する
b.端末がAPを探す為に問い合わせる

2については基本的には下記の手順になるはずです。
認証 → 接続 → データ交換

まずは1のaについて

APは自分の存在を定期的に周辺に知らせます。
知らせる電波のことをビーコンと言います。

通常の設定では、ビーコンにはSSIDやサポートしている速度やセキュリティなど通信に必要な情報が含まれます。
端末ではこの情報を受け取って、サポートする通信手順に合致するSSIDを一覧表示します。
自宅内では少数だと思いますが、屋外では大量のSSIDが表示されるのが一般的です。

この流れをパッシブスキャンと言います。
潜水艦等のソナーと同じ名前ですね。後述しますがアクティブスキャンもあります。

この時端末に保存されているSSIDの中で合致する設定があり、かつ自動接続になっている場合はそのAPに対して接続動作が行われます。
複数の合致がある場合は原則的には一番電波強度の強いAPが選択されるはずですが、端末の仕様等で必ずしもそうならない時があります。

1のbはアクティブスキャンの事です。

パッシブスキャンによっても一定時間ビーコンが検知できない場合や、ステルスAPに対して接続を行いたい場合に動作します。
端末からAPに対するプローブ要求とAPから端末へのプローブ応答から構成されます。

プローブ要求には端末が接続したいSSID情報が含まれ、同じSSIDを持つAPがプローブ応答します。
当然ですが、端末がスマホの様な移動体の場合は同じSSIDを持つAPが応答できない(存在しない)ケースが多くなります。
相手がいないのに、このSSIDのAPいますか?と探し続ける感じですね。

よくステルスは危険だから設定しない方が良いと言う人がいますが、これが原因です。
でも、ステルスで無くても端末が接続したい相手が見つからないとアクティブスキャンするなら、同じ事の様な気もしますが…

まずは、ステルスの場合に何が違うのか?ですが、単にビーコンが違うだけです。
ビーコンにSSIDが含まれないか、ビーコンそのものを出さない場合もあるらしいです。
曖昧に書いたのは、自分の環境下ではステルス設定したAPはSSIDを含まないビーコンを出しているからです。
端末にとってはビーコンを出さないAPもビーコンが見つからないケースと同じです。

ビーコンは電波ですので、その電波を検出可能な受信器(無線LANじゃなくても)なら確認可能です。
通常の無線LAN子機でもSSIDを除くMACアドレスやサポートする通信情報は検知できます。
ただ、それを表示するかどうかは端末の仕様次第です。

最初は、ビーコンを検知できるなら自分が過去に接続した情報と比較してSSIDを除いて同じならプローブ要求すれば良いのでは?と思いました。
でも、よく考えるとネットワークによっては同一SSIDを複数のAPが持つケースがあるので、比較結果で同一だけじゃ駄目と分かりました。

結局、ビーコンの有無や一致に関わらず、アクティブスキャンするしか無い事になります。

2018/5/9 20:02  [2048-95]   

1のプロセスでお互いの存在確認が取れたら2の接続プロセスに進みます。

大昔のルータは初期状態で誰でも接続可能な状態で出荷されていたので、1が終われば簡単に2も終了してました。
しかし、現在はほぼ初期状態では何らかの認証が必要です。
但し、SSIDが同じだったり、機器名等とMACアドレスの組合せで変化を付けていてもパスワードは同じだったりでザル状態のも多いです。
なので、必ず初期状態からは変更するのが鉄則だと思います。

と、ここまで調べていてSSIDとひとくくりに書くのは正確では無い事が分かりました。
この前にアクティブスキャンの際に「同一SSIDを複数のAPが持つケース…」と書きましたが、これがまさにESSIDの事でした。

元々のSSIDは一つのAPに対して設定されるもので、それを拡張して複数のAPで使用出来る様にしたのがESSIDって事みたいです。
従って、現状では正確に表現するならESSIDと書くのが正解ですね。

今回は単純に単一のAPとして考えます。

話を戻します。

認証の手順は利用する暗号化方式によって異なるみたいです。
現状では殆どがWPA2を採用していると思うので、そのケースを調べます。

下記の様な手順のようです。
T.アソシエーション処理
U.PMKの共有
V.PTKの生成
W.GTKの生成

T.アソシエーション処理

簡単に書くと、これから行う認証方式や手順の確認って感じです。
ここでは認証自体が行われる訳では無いので、接続しようとする全ての端末が処理を完了できます。

以下面倒なので、手動で設定するパスキー等はすべてパスと略します。

通信に本当に使用される認証キー自体はこの後のプロセスで生成されるのですが、それは設定されたパスだけでなく乱数や機器固有情報等から自動生成されるって事みたいです。

蛇足ですが、今では殆ど使用されないWEPはこの部分でお互いが持つパスを使用して暗号化し通信するので、悪意ある第三者がその内容からパスを復元する事も可能みたいです。

U.PMKの共有

PMKとはPairwise Master Keyの略で通信で使用するマスターキーです。
WPA2では通信によってキーが違うらしいですが、それを生成する元となるキーの事です。
最初にそれぞれに設定されているパスが同じかどうかの確認はするみたいですが、実際の通信ではPMKから生成されたキーを使うらしいので、セキュリティレベルは上がるって事でしょうか?

V.PTKの生成 及び W.GTKの生成

PTKとはPairwise Transient Keyの略で、ユニキャスト(1対1)通信で使用するキーです。
共有されているPMKを元にして決められた手順で生成されます。

GTKとはGroup Transient Keyの略でマルチキャストやブロードキャスト(1対多)通信で使用するキーです。
PTKを元にして生成されるらしいです。

キーの生成と交換が完了するまでには4ウェイハンドシェイク(2往復)の通信が行われます。

具体的には

1.APから端末
 ANonce(Authenticator Nonce:APで生成されるランダム文字列)を送信
 受信した端末はANonceとSNonce(Supplicant Nonce:端末で生成したランダム文字列)からPTKを生成
2.端末からAP
 SNonceとMIC(Message Integrity Check:メッセージ完全性コード)を含む情報を送信
 受信したAPはANonceとSNonceからPTKを生成し、端末から送信されたMICを検証
3.APから端末
 GTKを生成しMICを含む情報とともに送信
4.端末からAP
 端末は一時キーをインストールし、インストールした事をAPに通知
 APも一時キーをインストール(※文献によっては3でインストールするとの記述もあり、どちらか不明)

先日発見されたWPA2の脆弱性は3番目のAPから端末へのキーの通知に対して端末が応答出来ないと、3番目の通知を再送するのですが、その際にNonceやカウンタがリセットされる事が原因のようです。
悪意ある第三者が強制的にリセットさせて、APを偽装して意図的に作られた文字列をベースにして、キー生成を最初から行う事が可能って感じでしょうか?

もし、そうだとするとAPが一時キーをインストールするのは最後が正しいかも知れないですね。

2018/5/13 16:56  [2048-96]   

ところで、ESSIDをステルスにすることの是非ですが…

自分は可能な限りステルス設定をしてMACアドレスフィルタを掛けます。

確かに、不必要な場所で接続先を探す動作はセキュリティ的には良くないとは思います。
でも、それは一定レベル以上の技術を持って他人を攻撃しようという悪意(好奇心?)ある人がいる前提です。

MACアドレスも偽装可能だからフィルタ掛けても意味ないという人もいます。
確かに、その通りですが、それも悪意ある人がいる前提です。

もし、ある家庭のAPを攻撃しようとするなら、そのAPの電波が到達する範囲に入る必要があります。
そして、セキュリティの脆弱な部分を探して攻撃方法を考える事になります。
そこまでの労力を掛け、発見されるリスクを負ってまで攻撃するでしょうか?

普通に考えて、明らかに労力やリスクに見合う何かの存在を確信しているか、攻撃対象に特別な感情を持っていないと実行はしないと思います。

それよりも、ステルス設定等は行わずいつでもAPの存在を主張し続けのはどうなのでしょうか?
田舎の一軒家でない限りは、APの電波は屋外や近隣の室内まで届きます。
もし、そこに技術と悪意(または好奇心)を持った隣人がいたなら…

無線LAN普及の初期の頃はAPのデフォルトはセキュリティ無しだったので、誰でも接続可能でした。
現状はそこまでの無防備な状態では無いですが、それに類する状態の方が危ない気がします。

2018/5/18 10:19  [2048-97]   



表の掲示板で中継器を使うと頻繁に通信が途切れるとの投稿があり、電波干渉を疑っていました。
でも、投稿された場所が少し?違う所で、かつ細かく確認等すると長くなるので、専用場所として縁側の設置をお願いしました。

今のところ縁側は設置されていないので、とりあえずここにメモしておきます。


最初に初歩の解説。

無線LANには2.4GHz帯と5GHz帯の2種類の周波数帯が利用可能です。
但し、一部の機器は一方しか対応していない場合もあるので要注意です。

電波は周波数が高い程、直進性が強く、障害物の影響を受けやすいと言う特性があります。
場合によっては5GHz帯は隣室で安定した通信が出来ない場合もあります。

この特性から、だから2.4GHz帯を使うべきでスマホ等も2.4GHz帯だけの対応で構わないとする主張する人もいますが、全く賛同できません。
個人的には可能な限り5GHz帯も利用可能な機器を選定すべきだと思います。

何故なら5GHz帯の方が安定して高速な通信が可能だからです。
前述の隣室の離しと矛盾すると考える人も居ると思いますが、周波数帯は共有しているので単に特性だけで判断できません。

次に2.4GHz帯の解説。

この周波数帯は無線LAN以外でもアマチュア無線やISM(産業科学医療)でも使用され、コードレスホンや電子レンジ、Bluetoothでも使用されます。

無線LANに限って言えば、2401〜2495MHzが利用可能です。
但し、自由な周波数が使えるのでは無く、5MHz刻みで22MHz帯域を一つのチャネルと指定しています。

日本では1〜14チャネルですが、14は802.11bのみの対応なので、無いものだと思った方が良いです。
北米では1〜11なので、12及び13チャネルに対応していない機器があるかも知れません。

22MHzの帯域が5MHz刻みなので、当然ですが隣接するチャネル同士は殆ど重なります。
完全に干渉を避ける為には5チャネル離す必要があります。

この場合802.11g以上で設定可能なのは最大3チャネルで、下記のいずれかのパターンです。
 1,6,11
 2,7,12
 3,8,13
 
これは同じ室内で複数のAPを作る時は守った方が良いです。
4チャネル離しでも重なりは大きくないので影響も小さいとは思いますが、何とも言えません。
しかも、1チャネルから指定可能な場合を除くと同時利用可能チャネル数は5チャネル離しと同じです。

単一のAPだけで良いなら、どれを使用しても良いと言いたいですが、日本の住宅事情だと近隣や別室からの電波も拾うので、設置予定場所の電波状況を確認して使用チャネルを決めた方が良いです。

通常はチャネルの選択は自動で一番使えそうなチャネルが選択されます。
但し、前述の12〜14に割り当てられてしまった場合は接続できない端末があるかも知れません。
その場合は、意識的に使用チャネルを指定する為に手動設定する事になります。

問題は、どのチャネルが使えるのかを知る方法です。(後述)

最後に5GHz帯の解説

この周波数帯は無線LAN以外でも気象レーダをはじめとするレーダ類やISM、アマチュア無線や一部は衛星や放送でも使用されています。

無線LANに限れば5150〜5350と5470〜5725MHzが利用可能です。
チャネルが設定されているのは2.4GHzと同様ですが、設定の仕方が大きく異なります。

前半の周波数帯は5180MHzを中心に前後20MHz幅を36チャネル、後半の周波数帯は5500MHzを中心に前後20MHz幅を100チャネルとし、20MHz間隔でチャネルが設定されています。
従って、隣接チャネル間は完全に独立していて干渉はありません。
但し、何故かチャネル番号は4飛ばしです。

5150〜5350MHzでは36,40,44,48,52,56,60,64の8チャネル、5470〜5725MHzでは100,104,108,112,116,120,124,128,132,136,
140の11チャネルです。

チャネルの指定方法は2.4GHzと同じですが、チャネル間の干渉が無い事と、電波の特性で近隣の影響を受けにくいので、選択可能なチャネルが明らかに多いと言う事が分かります。
そうは言っても、同室内に複数のAPを設置する場合は当然別のチャネルを設定する必要があります。
またアパート等で壁一枚で隣家と隣接している場合や、自宅内のAPの管理者ではない場合は使用可能チャネルを知る必要があります。

ここまでが前置き…

2018/5/7 21:40  [2048-90]   

次に調べる方法

AndroidのアプリにWifi Analyzerというのがあります。
このアプリを使えば一部を除いてAPの状況が分かります。

分からないのはステルスのAP(SSID)ですが、アプリが動作するスマホ等に接続設定があれば分かります。
但し、接続中のAP以外はステルスのSSID名は表示されません。
SSID名は無くても機器が持つMACアドレスは表示されるので、自分でalias設定する事も可能です。

この動作から通信パケットを傍受している事が分かります。(まあ、他に方法無いですが…)
ステルスのAPのパケットにはSSID名が含まれていないので、表示もされないって事だと思います。

ステルス以外のAPはSSID名が表示されるので機種名まで判別可能なケースもあります。
もし、機種毎の初期値が同じで、変更せずに使ってたら怖いですね…

実際に確認すると自宅以外に近隣のAPが数多く検出されます。
もし、使用するAPと干渉するAPが存在し、かつ強度も近いなら影響を受ける可能性が高いです。

但し、そのAPが常時存在するのか?、また常時同じチャネルなのか?など条件(は時間帯等)を変えて何度か確認した方が良いと思います。
実際に、わが家の近隣では夜間には存在しないAPがあります。
たぶん、就寝時に電源を落としているのだと思います。

次はステルスAPの存在を確認したい場合はどうするか?です。
方法はいくつかあるかも知れませんが、パソコンがあるならinSSIDerと言うソフトを使うと確認できます。
Home向けはVer3迄はフリーウェアだったらしいですが、最新版Ver4はシェアウェアになってます。

探せば公式サイト以外でVer3も入手可能です。
但し、Ver3では802.11acは検知できません。
干渉の多くは2.4GHz帯で発生するので実使用上はほぼ問題ないです。
当然ですが、パソコンにWi-Fiインタフェースが必要で、対応している周波数帯のみ確認できます。

Office向けはWi-Spy(無線LAN以外の電波も検知)等も含めて2万円強で購入可能です。
面白そうだけど、玩具としては高い…

2018/5/7 23:24  [2048-91]   

パソコンのソフトでAcrylic Wi-Fi Homeと言うのを見つけました。
これなら802.11acも検出できるみたいです。

Home版はinSSIDerとほぼ同じで、ステルスを含めたAPのリストアップが可能です。
これにもPro版があって39.95米ドルみたいです。

2018/5/9 12:28  [2048-93]   

探せば類似のソフトが見つかるものですね。

Microsoft StoreにはWiFi Analyzerいうのがありました。
名前も1文字違いますが、作者はAndroidとは違います。

同じく、WiFi Commanderも有料ですが入手可能です。

StoreではないですがNetSpotというのもあります。

基本無料のソフトでも全ての機能を使う為には有料の上位版を使うしか無さそうですが、単にAP検索だけなら無料の範囲で可能です。
ただ、ソフトによって若干の検出値の違いや検出できないステルスAPがあったりするので、並べてみないと正しくない(単に多数決ですが)のは分かりません。

比較(と言っても大した項目は無いと思いますが)は気が向いたらやってみます。

2018/5/9 17:49  [2048-94]   


この掲示板は閲覧専用です(運営者のみが投稿できます)。
運営者のみ投稿可
備忘録いろいろ
備忘録いろいろをお気に入り登録
運営者:
亜都夢さん
設立日:
2017年3月2日
  • 注目度:

    112(お気に入り登録数:2件)

タグの登録はありません

該当掲示板はありません

ページの先頭へ