1.　はじめに

ローカル5Gは，大学キャンパスや研究機関における実証・教育・研究基盤としての導入が進展している．高信頼・低遅延通信の実現などを目的とし，免許に基づく限定エリア運用と柔軟なネットワーク設計により，既存キャンパスネットワークでは困難なユースケースの開拓が期待される．

大学キャンパスにおけるローカル5Gの利用場面としては，（U1）屋外カバーエリアでのフィールド実験や移動を伴う計測・観測，（U2）学内に設置した実験基盤へのアクセスを要する実験，（U3）実習・ハッカソン等の短期イベントで参加者が自身のスマートフォン/PCを持ち込む利用，が想定される．これらでは，参加者規模や端末多様性に対して専用端末の貸与だけでは台数・機種が追従しにくく，日常利用端末上のアプリやツールを前提とした実験設計が制約される．また，大学側が端末の配布・回収・保守を恒常的に担う運用は継続性の観点で負担が大きい．したがって，持ち込み端末を安全かつ再現性高く収容するための要件整理・設計判断・検証手順の体系化が実践的課題となる．

上記U1からU3の利用では，端末が学内実験基盤や学外サービスへ安定して到達できることに加え，端末を識別可能な形で通信の観測・検証（到達性試験，ログ相関，双方向通信の成立確認）を行えることが実務上重要となる．IPv4のみの構成では，キャンパス境界でのNAPTにより複数端末の通信が単一のグローバルIPv4に集約され，端末別の到達性評価や双方向通信（端末へ外部から到達させる検証，P2P型アプリ等）の設計・切り分けが難しくなる．一方，IPv6では端末ごとにグローバルに一意なアドレスを付与でき，端末識別と双方向性を前提とした評価・運用（U2の実験基盤連携やU3の短期参加者の検証手順）の単純化に寄与する．加えて，インターネットにおけるIPv6到達性は継続的に増加しており，GoogleおよびAPNIC Labsの公開統計からもその傾向が確認できるため[1], [2]，IPv6を提供できない環境は評価対象や利用可能な通信形態を狭める可能性がある．ただし，学内外の既存システムや外部サービスにはIPv4依存が残るため，IPv6のみでの運用にも制約がある．以上より，本稿ではIPv4/IPv6デュアルスタック構成を対象に設計指針と評価を行う．

多くの公開事例は導入業者が提供する専用端末や貸与端末を中心としており，利用者が保有するスマートフォンやPC等の持ち込み端末を安全かつ再現性高く収容するための体系的知見（要件定義・設計判断・検証手順）は十分に共有されていない．GlobalStatsの調査[3]によれば，2025年10月時点での日本国内でのモバイル端末のシェアはiOS系が約59%，Android系が約40%である．キャンパスローカル5Gネットワークに持ち込まれる端末についても同様の分布となると仮定すると，端末固有の要件差を踏まえながら，これらを可能な限り広く収容できる設計が求められる．特にiOS端末の収容は，Appleが示すローカル5G接続要件[4]による特有の要件を伴う．

現状のローカル5G導入では，単なる予算不足ではなく，技術的・制度的・運用的な複合的制約が顕在化している．免許取得，5Gコア構築，USIM（Universal Subscriber Identity Module）調達・発行管理，端末適合性検証といった複数の要素を同時に整備するためには，費用だけでなく専門知識・体制・制度的支援が不可欠であり，単に予算を確保すれば解決するものではない．特にiOS端末の収容やIPv6対応には，5Gコア構成・RAN（Radio Access Network）暗号化・端末設定・学内ルーティングの整合が求められ，運用者の知識や標準化の不足が障壁となる．

本研究は，上記の現実的な制約を踏まえ，持ち込み端末を対象としたIPv4/IPv6デュアルスタック接続性の運用設計指針を提示し，IPv6対応オープンソース5Gコアを用いた実機検証により妥当性を評価することを目的とする．特に，iOS端末の収容要件を満たしつつ，学内IPv6ルーティングと5Gコアにおけるアドレスプール設計を組み合わせることで，学外サービスへの透過的到達性を確保する．この目的に対し，以下のリサーチクエスチョン（RQ）を設定する．

RQ1　持ち込み端末を前提にiOS端末を含む多様な端末を収容するためには，どのような設計が必要か．

RQ2　ローカル5GでIPv4/IPv6デュアルスタック接続性を提供し，キャンパスネットワーク経由で学外サービスに透過的にアクセス可能とするためには，どのような設計が必要か．

