SFR-Meshは複数のSFR (Single Frequency Repeater) をメッシュ状に接続し通はセッションを動的に形成する新しいネットワークアーキテクチャです。

現在、開発中の新制御方式によるシステムで2026年3月より実証実験を開始し、制御技術の検証は完了いたしました。　現在将来の普及を目指してさらなる改善、及び開発を進めております。

2026年6月より、自動展開できる基地局向け設備を開発中です。　実証実験の中でHotSpot等の設定の煩雑さや遠隔地にあるSFR基地局の状態の監視などがSFR管理者に置いて負担となっていることを学びました。　より多くの方に楽しんでいただくため、また安定して末永く運用するには管理者の皆様の負担軽減も重要となり、手間や苦労が無く展開運用できる設備が大切です。　そこでネットワーク機器やネットワーク自体の取扱い作業負担軽減の為、簡単な操作で各SFR基地局固有の設定を自動展開、事犯自動キャブレーション、将来のアップデートの際は遠隔で自動更新されるシステム等を開発中です。　実現できますと去らない接続局の普及のフェーズに入れます。

はじめに

こちらのサイトにお越し下さいまして、誠にありがとうございます。　ご興味を抱いてくださり、お時間を割いて頂けましたことに大変感謝しております。

このシステムは接続の交換を処理しており、ユーザーからは見えない部分のお話が多いため難しい部分もあるかと思いますがご一読いただければ幸いです。　また、インフラとしてのシステムである以上技術うんぬんよりも裏方として、仕組みを使った使用感、楽しさ、便利さなど触れて頂いた方々の体験が最終的な評価になることも理解しております。

実用に至るまでの道のりは長くなることが予想されますが、最善を尽くす所存です。　温かく見守って頂ければありがたいです。

現在行われている実証実験とは、今回開発したLUTGを用いた透過型の制御方法が、実際に現在流通している機材で動作しているか実用となる可能性があるかを検証する作業です。　2026年5月時点で理論は成立していること、また、現在考えられる制御や体系が確立できたことは確認されました。　一方で現在一般に流通している機材やソフトでの限界点も見えてきました。

実用化、永続的な運用を実現するためには以下の課題があります。

サーバーＯＳバージョンのアップデートへの永続的な対応
接続機器の処理精度の問題
接続機器の現地制御の新規開発
接続機器の動態管理の確立
回線の管理を含めた品質の向上
インフラ維持のコストの捻出方法

今回開発したSFR-Meshの主要部分は既に対応済みですが、既存の機構にライフタイム上の限界や、開発時点で考慮されていない機能上の制限や不足が多々存在し、新規に開発して対処しSMRの性能か機能を最大限活用する必要があります。

開発並びに、現在行われている実証実験に係わるサーバー側のすべての費用は開発者個人で全額負担しております。　（SFR基地局側とサーバー接続までのコストはそれぞれの管理者負担です。）従って上記の課題がが解決されるまで、通常運用の開始は出来ない状況です。　解決には相当量の工数がかかることが見込まれておりますのでそれなりの期間を要すると見込んでおります。

下記のリンクから使い方やTGリストなどをまとめておりますので、ご一読ください。

また、もしご興味あありましたら、どのような仕組みなのかもご一読いただけますと大変ありがたいです。

SFR-Meshとは

SFR-Meshは、DMRデジタル無線で「接続したいSFRを直接呼び出して交信できる」新しい通信方式です。従来のDMRでは、決められたトークグループ（TG）に参加してそこにいる局と交信する必要がありました。しかしSFR-Meshでは、呼び出したい相手側のSFR（デジピーター）を指定するだけで、システムが自動的に回線を構築し、通話終了後には自動的に解放されます。

日本国内のDMRモードは以前より様々な実験が行われていましたが、特にハムフェア2023にてJ5RBD 加藤OMによりSFR(Single Frequency Repeater)の実験が行われたのきっかけとし、VoIPリンク研究会などの活動や、熱心なSFR基地局管理者の皆様のご尽力により近年で急速に普及が進みました。

開発のねらい

これまでも、ご自身でホットスポットやドングルなどを導入しVoIPリンクをを活用、普及されてきた多くのアマチュア無線家の皆様のご尽力により様々なネットワークが形成されております。　一方で実現には機材と一定の知識や技術が必要な側面もあります。

今回次の目標を開発のねらいとしました。