RQ3　提案する運用設計指針は接続性と基本性能の観点で妥当性を示せるか，さらに他拠点で再現可能な条件をどのように整理できるか．

これらのRQを通じて，現状の多くのローカル5Gネットワーク運用で顕在化している「専用端末依存」「IPv6非対応」「再現性不足」という課題を解決し，ローカル5Gの運用モデルを一般化するための設計指針を提示する．

本稿の構成は以下のとおりである．2章で5G SAの基本構成とローカル5Gの特徴を概説し，3章で関連研究を整理する．4章で運用設計指針を提示し，5章でリファレンス実装を用いた接続性・到達性・性能評価を行う．6章で目的達成度と一般化条件・制約要因を考察し，7章で結論と今後の課題を述べる．

2.　ローカル5Gと5G SAの基本構成

2.1　5G SAアーキテクチャの概要

5G SAでは，無線アクセスネットワーク（RAN）と5G専用のコアネットワーク（5GC）が連携し，以下の要素で構成される．5Gコアの構成要素とインタフェースは3GPP TS 23.501 [5]で定義されている．

• ・RAN
  • −(Radio Unit): 無線信号の送受信を担当する物理層装置．
  • −DU(Distributed Unit): MAC(Medium Access Control)/RLC(Radio Link Control) 層を処理し，RUとCUを接続する．
  • −CU(Central Unit): PDCP(Packet Data Convergence Protocol) 層や制御プレーンを担当し，5GCと接続する．
  • −CUとDUはF1インタフェース，DUとRUはフロントホール（Fronthaul; FH）で接続される．
• ・5GC
  • −AMF(Access and Mobility Management Function): UE(User Equipment) の登録，接続，モビリティ管理を担当．N2インタフェースでCUと接続．
  • −SMF(Session Management Function): PDUセッションの確立，IPアドレス割当，UPFとの連携を担当．N4インタフェースでUPFと接続．
  • −UPF(User Plane Function): ユーザデータの転送を担当．N3インタフェースでCUと接続．N6インタフェースで外部ネットワーク（Data Network; DN）と接続．
  • −NSSF(Network Slice Selection Function): ネットワークスライスの選択を制御．N22インタフェースでAMFと接続．

図1に，上述した構成要素およびインタフェースを示す．

5Gでは，ユーザデータおよび制御メッセージに対し暗号化と完全性保護を行うためのアルゴリズムが規定されており，その識別子としてそれぞれNEA（0から3）およびNIA（0から3）が定義されている[6]．NEA0は暗号化なし，NIA0は完全性保護なしを意味する．NEA1からNEA3およびNIA1からNIA3はそれぞれ標準化されたアルゴリズム識別子である．端末（UE）とネットワーク（RAN/5GC）の交渉により使用する方式が選択される．

5Gのネットワークスライシングでは，端末が利用するスライスを識別する情報としてS-NSSAI（Single Network Slice Selection Assistance Information）が用いられ，S-NSSAIはSST（Slice/Service Type）とSD（Slice Differentiator）から構成される．SSTは「そのスライスが想定するサービス種別」を表す8ビット値であり，3GPPでは標準SST（1＝eMBB，2＝URLLC，3＝MIoT，等）が定義されている．

2.2　ローカル5Gにおける柔軟性と課題

ローカル5Gは，事業者網と異なり，PLMN（Public Land Mobile Network）やスライス構成，DNN（Data Network Name）設計，IPv4/IPv6の扱いを自組織で自由に決定できる．この柔軟性は，持ち込み端末や学内システム連携に有利である一方，以下の課題を伴う．

• ・多様な端末の収容：Apple社はiOS端末のプライベート5G接続に関する要件を公開しているが，iOS端末を収容するにはPLMN設定やSUCI（Subscription Concealed Identifier）非Null保護スキーム，構成プロファイルによるIPv6有効化など，複数の条件を満たす必要がある．Android端末はベンダやモデルによる挙動差が大きく，少なくともSA対応やBand n79対応の確認が不可欠である．
• ・IPv4/IPv6デュアルスタックの実現：学内外のシステム連携に不可欠だが，5GC・RAN・端末の設定整合が必要．5GコアのIPv6対応は3GPP仕様で定義されているものの，実際の運用では，商用ベンダ製品やオープンソースソフトウェア実装においてIPv6サポートが限定的である場合がある．

2.3　本稿の焦点

本稿は，上記課題のうち，持ち込み端末を対象としたIPv4/IPv6デュアルスタック収容の要件と運用設計指針に焦点を当てる．特に，iOS端末の収容要件を規格・公式仕様に基づき体系化し，5GC・RAN・端末間で生じやすい設定不整合を防ぐため，相互依存を前提に整合性を確保し再現性を担保する体系化された運用設計指針を提示する．また，Open5GSを用いたリファレンス実装を通じて，接続性・性能・運用性の評価を行い，再現性の高い実践知として整理する．

3.　関連研究

ローカル5Gに関する国内外での複数の導入事例が報告されている．本章では，（1）大学キャンパスにおけるローカル5G導入事例，（2）運用モデルとプラットフォーム構成，（3）IPv6対応や持ち込み端末に関する課題，の3観点から関連研究を整理する．

3.1　大学キャンパスにおけるローカル5G導入事例

国内では，広島大学をはじめとする複数の大学で，キャンパスネットワークと連携したローカル5Gテストベッドの構築が進められている．広島大学の事例では，5GコアおよびCU/DU/RUを含む商用機器を用い，学内外の研究連携や実証実験フィールドとしての活用を目指している[7]．また，NICTが提供するB5Gモバイル環境[8]は，28GHz帯やSub-6GHz帯を含む総合テストベッドとして，モバイルコアや基地局ソフトウェアの開発・検証を可能にしており，大学拠点での利用事例も報告されている．

これらの事例は，ローカル5Gを教育・研究基盤として活用する有効性を示す．

3.2　運用モデルとプラットフォーム構成

国際的には，ローカル5Gの導入における「make or buy」戦略や，複雑な産業エコシステムにおけるプラットフォーム構成に関する研究が進められている．Xieら[9]は，教育広域網を活用したキャンパスプライベート5Gの構成案を提案している．Kulkarniら[10]は，キャンパスにおけるローカル5G導入の意思決定において，コスト，運用負荷，サービス品質の観点から複数のシナリオを比較している．また，Ahokangasら[11]は，プライベート5Gネットワークのプラットフォーム構成とマルチステークホルダー環境における調整課題を分析し，ネットワークスライシングやセキュリティ要件の重要性を指摘している．

これらの研究は，ローカル5Gの導入・運用における戦略的視点を提供する．

3.3　IPv6対応と持ち込み端末に関する課題

3.1節で整理した大学キャンパスにおけるローカル5G導入事例は，教育研究基盤としての有効性やシステム構成の実現可能性を示している一方，運用者が持ち込み端末を想定して「どの端末を」「どの条件で」「どの手順で」収容できるか，およびIPv4/IPv6を含むIP設計と学内外到達性をどのように再現可能な形で担保するかについては，詳細な設計判断と検証手順が必ずしも明確ではない．また，3.2節で整理した運用モデルや導入意思決定に関する研究は，make-or-buyやプラットフォーム構成，運用負荷・コスト・品質の観点からローカル5G導入を俯瞰する枠組みを提供するが，端末互換性（特にiOS要件）やデュアルスック実装の設定整合（USIM/SUCI，RAN暗号化，端末側IPv6有効化，学内IPv6ルーティング等）に踏み込んだ再現可能な実装指針までは示していない．

以上を踏まえると，既存研究の到達点と残課題は次のように整理できる．

（残課題1）　持ち込み端末を前提とした端末収容要件の体系化：iOS/Android/Windows等の端末差を踏まえた「接続成立条件」と「運用上の注意点」を明示する必要がある．

（残課題2）　IPv4/IPv6デュアルスタックの運用設計の具体化：5Gコア，RAN，端末設定，学内ルーティングの整合を，第三者が追試可能な形で示す必要がある．

（残課題3）　再現性資産（設定・手順・評価方法）の提示：導入事例や概念整理に留まらず，他拠点が同条件で再現できる具体的資産が必要である．

本稿は，上記の残課題1から3に対し，iOS端末の収容要件を満たすためのUSIM/SUCI設定・RAN暗号化整合・端末側IPv6有効化を含む指針を提示し（残課題1，2への対応），Open5GSによるデュアルスタック構成と評価結果により運用設計を具体化し（残課題2への対応），さらに設定ファイル・スクリプト等の再現性資産を付録として提供する（残課題3への対応）ことで，導入事例・概念整理と実運用の間のギャップを埋めることを目指す．

4.　運用設計指針

本章では，ローカル5GネットワークにiOS端末を含む多様な端末を収容し，各端末にIPv4/IPv6デュアルスタック接続性を提供するための，USIM・5Gコア・RAN・端末の設定を一貫して構成する，運用設計指針を提示する．