VoIPシステムの知識が無くても楽しめる
VoIP機材が無くてもDMR無線機があれば楽しめる
応答はPTT押下のみで簡単に
現地での複雑なTG番号登録作業を無くす
既存機材を無改造で活用（管理者や利用者側の負担をサーバー側で吸収）
RFでの運用を最大限活用
万一の緊急時や災害時、防災でも実用となる、許容される性能

また、現在国内各地でSFR基地局を設置運用されている管理者有志の皆様は、独自に設備を用意され、それを維持しオープンに提供されています。　地域やサービスエリアによっては運用者が少ないこともあるかと思います。　また全国のDMRを楽しまれている方々と無線の上でお話しできたら嬉しいと思います。

一方で、ホットスポットは、ご自身で工夫や改善をしない限り個人が自分の為に設置し利用する前提で接続し、その先のシステムもレピーターを除いてはホットスポットの先に不特定多数のユーザーが存在する前提ではない側面があり、現在の日本でのSFR運用となじまない場面が生じていました。

これらを実現のため、新たに発案・開発した上位 TG 制御レイヤーを導入し、従来の TG の役割を単なる配信先から「セッション生成トリガー」として再定義します。これにより中央集約型であった TG 制御を各 SFR（Single Frequency Repeater）へ分散し、メッシュ状に接続された通話セッションを動的に形成する新しいネットワークアーキテクチャを実現します。

従来のDMRネットワークでは、通話は主に固定されたトークグループ（TG）に基づいて配信されます。　ユーザーがPTTを押すと、そのTGに接続しているすべてのノードへ音声が配信されます。

この方式はシンプルで広く普及していますが、SFR環境ではいくつかの問題が発生します。

通常、この方式では TGへの接続を維持する必要があります。　しかし、SFRは単一チャネル資源のため、TG接続中はチャンネルが常時接続となり、SFRのリソースを占有してしまいます。　また接続中はローカルの交信トラフィックがそのままネット側に流れてしまいますので公共性が高いSFRでは弊害となります。

自宅に設置されたホットスポットのような環境では大きな問題になりませんが、現在日本で普及している SFR（DMRデジピーター） の運用では次のような制約が生じます。

システム開発について

SFR-Meshシステムは将来安定してSFR基地局をVoIP接続するインフラを提供し、VoIP機器が無いユーザーにも広くRF通信を起点としてSFRを通してより多くの方と通信できることを最大の目的とし、7K2LGO　佐藤個人により独自に開発を開始し、現在自身のサーバーにて稼働しております。

2026年5月時点で今回開発したLUTG制御方式の実証実験は成功いたしました。

既存のシステム環境の延長線上で新しいLUTGとSSOTを中心とした接続制御技術の開発と実証まで到達したのが現在地です。

またベースとなっているサーバープログラム自体のインストール作業を含めた再現性が著しく悪く稼働に至るまでが困難が多く、また、ライフサイクルの問題がありるのも事実です。　

この制御方式を用いて将来のOS等の更新対応のため、基本的な部分を改善する必要があります。　また、この実験と通じSFR基地局の管理者の皆様のホットスポットの管理でそれなりのご苦労があることが分かりました。　また現在利用しているPi－Starを安定して稼働するためにはハードウェアの選定、また、遠隔地に設置されている設備の管理の負担軽減も重要であることを学びました。　現在この対策のための手法を用意しているところです。

将来にわたる安定運用の為にはOSのバージョンアップ対応、DATA通信収容、安定性向上のための専用SFR接続システムの実現などが必要ということが分かり、改めて新規開発とする必要があることが分かってきました。　今後本格的に運用には根本的な部分からすべて新規に作り直し寄せ集めのシステムではない状態で将来性を持ったシステムにする必要があります。

実証実験は行いますが、将来の継続性と安定性を考慮しプロトタイプである現状のままで通常運用での展開に進むことは考えていません。　また、通常運用への展開には相当な工数と開発を継続する資金が必要となりますので相当な困難があるものと覚悟しています。

ETSIの規格の中でDMR Tier IIの特徴を最大限位活用している状態になあると考えていますが、このシステムが最善とも思っておらず、他のシステムや方式を否定する意図は全くなく、開発者の今できることを最大限行い、今出せる最善を尽くしただけですので、温かく見守って頂ければ大変ありがたいです。