本章で提示する運用設計指針は，USIM/PLMN管理，5Gコア/RAN設定，端末設定，および接続確認・評価を一連の手順として整合させることで，再現性高く持ち込み端末へIPv4/IPv6デュアルスタック接続性を提供することを目的とする．図2に，本研究で想定する運用モデルを示す．

4.1　USIMおよびPLMN

図2の手順S1として，Appleが定めるローカル5G接続要件に従い，自営用IMSI（International Mobile Subscriber Identity）^*1を取得し，書換可能なUSIMカードを採用する．この選択は，PLMN情報を自組織で管理することで，端末接続要件を柔軟に満たし，将来的なスライス運用やDNN設計の自由度を確保するためである．

さらに，図2の手順S2として，SUCIに非Null保護スキームを適用することで，iPhoneのSA接続条件を満たす構成を実現する．この設定は，pySim-shellや専用スクリプト（A.1章参照）を用いてUSIM内部のファイルを変更し，5Gコアの公開鍵を反映することで達成される．これにより，セキュリティ要件と端末互換性を両立させることが可能となる．

なお，本稿で書換可能USIMを採用した主目的は，参照実装として自営PLMN/加入者情報（鍵・SUCI設定を含む）を一貫して管理し，設定・手順を付録により提示することで，再現性のある運用設計指針を提供する点にある．一方，持ち込み端末の運用では，端末によってUSIMスロットが1枚分であり，利用者に個人契約SIMの差し替えを求めることが現実的でない場合がある．差し替え困難な端末に対しては接続用機材の貸与により運用上吸収することを想定する．本稿ではUSIMを用いた参照実装を中心に扱うが，USIM差し替え困難な端末への対応を含めた将来の選択肢としてeSIMの採用もあり得る．eSIMは物理配布を不要にして端末オンボーディングを簡素化し得るため，6.7節で拡張性の観点から改めて論じる．

4.2　IPv6対応

図2の手順S3として，オープンソースでIPv6に対応した5Gコアを採用し，オンプレミス環境に構築する．5GコアのAMF，SMF，UPFの設定を変更し，DNNごとにIPv4およびIPv6のアドレスプールを定義する（A.2.2節およびA.2.3節参照）ことで，IPv6到達性を確保する．

この設計は，IPv6を活用した研究や教育活動の基盤を提供するだけでなく，既存のIPv4サービスとの互換性を維持するための現実的な解である．IPv6の導入は，単なるアドレス付与に留まらず，キャンパスネットワーク経由で学外サービスへの透過的な接続を保証することを目的としている．

4.3　RANの暗号化と完全性保護

図2の手順S4として，RANの設定を変更し，暗号化アルゴリズムをNEA1，完全性保護アルゴリズムをNIA1に設定する（NEA/NIAの概要は2.1節参照，具体的な設定内容はA.3章参照）．これにより，Apple公式要件が要求する非Null保護スキームと整合し，SA接続を許容する構成を実現する．この変更は，RANとコア間のセキュリティ交渉において，端末側の要件を満たすために不可欠であり，暗号化設定の優先順位を調整することで，互換性と安全性を両立させている．

4.4　スライス設定

ベンダ依存の非標準SSTを排除し，将来的なスライス運用の拡張性を確保するため，代表的な標準SSTを採用する（SSTの概要は2.1節参照）．なお，5章の評価で用いたRAN実装ではSDの識別が事実上無効であったため，SSTのみで簡素化したが，これは実装依存の暫定措置であり，標準の一般原則を示すものではない．

4.5　端末側の設定

持ち込み端末運用では，端末OS・機種により「必要な設定」と「つまずき点」が異なる．ここでは，図2の手順S5として，iOS，Android，Windowsの3カテゴリに分けて，デュアルスタック接続を成立させるための最小要件と運用上の注意点を整理する．

4.5.1　iOS（iPhone/iPad）

iPhoneに構成プロファイルを適用し，APN^*2のIPv4/IPv6両対応を強制することで，IPv6アドレスの付与を可能にした．このプロファイルはApple Configuratorを用いて作成し，AllowedProtocolMaskをIPv4とIPv6の両方を示す値に設定する（A.4章参照）ことで，デュアルスタック構成を端末側で保証した．これにより端末設定の一貫性が確保される．

4.5.2　Android

Android端末は機種・ベンダにより挙動差が大きく，Google社による統一的な公開情報もないため，持ち込み端末運用では事前条件の整理が重要となる．最低限，（i）5G SA対応，（ii）ローカル5Gの運用バンド（本稿ではn79）対応，（iii）プライベートPLMN（MCC＝999等）の受容性，の3点は事前の確認を要する．加えて，端末側でAPNが設定可能な場合は，APNの「APNプロトコル（IPバージョン）」をIPv4/IPv6（デュアル）に設定し，IPv6アドレス付与と到達性を確認する．

4.5.3　Windows

Windows端末では，5GモデムがSAおよび運用バンド（本稿ではn79）に対応し，プライベートPLMN（MCC＝999等）を受容できること，ならびにOS/ドライバが当該モデムを正しく認識していることを事前に確認する必要がある．APNの「APNプロトコル（IPバージョン）」はIPv4/IPv6（デュアル）に設定し，IPv6アドレス付与と到達性を確認する．

5.　評価

図2の手順S6およびS7として，本学に設置したローカル5Gネットワークに対して，接続性，IPv6到達性，ならびにユーザプレーン性能（スループット，パケット損失率，RTT（Round Trip Time））の観点から評価を行った．なお，評価にあたり，1章のユースケース（U1からU3）に基づく目標値を事前に定義する．U1では移動や無線変動下でも通信が破綻しないことを重視し，パケット損失率1%以下を目標とする．音声・映像等のリアルタイム通信において損失が1%を超えると品質劣化が顕在化しやすい[12]という一般的な指標に基づき，移動や無線変動下でも破綻しない下限として設定した．U2では対話的利用を想定し，RTT中央値80 ms以下を目標とする．対話的アプリケーション（音声通話・ビデオ会議等）が遅延の影響を受ける[13]ことが知られており，その影響を小さくするための目安として設定した．U3では参加者体感の確保として，上り下りスループット中央値32 Mbps以上を目標とする．短期参加者を含む利用で典型的に想定されるビデオ会議・画面共有等が1端末あたり4 Mbps程度で成立する[14]ことから，8端末同時接続を可能とするための下限として設定した．

5.1　評価環境

評価環境を，NEC UNIVERGE RV1200を用いたSA構成のRANと，オープンソースでIPv6に対応したOpen5GS v2.7.2を用いた5Gコアにより，図3に示すように構成した．運用周波数帯は4.8–4.9 GHz（n79の一部），帯域幅は100 MHzであり，自営免許に基づく限定エリアで運用した．DNとして，大阪大学のキャンパスネットワークであるODINSのうち，本件専用のVLANを用いてインターネットへのIPv4/IPv6接続性を確保した．

USIMは，書換可能なsysmocom ISIM-SJA5-S17を用いた．端末は，iPhone 16（iOS 26.0.1）を主対象としつつ，n79およびSA対応のAndroidスマートフォン，モバイルルータ，Windowsラップトップ等も用いた．

本評価環境について，第三者の追試を容易にするため，以下を再現性資産として整理した．

• ・USIMプロビジョニング：pySim-shell用USIM書換スクリプト（A.1章）
• ・Open5GS設定：amf.yaml, smf.yaml, upf.yaml, nrf.yaml, nssf.yaml（A.2章）
• ・iOS構成プロファイル：XMLサンプル（A.4章）
• ・評価スクリプト：iperf3ラッパー（A.5章）

5.2　接続性評価

iPhone 16に対して自営用IMSIを書き込んだ書換可能USIMを装着し，SUCI非Null保護を有効化したうえで，RAN側の暗号化・完全性保護設定をNEA1・NIA1に整合させた構成でRegistrationを試行した．Registration要求から登録完了（Registration complete），PDUセッション確立（SMF・UPFのDNN＝internet）までの過程は端末アプリケーション・端末システムUI・Open5GSログの3点で追跡し，AMFにおけるN2（NGAP）シグナリングとSMFのセッション管理が一貫して成功していることを確認した．

同様の手順を，モバイルルータおよびWindowsラップトップに適用した結果，RegistrationとPDUセッション確立が安定的に成立した．Android端末のうち，京セラKC-S305およびSamsung Galaxy A25 5GはRegistrationした一方で，Google Pixel 7aおよび8aは仕様上n79およびSA対応とされているにもかかわらず，Registrationに至らない事象を再現性を持って確認した．

表1に，端末ごとの前提条件（n79/SA対応，MCC＝999の受容性）と接続結果を整理した．

5.3　IPv6到達性評価