冒頭の開発のねらいにて触れました「緊急時や災害時、防災でも実用となる、許容される性能」につきまして、簡単に説明いたします。　開発者は28年に渡り、消防、警察、港湾、航空の緊急業務や災害有事危機管理統合指揮所（EOC）の安全監理士官としての現場で、古くはFMレピーターからP25 Ph-2トランキングシステム等の業務無線も活用してきました。　その際のレベルを参考として、アマチュア無線と言えども、一定の許容されるレベルを維持できる仕様を目指しました。　これにはプログラムと開発のみで達成できるものではありません。　運用する設備や回線、それを維持する工数・脳数の総体がシステムとしての性能＝ユーザーの使用感と体験につながる性質のものであることをご理解頂きます様お願いいたします。

SFRの接続に関して

現時点では小さな規模になりますがVoIPリンク研究会のご協力を頂きまして、新しく生まれた制御技術の実証実験の為の運用を行っており、システム総体として完成を迎えるまでは広く接続の募集を行う段階にはありません。

この技術の紹介や使い方などに関するお問い合わせ等は、VoIPリンク研究会にお願いしております。

現在開発中につき実験段階で、運用パフォーマンスなどの想定や評価、改善作業を行っております。　その際ある程度の負荷や状況を作るトラフィックは必要となりますが、ログ最終などの観点から必要以上のロードは作業の支障になることと、作業中のモジュール再起動が多く発生しますので通信が途絶えますので管理できる範囲での実証実験となっております。　また、この間は開発者の判断により作業スケジュール優先で接続・切断を作業の必要に応じて行っております。

今後の接続拡大に際しては、インフラサーバーである性質上、安定した運用リソースの確保など解決しなければならない課題があります。（開発者個人で負担できるワークロードや金銭的なコスト範囲を超えます。）

重ねてになりますが、VoIP機器が無いユーザーにも広くRF通信を起点としてSFRを通してより多くの方と通信できることを目標としており不特定多数のプライベートHSを直接接続することを主な目的としておらず、接続管理方法も異なります。　また、これを収容するための開発・運用リソースコストを継続して個人が維持できないのが現状です。

また、SFR側のHSをシステムの一部として制御を委譲、分散して運用する都合上、設定ミスや複合条件などによりシステム全体に影響を及ぼす可能性があり、対応を含めた適切な運用管理を必要とするシステムです。

実証実験を進めていく中で、現在普及している保護隔離された接続条件のレフレクション方式を前提としたＭＭＤＶＭ製品は、双方向の協調制御が必要ないためそのような機能が一切なく、両方向からそれぞれ一方的な配信を行うことにより成立しています。　今回の方法もそこを前提として設計しておりますが、通常運用が行われているサイトに接続をする仕組み（保護隔離されていない状況）においては、どうしても性能と品質確保の上で限界が明らかになってきました。

今後はホットスポット側（ＳＦＲ基地局現地側）での協調制御が性能維持では必要となること判明しました。　出入り口の協調制御は移動局端末を直接制御できないTier IIで出来る最後の砦となり今後の最大の課題です。

実証実験中の各SFR基地局でのHSの設置・運用に関しましては、それぞれのSFR管理者の責任においてお願いいたします。　SFR-Meshはインフラ提供を目的としたシステムリソースであり、SFR基地局設備の運用管理を負うものではありません。

2026年7月より上記の不足を改善するため、VPN自動接続・設定情報自動展開・設定や半自動キャリブレーション機能などをの新しいHot Spot端末用OSの新規開発を開始しました。　このSH用OSが完成しましたら展開を開始します。　またこのOSでは仕様変更の際も自動で管理サーバーからプログラムをプッシュしてシステム開発の進展とともに管理者の手を煩わせることなく最新の機能の活用が可能になります。

DMR以外のモードの接続について

様々な制御をETSIに準拠して構築していますのでDMR専用のシステムです。　フレームレベルで関与していますので、DMRプロトコル以外のモードでの相互運用には、制御面でのインタープリターのような機構が必須で、その開発の可能性は現時点では非現実的と認識しています。　従来型のStatic TG接続互換レベルが現実的なラインと考えています。

一方で、Open Bridge Protocol (OBP)を実装し既存のADNシステムとの外部相互接続の互換性は維持していますので将来の展開の可能性は残してあります。

また、D-APRSのモジュール実装も計画しておりますが、ブロードキャスト思想の現行のAPRSは、APRSからDMRネットワークへの双方向の通信を実現するために常時接続を要求することになりますので、シングルリソースのSFR経由での親和性は大変悪いのが現実です。　一方でDMRからの一方的なデーターの垂れ流しは簡単ですが、APRSの双方向通信のポリシーに反することになりますので難しい判断が必要な状況です。