接続後にiPhone端末に割り当てられたIPアドレスは，IPv4についてはプライベートアドレスからキャンパス境界でNAPTされたグローバルアドレスにより外部到達が実現していること，IPv6については所定のプレフィックス（図A･5・図A･6で定義）からグローバルIPv6アドレスが端末に付与されていることを，それぞれターミナル画面（図4（左））とウェブブラウザ画面（図4（右），接続先：inonius.net）で確認した．IPv6によるウェブサイトへのアクセスの成立は，図4（右）に示すとおりであり，IPv6のみで到達できるサービスに対して端末が問題なく接続できることを視覚的に裏付けている．Windowsラップトップおよび接続可となったAndroid端末では，iPhoneのケースと同様のIPv6到達性を確認した．

モバイルルータでは，RANとのSA接続後，DNN＝internetでIPv4/IPv6の両方のアドレスが割り当てられた．表1記載のWindowsタブレットを，5Gモデムをオフにした状態でWi-Fiにより，モバイルルータの配下端末としてテザリング接続したところ，テザリング端末にIPv4アドレスはモバイルルータのLAN側プライベートアドレスが，IPv6アドレスはモバイルルータ自体に付されたものと同じ/64プレフィクスにテザリング端末自身の設定する下位64ビットを結合したアドレスが付され，テザリング端末からもキャンパスネットワーク経由で学外サービスにアクセス可能であることを確認した．

5.4　性能評価

ユーザプレーンの基本性能が運用上許容される水準にあることを確認するため，屋外RUカバーエリアにおける静止状態と歩行状態（約5 km/h）での通信品質を測定し，移動による影響を定量的に評価した（図5）．評価指標はスループット・パケット損失率・RTTとした．UEとして用いたWindowsラップトップ（Fujitsu LIFEBOOK WU2/J3 5G）から本学内に設置したMEC（Multi-access Edge Computing）サーバを対向として計測した．

これによりスループットとパケット損失率については5回の計測データを，RTTについては50回の計測データを取得した．スループットおよびパケット損失率の測定は，iperf3により一定時間の送受信を行うだけでなく，A.5章に記載したスクリプトによりTCPで実効帯域を測定した上でUDPレートを自動決定し，許容損失率を満たす最大レートを探索するため，1回の測定が複数回の通信試験から構成され測定時間を要する．また屋外RUカバーエリアでは，周辺電波環境や端末位置の微小変動などにより短時間でも値が変動し得るため，本稿では同一条件で複数回測定し，外れ値の影響を受けにくい中央値を代表値として採用した．そのうえで，測定実施可能時間とのトレードオフから，スループット/損失率は各条件5回の反復測定を行い中央値で整理した．一方RTTは1回の測定コストが小さいため，同一条件で50回のサンプルを取得し，中央値に加えて分布としてばらつきを可視化した．

表2に，（静止時/歩行時）×（IPv4/IPv6）の上り・下りスループット・パケット損失率・RTTの中央値を記載し，図6に，RTT分布を箱ひげ図として示す．下りスループットはIPv4・IPv6とも静止・歩行の両条件で100 Mbps超を維持し，上りは歩行時に約30%低下したが40 Mbps以上を確保した．パケット損失率はIPv4/IPv6とも静止時は0，歩行時でも約0.4%に留まった．RTTは静止IPv4でスパイクがあり平均値（図6箱ひげ図中の×印で示す）を引き上げたが，中央値は他と同程度で50 ms未満であった．

6.　考察

6.1　目的達成度とリサーチクエスチョンとの対応関係

本研究は，キャンパスローカル5G環境において，持ち込み端末を対象にIPv4/IPv6デュアルスタック接続性を提供するための運用設計指針を提示し，その妥当性を評価することを目的とし，1章に示す3点のRQを設定した．RQと5章に示した評価結果との対応関係は以下のように整理される．

RQ1（多様な端末を収容するための構成要件）について，iPhone，モバイルルータ，WindowsラップトップでRegistrationとPDUセッションが安定的に成立し，USIM/SUCI非Null保護，RAN暗号化，端末プロファイルによるIPv6有効化という設計要件が妥当であることを，表1および図4の事例で示した．

RQ2（IPv4/IPv6デュアルスタックの構成要件）について，Open5GS上のAMF/SMF/UPFの設計により，学外への透過的なIPv6接続が，NAPTによるIPv4接続に加えて，成立することを図4で明確化した．

RQ3（妥当性と一般化可能性）について，表2と図6に示した性能の測定結果により，5章に示した目標を達成していることを確認した．また，Android端末の一部機種接続不可事例の分析から，端末差異に起因する制約を踏まえた一般化条件の提示が不可欠であるとの結論に至った．接続不可事例に関しては，原因の同定と対策の一般化に向けた追加解析を今後の課題として位置づける．

以上により，提案構成は，持ち込み端末環境におけるiOS端末を含む多様な端末の収容と，IPv4/IPv6デュアルスタック接続性の提供という目標を，基本性能の観点でも満たすことが確認された．特に，構成プロファイルを用いてIPv6通信を可能にしたiOS端末の収容は，日本国内の端末シェアを踏まえると，実務的な適用範囲を広げ，ローカル5GネットワークにおけるIPv4/IPv6デュアルスタック提供の実現可能性を高める．

6.2　一般化可能性と適用条件

他拠点での再現可能性は，いくつかの前提が同時に満たされることに依存する．第1に，PLMN/USIMの自営管理が確立されていることが必要である．すなわち，自営用IMSIの取得，USIM書き込みのためのADM鍵の安全な管理，SUCI非Null保護の設定が組織側で確実に行える体制である．第2に，5Gコアを自営運用できることが求められる．Open5GS等のIPv6対応オープンソースソフトウェア5GコアでAMF/SMF/UPFを構成し，DNN別にIPv4/IPv6のアドレスプールとトンネルインタフェースを設計する能力が必要となる．第3に，RAN側で暗号化・完全性保護（NEA1/NIA1）が可能であり，SSTの標準値を運用できることが不可欠である．第4に，学内のIPv6ルーティングが整備され，プレフィックス配布，FW/ACLの整合，外部へのIPv6経路が確保されていることが条件となる．

6.3　制約要因と内部妥当性に対する脅威

本研究の内部妥当性に対する脅威として，測定系の構成やキャンパス側ネットワークの状態が性能指標に影響する可能性がある．たとえば，iperf3サーバの位置や経路に依存するボトルネック，FW/ACLの一時的な変更，同時接続端末の負荷変動がRTTやスループットの中央値を左右することがある．これらは繰り返し測定と中央値採用により一定の緩和を図っているが，測定時刻や負荷条件の差異に対する残余の影響は否定できない．外的妥当性の観点では，RANベンダや端末ベンダの実装差が一般化の障壁となりうる．また，スライスを標準SSTのみで運用し，SD値を事実上無効化する簡素化は，使用できるスライス数を制約し，将来的なスライス多様化やQoS差別化の柔軟性を制約する側面がある．この点は，PCF（Policy Control Function）連携やQoSポリシの段階的導入を前提とした設計拡張により，緩和の余地がある．

6.4　Android端末の挙動差と原因仮説

Android端末間でRegistrationの可否が分かれた要因について，Google社による公式な公開情報がないことから，現時点で確定的に述べることは難しい．ただし，Google Issue Tracker [15]では，プライベートネットワーク用のMCC/MNCがGoogle Pixel 7a等の端末で4Gネットワークでは使用できるものの5Gネットワークでは使用できない旨の報告およびGoogle社に対する改善要望がなされている．また，GitHub [16]では，試験用のMCC＝001/MNC＝01であれば5Gネットワークでも動作したこと，この原因がCarrierConfigデータベースにあること，（端末のJailbreakを行わない限り）暫定的な回避策は存在せずAndroidがMCC＝999を標準的に扱うよう変更されるのを待つ以外にないことの報告がなされている．このことから，Google Pixelを含む一部のAndroid端末では，MCC＝999の扱いに起因する制約がある可能性が示唆される．

現時点においては，端末差異を前提に，接続可否・必要条件・既知の制約を表1のようにホワイトリスト形式で継続的に公開・更新することが，持ち込み端末運用の予見性とユーザ支援の観点で有効である．

6.5　運用・管理への影響と示唆

運用設計指針の導入は，技術面に加えて運用・管理面での規律化を伴う．PLMN/IMSI/ADM鍵の管理は，漏えい防止と誤書込み防止（ADM鍵誤入力によるUSIMロック）に関する手順整備が必要であり，USIMの配布・回収・失効管理を含めたライフサイクル設計が求められる．RAN暗号化のポリシ変更（NEA1/NIA1）は，コア側のintegrity_order/ciphering_order（A.2.1節のamf.yaml参照）との一貫性が重要であり，設定変更の監査可能性を確保するために，変更記録とロールバック手順の明文化が推奨される．端末側では，iPhone構成プロファイル適用後の手動APN操作が設定上書きを招く（A.4章参照）ため，ユーザ向けのガイドライン整備と動作確認手順（端末設定→ネットワーク情報→IPv6付与の確認）を簡潔に提供することが望ましい．接続性の品質監視については，Registration成功率，PDUセッション確立時間，RTT中央値，パケット損失率などのメトリクスを定期的に取得し，閾値逸脱時の原因切り分けフローを図示して運用チームに共有することが，安定運用の鍵となろう．

6.6　セキュリティとプライバシ

SUCI非Null保護の採用は，無線区間で加入者識別情報を秘匿し，受動的傍受に対する曝露リスクを低減させる．暗号スイートの選定（NEA1/NIA1）は，端末互換性と強度のバランス設計であり，将来的にNEA2/NIA2の適用可否をRAN側の対応の進展に合わせて再検討する余地がある．IPv6はアドレス可視性が高いため，キャンパスFW/ACLにおいて，意図した通信経路以外への到達を適切に制限し，ログ監査を可能にする設計とすることが重要である．

6.7　スケーラビリティと拡張性

本研究は接続成立と基本性能の妥当性を示したが，今後，同時接続端末数の増加時におけるAMF/SMF/UPFの資源配分，N3/N6のボトルネック，RANのスケジューリング挙動などのスケーラビリティ評価が必要となる．SSTのみでのスライス分離は運用の簡素化には有効だが，サービス多様化時にはQoSポリシやPCF連携の導入を通じて，トラフィック種別ごとの差別化を図る設計へ発展させることが望ましい．

4.1節で述べたように，eSIMは物理配布を不要にし，オンボーディング迅速化や失効・再発行の効率化に資する可能性がある．一方で，大学が単独でeSIM発行・配布運用まで含めて自前で整備することは費用・労力・時間の観点から容易ではないため，本稿ではeSIMの採否を結論づけず，将来の検討課題として位置付ける．eSIMプロファイル配布機能を外部事業者が提供する形態も存在するが，この適否についても本稿では議論せず，将来の議論に委ねる．

7.　おわりに

本稿では，ローカル5G環境において，iOS端末を含む持ち込み端末をIPv4/IPv6デュアルスタックで収容するための運用設計指針を体系化し，Open5GSを用いた実機環境での評価を通じてその有効性を検証した．

本稿の主な貢献は以下のとおりである．

持ち込み端末収容の設計　iOS端末の接続要件に準拠するため，自営用IMSIと書換可能USIMを用い，SUCI非Null保護を適用．RANの暗号化・完全性保護をNEA1/NIA1とし，iPhone構成プロファイルによりIPv6を有効化することで，端末側要件とネットワーク側設定の相互依存を解消．（RQ1に対応）

デュアルスタック対応ローカル5Gの実証　5GコアにIPv6対応のオープンソースソフトウェアであるOpen5GSを採用し，DNNごとにIPv4/IPv6アドレスプールを設計．学内IPv6ルーティングと合わせ，ローカル5G端末から学外IPv6サービスへの到達性を確保．（RQ2に対応）

接続性評価と一般化条件の提示　端末カテゴリ横断の接続性評価・IPv6到達性評価・性能評価を行い，提案運用設計指針の妥当性を定量的に確認．他拠点への適用条件（PLMN/USIM自営管理，5Gコア自営運用，RAN暗号化整合，学内IPv6整備）を明示し，再現性を担保．（RQ3に対応）

本研究の成果は，接続性と基本性能の観点からデュアルスタック化が実現可能であることを示した．単一セル内で単一UEを接続した静止および歩行の条件での評価においてはデュアルスタック構成で良好な性能が得られた．また，構築・運用における再現性を担保するため，設定ファイル，USIM書換スクリプト，構成プロファイル，評価スクリプトを付録として整理し，第三者による追試を容易にした．

本研究の意義は，ローカル5Gを活用したキャンパスネットワークや実証環境において，持ち込み端末を前提とした柔軟な運用を可能にする実践知を提供したことにある．これにより，従来はベンダ専用端末に依存していたローカル5Gの利用モデルを，一般的なスマートフォンやPCに拡張するための基盤が整備された．本研究で提示した枠組みと知見は，ローカル5Gの導入を検討する大学や研究機関にとって，再現性と安全性を両立するための有効な運用設計指針となると考えられる．

今後の発展の方向性として数点挙げられる．第1はeSIM発行のオンライン化を進めることである．USIMカードの物理配布を不要にし，持ち込み端末のオンボーディングを迅速化できる可能性がある．第2はAndroid端末の接続性を体系化することである．ベンダ依存の挙動差を吸収するための標準化された診断プロセスを確立することが求められる．第3はスライシングとQoS制御の高度化を図ることである．S-NSSAIの実装依存を踏まえた柔軟なスライス設計とQoSベースの評価を追加することが重要である．第4は広域連携の実証を進めることである．複数拠点間でのローカル5G相互接続やIPv6スライシングの評価を行うことが期待される．