JP7241899B2 - ５ｇ以降を用いた産業自動化 - Google Patents

５ｇ以降を用いた産業自動化 Download PDF

Info

Publication number
JP7241899B2
JP7241899B2 JP2021547171A JP2021547171A JP7241899B2 JP 7241899 B2 JP7241899 B2 JP 7241899B2 JP 2021547171 A JP2021547171 A JP 2021547171A JP 2021547171 A JP2021547171 A JP 2021547171A JP 7241899 B2 JP7241899 B2 JP 7241899B2
Authority
JP
Japan
Prior art keywords
network
tsn
spectrum
data
rbs
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2021547171A
Other languages
English (en)
Other versions
JP2022522630A (ja
Inventor
ヨアキム サックス，
アンナ ラルモ，
アブドゥールラフマン アラッバシ，
アレクセイ シャピン，
アンデシュ ホグラン，
ビクラムジット シン，
ディナン ルーラント，
イン－ピン エリク ワン，
ヒョードル チェルノゴロフ，
ゲーザ サボー，
フベルタス アンドレアス ミュンツ，
ムハマド イクラム アシュラフ，
ヨハン ルンドショー，
ジョン ウォルター ディアチーナ，
オルソン， ヨーナス フレベリ
ホセ ルイス プラダス，
キンモ ヒルトゥネン，
キティーポン キティーチョークチャイ，
クン ワン，
マグヌス サンドグレン，
マジド ジェラミ，
マティアス アンデション，
ミゲル ロペス，
ニエンシャン シー，
ニクラス アンドガルト，
ノルベルト レイダー，
オスマン ヌリ カン ユルマズ，
パトリク サルメラ，
プラディーパ ラーマチャンドラ，
シャンドル ラーツ，
サラ サンドバリ，
ステファノ ルフィニ，
トシュテン ドゥッダ，
ヴォルフガング トヌッティ，
チェンホア ツォウ，
ロベルト バルデメイレ，
パウル シュリワ－ベルトリング，
アンドラシュ ケルン，
バラージュ バルガ，
ガーボル ネメト，
ヤノシュ ファルカシュ，
ジョルト ケネシ，
ユフェイ ブランケンシップ，
イン スン，
トールニー ホルムバリ，
ソルール ファラハティ，
ロドリゴ ベリ，
ペル スカリン，
ペル パーション，
オラ アンジェルスマルク，
モルテン ヴァールストレーム，
マウゴジャタ スベンソン，
クマール バラチャンドラン，
ホセ アラウーホ，
ヨハネス ニグレン，
ヨハン オルソン，
ヨアキム パーション，
ヘンリク エンブスケ，
ハラルト グスタフソン，
ジェルジュ ミクロース，
フレドリク スベンソン，
デュルヴィン パテル，
デニス スンドマン，
ベルナルド スメーツ，
アレクサンドロス パライオス，
Original Assignee
テレフオンアクチーボラゲット エルエム エリクソン（パブル）
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by テレフオンアクチーボラゲット エルエム エリクソン（パブル） filed Critical テレフオンアクチーボラゲット エルエム エリクソン（パブル）
Publication of JP2022522630A publication Critical patent/JP2022522630A/ja
Application granted granted Critical
Publication of JP7241899B2 publication Critical patent/JP7241899B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H04L67/1044—Group management mechanisms 
    • H04L67/1046—Joining mechanisms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/02—Arrangements for optimising operational condition
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
    • G06K19/00—Record carriers for use with machines and with at least a part designed to carry digital markings
    • G06K19/06—Record carriers for use with machines and with at least a part designed to carry digital markings characterised by the kind of the digital marking, e.g. shape, nature, code
    • G06K19/06009—Record carriers for use with machines and with at least a part designed to carry digital markings characterised by the kind of the digital marking, e.g. shape, nature, code with optically detectable marking
    • G06K19/06018—Record carriers for use with machines and with at least a part designed to carry digital markings characterised by the kind of the digital marking, e.g. shape, nature, code with optically detectable marking one-dimensional coding
    • G06K19/06028—Record carriers for use with machines and with at least a part designed to carry digital markings characterised by the kind of the digital marking, e.g. shape, nature, code with optically detectable marking one-dimensional coding using bar codes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
    • G06K19/00—Record carriers for use with machines and with at least a part designed to carry digital markings
    • G06K19/06—Record carriers for use with machines and with at least a part designed to carry digital markings characterised by the kind of the digital marking, e.g. shape, nature, code
    • G06K19/06009—Record carriers for use with machines and with at least a part designed to carry digital markings characterised by the kind of the digital marking, e.g. shape, nature, code with optically detectable marking
    • G06K19/06037—Record carriers for use with machines and with at least a part designed to carry digital markings characterised by the kind of the digital marking, e.g. shape, nature, code with optically detectable marking multi-dimensional coding
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
    • G06K19/00—Record carriers for use with machines and with at least a part designed to carry digital markings
    • G06K19/06—Record carriers for use with machines and with at least a part designed to carry digital markings characterised by the kind of the digital marking, e.g. shape, nature, code
    • G06K19/067—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components
    • G06K19/07—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components with integrated circuit chips
    • G06K19/0723—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components with integrated circuit chips the record carrier comprising an arrangement for non-contact communication, e.g. wireless communication circuits on transponder cards, non-contact smart cards or RFIDs
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C9/00—Individual registration on entry or exit
    • G07C9/00174—Electronically operated locks; Circuits therefor; Nonmechanical keys therefor, e.g. passive or active electrical keys or other data carriers without mechanical keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04J—MULTIPLEX COMMUNICATION
    • H04J3/00—Time-division multiplex systems
    • H04J3/02—Details
    • H04J3/06—Synchronising arrangements
    • H04J3/0635—Clock or time synchronisation in a network
    • H04J3/0638—Clock or time synchronisation among nodes; Internode synchronisation
    • H04J3/0658—Clock or time synchronisation among packet nodes
    • H04J3/0661—Clock or time synchronisation among packet nodes using timestamps
    • H04J3/0667—Bidirectional timestamps, e.g. NTP or PTP for compensation of clock drift and for compensation of propagation delays
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/34—Flow control; Congestion control ensuring sequence integrity, e.g. using sequence numbers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/04—Protocols for data compression, e.g. ROHC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/03—Protecting confidentiality, e.g. by encryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0215—Traffic management, e.g. flow control or congestion control based on user or device properties, e.g. MTC-capable devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/50—Service provisioning or reconfiguring
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W48/00—Access restriction; Network selection; Access point selection
    • H04W48/08—Access restriction or access information delivery, e.g. discovery data delivery
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W56/00—Synchronisation arrangements
    • H04W56/001—Synchronization between nodes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W56/00—Synchronisation arrangements
    • H04W56/0055—Synchronisation arrangements determining timing error of reception due to propagation delay
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W56/00—Synchronisation arrangements
    • H04W56/0055—Synchronisation arrangements determining timing error of reception due to propagation delay
    • H04W56/0065—Synchronisation arrangements determining timing error of reception due to propagation delay using measurement of signal travel time
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/12—Wireless traffic scheduling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W92/00—Interfaces specially adapted for wireless communication networks
    • H04W92/02—Inter-networking arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/18—Self-organising networks, e.g. ad-hoc networks or sensor networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W92/00—Interfaces specially adapted for wireless communication networks
    • H04W92/16—Interfaces between hierarchically similar devices
    • H04W92/18—Interfaces between hierarchically similar devices between terminal devices

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Mathematical Physics (AREA)
  • Medical Informatics (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Small-Scale Networks (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Treatments For Attaching Organic Compounds To Fibrous Goods (AREA)

Description

本開示は、無線通信ネットワークに関し、第５世代（５Ｇ）または他の無線通信ネットワークを使用した、産業アプリケーションに好適なネットワークアーキテクチャ、無線デバイス、および無線ネットワークノードを説明する。
モバイル技術の第５世代（５Ｇ）は、既存の３Ｇ／４Ｇ技術よりも幅広い範囲のサービスを提供することができる。５Ｇの３つの主な使用事例は、モバイルブロードバンドの高度化（ｅＭＢＢ：Ｅｎｈａｎｃｅｄ Ｍｏｂｉｌｅ Ｂｒｏａｄｂａｎｄ）、大量のマシンタイプ通信（ｍＭＴＣ：Ｍａｓｓｉｖｅ Ｍａｃｈｉｎｅ Ｔｙｐｅ ｏｆ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）、および超高信頼低遅延通信（ＵＲＬＬＣ：Ｕｌｔｒａ Ｒｅｌｉａｂｌｅ Ｌｏｗ Ｌａｔｅｎｃｙ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）である。５Ｇシステムの重要な目的は、バーティカル市場からの厳しいシステム要件をサポートすることができることである。それらの要件は、信頼性、レイテンシ、スループット、位置決め、および可用性の複数の組合せ、ならびに、ローカル残存性、ローカルデータ／ルーティング、ローカル管理、セキュリティ、データ完全性、およびプライバシを伴ったローカルデプロイメントを同時にサポートすることを含む。
５Ｇシステムの産業ネットワーク観点が図１に例証される。サービス性能要件は、自動化アプリケーションに由来している。５Ｇシステムは、自動化アプリケーションに通信サービスを提供している。バーティカルドメインにおける自動化をサポートするために、５Ｇシステムは、特定のアプリケーションおよび使用事例にサーブするためにサービス性能要件を満たすように、信頼性が高く柔軟である必要がある。それらは、信頼性、可用性、保全性、安全性、および完全性のシステム特性を備える必要がある。
５Ｇの仕様は、第３世代パートナーシッププロジェクト（３ＧＰＰ：３ｒｄ－Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）のメンバにより開発中である。文書「Ｓｅｒｖｉｃｅ Ｒｅｑｕｉｒｅｍｅｎｔｓ ｆｏｒ Ｃｙｂｅｒ－Ｐｈｙｓｉｃａｌ Ｃｏｎｔｒｏｌ Ａｐｐｌｉｃａｔｉｏｎｓ ｉｎ Ｖｅｒｔｉｃａｌ Ｄｏｍａｉｎｓ， Ｓｔａｇｅ １」、３ＧＰＰ ＴＳ ２２．１０４，ｖ．１６．０．０（２０１９年１月）は、様々なバーティカル市場によって使用されるサイバーフィジカル制御アプリケーションの異なる使用事例を十分にサポートするために満たされる必要のある性能基準の様々なセットを提供する要件を指定する。
産業アプリケーション空間において、要件は、同じデプロイメントにおける大量のマシンタイプ通信（ｍＭＴＣ）、モバイルブロードバンドの高度化（ｅＭＢＢ）、および超高信頼低遅延通信（ＵＲＬＬＣ）トラフィックなどの異なるサービスレベルのためのサポートを含め、工場および製造環境における混合サービスのためのサポートを含む。産業用決定論的サービスのためのサポートが必要とされる。５Ｇシステム（５ＧＳ）と既存の産業ネットワークとのインテグレーションも必要である。非公開ネットワークのためのサポートを含む、相互運用性、および公衆陸上移動網（ＰＬＭＮ）との相互運用性が必要である。
システム可用性および信頼性に関して、通信サービスプロバイダとしての５Ｇシステムは、可用性および信頼性の３ＧＰＰ規定に準拠するべきである。通信サービス可用性は、システムが特定のエリア内での仕様に従ってエンドツーエンドサービスを配信するために予測される時間の量によって除算される、エンドツーエンド通信サービスが合意したサービス品質（ＱｏＳ）に従って配信される時間の量のパーセンテージ値として規定される。必要な可用性は、システムが利用可能でないときの金銭的損失と、例えば、冗長性を増大させることによって、可用性を増大させるための複雑性とのトレードオフを考慮した、事業的な見地によって決定されることになる。９９．９５％を超える可用性は、通常、公共エネルギー供給網が最も弱いコンポーネントになることを防ぐために、追加の電源を必要とする（欧州では、９９．９～９９．９９％可用性）ということを理解されたい。
通信サービス信頼性は、所与の条件下で所与の時間間隔にわたって必要に応じて実施するための通信サービスの能力と規定される。これらの条件は、動作モード、ストレスレベル、および環境条件など、信頼性に影響を及ぼす側面を含む。信頼性は、故障までの平均時間、または指定の時間期間内の故障なしの可能性などの適切な尺度を使用して定量化され得る。
産業アプリケーションにおける５Ｇの使用は、安全性要件を満たさなければならず、ここでは安全性は、危険、リスク、または損傷を引き起こすことを防ぐ、または引き起こす可能性の低い条件と規定される。したがって、安全システムは、最初から機能的に安全であるように設計されるべきである。自動保護機能は、動作中にシステムの安全性を確実にするためにシステムに組み込まれ得る。自動保護を確実にするためにシステム設計において考慮されるべき安全面は、例えば、ヒューマンエラー、ハードウェアおよびソフトウェア故障、ならびに動作および環境ストレス因子を含むべきである。
今日の多くの産業は、自らのローカルネットワークデプロイメントを完全に掌握している。故に、ローカル残存性、ローカルデータ／ルーティング、およびローカル管理に関するローカルデプロイメント側面は、産業ネットワークのための要件になる。簡単に言うと、工場ネットワークは、外の世界への接続が失われるときにさえ、正常に動作するべきである。さらには、データが敷地から出ないこと、ならびにローカルＩＴスタッフがネットワークデプロイメントを要求に応じて管理および変更することができることというような要件が存在し得る。
セキュリティ、データ完全性、およびプライバシも同様に産業にとって重要な要件である。プロセスおよび製造プロセスからのデータに関する事業の重大な情報は流出してはならない。
本明細書に詳細に説明されるのは、タイムセンシティブネットワーキング（ＴＳＮ：Ｔｉｍｅ－Ｓｅｎｓｉｔｉｖｅ Ｎｅｔｗｏｒｋｉｎｇ）および５Ｇ無線ネットワークインテグレーションのための技術を含む、産業用モノのインターネット（ＩＩｏＴ：Ｉｎｄｕｓｔｒｉａｌ Ｉｎｔｅｒｎｅｔ－ｏｆ－Ｔｈｉｎｇｓ）シナリオを強化するための様々な技術である。対応するデバイスおよびノードもまた、詳細に説明される。
無線デバイスによって実施される一例示的な方法は、無線アクセスネットワーク（ＲＡＮ）の無線基地局（ＲＢＳ）からシステム情報（ＳＩ）を受信することであって、ＳＩがＲＢＳを通じたＴＳＮのためのサポートを示している、システム情報（ＳＩ）を受信することと、ＲＢＳを通じて外部データネットワークとの少なくとも１つのＴＳＮデータストリームを確立することとを含む。例示的な方法は、ＲＢＳを介して無線通信ネットワークから第１のタイミング信号を受信することと、無線デバイスが接続される外部ＴＳＮデータネットワークから第２のタイミング信号を受信することと、第１のタイミング信号を第２のタイミング信号と比較してオフセットを決定することと、このオフセットを無線通信ネットワークに伝送することとをさらに含む。
同様に無線デバイスによって実施される別の例示的な方法は、無線通信ネットワークから第１のタイミング信号を受信することと、無線デバイスが接続される外部ＴＳＮデータネットワークから第２のタイミング信号を受信することと、無線通信ネットワーク内の無線基地局（ＲＢＳ）を通じて外部ＴＳＮデータネットワークとの少なくとも１つのＴＳＮデータストリームを確立することとを含む。
別の例示的な方法は、無線アクセスネットワーク（ＲＡＮ）と関連付けられたコアネットワークの１つまたは複数のノードにおいて実施され、また、ユーザ機器（ＵＥ）および外部ネットワークと関連付けられたタイムセンシティブデータストリームをハンドリングするためのものである。この例示的な方法は、外部ネットワークから、タイムセンシティブデータストリームと関連付けられた伝送スケジュールを受信することと、ＲＡＮに、ＲＡＮと第１のＵＥとの間のデータストリームの通信のために無線リソースを割り当てる要求を送信することとを含み、該要求は、伝送スケジュールに関連した情報をさらに含む。本方法は、ＲＡＮから、データストリームと関連付けられた伝送スケジュールに合うように無線リソースを割り当てることができるかどうかを示す応答を受信することをさらに含む。本方法は依然として、データストリームのための設定情報を獲得することであって、該設定情報が、静的なままであるべきデータストリームと関連付けられたデータパケットのヘッダ内の１つまたは複数のフィールドについてのそれぞれの値を示す、設定情報を獲得することと、第１のＵＥへの設定情報の伝送を開始することと、外部データネットワークからデータストリームと関連付けられたデータパケットを受信することと、データパケットから１つまたは複数のフィールドを削除して、圧縮されたデータパケットを生成することと、第１のＵＥへの圧縮されたデータパケットの伝送を開始することとをさらに含む。
別の例示的な方法は、無線通信ネットワークと関連付けられた無線デバイスによって実施され、また、外部データネットワーク内のデータストリームと関連付けられたデータパケットの輸送のためのものである。この例示的な方法は、ＲＡＮのＲＢＳからＳＩを受信することであって、ＳＩがＲＢＳを通じたＴＳＮのためのサポートを示している、ＳＩを受信することと、ＲＢＳを通じて外部データネットワークとの少なくとも１つのＴＳＮデータストリームを確立することとを含む。この方法は、ＴＳＮデータストリームのための設定情報を獲得することであって、該設定情報が、静的なままであるべきＴＳＮデータストリームと関連付けられたデータパケットのヘッダ内の１つまたは複数のフィールドについてのそれぞれの値を示す、設定情報を獲得することと、ＲＢＳから、ＴＳＮデータストリームと関連付けられたデータパケットを受信することと、１つまたは複数のフィールドをデータパケットに追加して、圧縮解除されたデータパケットを生成することとをさらに含む。
別の例示的な方法は、ＲＡＮとの通信のために設定される無線デバイスによって実施され、また、外部ネットワークと関連付けられた伝送スケジュールに従ってＲＡＮ内のリソースをスケジューリングするためのものである。この例示的な方法は、ＲＡＮのＲＢＳからＳＩを受信することであって、ＳＩがＲＢＳを通じたＴＳＮのためのサポートを示している、ＳＩを受信することと、ＲＢＳを通じて外部データネットワークとの少なくとも１つのＴＳＮデータストリームを確立することとを含む。この例示的な方法は、外部ネットワークから、ＴＳＮデータストリームと関連付けられた伝送スケジュールを受信することと、ＲＢＳと関連付けられたネットワークに、無線デバイスとＲＢＳとの間のＴＳＮデータストリームの通信のために無線リソースを割り当てる要求を送信することであって、該要求が、伝送スケジュールに関連した情報をさらに含む、要求を送信することと、ネットワークから、ＴＳＮデータストリームと関連付けられた伝送スケジュールに合うように無線リソースを割り当てることができるかどうかを示す応答を受信することとをさらに含む。
同様に無線通信ネットワークと関連付けられた無線デバイスによって実施される別の例示的な方法は、無線通信ネットワークから第１のタイミング信号を受信することと、無線デバイスが接続される外部タイムセンシティブネットワーキング（ＴＳＮ）データネットワークから第２のタイミング信号を受信することとを含む。本方法は、無線通信ネットワーク内の無線基地局（ＲＢＳ）を通じて、外部ＴＳＮデータネットワークとの少なくとも１つのＴＳＮデータストリームを確立することと、外部ネットワークから、対応するＴＳＮデータストリームと関連付けられた伝送スケジュールを受信することとをさらに含む。
無線デバイスによって実施される依然として別の例示的な方法は、ＲＡＮのＲＢＳからＳＩを受信することであって、ＳＩがＲＢＳを通じたＴＳＮのためのサポートを示している、ＳＩを受信することと、ＲＢＳを通じて外部データネットワークとの少なくとも１つのＴＳＮデータストリームを確立することとを含む。この方法は、ＴＳＮデータストリームのための設定情報を獲得することをさらに含み、該設定情報は、静的なままであるべきＴＳＮデータストリームと関連付けられたデータパケットのヘッダ内の１つまたは複数のフィールドについてのそれぞれの値を示す。本方法は、ＲＢＳから、ＴＳＮデータストリームと関連付けられたデータパケットを受信することと、１つまたは複数のフィールドをデータパケットに追加して、圧縮解除されたデータパケットを生成することとをさらに含む。
無線通信ネットワークと関連付けられた無線デバイスによってここでも実施される別の方法は、無線通信ネットワーク内の無線基地局（ＲＢＳ）を通じて、外部ＴＳＮデータネットワークとの少なくとも１つのＴＳＮデータストリームを確立することと、ＴＳＮデータストリームのための設定情報を獲得することであって、該設定情報が、静的なままであるべきＴＳＮデータストリームと関連付けられたデータパケットのヘッダ内の１つまたは複数のフィールドについてのそれぞれの値を示す、設定情報を獲得することとを含む。本方法は、ＲＢＳから、ＴＳＮデータストリームと関連付けられたデータパケットを受信することと、１つまたは複数のフィールドをデータパケットに追加して、圧縮解除されたデータパケットを生成することとをさらに含む。
無線通信ネットワークと関連付けられた無線デバイスによって実施される依然として別の方法は、無線通信ネットワーク内の無線基地局（ＲＢＳ）を通じて、外部ＴＳＮデータネットワークとの少なくとも１つのＴＳＮデータストリームを確立することと、外部ネットワークから、対応するＴＳＮデータストリームと関連付けられた伝送スケジュールを受信することとをさらに含む。
さらに別の例示的な方法は、第１のデバイスによって実施され、また、モノのインターネット（ＩｏＴ）環境への第２のデバイスの登録を支援し、第２のデバイスを使用するためのものである。この例示的な方法は、第２のデバイスと関連付けられた登録機能の表現を獲得することであって、該登録機能が、第１および第２のデバイスと関連付けられた登録情報を含む少なくとも１つのシリアル化した登録アプリケーションと関連付けられる、登録機能の表現を獲得することと、第１のデバイスと関連付けられた登録情報が第２のデバイスと関連付けられた登録情報から分離されるように、登録アプリケーションをデシリアル化することと、第２のデバイスと関連付けられた登録情報に基づいて第２のデバイスを設定することによって、第２のデバイスによる第２のデバイスの登録プロセスの実行を開始するため、第２のデバイスと関連付けられた登録情報を第２のデバイスに伝送することとを含む。この方法は、第２のデバイスから、第２のデバイスと関連付けられた設定情報を受信することと、第１のデバイス上で実行する第１の実行時環境を使用して、第２のデバイス上で実行する第２の実行時環境にコードモジュールを移送することであって、該コードモジュールが、第２の実行時環境内で実行し、第２の実行時環境によってサポートされる第２のデバイスの機能を第１のデバイスに公開するように設定される、コードモジュールを移送することとをさらに含む。本方法は、第１の実行時環境内でアプリケーションを実行することであって、アプリケーションが、移送されたコードモジュールおよび第２の実行時環境を介して第２のデバイスの機能を遠隔で呼び出す、アプリケーションを実行することをさらに含む。
対応する一方法は、第２のデバイスによって実行され、また、第１のデバイスによって支援されるＩｏＴ環境への登録プロセスを実行し、第２のデバイスの機能へのアクセスを第１のデバイスに提供するためのものである。この例示的な方法は、第１のデバイスから、第２のデバイスと関連付けられた登録情報を受信することと、登録情報に基づいて第２のデバイスを設定することによって登録プロセスを実行することと、第２のデバイスと関連付けられた設定情報を第１のデバイスに伝送することとを含む。本方法は、第１のデバイス上で実行する第１の実行時環境から、第２のデバイス上で実行する第２の実行時環境へ、コードモジュールを受信して、第２の実行時環境によってサポートされる第２のデバイスの機能を第１のデバイスに公開することと、第２の実行時環境を使用して、第１の実行時環境内で実行するアプリケーションからのコードモジュールを介して受信される機能の遠隔呼出しに応答して第２のデバイスの機能の性能を制御することとをさらに含む。
これらおよび他の方法は、以下に詳細に説明され、また添付の図面に例証される。対応するデバイス、ネットワークノード、および同様のものもまた、詳細に説明され、これらの技術が有利に使用され得るネットワーク配置および環境についても同様である。
５Ｇシステムのネットワークの観点を示す図である。 インダストリ４．０の概念を示す図である。 オペレーションテクノロジ（ＯＴ：Ｏｐｅｒａｔｉｏｎｓ Ｔｅｃｈｎｏｌｏｇｙ）システムに統合されたスタンドアロン５Ｇ非公共ネットワークを示す図である。 公共広域ネットワークと連係動作する５Ｇ非公共ネットワークを示す図である。 ネットワークスライスの概念を示す図である。 ネットワーク全体にわたる４つの異なるスライスの例を示す図である。 ネットワークスライスの特徴を示す図である。 ネットワークをスライスためのメカニズムを示す図である。 ５ＧシステムにおけるＱｏＳを示す図である。 ネットワークスライス間のリソース分割を示す図である。 運動制御アプリケーションにおける実例の論理機能分割を示す図である。 クラウド内の制御機能を示す図である。 モデル化された無線リンクを介した遠隔ロボット制御のためのアーキテクチャを例証する図である。 協調的な製造業者アグノスティックロボット組立体の一例を例証する図である。 ＴＤＯＡジオロケーションの原理を示す図である。 異なる帯域幅を使用した、３ＧＰＰ屋内オープンオフィス（ＩＯＯ：Ｉｎｄｏｏｒ Ｏｐｅｎ Ｏｆｆｉｃｅ）シナリオにおける位置決めについての累積分布を示す図である。 ハイブリッド位置決めの原理を例証する図である。 スペクトルリーシングの規制上の観点を提供する図である。 モバイルサービスに割り当てられる周波数帯域についてのスペクトル割当て可能性を示す図である。 認可されたスペクトルを使用するローカルネットワークを例証する図である。 モバイルネットワークオペレータ（ＭＮＯ）などのライセンス保有者からのリーシングを使用したローカルネットワークを例証する図である。 ＣＢＲＳの特徴を示す図である。 高水準ＳＡＳアーキテクチャを示す図である。 ＰＡＬ保護エリアを例証する図である。 産業クラウドシナリオを示す図である。 単純な工場の状況における情報管理を例証する図である。 工場内の階層ネットワークアーキテクチャを例証する図である。 異なるパケットサービスおよびサービス品質関係を示す図である。 タイムセンシティブネットワーキング（ＴＳＮ）の概念を紹介する図である。 産業シナリオにおける一例示的なＴＳＮおよび５Ｇインターワーキングアーキテクチャを例証する図である。 ５Ｇを使用して非ＴＳＮデバイスをＴＳＮネットワークに接続するために仮想エンドポイントを使用することを示す図である。 ５ＧネットワークにまたがるＴＳＮ時間同期の図である。 ５Ｇシステムにおける複数の時間ドメインのサポートの図である。 工場ネットワークにおける複数の時間ドメインの図である。 時間ゲートされたキューイングの図である。 信頼性のためのフレームレプリケーションおよび排除の図である。 ＴＳＮ用の十分に分散型のモデルの図である。 ＴＳＮ用の集中型のネットワーク／分散型のユーザモデルの図である。 ＴＳＮ用の完全に集中型の設定モデルの図である。 ＣＵＣおよびＣＮＣから成る設定エージェントの図である。 ＣＮＣとＣＵＣとの間の対話の図である。 ＴＳＮ集中化設定モデルにおけるＴＳＮストリームセットアップを図示する信号フロー図である。 潜在的な５Ｇ－ＴＳＮ統合アーキテクチャセットアップの図である。 ＴＳＮ ＦＲＥＲセットアップの図である。 ＦＲＥＲをセットアップするための、ＡＦと、ＣＵＣと、ＣＮＣとの間の対話の図である。 ５Ｇネットワークを示している。 チェーンコントローラ概念の図である。 工場サイトにおけるコアネットワークデプロイメントの高レベル機能図である。 多接続用のＲＡＮの制御プレーンの図である。 多接続用のＲＡＮのユーザプレーンアーキテクチャの図である。 ＮＲについての様々な無線ベアラタイプの図である。 ミニスロットを使用する場合のレイテンシパフォーマンスの図である。 スロット境界制限をまたぐ送信に起因するロングアラインメント遅延の図である。 スロット境界をまたぐミニスロット繰り返しの使用の図である。 ＰＵＳＣＨでＵＣＩの省略を可能にする、ベータファクタの使用の図である。 ２シンボル周期性で、１ＯＦＤＭシンボルを占有するショートＰＵＣＣＨの図である。 ＤＣＩサイズ、ＵＥの数、およびＣＯＲＥＳＥＴサイズの関数として、監視オケージョン当たりのブロッキング確率の例の図である。 １再送信を伴うダウンリンクデータレイテンシの図である。 設定グラントおよび１再送信を伴うアップリンクデータレイテンシの図である。 ダウンリンクデータレイテンシの比較の図である。 グラントベースのアップリンクデータレイテンシの比較の図である。 設定グラントアップリンクデータレイテンシの比較の図である。 アップリンクＵＥ間プリエンプションの図である。 電力制御されたマルチプレクシングスキームにおける、ＭＣＳ１４のパフォーマンスの図である。 いくつかの異なる変調符号化スキームについての、１送信後のＰＤＳＣＨ ＢＬＥＲの図である。 多地点協調およびアップリンクプリコーディングを伴う場合と、伴わない場合の、様々なマルチアンテナ技法についてのアップリンクＳＩＮＲの図である。 スケジューリング要求（ＳＲ）およびバッファステータスレポート（ＢＳＲ）動作の例の図である。 異なるトラフィックにマッピングされた複数のＳＲ設定の図である。 進行中のロングＵＬ－ＳＣＨ送信に起因する遅延したＳＲの図である。 ＳＲ手順を介する動的グラントを取得する際の遅延の図である。 設定グラントＴｙｐｅ １手順の図である。 設定グラントＴｙｐｅ １手順の図である。 様々な到来およびペイロードサイズを伴う、産業用確定的ストリームの図である。 様々なパターン、周期性、レイテンシ、および信頼性要件を伴う、産業用確定的ストリームの図である。 オーバラッピング設定の図である。 論理チャネル優先順位付け（ＬＣＰ）手順の例の図である。 ロバストなグラント上で非クリティカルなトラフィックを送ることに伴う問題の図である。 図７７の問題を回避するための制限の図である。 非ロバストなショートグラント上でクリティカルなトラフィックを送ることにより生ずる余分なレイテンシの図である。 図７９の問題を回避するための制限の図である。 設定グラントをオーバライドする動的グラントに伴う問題の図である。 設定グラントが条件付きで動的グラントをオーバライドできるようにすることの利点の図である。 異なるＰＵＳＣＨ持続時間でオーバラップするグラントの図である。 ネットワーク効率を高度化するためのＵＥ内プリエンプションのイネーブル化の図である。 デュアルキャリア（ＤＣ）およびキャリアアグリゲーション（ＣＡ）シナリオにおけるパケット複製の図である。 複製を伴う場合と、複製を伴わない場合の、残存誤差の図である。 ユニバーサル時間ドメインおよびワーキングクロックドメインの図である。 ＳＦＮ送信の図である。 ３つの時間ドメインを伴う産業用ユースケースの図である。 連続的なＰＴＰチェーンメソッドの図である。 ＩＥＥＥ８０２．３ＭＡＣフレームフォーマットの例の図である。 イーサネットヘッダ圧縮からのゲインの図である。 可能なイーサネットヘッダ圧縮アンカーポイントの図である。 ＰＤＣＰ複製の事例における、無線リンク障害（ＲＬＦ）の図である。 例示的なモビリティ手順の図である。 ＯＳＩモデルにマッピングした産業用ＩｏＴプロトコルスタックの可能な実現化の図である。 産業用イーサネットカテゴリー化の図である。 Ｐｒｏｆｉｎｅｔで使用されるような時間－スケジューリングされた送信の図である。 Ｐｒｏｆｉｎｅｔ ＩＲＴ用のフレーム構造の図である。 負荷が増大し、Ｅ２Ｅレイテンシ要件が大きくなる場合の、信頼性の観点から異なる無線技術の推定されるパフォーマンスの図である。 Ｗｉ－Ｆｉにおける典型的なチャネルアクセスおよびデータ交換の図である。 Ｗｉ－Ｆｉにおけるチャネルアクセスの図である。 Ｍｉｎｓｔｒｅｌアルゴリズムのシミュレーションの図である。 ＯＰＣ－ＵＡの可能なプロトコルスタックの図である。 ＴＳＮ上のＯＰＣ－ＵＡの図である。 ＩＥＥＥ標準８０２．１Ｑｂｖ－２０１５で規定されるような、分散型の時間センシティブなネットワーキング（ＴＳＮ）設定モデルを図示するブロック図である。 ＩＥＥＥ標準８０２．１Ｑｂｖ－２０１５で規定されるような、集中型ＴＳＮ設定モデルを図示するブロック図である。 ＩＥＥＥ標準８０２．１Ｑｂｖ－２０１５で規定されるような、完全に集中型のＴＳＮ設定モデルを図示するブロック図である。 図１０８に示される完全に集中型の設定モデルを使用する例示的なＴＳＮストリーム設定手順のシーケンス図である。 例示的な５Ｇ無線ネットワークの、制御プレーン（ＣＰ）およびデータまたはユーザプレーン（ＵＰ）アーキテクチャを図示するブロック図である。 図１１０に示される５Ｇネットワークアーキテクチャと例示的な完全に集中型のＴＳＮネットワークアーキテクチャとの間のインターワーキングのための例示的な配置を図示するブロック図である。 ＩＥＥＥ標準８０２．１Ｑｂｖ－２０１５で規定されるような、ゲートに基づいてトラフィックキュー間で送信選択を図示するブロック図である。 本開示の様々な例示的な実施形態による、５ＧおよびＴＳＮネットワークを介する、２つのＴＳＮトーカ／リスナユニット間の例示的な通信シナリオを図示するブロック図である。 本開示の様々な例示的な実施形態による、図１１３に示されるネットワーク設定を介するＴＳＮストリームパケットのタイムリーな送達を設定するための、例示的な方法および／または手順のシーケンス図である。 本開示の様々な例示的な実施形態による、５Ｇネットワークを介する、ＴＳＮトーカ／リスナユニットと仮想化コントローラとの間の例示的な通信シナリオを図示するブロック図である。 本開示の様々な例示的な実施形態による、図１１５に示されるネットワーク設定を介するＴＳＮストリームパケットのタイムリーな送達を設定するための、例示的な方法および／または手順のシーケンス図である。 本開示の様々な例示的な実施形態による、コアネットワーク（例えば、５Ｇコアネットワーク）内のネットワークノードによって実施される例示的な方法および／または手順を図示するフロー図である。 本開示の様々な例示的な実施形態による、無線アクセスネットワーク（例えば、ＮＧ－ＲＡＮ）内のネットワークノードによって実施される例示的な方法および／または手順を図示するフロー図である。 本開示の様々な例示的な実施形態による、ユーザ機器（ＵＥ）によって実施される例示的な方法および／または手順を図示するフロー図である。 本開示の様々な例示的な実施形態による、例示的な通信システムのブロック図である。 本開示の様々な例示的な実施形態による、様々な方法で設定された例示的な無線アクセスノードのブロック図である。 本開示の様々な例示的な実施形態による、様々な方法で設定された例示的な無線アクセスノードのブロック図である。 本開示の様々な例示的な実施形態による、様々な方法で設定された例示的な無線アクセスノードのブロック図である。 本開示の様々な例示的な実施形態による、様々な方法で設定された例示的な無線デバイスまたはＵＥのブロック図である。 本開示の様々な例示的な実施形態による、様々な方法で設定された例示的な無線デバイスまたはＵＥのブロック図である。 ５Ｇコアネットワーク（５ＧＣＮ）機能および無線アクセスネットワーク（ＲＡＮ）の図である。 イーサネットＰＤＵタイプデータ．１についてのプロトコルスタックの図である。 ＴＳＮフレーム構造の図である。 本開示の実施形態による、ダウンリンクシグナリングについてのシグナリング図である。 本開示の実施形態による、アップリンクシグナリングについてのシグナリング図である。 いくつかの実施形態による方法の図である。 いくつかの実施形態による別の方法の図である。 いくつかの実施形態による別の方法の図である。 いくつかの実施形態による別の方法の図である。 無線アクセスネットワーク上の時間センシティブなネットワーキングをハンドリングする方法を実装するためのフローチャートである。 無線アクセスネットワーク上の時間センシティブなネットワーキングを通知する方法を実装するためのフローチャートである。 無線アクセスネットワーク上の時間センシティブなネットワーキングのための設定メッセージを配信する方法を実装するためのフローチャートである。 通信システムの第１の例の概略ブロック図である。 通信システムの第２の例の概略ブロック図である。 通信システムの第３の例の概略ブロック図である。 通信システムの第４の例の機能ブロック図である。 通信システム用の第１の概略シグナリング図である。 通信システム用の第２の概略シグナリング図である。 ５ＧとＴＳＮとのインターワーキングの図である。 工場における複数のＴＳＮ ｇＰＴＰ時間ドメインの図である。 ＢＳがどのようにＵＥをセル側の参照時間に同期させるかの図である。 デバイスが、ＴＳＮドメインへのセルラリンクで接続されると想定されるシナリオである。 セルラリンクで仮想コントローラに接続されるＴＳＮドメインを想定する店舗フロアシナリオである。 ２つのＴＳＮネットワークがセルラリンクで接続されるシナリオである。 例示的な同期手順の図である。 別の例示的な同期手順の図である。 例示的な同期手順についてのシーケンスフローである。 別の例示的な同期手順についてのシーケンスフローである。 本明細書で開示される方法を使用するＰＴＰ時間送信の図である。 無線デバイスによって実施される例示的な方法の図である。 無線ネットワーク内の仮想装置の概略ブロック図である。 基地局などのネットワークノードによって実施される例示的な方法の図である。 無線ネットワーク内の仮想装置の概略ブロック図である。 無線デバイスによって実施される例示的な方法の図である。 無線ネットワーク内の仮想装置の概略ブロック図である。 基地局などのネットワークノードによって実施される例示的な方法の図である。 無線ネットワーク内の仮想装置の概略ブロック図である。 本明細書の実施形態による、フローチャートとシグナリングスキームの組み合わせである。 本明細書の実施形態による、設定をハンドリングするためのＵＥを描いたブロック図である。 本明細書の実施形態による、無線通信ネットワーク内で設定をハンドリングするための無線ネットワークノードを描いたブロック図である。 本明細書の実施形態による、例示的な無線デバイスのブロック図である。 本明細書の実施形態による、例示的な無線ネットワークノードのブロック図である。 いくつかの実施形態による、モノのインターネット（ＩｏＴ：Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）環境におけるデバイスのエンロールメントを支援するための方法を示す図である。 いくつかの実施形態による、モノのインターネット（ＩｏＴ）環境においてエンロールメントするための方法を示す図である。 いくつかの実施形態による、エンロールメント処理を示す概略図である。 いくつかの実施形態による、実例の方法ステップを示す流れ図である。 いくつかの実施形態による実例の配置を示すブロック図である。 いくつかの実施形態による実例の配置を示すブロック図である。 １つまたは複数の実施形態による実例のネットワーク環境を示すブロック図である。 １つまたは複数の実施形態によるエンティティ間の実例のシグナリングを示すコールフロー図である。 １つまたは複数の実施形態による第１のデバイスによって実行される実例の方法を示す流れ図である。 １つまたは複数の実施形態による第２のデバイスによって実行される実例の方法を示す流れ図である。 １つまたは複数の実施形態による実例のハードウェアを示すブロック図である。 １つまたは複数の実施形態による実例の第１のデバイスを示すブロック図である。 １つまたは複数の実施形態による実例の第２のデバイスを示すブロック図である。 本明細書で説明されるような様々な態様による連合データベースに問い合わせるためのシステムの１つの実施形態の流れ図である。 本明細書で説明されるような様々な態様による連合データベースに問い合わせるためのシステムの別の実施形態の流れ図である。 本明細書で説明されるような様々な態様による連合データベースを備えるネットワークノードの１つの実施形態を示す図である。 本明細書で説明されるような様々な態様による連合データベースを備えるネットワークノードの別の実施形態を示す図である。 本明細書で説明されるような様々な態様による、同じまたは異なる裁判管轄内に位置する１つまたは複数の自律的または準連合データベース（ｓｕｂ－ｆｅｄｅｒａｔｅｄ ｄａｔａｂａｓｅ）を表す連合データベースを備えるネットワークノードによって実施される方法の１つの実施形態を示す図である。 本明細書で説明されるような様々な態様による、同じまたは異なる裁判管轄内に位置する１つまたは複数の自律的または準連合データベースを表す連合データベースを備えるネットワークノードによって実施される方法の１つの実施形態を示す図である。 本明細書で説明されるような様々な態様による自律的データベースを備えるネットワークノードの１つの実施形態を示す図である。 本明細書で説明されるような様々な態様による自律的データベースを備えるネットワークノードの別の実施形態を示す図である。 本明細書で説明されるような様々な態様による、連合または準連合データベースによって表された、一定の裁判管轄内の自律的データベースを備えるネットワークノードによって実施される方法の実施形態を示す図である。 本明細書で説明されるような様々な態様による、連合または準連合データベースによって表された、一定の裁判管轄内の自律的データベースを備えるネットワークノードによって実施される方法の実施形態を示す図である。 本明細書で説明されるような様々な態様による連合データベースに問い合わせるためのシステムの別の実施形態を示す図である。 本明細書で説明されるような様々な態様による連合データベースに問い合わせるためのシステムの別の実施形態を示す図である。 本明細書で説明されるような様々な態様による連合データベースに問い合わせるためのシステムの別の実施形態を示す図である。 本明細書で説明されるような様々な態様による連合データベースに問い合わせるためのシステムの別の実施形態を示す図である。 本明細書で説明されるような様々な態様によるネットワークノードの１つの実施形態を示す図である。 ３ＧＰＰ ＴＳ２９．５６１からのＵＰＦにおけるイーサネットフレームハンドリングを示す概略ブロック図である。 産業用セットアップにおいて連係動作する５Ｇ－ＴＳＮを示す概略ブロック図である。 仮想エンドポイントを伴うＴＳＮ制御およびデータプレーンを示す概略ブロック図である。 異なるＰＤＵセッションタイプのためのＵＰＦの一部としてのＶＥＰ展開を示す概略ブロック図である。 外部ＴＳＮネットワーク設定によって見られるようなＶＥＰを示す概略ブロック図である。 いくつかの実施形態による実例の方法ステップを示す流れ図である。 いくつかの実施形態による実例の方法ステップを示す流れ図である。 いくつかの実施形態による実例の方法ステップおよびシグナリングを示す組み合わされた流れ図兼シグナリング図である。 いくつかの実施形態による実例の方法ステップおよびシグナリングを示す組み合わされた流れ図兼シグナリング図である。 いくつかの実施形態による実例の装置を示す概略ブロック図である。 冗長経路を使用するＴＳＮデータストリームの伝送を示す図である。 本開示の実施形態による通信システムを示す図である。 本開示の実施形態によるシグナリング図である。 本開示の実施形態による無線ネットワークにおける冗長経路を示す概略図である。 さらに本開示の実施形態による無線ネットワークにおける冗長経路を示す概略図である。 さらに本開示の実施形態による無線ネットワークにおける冗長経路を示す概略図である。 本開示の実施形態によるコアネットワークノードにおける方法の流れ図である。 本開示の実施形態による設定ノードにおける方法の流れ図である。 ＰＴＰヘッダフォーマットを示すテーブルである。 無線通信ネットワークの実施形態を示す概略ブロック図である。 本明細書における実施形態による伝送デバイスによって実施される方法を描写する流れ図である。 本明細書における実施形態による受信デバイスによって実施される方法を描写する流れ図である。 本明細書におけるいくつかの実施形態による、ブロードキャストを使用する５ＧＳにおける複数の時間ドメインサポートの実施形態を示す概略ブロック図である。 本明細書におけるいくつかの実施形態による、関連するｇＰＴＰフレームだけの場合の５ＧＳにおける複数の時間ドメインサポートの実施形態を示す概略ブロック図である。 本明細書におけるいくつかの実施形態による、５ＧＳにおける複数の時間ドメインサポートの実施形態を示す概略ブロック図である。 本明細書における実施形態による伝送デバイスによって実施される方法を描写する流れ図である。 本明細書における実施形態による受信デバイスによって実施される方法を描写する流れ図である。 いくつかの実施形態による、ホストコンピュータに中間ネットワークを介して接続された通信ネットワークを概略的に示す図である。 いくつかの実施形態による、部分無線接続で基地局を介してユーザ機器と通信するホストコンピュータの一般化したブロック図である。 ホストコンピュータ、基地局、およびユーザ機器を含む通信システムで実行される実例の方法を示す流れ図である。 ホストコンピュータ、基地局、およびユーザ機器を含む通信システムで実行される実例の方法を示す流れ図である。 ホストコンピュータ、基地局、およびユーザ機器を含む通信システムで実行される実例の方法を示す流れ図である。 ホストコンピュータ、基地局、およびユーザ機器を含む通信システムで実行される実例の方法を示す流れ図である。
以下は、５Ｇに関する要件およびユースケースに対処するためにターゲットにされる無線通信ネットワークの多くの態様についての、概念、システム／ネットワークアーキテクチャ、および詳細デザインの詳細な説明である。用語「要件（ｒｅｑｕｉｒｅｍｅｎｔ）」、「必要性（ｎｅｅｄ）」、または同様の言葉は、一定の実施形態の有利なデザインという意味でのシステムの望ましい特徴または機能を説明するものとして理解され、全ての実施形態の必要または不可欠な要素を示すわけではないものとして理解されることになる。したがって、以下では、同様の言葉で、要求される、重要である、必要である、または説明されるような、説明される各要件および各能力は、任意選択であるものとして理解されることになる。
オペレーションテクノロジ通信システムおよび５Ｇ
今日、様々な技術が産業用通信システムで使用される。工場における製造システムのために、図２の左側に描写されているような階層型の通信構造が使用される（しばしばオートメーションピラミッドと呼ばれる）。このデザインは、ＩＳＡ９５／９９モデルに基づいている。産業用機器は、例えば、プロダクションセルをカバーする、小さいサブシステム内で接続される。これらのサブシステムは、ゲートウェイによって分離され、異なる通信技術を使用することができ、各サブシステムは、クリティカル通信性能を保証できるように密接に管理される。次に高いレベルでは、これらのサブシステムは、例えば、プロダクションセル間の協調、および、プロダクションシステムの監督制御のために、相互接続される。製造作業に関連したこの部分は、クリティカル通信を含むオペレーションテクノロジ（ＯＴ）ドメインと呼ばれ、ここで、要件は、典型的には、より低いレベルに対するより大きい要求になる。クリティカル通信は、今日、フィールドバスまたは産業用イーサネットのような有線通信技術に主に基づいている。ネットワークのＯＴ部分は、企業アプリケーションおよびサービスを含むネットワークのＩＴ部分から安全に分離される。
サイバーフィジカルプロダクションシステムに製造を変換することによって、柔軟性および効率性を向上させるために、製造システムのより広範囲のデジタル化が予想される。このような推移は、第４の産業革命、またはインダストリ４．０とも呼ばれる。プロダクションシステム全体がデジタルツインでモデル化され、監視され、評価され、操縦される可能性があることが想定される。そのためにも、図２の右側に示されるような、製造現場レベルでの接続孤島（ｉｓｏｌａｔｅｄ ｃｏｎｎｅｃｔｉｖｉｔｙ ｉｓｌａｎｄ）を回避する、工場全体にわたる完全な接続が望まれる。ネットワークの異なるドメインの分離は、これにより、（ゲートウェイを介した）物理的分離から論理的分離に移される。この推移では、クリティカル通信と非クリティカル通信との間で共有される共通イーサネットインフラストラクチャでの一定のトラフィックフローに、保証された高性能接続サービスを提供することができるので、ＩＥＥＥ８０２．１のタイムセンシティブネットワーキング（ＴＳＮ：Ｔｉｍｅ－Ｓｅｎｓｉｔｉｖｅ Ｎｅｔｗｏｒｋｉｎｇ）が中心的役割を果たす。完全に標準化されたソリューションとして、これは、今日存在する複数の独自のフィールドバス技術の、グローバル規格への集中も可能にする。
無線接続は、製造システムに大きな価値をもたらすことができる。無線接続は、大規模なケーブル配線を回避することによって、コストを節約することができ、有線では実現できない新しいユースケースをサポートすることができる（例えば、モバイル構成要素を接続すること）。しかし、具体的には、無線接続は、製造現場の再設計に、かなりの柔軟性をもたらし、インダストリ４．０への主要なトレンドである。今日、製造現場での無線技術の使用は非常に限定的であり、様々な異なる技術を介して提供される非クリティカル通信に焦点が合っている。クリティカル通信サービスのために、今日、信頼でき、決定的な低レイテンシを提供できる無線技術はない。
５Ｇは、ｅＭＢＢおよびｍＭＴＣを同時にサポートしつつ、信頼できる決定的な低レイテンシサービスを提供することを約束する。（５Ｇ ｍＭＴＣは、ＮＲキャリアに組み込むことができるＬＴＥ－ＭおよびＮＢ－ＩｏＴに基づいていることに留意されたい。最終的には、ＮＲベースのｍＭＴＣモードが期待される。）このために、５Ｇは、有線接続のためにＴＳＮが行っていることと同様の役割を無線側で果たすことができる。５Ｇは、全てのサービスタイプを集中させる汎用のグローバルに標準化された技術を提供し、製造現場通信のはるかに広いフィールドに無線接続を拡散させることができる。
ＴＳＮには、５Ｇのために果たすべきさらなる役割がある。産業用ネットワークは、寿命の長い設備であり、工場の大多数に既に展開している。既存の利用されなくなった設備への新しい技術の展開は遅く、厄介である。ＴＳＮは、構築の実践の再設計をトリガすることが期待され、これは、可能ならば、産業の利用されなくなったネットワークにさえ入ることを期待される。無線の同等物としてＴＳＮに５Ｇにリンクすることによって、ＴＳＮは、利用されなくなった市場を変換するのに役立てるための市場解放の機会をもたらす。これは、５ＧアーキテクチャのソリューションがＴＳＮと主に適合される必要性を動機づける。
５Ｇの統合は、いくつかの要件に対処しなければならない。
・ローカルコンテンツ：プロダクション関連データは、産業／工場敷地を離れることができない、すなわち、全てのこのようなデータは、例えばセキュリティおよび信用のために、ローカルに保存されなければならない。
・クリティカル接続の完全制御：クリティカル通信は、産業エンドユーザの制御下にあり、割込みのない動作を管理するオペレーションシステムにリンクされなければならない。
・ローカル管理：管理ソリューションは、産業のビジネスおよび運用プロセスと統合しやすく、ネットワーク可観測性を含まなければならない。
・ローカル生存性：接続ソリューションは、何らかの外部故障によって決まるものではない、すなわち、接続ソリューションは、生存性に至るとき、自己完結型でなければならない。
・ライフサイクル管理（ＬＣＭ：Ｌｉｆｅ Ｃｙｃｌｅ Ｍａｎａｇｅｍｅｎｔ）：いくつかの産業界は、何十年もの範囲にまたがってＬＣＭを必要とする。これは、デバイス設定、ファームウェア更新、アプリケーションソフトウェア更新、識別情報証明の提供、インストール、現場での提供およびメンテナンスのための方式を含む、産業用デバイスおよびネットワークインフラストラクチャの長期の可用性が必要であることを意味する。
・セキュリティ：接続ネットワークは、認証されたトラフィックだけが許可され、機密性保護の要求レベル（例えば、暗号化および／または完全性保護）が適用されることを保証しなければならない。インターネットからの侵入（ハッカー）、マルウェアがデバイスおよびサーバに達すること、データの改ざん等からの保護のような機能も、サポートされなければならない。異なるセキュリティゾーンのサポートは、有効にされなければならない。また、ネットワークインフラストラクチャ自体は、安全であり、外部攻撃から保護されなければならない。
・既存のソリューションとの統合：接続ソリューションは、既存の有線ＯＴシステム、および他の無線接続デバイスに統合されなければならない。１つの例は、産業用イーサネットフレームのトランスポートである。
システムアーキテクチャ
図３に示されるような産業用システムに統合された５Ｇネットワークは、以下の機能を必要とする。
・決定的性能を伴う全てのサービスカテゴリのＵＲＬＬＣ、ｅＭＢＢ、およびｍＭＴＣを含む、無線接続、携帯性サポート、サービス管理、およびＱｏＳを含む、５Ｇ接続のための５Ｇ無線アクセスおよびコアネットワーク
・高可用性および冗長性
・プライベートネットワークサービスを可能にするネットワーク識別情報（すなわち、ネットワークアクセスおよびネットワークサービスをデバイスの規定されたグループに制限すること）
・セキュア証明に基づくセキュリティソリューション
・ポジショニングおよび時刻同期のサポート
・ネットワーク監視およびＱｏＳ保証メカニズム
・軽量ネットワーク管理ソリューション
・産業用アプリケーションのための決定的性能および高可用性を伴うクラウドコンピューティングインフラストラクチャ
・既存の産業システムと統合する能力（すなわち、接続性、クラウドコンピューティングインフラストラクチャ、管理システム）
・工場内外のサービス継続性が要求される場合の、外部公共ネットワークと連係動作する能力
５Ｇシステムは、種々の変形形態で展開することができる。専用スペクトルへのローカルアクセス権を産業ユーザが取得できる場合、図３に描写されるように、スタンドアロンローカル５Ｇシステムを展開することができる。このようなスタンドアロン５Ｇネットワークは、例えばローミングを介して、公共ネットワークと連係動作することを可能にすることができる。代替として、２つの（または３つ以上の）ネットワークの物理インフラストラクチャに基づく論理ネットワークスライスを作り出すことによって、連合ネットワークスライシングを適用することができる。
ローカル５Ｇシステムは、図４に描写されているような、産業立地における公共モバイルネットワークオペレータによって提供される非公共ネットワークサービスとしても実現することができる。ネットワークインフラストラクチャの少なくとも一部のオンサイトでのローカル展開が、典型的には必要である。オンサイトデータの大発生は、低レイテンシを保証し、サイトを離れない情報のデータプライバシポリシを可能にする。コア制御機能は、外部のＭＮＯサイトから提供することができ、または、例えばローカル生存性をサポートするために、完全または部分的にオンサイトにあってもよい。クリティカル通信サービスは、ローカル大発生を介してオンサイトで保存されるが、他のいくつかの機能は、データセッションの外部終了も使用することができる。
スタンドアロンローカルネットワークと公共ＭＮＯネットワークとの組合せも、２つのネットワークドメインにわたる非公共ネットワークサービスを提供するための基礎として使用することができる。産業ユーザは、公共ネットワークインフラストラクチャとともに、連合ネットワークスライシングを介して非公共ネットワークサービスを提供するオンサイトのローカルネットワークを展開してもよい。例えば、ローカル展開は、ローカルカバレッジ、可用性、容量、およびコンピューティングリソースの観点から、公共ネットワークを「強くする」ために展開されてもよい。
ローカルネットワークは、ローカルスタンドアロンネットワークを提供することに加えて、公共ネットワークをサイトで拡張することによって、ニュートラルホスト能力も提供することができる。このために、マルチオペレータコアネットワーク（ＭＯＣＮ）またはマルチオペレータ無線アクセスネットワーク（ＭＯＲＡＮ）などのネットワーク共有ソリューションを適用することができる。共有ネットワークのアプローチでは、異なるサポートネットワーク（またはネットワークスライス）に、保証されたリソースおよび性能をもたらすことができるリソース管理ソリューションが必要である。ローカルネットワークプロバイダと公共ネットワークプロバイダの両者のために、ネットワーク共有ソリューションをうまく動機づけることができる。ローカルプロバイダは、フリーのローカルサイトをＭＮＯに提供することができ、一方で、ＭＮＯは、そのスペクトルリソースをネットワークに提供することができる。公共サービスとプライベートサービスを同じ基地局がサポートできるので、ローカルネットワークと公共ネットワークとの間の一部の改善された共存が可能になるはずである。さらに、共有ソリューションを、種々のサービスによって動機づけることができる。例えば、公共ＭＮＯは、例えば、電話通信、モバイルブロードバンド、およびＩＴ接続といった、産業サイトでの従来の企業サービスを提供することができ、一方で、プライベートスタンドアロンローカルネットワークは、ローカル産業用ＯＴ接続のために使用される。
産業用モノのインターネット（ＩｏＴ）のためのネットワークスライシング
産業用ＩｏＴネットワークソリューションを有効にする、または実現するための１つのアプローチとして、ネットワークスライシングが考えられる。ネットワークスライシングは、共通の共有インフラストラクチャ上に、分離および孤立した論理ネットワークを提供することができる。これは、例えば、以下を行うために使用することができる。
・工場内で異なるセキュリティゾーンを分離すること
・例えば、非クリティカル通信からクリティカル通信を孤立させるために、異なるサービスカテゴリを分離すること
・公共モバイル通信のためにさらに使用される公共ネットワークインフラストラクチャ上で非公共ＩＩｏＴネットワークを提供すること
ネットワークスライシングは、プロバイダネットワークを眺め、実現する概念的な方式である。複数の目的にかなう単一かつモノリシックネットワークの普及した観念の代わりに、仮想化およびＳＤＮなどの技術進歩により、我々は、共通および共有インフラストラクチャ層の最上位で論理ネットワークを構築することができる。
これらの「論理ネットワーク」は、「ネットワークスライス」と呼ばれることもあるが、特定のビジネスのため、またはことによると、（プロバイダの）特定の顧客のために確立される。これらは、エンドツーエンドであり、意図したビジネス目的の背景で完了する。これらは、要求される能力およびリソース全てを含む、独自のネットワークであり、独自のネットワークのようにふるまう。これは、インフラストラクチャリソースの共有から、設定されたネットワーク機能を通じて、ネットワーク管理、またはことによるとＯＳＳ／ＢＳＳ能力まで、幅広く拡張する。これは、モバイルおよび固定両方のネットワーク構成要素を包含する。１つの予想は、種々のスライスが、共通物理リソースを共有したとしても、独立し、孤立しているというものであり、したがって、懸念の分離をもたらす。ネットワークスライスは、複数の物理ネットワークインフラストラクチャ全体に及ぶものと規定することができ、連合ネットワークスライシングと呼ばれることもある。これは、ローミングに対する代替ネットワーク認識を可能にすることさえ提供することができる。
サービスを実現するために既存ネットワークがちょうど構築されたときに、ネットワークスライスも構築される。これらは、これら自体におけるサービスではないが、１つまたはいくつかのサービスを実現するために構築される。特殊なケースとして、サービス（またはそのインスタンス）は、ネットワークスライスと１対１にマッピングし、例えば、卸売りタイプのサービスを可能にする。リソース（物理的または論理的）は、スライスに専用、すなわち分離したインスタンスであってもよく、または、複数のスライスにわたって共有されてもよい。これらのリソースは、プロバイダの中で必ずしも全て生み出されるわけではなく、実際には、例えば、アグリゲーション、ローミング等を容易にする、他のプロバイダから購入されるサービスであってよいものもある。
ネットワークスライスは、図５に示されるように、リソースのセットを備えるものと規定することができる。これは、スライスに配分された割当てもしくはプロフィールである物理リソース、またはことによると、動機づけられる場合、専用物理リソースであってもよい。スライスは、また、設定されたネットワーク機能、管理機能、ＶＰＮ等などの論理エンティティを備えるものと規定することができる。リソース（物理的または論理的）は、スライスに専用、すなわち分離したインスタンスであってもよく、または、複数のスライスにわたって共有されてもよい。これらのリソースは、プロバイダの中で必ずしも全て生み出されるわけではなく、実際には、例えば、アグリゲーション、ローミング等を容易にする、他のプロバイダから購入されるサービスであってよいものもある。ネットワークスライシングは、例えば、関連付けたサービスレベル契約（ＳＬＡ：ｓｅｒｖｉｃｅ－ｌｅｖｅｌ ａｇｒｅｅｍｅｎｔ）でのネットワーク容量のリースを可能にする。
スライスが新しいビジネス要件または顧客に対処するために作り出される可能性があり、変化に適合させなければならない可能性があるとき、スライスは、スライスを作り出す、変更する（例えば、アップグレードする）、または除去する役割を担う、新しいタイプのライフサイクル管理機能を必要とする。ネットワークスライシングは、スライスが使用されている特定のユースケースに最適化された種々のネットワークアーキテクチャを可能にする。種々のネットワークスライスのためのこの最適化は、機能ドメインにおける、および、ネットワーク内の異なる機能の地理的展開における、両方の最適化を含むことができる。これは、ネットワークを通じた４つの異なるスライスの例を示す図６で見ることができる。これらは、コスト効率がよくタイムリーな手法での、他の第三者またはサービスプロバイダからの産業固有のサービスおよびまたはアプリケーションを含む、これらをサービスプロバイダがサポートすることも予期する。
ネットワークスライシングについての規定には２つの要素がある。一般的な規定については、「モバイルオペレータの視点から、ネットワークスライスは、取り決められたサービス品質を提供することができる、共有物理インフラストラクチャ上で動く独立したエンドツーエンド論理ネットワークである。」というＧＳＭＡからのものが使用される。この一般的な規定に加えて、上記を実現するいくつかの実装形態が存在し、「ネットワークスライシング」が言及されるときをしばしば意味する。最も突出したものは、５Ｇコア仕様書「Ｓｙｓｔｅｍ Ａｒｃｈｉｔｅｃｔｕｒｅ ｆｏｒ ｔｈｅ ５Ｇ Ｓｙｓｔｅｍ（５ＧＳ），Ｓｔａｇｅ２」、３ＧＰＰ ＴＳ２３．５０１、ｖ．１５．４．０（２１０８年１２月）：「ネットワークスライス：特定のネットワーク能力およびネットワーク特性を提供する論理ネットワーク［…］ネットワークスライスは、ＰＬＭＮ内で規定され、コアネットワーク制御プレーンおよびユーザプレーンネットワーク機能を含まなければならない［…］」から来ている。上記の規定を少なくとも部分的に実現する方法は、５Ｇに限定されず、４Ｇネットワークでも利用可能である。
これらの規定について、基本的なネットワークスライスを図７に従って説明することができる。
・共有物理インフラストラクチャがある（図７の（１）参照）。
・１つまたは複数の独立したエンドツーエンド論理ネットワーク（図７の（２）参照）が規定され、以下を備える。
ａ．コアネットワーク制御プレーン
ｂ．ユーザプレーンネットワーク機能
・これらの論理ネットワークは、取り決められたサービス品質、もしくは指定されたサービス能力、または、言い換えれば、ネットワークスライス能力についてのサービスレベル契約（ＳＬＡ）（図７の（３）参照）をサポートすることができる。
ネットワークスライスが規定されると、第１の問題は、対応するネットワークスライスを通じてどのようにデータトラフィックフローが割り当てられるか、またはルートされるかである。多くの場合、単一のデバイスは、単一のスライスしか使用しておらず、したがって、特定のネットワークスライスに各ＵＥを割り当てることによって配分することができる。それでも、場合によっては、デバイスが、複数のスライスのためにトラフィックをサーブすることができる。
特定のサービス性能およびＱｏＳを提供するためのサービス処置のためのモバイルネットワークにおけるベースラインは、デディケーテッドベアラであり、デディケーテッドベアラは、特定のユースケースまたはサービスの要件を満たすためのソリューションであることが多い。無線アクセスネットワーク（ＲＡＮ）では、デディケーテッドベアラは、ベアラ固有のＱｏＳをかなえるためにスケジューラによって使用することができる無線ベアラにマッピングする。特定のリソースは、一定のデディケーテッドベアラのために確保しておくことができる。ネットワークエッジにおいて、ベアラは、５－ｔｕｐｌｅのソースＩＰアドレス、宛先ＩＰアドレス、ソースポート番号、宛先ポート番号、およびプロトコル（ＵＤＰまたはＴＣＰ）のような、パケットヘッダに対するフィルタに基づいて個別に識別し、扱うことができる。
図８は、ネットワークをスライスするための４つの利用可能な４Ｇ方法を示す。第１の１つについて、ＲＡＮ共有が適用され、ｅＮＢが複数のＰＬＭＮ ＩＤを知らせることができるようにする。このアプローチを利用するために、ＲＡＮおよびコアは、ＰＬＭＮ ＩＤを知らせて、トラフィックが正しいコアネットワークとの間で適切にルートされることを保証するために、この特徴をサポートしなければならない。ＵＥは、好ましい（ホーム）ネットワークを備えることを含む、ネットワーク選択の普通の手順に基づいてＰＬＭＮを選択する。ＵＥは、（マルチＳＩＭ ＵＥの場合を除いて）１つのＰＬＭＮによってのみサーブされることが可能である。現在、このソリューションは、あらゆるＵＥによって、および、少なくともいくつかのネットワーク側システムによってサポートされる。
第２のソリューションは、ＵＥにおいて設定されたアクセスポイント名（ＡＰＮ：Ａｃｃｅｓｓ Ｐｏｉｎｔ Ｎａｍｅｓ）によって決まる。この場合、１つのＰＬＭＮ ＩＤがＲＡＮによって知らされるが、ユーザプレーンのトラフィックは、ＡＰＮに基づいて正しいコアネットワークにルートされる。ＵＥは、ＰＤＮセッションが確立されたとき、複数のＡＰＮを設定してもらうことさえでき、複数のＩＰアドレス（マルチホーミング）を生じる。アップリンクで伝送するときに正しいソースＩＰアドレスが使用されることを保証することは、簡単ではない。インターネットアプリケーションのために同じＵＥで２つ以上のＡＰＮを設定することは、あらゆるデバイスによってサポートされないことがある。このソリューションは、ＲＡＮへの変更を必要としないが、コアネットワークでサポートされなければならない。
３ＧＰＰには、以前のソリューションのために行われたような、好ましいＰＬＭＮ ＩＤまたはＡＰＮ設定ではなく、ネットワーク内の設定に基づくスライスの選択を可能にする専用コアネットワーク（ＤＣＮ：ｄｅｄｉｃａｔｅｄ ｃｏｒｅ ｎｅｔｗｏｒｋ）として標準文書で現在説明される、ＤＥＣＯＲと名付けられた検討事項がある。特徴は、ＲＡＮおよびコアでサポートされなければならず、ホーム加入者サーバ（ＨＳＳ）からの情報は、「ＵＥ使用タイプ」を判定するために使用され、これによって、正しいスライスに機能を負わせる。このソリューションにおけるＵＥのインパクトはない。
ｅＤＥＣＯＲとして知られる概念は、ＵＥがＤＣＮ－ＩＤを投入して、スライスを選択できるようにすることによって、これをさらに強化する。このアプローチを利用するために、ＲＡＮ、コア、およびＵＥは、特徴をサポートしなければならない。
ＤＥＣＯＲとｅＤＥＣＯＲの両方は、ＵＥあたり１つのスライスしか許容しないが、異なるタイプのＵＥが異なるスライスによってサーブされることを保証する。各専用コア内で、複数のデディケーテッドベアラおよびＡＰＮを使用することができる。
リリース１５およびそれ以降について、５Ｇスライシングは、理論的には制限のない数のスライスにこの特徴を拡張するが、ＵＥ、ＲＡＮおよびコアにおける実行およびリソース依存の制約が当てはまる恐れがある。４Ｇについて、５Ｇにおけるスライシングを実現するためのいくつかのサブオプションが存在するが、本書類ではさらに区別されない。
トラフィックが対応するスライスに割り当てられると、次の問題は、サービス性能をどのように提供できるかについてである。多くの産業用ＩｏＴユースケースでは、優先トラフィックのために保証されたサービス性能が要求される。通常の（すなわち、スライスされていない）５Ｇネットワークでは、または単一のネットワークスライス内では、５ＧシステムでＱｏＳがどのように適用されるかを示す図９に示されるようなトラフィックフロー分離に従って、異なるトラフィックフローを分離することができる。専用リソース割当てをクリティカルトラフィックに提供することができる。保証された伝送リソース（すなわち、保証されたビットレート）を伴う認められた優先トラフィックフローの数が、利用可能リソースを超過せず、リソースの変形形態に十分なマージンがあることを保証するために、アドミッション制御が使用される。
スライス間のリソース分割について、物理インフラストラクチャにおけるリソースの確保は、個々のトラフィックフローごとではなく、代わりに、スライス内のクリティカルトラフィックフローの合計に基づく。このトータル要件は、ネットワークスライスＳＬＡにおいて規定されなければならない。リソース分割は、静的である必要はない。１つのスライスの未使用リソースを別のスライスが使用できる場合に、より良い効率性を達成することができる。これは、実例のスライスＡとＢの間のリソース分割を示す図１０で見ることができる。要求されることは、いずれかの時間的ポイントで（または少なくとも、ＳＬＡで規定された可用性レベルまで）、保証されたサービスフローへのアクセス権を、各ネットワークスライスが得ることができることである。
産業用アプリケーション
以下は、産業技術に関係するいくつかのアプリケーションおよび活動についての議論である。この議論は、以前の技術に比べて、多くのさらなる利益をもたらす新しい技術である、クラウドロボット工学についての議論を含む。
「Ｓｔｕｄｙ ｏｎ Ｃｏｍｍｕｎｉｃａｔｉｏｎ ｆｏｒ Ａｕｔｏｍａｔｉｏｎ ｉｎ Ｖｅｒｔｉｃａｌ Ｄｏｍａｉｎｓ」、３ＧＰＰ ＴＲ２２．８０４、ｖ．１６．２．０（２０１８年１２月）の５．３．２章に、将来の工場のためのユースケースとして、運動制御が紹介されている。運動制御は、任意のオートメーションアプリケーションに不可欠なものであり、例えば、産業用ロボットにとって基本的なものでもある。ロボットの動きまたは印刷機械の機能は、基本的に、単に、複数のアクチュエータの協調運動制御である。
運動制御は、アプリケーションが必要とする方式でアクチュエータ（またはアクチュエータのグループ）を駆動する（および運動制御がそうすることを保証する）タスクを指す。電子モータは、産業界における最も一般的なアクチュエータである。電気モータを分類するための多様な方式がある（例えばＡＣ－ＤＣ（ブラシあり／ブラシレス）、ステッパ－サーボ－ハイブリッドステッパ）。それでも、運動制御原理は、各モータクラスに同様のものである。複数のアクチュエータを協調および同期させるため、ならびに、より高いレイヤの制御のために、通信技術が使用される。正確さまたは精密さについての要件を伴う運動制御アプリケーションが、閉ループ制御として常に実行される。
運動制御システムにおける共通の論理分割がある。
・物理アクチュエータ（別名モータ）＆エンコーダ（すなわち、スピード、位置等についての１つまたは複数のセンサ）
・ドライバ（インバータとも呼ばれる）
・運動コントローラ
・プログラマブルロジックコントローラ（ＰＬＣ：Ｐｒｏｇｒａｍｍａｂｌｅ Ｌｏｇｉｃ ｃｏｎｔｒｏｌｌｅｒ）
運動制御機能のこの論理分割は、図１１に示されている。
運動制御アーキテクチャにおける典型的な通信パターン（図１１におけるような番号）。
１）ＰＬＣは、より高いレベルのコマンドを運動コントローラに伝える（これは、それほど厳格な通信要件を課さない）。
２）運動コントローラは、例えば以下を使用することによって、ドライバのための、いわゆるセットポイント（スピード、トルク等であることもある）を生成する。
ａ．パルス幅変調、これは通信技術ではない。
ｂ．通常１ｍｓ未満の非常に短いサイクル時間のサポートを伴う、ＥｔｈｅｒＣａｔもしくはＰｒｏｆｉｎｅｔ ＩＲＴまたは同様のもののようなプロトコル。
３）ドライバからモータに供給される電流（セットポイントに基づくモータへのエネルギー供給であり、通信技術ではない）。
４）ドライバおよび／または運動コントローラへのエンコーダ（センサ）フィードバックであり、フィードバックは、モータおよびエンコーダのタイプに依存する。フィードバックは、アナログであってもよく、または、同じ要件（循環閉ループセットポイント伝送およびフィードバック）を伴う、２）におけるような、例えばＥｔｈｅｒＣａｔまたはＰｒｏｆｉｎｅｔ ＩＲＴに基づいていてもよい。
例えば、いくつかのモータが同じ機械で使用される場合、単一の運動コントローラが複数のアクチュエータを制御することもできる。上記で言及された技術レポートでは、運動制御アプリケーションについての要件（そこでは、運動コントローラ－ドライバ－エンコーダという閉ループに取り組んでいる）がリストアップされている（これらの要件は、下記に、表１の中で複製されている）。
Figure 0007241899000001
３ＧＰＰ ＴＲ２２．８０４では、２つの連続パケット損失は受入れられず、関与する全てのデバイス間の非常に高い同期が要求されることがさらに言及されている（ジッタは、１μｓｅｃ未満である）。後者は、分散エンコーダからサンプルを取れるようにするため、および、共通サンプリングポイントで運動コントローラからドライバへの新しいセットポイントを適用するためにも必須である。これは、等時性通信と呼ばれ、アプリケーション（つまり、運動制御プログラム、ならびに全てのアクチュエータおよびエンコーダ）が、（例えばＰｒｏｆｉｎｅｔの）通信技術によって与えられた通信サイクルタイミングに同期していることを意味する。これは、時限チャネルアクセスを使用した最低限かつ決定的なレイテンシも保証する。
運動制御製造業者Ｌｅｎｚｅなどの運動制御機器のいくつかのベンダも、単一の物理エンティティに機能を結合する。上位の「制御レベル」では、ベンダは、ヒューマン－マシンインターフェースの隣に、結合されたＰＬＣ＋運動コントローラ（ロジック＆運動）を使用する。このコントローラは、ＩＯデバイス（３）からの入力を取り、そのセットポイントを、例えば、ＥｔｈｅｒＣａｔ（「フィールドレベル」）でサーボ－インバータ（２）に送り込む。
別のトレンドは、エンコーダおよび／またはドライバおよび／または運動コントローラをモータに統合することである。これも、統合型モータまたはスマートモータと呼ばれることがある。
さらに、同じアプリケーションのために複数の運動コントローラを使用することができ、各運動コントローラが、ドライバのサブセットを制御する。協調したモータの動きは、別々の運動コントローラ間の通信を必要とする。３ＧＰＰ ＴＲ２２．８０４では、これは、「コントローラ間」（Ｃ２Ｃ：Ｃｏｎｔｒｏｌｌｅｒ－ｔｏ－Ｃｏｎｔｒｏｌｌｅｒ）通信と呼ばれる。４ｍｓから１０ｍｓまでのサイクル時間が想定される。同期についての要件は、等しく厳格であり、ジッタは、Ｃ２Ｃレベルでも１μｓｅｃ未満である。ペイロードサイズは、１ｋＢまでであってもよい。
安全のために、無線運動制御アプリケーションにおいて展開された、さらなる機能的安全性制御があってもよい。機能的安全性は、運動制御自体のために使用される閉ループの隣に、追加の閉ループとして実装される。これは、運動制御構成要素における追加のハードウェアまたは統合された安全性機能を通じて行われる。ＰｒｏｆｉＳａｆｅのような通信プロトコルが使用される。１つの安全性制約は、（ＩＥＣ６１８００からの）例えばセーフトルクオフ（ＳＴＯ：Ｓａｆｅ Ｔｏｒｑｕｅ Ｏｆｆ）である。ＳＴＯは、ＰＬＣまたは追加の安全性ＰＬＣによって何らかのエラー／安全性問題が検出された場合、モータへの電源供給を停止しなければならないことを規定する。ＳＴＯは、例えば、非常ボタンを押すことによってトリガすることができる。３ＧＰＰ ＴＲ２２．８０４では、機能的安全性のために、厳密な循環データ通信サービスが両エンド間で要求されることが説明されている。実際の安全性イベントが発生していなかったとしても、接続が妨げられると、非常停止がトリガされる。異なるユースケースに対して、異なる要件が存在する（４ｍｓから１２ｍｓまでのサイクル時間、パケットサイズ４０バイト～２５０バイト、３ＧＰＰ ＴＲ２２．８０４による伝送時の許容可能ジッタ）。安全性機能は、運動制御アーキテクチャの異なる構成要素内で実行されてもよい。
要約すれば、運動制御のための４つの異なるタイプの通信が存在する。
１）最低レベル閉ループ運動制御（運動コントローラ－ドライバ－エンコーダ）
２）コントローラ間通信
３）機能的安全性通信
４）ＰＬＣから運動コントローラへの通信
レイテンシに関する通信システムについての要件は、１から４まで減少している。無線通信技術に対してリンク１～４を確立する意味があるかどうかは、アプリケーションによる。ほとんどの場合、おそらく１）のためではなく、２）、３）、および４）のために無線リンクを確立することに最も関連している可能性がある。
クラウドロボティクス
産業ロボティクスリサーチおよび一般的なロボティクスにおいて、クラウドロボティクスは、大きな話題である。それは、どのようにして異なるクラウド技術が、様々なロボティクスタスクのためのさらなる利益を提供するために使用され得、それによりシステム全体の柔軟性および能力を改善するのかを説明する。いくつかの研究は、ロボットをクラウドに接続することの利益を既に示している。
・クラウド内でのより強力な計算リソースの使用（例えば、人工知能（ＡＩ）タスクのため）。
・分析、意思決定、および学習のためのほぼ無制限のデータの使用（デジタルシャドウおよびリアルタイムシミュレーションを含む）。
・新しいタイプの使用事例が可能になる（例えば、クラウド内の協調制御）。
・機能が中央クラウドへオフロードされるため、ロボットあたりのより低い費用。
・１つのロボットがクラウド内の最新バックアップから物理的に離脱する場合、フェイルオーバを実施する可能性。
・機能の信頼性は、クラウド内のホットスタンバイとして複数のインスタンスを実行することによって改善され得、動作は、途切れることなく、不完全な主要機能から直ちに引き継がれ得る。
・運用保守をより容易にする（ソフトウェア更新、設定変更、監視など）。
・ＣＰＵエネルギー消費をクラウドへオフロードすることによって、特に、モバイルのバッテリ駆動ロボットのため、エネルギーを節約すること。
実際、高い柔軟性は、インダストリ４．０の重要な要件である。高い柔軟性は、生産ラインの素早い再設定、ならびに容易なアプリケーション展開をサポートすることにより、高い費用効率およびカスタマイズした生産を実現するために必要とされる。典型的な産業アプリケーションは、タイムセンシティブであり、非常に信頼性の高い通信エンドツーエンドを必要とする。したがって、５Ｇ ＵＲＬＬＣおよびエッジクラウドは、この要件に対処するために必須の技術である。一部のクラウドロボティクスアプリケーションは、リアルタイム通信を必要としないが、クラウドの処理がロボットの即時運動に関連している場合は特に、リアルタイム通信を大いに必要とするものも依然として存在する。以下において、クラウドロボティクスにより対処され得る産業アプリケーションでの主要課題のうちの一部が列挙される。
・コントローラとデバイスとの間の高速閉ループ制御（１～１０ｍｓ）。
・コントローラとデバイスとの間の無線リンク。
・クラウド実行環境内のリアルタイム産業アプリケーション（例えば、サーボコントローラ）。
・産業グレードの信頼性（例えば、ケーブルベースのＰｒｏｆｉＮｅｔと同じ）。
・柔軟な生産ライン（容易な再配置および再プログラミング、低遅延ソフトウェア更新、再設定、すなわち、ＦａａＳ能力）。
・協調制御およびモジュラアーキテクチャ。
・適合アルゴリズム（例えば、ヒューマン・ロボットコラボレーションの場合、制御は、変化する動的環境に対応しなければならず、学習および認知能力を必要とする）。
・異なる制御アプリケーションのための共有データ。
以下において、簡単に説明されるのは、（現実または疑似の）４Ｇ／５Ｇ接続に関与するいくつかのクラウドロボティクスシナリオ、および産業ロボティクス応用のためのクラウド技術である。
クラウドロボティクスの１つの応用は、ロボット内のハードウェアプログラマブル論理制御装置（ＰＬＣ）をソフトウェア版（ソフトＰＬＣ）で置き換えて、それをコモディティＨＷコンポーネント上で仮想化環境／クラウド内で実行することである。この概念研究は、２つの大型ロボットアームを有する実際のロボットセル、コンベアベルト、およびいくつかの他の産業デバイスに関与していた。通信のため、ＰｒｏｆｉＮｅｔが使用された。
１つの問題は、どのレベルのロボット制御が、ＬＴＥを介したクラウドへシフトされ得るのかということである。これは、図１２に例証される。典型的にはＰＬＣによって行われる高水準制御は、あまり遅延クリティカルではなく、すなわち、それは、設定に応じて、数十ミリ秒（例えば、約３０ｍｓ）のレイテンシ要件を有する。しかしながら、通信全体は、遅延変動（ジッタ）およびパケット損失に非常に敏感である。例えば、８ｍｓ周波数での周期的トラフィックの場合、３つの連続パケット損失または３×８（２４）ｍｓジッタは、ロボットセル全体を停止させ得る。それらの要件は、ケーブルベースのソリューションと比較して専用ハードウェアコンポーネントを使用するときには満足するのが簡単であるが、無線技術と比較して仮想化実行を使用することは困難であり得る。
クラウドプラットフォームの観点から、仮想化制御がもたらす主な課題の１つは、リアルタイムアプリケーションの実行である。アプリケーションは、ＰＬＣコードを実行することを担うリアルタイムＯＳの次に、基本ＯＳとしてＷｉｎｄｏｗｓ ７を使用するソフトＰＬＣを使用し得る。両方が、並行して実行し、プロセス間通信（ＩＰＣ）を介して通信する。制御論理実装構造は、常に、ＲＴＯＳによって実行され、Ｗｉｎｄｏｗｓは、多くの場合、ユーザインターフェースとして使用される。ＲＴＯＳは、典型的には、精密なタイマおよび特定のネットワークインターフェースカードなどの必須の性能を確実にするためにいくつかの特定の要件を有する。ソフトウェアＰＬＣプラットフォームをホストし、ハードウェアＰＬＣ上で実行していたものと同じ制御論理を実行することができる仮想化環境が作成され得る。
実際の工場環境において、専用ＨＷからの制御論理のＰＬＣレベルをエッジクラウドプラットフォームへ置くことは実現可能であり、ＬＴＥを介したとしても適切に機能する。しかしながら、本発明者らが、アクチュエータの速度、加速、または位置を正確に操縦する軌道計画、逆運動学、および制御ループなどのアプリケーションを調査する場合、１～５ｍｓの範囲内の著しくより低いレイテンシが必要とされる。それらのアプリケーションをサポートするためには、図１２に示されるような、高信頼性かつ低レイテンシの５Ｇサービスが必要不可欠である。
ロボットの運動制御をクラウドへ移動させることの裏にある１つの動機は、ここでも、柔軟性を増大させることである。例えば、デバイスのみが移動される必要がある（コントローラボックスなし）ため、クラウド制御のデバイスを用いて生産ラインを再配置することははるかに容易であり、そのような環境において管理すること、再プログラムすること、フェイルオーバを行うこと、またはソフトウェア更新をすることはより容易である。しかしながら、いくつかの機能性、例えば、接続性問題の場合のいくつかの安全機構は、ロボットの内側／近くに留まらなければならない（ケーブルを使用して）。ネットワークに対する要件は、ロボットクラウドもそのタスクを接続なしに実施することができる場合には下げられる。一時的な接続損失または低減された性能（例えば、作業現場での広範囲のロボット移動性に起因する）の場合、ロボットクラウドは、その作業速度を低減するか、または、安全性を確実にするために他の機構を起動させるか、またはネットワークから独立した状態で標的を加工し得る。ロボット自体の隣の追加のエンティティとしてのロボットコントローラは、作業現場から除去されなければならない。このタイプのデプロイメントのためのアーキテクチャは、図１３に示される。
別の手法は、運動制御がロボットの内側で自律的に行われ、接続性が協調ロボット制御などの新しい使用事例を可能にするためだけに使用されるというものであり得る。協調制御の場合、１つの制御エンティティは、依然として、他の制御プロセスの実際の状態への素早いアクセスを必要とし得る。この選択肢は、例えば、運動制御がロボットの内側に５ｍｓ制御ループを有する一部のシナリオにおいて有効であるが、それは、約１００ｍｓ毎にのみ別のインスタンスと協調する必要がある。
軌道計画および実行を含むロボットコントローラが実装されており、モデル化された無線チャネルを介したローカルクラウドからのロボットアーム制御アプリケーションの性能が評価される。評価段階のアプリケーションは、産業ロボットアームの閉ループ制御に含まれていたものであり、ここでは制御は、モデル化された５Ｇリンクを通じてロボットアームに接続された。
ロボットアーム運動品質の性能に対するリンク遅延の効果は、特定の重要業績評価指標（ＫＰＩ）によって測定され得る。産業ロボットアームは、ジョイント（サーボ）ごとに速度命令を受容し、８ｍｓ更新時間でジョイント状態情報を公開する、外部からアクセス可能な速度制御インターフェースを有する。ＫＰＩは、応答時間、および軌道実行の精度、すなわち、計画した軌道からの空間的および時間的ずれであり得る。測定は、４ｍｓ未満のネットワーク遅延はこのアプリケーションにおいて著しい性能影響を及ぼさないことを示している。これは、（１）ロボットの内部動作が、ロボットで使用される内部サンプリングに起因して応答時間において約２ｍｓの標準偏差となること、および（２）ロボットおよびコントローラのチックが非同期であることが理由である。４ｍｓ未満のネットワーク遅延の影響は、測定セットアップの背景「雑音」によってマスクされる。
いくつかの他の結論に達することができる。
・外部イベントに対する反応：ロボットとコントローラとの間のネットワーク遅延が反応時間を直接増加させることから、低ネットワーク遅延が望ましい。
・リアルタイム軌道微調整（すなわち、ロボットアームの終端の正確な位置決め）：軌道実行時間の期限は、最大許容ネットワーク遅延に対する要求をもたらす。一般に、ネットワーク遅延が高いほど微調整時間は長くなり、この方式では、合計軌道実行時間が増大する。
・軌道正確性：いくつかのタスクは、最終位置だけでなく、溶接などの経路に沿って、正確な運動を必要とする。別の例は、より多くのロボットアームの協働であり、ここでは、精密かつ同期した運動が重要である。これらのタスクでは、外部情報が軌道計画において尊重されるべき場合、低ネットワーク遅延が望ましい。
ロボットアームの内部機構もまた、ネットワーク遅延に対して要件を課し得る。一般に、短い更新時間を有するシステムは、より低いネットワーク遅延を必要とする。例えば、２０ｍｓの更新時間でのロボットアームの制御は、１ｍｓ更新時間を有するより精密かつ高速のロボットアームよりも高いネットワーク遅延に耐える。これに加えて、比較的高い更新時間を有するシステムのための超低レイテンシ接続を提供することは、限られた性能利点を有する。
軌道実行の性能要件もまた、ネットワーク遅延に要件を課し得る。より高速のロボット運動は、正確な運動のために、より低いネットワーク遅延を必要とする。その一方で、より高いレイテンシ接続が利用可能な場合、より低いロボット速度を使用することにより、増大したネットワーク遅延をある程度補うことができる。性能最適化もまた、必要とされるネットワーク遅延のためのガイドラインを提供し得る。妥当な必要とされる正確性を選択することにより、実行時間を改善することができる。例えば、それほど正確でない運動で十分な場合、緩和した正確性が微調整時間を短縮することができる。
新たなロボット概念および応用は、大規模に協働的なロボット制御、ならびにサイバーフィジカル生産システムにおけるデジタルツインの使用を含む。これらは、以下の章で簡単に論じられる。
ヘキサポッド
ロボットアームおよびロボットセル制御などの産業アプリケーションにより高い協働および適合能力を導入するときは、大量のサーボの協働が必要とされ得、使用事例をさらにより困難にする。ヘキサポッドロボットは、例えば、サーボ制御、協働など、インダストリ４．０ロボットセルにおいて生じる広範な課題を評価するための有用なアプリケーションである。図１４は、クラウドベースの制御のために５Ｇスライスと結合される協働的なロボット・ベンダー・アグノスティックシステムとして見ることができる、ヘキサポッドロボットを例証する。
ヘキサポッドは、ベースリンクを介して接続される６つの３自由度ロボットアームと見なされ得る。５Ｇ要件を評価するため、１８個のジョイントにおけるサーボは、ヘキサポッドから離れた無線ネットワークホップに存在するコンピュータから別個に制御され得る。このように、ヘキサポッドは、同期した協働の効果を視覚化するための適切な選択であることを証明する。十分に同期した協働は、安定した中心位置を結果としてもたらすはずであるが、システム内のいかなるグリッチもプラットフォームの揺れを結果としてもたらす。ヘキサポッドの無線制御の評価の結果は、Ｇｅｚａ Ｓｚａｂｏ、Ｓａｎｄｏｒ Ｒａｃｚ、Ｎｏｒｂｅｒｔ Ｒｅｉｄｅｒ、Ｊｏｚｓｅｆ Ｐｅｔｏ、「ＱｏＣ－ａｗａｒｅ Ｒｅｍｏｔｅ Ｃｏｎｔｒｏｌ ｏｆ ａ Ｈｅｘａｐｏｄ Ｐｌａｔｆｏｒｍ」、ＡＣＭ Ｓｉｇｃｏｍｍ、Ｂｕｄａｐｅｓｔ、２０１８に報告されている。
デジタルツイン
デジタルツイン（ＤＴ）概念は、実ロボットの制御に対するネットワークの効果を分析するのに有用であり、ここでは、そのＤＴは、機敏なロボットタスクを実行する複雑なロボットセル内で実行する。実現可能なＤＴは、Ｇａｚｅｂｏシミュレーション環境に実装され得、Ａｇｉｌｅ Ｒｏｂｏｔｉｃｓ ｆｏｒ Ｉｎｄｕｓｔｒｉａｌ Ａｕｔｏｍａｔｉｏｎ Ｃｏｍｐｅｔｉｔｉｏｎ（ＡＲＩＡＣ）を解決する完全にシミュレートされたシナリオに対して評価され得る。この評価は、異なるコマンド周波数、制御ループ、ならびに実ロボットおよびシミュレートされたロボットのダイナミクスのハンドリングの問題を取り扱う。ハードウェアアグノスティックＧａｚｅｂｏプラグイン内のアーキテクチャの評価は、シミュレートされたロボットを制御するネットワークのシミュレーションが低遅延シナリオで使用され得ることを示す。高遅延シナリオにおいて、シミュレートされたレイテンシは、完全な故障がロボットセル内で発生するまで遅延サイズに関しておよそ約１０％多くの余地を提供する。これらの結果は、Ｂｅｎ Ｋｅｈｏｅ、Ｓａｃｈｉｎ Ｐａｔｉｌ、Ｐｉｅｔｅｒ Ａｂｂｅｅｌ、Ｋｅｎ Ｇｏｌｄｂｅｒｇ、「Ｓｕｒｖｅｙ ｏｆ Ｒｅｓｅａｒｃｈ ｏｎ Ｃｌｏｕｄ Ｒｏｂｏｔｉｃｓ ａｎｄ Ａｕｔｏｍａｔｉｏｎ」、ＩＥＥＥ Ｔｒａｎｓａｃｔｉｏｎｓ ｏｎ Ａｕｔｏｍａｔｉｏｎ Ｓｃｉｅｎｃｅ ａｎｄ Ｅｎｇｉｎｅｅｒｉｎｇ（Ｔ－ＡＳＥ）：Ｓｐｅｃｉａｌ Ｉｓｓｕｅ ｏｎ Ｃｌｏｕｄ Ｒｏｂｏｔｉｃｓ ａｎｄ Ａｕｔｏｍａｔｉｏｎ Ｖｏｌ．１２、ｎｏ．２．Ａｐｒ．２０１５に報告される。
位置決め
位置決めは、産業および製造シナリオにおける重要な機能性と認識され、人員の追跡（例えば、鉱山内）、安全性（例えば、フォークリフト近くで作業するとき）、製造／組立フロアにおける器具の位置特定、サプライチェーン最適化、無人運搬車の動作などの使用事例がある。大半の使用事例は、相対位置決めのみを必要とし、例えば、ここでは、すべての位置は、工場ホール内の共通参照地点に対して規定される。
必要とされる位置決め正確性、ならびに位置決めが実施されることになる環境および無線状況は、異なる使用事例では著しく異なる。しかしながら、大半の製造使用事例は、例えば、工場ホールまたは鉱山内のトンネルのように、屋内である。これは、全地球ナビゲーション衛星システム（ＧＮＳＳ）ベースのソリューションは、衛星中継から屋内で受信される非常に低い信号強度、結果としてカバレッジがないか劣悪であることが理由で、使用が困難であることを示唆する。
屋内でのＧＮＳＳシステムの制限は、セルラベースの位置決めソリューションの余地をもたらした。産業および工場フロアにおいて現在一般に使用される位置決めソリューションは、Ｗｉ－Ｆｉ、無線周波数識別（ＲＦＩＤ）、ブルートゥース低エネルギー（ＢＬＥ）、超広帯域（ＵＷＢ）、およびＬＴＥに基づく。狭帯域（ＮＢ）－ＩｏＴおよびＣＡＴ－Ｍは、低複雑性、低電力、低コストデバイスに対処するための３ＧＰＰ ＬＴＥ技術であり、したがって、位置付けられるべきアセットが通信の必要性のために３ＧＰＰモデムモデムをまだ含んでいない使用事例のための唯一の現実的な３ＧＰＰ位置決めソリューションである。ＲＡＤＡＲなどの無線ソリューション、ならびにＬＩＤＡＲおよびコンピュータビジョンシステムのような非無線ソリューションはまた、高い（メートル未満の）正確性を伴った位置決めが必要とされるときに特に重要である。
多重伝搬は、多くの場合、位置決めにとって重大な誤差源である。産業用ホールにおいて、経路の遅延広がりは、典型的には比較的短いが、そのような環境における正確な位置決めのための要件を考えると、これらは依然として重大である。大半の位置決めアルゴリズムは、見通し内測定の可用性の仮定の下で機能し、見通し内（ＬｏＳ）と見通し外（ｎＬｏＳ）とを区別する簡単な方法は存在しない。ｎＬｏＳ経路が、位置決めのためにＬｏＳ経路の代わりに誤って使用される場合、飛行時間および到来角の両方が誤認である可能性がある。ｎＬｏＳ経路の飛行時間は、ＬｏＳ経路の飛行時間の上界であるが、到来角は完全に誤っている場合がある。したがって、ｎＬｏＳ経路は、位置決めアルゴリズムの性能を大いに劣化させ得る。今後の産業位置決めスキームは、この問題に十分に取り組む必要がある。
精密な位置決めの別の障害は、ネットワーク同期誤差である。実践的なネットワーク同期アルゴリズムは、最大３６０ｎｓのネットワーク同期誤差を示唆し得、これは±１１０ｍの位置決め誤差に対応する。位置決め正確性を改善するための有望な代替案は、無線インターフェースベースの監視（ＲＩＢＭ）である。このソリューションは、近隣基地局からの位置決め参照信号の基地局タイミング測定に基づき、はるかに良好な正確性を伴った「仮想同期」が提供され得るように基地局間の同期オフセットを推定する。代替的に、ネットワーク同期を必要としない位置決め技法、例えば、ラウンドトリップタイムおよび／または到来角測定に基づいた技法が検討され得る。本明細書に記載される位置決め正確性のいかなる推定も、良好なネットワーク同期が、例えばＲＩＢＭを使用して、達成されていることを前提とするということに留意されたい。
特に、測定が実施される時刻間での、位置決め正確性は、運動の軌道を考慮することによって著しく改善され得る。さらには、内部測定ユニット（ＩＭＵ）が、位置推定を更新する手段として端末においてますます広く採用されるようになっている。これらは、端末の運動を追跡するために加速度計およびジャイロスコープ（および時として磁力計も）使用する。
デプロイメント面
費用を低減し、デプロイメントを単純化するため、１つのシステムが通信および位置決めの両方に使用されるソリューションが好ましい。これは特に、別個の位置決めシステムのデプロイメントが困難かつ高費用である環境において、例えば、各ノードの設置費用がしばしば高い鉱山において、重要である。しかしながら、例えば１つまたは数個のマイクロ基地局を備え得る、通信デプロイメントが、十分に良好な位置決め正確性をもたらさない場合、高精度の位置決めが、典型的には通信よりもはるかに高密度のデプロイメントを必要とすることから、通信システムに加えて追加される別個または無料の位置決めシステムが最良のソリューションであり得る。
達成され得る位置決め正確性は、デプロイメントがどれくらい高密度であるか、および無線環境の特徴に大いに依存する。故に、通信ネットワークの高密度化は、改善された位置決め正確性を達成する手段であり得る。高密度のデプロイメントは特に、深刻な多重伝搬を伴う環境において、多重伝搬が動的に変化している場合は特に、重要であるが、それは、高密度のデプロイメントでなければ、位置を推定するために利用可能な十分に多くのＬｏＳ経路が存在しない場合があるためである。高密度のデプロイメントはまた、高い信号減衰を伴う隠れた物体が位置特定され得ることを確実にするために必要不可欠であり得る。
ネットワークの密度は、製造シナリオにおいて十分に良好な位置決め正確性を提供するための重要な側面である。考慮すべき別のデプロイメント面は、アンカーノードを設置するのがどれくらい単純であるかということである。設置は、例えば、アンカーの正確な位置を手動でもたらすことを含み得、これは、困難で、時間がかかり、誤りが発生しやすいものであり得る。これを回避するため、同時位置決め地図作成（ＳＬＡＭ）アルゴリズムが、初期設定段階における各アンカーの位置を推定するために使用され得る。
高密度のデプロイメントを費用対効果の高いものにするため、各アンカーの費用は低く保たれなければならない。しかしながら、通信および位置決めの両方を提供する技術のための各アンカー／基地局の費用は、当然ながら、位置決めのみを提供する技術、例えば、ＲＦＩＤおよびＵＷＢのためのものよりも高い。高精度の位置決めを達成するための通信ネットワークの高密度化に関わる費用を低減するための１つのやり方は、より高価な基地局と同じ技術を使用して、位置決めのみを提供する低減された能力を伴った、単純なアンカーを開発することであり得る。例えば、工場ホールの天井に取り付けられた１つのみまたは数個の非常に能力の高いＮＲ基地局は、通信カバレッジを提供するのに十分であり得る。より能力の低いＮＲ位置決めノード／アンカーは、このとき、高い正確性で位置決めを達成するための高密度化のために使用され得る。
超高密度デプロイメントの必要性を低減する別のやり方は、ＮＲの高度なビーム形成能力を反射体と組み合わせることであり得る。このやり方では、伝送ビームおよび反射体のすべての対が、仮想アンカーとして作用し得、それにより、ほんの少しのＮＲ基地局で超高密度デプロイメントの利益を達成する。反射体は、安定した位置決め正確性を確実にするために、静止しているか、または少なくとも緩徐にのみ変化していなければならないため、そのようなソリューションの１つの課題は、安定性である。
スペクトル面
位置決め正確性が増大した帯域幅により改善することは周知である。さらには、信号帯域幅が高いほど、ｎＬｏＳ主体受信信号からのＬｏＳ前縁のより大きい解像度を可能にし、したがって、ＬｏＳ経路を正確に検出するのがより容易である。その一方で、より高い搬送波周波数を使用することは、増大した信号減衰に起因して、ＬｏＳ経路の検出可能性を低減し得る。
ローカル使用のための周波数帯域は、現在、例えば、ドイツおよびスウェーデンでは３．７～３．８ＧＨｚ帯域と規定されている。全国的なスペクトルおよび／または非認可スペクトルも同様に産業のために使用され得る。１００ＭＨｚ帯域幅は、メートル未満の位置決め正確性を達成するのに十分なはずである。性能をさらに改善するため、異なるスペクトル部分が組み合わされ得る。
正確性要件
位置決め正確性要件は、ミリメートルから数十メートルのレベルまで様々である。例えば、鉱山における削孔および発破ならびに自動製造（整列、組立）は、ミリメートルからセンチメートルの正確性から恩恵を受け得る。センチメートルからデシメートルの正確性が所望される他の例としては、製造／組立フロア内での器具の位置特定、および無人搬送車の追跡が挙げられる。デシメートルからメートルの正確性は、いくつかのの安全ソリューション、例えば、人員の追跡およびフォークリフトの近くで作業している人員のためのリアルタイム警告に必要とされるが、例えば、サプライチェーン最適化およびアセット追跡（例えば、器具、機械）を考慮するときにも必要とされる。
３ＧＰＰは、ＴＳ２２．１０４、Ｓｅｃｔｉｏｎ ５．７、「Ｐｏｓｉｔｉｏｎｉｎｇ ｐｅｒｆｏｒｍａｎｃｅ ｒｅｑｕｉｒｅｍｅｎｔｓ」において、５Ｇ位置決めサービスのための位置決め要件を文書化している。表２は、これらの要件のうちのいくつかを抜粋したものである。３ＧＰＰによると、使用事例に応じて、５Ｇシステムは、より正確性の高い位置決めを達成するために、３ＧＰＰおよび非３ＧＰＰ技術の使用をサポートしなければならない。
Figure 0007241899000002
位置決め技術の概観
以下には、製造業に有用であり得る位置決め技術の概観が提供され、それらが製造シナリオにおいてどのように適用され得るかにいくらか焦点を合わせている。焦点は、３ＧＰＰ技法にあるが、いくつかの他の技法も同様にここで検討される。ＲＦＩＤおよびＢＬＥビーコンを使用した位置決めは、この概観には含まれていないが、同じ原理の多くがここで当てはまるということ、および本明細書に説明される様々な技術はこれらおよび他の位置決め技術と組み合わされ得るということを理解されたい。
ＬＴＥ ＯＴＤＯＡ
リリース９以降、ＬＴＥは、３ＧＰＰ ＴＳ ３６．３０５に説明される参照信号時間差（ＲＳＴＤ）測定に基づく観測到着時間差（ＯＴＤＯＡ）位置決めをサポートする。ＵＥは、近隣セルから位置決め参照信号（ＰＲＳ）を受信し、ＲＳＴＤ測定を使用して各セルについて到達時間（ＴＯＡ）を推定し、参照セルに関してＴＯＡを折り返し報告する。その後、エボルブドサービングモバイルロケーションセンタ（Ｅ－ＳＭＬＣ：Ｅｖｏｌｖｅｄ Ｓｅｒｖｉｎｇ Ｍｏｂｉｌｅ Ｌｏｃａｔｉｏｎ Ｃｅｎｔｒｅ）が、既知のｅＮＢ位置に基づいてＵＥの位置を推定する。到達時間差（ＴＤＯＡ）が、ＴＯＡの代わりに参照セルに関して使用されるが、それは、これが、ＵＥが時間同期されるべきだという要件を削除するからであるが、ネットワークは同期される必要がある。原則として、最低でも３つのセルが、２Ｄ位置決めに必要とされ、最低でも４つのセルが、３Ｄ位置決めに必要とされる。
図１５は、ＵＥ位置が、ＯＴＤＯＡの原理に従って、３つのｅＮＢからどのように推定され得るかを例証するものであり、完璧なＴＤＯＡ測定を前提とした２Ｄ ＴＤＯＡベースの位置決めの概念プロットである。各ＴＤＯＡ（参照ｅＮＢのＴＯＡからｅＮＢのＴＯＡを引く）は、光の速さによって乗算されるとき、距離の差（例えば、メートル単位）に変わる。各ＴＤＯＡは、潜在的なＵＥ位置の２Ｄ平面上に双曲線を返す。そのような双曲線の交点が、このとき、ＵＥ位置である。実際には、位置は、ガウス・ニュートン検索または同様の数値アルゴリズムを使用して、Ｅ－ＳＭＬＣによって推定される。
ＬＴＥでは、ＲＳＴＤは、セル特有の信号に基づいて、または任意選択的に規定されたＰＲＳに基づいて推定され得る。しかしながら、ＴＤＯＡ推定手順は、典型的には、ＰＲＳを使用するが、これは、他のセル特有の参照信号が、低い（－６ｄＢ未満の）信号対干渉および雑音比（ＳＩＮＲ）で近隣セルの十分に高い検出確率を保証することができないためである。ＰＲＳは、時間変数（フレーム内のスロット数およびスロット内のＯＦＤＭシンボル数）によって初期設定されるＧｏｌｄ系列、ならびにＰＲＳ ＩＤから規定され、副搬送波内でシフトされる斜線パターンで割り当てられる。本質的に、３つの主な因子が高いＰＲＳ検出可能性に寄与する。
・Ｇｏｌｄ系列は、低い相互相関特性を保証する。
・６つの副搬送波の距離（再使用因子）を伴ってリソースブロックおよびＯＦＤＭシンボルごとに２つのＰＲＳリソース要素が存在する。各ＰＲＳ斜線の特定の位置は、ＰＲＳ ＩＤ ｍｏｄ ６によって決定される。ＰＲＳに使用されない副搬送波は、ＬＩＳ（低干渉サブフレーム）を作成するために空である。
・ＰＲＳは、遠隔セルからＰＲＳを受信するときにＳＩＮＲを増大させるために、いくつかの伝送機会においてはミュートされ得る。
ＲＳＴＤは、受信したダウンリンクベースバンド信号をＰＲＳと相互相関させることによって生成される電力遅延プロファイル（ＰＤＰ）から引き出される。ここでの課題は、雑音ピークではないＰＤＰ内の最も早いピークを検出し、次いでサンプルの倍数に関してピーク遅延をとることである。ＴＯＡ誤差の主な源は、ＬｏＳ経路がブロッキングまたはシャドーイングに起因して検出されないｎＬｏＳ状態である。
実際のデプロイメントにおいてＬＴＥ ＯＴＤＯＡで達成され得る位置決め正確性は、リリース９では約５０～１００ｍである。ＬＴＥリリース１４では、Ｅ－ＳＭＬＣに対する報告分解能は、相対距離分解能を９．８ｍから４．９ｍに改善するために、ＴｓからＴｓ／２に変更されており、ここでは、Ｔｓは、ＬＴＥ内の基本時間単位（３２．５５ｎｓ）である。しかしながら、どれくらいの正確性が実際に達成され得るかは依然として不明瞭である。加えて、ＯＴＤＯＡは、ネットワーク同期を必要とし、任意の同期誤差が、達成され得る位置決め正確性を低減する。ＬＴＥの場合、最高でリリース１４まで標準化された位置決め方法の大半をカバーするモバイルブロードバンド（ＭＢＢ）ＵＥチップセットが利用可能である。
図１６は、１００ＭＨｚ（３０ｋＨｚ ＳＣＳ、２７５ＰＲＢ）、５０ＭＨｚ（１５ｋＨｚ ＳＣＳ、２７５ＰＲＢ）、１０ＭＨｚ（１５ｋＨｚ ＳＣＳ、５０ＰＲＢ）、５ＭＨｚ（１５ｋＨｚ、２５ＰＲＢ）という異なる帯域幅を使用した、３ＧＰＰ屋内オープンオフィス（ＩＯＯ）シナリオについてのＯＴＤＯＡ位置決め結果を示す。プロットは、ＮＲ内のベースラインとして、位置決めのための既に存在している追跡参照信号（ＴＲＳ）の使用に基づく。
このシナリオは、２０メートル離れた６個のｇＮＢ（合計で１２個のｇＮＢ）を前提とする。（「ｇＮＢ」は、ＮＲ基地局についての３ＧＰＰ用語である。）結果は、帯域幅が５ＭＨｚから１０ＭＨｚに増大するとき、および同等に帯域幅が５０ＭＨｚまでさらに増大するとき、位置決め正確性が著しく改善されることを示す。しかしながら、１００ＭＨｚおよび５０ＭＨｚの結果はそれほど差がなく、８０％パーセンタイルでおよそ８メートルの正確性であるということも見て分かる。１００ＭＨｚの場合は、到達時間（ＴＯＡ）推定のためのより高度なピーク検索アルゴリズムを使用することによってさらに改善され得る。現在のシミュレーションにおいては、最も高いピークの少なくとも半分の高さであるＰＤＰ内の最も早いピークがＬＯＳピークと見なされる。信号対雑音比（ＳＮＲ）が増大されると、雑音フロアを上回るピークを検出する可能性は改善され得る。さらには、２０ｍの基地局間距離（ＩＳＤ）よりも大きい誤差は、ＯＴＤＯＡが非現実的になる場合、単純なセルＩＤ（ＣＩＤ）推定を組み合わせることによって実際には補われ得るが、これはここでは行われない。
狭帯域（ＮＢ）－ＩｏＴおよびＣＡＴ－Ｍは、低複雑性、低電力、および低費用デバイスに対処するための３ＧＰＰ ＬＴＥ技術である。そのような低費用デバイスの可用性は、これを、位置付けられるべきアセットが通信の必要性のために３ＧＰＰモデムをまだ含んでいない使用事例のための唯一の現実的な３ＧＰＰソリューションにする。しかしながら、位置決め正確性は、使用される狭帯域幅が主たる理由で、ＩｏＴデバイスを使用するときには著しく悪い。シミュレーション研究は、屋内デプロイメントにおけるＮＢ－ＩｏＴについては７０％パーセンタイルで１００ｍ位置決め誤差を実証したが、位置決めのために５０ＰＲＢを使用するＬＴＥは、同じシナリオにおいて７０％パーセンタイルで約２３ｍをもたらした。
ＮＢ－ＩｏＴデバイスの狭帯域幅は、時間内により長いＰＲＳの機会を可能にすることによって部分的に補われる。しかしながら、ＰＲＳがフレームごと（１０ｍｓ）に繰り返されるため、相関特性は乏しい。ＮＢ－ＩｏＴデバイスはまた、電力消費を低減するためにより低いサンプリングレートを有し、これがＲＳＴＤ測定の正確性を低減する。
ＬＴＥ ＩｏＴデバイスのチップセットは、ＬＴＥ ＭＢＢのチップセットほど容易に利用可能ではない。しかしながら、開発が進行中であり、可用性は徐々に改善している。
ＮＲのＩｏＴ位置決めは、２０１８年１２月時点では規定されていないが、より良好なＩｏＴ位置決め正確性の１つの成功要因は、例えば、ＰＲＳ反復間隔を増大させることによって、ＰＲＳの時間相関特性を改善することである。ＮＢ－ＩｏＴのキャリアアグリゲーションについても、論じられており、増大した帯域幅は、この場合、改善されたＩｏＴ位置決めの別の成功要因であり得る。別の代替案は、ｅＮＢ ＰＲＳの位相を修正し、それにより、ＮＢ－ＩｏＴデバイスが低レートでサンプリングし、依然としてＰＲＳの位相を検出することができることを確実にすることであり得る。
ＬＴＥ拡張セルＩＤ位置決め
拡張セルＩＤ（Ｅｎｈａｎｃｅｄ Ｃｅｌｌ ＩＤ）、すなわちＥ－ＣＩＤは、ＬＴＥリリース９において導入された。ＵＥは、ネットワークに、サービングセルＩＤ、タイミングアドバンス、ならびに検出した近隣セルのＩＤ、推定タイミング、および電力を報告する。ｅＮＢは、到来角、セル部分、ラウンドトリップタイムなどのような追加の情報を位置決めサーバに報告し得る。位置決めサーバは、この情報およびセルの場所のその知識に基づいてＵＥ位置を推定する。
Ｅ－ＣＩＤの正確性は、デプロイメント密度に主に依存する。屋外デプロイメントの場合、Ｅ－ＣＩＤの正確性は、数百メートル未満のＩＳＤを伴う都市環境では約１００ｍ程度、または最大数キロメートルのＩＳＤを伴う農村環境では３０００ｍ程度であり得る。製造業のような環境の場合のＥ－ＣＩＤの正確性は、研究されていないが、正確性は、この環境が多くのマルチパスを含み、例えば到来角データが反射に起因して誤認されている可能性があるため、ＩＳＤ程度であることが予期される。その一方で、そのような困難なシナリオにおいてさえ、ＲＦ指紋法は、電波伝搬が安定しており、校正／訓練フェーズが実現可能である場合、数メートルの正確性をもたらすことができなければならない。
ＮＲ位置決め特徴
２０１８年１２月現在、ＮＲ位置決めのための規定された概念は存在しない。ＬＴＥ ＯＴＤＯＡに勝る改善された位置決め正確性を可能にするＮＲ特徴を想定することができる。これらの特徴のうちのいくつかには、同様に新たな課題が付随する。
・ビームベースのシステムにおけるより良好な測距および到来角／出発角（ＡｏＡ／ＡｏＤ）推定。
・より高い搬送波周波数がＮＲにおいてサポートされ、これは信号がブロッキング／シャドーイングの影響をより受けやすいことを意味する。これは、部分的に、ビーム形成によってハンドリングされ得る。さらには、より高い搬送波周波数には、典型的には、より広い帯域幅が付随し、より良好なＲＳＴＤ分解能を可能にする。
・より小さい基地局間距離およびセル半径に関するより高密度のデプロイメント。これは、特定のビームのためのビームＩＤを使用したビーム形成と組み合わせて、すべての可能なビーム／セルＩＤ組合せのためにコード直交性を維持するために、より高機能なＧｏｌｄ系列初期設定を必要とする。
・より良好な時間整列がＮＲにおいて予期され、それにより時間同期誤差を低減する。
・基本時間単位は、ＬＴＥと比較してＮＲにおいて低減される。ＰＲＢの最大数は２７５（ＬＴＥにおける１１０と比較）であり、ＬＴＥのＦＦＴ長さの倍である４０９６のＦＦＴ長さを必要とする。さらには、副搬送波間隔は、１５ｋＨｚから２４０ｋＨｚの範囲に及ぶ。本質的に、これは、ＬＴＥにおいてよりも短いサンプリング間隔を示唆し、ＴＯＡ位置決め分解能を改善する。
ＮＲ Ｒｅｌ－１６のために標準化されたソリューションは、メートル未満の正確性を達成するために必要とされる器具を提供することが期待される。ＮＲの技術可能性を示すリンクレベルシミュレーションは、デシメートル未満の正確性が理論上では可能であり得ることを示す。リリース１６ ＮＲ位置決め３ＧＰＰ研究事項は、２０１８年１０月に開始した。
無線ドットシステムを使用した位置決め
エリクソンの無線ドットシステム（ＲＤＳ）は、屋内産業および製造シナリオにおける通信に非常に適している。しかしながら、２０１８年１２月時点で利用可能なＲＤＳ製品では、同じＩＲＵに接続されるＤＯＴを互いと区別することが不可能なため、セルＩＤベースの位置決めのみが利用可能である。さらには、ＲＤＳは、多くの場合、最大８個のＤＯＴが同じＩＲＵに接続され得るため、大きいセルを用いて配備される。デジタル５Ｇ ＤＯＴでは、最大１６個のＤＯＴが同じＩＲＵに接続され得る。
ＤＯＴあたりの位置決めを可能にする位置決め正確性の改善が提案されている。ＵＥ位置は、ＤＯＴレベル電力と組み合わせたアップリンク到達時間差（ＵＴＤＯＡ）アルゴリズムを使用して計算される。シミュレーションは、１メートル未満の位置決め誤差が良好なＳＮＲおよび良好なＤＯＴジオメトリ配置で達成され得ることを示している。しかしながら、ＤＯＴ位置の正確性およびＤＯＴケーブル長さ遅延のような様々な誤差源を考慮すると、約１～５メートルの位置決め誤差が起こり得る。
厳密なマルチパスを伴う典型的な製造シナリオの場合、無線ドットシステム（ＲＤＳ）が、高密度デプロイメントおよび低費用のノードに起因して、通信および位置決めの組合せを提供するための最も好適なソリューションのようである。
Ｗｉ－Ｆｉ位置決め
Ｗｉ－Ｆｉは、産業において既に一般的に配備されており、したがって、しばしば、位置決めにも使用される。１つの一般的に配備されるＷｉ－Ｆｉソリューションは、シャドーイングおよびアンテナパターンに応じて、信号強度インジケータ（ＲＳＳＩ）だけを受信するアクセスポイントにより、およそ５～１０ｍの正確性を達成することができるＡＲＵＢＡソリューションである。より良好な位置決め正確性を達成するため、ＡＲＵＢＡソリューションは、ブルートゥース低エネルギー（ＢＬＥ）バッテリ駆動のＡＲＵＭＢＡビーコンと組み合わされ得る。この特殊化した位置決めソリューションでは、＜３ｍの非常に良好な正確性が達成される可能性が高く、位置決めされるべきデバイスがビーコンの近くに位置するときには＜１ｍの正確性さえ可能であり得る。
優れた産業用Ｗｉ－Ｆｉ位置決めソリューションは、オフィス環境において平均１ｍ～３ｍの正確性を達成する。この位置決めソリューションは、特殊化したアンテナアレイを伴って、通信に使用されるＷｉＦｉ無線と同じユニット内に含まれる追加のＷｉＦｉ無線を含む。位置は、ＲＳＳＩおよび到来角（ＡｏＡ）測定の組合せを使用して推定される。
Ｗｉ－Ｆｉ位置決めと３ＧＰＰベースのＯＴＤＯＡ位置決めとの違いは、Ｗｉ－Ｆｉ位置決め（ＩＥＥＥ ８０２．１１ｍｃ）が、ラウンドトリップタイム（ＲＴＴ）に基づき得ることである。上に説明されるＯＴＤＯＡアルゴリズムと対照的に、ＲＴＴを使用する利点は、ネットワーク時間同期の必要がないことである。
ＵＷＢ
超広帯域（ＵＷＢ）技法は、ＵＷＢ信号における固有の高い時間分解能が精密な位置決めを可能にするため、位置決めソリューションにおいてますます人気が高まっている。いくつかのＵＷＢベースの位置決め製品が利用可能である。それらの多くは、ＤｅｃａＷａｖｅ ＵＷＢ技術に基づくが、独自ソリューション（例えば、Ｚｅｂｒａ）も存在する。
ＵＷＢは、複数のアルゴリズムにおいて使用され得る。ＵＷＢは、ダウンリンクまたはアップリンクＴＤＯＡ、複数のアンテナを使用した到来角、ならびに、ネットワーク時間同期が全く必要とされない直接距離測定をサポートすることができる。
ＵＷＢ技法に使用される非常に短い伝送パルスの性質に起因して、ＵＷＢは、反射が個別に検出され、またフィルタリングされ得ることから、多重伝搬に起因する問題を検出および除去することができる。これは、そのような区別が不可能である狭帯域システムと比較して、明白な利点である。飛行時間の精度は、２～５ｃｍの範囲にある。実環境に適用されると、ＵＷＢでの位置決め正確性は、１０ｃｍの規模である。
ＵＷＢの１つの利点は、３ＧＰＰモジュールと比較して安価なデバイスの可能性である。市販のＵＷＢトランシーバは、およそ３～４ＵＳＤで入手可能である。このことは、増大した設置密度、様々な使用事例をサポートするためのアルゴリズムの柔軟な選択、および世界的に様々なセグメントにサーブすることができる地球生態系をサポートするためのクラウドプラットフォームを可能にする。
ライダ
いくつかの位置決め技法は、物体までの超音波または電磁波のラウンドトリップ遅延を測定することによって距離を推定する。超音波は、空中で大きな損失を被り、数メートルを超える距離に到達することができない。レーダおよびライダは、それぞれ無線および光スペクトル内で電磁波を使用する。無線周波数波と比較して光波のより短い波長は、より良好な分解能へと変わり、したがって、ライダソリューションは、高正確性位置決めのための好ましい選択である。レーダソリューションにおいてのように、典型的なライダの主要構成要素は、送信機および受信機を含み、距離は、標的までの光のラウンドトリップ遅延に基づいて測定される。これは、透過光の波形の強度、位相、および／または周波数を変調し、その変調パターンが受信機に戻ってくるまでに必要な時間を測定することによって達成される。
人気のあるライダアーキテクチャとしては、パルスおよび周波数変調連続波（ＦＭＣＷ）スキームが挙げられる。パルスライダは、光の粒子性質に依拠し、幅広いレンジウィンドウにわたって適度な精度を提供することができる一方、ＦＭＣＷライダは、光の波性質に依拠する。これらのライダにおいて、変調は、光フィールドの周波数に適用され、光ドメイン内の大きい周波数帯域幅が、アクセス可能になり、ナノメートル範囲での正確性を伴った超高精度位置特定を達成するために利用され得る。
位置決め技法の概要
この章で論じられる位置決め技法の重要な性質は、表３にまとめられる。記載される正確性の数字は、表示目的にすぎないということに留意されたい。実際の位置決め正確性は、ネットワークデプロイメント、セル計画、無線環境などを含むがこれらに限定されない様々な因子に依存する。
Figure 0007241899000003
ハイブリッド位置決め
今日の市場にある多くのデバイスには、慣性測定装置（ＩＭＵ）などのセンサが装備される。ＩＭＵは、例えば、３軸ジャイロスコープおよび３軸加速度計を含み得る。ＩＭＵによって提供されるデータは、ロケーションサーバが、ＯＴＤＯＡ／Ｅ－ＣＩＤ位置決めセッション間、後、または最中にＵＥ軌道を推定することを可能にすることができ、また頻繁なＯＴＤＯＡ／Ｅ－ＣＩＤ測定の必要性を低減することができる。ＩＭＵを使用したハイブリッド位置決めソリューションは、また、デバイスが時間の位置決めカバレッジ部分から出る可能性のあるシナリオにおいて有益であり得、それにより位置決め信頼性を増大させる。位置推定値と一緒にＩＭＵデータを使用する一例が、図１７に例証される。過去の位置推定値から速度および方向を推定し、ＵＥ軌道を予測することによって、ＩＭＵ測定が利用可能でない場合にさえ同じ方法が適用され得る。
ＩＭＵだけに基づいた位置決めシステムは、相対位置決めシステムであり、すなわち、それは、既知の座標に対してＵＥの位置を推定することができるということに留意されたい。例えば、一定期間にわたる圧力差は、高度変化につながり、一定期間中の加速は、速度の変化を示す。
無線測定値をＩＭＵデータと融合するためには、ＵＥを備えたＩＭＵから報告されるデータが、標準化された地球有界座標系と整列される必要がある。または、ＵＥが報告したＩＭＵ測定値は、ロケーションサーバが測定値を地球有界座標系へ変えることを可能にすることができる必要がある。地球座標においてＵＥ位置を得るため、デバイスの方向が必要とされる。方向を決定するための一般的な方法は、ジャイロスコープ、磁力計、および加速度計を使用することである。方向が推定された後、方向および加速度計を使用して、座標系に対して加速度を推定することができる（加速度計から重力を引く）。相対加速度を有することにより、例えば、二重積分によって、デバイスの相対変位を推定することが可能である。
ＬＴＥ Ｒｅｌ－１５は、ＩＭＵ位置決めのためのサポート、ならびにロケーション位置決めプロトコル（ＬＰＰ）を介してＩＭＵ位置決めをサポートするためのシグナリングおよび手順の仕様、ならびにＩＭＵ関連の推定を含むハイブリッド位置決めを含む。
ネットワーク同期正確性
ＬＴＥにおいてサポートされる位置決め方法である、ＯＴＤＯＡならびにアップリンク到達時間差（ＵＴＤＯＡ）では、ＴＤＯＡ推定値において誤差をもたらすネットワーク同期誤差が、位置決め誤差全体を支配し得る。したがって、達成され得るネットワーク同期正確性がどれくらいであるかを理解することが重要である。同期誤差は原則として、同期誤差によって引き起こされるタイミング誤差の間に光が進む距離を考慮することによって、位置決め誤差に直接変わり得、すなわち、１ｎｓの同期誤差は、０．３ｍの位置決め誤差に対応する。
同期誤差は、主に、４つの付加部からなる。
１）アンカー（マクロ基地局およびＤＯＴのためのベースバンドユニット）に送達される外部同期基準における誤差。
２）アンカー（ベースバンドユニット）と外部同期基準との間の同期誤差。
３）無線基地局（ＲＢＳ）内の同期誤差。
４）ＲＢＳアンテナとＵＥとの間の同期誤差。
製造シナリオを検討するとき、本発明者らは、４つの部分の各々について以下の状況を有する。
１）外部同期基準は、典型的には、ＧＮＳＳ受信機に由来する。ＧＮＳＳ受信機は、それが空の大部分へのＬｏＳを有するとき、＜５０ｎｓの正確性を有し得るが、マルチパスが存在するときは、正確性は急速に減少し、屋内ＧＮＳＳ受信機からの仮定される正確性は、＜２００ｎｓである。外部同期は、より良好なマルチパスフィルタリングおよびより良好な内部正確性を有するより高価なＧＮＳＳ受信機を使用することによって改善され得る。
２）ベースバンドユニットは、およそ１５０ｎｓの正確性でＧＮＳＳ受信機に同期することができる。この数字は、より良好なハードウェア、すなわち、新しいベースバンドユニットを使用することによってのみ改善され得る。
３）内部分配のバジェットは、１３０ｎｓである。実際にどうであるかは、ＲＢＳの多くのハードウェア設定に依存する。最も単純なのは、１つのホップでアンテナ一体型無線（ＡＩＲ）ユニットに直接接続される単一のベースバンドユニットである。
４）ＲＢＳアンテナとＵＥとの間の同期誤差がどれくらい大きいかは不明瞭である。しかしながら、ＯＴＤＯＡは、ＵＥが存在する位置においてＵＥによって観察されるＰＲＳの位相を基にするため、この誤差は、ＯＴＤＯＡ位置決め誤差に影響を及ぼすことはなく、ネットワークとＵＥとの間の同期は必要とされない。
上の議論は、ＲＢＳが基準に時間ロックされることを前提とする。ＲＢＳが時間ホールドオーバへ進むと、正確性は減少し得る。
上の数字は、ＲＢＳアンテナと基準との間の位相差が測定および報告される無線インターフェースベースモニタリング（ＲＩＢＭ）によって著しく改善され得る。報告された位相差は、次いで、物体の位置を計算するときに考慮され得る。同期誤差は残っているが、考慮される誤差の部分は、ＯＴＤＯＡ位置決め正確性に影響を及ぼさない。これは、ＲＩＢＭが、ＲＢＳ間で約２０ｎｓの仮想同期正確性を達成し得るため、有望な方法である。それにより、外部同期基準誤差１）は、ＯＴＤＯＡ位置決めに影響を及ぼさず、無視され得る。
ＲＤＳの場合、同じ屋内無線ユニット（ＩＲＵ）に接続されるＤＯＴ間の同期は、ＩＲＵが共通ＤＯＴハードウェアを含むという前提のもと、およそ６ｎｓである。これは、現在利用可能なレガシーＤＯＴおよび２０１９年に利用可能になるデジタル５Ｇ ＤＯＴの両方に当てはまる。ＲＩＢＭは、異なるＩＲＵに接続されるＤＯＴ間の同期を達成するためのソリューションであり得るが、動作するために特殊な特徴を必要とし得、それは、標準ＲＩＢＭアルゴリズムは、ノードが、伝送していないときに受信するために同期されることを必要とするためであり、ＤＯＴはこれを必要としない。
要するに、実際のネットワーク同期アルゴリズムは、ＧＮＳＳ基準にロックされるとき最大３６０ｎｓのネットワーク同期誤差を示唆し得、これは、最大±１１０ｍ（３シグマ）の位置決め誤差に対応する。ＲＢＳが時間ホールドオーバにある場合、正確性はさらに悪くなり得る。将来、ＲＩＢＭは、約２０ｎｓの仮想同期正確性を提供し得、これは、６ｍの位置決め誤差に対応する。ＲＤＳの場合、同じＩＲＵに接続されるＤＯＴを使用した位置決めは、約６ｎｓの同期誤差によって影響され、これは、およそ２ｍの位置決め誤差に対応する。異なるＩＲＵに接続されるＤＯＴが位置を推定するために利用される場合、ＲＩＢＭは、将来、約２０ｎｓの仮想同期正確性を提供するために適用され得る。
厳密なマルチパスシナリオにおいて正確性を改善すること
ＬＴＥ ＯＴＤＯＡ、ならびに他の位置決めアルゴリズムは、マルチパスの問題をハンドリングする方法がない場合、位置決め正確性に関して厳しいペナルティを被る。本質的に、ＯＴＤＯＡは、ＲＳＴＤがＬｏＳ経路を表すことを前提とするが、一般に、ＬｏＳ経路がブロックされる、または極めて減衰されるか否かを決定することは難しい。少なくとも、ｎＬｏＳ経路は、送信機と受信機との間の距離の上界を表すということが言える。マルチパス問題は、典型的な産業環境において、特に高い周波数の場合、顕著である。マルチパス問題に取り組むいくつかの手法としては、以下が挙げられる。
・ノードを好ましい場所に置くことによって、例えば、いくつかの参照場所の位置決め正確性を推定することができる計画ツールを使用することによって、良好なＬｏＳ状態を有するようにネットワークを設計する。これは、より高い設置複雑性を示唆し得、また多くの動く物体を伴う産業環境では実現可能ではない場合がある。
・仮説検証、例えば、ＴＯＡ／ＴＤＯＡ推定値のサブセットからの位置を使用する実現可能性試験を使用して、ｎＬｏＳを推定する。推定が一貫しない場合、それをｎＬｏＳと分類する。この方法は、高密度ネットワークでは高い計算複雑性を有し得る。
・別の代替案は、基準としてＩＭＵ測定および推測航法に基づいて位置更新を検討し、測定されたＴＤＯＡが参照位置と十分に一致しない場合は経路をｎＬｏＳと分類することである。
・線追跡のための環境モデルを使用し、距離推定値を線と関連付ける。このやり方では、ｎＬｏＳ推定値は、より良好な方法で位置決め推定値に貢献し得る。そのような環境モデルは、多くの場合、利用可能でないが、デジタルツインが開発される場合に使用され得る。
・偏光を使用したｎＬｏＳの推定。偏光は、バウンス事象において変化するため、ｎＬｏＳは、参照偏光が誤っている場合に検出される。
・個々の距離推定値を通信に依存しない速度／位置測定（ジャイロ／加速度計）と比較して、どの推定値が実行可能にＬｏＳであるかを決定する。当然ながら、すべてのＵＥがそのようなロケーションセンサを装備するわけではない。
・Ｒｅｌ－１４は、マルチパス参照信号時間差（ＲＳＴＤ）と呼ばれるＬＴＥ ＯＴＤＯＡに対する重要な強化を導入した。主たる考えは、電力遅延プロファイル（ＰＤＰ）からいくつかの潜在的なピーク候補を含み、最大尤度を使用して位置を推定することであった。このやり方では、アルゴリズムがＬｏＳ経路について難しい決断を行わないため、位置決め正確性が著しく改善された。
要するに、本発明者らは、製造のための最も好適な位置決めシステムの選択は、以下を含むいくつかの異なる側面を考慮しなければならないと結論付けることができる。
・必要とされる正確性
・必要とされるレイテンシ
・デプロイメント面
・デバイス
正確性については、ｍｍレベルの正確性から十分の数メートルに及ぶ位置決め要件を伴う産業使用事例が存在する。ＬｏＳの高い確率および少ないブロッキング障害物を伴う環境においては、例えば、工場ホールの天井内に１つのみまたはいくつかのマイクロ基地局が取り付けられたデプロイメントでは、十メートルから十分の数メートルの正確性以内で位置を推定することが可能であり得る。しかしながら、多くの製造シナリオにおいて、現実は、マルチパス、反射、および多くのブロッキング障害物を伴う環境である。そのようなシナリオにおいては、無線ドットシステム（ＲＤＳ）が、高密度デプロイメントおよび低費用のノードに起因して、通信および位置決めの組合せを提供するための最も好適なソリューションのようである。
異なる位置決め技法について記載される正確性数値は、多くの場合、ネットワーク同期が十分に良好であることを前提とする。しかしながら、多くの場合、３～６ｍの位置決め誤差に対応する約１０～２０ｎｓのネットワーク同期誤差は、達成するのが非常に困難である。位置決めの必要性のため、ＲＩＢＭを通じて達成される仮想ネットワーク同期は、最も有望なソリューションである。
ＵＷＢソリューションは、高い正確性および比較的安価なデバイスに起因して、産業および製造使用事例においてますます人気になっている。しかしながら、１つの欠点は、ＵＷＢソリューションが通信システムと統合されないことであり、これは、例えば、３ＧＰＰベースのソリューションに言えることである。将来、ＮＲがＵＷＢに置き換わり得るが、それは、ＮＲもまた非常に幅広い帯域幅を使用するためである。
製造における位置決めレイテンシ要件は、大半の使用事例では緩和される。例えば、器具およびアセットを追跡し続けることは、非常に頻繁な位置決め更新を必要としない。位置決めレイテンシに関して最も要求の多い製造使用事例は、安全性関連であり得る。１つの例は、フォークリフトが近いときに作業者に警告するためのリアルタイム警報である。そのような使用事例のための高い正確性と位置決めレイテンシとのトレードオフは、まだ徹底的に研究されていない。
デバイスとアンカーとの関係も、検討することが重要である。ＬＴＥおよびＮＲの場合、デバイスおよびアンカーの両方が複雑かつ高費用であり、したがって、これらの技法を基にしたソリューションは、多くの小さい物体が追跡されるべき使用事例には、各物体が独自のＬＴＥまたはＮＲデバイスを有さなければならないため、好適ではない。この場合、ＵＷＢまたはＲＦＩＤは、複雑性の大半がアンカーノードにあり、したがってデバイス／タグが安価であるため、より好適であり得る。ＮＢ－ＩｏＴまたはＣＡＴ－Ｍなど、安価なデバイスを用いた３ＧＰＰベースの技術もまた、このタイプの使用事例のために検討され得るが、これらの技法は、狭帯域であるため、達成され得る位置決め正確性は低い。
スペクトル
産業アプリケーションでは、スペクトルに関連するいくつかの特定の問題として以下が挙げられる。
・ローカル使用に好適なスペクトル、
・ローカルスペクトル使用を可能にするための規制手段、例えば、リーシングおよびローカルライセンシング、
・ローカルスペクトル使用を可能にするための技術的手段、例えば、エボルブドライセンス共有アクセス（ｅＬＳＡ：ｅｖｏｌｖｅｄ Ｌｉｃｅｎｓｅｄ Ｓｈａｒｅｄ Ａｃｃｅｓｓ）および市民ブロードバンド無線サービス（ＣＢＲＳ：Ｃｉｔｉｚｅｎｓ Ｂｒｏａｄｂａｎｄ Ｒａｄｉｏ Ｓｅｒｖｉｃｅ）。
・５Ｇ ＮＲは、ＬＴＥのために現在使用される多くを含め、様々な周波数帯域にわたってアクセス技術として使用されることになる。いくつかの周波数範囲は、３４００～３８００ＭＨｚおよび範囲２４～２９ＧＨｚの上部など、より世界的に調和化される可能性が高いが、バンドプランにおける変動がおそらくは存在することになる。ＩＭＴ２０２０のためのバンドの識別に至るまでのＷＲＣ－１９（２０１９年世界無線通信会議）の研究プロセスは、調和化の優れた見込みが存在する追加のミリメートル波（ｍｍＷ）スペクトル帯域、例えば、３７～４３ＧＨｚをもたらし得る。
近年の規制は、「ローカルまたは地域使用」のための帯域（例えば、ドイツおよびスウェーデンでは３７００～３８００ＭＨｚ、中国では３３００ＭＨｚ）を指定している。そのようなアクションは、産業ＩｏＴのための世界的な無線ソリューションではない。依然として、これらの帯域の導入は、スペクトルの私的使用ライセンスのための優れた最初のステップである。これらの規制措置がすべての市場に直ちに広がることは予期されない。したがって、世界的に調和化されたスペクトルへの追加のアクセスは、本質的には、スペクトルのリーシング、または明確に定義されたサービスレベルアグリーメント（ＳＬＡ：Ｓｅｒｖｉｃｅ Ｌｅｖｅｌ Ａｇｒｅｅｍｅｎｔｓ）のもとキャパシティのリーシングを可能にするビジネスアグリーメントを通じた、モバイルネットワークオペレータ（ＭＮＯ：Ｍｏｂｉｌｅ Ｎｅｔｗｏｒｋ Ｏｐｅｒａｔｏｒ）に許可されたスペクトルから生じる機会を必要とするということは明白である。
ｍｍＷスペクトルの可用性は、市場において製品を確立するために必要とされる時間、およびそのような高い周波数での半導体製造の複雑性に主に起因して、産業ＩｏＴの課題をもたらす。機器のための構築慣例は確立されておらず、デバイスのための費用対効果の高いソリューションに大きな課題が残っている。ミリメートル波機器もまた、いくつかの利点を提供し得る：狭ビーム送信機の伝搬特性は、伝送電力制御およびビーム形成を用いた良好な再使用を可能にすることができ、共存も同様により容易であり得る。周波数帯域はまた、より幅広い帯域幅信号に好適であるが、産業無線に利用可能にされ得るスペクトルの量においては不確実性が残る。
文献ではインダストリ４．０として知られる第４次産業革命は、製造業、工場内の探査および加工制御状況、鉱山、加工業などにおける５Ｇ無線技術の機会である。これらの機会の開拓は、未認可、共有、または独占的認可のいずれかの、スペクトルへのアクセスを必要とする。実際、高品質の認可されたスペクトルへのアクセスの欠如が、克服されなければならない主な障害であるという産業からの明示が存在する。産業ＩｏＴのための認可されたスペクトルへのアクセスは、３つのやり方のうちの１つで提供され得る。
１．サービスレベルアグリーメント（ＳＬＡ）：ＭＮＯとのアグリーメントは、ＭＮＯ提供または支給のサービスにより、これらの要件を満たすことができる。例えば、
・ターンキー方式でのオンプレミスＭＮＯデプロイメント、または公開ネットワークに任意選択的に接続される認証機器のＭＮＯ許可エンドユーザデプロイメント。このケースは、この議論ではこれ以上扱われない。
・代替案は、ネットワークスライシングの使用を通じてＭＮＯネットワーク上でのキャパシティを保証するプライベート仮想ネットワークを確立することである。
２．スペクトルリーシング：バーティカルに向けた貸与者としての役割を果たすＭＮＯ。
３．ローカルライセンシング：典型的には適用区域の所有権と関連付けられた、限定された地理的デプロイメントにわたる、直接的にバーティカルへの規制当局ライセンススペクトル。
スペクトルリーシングの規制状況は以下に要約される。スペクトルリーシングの規制は、５Ｇ使用事例の潜在的なビジネスモデルにとって関心の対象である。
・米国は、スペクトルリーシング、２００３～２００４年まで遡ったリーシング日のための規制、に関して最も成熟している。スペクトルリーシングは、商業的に使用される。公開データベースユニバーサルライセンシングシステム（ＵＬＳ：Ｕｎｉｖｅｒｓａｌ Ｌｉｃｅｎｓｉｎｇ Ｓｙｓｔｅｍ）がすべてのリーシングアグリーメントを記録する。
・南アメリカでは、少数の国がＭＮＯ間のリーシングを許可する。
・ＥＵでは、主なモバイル／セルラ帯域のリーシングは、２０１２年以降、規制において許可される。それは、加盟国における規制では必ずしも実施されない。非ＭＮＯに対するＭＮＯ所有の周波数の商業リーシング例は今のところ見つかっていない。
・アジアでは、美人投票（ｂｅａｕｔｙ ｃｏｎｔｅｓｔ）が、一般的に、いくつかの重要な国においてスペクトルリーシングを防ぎ、故に規制の部分ではない。
・アフリカでは、スペクトルリーシングは、一般的に、許可されない。
ローカルライセンスに関して、そのようなライセンスは、現在、私的／公的使用のために存在していない。いくつかの５Ｇ使用事例は、特に産業自動化に対処することと関連付けられるとき、ローカルライセンシングから恩恵を受け、５Ｇ導入がこの点に関して機会を提供する。欧州における第１の５Ｇバンド（３．４～３．８ＧＨｚ）の計画オークションは、ローカルライセンシングの特定の実現を規定することによって２つの国（ドイツおよびスウェーデン）における規制活動をトリガしている。中国では、産業は、専用スペクトルに関心を示している。
可能なソリューションの完全な見解を示すために、産業アプリケーションに好適な未認可帯域についても触れる。未認可帯域は、一般的には、コンテンションベースの動作に起因する干渉の可能性が理由でＵＲＬＬＣには適さず、アクセス性能における変動が、スループットおよび遅延性能における不確実性を作り出す。
エボルブドＬＳＡ（ｅＬＳＡ）は、データベース／コントローラアーキテクチャを用いて規制内でリーシングおよびローカルライセンシングをサポートするための、現在特定されているソリューションである。ｅＬＳＡは、任意の帯域をサポートし、また技術依存しない（ｔｅｃｈｎｏｌｏｇｙ ｎｅｕｔｒａｌ）と考えられている。同様に、３５５０～３７００ＭＨｚ帯域でまず使用されることになる、米国内の市民ブロードバンド無線サービス（ＣＢＲＳ）は、その帯域の規制要件をハンドリングするためにスペクトルアクセスシステム（ＳＡＳ）を使用することになる。これは、ローカルエリア使用のためのリーシング機会を提供するデータベース／コントローラアーキテクチャでもある一方、実際のライセンシングは、ＦＣＣ規制のとおり、より大きいエリアをカバーしている。ＳＡＳは、適切な規制要件を前提として他の帯域に対しても同様に使用され得る。ｅＬＳＡおよびＣＢＲＳは、国または地域における必要な規制要件に従って異なるデプロイメント同士の共存に応じる。しかしながら、共存が確実にされる方式は、ｅＬＳＡとＣＢＲＳとの間で異なる。
多くの異なるスペクトル帯域が５Ｇのために識別される。ここでは、ＮＲ技術を使用する可能性の高い帯域のみが論じられる。例えば、７００ＭＨｚ帯域は、欧州郵便電気通信主管庁会議（ＣＥＰＴ：Ｅｕｒｏｐｅａｎ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｐｏｓｔａｌ ａｎｄ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ａｄｍｉｎｉｓｔｒａｔｉｏｎｓ）では５Ｇバンドとして識別されるが、おそらく４Ｇを実装する。同じことが、７００ＭＨｚ帯域に関してＡＰＡＣにも当てはまる。また、２．３ＧＨｚ帯域が、例えば、スウェーデンにおいて議論されているが、現在は主に４Ｇの文脈においてである。
現在、世界のすべての国において有効であり割り当てられた５Ｇ ３ＧＰＰ調和化帯域は存在しないが、３４００～３８００ＭＨｚ、２４．２５～２９．５ＧＨｚのような調和化スペクトル範囲は存在する。いくつかの３ＧＰＰ帯域は、各範囲内で規定されることになる。割当て中の多くのｍｍＷ帯域は、ＷＲＣ－１９からの結果に左右される。
欧州
３４００～３８００ＭＨｚ帯域は、ＣＥＰＴ内では５Ｇのための「先駆的な帯域」として識別される。異なる国のための計画は、非常に異なるライセンス有効期限を有する既存事業者に応じて、大いに異なる。全帯域をオークションする計画をする国が存在し、そして通常、スウェーデンにおいてのように、１００ＭＨｚブロックが提案される。他の国は、既存事業者使用に起因して、現在、上位または下位、例えば、２００ＭＨｚしか利用可能にしていない。これは、英国においてのように、より狭い帯域ライセンスを結果としてもたらす。残りのスペクトルが利用可能になるとき、新規オークションが発生する。これは、帯域の再割当てなど、何も行われなければ、オペレータにとって非連続的なスペクトル保持を結果としてもたらす。「キャリアアグリゲーションが存在する」ため、再割当ては発生しない場合がある。
既存の計画に従ってローカルサービスのために１００ＭＨｚ（３７００～３８００ＭＨｚ）を取っておくことを提案するドイツおよびスウェーデンを除き、大半の国は、国家ライセンスを奨励する。ブロックは、スウェーデンでは２０２３年に概して利用可能である。
ＥＣ（Ｅｕｒｏｐｅａｎ Ｃｏｍｍｉｓｓｉｏｎ）からの「５Ｇアクションプラン」において、すべての国が、
・２０２０年中に各国少なくとも１都市において５Ｇネットワークを使用可能にすること、
・完全な構築を２０２５年に整えること、
が規定される。
このことは、ＥＣ目標を実現するために、様々な国家カバレッジ要件が存在するため、おそらく、大半の国が中帯域（３～８ＧＨｚ）に焦点を合わせることを意味する。
２６ＧＨｚ帯域（２４．２５～２７．５ＧＨｚ）もまた、５Ｇのために識別される。正確な規定は、ＷＲＣ－１９の結果に大いに依存している。大半の国では、範囲２６．５～２７．５ＧＨｚは、空であり、これよりオークションされ得る。一部の国では、オークションが既に開始している。
米国
米国では、ｍｍＷ（２４／２８／３７／３９ＧＨｚ）上に５Ｇを標的とするいくつかの帯域が存在し、連邦通信委員会（ＦＣＣ）が中帯域スペクトル（例えば、３．７～４．２帯域）を検討し始めたのはほんの最近である。６００ＭＨｚのＴ－Ｍｏｂｉｌｅおよび２６００ＭＨｚのＳｐｒｉｎｔなど、オペレータは、ＮＲを配備するための既存の帯域の部分を識別している。
既存の被許諾者によって所有されていない２８／３９ＧＨｚにおけるｍｍＷスペクトルの予定されているＦＣＣオークションがある。
中帯域では、５Ｇは、ＣＢＲＳ帯域（３５５０～３７００ＭＨｚ）において許可されることになる。この帯域は、１０ＭＨｚブロックに基づいて、認可（ＰＡＬ）および一般認証（ＧＡＡ）ブロックを有する。３７～３７．６ＧＨｚでは、ローカル使用のためのライセンスが規定されることが提案される。
アジア太平洋
アジア太平洋領域内の主要国のうちのいくつかは、２０１８／２０１９年中にオークションを計画している。
韓国は、オペレータに対して、２０１８年６月に、３．５ＧＨｚ（３４２０～３７００ＭＨｚ）および２８ＧＨｚ（２６．５～２８．９ＧＨｚ）をオークションした。
中国は、２０１８年中に、２．６ＧＨｚ（合計１６０ＭＨｚ）および４．９ＧＨｚ（１００ＭＨｚ）上の追加の周波数をＣＭＣＣに割り当てることを計画している。３．５ＧＨｚ（３３００～３６００ＭＨｚ）のためのオークションが２０１９年に計画され、ここでは３３００～３４００ＭＨｚが、屋内使用のために計画される。現在、２３００ＭＨｚは、主に４Ｇ屋内であるが、いまのところ５Ｇを許可する兆候はない。
日本は、２０１９年中、帯域３．６～４．１ＧＨｚ、４．５～４．８ＧＨｚ（私的運用のための２００ＭＨｚ）、および２７～２９．５ＧＨｚ（私的運用のための９００ＭＨｚ）のためのコンテストを計画している。３４００～３６００ＭＨｚの一部は、既にＬＴＥに割り当てられており、徐々に５Ｇに変換されることになるが、日本では、帯域割当ては法律により規定され、変更には時間がかかり得るということに留意されたい。
オーストラリアは、２０１８年後半中に、３４００～３７００ＭＨｚに対する５Ｇオークションを計画している。
５Ｇオークションを計画するためのプロセス中である他の国は、インド、インドネシア、パキスタン、タイ、およびベトナムである。
中東
ＵＡＥ、サウジアラビア、およびカタールのような国々は、３．５ＧＨｚおよび２６ＧＨｚのための確固たるオークション計画２０１９～２０２１年を有する。他の国々もまた、予定しているオークションについて示しているが、詳細はまだ分かっていない。
スペクトルの概要
異なる国における４Ｇ／５Ｇスペクトル帯域の概要は、表４に示される。濃く塗られた項目は、ローカルサービスのため、および産業自動化のために使用され得る。
Figure 0007241899000004
ローカルスペクトルへのアクセスを制御するための規制方法
ローカルスペクトルへのアクセスを得るために２つの他の規制方法が存在する：
・スペクトルリース、
・ローカルライセンシング。
これらの方法は、オペレータがスペクトルに対する顧客制御に同意する場合、または規制当局が実行可能な方策としてローカルライセンシングを確立する場合、適用可能である。
スペクトルリース手法のもと、被許諾者／貸与者は、料金ありまたはなしで、自らのライセンスの部分を賃借者にリースする。賃借者は、周波数帯域の部分、特定の地理的領域へのスペクトルの一部分、または両方をリースすることができる。サブリースは、賃借者が二次賃借者にスペクトルをリースするときである。スペクトルリーシングの規制観点は、図１８に示される。
スペクトルのリーシングのための規制は、国ごとに異なる。多数の側面が規制され得る。
・専門用語
・スペクトルに対する法律上（法定）の制御と事実上（原則として無線ネットワーク所有者）の制御とを区別または区別なし
・適用のためのプロセス、例えば、認証までの定められた時間
・例えば、競争関連事項を考慮して、どの帯域がリーシングに利用可能であるか
・ライセンス認証の期間を超えることなく、リースの期間
・サブリーシングの可能性
・リースのために規定される領域
・その他
また、規制当局は、リーシングアグリーメントのおおよそを公開することを選択することができる。
以下は、スペクトルリーシングに関する規則状況の概観である。
・米国は、スペクトルリーシングに関して最も成熟しており、規制は、２００３～２００４年から存在する。スペクトルリーシングは、商業的に実施される。スペクトルリーシング、スペクトルアグリゲータ、スペクトルブローカの例が存在する。すべてのリーシングアグリーメントを含む公開検索可能データベース（ＵＬＳ）が存在する。
・南アメリカでは、少数の国がＭＮＯ間のリーシングを許可する。
・ＥＵでは、主なモバイル／セルラ帯域のリーシングは、２０１２年以降、規制において許可される。それは、加盟国における規制では必ずしも実施されない。スウェーデン、フィンランド、英国、アイルランド、ドイツ、フランス、またはイタリアにおいては、ＭＮＯ所有の周波数についての任意の商用リーシング例があるようには見えない。
・英国では、リーシングは、競争関連事項に起因して、主要セルラ帯域においてＯｆｃｏｍによって許可されていない。
・アイルランドでは、リーシングは、競争関連事項のＣｏｍＲｅｇ審査後に、主要セルラ帯域において許可される。
・スウェーデンでは、スペクトルリースは許されている。規制当局は、これまでのところ、規制当局のオークション計画（安定した長期計画の欠如）に起因して短期間リーシングのみを許可している。オペレータは、これまでのところ、保護が保証された長期間リーシングを、それらのネットワーク計画／構築における不確実性に起因して、許可していない。
・フィンランドでは、スペクトルリースは許されているが、リーシングは、ＭＮＯライセンスに関連して全く対処されておらず、したがってこのケースは、規制当局によって全く実施されていない。
・ドイツの場合、スペクトルリーシングは、最初、２０１８年秋に、３．７～３．８ＧＨｚに関する協議において対処された。規制当局は、使用権所有者およびユーザ（テナント）を被許諾者と規定した。
・イタリアでは、スペクトルリースは許されており、商業的に使用される。
・アジアでは、コンテストが、概して、いくつかの重要な国におけるスペクトルリーシングを防ぎ、したがって、スペクトルリーシングは、規制の一部分ではなく、例えば、中国、インド、日本では許可されていないが、スペクトル取引きに対する関心は高まっている。スペクトルリーシングは、韓国では、許可されているが、使用されていない。
・アフリカでは、スペクトルリーシングは、概して、許可されていないようである。しかしながら、ナイジェリアは、近年、スペクトルリーシングを含むスペクトル取引きガイドラインを公開した。
・米国におけるＭＮＯスペクトルの商用リーシングは、いくつかのケースに関係する。
・全国的なオペレータは、キャパシティ／カバレッジ／成長が必要とされる市場に対処するために、自らの間でスペクトルをリースする。
・全国的なオペレータは、例えば、ＶｅｒｉｚｏｎのＬＴＥ ｉｎ Ｒｕｒａｌ Ａｍｅｒｉｃａ（ＬＲＡ）プログラムなど、非全国的なオペレータにスペクトルをリースする。Ｖｅｒｉｚｏｎは、このプログラムに２１の地方および小規模キャリアを登録し、１９がこのプログラムを介してＬＴＥネットワークをローンチした。このプログラムは、Ｖｅｒｉｚｏｎがルーラルエリアを素早く構築することを可能にする。
・Ｉｎ
・例えば、工場自動化使用事例において、５Ｇバーティカルのためにスペクトルをリースすることに関心のあるＭＮＯは、未だ見られない。
オペレータからのモバイル帯域のスペクトルリーシングは、カバレッジおよび規制当局からの他の要件を満たすために、主に他のオペレータに向けて行われている。量の点で、これは、ほぼ米国内のみである。
より高い帯域（＞１０ＧＨｚ）では、固定サービスは、サービスプロバイダによるオペレータからのリーシングを伴う使用事例である。これは、米国および欧州の両方において確立される。
５Ｇの到来に伴って、バーティカルは、専用（モバイル）スペクトルを必要とした使用事例を提供する。１つの疑問は、どの当事者が賃借者となるのかである。
モバイルスペクトルをバーティカルにリースする可能性に関する長期的なオペレータの反応は分からない。そのようなリーシングアグリーメントの貸与者および賃借者の両方にとって、起こる機会および問題がある。例えば、
・十分に活用されていないスペクトルに対するＭＮＯの関心
・ＭＮＯは、大量の需要がある地域、または需要が５～１０年以内に予期される地域でスペクトルをリースすることをためらう場合がある
・３０年超の必要なリース時間は、プロセスおよび建造物への投資に起因して、ＭＮＯのライセンス継続期間よりもはるかに長い。
５Ｇの導入は、ネットワークスライシングを通じてＳＬＡを提供するオペレータの能力に幅広い変化を引き起こすことになる。ネットワークスライシングは、３ＧＰＰベースのネットワークにより様々な程度にサポートされるが、５Ｇ ＣＮは、使用事例、ＱｏＳクラス、ならびにサービスプロバイダ間での分離をもたらすためにネットワークスライスをプログラミングすることを可能にするフレームワークをオペレータに提供する。このとき、スライシングがネットワークキャパシティのリーシングを可能にすることができるデプロイメントケースを有することが可能である。これは、ローカルユーザがエンドツーエンドＳＬＡの制御下にあること、および、例えばＱｏＳを含む、ＲＡＮの挙動を限度内で制御することさえ可能にする。ＭＮＯは、計画および管理に対する全体的制御を失うことなく、リーシングのＳＬＡに従って、ＲＡＮを配備し、ＣＮと統合する。
スペクトルリーシングに可能な帯域は、特定の要件に準拠しなければならない。帯域のリーシングは、特定の国／地域の規制において許可されなければならない。上の表４から中国、アフリカ、および日本を取り除いたものは、以下の表となる。
Figure 0007241899000005
ローカルライセンシング
ライセンスの大部分は、ライセンスのためのエリアを規定するための既定の行政区画を使用する。例えば：
・国境
・地域の境界、または他のより大きい行政構造
・コミュニティ／地方自治体
粒度の次のレベルは、所有地であり得る。この手法では、所有地および土地使用権が、ローカルライセンスのために使用されるべき行政規定として使用され得る。ローカルスペクトルがより大きいエリアスペクトルライセンスから必要とされる場合、粒度を増大させるための１つのソリューションは、サブエリアのリーシングを使用することである。このソリューションは、必要に応じて、所有地よりも大きいエリアを規定することができる。
現在、規制当局が地域／地方自治体よりも小さいエリアのためのローカルライセンスを規定するとき、この規定は、座標および放射状範囲、イベント名、住所、エリアを規定する座標などであった。これは、そのようなライセンスの数が小さかったため、問題になっていなかった。しかしながら、５Ｇ使用事例の到来により、これは変化するであろう。これは、規制当局にとっての進行中の仕事である。
ローカルライセンスの数が５Ｇ使用事例と共に増えれば、調整も増える必要がある。
・地理的データベースが、例えば新規申込者のための、ライセンスエリアを示すために必要とされる。
・実装間の干渉は、規制要件を通じた調整を必要とする。
商業サービスのための国家および地域ライセンスが存在するが、ローカルライセンスは、試験機関および試験工場などの非商業目的のためにも存在する。場合により、いくつかのＰｒｏｇｒａｍ Ｍａｋｉｎｇ ａｎｄ Ｓｐｅｃｉａｌ Ｅｖｅｎｔｓ（ＰＭＳＥ）サービスのためのライセンスは、ローカルと見なされ得る。新しいタイプの使用事例を伴った５Ｇの到来は、例えば、工場のためのローカルライセンスを必要とすることになり、規制に新規要件を課す。
欧州内の５Ｇサービスの一次帯域は、３．４～３．８ＧＨｚであり、この帯域のオークションは、ローカルライセンスに関する規制活動をトリガする。より高い帯域、例えば、２４．２５～２７．５ＧＨｚ（欧州内での早期実装のための先駆的な帯域）は、それらの伝搬特性が、特に屋内で使用されているとき、共存問題を引き起こす可能性が低いという意味で、ローカル使用に好適である。現在、これらの帯域のためのローカルライセンスに関する規制議論は、主として範囲外であるか、または、単に可能性の範囲に入っているだけであり得るが、これは、産業関心と共に変化することが予測される。
特定の屋内環境は、ネットワークが現代建築物内の床によって分離される場合は特に、複数の使用にわたるスペクトルの再使用に適している。建築物の複数階にわたる損失は、３．５ＧＨｚのような中帯域周波数においてさえも何十ｄＢにもなり得ることがよく知られている。
中国の産業は、ドイツの３．７～３．８ＧＨｚの提案を指して、規格フォーラムにおいてローカルライセンスへの関心を示している。
産業に割り当てられるライセンスの一例は、１９９０年代にカナダ水力発電産業に提供された１８００～１８３０ＭＨｚからの割当てである。
欧州：３．７～３．８ＧＨｚ（３．４～３．８ＧＨｚの部分、５Ｇサービスのための一次帯域）
いくつかの国は、スペクトルをオークションしており、さらに多くがそれに続く。２つの国が、ローカルライセンスを含む協議を行っており、互いに追従している。
・ドイツは、２０１８年の第３四半期にオークション規則を発布し、２０１９年Ｑ１～Ｑ２にオークションがスケジュールされている。この規則は、「ローカル所有地関連使用」のため、屋内使用と屋外使用とを区別し、所有地をローカルの定義と示唆する。例えば、道路、公園など、私有地ではない所有地が存在することに留意されたい。
・スウェーデン、オークション遅くとも２０２０年Ｑ１。近年の協議は、「ローカルブロック割当て」を規定する。ここでローカルは、鉱山、屋内施設、およびホットスポットなど、「小さい地理的地域」を指すと規定される。通常、地方自治体に対応する、地域ライセンスもまた、この協議で触れられることにも留意されたい。
米国：３．４～３．５５ＧＨｚ（ＣＢＲＳへの拡張の可能性）
米国では、電気通信情報局（ＮＴＩＡ）が、この帯域における軍用レーダとモバイルブロードバンドとのスペクトル共有を評価している。既存事業者システムは、ここでは、既存のＣＢＲＳ範囲と比較して異なる。ＣＢＲＳ規則が適用される場合、認可された運用は、国をまたがり、第３のティアが、一般認証アクセスによって含まれる。ＣＢＲＳ帯域内の広域サイズは、バーティカルがオークション市場に参加しそうもないため、産業使用には不向きである。
ローカルライセンシングのための帯域
ローカルライセンシングに可能な帯域は、特定の要件に準拠しなければならない。ローカルライセンシングは、規制当局によって許可されなければならない。
上の表４にローカル構想を入れたものが、以下の表となる。
Figure 0007241899000006
リーシングおよびローカルライセンシングのための技術サポート
欧州では、ｅＬＳＡは、既存事業者を合理的な予測可能時間内に撤退させることができない、ＩＭＴ帯域内のスペクトルへのアクセスを管理するＥＴＳＩ指定のシステムライセンス共有アクセスの継続である。アクセスは、時間および地理的地域において管理され得る。このシステムは、地理的な保護、および既存事業者が他者に使用を許可しない除外区域を作り出す。ｅＬＳＡでは、許容区域は、多くのローカルアクセスライセンスを承諾および管理するプロセスが自動化され得るローカル被許諾者ハンドリングも可能にするために導入される。それは、ＭＮＯなどの確立されたライセンスからのローカルエリアユーザへの周波数のリーシングのハンドリングも含む。図１９は、ＩＭＴなどのモバイルサービスに割り当てられる周波数帯域についての仮定したスペクトル割当て可能性を示す。
ｅＬＳＡシステムに対する仕様作業は、ＥＴＳＩ（欧州）において開始しており、ＥＴＳＩ技術レポート「Ｆｅａｓｉｂｉｌｉｔｙ ｓｔｕｄｙ ｏｎ ｔｅｍｐｏｒａｒｙ ｓｐｅｃｔｒｕｍ ａｃｃｅｓｓ ｆｏｒ ｌｏｃａｌ ｈｉｇｈ－ｑｕａｌｉｔｙ ｗｉｒｅｌｅｓｓ ｎｅｔｗｏｒｋｓ」に基づく。システム要件に関する技術仕様は、２０１８年の終わりに準備が整い、アーキテクチャおよび手続きフローに関する仕様がその後に続き、次いでプロトコル仕様がその後に続くと仮定される。「ローカルエリア」に関連したアジア太平洋情報では、サービスが共有されており、技術レポートへの作業が承認されている。
ｅＬＳＡシステムは、データベース／コントローラ概念に基づく。ｅＬＳＡシステムは、ライセンシングおよびリーシングをサポートするが、例えば、ホワイトスペースまたは規則により認可されたアクセスなどのアクセスが認められた未認可／ライセンス免除運用は、これが必要な干渉保護要件を提供しないことから、サポートしない。
データベースは、ｅＬＳＡレポジトリと名付けられ、規制ドメイン内にあると仮定される。コントローラは、ｅＬＳＡコントローラと名付けられ、ｅＬＳＡ被許諾者のシステムが、ライセンシング状態に従って動作するために必要な設定を有することを確実にし、それにより、ＵＲＬＬＣ使用事例をサポートするための高品質ニーズを容易にサポートする。コントローラは、ｅＬＳＡレポジトリから必要な規制共有および共存要件を得る。
図２０は、ローカルライセンスのための考えられるアーキテクチャスケッチを示すが、図２１は、リーシングのための考えられるアーキテクチャを示す。後者の場合、ＭＮＯが周波数をリースするＭＮＯであることから、ｅＬＳＡコントローラボックスもまた、ｅＬＳＡレポジトリ機能性のうちのいくつかを含む。
米国では、連邦通信委員会（ＦＣＣ）が、ＦＣＣ規則において成文化された規制において、３５５０～３７００ＭＨｚ帯域内の市民ブロードバンド無線サービス（ＣＢＲＳ）を規定している。図２２は、ＣＢＲＳの態様を例証する。
ＣＢＲＳ帯域は、海軍のレーダによって、および固定衛星システム（ＦＳＳ）サービスによって使用中であり、両方のサービスがティア１既存事業者主要使用を占める。４７ ＣＦＲ Ｐａｒｔ ９０、Ｓｕｂｐａｒｔ Ｚの規則の下で動作する、無線インターネットサービスプロバイダ（ＷＩＳＰ）などの既得無線ブロードバンドサービスユーザはまた、２０２０年４月までＣＢＲＳからの干渉から保護される。２つの残りのティアはそれぞれ、無線ブロードバンド使用のための帯域内の優先アクセスライセンス（ＰＡＬ）および一般認証アクセス（ＧＡＡ）の発行を許可する。ＰＡＬユーザは、獲得したライセンスエリアおよび帯域幅に基づいたスペクトルへのライセンスから恩恵を受ける。ＧＡＡユーザは、認証されたアクセスに基づいて、高次のティアによって利用されない任意のスペクトルにアクセスすることを許可される。
無線デバイスは、それらの場所およびそれらの動作パラメータに基づいて、市民ブロードバンド無線サービスデバイス（ＣＢＳＤ）として登録される。任意の適格な無線デバイスが、優先アクセスライセンス（ＰＡＬ）およびＧＡＡスペクトルへのアクセスを要求し得る。ＦＣＣは、ＧＡＡスペクトルユーザのためのいかなる規制保護ももたらさないため、ＧＡＡ共存のためのソリューションを作成するのは産業アグリーメントに委ねられている。ワイヤレスイノベーションフォーラム（ＷＩｎｎＦｏｒｕｍ）は、大半は規制順守に向けて取り組まれる技術アグノスティックプロトコルを指定しているが、ＣＢＲＳアライアンスは、ＣＢＲＳ内で動作するＬＴＥネットワークの性能を改善することを求めている。
ＣＢＲＳアライアンスは、公共サービスと関連付けられたオペレータ開発のスモールセルネットワーク、最後の１マイルの代用のための固定無線サービス、および産業無線を含む、様々な使用事例のために、帯域内のＬＴＥの運用を促進および改善することを求める産業貿易機関として特権を与えられた。このアライアンスは、従来のオペレータ開発の運用およびニュートラルホストを含むプライベートネットワーク運用の両方を許可するためにネットワークアーキテクチャへの変更を指定しており、帯域４８および４９を、この帯域内でのＬＴＥ－ＴＤＤおよびＬＴＥ－ｅＬＡＡ運用のために規定するための３ＧＰＰにおける貢献の推進力を確立するためにプラットフォームを提供した。ＣＢＲＳアライアンスはまた、２０１９年に、５Ｇ ＮＲをこの帯域に導入する。産業無線アプリケーションに対する５Ｇの焦点は、ＣＢＲＳアライアンスの使命と合致する。
ジオロケーションデータベースおよび政策マネージャである、スペクトルアクセスシステム（ＳＡＳ）は、ＣＢＳＤによるＣＢＲＳスペクトルへのアクセスを承認する。ＳＡＳは、主に、ＦＣＣ規制に従って、高次ティアユーザを低次ティア運用から保護する。ＣＢＲＳにおける論理的関係性は、ＧＡＡスペクトルのための共存マネージャ（ＣｘＭ）機能性を含む、高水準ＳＡＳアーキテクチャを例証する図２３に示されるような、ＳＡＳ－ＣＢＳＤおよびＳＡＳ－ＳＡＳインターフェースによって説明される。連邦レーダシステムは、沿岸レーダ活動に関するＳＡＳを通知する環境センシングコンポーネント（ＥＳＣ）を形成するセンサのネットワークの実装によって保護される。ＰＡＬユーザは、１０ＭＨｚブロックにわたる大きい地理的領域に対する地域ライセンスを与えられる。
各ＰＡＬは、１０ＭＨｚであり、ＣＢＲＳ帯域の最初の１００ＭＨｚ、すなわち、３５５０～３６５０ＭＨｚ内に制限された最大７つのライセンスに限定される。新たな規則は、国に対する基本ライセンスエリアを有し、これは米国においては番号３１４２である。各ライセンスエリアには７つのＰＡＬが存在し、ライセンス期間は、再交付の保証付きで１０年であり、ライセンスは、区分化および分割され得る。単一のオペレータは、最大４つのＰＡＬライセンスを上限とする。地理的制約の下でスペクトルをリースする能力およびライセンスを分割する能力は、産業のためのスペクトル使用における二次市場をサポートする。このやり方では、ＰＡＬライセンスは、おそらく大きな負担なくＵＲＬＬＣをサポートできる。
ＷＩｎｎＦｏｒｕｍは、既存事業者の保護を含む、帯域を管理するための技術依存しない機構、およびＰＡＬを規定している。ＧＡＡユーザ同士の共存のための追加要件は、共存が、ＳＡＳの中央当局によって、または無線環境の知識から生じるＣＢＳＤによるローカルアクションによって、設計されるべきかどうかに関する十分な議論を伴って、開発されている。
図２４は、ＰＡＬスペクトル管理の一例証である。ＰＡＬユーザは、１つまたは複数のＣＢＳＤの実際のデプロイメントの周りに輪郭が描かれたカバレッジエリア内でのみ保護される。これらのカバレッジエリアは、ＰＡＬ保護エリア（ＰＰＡ）として知られ、送信局から－９６ｄＢｍの信号レベルに境界がある。ＰＡＬ保護エリア（ＰＰＡ）は、ＰＡＬまたはＧＡＡの他の関連しない使用からの干渉保護の資格を得る多角形領域を登録するために融合され得る重複カバレッジエリアを有するＣＢＳＤのデプロイメントクラスタを表す。図は、いくつかのライセンス地域を示し、その各々は、国に対応する。複数のライセンス地域にまたがる、すなわち、２つ以上の地域でライセンスを有するＰＡＬユーザは、自身のライセンスを組み合わせて共通チャネル割当てを作成することができる。
ＧＡＡユーザは、ＰＰＡ内の実際のＰＡＬデプロイメントが、ＰＰＡ内の－８０ｄＢｍを超える集合干渉から保護される限り、ＰＡＬスペクトルを使用し得る。これは、図ではＰＰＡ Ｃについて例証され、ここでは、２つのＧＡＡ ＣＢＳＤは、それらの伝送からの集合干渉がＰＰＡ境界の大半にわたって－８０ｄＢｍを超えない限り、ＰＡＬユーザと同じチャネルに対して動作することが許可される。重複する、または十分に近接している、異なるオペレータからのＰＰＡは、明らかに、排他的なスペクトル割当てを使用する。故に、ＧＡＡユーザは、帯域が高次ティアによって邪魔されない場合、１５０ＭＨｚのスペクトルのすべてへのアクセスが保証される。
ＧＡＡユーザは、相互干渉または高次ティアからの干渉から保護されないが、ＷＩｎｎＦｏｒｕｍ、およびＣＢＲＳアライアンスは、ＧＡＡユーザのためにより高品質の体験を作り出す方法を明示しようとする試みに従事してきた。ＣＢＲＳアライアンス手順は、ＳＡＳによってＣＢＲＳアライアンス共存グループに割り当てられたスペクトルを再割当てし、環境モデリングに基づいてローカル干渉グラフを作成し、ＣＢＳＤのネットワークを知らせる共存マネージャ（ＣｘＭ）からのスペクトル割当てを最適化する。加えて、ＣｘＭは、ＴＤＤ信号のためのアップリンク・ダウンリンク調整を管理する。ＬＴＥ－ＴＤＤネットワークはすべて、セル位相同期されることが予期され、ＣＢＲＳアライアンス共存仕様は、ＳＡＳまたはＣｘＭから独立して、これがどのように達成されることになるかを詳述する。ＷＩｎｎＦｏｒｕｍおよびＣＢＲＳアライアンスは、ＣＢＳＤあたり少なくとも１０ＭＨｚのスペクトルを保証することを試みる。これは、密集地域におけるｅＭＢＢサービスへの配慮がない可能性が高い。
ＰＡＬおよびＧＡＡスペクトルの両方が、ＵＲＬＬＣ要件に対処することができるが、ＵＲＬＬＣ品質は、すべてのＧＡＡ状況では保証することはできない。したがって、オペレータは、カバーされている施設が他の干渉物から物理的に隔離されない限り、キャパシティまたはレイテンシ性能が低下しないことを顧客に約束するＳＬＡに入ることができない。
ＣＢＲＳは、いくつかの欠点を有する。
・ライセンシング制度の３ティア特性、および特にＧＡＡを許可する規則は、帯域の有用性に大きな不確実性を作り出す。この不確実性のうちの一部は、ＧＡＡスペクトルが未認可スペクトルのようであるか、またはホワイトスペースと類似しているかについて、そうではないことの理解の欠如から生じる。実際、ＧＡＡ使用周辺のＦＣＣ規則の厳しい解釈は、ホワイトスペース類似性を誤って確信するということをもたらす。
・ＷＩＮＮＦ仕様は、それらが干渉保護を確保する様式でＧＡＡスペクトルのみを使用し得るという印象を一部のオペレータの間に作り出した。そのような印象は、おそらく、帯域幅が品質のためにトレードオフされる程度までユーザ間のスペクトルの分割を必要とする。これは、ｅＭＢＢ使用には適していない。
・ＷＩＮＮＦおよびＣＢＲＳアライアンス共存仕様は、屋外デプロイメントを過少評価する傾向がある。高電力基地局は、低電力基地局よりも大いに、既存事業者保護に向けたものである。屋内デプロイメントは、スペクトルを割り当てるときに好まれ得、屋内ノードの大きいネットワークは、ＳＡＳが公平性基準を導入しない限り、それらのスペクトルの公正な分配よりも多くを獲得することができる。本発明者らは、ビジネス保証に基づいた実際的な手法が存在することを期待する。
・ＣＢＲＳの興味深い使用事例は、カバレッジおよびオフローディングのための都市スモールセルおよびマイクロにある。これの理由は、主に、大きいライセンスエリアであり、オペレータは、収益性の高い市場においてライセンスに入札する可能性が高い。ＣＢＲＳの産業自動化使用の場合、オペレータは、それらのスペクトルを分割するか、またはリースするかのいずれかの意図を持ってライセンスを獲得しなければならない。
・ＣＢＲＳは、５Ｇのための第一に関心のある帯域において規定されている。スペクトルが提供されている規定、特にＰＡＬは、その帯域をｅＭＢＢサービスにとっては疑問の余地があるものにし、動作のＵＲＬＬＣモードを含む、産業目的のための混合した有用性を有する。
その一方、ＣＢＲＳに関して良い点もある。
・ＣＢＲＳによって使用される、使わなければ駄目になるという手法は、スペクトル有用性を改善することにおける考え抜かれた実践である。規則は、オペレータに、自らのライセンスを実際のデプロイメントと共に使用する動機付けをし、オペレータは、自らのスペクトルから収益を実現するために、独自の無線をデプロイメントすること、またはＰＰＡをリースすることのいずれかの動機を有する。
・ＣＢＲＳにおける大半のユーザが屋内スモールセルユーザである場合、帯域の成功は保証されることになる。多数の産業使用事例に資格がある。
・ＦＣＣは、スペクトルの産業および企業使用に有利に働くようにオークション手順を歪めることはできない。さらには、産業ユーザは、ライセンス市場において競争することにはそれほど関心がない。実際、エリクソンのローカルライセンス概念は、おそらくは少額の登録料で、規則によって不動産所有者へ割り当てられているライセンスに依存する。ライセンスの分割を許可することによって、ＦＣＣは、産業ユーザに、リーシング、購入、またはＧＡＡ規則による運用という選択を提供した。
・ＣＢＲＳは、商用デプロイメントに参加する予定であり、この分野において実証されることになる。帯域内でのＬＴＥ使用のためのものを含む、規格を開発する産業組織の確立は、実際のデプロイメントおよび何らかの形での帯域の成功を確保する。同じことは、２．３ＧＨｚ内のＬＳＡに関しては言うことができない。実際、他の規制当局、例えば、Ｏｆｃｏｍの間で、ＣＢＲＳに関する目立った関心がある。ＣＢＲＳを配備することにおける経験は、ＣＢＲＳをスペクトル共有を実施する許容のやり方として受容することを通信業界に奨励し得る。
共存
一般に、共存問題は、セルラまたはＲＬＡＮ技術を使用した産業ネットワークが、他のサービス、例えば、衛星とスペクトルを共有するときに存在する。産業は、無線ナビゲーション、衛星サービス、または固定サービスによる使用のために世界的に指定されるスペクトルへのアクセスを、地理における、またはそのようなサービス間の経路損失を通じた、十分な隔離があるという条件で、得ることが可能である。例えば、スペクトルの屋内工場使用は、衛星帯域内で容易に発生し得る。製造業者がそのような帯域を無線設備内に含む動機があるように、そのような帯域は、ＲＬＡＮ使用またはＩＭＴに割り当てられた帯域に近いことが望ましい。ＣＢＲＳ帯域は、世界中の大半の市場においてモバイル使用のために既に指定されている帯域と密接な関連性を有するような１つの帯域である。
スペクトルの産業使用の別の側面は、スペクトル有用性の問題である。セルラ技術は、高いスペクトル効率という利点を有するが、規制が、スペクトルの高い再使用の度合いを可能にすることも必要である。多くの場合において、これは、スペクトルが極めて接近したライセンスエリアにおいてどれだけ再使用され得るかを理解することを伴う。
現実における共存が問題ではないケースがある。産業のための使用事例のための屋内スペクトルは、他のもの、例えば、衛星、ＦＳ、ＦＦＳ、レーダ（屋内だけではない）用の使用不能のスペクトル（モバイル割当てを含まない）から恩恵を受けることができる。しかしながら、産業のための屋外スペクトルのための使用事例も検討されなければならない。
屋内産業使用事例は、他のサービス、例えば、衛星、ＦＳ、ＦＳＳ、レーダなどに指定され得る二次使用スペクトルから恩恵を受けることができるというのは真実であるが、産業によって屋外使用のためのローカルスペクトルを指定することも同様に重要である。
共有スペクトル－市場検討
共有スペクトル規制の背後にある哲学は、米国と欧州とでは異なる。ＦＣＣは、スペクトル有用性に高い価値を置く様式でＣＢＲＳを規定しようとしてきたが、ＥＵは、スペクトル品質および安定性の方へ傾いていた。
欧州では、産業ＩｏＴのサポートは、他からの干渉のレベルが特定のレベルに制約され得るため、認可帯域に焦点を合わせる。国内に多くのライセンスおよびリーシング契約が存在することが予期される。
エボルブドＬＳＡシステムは、デプロイメントおよび共存問題を効率的な様式でハンドリングするために、ＥＴＳＩにおいて設計されている。国によっては、同一チャネルの可能性を有する共存シナリオは、ローカル屋内対ローカル屋内、ローカル屋内および重複する領域カバレッジ、ならびにローカル屋内対ローカル屋外であり得る。規制共有条件は、例えば、周波数ドメイン（および再使用パターンの潜在的な必要性）、ガード距離（必要な場合）、壁損失仮定において、また近隣への干渉の予測可能性をセキュアにする境界において許容最大信号強度を設定することによって、これをハンドリングすることを必要とした。これは、希望のネットワーク品質レベルをセキュアにするために既知の予期される干渉レベルによりネットワークのデプロイメントを促進する。
予測不可能な干渉挙動を有する未認可および認可免除帯域は、高いＱｏＳを必要としないサービスのために使用され得、認可ネットワークと一緒に同時に使用され得る。
米国では、スペクトルのリーシングおよび私的使用は、ＣＢＲＳ内で起こる可能性が最も高い。ＰＡＬ規制は、実際のデプロイメントを保護することに向けられている。被許諾者の無線によってカバーされないライセンス規定内のエリアは、確立されたＰＰＡと干渉しないことを条件に、ＧＡＡユーザに利用可能である。しかしながら、被許諾者は、プライベートＰＰＡがライセンスをリースすることを許可することによって、自らのライセンスを自由に収益化することができる。これが、スペクトルの有用性を改善しそうである。
ＧＡＡ使用は、プライベートデプロイメントに開かれており、様々な因子：都市化、人口密度、商業的関心、屋内対屋外デプロイメント、スモールセル対ラージセル（低電力対高電力）の屋外デプロイメントに応じて、体験の混合品質を有する。
ＷＩｎｎＦｏｒｕｍおよびＣＢＲＳアライアンスは、割り当てられたスペクトルの同一チャネル使用からのＧＡＡユーザへの干渉影響を低減することができるＧＡＡのための共存原理を規定することに携わっている。共存のための手順の開発は、議論があり、一般的には、互いと干渉すると見なされる近隣ＣＢＳＤ同士のスペクトル割当てを直交させることを伴う。これは、いくつかの状況下でＣＢＳＤへの個々のスペクトル割当てを低減するという欠点を有する。これは、ｅＭＢＢカバレッジが予期されるケースでは特に、帯域内のＮＲ使用には特に心配である。
未認可スペクトル
無線の産業使用は、セルラまたは無線ローカルエリアネットワーク（ＲＬＡＮ）技術のいずれかに重複し得る。実際、スペクトルのすべての産業使用を、高信頼性クリティカル通信から派生する、またはクリティカル通信に付随すると分類する必要はない。産業自動化環境の特定の特性は、スペクトル可用性への高レベルの重要性、デプロイメントの容易さおよび低い規制、ならびに信頼に値しかつセキュアなネットワーキングを開発する機会である。しかしながら、多くの使用事例、およびおそらくは産業使用のための使用事例の大部分は、ライセンス免除スペクトルも利用し得る。ライセンス免除運用のための技術としてのＭｕｌｔｅｆｉｒｅおよびＬＡＡの開発は、セルラ産業がＲＬＡＮドメインに入るための手段を提供する。
未認可スペクトルの主な欠点は、干渉の存在下で動作する必要性、および分散知能に基づいたスペクトルの共有使用によって引き起こされる低信頼性を含む。これは、典型的には、無線ノードが、衝突回避およびＬｉｓｔｅｎ－Ｂｅｆｏｒｅ－Ｔａｌｋエチケットを使用してチャネルに瞬時にアクセスすることを意味する。これは、ＫＰＩ保証については受け入れない。したがって、未認可スペクトルは、通常、ミッションクリティカルなアプリケーションには適していない。
産業アプリケーションにとって関心のある未認可スペクトル帯域は、幅広いスペクトル帯域に及ぶ。米国内のＦＣＣは、未認可スペクトルの可用性を拡大することにおいて、近年、最も積極的であった。
表７は、様々な国における未認可帯域を列挙し、下線付きのテキストは、検討中の帯域を指す。表内の帯域は、ブロードバンド使用のために列挙されるものであり、ここでは、短距離デバイス通信帯域であると指定されるいくつかの帯域を含まない。未認可帯域は、一般的には、干渉の可能性に起因して、ＵＲＬＬＣには適さない。
Figure 0007241899000007
欧州および米国内でのスペクトルリーシングは、規制問題ではないが、オペレータにとっての関心およびビジネスは不明である。アジアおよびアフリカでは、スペクトルリーシング議論は始まったばかりである。
産業のための使用事例のための屋内スペクトルは、他のもの、例えば、衛星、ＦＳ、ＦＦＳ、レーダ（屋内だけではない）用の使用不能のスペクトル（モバイル割当てを含まない）から恩恵を受けることができる。しかしながら、産業のための屋外スペクトルのための使用事例も検討されなければならない。
屋内産業使用事例は、他のサービス、例えば、衛星、ＦＳ、ＦＳＳ、レーダなどに指定され得る二次使用スペクトルから恩恵を受けることができるというのは真実であるが、産業によって屋外使用のためのローカルスペクトルを指定することも同様に重要である。
ｅＬＳＡは、スペクトルリーシングおよびローカルライセンシングのための帯域および技術にアグノスティックである。ＣＢＲＳは、米国内のスペクトルの産業使用のための最良の機会になりそうである。ＣＢＲＳは、ＩＭＴによって世界的にアクセス可能であるスペクトル範囲内で指定されており、規模の経済を可能にし、またライセンスのリーシングならびに分割を可能にする。分割を許可することは、ＣＢＲＳがローカルライセンシングを可能にすることは意味しない。
ＩＭＴおよびＭＢＢスペクトルの世界的な調和は、決して適切に実現されることのなかった望みであった。長年にわたるモバイルサービスのためのスペクトルに対する多様な規制措置の結果は、産業使用事例のために調和を達成することを困難にする。しかながら、電気通信産業においては、スペクトル範囲３４００～４２００ＭＨｚおよび２４．２５～２９．５ＧＨｚの部分を産業使用のために割り当てることに対する関心がある。
３４００～４２００ＭＨｚは、５Ｇの構築が開始する中国および米国以外では、第１の周波数範囲となりそうである。この範囲内のローカルライセンシングのための限られた規制サポートは、非ＭＮＯ依存スペクトル使用に遅延を生じさせる。例えば、スウェーデンでは、ローカルライセンシングは、５Ｇによる使用のためには早くても２０２３年以降に利用可能になり得、大半の他の欧州諸国では、規制措置はまだ検討されていない。したがって、リーシングは、そのタイムフレームにおいては、ＭＮＯ提供のサービスを除き、スペクトルへのアクセスのための唯一の選択肢になりそうである。ｍｍＷスペクトルは、より時を得た様式でローカルライセンシングの可用性を可能にするために関心の対象であり得るが、それは、ある程度、ＷＲＣ－１９におけるモバイル帯域の割当てに依存する。
セキュリティ
多くの場合、システムのセキュリティは、最も弱い環の強度と同じにすぎないと言われる。しかしながら、侵入している（または無視している）システムの部分に応じて、それは非常に異なる結果を有し得る。２つ以上のエンティティに関与するシステムについて語るとき、使用されるセキュアな識別情報、ならびにそれらのハンドリングおよび保護は、他のセキュリティ機能性の大部分が依拠するブロックを構築している。識別情報は、エンティティを認証するため、アクセスを付与し、アクションの権限を与えるため、およびエンティティ間のセキュアなセッションを確立するために使用される。これは、デバイスがセキュアな識別情報を有すること、ならびにデバイスの識別情報および資格証明書を保護および隔離するハードウェア（ＨＷ）およびソフトウェア（ＳＷ）ベースの機構を提供することを必要とすることを意味する。保護される必要がある識別情報だけでなく、例えば、どのＳＷがデバイス上で実行されているかの適切な制御を通じて、デバイス自体も守られなければならない。すべての前述したことは、デバイス内にＨＷ信頼の基点（ＲｏＴ：Ｒｏｏｔ ｏｆ Ｔｒｕｓｔ）、基本的には、セキュリティが基づくトラストアンカーを有することによって、可能にされる。
識別情報
デバイスの識別情報は、通信パーティに対してデバイスを識別するために使用される。識別情報は、典型的には、識別子、およびデバイスの認証のために使用される鍵、鍵ペア、またはパスワードなどの認証情報からなる。認証された識別情報は、通信パーティ（ネットワーク、サービス、またはピアデバイスなど）が、ネットワーク／リソースアクセス制御、サービス使用、課金、サービス品質設定などのために根拠の確かなセキュリティポリシー決定を行うことを可能にする。
共有秘密に基づいた識別情報は、すべての通信エンドポイント、およびそれらだけが、秘密の値を知っているという事実に依拠する。共有秘密のランダム性は、１つの鍵特性である。それは、典型的には、共有秘密ベースの識別情報の最も基本的な形態であるユーザ名－パスワード対にはかなり弱い。ランダム性に加えて、秘密の長さ、ならびにデバイスおよびサーバ側の両方で秘密が安全にハンドリングされることが重要である。
非対称鍵では、エンティティの識別子は、非対称鍵対の公開鍵であり、対応する秘密鍵が、認証証明書として機能する。秘密鍵を使用して生成された署名は、対応する公開鍵へのアクセスを有する者によって検証され得る。これは、おそらく、対称（共有秘密）鍵と比較した非対称の主な強みである。
非対称鍵ベースの識別情報に付加価値を与えるため、識別情報を認証局（ＣＡ）によって認定させることが可能である。ＣＡは、鍵対を所有するエンティティの識別情報を検証し、所有者と公開鍵とのつながりを認定する証明書を発行する。証明書の欠点は、制約された環境において問題点になり得る証明書のサイズ（または証明書チェーン）、ならびに証明書を獲得および維持（更新）する追加費用を含む。費用を低減するため、企業もまた、独自のＣＡを設け得る。
生公開鍵（ＲＰＫ）機構は、事前共有された鍵の単純性と非対称暗号ソリューションの恩恵との間の妥協案を示す。ＲＰＫは、特定の形式で公開鍵のみを含む、典型的な証明書よりも著しく小さい最小主義の証明書である。ＲＰＫは、自己署名証明書のようであり、提供された識別情報を裏付ける信頼されたエンティティは存在せず、すなわち、この識別情報を受信するピアは、それが、自らが通信することを望むエンティティの識別情報であるということを信用するために帯域外機構を使用することを必要とする。
すべての公開鍵インフラストラクチャ（ＰＫＩ）について、不正アクセスされた鍵を失効させるやり方を有することが推奨される。認証局（ＣＡ）からフェッチされ得る、またはオンライン認証状況プロトコル（ＯＣＳＰ）を使用してオンラインで認証状況をチェックする証明書失効リスト（ＣＲＬ）は、共通のやり方である。
３ＧＰＰセルラシステムは、共有秘密ベースの識別情報が使用される最も典型的な一例である。３ＧＰＰ識別情報は、ＩＭＳＩ、１５デジット識別子、およびその関連認証情報、１２８ビット共有秘密からなる。この情報は、３ＧＰＰコアネットワーク内の加入者データベース（例えば、ＨＬＲまたはＨＳＳ）、およびユーザ機器（ＵＥ）に設置されたＵＩＣＣまたはＳＩＭカードに格納される。ＵＩＣＣは、セキュアストレージおよび３ＧＰＰ認証情報のためのＴＥＥの両方として機能する。ＩｏＴデバイスでは、永続的に統合された埋込み型ＵＩＣＣ（ｅＵＩＣＣ）が代わりに使用され得る。ｅＵＩＣＣは、より小さい設置面積を有し、登録データの遠隔更新を可能にする。
５Ｇの場合、３ＧＰＰはまた、従来のＳＩＭ認証情報に対する代替案、すなわち、いわゆる「代替認証情報」を検討している。ＴＲ ３３．８９９は、証明書を含む、異なる識別情報ソリューションに目を向ける。仕様では、証明書のためのサポートは、例えば、ＥＡＰ－ＴＬＳがＡＫＡに対する代替案として規定される３３．５０１において説明される。ＥＡＰ－ＴＬＳは、証明書が認証のために使用されていることを示唆する。ネットワークを識別するため、証明書の使用は、ＵＥのホームネットワークの公開鍵で暗号化されたＵＥの私設識別子（ＳＵＰＩ）である秘匿化識別子（ＳＵＣＩ）の定義を通じて部分的に利用可能であり、すなわち、ネットワークは、公開鍵が加入者プロファイルの一部である非対称鍵対を既に有する。ＳＵＰＩは、３ＧＰＰ ＴＳ ２３．５０１において規定され、そこでは、ネットワークアドレス識別子（ＮＡＩ）は、証明書の使用を同様にサポートする、識別子の１つの潜在的な形式として与えられる。
エンドツーエンド（Ｅ２Ｅ）セキュリティ
ほとんどの場合、デバイスの通信を保護することが重要である。何らかの未認証の第三者への情報漏洩、および第三者に経路上でデータを修正させることの両方に対する保護である。これは、機密性（暗号化）および完全性（データの署名）保護を適用することによって達成され得る。データのための的確なセキュリティ必要性は、かなり使用事例依存であり、データ、その使用、感受性、値、およびデータの悪用と関連付けられたリスクに関連する。しかしながら、大まかには、完全性保護は常に適用されるべきであるが、機密性保護の必要性は、個別に評価されるべきである。一般に、単一の鍵が、１つの目的（暗号化、認証など）のためだけに使用されるべきである。
データを保護するため、ＴＬＳ、ＩＰｓｅｃ、およびＳＳＨなどの「正規の」インターネットセキュリティソリューションを含め、利用可能な多くの標準化されたプロトコルが存在する。ＩｏＴ最適化されたソリューションは、ＩｏＴのためのＴＬＳ変異形としてのＤＴＬＳ、およびＩｏＴフレンドリなＩＰｓｅｃをプロファイルするための進行中の作業を含む。また、ＩＥＴＦにおいて規定されるＯＳＣＯＲＥなどのアプリケーションレイヤセキュリティソリューションが利用可能であり、制約付きのデバイスに特に有用である。ＴＬＳと比較した利益は、例えば、活気のないデバイスと使用される蓄積転送タイプの通信のため、トランスポート層プロキシからでさえエンドツーエンドセキュリティが提供され得ることである。プロトコルオーバヘッドも最適化される。
３ＧＰＰはまた、３ＧＰＰネットワークの外側でさえ、サービスへのトラフィックエンドツーエンドを保護するためのツールを提供する。汎用ブートストラッピングアーキテクチャ（ＧＢＡ：Ｇｅｎｅｒｉｃ Ｂｏｏｔｓｔｒａｐｐｉｎｇ Ａｒｃｈｉｔｅｃｔｕｒｅ）、３ＧＰＰ ＴＳ ３３．２２０は、ＧＢＡ用語ではネットワークアプリケーションファンクション（ＮＡＦ）と呼ばれる、ＵＥ／ネットワークサービスへの加入を認証するためのＳＩＭ認証情報を使用する。ＧＢＡは、サービス／ＮＡＦとオペレータとの間に信頼関係があることを必要とする。その信頼を使用して、ＮＡＦは、ＵＥのＳＩＭ認証情報に基づく、ネットワークからのセッション鍵を要求することができる。それらのセッション認証情報は、ＵＥとサービスとの間の認証およびセキュアなセッション確立のために使用され得る。
ハードウェア信頼の基点
ハードウェア信頼の基点（ＨＷ ＲｏＴ）の概念は、以下の側面を含む。
・セキュアストレージ
・セキュア／計測ブート
・ＨＷ施行による高信頼実行環境（ＴＥＥ：Ｔｒｕｓｔｅｄ Ｅｘｅｃｕｔｉｏｎ Ｅｎｖｉｒｏｎｍｅｎｔ）
・ＨＷ保護された暗号および鍵管理（暗号加速、ＨＷベースの乱数発生器、安全に鍵を生成／格納／アクセスすること）
ＨＷセキュリティはまた、製造および開発中に使用されるインターフェースおよび機構の保護、セキュア鍵プロビジョニングの使用、鍵生成、デバイスのセキュアな設定、コード署名など、デバイスが製造される環境にまで拡大される。
デバイスが意図したとおりに挙動することを保証するための基本は、認証されたファームウェア／ソフトウェアのみがデバイス上で実行していることを確実にすることができることである。これは、ハードウェア信頼の基点に由来するセキュアブート機構を必要とする。セキュアブート機構は、デバイスブートアップ中、すべてのロードされたソフトウェアが実行を認証されていることを検証する。ＨＷ ＲｏＴは、本質的に信頼されるエンティティであり、そのデータ、コード、および実行は、その信頼境界の外側から変更することはできないことを意味する。ＨＷ ＲｏＴは、どのソフトウェアがデバイス上で実行しているにしろ、（その設計に従って）期待通りに動作しなければならない機能からなる。
デバイスは、（オフチップ）不揮発性メモリに格納される間、暗号鍵などのデバイス極秘データを保護するためにセキュアストレージ機構も有さなければならない。そのような機構はまた、ＨＷ ＲｏＴ、例えば、オンチップ不揮発性メモリまたはＯＴＰメモリに格納されるチップ個別鍵に依拠する。
マルウェア感染から回復すること、ならびに極秘データの損失およびデバイスの挙動の変更のリスクを最小限にすることができるように、ファームウェアおよびソフトウェアのセキュリティ関連部分は、他のソフトウェアとは分離される（および孤立して実行される）べきである。これは、ＨＷ隔離機構を使用して作成される高信頼実行環境（ＴＥＥ）を使用して達成される。
デバイスハードニング
デバイスは、典型的には、ＡＳＩＣ生産、デバイス生産中、またはフィールドで発見された所与のデバイスの問題を見つけることを目指したデバッギングおよびＨＷ分析のためのインターフェースおよび機構を含む。Ｊｏｉｎｔ Ｔｅｓｔ Ａｃｔｉｏｎ Ｇｒｏｕｐ（ＪＴＡＧ）、ＩＥＥＥ規格１１４９．１は、デバッギングおよび様々なＨＷ分析のための共通インターフェースである。これらの機構およびインターフェースは、それらがＦＷ／ＳＷおよび／またはデバイスデータを取得または修正するために未認証者によって使用されることができないように保護されなければならない。これは、インターフェースを永続的に無効にすること、認証されたエンティティのみがインターフェースを使用することを許可すること、またはインターフェースによってアクセスされ得るものを制限することによって達成され得る。また、認証されたアクセスのため、鍵などのデバイスの所有者／ユーザに属する極秘データが、デバッギング／故障分析を実施する者によってアクセスされることができないことが保証されなければならない。
ＳＷセキュリティは、デバイスセキュリティの最も重要な構築ブロックの１つである。ＨＷおよびＳＷセキュリティの両方が互いに補完し合う。基盤としてＨＷセキュリティなしにセキュアデバイスを構築することは不可能であるが、同じことがＳＷセキュリティにも当てはまる。
アプリケーションプロセッサを有するＩｏＴ ＧＷは、一般に、ＬｉｎｕｘベースのＯＳを実行するが、ＭＣＵベースのＩｏＴデバイスは、主に、ｍｂｅｄ ＯＳおよびＺｅｐｈｙｒ ＯＳなどの軽量ＯＳを実行する。高い可用性およびセキュリティ要件を満たさなければならないデバイス上で使用されている他の十分にセキュリティ認証されたＯＳも存在する。正しいＯＳを選択することが重要であり、そのＯＳのセキュリティハードニングも同等に重要である。ハードニングエントロピー、ユーザ空間コンポーネント、およびネットワーク機能性もまた、ＯＳセキュリティハードニングプロセスの一部と考えられ得る。デバイスハードニングに関連して検討すべき他の側面としては以下が挙げられる。
・最良のセキュアソフトウェア開発プラクティスに従って開発されているＳＷを使用すること。
・サンドボクシングおよび隔離－ＳＷをサンドボックス環境で実行すること。
・最小特権概念－プロセスは必要な特権のみを得る。
・暗号ハードニング－追跡可能かつレビュー対象のコードを有するセキュア暗号ライブラリを使用すること。
・暗号的にセキュアなＰＲＮＧの使用。
・証明書（適用可能なとき）。
・セキュアなＳＷ更新－適時に適用される署名付き更新。
安全のためのセキュリティ
しかしながら、これらのセキュリティ機構／ツール（おそらく非否認防止を除く）は、目標が安全なシステムを作ることであるか、そうでないかにかかわらず、任意のセキュアシステム内で実施されるべきである。安全要件は、おそらくどちらかというと、必要とされるセキュリティのレベルの指示、および、いかなる誤差も安全要件なしではシステム内よりも大きい結果を有する可能性があるため、セキュリティの設定がダブルチェックされる必要があるという指示である。セキュリティ設定は、システム内で使用される正しいレベルのセキュリティ／アルゴリズム／鍵を選択することにも関する。セキュリティに加えて、安全のための（少なくとも）等しく関連性のある部分は、例えば、システムを構成する通信チャネルおよびサービスの両方に関連した、システムの可用性／信頼性、またはコンポーネントの正しい動作（報告される値が正確である、時間同期など）である。
電波妨害
安全性のように、電波妨害もまた、セキュリティドメインに片足を突っ込んでいるトピックである。電波妨害は、サービス妨害（ＤｏＳ）攻撃の形態である。例えば、電波を通してインターフェースが、負荷分散および転送速度制限を意図する、負荷分散およびリルーティングトラフィック、バックアップ基地局、ならびに追加周波数など、いくつかのＤｏＳ対策は、電波妨害にも当てはまる。
産業用デバイス
産業用デバイスは、小型の単純な一目的のセンサから、ロボットセルおよび製紙工場などの大型の複雑なデバイスセットにまで及ぶ。故に、本発明者らがここで取り組む１つの非常に関連性のある質問は、デバイスとは何かということである。ＩｏＴデバイスは、多くの場合、検知デバイスおよび作動デバイスという２つの主なやり方で分類される。検知デバイスは、温度、光レベル、湿度、スイッチなどの特定の側面を測定するある種のセンサを装備する。作動デバイスは、コマンドを受信し、それに応じて状態、例えば、オンもしくはオフであり得る電球、またはエアコンファン速度、を変化させるようなものである。より複雑なデバイスは、センサおよびアクチュエータを組み合わせたセットを有するが、依然として１つのみの通信インターフェースを有する。さらにより複雑な機械は、いくつかのセンサおよびアクチュエータで構成された、いくつかのより小さいデバイスからなり得る。典型的には、小型デバイスの場合でさえ、マイクロコントローラまたは小型コンピュータが、通信スタックならびに処理能力、メモリなどをホストするために適所にある。本質的に、非常に複雑なデバイスは、実際、互いと相互作用する必要がある場合とそうでない場合とがあるか、また同じ通信モジュールを通じて通信する場合とそうでない場合とがあるいくつかの部分からなる、それ自体小さいネットワークである。
通信自体に課せられる要件の範囲は、問題になっているデバイスが目指すタスクの目的および重要性に応じて様々である。これらの要件は、スループット、レイテンシ、信頼性、バッテリ寿命、および拡張されたカバレッジを含み得る。例えば、温度変化を報告する単純なセンサは、緩和した通信要件を有することが分かり得るが、クラウドから無線でロボットを制御することは、ＵＲＬＬＣサービスを必要とする。ネットワークは、同じデプロイメント内のデバイスおよびサービスの混合をサポートすることができる必要がある。問題となっているデバイスが、実際、同じインターフェースを通じて通信するセンサおよびアクチュエータの異なるセットを有する複雑なモノである場合、ネットワークは、同じデバイスからの、サービスの混合、すなわち、異なるタイプのトラフィックをサポートすることも必要であり得る。これは、例えば、監視目的（モバイルブロードバンドトラフィックストリーム）および操作アーム（ＵＲＬＬＣトラフィック）のためのビデオカメラを有するロボット、または遠隔制御機能性を有する港湾ストラドルクレーンであり得る。
バーティカル産業市場に入るため、上に説明される異なる使用事例に対処し、デバイスに関するいくつかの極めて重大な調査質問に回答することが必要である。どのようにしてデバイスを異なるＵＲＬＬＣ要件と組み合わせるか、どのようにしてデバイス内の異なるＵＲＬＬＣストリームを組み合わせるか、およびどのようにして非ＵＲＬＬＣストリームをデバイス内のＵＲＬＬＣストリームと組み合わせるか。どのようにしてデバイス内のＱｏＳメトリクスを監視し、適時この情報をＢＳまたはネットワークコントローラに送信するか？どのようにしてデバイス（ＵＥ、キャリアなど）内の冗長性を確実にするか？
最後に、デバイスは、それが高い処理能力を有する場合は特に、ネットワークの隔離部分ではない。むしろ、デバイスは、システムの一部であり、システム機能、例えば、エッジクラウドの一部、または連合型機械学習アルゴリズムのアプリケーション、計算およびプライバシ観点の両方から有益であり得るものをホストし得る。
分散型クラウド
以下の議論は、産業シナリオの要件を満たすように特に設計された分散型クラウドの概念、産業クラウド、を紹介する。さらには、製造地からの大量のデータを収集、格納、および管理することができる情報管理システムについて説明される。格納された情報へのアクセスは、開発者が、関心のある特定のデータをどのように手に入れるかを見出そうとするのではなく、データを用いて何をすべきかに完全に焦点を合わせることを可能にする明確に定義されたＡＰＩによりハンドリングされる。
クラウドにおける従来の（ＩＴ）集中コンピューティングは、ローカルホスティングに勝る多くの利益を提供する。技術的な利点は、リソース（ＣＰＵ、ストレージ、ネットワーク、アプリケーション、サービス）、弾力性（リソース内外のスケーリング）、および計測（実際の使用の監視および支払い）を計算するための遍在するオンデマンドアクセスを含む。サービスプロバイダのリソースは、複数の消費者に同時にサービス提供するためにプールされる。サービスプロバイダによって配備、管理、および保守される遠隔ハードウェアを利用することによって、かなりの作業がローカルＩＴ部門からオフロードされ得る。これらのすべての性質が、個々の消費者にとってより低い全体費用へと変わる。
集中クラウドモデルは、多くの利点を有するが、すべての産業要件を解決するわけではない。検討すべき２つの大きな問題が存在する。まず、大きい距離にわたるシグナリングが、全体レイテンシを増加させる。厳しいタイミング制約を伴う（ハード）リアルタイムプロセスの場合、クラウドへのラウンドトリップ遅延は、性能に有害であり得、あるいは特定の使用事例を実施するのを不可能にさえし得る。クラウドへの通信およびクラウドからの通信が、制御がほとんど可能ではない多くの外部リンクに関与し得る場合、遅延ジッタもまた、大きな問題になり得る。第二に、産業生産に関連した計算タスクは、可用性、ロバスト性、およびセキュリティに対してかなり厳しい要件を課す傾向がある。クラウドネイティブのアプリケーションおよびサービスが、冗長かつフェイルセイフのやり方で設計および設定され得、またそうあるべきであるとしても、通信は、容易に保証されない。例えば、ファイバケーブルは、建設作業に起因して断線する場合があり、ルーティングテーブルは、壊れることがあり、停電が発生する。理由にかかわらず、ネットワーク接続のいかなる中断も、生産にとっては壊滅的になり得る。特に、中央クラウドで実行される閉ループ制御アルゴリズムに依拠するものは何でも、通信損失が最善の注意を払ってハンドリングされるように作製されなければならない。それが制御アルゴリズムのオンサイト複製、グレースフルデグラデーション、または他の何かを意味するかどうかは、個別に決定されなければならない。
クラウドコンピューティングの利益を依然として保持しながら、上に説明される問題を軽減するために、分散手法が提案される。原理は、図２５に描写される。基本的に、中央クラウド（データセンタとしても知られる）は、物理的に異なる場所において、いくつかの他の計算インスタンスに接続される。これらの周辺インスタンスは、処理パワー、メモリ、ストレージ、および通信に利用可能な帯域幅に関してかなり異なる能力を有し得る。典型的には、アプリケーションもまた、それらの異なる部分を別個のハードウェア上で実行するために分散される。製造に関連して使用されると、このシステムは、産業クラウドと呼ばれる。しばしば分散型クラウドに対して同義的に使用される別の観念は、エッジクラウドである。しかしながら、用語「エッジクラウド」は、基地局内に位置するクラウドリソースを特に指すために使用されることもある。明らかに、図２５に示されるように、産業クラウドシナリオは、より一般的であり、基地局以外の他の場所にも及ぶ。
機能的要件（すなわち、指定の挙動および何をすべきか）および非機能的要件（システムの動作に関連する品質属性）が、特定のタスクをどこに配備するべきかを決定する。データをそれが使用される場所の近くに維持することは、時間制約のあるタスクにとっては有利である。他の使用事例においては、帯域幅制限が、データが生成される一時的なストレージを余儀なくさせ得る。結果として、ローカル（オンサイト）計算およびストレージリソースの必要性がある。しかしながら、中央クラウドでより良好にハンドリングされるあまりタイムクリティカルでないタスクも豊富に存在する。例えば、予知保全および異常検出は、多くの場合、ログおよびセンサデータの長くかつ完全な時系列に依存する。この情報をデータセンタに格納することは、帰納的分析、および深層学習アルゴリズムの訓練を単純化する。
リアルタイム製造ソフトウェアプラットフォーム
オンサイトエッジクラウドデプロイメントは、機器の部分がソフトウェアだけのソリューションによって取って代わられる可能性を含め、デプロイメントおよび管理の費用を低減する新規かつ改善されたアプリケーションのための成功要因と考えられる。典型的な一例は、各製造ロボットの隣に設置される、既存のレガシーデプロイメントにおいてはハードウェアボックス、本質的には産業グレードＰＣである、ロボットコントローラである。この機器は、ミリ秒スケールの制御ループを要する、運動制御のようなロボットのリアルタイム制御を担う。そのようなブラウンフィールド技術のクラウド化における第１のステップは、コントローラからオンサイトクラウドへのソフトウェアの移動、故に、余分なハードウェア要素を取り除くことによって設置を単純化することである。
完全にソフトウェア定義された工場に対する次のステップは、機能ごとの信頼性、スケーリング、状態データ外部化、ならびにクラウド内でプログラムを実行する利益である更新およびバージョン制御のような管理の容易さを生かすために、今日のソフトウェアコントローラの機能性をよりきめの細かい機能に分解することである。各々のそのような機能は、各製造プロセスを制御する実際のビジネス論理を構成する全体的なドメイン特有プログラムの特定の部分をカプセル化し、また理想的には、それらは、異なるそのようなプログラムにわたって再使用可能である。５Ｇ製造の文脈において、プログラムは、ウェブスケールＩＴ産業の概念、ツールセット、および体験を再使用する、物体認識、運動制御、またはファンクションアズアサービス（ＦａａＳ：Ｆｕｎｃｔｉｏｎ－ａｓ－ａ－Ｓｅｒｖｉｃｅ）内のリアルタイム分析のような、一般的に使用される機能性を提供する製造ソフトウェアプラットフォーム（ＭＳＰ）内で開発され、またそこで実行することが想定される。ＭＳＰのプロバイダは、互いの上に積層し、増大するレベルの現実の抽象化を提供するコンポーネントにより物理デバイスの高い柔軟性およびプログラム可能性を可能にする。そのような抽象化は、検出／検知／入力、およびコマンド送信／起動／出力するときの両方に使用される。
そのような高水準概念は、例えば、多くの場合いくつかのソースからの情報を組み合わせた、低水準の感覚入力から合成される観察である。例えば、「ユニット＃３２はその目的地に到達した」は、屋内位置特定三角測量、目的地のデータベース、およびおそらくはカメラ検証から計算され得るトリガである。１つ１つの生入力は、位置特定システムまたは画像認識システムなどの入力デバイス特有のコンポーネント内でまず処理される可能性がある。これらのより高水準コンポーネントの結果を使用することは、より精密な調整という結果になるように、ＡＧＶ位置を相関させ得る。最後に、さらに高水準のコンポーネントは、それを標的データベースおよびシステムの全体的目標と相関させ得る。したがって、入力を処理することは、各々が少しだけ抽象化のレベルを上昇させ、さらなる文脈を追加するコンポーネントのスタックによって行われる。
同様に、高水準コマンドは、「この物体をそのロボットに渡せ」、「それを白色にペイントせよ」、または「そこにドリルで２つの穴を開けよ」などの、人間の作業者に与えられるようなものである。次いで、そのようなコマンドを実行するための正確な手順は、タスクスケジューリングから始まって、軌道計画、モータ制御、サーボへの生コマンドに至るまでコンポーネントのスタックによって計算される。
この手法は、最終的に、人間が容易に理解する高水準概念を使用した製造プロセスのプログラミング、クラウド化されたアプリケーションの複雑性分散性を一緒に単純化する、または隠すことを可能にする。この手法はまた、低水準コンポーネントが、おそらくアプリケーションアグノスティックであり、多くの文脈において使用され得る一方で、高水準コンポーネントは、高水準概念と連携してそれらを開発するのがより容易であるため、再使用をサポートし、開発時間を節約する。
実行環境およびＭＳＰプラットフォームの両方は、強力で簡潔な産業制御ビジョンを提供するために、それらが有線および無線両方の接続ソリューションとバンドルされる場合は特に、５Ｇネットワーク内およびそれに接続されるコンポーネントによって提供される値が追加され得る。これが起こるためには、ロボットベンダおよび製造会社のエコシステムが、搭載されており、そのようなコンポーネントを使用しなければならない。早い段階での協力が必要不可欠である。
データ／情報管理
産業プラント内で生成されるすべてのデータに対応するため、情報管理システムが必要とされる。そのようなシステムの重要な特徴は、それが分散型（ロバスト性、および必要とされる場合にデータにアクセスするため）、スケーラブル（１つまたは１００の機械のためにこれを行うことが、同じ複雑性の度合いを有するべきである）、および再使用可能（さらに別の製造現地のデータ管理を既存のインスタンスに追加することは単純でなければならない）、およびセキュア（機密性およびプライバシを賞賛し、データ完全性を確実にし、データオーナシップおよびアクセス制御のための手段を提供する）であることである。このシステムのタスクは、目的のデータを収集、管理、格納、フィルタリング、抽出、および発見することである。明らかに、システムは、有効期間、レイテンシ、ストレージおよび可用性、帯域幅などに対するかなり異なる要件を有する異なるタイプのデータ（例えば、時系列、ストリーミングデータ、目的のイベント、アラーム、ログファイルなど）に応じなければならない。さらには、システムは、極秘データおよび公開データの両方の混合をハンドリングしなければならない。データのストレージ要件は様々であるが、「安全な」ストレージを有する分散型クラウドの概念に基づいたソリューションは、予期される幅広い異なる要件に対処することが必要とされる。安全面は、空中（すなわち、データが転送されている間）およびストレージ内の両方における、プライバシに対する懸念およびアクセス権の実装を含む。
豊富な生成データのセットは、すべてのさらなる処理および分析の基本である。より多くのデータを収集することは、計画、生産内の流れ制御、効率的な物流、予知保全、情報共有、個々の機械の制御および起動、異常検出、アラームへの素早い反応、作業命令の配布、遠隔監視、日常業務、および他にも多くのことに関して新しい使用事例を促進する。多くのデータが収集されるほど、それを管理するタスクはより困難になる。大きい工業用地の場合、読み出され、監視され、制御され得るセンサおよびアクチュエータの総数は、１００００を容易に超え得る。サンプリングレートは、大きく異なるが、時間と共に、収集データの総計量はかなりのものになる。目的のデータを見つけることさえ問題になる傾向がある。
生産は、多くの場合、思うほど静的ではない。明らかに、設定の変更、またはわずかに異なる作業ステージのセットが、形状、材料、サイズ、表面研磨、ドリル穴の配置などに関する製品バリエーションに必要とされる場合がある。さらには、同じツールおよび機械のセットが、異なる製品バッチにおいて全く異なる製品のために使用され得る。新製品が製造される予定であるとき、それは、完全に新しい生産ラインが設定されることさえ必要とし得る。生産のバリエーションは、動作および分析に関してどのデータを見るべきかに対して影響を有する。新しいセンサおよびアクチュエータが利用されるとき、データ管理は、変更した条件に適合することができなければならない。
多くの場合、同じデータが、複数の目的（例えば、生産の監視および製品が完成した後の品質保証の両方のため）に有用であり得、また、上で論じられるように、生産が変化するときには、全く新しいパラメータが関心の対象となる。センサデータが収集されるときは、将来の使用のため、それに追加情報（別名メタデータ）で注釈を付けることが有利である。これの単純な一例は、最初から常に存在するものではないタイムスタンプをすべてのセンサ読出しに追加することである。他の有用なメタデータは、場所、製品ＩＤ、使用したツールに関する詳細、および／またはバッチ番号に関する情報である。一般に、この種のメタデータは、検索を単純化し、トレーサビリティを改善する。具体的には、それは、分析および機械学習目的に必要とされる特定の情報をフィルタリングおよび抽出するために使用され得る。
収集されるいくつかのセンサデータは、工場で実行されている産業プロセス以外の他のことに使用され得る。例えば、それは、生産に使用されるが他の誰かに所有される特定の機器の状態またはステータスを監視することに関連する読出しであり得る。所有者は、保守およびサービスを計画するために、および次世代の機器を改善するために統計値を収集するためにも、機器を監視することに関心がある。このデータは機密であり得、工場所有者には見えるべきではない。その一方で、工場所有者は、生産ラインから出る製品の品質または量に関連するデータを明らかにすることを望まないことがある。結果的に、データのオーナーシップを規定する、およびデータのアクセスを認証パーティだけに制限するための手段を提供する必要性がある。情報管理システムは、すべてのデータを、その目的またはそれが誰に属するかに関わりなく、依然として同じやり方でハンドリングしながら、これに応じなければならない。
図２６は、典型的な製造シナリオを例証する。左側には工場が描写され、一方、右側はデータセンタ（すなわち、中央クラウド）を表す。接続されたツール、機械、およびセンサは、処理および格納のために注釈および転送されるデータを生成する。「グローバル」デバイスレジストリは、すべての利用可能な生産者（センサ）および消費者（アクチュエータ）を追跡する。アプリケーションは、デバイスレジストリに尋ねることによって必要なデータをどこで見つけることができるかに関する情報を獲得する。ストレージは、出所のとおりに（それに関しては詳細は後で）、オンサイトおよびデータセンサ内の両方において対処されている。この設計は、オンサイト（低レイテンシ）ベースおよびオフサイトベース両方の制御アプリケーションを可能にする。明らかに、この機構は、複数の生産現地が含まれることになる場合は複製され得る。
この機構は、データが工場内および中央クラウド内の両方でハンドリングされる分散型クラウドの一例である。利用可能なリソースキャパシティは明らかな例外として、ローカル機構およびその機能性は、データセンサの対応する機構および機能性に非常に類似したものにされ得る。それを行うことは、両方の場所で実行するアプリケーションのデプロイメント、動作、およびライフサイクル管理を大いに単純化することになる。
データを注釈、格納、および処理することに加えて、情報管理システムは、データ出所もハンドリングしなければならない。手短に言うと、これは、データ起源、データが時間と共にどこを移動するか、誰が何の目的でそれを使用するか、およびいつそれが使用されるか、を追跡するプロセスである。これらのパラメータの記録をとることは、監査、法医学的分析、誤ったデータ系列の使用からのトレースバックのオフおよび回復を促進する。出所は、情報管理システムの管理者に、データ依存性の詳細図および導出された結果を獲得するやり方を与える。例えば、故障または未較正センサは、それが生産において即時の混乱を引き起こさなければ、しばらくの間気付かれないままである場合がある。このとき、そのセンサデータが機械学習アルゴリズムにおいて訓練目的で使用される場合、結果として生じるモデルは、その使用に悪影響を及ぼす不備があるものになり得る。適切な出所が整っていれば、不備の可能性のあるモデルがいつおよびどこで使用されたかを見つけ出し、これによって引き起こされる問題を軽減するための適切な措置をとることが可能である。
開発者のために単純化するために、情報管理プラットフォームが、すべてのデータを見つけ出してアクセスするために、十分に定義されたＡＰＩを提供することが重要である。これは、リアルタイムで収集される「生」センサデータ、および古いデータの過去記録の両方について言えることである。特に、分散型クラウドモデルは、目的のデータが地理的に異なる場所に格納され得、その配置は時間と共に変化し得ることを示唆するということに留意されたい。この事実は、異なるニーズ（例えば、レイテンシの変動に対する耐性）、全体的なロバスト性（例えば、データセンサへのリンク故障をハンドリングすること）、および長期的可用性に対する要件から得られる。データを使用するアプリケーションは、自身の格納場所を追跡する必要があるべきではなく、基礎となる情報管理プラットフォームがこれを行って、開発者がより重要なことに焦点を合わせることを可能にする。
情報管理システムのプロトタイプは、現在、イェーテボリのＳＫＦのころ軸受工場のうちの１つに配備されている。この取組みは、２０１８年６月～２０１９年９月に実行している５ＧＥＭ ＩＩリサーチプロジェクトの一部である。ソフトウェアは、オープンソースプロジェクト（例えば、工場からデータセンサへのデータフローをハンドリングするためのＣａｌｖｉｎ、ならびにパブリッシュ・サブスクライブ・メッセージングハンドリングのためのＡｐａｃｈｅ ＰｕｌｓａｒおよびＶｅｒｎｅＭＱ）、ならびに内部独占コードの両方に基づく。情報管理プラットフォームは、Ｋｕｂｅｒｎｅｔｅｓがコンテナのためであるデータのためのものである。明らかに、まだすべての機能性が整っているわけではないが、本発明者らは、頻繁に反復および更新する。取組みは、現代の継続的インテグレーション／継続的デプロイメント開発方法論を使用して行われる。これは、コードに対する変更が自動的に試験されることを意味し、分散型システムへのデプロイメントは、単一のコマンドによりなされ得る。全体的な設計は、大半のシステム更新が実行中のアプリケーションを中断することなく行われ得るように慎重になされる。故に、生産は、ソフトウェア更新をプラットフォームに配備するために停止される必要がない。この性質は、更新が生産現地のためのスケジュールされた保守時間枠外でもその後行われ得るため、工場敷地において特に重要である。通常、生産停止は、製造業者にとって非常に費用のかかるものであり、これは、計画した保守時間枠が、わずかしかなく、できる限り時間内に分けられることを意味する。
分散型クラウドは、弾力性、オンデマンド計算、リソースプーリング、測定されたサービス、およびネットワークアクセスなどの中央クラウドのすべての性質を保持する。加えて、処理を結果が使用される場所の近くに置く能力は、よりロバストなソリューション、分散化、および低レイテンシ使用事例の実装を促進する。
適切な情報管理システムが整っていれば、開発者は、新しいアプリケーションを構築し、製造現地への物理的アクセスなしに、およびデータがどのように収集されるか、またはそれがどこに格納されるかの詳細な知識なしに、工場で生成されたデータにアクセスすることができる。異なるタイプのデータは、オンサイトおよびデータセンタ内の両方でハンドリングされ、格納される。十分に定義されたＡＰＩは、サービスを表出し、利用可能な任意のパラメータおよびメタデータに基づいて効率的な検索およびフィルタリングを可能にする。データへのアクセス権は、ユーザおよび／または該ユーザの役割に基づいて規定され得る。高度なロギング特徴は、収集したデータの使用の監査およびトレーサビリティを促進する。
運用管理
運用管理（Ｏ＆Ｍ）という用語は、工場デプロイメント内のネットワークおよびデバイスを運用および管理するという行為を指す。運用サポートシステム（ＯＳＳ）は、このタスクを達成するために使用されるソフトウェアを指す。
工場フロアは、商品を生産および製造するために使用される機械類からなる。機械は、多くの場合、人間の介入ありまたはなしで、および自動化のレベルに応じて、商品が流れる組立ラインへと組織される。生産に使用される異なる器具および機械は、接続される場合とそうでない場合とがある。接続される場合、典型的には、ある種のデータは、器具および機械類自体の予知保全、または製造されている商品の品質保証プロセスを助けることのいずれかのために、機械類から集められる。これは、工場フロアの運用技術（ＯＴ）部分と呼ばれる。
工場を含め、大半の企業は、有線および無線通信（典型的には、イーサネットおよびＷｉ－Ｆｉ）、コンピュータ、携帯電話などを含む、従業員のために適所に通信インフラストラクチャも有する。この機器は、イントラネットおよびインターネット、Ｅメール、ならびに他の典型的なオフィスアプリケーションにアクセスするために使用される。これは、工場フロアの情報技術（ＩＴ）部分と呼ばれる。
ＯＴおよびＩＴの融合は、新興動向と認識されている。実際には、これは、単一のインターフェースが、両方のデバイス、接続性、これらのデバイスによって生成されるデータ、および工場内のネットワークインフラストラクチャを運用および管理することを意味する。工場内のＯＴ／ＩＴ融合に関連した研究課題としては以下が挙げられる。
・どんな種類のデバイス管理プロトコルが、ＯＴのために使用され、それらはＩＴシステムにインターフェース接続することができるか？
・どんな種類のプラットフォームが、すべての異なる側面をハンドリングするために必要とされるか？
デジタルツイン概念は、産業環境において非常に人気がある。ここでは、この考え方は、物的資産または工場全体のデジタルデータモデルに集められたデータをもたらし、次いでデータに対して分析を適用して、資産またはプロセスの過去、現在、および未来の挙動を予測、説明、および指示することである。デジタルツイン概念周辺の研究課題としては以下が挙げられる。
・物的資産をどのようにモデル化するか？
・何のデータが捕捉に関連し、期間はどれくらいか？
・どの種類のレイテンシがリアルタイム相互作用に必要とされ、それをどのように提供するか？
・どの種類のモデルが、考えられ得る未来を予測するために必要とされるか？
・どこで計算し、どの種類の計算能力が意義のある予測を実施するために必要とされるか？
このすべては、増大した信頼性および可用性をもたらし、リスクを低減し、保守費用を下げ、生産を改善することができる使用が容易なシステムにより達成されるべきである。オペレータがそのＯ＆Ｍのほんの一部分だけをその顧客に表出／委任するソリューションが望ましい場合がある。顧客は、単純なインターフェースを得るべきである。ソリューションは、一般家庭でさえそれを使用することができるように、わずか一握りのデバイスへとスケールダウンすることが可能でなければならない。
最後に、デジタルツインの考え方と併せた拡張現実および仮想現実は、融合ＩＴおよびＯＴ空間における未来のネットワーク管理に大きな影響を有し得る。機器管理は、同じ空間に存在している感覚で遠隔で行われ得る。また、機器使用または補修に関する技術文書および指導は、スマート眼鏡、タブレットなどを通じて、現場の人間に遠隔で提供され得る。
タイムセンシティブネットワーキング
タイムセンシティブネットワーキング（ＴＳＮ）の一般的な考え方および冒頭の概観に続き、ここでは、提示される資料は、ＴＳＮ内の優れた出発点を得る助けとなる。５Ｇ－ＴＳＮインテグレーションの特定の詳細も提供される。
ＴＳＮは、産業アプリケーション（およびその他）の非常に需要の高いドメインに対するサポートを可能にするために、有線ＩＥＥＥ８０２．３イーサネット通信を改善することが想定される。ＴＳＮは、Ｔｉｍｅ－Ｓｅｎｓｉｔｉｖｅ Ｎｅｔｗｏｒｋｓ（またはＮｅｔｗｏｒｋｉｎｇ）の略である。それは、ＴＳＮタスクグループによる進行中のＩＥＥＥ標準化構想である。それらは、ＴＳＮを個々の特徴のセットとして規定する。大半のＴＳＮ特徴は、ＩＥＥＥ８０２．１Ｑ規格に対する拡張である。ＴＳＮネットワークは、イーサネットエンドステーション（時に、エンドポイントとも呼ばれる）、イーサネットケーブルおよびブリッジ（スイッチとも呼ばれる）を備える。イーサネットブリッジは、それがＴＳＮ特徴の特定の（定義されない）セットをサポートする場合、ＴＳＮブリッジになる。
ＴＳＮ規格内の異なる特徴は、一般に、以下を目指す。
・バッファ輻輳に起因するゼロパケット損失（通常のイーサネットブリッジは、実際、バッファが満たされる場合、パケットを破棄する）
・故障（機器、ビット誤差、制御プレーンなど）に起因する極端に低いパケット損失
・エンドツーエンドレイテンシに対する保証された上界
・低パケット遅延変動（ジッタ）
ＴＳＮ内の通信は、ＴＳＮデータストリームとも称され得るＴＳＮストリーム内で発生する。ＴＳＮにおける１つの具体的な特徴は、一例を挙げると、ストリームが、受信機（リスナと呼ばれるエンドステーション）まで送信機（トーカと呼ばれるエンドステーション）とネットワークとの間に配置される場合、予期しない待ち行列なしの低レイテンシ伝送を確実にするというアグリーメントの対象であることである。
以下において、ＴＳＮは、高水準観点から紹介される。その後は、ＴＳＮおよび５Ｇインターワーキングがどのようなものであり、特定のＴＳＮ特徴が５Ｇにおいてどのようにサポートされ得るかの技術的詳細である。
ＴＳＮ標準化は、Ａｕｄｉｏ－Ｖｉｄｅｏ Ｂｒｉｄｇｉｎｇ（ＡＶＢ）と呼ばれる音声および映像通信のためのイーサネットベースの通信規格を規定するために見出された標準化構想から生じた。ＴＳＮは、ＡＶＢに基づき、産業使用のためにそれを好適にするための特徴により強化される。現在に至るまで、ＴＳＮコミュニティは、以下の産業使用事例に焦点を合わせる。
・工場自動化のための産業通信（主な使用事例＃１）
○作業現場ＴＳＮリンク（水平）
○作業現場からクラウドへのＴＳＮリンク（垂直）
○機械内通信
○工場基幹回線のためのＴＳＮ
・車両内通信（主な使用事例＃２）
・発電および配電（スマートグリッド使用事例）
・ビルディング自動化（これまでのところこれに関する実践例はない）
・Ｆｒｏｎｔｈａｕｌｉｎｇ（ＩＥＥＥ Ｐ８０２．１ＣＭに従う）
この文書では、工場自動化のための産業通信における使用が取り上げられるが、詳細な技法および概念のうちのいくつかは、他の使用事例に適用可能であり得る。
図２７は、工場内の階層ネットワークアーキテクチャを例証する。作業現場ＴＳＮリンク（水平）は、生産セル、接続デバイスまたは機械、およびコントローラ内に現れる。生産ライン領域は、運用技術（ＯＴ）ドメインおよび情報技術（ＩＴ）ドメイン間の接続を可能にするが、必要に応じて、作業現場の生産セルを接続するためにも同様に使用される。本発明者らが上で紹介したＴＳＮ区分において、最初のもの（ＯＴ－ＩＴ）は、明白に、作業現場からクラウドまでのＴＳＮリンク（垂直）に基づき、後者はここでも作業現場ＴＳＮリンク（水平）に基づく。機械内通信に使用されるＴＳＮは、これが、おそらくは、例えば印刷機または任意の他の機械器具の内側に単一の機械ベンダによって配備されるＴＳＮネットワークでありさえすれば、水平の作業現場ＴＳＮリンクとは異なり、５Ｇ観点からは、これらの水平リンクが取り上げられる必要はあまりないようである。工場基幹回線のためのＴＳＮは、工場／ビルディング／オフィスネットワーク（薄いオレンジ領域）で使用される。例えば、仮想化されたコントローラからの決定性の通信が所望される場合、ＴＳＮは、作業現場までの必要なエンドツーエンドである。
ＴＳＮ通信は、ベストエフォート型イーサネットパケットネットワークに基づくが、ＴＳＮ特徴を通じて強化される、別の種類のパケットサービスである。アグリーメントは、決定論を達成するために、通信に関与するデバイス間で使用される。アグリーメントは、ＴＳＮストリームの送信機を特定の帯域幅およびネットワークに制限し、その代わりに、必要な帯域幅を留保し、バッファリング機構およびスケジューリングリソースを留保する。リソースは、特定のストリームによって独占的に使用され得る。ＣＢＲ（固定ビットレート）などの他のパケットサービスおよびベストエフォート型のパケットサービスと比較して、特定の観察が行われ得る。
ベストエフォート型パケットサービスは、おそらく最もよく知られているものであり、ここではパケットはできる限り早く転送および配信される。しかしながら、パケットのタイムリーな配信の保証はない。エンドツーエンドレイテンシおよびレイテンシの変動は、むしろ大きく、故に、統計的言語は、全体的な性能（損失、エンド・エンド・レイテンシ、およびジッタ）を表現することが好ましい。図２８の上部は、ベストエフォート型パケットサービスネットワークの典型的な性能を示す。エンドツーエンドレイテンシ内の典型的なテイルは、大半の産業使用事例にとっての問題を引き起こす。
対照的に、固定レイテンシおよびアプリケーション層で見られるようにゼロに近いジッタ（レイテンシ変動）を提供するＣＢＲパケットサービスも存在する。ＣＢＲは、典型的には、時間ドメイン内で多重化することによって提供され、典型的な例がＳＤＨ（同期デジタル階層ネットワーク）またはＯＴＮ（光伝送ネットワーク）である。ＣＢＲの典型的な性能は、図２８の中央部に見られ得る。ＣＢＲの欠点は、ネットワークリソースが共有されるやり方においてかなり柔軟性がないことである。そのため、例えば、レイテンシまたは帯域幅に関して異なるアプリケーションニーズに適合することは難しいが、当然ながら、産業文脈において、要件は多種多様であり、サーバ全部への単一ネットワークが所望される。
ＴＳＮは、同じインフラストラクチャを通じてすべてのタイプのトラフィッククラス（サービス品質（ＱｏＳ）および非ＱｏＳ）をサポートすることを目指す。したがって、ＴＳＮネットワークは、ＣＢＲとベストエフォート型のパケットサービスとの間のどこかに位置し、ここではレイテンシは、典型的には、ＣＢＲネットワークと比較して大きいが、レイテンシ変動およびジッタは、限られており、テイルはない。言い換えると、ＴＳＮは、ネットワークが、図２８の下部に見られるように、特定の合意したエンドツーエンドレイテンシおよびジッタよりも劣っていることがないという保証を提供する。これらの保証は、柔軟に適合され得る。この挙動は、大半の産業アプリケーションによって必要とされる。
ＴＳＮの中核となる特徴は、「ストリーム概念」であり、ここではストリームは、専用リソースおよびＡＰＩを備える。ＴＳＮストリームは、ＴＳＮ機能のあるネットワーク内の１つのエンドステーション（トーカ）から別のエンドステーションまたは複数のエンドステーション（リスナ）へのユニキャストまたはマルチキャストとして見られ得る。各ストリームは、固有のストリームＩＤを有する。ストリームＩＤは、トーカソースＭＡＣアドレスおよび固有ストリーム識別子で作成される。ブリッジは、ストリームＩＤに加えて、優先度コード（ＰＣＰ）フィールド、および内部フレームハンドリングのためにイーサネットヘッダ内の８０２．１Ｑ ＶＬＡＮタグの内側に含まれるＶＬＡＮ ＩＤ（ＶＩＤ）を使用する。その意味において、ＴＳＮストリームは、普通のイーサネット非ＴＳＮフレームよりも多くの特権を与えられる標準８０２．１Ｑイーサネットフレームである。トーカがＴＳＮストリーム内で任意のパケットを送信することを開始する前に、特定のストリームは、ネットワークに登録され、特定のＴＳＮ特徴が設定されなければならない。ＱｏＳが保証されたＴＳＮストリームの次に、ベストエフォート型トラフィックもまた、ピアによってＴＳＮネットワーク内で送信され得るが、当然ながら、ＱｏＳに対する保証はないか、または限られている。ＴＳＮストリームは、ＴＳＮドメイン内で送信される。ＴＳＮドメインは、連続ドメインとして見られ得、ここではすべてのデバイスは、同期しており、ＴＳＮ機能のあるポートを通じて連続的に接続される。ＴＳＮドメインは、一般的に管理されるデバイスの量として規定され、グループ化は、管理的決定である。
ストリーム管理は、ＩＥＥＥ８０２．１Ｑｃｃ、Ｑａｔ、Ｑｃｐ、およびＣＳにおいて規定される。それは、ネットワーク発見、ならびにネットワークにおけるネットワークリソースおよびＴＳＮ特徴の管理を、例えば、ＴＳＮストリームのための必要な保護チャネルの作成として規定する。さらには、ストリーム管理は、ユーザおよびネットワーク管理者に、ネットワーク条件を監視、報告、および設定するための機能を提供する。ＴＳＮにおいては、３つの設定モデル：分散型、集中型、および完全集中型モデルが存在する。後者２つのモデルにおいては、中央ネットワークコントローラ（ＣＮＣ：Ｃｅｎｔｒａｌ Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌｌｅｒ）が、ＴＳＮスイッチを管理するために、ソフトウェア定義されたネットワーキング（ＳＤＮ：Ｓｏｆｔｗａｒｅ Ｄｅｆｉｎｅｄ Ｎｅｔｗｏｒｋｉｎｇ）コントローラに類似して使用される。完全集中型モデルにおいては、中央ユーザコントローラ（ＣＵＣ：Ｃｅｎｔｒａｌ Ｕｓｅｒ Ｃｏｎｔｒｏｌｌｅｒ）が、エンドステーションおよびユーザのための中央インターフェースとして前もって使用される。分散型モデルでは、中央制御が存在しないため、ブリッジおよびエンドステーションは、ＴＳＮ要件について交渉する必要があり、このモデルにおいては、調整のために中央インスタンスを必要とするいくつかのＴＳＮ特徴は、適用不可能である。多くのＴＳＮ特徴はまた、ＣＮＣ／ＣＵＣ、エンドステーション、およびブリッジの間の相互作用のための共通プロトコルおよび言語規格（すなわち、ＹＡＮＧ、Ｎｅｔｃｏｎｆ、Ｒｅｓｔｃｏｎｆ、ＬＬＤＰ、ＳＮＭＰなど）を目指す。
時間同期は、すべてのＴＳＮ対応のネットワークエンティティによって共有される共通時間基準を確立するために使用される。時間同期は、ＩＥＥＥ８０２．１ＡＳ－ｒｅｖにおいて規定されるような時間情報を含むパケットの交換に基づき、ＩＥＥＥ８０２．１ＡＳ－ｒｅｖは、産業文脈において広く使用される高精度時間プロトコル（ＰＴＰ：Ｐｒｅｃｉｓｉｏｎ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）に対するいくつかの修正を規定し、そしてこのプロトコルは、ｇＰＴＰ（一般化されたＰＴＰ）と呼ばれる。ｇＰＴＰは、それが冗長なグランドマスターデプロイメント、ならびに単一ＰＴＰネットワーク内の複数の時間ドメインの確立、およびより広範なＰＴＰに対するいくつかの他の強化さらには制限をサポートするという意味で、ＰＴＰの上級版である。ｇＰＴＰの目標は、同期においてマイクロ秒未満の正確性を達成することである。精密な時間同期は、いくつかのＴＳＮ特徴（例えば、ＩＥＥＥ８０２．１Ｑｂｖ）のために使用され、ならびに、時間の一般的概念に依拠するアプリケーション（分散型運動制御のような）に提供される。
有界の低レイテンシを提供するストリーム制御は、所定のＴＳＮストリームに属するフレームがＴＳＮ対応ブリッジ内でどのようにハンドリングされるかを指定する。それは、フレームを、それらの関連トラフィッククラスに従って、効率的に転送し、適切に待ち行列に入れるための規則を施行する。すべての既存のストリーム制御が、同様の原理に従い、具体的には、特定の特権は、ＴＳＮストリームと関連付けられる一方、優先ＴＳＮストリームからでないフレームは、待ち行列に入れられ、遅延され得る。産業ネットワークキングのための関連特徴は、ＩＥＥＥ８０２．１Ｑｂｖ（「時間ゲート待ち行列」、すなわち、フレームの時間調整されたハンドリングを導入する）、およびＩＥＥＥ８０２．１Ｑｂｕに加えてフレームプリエンプションのためのＩＥＥＥ８０２．３ｂｒである。８０２．１Ｑｂｖは、精密な時間同期に依拠し、ＣＮＣが、時分割多重化様式に類似してブリッジ内でフレーム転送をスケジュールするために使用される場合にのみ適用可能である。Ｑｂｖを使用して、ＣＮＣは、フレームを正確にいつ転送すべきかをネットワーク内の経路と一緒に各ブリッジに伝える。Ｑｂｖの代替案は、ＡＶＢから生じるクレジットベースのシェーピング（Ｃｒｅｄｉｔ－Ｂａｓｅｄ Ｓｈａｐｉｎｇ）（８０２．１Ｑａｖ）であり、これは、それがそれほど決定論的ではないことから、厳しい産業使用事例にはおそらく使用されない。非同時性のトラフィックシェーピング（Ａｓｙｎｃｈｒｏｎｏｕｓ Ｔｒａｆｆｉｃ Ｓｈａｐｉｎｇ）（８０２．１Ｑｃｒ）と呼ばれる追加の特徴は、開発の初期段階にある。保証されたレイテンシ限度を達成するのにおそらく最も適しているＱｂｖに反対する論拠は、それがスケジューリングおよび時間同期に関して必要とする複雑性である。Ｑｂｖおよびフレームプリエンプション（Ｑｂｕおよびｂｒ）は、別個に使用され得るか、またはやはり組み合わされ得る。
ストリーム完全性は、超信頼性を提供するのに重要である。超低レイテンシおよびジッタでパケットを配信することとは別に、ＴＳＮストリームは、伝送誤差、物理的破損、およびリンク故障を含むネットワークの動的条件にかかわらず、それらのフレームを配信する必要がある。ストリーム完全性は、経路冗長性、マルチパス選択、ならびに待ち行列フィルタリングおよび取締まりを提供する。したがって、１つの主な特徴は、フレーム複製および除去の冗長性（ＦＲＥＲ：Ｆｒａｍｅ Ｒｅｐｌｉｃａｔｉｏｎ ａｎｄ Ｅｌｉｍｉｎａｔｉｏｎ Ｒｅｄｕｎｄａｎｃｙ）を含むＩＥＥＥ８０２．１ＣＢである。
上に説明されるＴＳＮ特徴の視覚上の概要は、図２９に提供される。
５ＧとＴＳＮとのインターワーキングがここで論じられる。両方のシステムがその後のＱｏＳおよびネットワーク管理のための多様なやり方を提供することから、新規ソリューションが必要とされる。ここに説明される技法のうちのいくつかに従う基本的な考え方は、５Ｇシステム（５ＧＳ）がＴＳＮネットワークのネットワーク環境に適合することである。進行中のＴＳＮ標準化は、特徴のセットを規定し、すべての特徴が全使用事例のためにサポートされる必要はないということに留意されたい。どのＴＳＮ特徴のセットがどの使用事例に関連するかに関する告知はまだ行われていない。この問題に対処するための進行中の構想は、共同プロジェクトＩＥＣ／ＩＥＥＥ６０８０２：「ＴＳＮ Ｐｒｏｆｉｌｅ ｆｏｒ Ｉｎｄｕｓｔｒｉａｌ Ａｕｔｏｍａｔｉｏｎ」である。それは、開発中であり、頻繁に更新される。公開は２０２１年を予定される。
リアルタイムイーサネットは、バーティカルアプリケーションのための確立した有線通信技術のうちの１つである。無線通信技術では、３ＧＰＰ ＴＳ２２．１０４は、リアルタイムイーサネットをサポートするために５Ｇシステム要件を指定する。いくつかのセンサ、アクチュエータ、およびモーションコントローラが、５Ｇシステムを使用して接続され、他が産業（例えば、リアルタイム）イーサネットを使用して接続されるとき、リアルタイムイーサネットと５Ｇとの相互接続は、イーサネットスイッチに接続されるゲートウェイＵＥを使用して実現されるか、またはデバイスは、イーサネットアダプタを使用してデータネットワークに直接接続される。
潜在的なベースラインシステム要件は、以下である。
・５Ｇシステムは、基本イーサネット層２ブリッジ機能をブリッジ学習およびブロードキャストハンドリングとしてサポートするものとする
・５Ｇシステムは、ＶＬＡＮ（ＩＥＥＥ８０２．１Ｑ）をサポートし、またこれを認識するものとする
・５Ｇシステムは、ＰＤＵセッション型イーサネットを伴う５ＧベースのイーサネットリンクにわたってＩＥＥＥ８０２．１ＡＳによって規定される時刻同期をサポートするものとする
・５Ｇシステムは、ＩＥＥＥ８０２．１Ｑ、例えば、ＩＥＥＥ８０２．１Ｑｂｖ（時間意識のあるスケジューリング）によって規定されるようなＴＳＮをサポートするものとする
・５Ｇシステムは、時間意識のあるスケジュールおよび非ＴＳＮ低優先度トラフィックに続くクリティカルリアルタイムトラフィックの共存をサポートするものとする。
ＴＳＮネットワークは、ブリッジ、エンドステーション、ネットワークコントローラ、およびケーブルという、４つタイプのコンポーネントからなる（備考：産業文脈においては、エンドステーションは、例えばデイジーチェーニングおよびリングトポロジを可能にするために、スイッチでもあるというのは一般的である）。５Ｇネットワークは、大半の場合において、ＴＳＮネットワークへのシームレスなインテグレーションが想定される場合、１つまたは複数のＴＳＮブリッジのように作用する必要がある。したがって、多くの場合、５Ｇネットワークは、通常のＴＳＮブリッジとしてＴＳＮネットワーク設定に参加する。
図３０は、工場ネットワーク内のベースラインアーキテクチャを例証し、ここではＴＳＮコンポーネントは、作業現場、ならびに工場基幹回線ＴＳＮにおいて使用される。５Ｇは、作業現場からクラウドへの（垂直）接続（垂直ＴＳＮリンクのための５Ｇ）に取って代わるために使用される。一般に、図３０に例証されるような作業現場ＴＳＮは、少なくとも、いかなるＴＳＮスイッチも有さない単一のＴＳＮ機能のあるエンドステーションであり得る。トーカおよびリスナは、５Ｇネットワークの両側（ＵＥおよびＵＰＦ）に登場し得る。５Ｇネットワークは、両方のＴＳＮドメインを接続および融合するために使用される。無線アクセスポイントまたは５Ｇ基地局は、ＴＳＮドメインを接続するために使用され得る。図３０のＣＵＣおよびＣＮＣは、工場基幹回線側に配備されるが、それらは、例えば、機械間ＴＳＮネットワークの部分として、作業現場にも実装され得る。
同じ作業現場における２つのＴＳＮドメインを接続すること（水平ＴＳＮリンクのための５Ｇ）は、１つの可能性のあるシナリオである。この場合、５ＧＳは、作業現場の単一ホップに取って代わる。ＮＲが現在デバイス・ツー・デバイス（Ｄ２Ｄ）能力をサポートしないため、これは、５Ｇにおいて２ホップ（ＵＥ Ａ－ｇＮＢ／コア－ＵＥ Ｂ）接続となる。
機械の内側で使用されるＴＳＮ（機械間通信）の場合、５Ｇとのインターワーキングは、明らかに、上で紹介したよりも関連性が低い。機械の内側の２つのノード（おそらくは金属）は、無線で通信するために５Ｇ基地局への中央接続におそらくは依拠しない。典型的な一例は、正確な結果を達成するために異なるモータが非常に正確に制御されなければならない印刷機である。
さらなる選択肢は、レガシー５Ｇデバイス（すなわち、ＴＳＮ特徴サポートなしのデバイス、または、イーサネットデバイスでさえない場合がある）が、工場基幹回線ＴＳＮネットワークに接続される５ＧＳに接続されることである。５ＧデバイスはいかなるＴＳＮ特徴も認識しないか、またはＴＳＮ特徴自体をサポートすることができないため、５ＧＳは、シームレスなＱｏＳエンドツーエンドを有するＴＳＮエンドポイントに通信することができるように、５Ｇデバイスの代わりにＴＳＮ特徴を設定する仮想エンドポイントとして作用し得る。仮想エンドポイント機能は、５ＧＳ内のＵＰＦの部分であり得る。ＴＳＮネットワーク観点からは、仮想エンドポイントが実際のエンドポイントであるように見え、５Ｇエンドポイントは隠れている。図３１は、仮想エンドポンイントが、５Ｇを使用して非ＴＳＮデバイスをＴＳＮネットワークに接続するためにどのように使用され得るかを示す、作業の概念的方式を例証する。図内では、「ＵＰ」は、「ユーザプレーン」を指す一方、「ＣＰ」は、「制御プレーン」を指す。この概念は、「アプリケーションゲートウェイ」と称され得る。
いくつかのＴＳＮ特徴は、５ＧＳに課題をもたらす。以下では、シームレスな５Ｇ ＴＳＮインターワーキングを可能にするために、いくつかの主要ＴＳＮ特徴がどのようにして５ＧＳによってサポートされ得るかが強調される。
ネットワーク－ワイド参照時間（ＩＥＥＥ８０２．１ＡＳ－ｒｅｖ）
ＴＳＮでは、参照時間は、ローカルクロックをエンドステーションで許可し、互いに同期するようスイッチングするＩＥＥＥ８０２．１ＡＳ－ｒｅｖ同期プロトコルによって与えられる。より具体的には、上記文書で説明されるいわゆる汎用高精度時間プロトコル（ｇＰＴＰ）は、ネットワークの異なるＴＳＮ対応デバイス間でホップごとの時間伝送を採用する。プロトコルは、ＴＳＮネットワーク内で複数の時間ドメインおよび冗長なグランドマスタセットアップならびに他の特徴の確立をサポートしている。５ＧＳは、ｇＰＴＰプロセスに参加可能であり、ＴＳＮと同じクロック正確性および同期能力を可能にするべきである。ｇＰＴＰプロセスは、クロックドリフトを補償するよう常に周期的に実行されなければならない。５ＧＳによってＴＳＮネットワーク内のグランドマスタからケーブルで受信したクロック情報は、基地局（ＢＳ）からＵＥへ無線で搬送される必要があり、またはその逆でもよい。これをどのように行うことができるかについて、様々な選択肢が現在議論されており、標準化における進行中のトピックである。以下では、また一般には、グランドマスタは、ｇＰＴＰに使用されるソースクロックを搬送するデバイスである。
５ＧネットワークにまたがるＴＳＮ時間同期の単純な例を、図３２に示す。グランドマスタの時間信号は、ＵＰＦ側において５ＧＳで受信され、ＢＳによって無線で送られる。ＵＥは、ＢＳから受信する時間信号を、デバイス１（図面では「Ｄｅｖ１」）に転送する。デバイス１は、グランドマスタの時間信号を、デバイス２（図面では「Ｄｅｖ２」）に通信できる必要がある場合がある。
内部的には、５ＧＳは、ｇＰＴＰには関連しない任意のシグナリングを使用してグランドマスタ時間信号を搬送する場合がある。その場合、５ＧＳにおけるイングレスポイント（ＵＥおよびユーザプレーン機能（ＵＰＦ）において）は、ｇＰＴＰスレーブとして作用する必要がある。これらは、到来ｇＰＴＰ信号からのグランドマスタに自身を同期させ、その時間の概念をＲＡＮ上で転送する。もちろん、時間同期正確性の要件は、アプリケーションによって規定され、満足される必要がある。ＬＴＥ Ｒｅｌｅａｓｅ １５では、サブマイクロ秒の正確性を有する正確な時間同期についてのシグナリングメカニズムが導入されており、ＮＲ用に再利用される場合がある。
産業用のユースケースでは、図３３および図３４に描かれているように、複数の時間ドメインのサポートが妥当な場合がある。１つの時間ドメインは、協定世界時（ＵＴＣ）などの、グローバルな時間ドメインであり得る。この時間ドメインは、アプリケーションによって使用され、グローバル時間ベースの一定の事象のログを取ることができる。さらには、ローカルクロック、すなわち、任意の時間スケールに基づいているが一定の規定された開始ポイントエポックを有していないクロック（例えば、グローバルクロック時間スケールを参照する代わりに、デバイスのブートアップ時に開始したグランドマスタにおけるクロック）に基づいて、追加的な時間ドメインを使用することができる。このローカルクロックは、グローバルクロックよりも、ずっと高い精度を有することができる。ローカルクロックは、グランドマスタから、いくつかの他のデバイスに分散され、非常に正確に同期されたアクションを協調させるようアプリケーションレイヤで、または例えば、８０２．１Ｑｂｖで規定されるような時間決めされた通信用に使用される。５ＧＳにおける複数の時間ドメインをサポートするために、実装形態のうちの１つの可能な方法が、例えばＵＴＣ時間スケールを使用して、すべてのｇＮＢおよびＵＥ間の共通参照時間を確立し、次にそれに基づいて、５ＧＳ内の個々の時間ドメイン信号を、その特定の時間ドメインを必要とするエンドステーションのみに伝送する。個々のローカル時間信号の送信のために、共通参照時間からのタイムスタンピングを使用すること、または共通参照時間を参照するオフセットを周期的に送信することが可能である。加えて、類似のタイムスタンピングメカニズムを使用して、ｇＰＴＰフレームの転送が、ＲＡＮを通じてトランスペアレントに行われることが可能な場合もある。
共通参照時間を使用して、一般的な複数の他の時間ドメインをサポートするという概念を、図３３に図示する。この図面では、５Ｇ時間ドメイン内のクロックは共通参照時間を描いているが、ＴＳＮワークドメイン内のクロックは、５ＧＳでいくつかのＵＥに転送される必要があるローカルクロックである。共通参照時間を使用して、ＵＥおよびＵＰＦにおいて行われたタイムスタンプに基づいて、５ＧＳにおいて変化する送信時間を考慮するよう、ｇＰＴＰパケット内部（ＴＳＮワークドメインクロックに属する）の時間を補正することが可能な場合がある。例えば、アナウンス（設定）フレームおよびフォローアップ（タイムスタンプを搬送する）フレームのように、イングレスに到来するすべてのｇＰＴＰフレームのうちのサブセットだけが、５ＧＳ全体でトランスポートされる必要がある場合がある。他のフレームは、５ＧＳイングレスにおいて消費され、転送されない可能性がある。エグレスにおいて、５ＧＳは、あらゆる場合に、ｇＰＴＰマスタのように作用する必要がある。時間ドメインを検出して差別化するために、各フレームのｇＰＴＰヘッダにおけるドメイン番号フィールドを、使用することができる。どのＵＥをどの時間ドメインに同期させるかを識別するためには、何らかの努力が必要となる。最近の研究活動は、この問題に対処している。
図３３では、５ＧＳにおけるアプリケーション機能（ＡＦ）は、ＴＳＮネットワークにおけるＣＮＣに向けたインターフェースとして使用される。１つの可能な方法では、ＣＮＣは、時間ドメインがどのように確立される必要があるか、すなわち、どのＵＥがどの時間ドメイン信号を必要とするかについての情報を５ＧＳに提供する場合がある。
時間決めされた送信ゲート（ＩＥＥＥ８０２．１Ｑｂｖ）
ＴＳＮ特徴ＩＥＥＥ８０２．１Ｑｂｖは、送信ゲートによって制御されるトラフィックのスケジューリングされた送信を提供する。イーサネットブリッジの各エグレスポートには、最大８キューが備えられ、それぞれのキューは別個のゲートを伴っている。これを図３５に図示する。
イングレストラフィックは、宛先となっているエグレスポートでキューに転送される。エグレスキューは、例えば、フレームのＶＬＡＮヘッダフィールド内の優先度コードポイント（ＰＣＰ）によって識別される。規則的なサイクル（「周期ウィンドウ」）が、ポートごとに確立され、そのウインドウにおけるあらゆる特定の時間において、一定のゲートだけがオープンされ、したがって一定のトラフィッククラスだけが送信され得る。キュー協調は、ＣＮＣによって行われる。ＣＮＣは、トポロジ、ストリーム、さらには個々の遅延情報についての情報をすべてのスイッチから集め、ゲート制御リスト（ＧＣＬ）を作成する。ＧＣＬは、各スイッチでキューのオープンとクローズのタイミングを制御するが、キュー内のフレームの順は制御しない。キュー内のフレームの順、すなわち、キュー状態が確定的ではない場合、２つのストリームのタイムリーな挙動は、変動し、エンドツーエンドの送信全体にジッタをもたらす場合がある。時間協調様式でゲートをオープンおよびクローズすることによって、同一のインフラストラクチャに不確定的なベストエフォート型のトラフィックが存在していても、ＴＳＮネットワーク全体で確定的なレイテンシを達成することが可能である。ベストエフォートなトラフィックは、そのキューをクローズし、優先トラフィックを別のキューから通過させることにより、単純に抑えられる。タイムリーな送達は、フレームを１つのブリッジから次のブリッジに遅れて送信しないことを意味するだけでなく、連続的なホップにおいてバッファ輻輳をもたらす可能性があるため、フレームをあまり早期に送信することを妨げることに言及することは重要である。
５ＧＳは、８０２．１Ｑｂｖ標準が期待する方法、すなわち、５ＧＳがＴＳＮネットワークの観点から１つまたは複数のＴＳＮスイッチとして作用する場合にＣＮＣによって作成されたＧＣＬにしたがって、フレームを送信することができるべきである。これは、ＵＥおよびＵＰＦそれぞれにおいて、イングレスおよびエグレスＴＳＮトラフィック用に特定のタイムウィンドウを維持することを意味する。そのため、アップリンクおよびダウンリンクの両方において、設定された時間ポイントで（早くもなく、遅くもなく）パケットが次のＴＳＮノードに確かに転送されるよう、５ＧＳ内のデータ伝送は、特定の時間バジェット内に起こらなければならない。５ＧＳにおけるレイテンシの最大部分が、恐らくはＲＡＮに加えられるため、無線リソースのスケジューリングを改善するために、ＣＮＣからのタイミング情報をｇＮＢで使用することが妥当と思われる。設定グラントおよび半永続スケジューリングのようなメカニズムを使用するＢＳにおける無線リソースの効率的なスケジューリングのために、Ｑｂｖスケジューリングによる送信タイミングについての情報を活用することが可能な場合がある。とにかくＢＳは、ＵＥに時間信号を転送することができるように時間を認識する必要があるため、ただ前もって送信スケジュールについて知っておく必要がある場合がある。Ｑｂｖメカニズムは、ＴＳＮネットワークから最小のジッタで、フレームが５ＧＳに確実に到達できるようにする。
５ＧＳにおけるアプリケーション機能（ＡＦ）は、ＣＮＣをインターフェースするためのオプションであり得る。そこで、トポロジが通知される場合があり、同様に、５ＧＳが常時のＴＳＮスイッチまたは任意のＴＳＮスイッチトポロジであるかのように、レイテンシ数字がＣＮＣに与えられる場合がある。次に、ＡＦはＣＮＣから時間スケジュールを受け取り、５ＧＳが外部ＴＳＮネットワークで生じている時間ゲートされたキューイングをサポートするよう、それを意味のあるパラメータに変換することもできる。現在の方法では、ＣＮＣは、典型的なＴＳＮスイッチを通じて加えられる遅延を規定するために固定数だけを受け入れるよう指定されることを理解することは重要である。したがって、ＣＮＣにレポートされる必要があるレイテンシ数に関して、５ＧＳがより「柔軟な」ＴＳＮスイッチでもあることができるように、何らかの新しい方法が必要とされる。
パケットのタイムリーな送達を達成する１つの方法は、５Ｇネットワークのエグレスポイントにおいて（つまり、ダウンリンクまたはアップリンク用のＵＥおよびＵＰＦにおいて）、プレイアウトバッファの使用を伴うことであり得る。このようなプレイアウトバッファは、時間を認識し、Ｑｂｖに使用されＴＳＮネットワークのＣＮＣによって指定される時間スケジュールをさらに認識する必要がある。プレイアウトバッファの使用は、ジッタを低減するための一般的な方法である。例えば、ダウンリンクについての原理では、ＵＥまたはＵＥに従うあらゆる機能は、転送する一定の規定された時間的ポイントになる（「プレイアウトする」）までパケットを保留する。ＴＳＮトラフィック用の追加的な機能として、恐らくはＵＰＦにおいて、またはＵＰＦの後、同じことがアップリンクにもあり得る。
フレームプリエンプション（ＩＥＥＥ８０２．１Ｑｂｕ）
ＩＥＥＥ８０２．１Ｑｂｕ修正条項「フレームプリエンプション」、およびその付随文書ＩＥＥＥ８０２．３ｂｒ「Ｓｐｅｃｉｆｉｃａｔｉｏｎ ａｎｄ Ｍａｎａｇｅｍｅｎｔ ｐａｒａｍｅｔｅｒｓ ｆｏｒ Ｉｎｔｅｒｓｐｅｒｓｉｎｇ Ｅｘｐｒｅｓｓ Ｔｒａｆｆｉｃ」は、フレーム送信を中断して優先度のより高いフレームを送信する能力を加えている。これらは、低優先度の送信が完全に終了するのを待機する必要がないため、あらゆるエクスプレスフレームは短いレイテンシを有する。８つの優先度レベルが、エクスプレス（ｅｘｐｒｅｓｓ）と、あらかじめ空にできる（ｐｒｅｅｍｐｔｉｂｌｅ）との２つのグループに分けられる。エクスプレスグループに属する優先度レベルに割り振られたキューは、エクスプレスキューと称される。プリエンプトされたフレームの送信は、エクスプレストラフィックが終了した後、再開され、受信側はプリエンプトされたフレームを、フラグメントから再組立てすることができる。
５Ｇネットワークは、既存のメカニズムでプリエンプション技法を既にサポートしている。フレームのプリエンプションを十分にサポートするためのさらなる努力が必要かどうかは、まだ明らかではない。ＩＥＥＥフレームのプリエンプションと、５Ｇのプリエンプション技法との間には、重要な違いがあることに留意されたい。ＩＥＥＥフレームのプリエンプションは、送信を中断しているだけで、エクスプレスフレームを転送した後、プリエンプトされたフレーム送信が継続される。再送信は、行われない。
フレームレプリケーションおよび信頼性の排除－ＦＲＥＲ（ＩＥＥＥ８０２．１ＣＢ）
ＩＥＥＥ８０２．１ＣＢ標準は、冗長な送信のためのパケットの識別およびレプリケーションを提供する、ブリッジおよびエンドシステムのための、手順、管理オブジェクト、およびプロトコルを導入する。これらの手順のうちの１つが、フレームレプリケーションおよび信頼性の排除（ＦＲＥＲ：Ｆｒａｍｅ Ｒｅｐｌｉｃａｔｉｏｎ ａｎｄ Ｅｌｉｍｉｎａｔｉｏｎ ｆｏｒ Ｒｅｌｉａｂｉｌｉｔｙ）であり、所与のパケットが送達される確率を向上させるために提供される。何らかの理由で１つのイーサネットプラグが除去される場合、または不意にケーブルが切断される場合、通信は継続すべきである。
図３６は、ＦＲＥＲの基本的な特徴のうちの一部を図示している。ＦＲＥＲの重要な特徴の一部は：
・シーケンス番号を、ソースまたは特定のストリームから発せられるパケットに追加する。
・正確な必要性／設定に基づいて、パケットがレプリケートされる。これらは、ネットワークをトラバースする２つ（またはそれより多くの）同一のパケットストリームを作成する。
・ネットワーク中の特定のポイント（典型的には受信側に近いか、または受信側）において、複製パケットは除去される。
・複雑な設定がサポートされるため、メカニズムはネットワーク中の複数ポイントにおける障害をサポートすることができる。
５ＧＳは、例えば単一のＵＥへのデュアルコネクティビティ、または同一の産業用デバイスにデプロイされる２つのＵＥ（「ツインＵＥ」と呼ぶことができる）への２つのＰＤＵセッションをやはり使用して、同じくＴＳＮのためにＦＲＥＲで規定されるようにエンドツーエンドの冗長性をサポートする必要がある場合がある。とにかく、５ＧＳにおける冗長性は、ＴＳＮネットワークと全く同一の原理には基づくことができない（別個の装置を使用する完全な物理的エンドツーエンドの冗長性を意味する）。後者は固定有線リンクに依拠するが、５Ｇは動的無線環境に依拠する。それにもかかわらず、ＦＲＥＲによって規定されるような冗長性は、むしろ装置内の障害（接続ロスにつながるｇＮＢ内のエラーなど）に向けられるが、無線状態を変更することおよびハンドオーバによる接続ロスの影響を明らかに克服することも助ける。
「ツインＵＥ」が使用される場合、十分な冗長性をサポートするためにはいつでも、これらは２つのＢＳに接続されるべきであり、ハンドオーバの場合は、一度に同じＢＳに対して両方でハンドオーバを実施してはならない。
物理的な冗長性が５ＧＳに実装される必要があるかどうか、またはトラフィックが、例えば、単一のユーザプレーン機能（ＵＰＦ）またはサーバハードウェア上でそれぞれ搬送することができるかどうか、はオープンな議論である。例えば、いくつかの５ＧＳ機能が信頼できるため、冗長な方法でデプロイされる必要がない場合、５ＧＳの一部分については、単に物理的な冗長性を使用することで十分な可能性がある。
このＦＲＥＲタイプの冗長性を、ＲＡＮおよびコアの両方において、５ＧＳでどのようにサポートすることができるかを説明することに対して、いくつかの発明が行われている、冗長性についての設定ポイントとして、アプリケーション機能（ＡＦ）を使用することも提案する。５ＧＳは、ＴＳＮネットワークに異なる冗長経路を通知することができ、５ＧＳでは内部的に、一定のコンポーネントの物理的な冗長性があってもなくても十分な方法で冗長性をサポートすることができる。そのため、実際の冗長性の５Ｇ解釈は、この方法で冗長性のＣＮＣ／ＴＳＮ規定から隠すことができる。
５ＧおよびＴＳＮ－ネットワーク設定
ＴＳＮでは、ＩＥＥＥ８０２．１Ｑｃｃ拡張は、ＴＳＮのランタイム設定および再設定をサポートする。初めに、ユーザネットワークインターフェース（ＵＮＩ）を規定する。このインターフェースは、ユーザがネットワークの知識なしにストリーム要件を指定できるようにして、それによってユーザにとってネットワーク設定をトランスペアレントなものにしている。もちろん、これはプラグアンドプレイ挙動を達成することにも関連しており、プラグアンドプレイは、住宅およびオフィスのネットワーキングに一般的であるが今日の産業用イーサネットのネットワークにおいてそうではないからである。
この透明性を可能にする３つのモデルが存在する。具体的には、十分に分散型のモデルであり、このモデルでは、ストリーム要件がトーカから生じてリスナまでネットワークを伝搬する。この場合、ＵＮＩはエンドステーションとそのアクセススイッチの間にある。十分に分散型のモデルは図３７に図示されており、このモデルでは実線矢印は、トーカと、リスナと、ブリッジとの間でユーザ設定情報を交換するためのＵＮＩインターフェースを表している。図面において破線矢印は、ＴＳＮユーザ／ネットワーク設定情報ならびに追加的なネットワーク設定情報を搬送するプロトコルを表している。
集中型のネットワーク／分散型のユーザモデルは、ネットワーク内のすべてのストリームの完全な知識を備えた集中型ネットワーク設定器（ＣＮＣ）と呼ばれるエンティティを導入する。すべての設定メッセージは、ＣＮＣから生じる。ＵＮＩは、やはりエンドステーションとアクセススイッチとの間にあるが、このアーキテクチャでは、アクセススイッチはＣＮＣと直接通信する。図３８は、集中型のネットワーク／分散型のユーザモデルを描いている。
最終的には、十分に集中型のモデルは、中央ユーザ設定器（ＣＵＣ）エンティティが、エンドステーション能力を取り出し、エンドステーション内でＴＳＮ特徴を設定できるようにする。ここで、ＵＮＩはＣＵＣとＣＮＣとの間にある。この設定モデルは、リスナとトーカが、膨大な数のパラメータの設定が設定されることを必要とする、製造のユースケースに最適である場合がある。ＣＵＣはエンドステーションをインターフェースして設定するが、ＣＮＣは、さらにブリッジをインターフェースする。十分に集中型のモデルを、図３９に図示する。以下の議論は、十分に集中型のモデルについてのさらなる詳細を与えるが、それはこのモデルが製造のユースケースに最適と思われるからである。
ＣＵＣおよびＣＮＣ
ＣＵＣおよびＣＮＣは、十分に集中型のモデルでは、図４０に示されるようなタスクの両方を実行する設定エージェント（例えば、工場自動化のコンテキストにおけるＰＬＣ）の一部であり、図４０はＣＵＣとＣＮＣから成る設定エージェントを図示する（図面では、「ＳＷ」はスイッチを指し、「ＥＳ」はエンドステーションを指し、「ＵＮＩ」はユーザネットワークインターフェースを指している）。標準ＩＥＥＥ８０２．１Ｑｃｃは、プロトコルが図４０に示すように、ＣＵＣとＣＮＣとの間で使用されるよう指定していない。ＣＵＣとエンドステーションとの間のインターフェースには、ＯＰＣ ＵＡ（Ｏｐｅｎ Ｐｌａｔｆｏｒｍ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｕｎｉｆｉｅｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）が、ブリッジとＣＮＣとの間にはＮｅｔｃｏｎｆが、可能な選択となり得る。ＴＳＮストリーム確立には、図４１に描かれるように、ＣＵＣはジョイン要求をＣＮＣに出し、これはＣＮＣとＣＵＣとの間の対話を示している。
トーカとリスナの間の通信は、上で導入したようなストリーム内で起こる。ストリームは、データレートならびにトーカおよびリスナで実装されるアプリケーションによって与えられるレイテンシの観点から、一定の要件を有する。ＴＳＮ設定および管理特徴を使用して、ストリームをセットアップして、ネットワーク全体のストリームの要件を保証する。ＣＵＣは、ストリーム要件およびエンドステーション能力をデバイスから収集して、直接ＣＮＣに通信する。図４２は、ＴＳＮストリームのセットアップを行うための様々なエンティティ間のシーケンス図を示している。
十分に集中型のモデル内のＴＳＮネットワークでＴＳＮストリームをセットアップするためのステップは、以下の通りである：
１）ＣＵＣは、例えば、時間センシティブなストリームを交換することになっているデバイスを指定する、例えば、産業用アプリケーション／エンジニアリングツール（例えば、ＰＬＣ）からの入力を得ることができる。
２）ＣＵＣは、ユーザトラフィックおよびペイロードサイズの期間／間隔を含む、エンドステーションおよびＴＳＮネットワーク内のアプリケーションの能力を読み取る。
３）ＣＮＣは、例えば、ＬＬＤＰおよびあらゆるネットワーク管理プロトコルを使用して、物理的なネットワークトポロジを発見する。
４）ＣＮＣは、ネットワーク管理プロトコルを使用して、ＴＳＮネットワーク内のブリッジ（例えば、ＩＥＥＥ８０２．１Ｑ、８０２．１ＡＳ、８０２．１ＣＢ）のＴＳＮ能力を読み取る。
５）ＣＵＣは、ＴＳＮストリームを設定するためにＣＮＣに向けてジョイン要求を開始する。ＣＮＣは、１トーカから１つまたは複数のリスナに向けたＴＳＮストリームのために、ブリッジにおいてネットワークリソースを設定する。
６）ＣＮＣは、ＴＳＮドメインを設定する。
７）ＣＮＣは、物理的なトポロジをチェックして、必要とされる特徴がネットワーク内のブリッジによってサポートされるかどうかをチェックする。
８）ＣＮＣは、ストリームの経路およびスケジュール（Ｑｂｖが適用されている場合）の計算を実施する。
９）ＣＮＣは、ＴＳＮネットワーク内の経路に沿ってブリッジ内のＴＳＮ特徴を設定する。
１０）ＣＮＣはＣＵＣへのストリームについてのステータス（成功または失敗）を返す。
１１）ＣＵＣは、エンドステーションをさらに設定して（この情報交換に使用されるプロトコルは、ＩＥＥＥ８０２．１Ｑｃｃ仕様の範囲にはない）、初めにリスナとトーカとの間で規定された通りにユーザプレーントラフィック交換を開始させる。
５ＧＳアプリケーション機能（ＡＦ）は、５ＧＳがＴＳＮ制御プレーン機能（すなわち、ＣＮＣとＣＵＣ）と対話するための、潜在的なインターフェースとして考える。３ＧＰＰ ＴＳ３３．５０１によると、ＡＦは、トラフィックルーティングに影響を与え、５Ｇリンク用のポリシ制御のためにポリシフレームワークと対話し、サービスを提供するために３ＧＰＰコア機能とさらに対話することもでき、このサービスを利用して５Ｇ ＴＳＮインターワーキングシナリオにおいて、ＴＳＮストリームをセットアップおよび設定することができる。図４３は、ＡＦのＴＳＮ制御プレーンとの潜在的なインターフェースを図示している。
ＴＳＮネットワークにおける、ＦＲＥＲセットアップのシーケンスストリームが、図４４に示されている。ＣＵＣは、ＣＵＣからＣＮＣへのメッセージをジョインするためにパラメータ（１よりも大きいＮｕｍＳｅａｍｌｅｓｓＴｒｅｅｓ）の値を要求にセットする。次に、ＣＮＣはこの入力に基づいて、経路計算ステップにおいて、素な木（ｄｉｓｊｏｉｎｔ ｔｒｅｅ）を算出する。このステップは、ＩＥＥＥ８０２．１ＣＢ（ＦＲＥＲ）の管理オブジェクトを使用して、ブリッジにおける冗長な経路を設定する。
上のＦＲＥＲ部分で導入したように、ＡＦは、ＣＮＣへの冗長性サポートをシグナリングし、ＣＮＣからの冗長な経路計算を受け入れるインターフェースを実装することができる。これは図４５に図示されており、図４５はＦＲＥＲをセットアップするための、ＡＦと、ＣＵＣと、ＣＮＣとの間の対話を図示している。さらには、ＡＦをさらに使用して、ＦＲＥＲ以外の他のＴＳＮ特徴のために、ＣＮＣと対話することもできる。
現在ＴＳＮは、研究および開発フェーズである。初期の製品が、市販であり、ここで列挙するＴＳＮ特徴のサブセットのみをサポートしている。また、ＴＳＮの標準化が、進行中であり、一部の特徴はまだ完成していない。特に、どの特徴が産業用のユースケースに関連し、どの特徴が関連しないか明らかではない。ＩＥＣ／ＩＥＥＥ６０８０２は、産業用の使用に向けたＴＳＮプロファイルを規定するための進行中の努力である。それにもかかわらず、ＴＳＮが数年のうちに有線産業用自動化用の主な通信技術となることが、広範囲のビジョンである。
先の段落において、時間センシティブなネットワーク（ＴＳＮ）の概念が導入され、産業用用途に向けたイーサネット通信を改善するビジョンを説明した。次いで、技術的な導入が、ベストエフォート型のトラフィックだけではなくクリティカルな優先度のストリームをハンドリングする必要があるＴＳＮのパフォーマンス上のゴールの一部を提供した。これらのクリティカルなストリームは、ＴＳＮがサポートしなければならない非常に低く境界付けされたレイテンシを必要とする。これにより、産業用自動化の領域において、ＴＳＮが新しいユースケースを可能にすることができる。
次いで、ＴＳＮがどのように確定的な通信を提供するかを説明するために、ＴＳＮ動作原理についてのさらなる詳細を提供した。５ＧをＴＳＮコア特徴と統合する問題も議論した。この統合には、５ＧネットワークからのＴＳＮ特徴の特定のセットのサポートが必要とされる。この特徴セットが説明され、２つのネットワーク間の滑らかなインターワーキングを可能にするための一部の発明の技法も説明された。
コアネットワーク
コアネットワークは、無線アクセスネットワーク（ＲＡＮ）と１つまたは複数のデータネットワーク（ＤＮ）との間に常駐するシステムの一部である。データネットワークは、インターネットまたは閉じられたコーポレートネットワークであってもよい。コアネットワークが、十分に仮想化され、クラウドプラットフォームの上部で実行されるものと想定する。コアネットワークのタスクには、以下が含まれる：サブスクライバ管理；サブスクライバ認証、認可、およびアカウンティング；モビリティ管理；ポリシ制御およびトラフィックシェーピングを含むセッション管理；合法的傍受；ネットワーク公開機能。５Ｇコアネットワークは、３ＧＰＰ文書「Ｓｙｓｔｅｍ Ａｒｃｈｉｔｅｃｔｕｒｅ ｆｏｒ ｔｈｅ ５Ｇ Ｓｙｓｔｅｍ （５ＧＳ）」、３ＧＰＰ ＴＳ２３．５０１，ｖ．１５．４．０（２０１８年１２月）に説明されている。図４６は、３ＧＰＰ ＴＳ２３．５０１に記載されるような、５Ｇコアネットワークのコンポーネント、ならびにその無線アクセスネットワーク（ＲＡＮ）およびＵＥに対する関係性を図示している。
今日のモバイルブロードバンド（ＭＢＢ）デプロイメントでは、コアネットワーク機能は、数百万のサブスクライバにサービングする大規模なノード上にデプロイされることが多い。ノードは、少数の集中型データセンタに置かれることが多く、スケール上の経済性を与えている。
５Ｇでは、ＭＢＢ以外にも多くの他のユースケースが生じる。これらの新しいユースケースは、様々なデプロイメントおよび様々な機能性を必要とする可能性がある。例えば、製造においては、合法的な傍受ならびに多くの課金および会計機能は、必要ない場合がある。モビリティは、簡略化することができるか、または小規模な工場サイトの場合では、まったく必要ない可能性がある。代わりに、ネイティブなイーサネットまたは時間センシティブなネットワーキング（ＴＳＮ）のためのサポートを含む新しい機能が必要とされる。新しい機能は、時間のかかる標準化プロセスを経る必要なく迅速に追加できることが好ましい。
レイテンシ、データのローカル性、および生存性の理由から、製造用のコアネットワークは、必ずしも大規模な集中型データセンタで実行される必要はない。代わりに、工場サイトでは、小規模なコアネットワークをデプロイ可能であるべきである。５Ｇ、および製造に必要なものは、デプロイメントの観点から、また機能性の観点から柔軟なコアネットワークである。
これらの問題は、コアネットワークのユーザプレーンをマイクロユーザプレーン機能（μＵＰＦ）と呼ばれる小さな機能に分解することにより対処することができる。ユースケースに応じて、μＵＰＦの様々なセットが、サブスクライバ向けのユーザプレーンサービスに再構成される。サービスは、経時的に変わる可能性があり、μＵＰＦは、レイテンシのようなサービス要件に応じて、実行ノードでホストされる。コアネットワークの制御プレーンは、抽象レベルでサービスを説明することにより、サービスを要求する。チェーンコントローラは、この高レベルサービス説明をμＵＰＦのセットに変換し、これらのμＵＰＦを正しい実行ノードでインスタンス化する。図４７は、チェーンコントローラ概念を図示している。
この手法は、デプロイメントおよび機能性の観点から柔軟性を与えており、製造のようなユースケース向けのベースとして使用することができる。柔軟性の重要な態様として、この手法により、非常に小さなフットプリントにスケールダウンすることができる実装形態が可能となる。
製造におけるコアネットワークに代替的な１つのコアネットワークデプロイメントは、工場において、ローカルの、可能性としてはスタンドアロンのデプロイメントである。別のデプロイメント代替は、より集中型のクラウドでコアネットワークの一部を実行することである。そのようなクラウドは、オペレータサイトまたは何らかのコーポレートサイトに存在する可能性がある。コアネットワークがオペレータによって提供される場合、そのようなデプロイメントは、規模が経済的であるという優位性を与えることができる。この製造カスタマ向けのプロセスは、やはり他のカスタマ用に使用されるノード上でホストすることができる。同一の管理システムを使用して、複数のカスタマにサービングすることができる。
後者のデプロイメントでは、レイテンシ、データのローカル性およびローカル生存性のために、特殊なケアが取られる必要がある。ユーザプレーンの部分は、レイテンシのために、いつもローカル工場クラウドで実行される必要がある。しかし、制御プレーンは、リモートで非常に良好に実行することができ、これはこのデバイス制御プレーンシグナリングが、主に認証（あまり頻繁ではなく、時間クリティカルではない）、セッションセットアップ（典型的には、工場デバイスでは一度だけ）、および基地局全体のモビリティ（小規模なデプロイメントでは、全く起こらない場合がある）に向けたものであるからである。
シグナリングは、主に認証（あまり頻繁ではなく、時間クリティカルではない）、セッションセットアップ（典型的には、工場デバイスでは一度だけ）、および基地局全体のモビリティ（小規模なデプロイメントでは、全く起こらない場合がある）に向けたものである。図４８は、このデプロイメントの高レベル機能図を示している。
ＭＢＢに使用される一部のコアネットワーク機能は、製造では必要とされない。これは、産業用用途のコアネットワークに、非常に最小限の特徴までスケールダウンするよう要件を課す。いくつかの新しい特徴が必要となる。必要とされる新しい特徴は、基本的なイーサネットサポート（ネイティブイーサネットＰＤＵセッション）、およびより高度なイーサネット特徴（例えば、ＴＳＮ）である。
工場内では、トラフィックを区別できなければならない。例えば、製造クリティカルなデバイスは、異なるサービスそして「オフィス」デバイスを必要とする。そのような区別化を達成するためにはいくつかの技法があり、ＰＬＭＮ、スライシング、ＡＰＮ、またはμＵＰＦチェインニングが挙げられる。
さらなる特徴が、以下の領域で構想され得る：
・レジリエンス
・冗長性（複数のＵＥ）
・データのローカル性
・工場外部から工場フロアネットワークへアクセスする能力
製造向けの新しい特徴は、コアネットワークへのいくつかのインターフェースにインパクトを与える。例えば、製造クリティカルなコアネットワークサービスを実行することは、実行する製造クリティカルなクラウドを必要とする。または、工場所有者の責任の下、いくつかの部分をローカルで実行するネットワークデプロイメント、およびオペレータの責任の下、いくつかの部分を集中化して実行するネットワークデプロイメントは、管理システムに変更を必要とする。さらには、５Ｇ（コア）ネットワークシステムが単一の論理ＴＳＮスイッチとしてモデル化される場合、追加的なネットワーク公開インターフェースが、必要とされる。
無線アクセスネットワーク
近年、産業用ＩｏＴのサポートを可能にするために必要なセルラ無線アクセス能力が、大いに改善されてきており、ＬＴＥおよびＮＲ両方がこのサポートを提供するために適した技術となっている。ＵＲＬＬＣを可能にするために、信頼できる送達ならびに新しいＭＡＣおよびＰＨＹ特徴をサポートするいくつかのアーキテクチャオプションが、ＬＴＥおよびＮＲ Ｒｅｌｅａｓｅ１５の仕様に追加されている。追加的なＵＲＬＬＣ高度化が、レイテンシ０．５～１ｍｓおよび最大１～１０－６の信頼性を達成することを目標に、ＮＲ Ｒｅｌｅａｓｅ１６向けに研究されている。さらには、ＮＲ ＲＡＮによってイーサネットＰＤＵトランスポートおよびＴＳＮをサポートすることを特にターゲットとする改善が、Ｒｅｌｅａｓｅ１６で構想される。
以下では、指定されたＬＴＥおよび３ＧＰＰ Ｒｅｌｅａｓｅ１５で導入されたＮＲ ＵＲＬＬＣ特徴、ならびにＮＲ Ｒｅｌｅａｓｅ１６のために本発明で提案されるＲＡＮ概念を説明する。まず、５Ｇ ＲＡＮアーキテクチャオプションを、どのように使用して、より高い信頼性を達成するために、データ複製をサポートすることができるかを議論する。次いで、ＮＲ産業用ＩｏＴおよび高度化ＵＲＬＬＣ（ｅＵＲＬＬＣ）に対してＲｅｌ－１６作業において現在検討されている特徴を含めて、ＵＲＬＬＣ用のレイヤ１およびレイヤ２特徴を説明する。以下では、ＬＴＥおよびＮＲがどのように高精度時間参照をＵＥに送達するか、ならびにイーサネットＰＤＵが５Ｇ ＲＡＮを通じて送達される場合、イーサネット圧縮がどのように機能するかを続けて説明する。工場自動化などの産業用ＩｏＴユースケースでは、データプレーンおよび制御プレーンの両方について、信頼性を確実にする必要がある。さらには、信頼できる制御プレーンおよび信頼できるモビリティがどのように達成することができるかの説明。技術ロードマップを、Ｒｅｌｅａｓｅ１５ ＬＴＥおよびＲｅｌｅａｓｅ１５ ＮＲにおいて指定される、ならびにＲｅｌｅａｓｅ１６ ＮＲに計画される特徴セットをハイライトして説明し、要約を用いて結論付ける。
５Ｇ ＲＡＮアーキテクチャオプション
このサブセクションは、５Ｇ ＲＡＮアーキテクチャを導入するが、産業用ＩｏＴをサポートするための特徴の後続の説明は、このアーキテクチャに基づいている。
３ＧＰＰにおける５Ｇ標準化作業は、ＮＲについて、ＬＴＥについて、ならびにＮＲおよびＬＴＥ両方を含む多接続性について、Ｒｅｌｅａｓｅ１５で締めくくった。Ｒｅｌｅａｓｅ１５は、新しく開発された無線アクセス技術である５Ｇ ＮＲについての、最初のリリースである。加えて、５Ｇユースケースを可能にするために必要ないくつかのＬＴＥ特徴が指定されている。これらの新しいＲｅｌ－１５ ＮＲおよびＬＴＥ標準は、複数の変形形態において、両方の技術の統合をサポートする。すなわち、ＬＴＥ基地局（ｅＮＢ）は、ＮＲ基地局（ｇＮＢ）とインターワーキングし、それぞれがＥ－ＵＴＲＡコアネットワーク（ＥＰＣ）および５Ｇコアネットワーク（５ＧＣ）を伴う。そのような統合ソリューションでは、ユーザ機器（ＵＥ）は、様々なキャリアを介して、ＬＴＥまたはＮＲタイプの２つの無線基地局と同時に接続し、これは一般的にデュアルコネクティビティ（ＤＣ）と表され、ＬＴＥ＋ＮＲの場合ではＥＮ－ＤＣ／ＮＥ－ＤＣと表される。ＬＴＥとＮＲのインターワーキングを可能にするネットワークアーキテクチャを、図４９、図５０、および図５１に図示する。
図４９は、多接続の場合における、ＲＡＮの制御プレーンを示している。図面の左に示されるＥＮ－ＤＣの場合では、ＬＴＥマスタｅＮＢ（ＭｅＮＢ）は、ＥＰＣのＭＭＥに向けてのアンカーポイントである。この場合、ＮＲノード、ｇＮＢは、ＬＴＥネットワークに統合される（そのため、ｅｎ－ｇＮＢと表される）。右に示されるＮＲ－ＮＲ ＤＣの場合では、マスタノードおよびセカンダリノードの両方（ＭＮおよびＳＮ）が、ＮＲ ｇＮＢタイプのものであり、ＭＮは制御プレーンの５ＧＣへのインターフェース、すなわち、ＡＭＦへのインターフェースを終端する。
図５０は、ユーザプレーンネットワークアーキテクチャを示しており、やはり左にＥＮ－ＤＣの場合を示し、右にＮＲ－ＮＲ ＤＣの場合を示してある。ユーザプレーンでは、データはコアネットワークからセカンダリノードに（ＥＮ－ＤＣではｅｎ－ｇＮＢ、ＮＲ－ＮＲ ＤＣではＳＮ）直接ルーティングすることができるか、またはセカンダリノードに向けてＭｅＮＢ／ＭＮを介してルーティングされ得る。
ＵＥとの送信／受信は、この時両方のノードで生じる可能性がある。
ＬＴＥおよびＮＲにおける無線アクセス用のプロトコルアーキテクチャは、大部分は同じであり、物理レイヤ（ＰＨＹ）、媒体アクセス制御（ＭＡＣ）、無線リンク制御（ＲＬＣ）、パケットデータコンバージェンスプロトコル（ＰＤＣＰ）、ならびに（ＮＲ用の５ＧＣからのＱｏＳフローハンドリングのための）サービスデータ適応プロトコル（ＳＤＡＰ）から成る。以下のそれぞれのセクションでさらに見ていくように、１つの送信リンクについて、低レイテンシおよび高信頼性を実現するために、すなわち、１つの無線ベアラのデータを１つのキャリアを介してトランスポートするために、いくつかの特徴がＰＨＹおよびＭＡＣ用のユーザプレーンプロトコルに導入されている。さらには、信頼性は、複数の送信リンクでデータを重複して送信することにより改善することができる。このために、複数のベアラタイプオプションが存在する。
図５１では、ユーザプレーンおよび制御プレーンのベアラ（ＤＲＢまたはＳＲＢ）両方が想定することができる、ＮＲ用の異なる無線ベアラタイプが図示されている。マスタセルグループ（ＭＣＧ）またはセカンダリセルグループ（ＳＣＧ）では、ベアラタイプ送信は、それぞれセカンダリノード／ＳＮとしてＭｅＮＢ／ＭＮまたはｅｎ－ｇＮＢのセルグループを介してのみ起こる。ＭＣＧおよびＳＣＧは、ＵＥの観点から規定されることに留意されたい。しかしながら、ネットワークの観点からは、これらのベアラは、使用されるセルグループとは無関係に、ＭＮまたはＳＮにおいて終端され得る。
分離ベアラタイプの運用では、データはＰＤＣＰで分離または複製され、ＭＣＧおよびＳＣＧセルグループ両方に関連付けられるＲＬＣエンティティを介して送信される。やはり、分離ベアラは、ＭＮまたはＳＮにおいて終端され得る。データは、これらのベアラのうちの１つまたは複数を介してＵＥに伝達することができる。データの複製は、セルグループ内で追加的にＣＡを採用する場合に、またはセルグループ間の複製のために分離ベアラを採用することにより、ＭＣＧまたはＳＣＧベアラについて可能である。これを以下でさらに説明する。さらには、同一データを複数のベアラ、例えば、ＭＣＧ終端ベアラおよびＳＣＧ終端ベアラ上で送信することによって、冗長性を導入することもできるが、この複製のハンドリングは、高次レイヤ、例えば、ＲＡＮの外部で起こる。
ユーザプレーンにおけるＵＲＬＬＣイネーブラ
ＵＲＬＬＣサービスの運用では、すなわち、低レイテンシおよび高信頼性通信のプロビジョニングでは、Ｒｅｌ－１５でＬＴＥおよびＮＲの両方について、いくつかの特徴が導入されている。この特徴のセットは、ＵＲＬＬＣサポートの基礎を構成して、例えば、信頼性１～１０＾－５でレイテンシ１ｍｓをサポートしている。
説明されるＲＡＮ概念では、これらのＵＲＬＬＣ特徴をベースラインとして取り、レイヤ１およびレイヤ２の両方に開発された高度化を伴う。これらは、一方では、信頼性１～１０＾－６を伴うより厳格なレイテンシで信頼性ターゲット０．５ｍｓを遂行する目的を果たすが、他方では、より効率的なＵＲＬＬＣ運用、すなわち、システムキャパシティを改善することを可能にもしている。これらの高度化は、様々な（ほとんどは周期的）トラフィック特性の複数のサービスが、確定的なレイテンシでサービングされなければならないＴＳＮシナリオにも特に関連している。
このセクションでは、ユーザプレーンデータトランスポート用のＵＲＬＬＣイネーブラ、すなわち、レイヤ１およびレイヤ２特徴を説明する。これは、ＲＡＮからの５Ｇ ＴＳＮ統合をサポートするための、ＲＡＮ概念全体のうちの一部に過ぎず、制御プレーンおよびモビリティにおける信頼性、ならびに正確な時間参照プロビジョニングなどの、さらなる態様が検討される。
ほとんどの事例では、本明細書における主な説明はＮＲに基づいているが、一定の事例では、ＬＴＥ説明がベースラインとして与えられつつ、特徴は概念的にはＮＲにも適用可能であることに留意されたい。さらに以下では、特徴がＬＴＥ／ＮＲに指定されるかどうかを識別する表が与えられる。特徴が必要とされるかどうかは、レイテンシおよび信頼性の観点からの特定のＵＲＬＬＣ ＱｏＳの必要性次第である。さらには、特徴の一部は、ＵＲＬＬＣ自身のイネーブラとしてではなく、ＵＲＬＬＣ要件のより効率的な実現をシステムによって可能にするものと考えることができる。すなわち、キャパシティを高度化する特徴は、結果としてサービングすることができるＵＲＬＬＣサービスの数を増加させる。したがって、これらの特徴は、大まかには、低レイテンシのために必須の特徴、高信頼性のために必須の特徴としてグループ化することができ、他は以下の通りである。
低レイテンシのために必須の特徴：
・スケーラブル、および柔軟なヌメロロジー
・ミニスロットおよびショートＴＴＩ
・低レイテンシ最適化のダイナミックＴＤＤ
・高速処理時間および高速ＨＡＲＱ
・設定グラント（ＣＧ）を有するアップリンク上のプリスケジューリング（レイヤ２）；
高信頼性のために必須の特徴：
・低ＢＬＥＲターゲットのための低ＭＣＳおよびＣＱＩ
さらには、以下の特徴が同様に検討されている：
・ショートＰＵＣＣＨ：例えば、高速スケジューリング要求（ＳＲ）、およびさらに高速のＨＡＲＱフィードバック用
・ＤＬ プリエンプション：他のトラフィックが進行中である場合の、クリティカルなトラフィックの高速送信用
・ＤＬ制御高度化：ダウンリンク制御のさらに効率的でロバストな送信用
・マルチアンテナ技法：信頼性を改善すること
・スケジューリング要求およびＢＳＲ高度化：複数のトラフィックタイプのハンドリングのため
・ＰＤＣＰ複製：キャリア冗長性のため、すなわち、さらなる信頼性のため
以下の議論では、Ｒｅｌｅａｓｅ１５で指定されるようなこれらの特徴、Ｒｅｌｅａｓｅ１６に適切な高度化の説明、ならびにＲｅｌｅａｓｅ１６に適切な新しい特徴説明を、レイヤ１から始めてレイヤ２に続けてレビューする。
ユーザプレーンにおけるＵＲＬＬＣイネーブラ
ＮＲでは、スロットは、１４ＯＦＤＭシンボルに規定され、サブフレームは１ｍｓである。したがって、サブフレームの長さは、ＬＴＥにおける場合と同じであるが、ＯＦＤＭヌメロロジーに応じてサブフレーム当たりのスロット数は変化する。（用語「ヌメロロジー」は、キャリア間隔、ＯＦＤＭシンボル持続期間、およびスロット持続時間の組み合わせを指す。）６ＧＨｚ（ＦＲ１）を下回るキャリア周波数では、ヌメロロジー１５ｋＨｚおよび３０ｋＨｚのＳＣＳ（サブキャリア間隔）が、サポートされるが、６０ｋＨｚのＳＣＳは、ＵＥについては任意選択である。１５ｋＨｚのＳＣＳは、通常のサイクリックプレフィックス用のＬＴＥヌメロロジーに等しい。周波数範囲２（ＦＲ２）では、ヌメロロジー６０および１２０ｋＨｚのＳＣＳがサポートされる。これは、表８にまとめることができる。
Figure 0007241899000008
様々なヌメロロジーを使用する可能性は、ＮＲを広範囲の様々なシナリオに適合させる利点を有する。最小の１５ｋＨｚサブキャリア間隔は、ＬＴＥとの共存を簡略化し、長いシンボル持続時間、さらには長いサイクリックプレフィックス長を与え、これをラージセルサイズに適したものにしている。高いヌメロロジーは、大きな帯域幅を占有する利点を有しており、高データレートおよびビームフォーミングにより適し、より良好な周波数ダイバーシティを有し、ＵＲＬＬＣに重要なことに、短いシンボル持続時間による低レイテンシを有する。
したがって、送信時間が高ＳＣＳに対してより短いため、ヌメロロジー自身を、ＵＲＬＬＣのための特徴として考えることができる。しかしながら、限度ファクタとなり得る、ＰＤＣＣＨモニタリング、ＵＥ能力、およびＰＵＣＣＨ送信機会などの、スロット当たりのシグナリング限度を考慮する必要があり、これは高ＳＣＳではスロットベース当たりのＵＥの能力のほうが低いからである。
ＮＲは、ミニスロット用のサポートを提供する。ＮＲでサポートされるマッピングには２つのタイプがあり、ＰＤＳＣＨおよびＰＵＳＣＨ送信のタイプＡおよびタイプＢである。タイプＡは、通常スロットベースと称されるが、タイプＢ送信は、非スロットベースまたはミニスロットベースと称される場合がある。
ミニスロット送信は、動的にスケジューリングすることができ、Ｒｅｌｅａｓｅ１５では：
・ＤＬでは７、４、または２シンボル長であることができ、ＵＬではどのような長さであってもよい
・スロット内では、どのシンボルから開始および終了してもよい。
最終手段は、送信はスロット境界を超えることができないことを意味することに留意されたい。これはヌメロロジーとミニスロット長との一定の組み合わせでは複雑さを招く。
ミニスロットおよびショートＴＴＩ両方は、最大アラインメント遅延（送信機会を待機する時間）および送信持続時間を低減する。図５２から分かるように、最大アラインメント遅延および送信持続時間の両方は、ＴＴＩおよびミニスロット長が減少するにつれて線形に減少し、この図は、ミニスロットの使用からのレイテンシを「通常」１４ＯＦＤＭシンボルスロットと比較して示している。図５２の結果は、ダウンリンクＦＤＤの１ショット、１方向レイテンシに基づいており、能力２のＵＥ処理を想定している。一定の広範囲シナリオでは、高ヌメロロジーは適切ではなく（ＣＰ長が短くなり、チャネル時間のばらつきに対処するには十分ではないことがある）、ミニスロットの使用がレイテンシを低減するための主な方法である。
ミニスロットの欠点は、より頻度の高いＰＤＣＣＨモニタリングが割り振られる必要があることである。頻繁なモニタリングは、ＵＥには困難な場合があり、またそれ以外ではＤＬデータ用に使用することができるリソースを使い切る。ＮＲ Ｒｅｌ－１５では、設定可能な監視オケージョンの数は、スロットおよびＵＥが実施することができるサービングセル当たりのブラインド復号の最大数、ならびにスロットおよびサービングセル当たりの非オーバラップ制御チャネルエレメント（ＣＣＥ）の最大数によって限定される。
データシンボルのための効率を維持するために、ＤＭＲＳに使用されるリソースの割合が高いことに起因して、ミニスロットを伴う高Ｌ１オーバヘッドを期待することができる。ＯＦＤＭシンボルのごく一部がＤＭＲＳに使用される場合であっても、例えば、１スロットにつき、１４シンボルのうちの２シンボルではなく、４シンボルのうち１つのシンボルとなる可能性がある。
形式化された欠点に基づいて、ミニスロットに関連する以下の課題が、ＮＲ Ｒｅｌｅａｓｅ１６で対処されている：
・ミニスロット繰り返し（スロット境界をまたぐ繰り返しを含む）；
・ＤＭＲＳオーバヘッドの低減；
・高度化したＵＥモニタリング能力；
・ＵＥおよびｇＮｂにおける高速処理。
これらの課題に対するＲｅｌｅａｓｅ１６でのソリューションを、以下で説明する。
ミニスロットの繰り返しに関して、ＵＲＬＬＣトラフィックは非常にレイテンシにセンシティブであるため、ほとんどの関連する時間割り当て方法はタイプＢであり、この場合、１スロット内で任意のＯＦＤＭシンボルから送信を開始することができる。同時に、信頼性要件が、非常に保存的なリンク適応セッティングとなる可能性があり、よりＲＢを必要とする低ＭＣＳが選択され得る。周波数において広い割り当てを有する代わりに、ｇＮＢは、同時により多くのＵＥをスケジューリングすることを助けることができる、時間的に長い送信を割り当てるよう決めることができる。残念ながら、Ｒｅｌｅａｓｅ－１５ＮＲにおける制限のため、送信は、スロット境界でオーバラップすると時間的に遅延させる必要がある。この問題の図が、図５３に提示されており、これは、ＮＲ Ｒｅｌｅａｓｅ１５におけるスロット境界制限をまたぐ送信に起因する長いアラインメント遅延の図である。ここで、アラインメント遅延は、ＵＥが送信の準備ができた時間と、次スロットの始めにおいて送信が起こる時間との、２つの事象間の時間である。
ミニスロットの繰り返しを使用して、スロット境界をまたぐ送信のスケジューリングを可能にすることによって可能なレイテンシゲインを図示するために、１スロットにフィットするよう制約された送信のスケジューリングと比較した、平均レイテンシゲインに注目する。これを達成するためのミニスロットの繰り返しを使用する１つの方法が、図５４に図示されているが、他の方法も全体的に同じレイテンシを与える。
データパケットが１つのスロット内の任意のシンボルにおいて、ＵＥに到達する見込みが等しく高いと想定して、表９～表１１は、ＨＡＲＱベースの再送信を伴うＵＬ設定グラントを考慮して、送信持続時間と、境界をまたがないＳＣＳおよび境界をまたぐスケジューリングとの様々な組み合わせでの、最悪ケースのレイテンシをそれぞれ示している。１スロットには１４シンボルがあるため、典型的には非常に低いブロック誤り確率をターゲットにしており、データが最悪ケースのレイテンシを与えるシンボルに到達した場合に、レイテンシバウンドが達成され得ることを確実にする必要がある。能力２のＵＥ、およびｇＮＢ処理時間がＵＥにおける処理時間と同じであることを想定して、レイテンシを評価する。ｇＮＢは、処理時間の半分を復号に使用すると想定している。すなわち、トランスポートブロックが正しく復号される場合、処理時間の半分の時間の後、高次レイヤに送達され得る。ＨＡＲＱ再送信を許可することは、第１の送信において高いＢＬＥＲをターゲットとすることにより、使用されるリソース量をかなり下げる可能性があるため、再送信をスケジューリングするＰＤＣＣＨを送信するために必要な時間およびＰＵＳＣＨ再送信を準備するために必要な時間を考慮して、最初の送信、第１、第２、および第３のＨＡＲＱ再送信の後、レイテンシを評価する。あらゆる再送信が、最初の送信と同じ長さを使用すると想定する。
表９～表１４では、Ｒｅｌｅａｓｅ１５（スロット境界をまたがない送信）で達成可能なＨＡＲＱベースの再送信についての最悪ケースのレイテンシ、およびスロット境界をまたぐことができるようミニスロットの繰り返しを使用した場合の最悪ケースのレイテンシを示している。あらゆる繰り返しをカウントして、ＳＣＳ＝１５、３０、または１２０ｋＨｚ、および合計ＰＵＳＣＨ長２～１４シンボルを考える。すなわち、２シンボルのミニスロットを４回繰り返す場合、表では８送信長として表される。表を解釈しやすくするために、ターゲットレイテンシは、それぞれ０．５、１、２、および３ｍｓに注目している。ミニスロットの繰り返しを使用して最悪ケースのレイテンシを示す表では、網掛けしたケースは、これらのターゲットレイテンシバウンドのうちの１つが、ミニスロットの繰り返しを使用して満足することができるが、Ｒｅｌｅａｓｅ１５を使用すると達成することができないケースを示している。
Figure 0007241899000009
Figure 0007241899000010
Figure 0007241899000011
Figure 0007241899000012
Figure 0007241899000013
Figure 0007241899000014
Ｒｅｌｅａｓｅ１５のスケジューリングと比較して、以下のゲインに達することが可能である：
・０．５ｍｓのレイテンシバウンドでは、ミニスロットの繰り返しを使用してさらに５ケースが可能となる。ゲインは、３０および１２０ｋＨｚのＳＣＳについて最初の送信で発生する。
・１ｍｓのレイテンシバウンドでは、ミニスロットの繰り返しを使用してさらに６ケースが可能となる。ゲインは、１５および３０ｋＨｚのＳＣＳについて最初の送信で起こる。
・２ｍｓのレイテンシバウンドでは、ミニスロットの繰り返しを使用してさらに１１ケースが可能となる。ゲインは、１５、３０、または１２０ｋＨｚのＳＣＳについて最初の送信、第１、または第２の再送信で発生する。
・３ｍｓのレイテンシバウンドでは、ミニスロットの繰り返しを使用してさらに７ケースが可能となる。ゲインは、１５または３０ｋＨｚのＳＣＳについて第２、または第３の再送信で発生する。
ＵＬにおけるミニスロットの繰り返しは、他の特徴と一緒に使用することが可能であり、一定のパターンに従った周波数ホッピングまたは繰り返しをまたぐプリコーダサイクリングなど、より高い信頼性を可能にしている。
ＰＵＣＣＨ高度化には、ショートＰＵＣＣＨの使用が含まれる。ＤＬデータ送信のために、ＵＥはＨＡＲＱフィードバックを送信してデータの正しい受信を肯定応答（ＡＣＫ）する。ＤＬデータパケットが正しく受信されない場合、ＵＥはＮＡＣＫを送信し、再送信を期待する。ＵＲＬＬＣの厳密なレイテンシ制約のため、１～２シンボルを有するショートＰＵＣＣＨフォーマット（例えば、ＰＵＣＣＨフォーマット０）は、関連性が高いと期待される。ショートＰＵＣＣＨは、スロット内の任意のＯＦＤＭシンボルで開始するように設定することができるため、ＵＲＬＬＣに適切な高速のＡＣＫ／ＮＡＣＫフィードバックが可能となる。しかしながら、ＨＡＲＱフィードバックの低レイテンシと高信頼性の間にはトレードオフが存在する。より多くの時間リソースが利用可能である場合、４～１４シンボルの持続時間を有することができるロングＰＵＣＣＨフォーマットを考慮することがやはり有益である。時間が長いリソースを使用することで、ＰＵＣＣＨ信頼性を高度化することが可能である。
別の高度化は、ＰＵＳＣＨでのＵＣＩマルチプレクシングである。ｅＭＢＢとＵＲＬＬＣとの混合型サービスを実行するＵＥの場合、ＰＵＳＣＨで送信されるＵＣＩに対する信頼性要件は、ＰＵＳＣＨデータとは著しく異なることができる。ＵＣＩに対する信頼性要件は、例えばＤＬ ＵＲＬＬＣデータについてのＨＡＲＱ－ＡＣＫをｅＭＢＢデータと同時に送信する時は、ＰＵＳＣＨデータに対する要件より高くしてもよく、または例えばｅＭＢＢを対象とするＣＱＩレポートをＵＲＬＬＣデータと同時に送信する場合、要件より低くしてもよい。ＵＣＩがＰＵＳＣＨデータよりも低い要件を有するケースでは、ＵＣＩの一部またはすべてをドロップすることが好ましい場合がある。
ＵＣＩとＰＵＳＣＨデータとの間の符号化オフセットは、ＵＣＩの様々なタイプ（ＨＡＲＱ－ＡＣＫ、ＣＳＩ）についてのベータファクタを通じて制御される。１．０より大きなオフセットは、対応するＵＣＩがデータよりも確実に符号化されることを意味している。Ｒｅｌｅａｓｅ１５で規定されるベータファクタは、最低値１．０を有する。この値は、ｅＭＢＢ ＵＣＩと共にＵＲＬＬＣデータを考慮する場合、十分に低くない場合がある。より良好なソリューションは、ＵＲＬＬＣ信頼性を確実にするようＰＵＳＣＨでＵＣＩを省略することを可能にする特殊なベータファクタ値の導入であろう。この手法が図５５に図示されており、この図は、ＵＣＩ送信を「省略」するための、ＤＣＩ信号におけるベータファクタの使用を示している。関連する問題は、ＵＲＬＬＣミニスロット送信用のスケジューリング要求（ＳＲ）が、スロットベースの送信の間、いつ来るかである。この問題は、以下でさらに分析する。
他の高度化は、電力制御の領域にある。ＵＣＩがＰＵＣＣＨで送信される時、信頼性要件は、ＵＣＩがｅＭＢＢまたはＵＲＬＬＣ／ｅＵＲＬＬＣに関連する場合、著しく異なる場合がある。フォーマット０およびフォーマット１では、ＰＲＢの数は１に等しく、より多くのＰＲＢを使用することによって信頼性を向上させる試みは、時間のばらつきに対してＰＵＣＣＨをセンシティブにする。したがって、フォーマット０およびフォーマット１では、異なる数のシンボルおよび／または電力調節により、異なる信頼性が達成される可能性がある。
シンボルの数は、フィールド「ＰＵＣＣＨリソースインジケータ」を使用して、ダウンリンクＤＣＩにおいて動的に示され得、２つのＰＵＣＣＨリソースが異なる数のシンボルで規定される。しかしながら、電力調節は、単一のＴＰＣテーブルに限定され、および／または場合によっては複数の電力セッティング（Ｐ０など）と最大２つまでの閉じられたコンポーネントが規定され得るＰＵＣＣＨ空間関連情報を使用する。しかし、異なるＰＵＣＣＨ電力セッティングは、ＭＡＣ ＣＥシグナリングを使用して選択することだけが可能である。これは、２つの連続的なＰＵＣＣＨ送信機会の間に、送信されるＨＡＲＱ－ＡＣＫが、ｅＭＢＢへの関連からＵＲＬＬＣ／ｅＵＲＬＬＣへの関連に変わる可能性がある混合型のサービスシナリオでは、明らかに遅すぎる。この問題に対するソリューションとして、ＰＵＣＣＨ電力制御高度化を、ＮＲ Ｒｅｌｅａｓｅ１６に導入して、ｅＭＢＢに関連するＰＵＣＣＨ送信とＵＲＬＬＣに関連するＰＵＣＣＨ送信との間での、より大きな電力差を可能にすることができる：
・大きな電力調節ステップを可能にする新しいＴＰＣテーブル、および／または
・ＤＣＩインジケーションを使用する電力セッティングの動的なインジケーション（例えば、Ｐ０、閉ループインデックス）
さらなる高度化はＨＡＲＱ－ＡＣＫ送信機会に関する。タイトなレイテンシ要件のあるＵＲＬＬＣでは、ミニスロットベースのＰＤＳＣＨ送信を用いる時に１スロット内にいくつかの送信機会を有する必要があり、そのため１スロット内のＰＵＣＣＨについてのＨＡＲＱ－ＡＣＫレポーティング用のいくつかの機会も必要となる。Ｒｅｌｅａｓｅ１５では、１スロット当たりサポートされるのは、ＨＡＲＱ－ＡＣＫを含め、せいぜい１ＰＵＣＣＨ送信である。これは、ＨＡＲＱ－ＡＣＫを送信するためのアラインメント時間を増加させるため、ＤＬデータレイテンシとなる。特に、ｅＭＢＢとＵＲＬＬＣトラフィックのマルチプレクシングがダウンリンクでサポートされる場合、ダウンリンクのデータレイテンシを低減するためには、１スロット内のＨＡＲＱ－ＡＣＫ送信用のＰＵＣＣＨ機会の数を増やすことが必要である。ＵＥ処理能力は、ＰＤＳＣＨ送信の終わりから、ＰＵＣＣＨにおける対応するＨＡＲＱ－ＡＣＫ送信の始めまでのＯＦＤＭシンボルの最小数を与えるが、ＨＡＲＱ－ＡＣＫの実際の送信時間は、スロット内のＰＵＣＣＨで許可される数によってさらに限定される。
Ｒｅｌｅａｓｅ１５では、ＵＥは、各ＰＵＣＣＨリソースセットが複数の数ＰＵＣＣＨリソースから成る最大４ＰＵＣＣＨリソースセットで設定することができ、ＨＡＲＱ－ＡＣＫビットを含む、設定によって設けられる範囲のＵＣＩサイズに使用することができる。第１のセットは、ＨＡＲＱ－ＡＣＫ情報を含む１～２ＵＣＩビットにだけ適用可能であり、最大３２ＰＵＣＣＨリソースを有することができるが、他のセットは、設定されていれば、ＨＡＲＱ－ＡＣＫを含む２つよりも多いＵＣＩビットに使用され、最大８ＰＵＣＣＨリソースを有することができる。ＵＥがＰＵＣＣＨに関するＨＡＲＱ－ＡＣＫをレポートすると、ＰＵＣＣＨ送信用の同じスロットを示しているＰＤＳＣＨ－ＨＡＲＱフィードバックタイミングインジケータの値を有する、最後のＤＣＩフォーマット１＿０またはＤＣＩフォーマット１＿１のＨＡＲＱ－ＡＣＫ情報ビット数およびＰＵＣＣＨリソースインジケータフィールドに基づいてＰＵＣＣＨリソースセットが決定される。ＰＵＣＣＨリソースセットのサイズが最大でも８である場合、ＰＵＣＣＨリソース識別情報は、ＤＣＩのＰＵＣＣＨリソースインジケータフィールドによって、明示的に示される。ＰＵＣＣＨリソースセットのサイズが８よりも大きい場合、ＰＵＣＣＨリソース識別情報は、ＤＣＩのＰＵＣＣＨリソースインジケータフィールドに加え、ＰＤＣＣＨ受信用の第１のＣＣＥのインデックスによって決定される。
タイトなレイテンシ要件のあるＵＲＬＬＣでは、ＰＤＳＣＨ送信用のスロット内でいくつかの送信機会を有する必要があり、そのため先に言及したように、１スロット内のＰＵＣＣＨについてのＨＡＲＱ－ＡＣＫレポーティング用のいくつかの機会も必要となる。
これは、ＵＥが、１スロット内で複数のＨＡＲＱ－ＡＣＫ送信の機会の可能性を有効にするために、いくつかのＰＵＣＣＨリソースで設定される必要があるが、これらのうちの１つだけがそれぞれのスロットで使用され得ることを意味している。例えば、ＵＲＬＬＣサービスを実行中のＵＥは、ＰＤＣＣＨを１秒ごとのＯＦＤＭシンボル、例えば、シンボル０、２、４、・・・、１２で、およびＨＡＲＱ－ＡＣＫ送信用のＰＵＣＣＨリソースをやはり１秒ごとのシンボル、例えば、１、３、・・・、１３で受信する可能性を伴って設定することができる。これは、所与のＵＣＩサイズ範囲のＵＲＬＬＣについてレポーティングするＨＡＲＱ－ＡＣＫのためだけに、ＵＥが７ＰＵＣＣＨリソースのセットで設定される必要があることを意味している。他の必要性のために、他のＰＵＣＣＨリソースを有する必要性がある可能性があるため、ＤＣＩのＰＵＣＣＨリソースインジケータによって明示的に示され得る最大でも８ＰＵＣＣＨリソースのリストが、越えられる可能性がある。１～２ＨＡＲＱ－ＡＣＫビットのケースにおいて、セットに８よりも多いＰＵＣＣＨリソースがある場合、第１のＣＣＥのインデックスは、どのＰＵＣＣＨリソースが示されるかを制御する。したがって、ＤＣＩを送信することができる場所を、意図したＰＵＣＣＨリソースを参照することができるように限定することができる。結果的に、これはＤＣＩを送信することができるスケジューリング制限を課す場合があり、ＤＣＩを所望のＣＣＥに送ることができない（そのＣＣＥが既に他のＵＥに使用されているため）場合「ブロッキング」を起こす場合もある。したがって、上の例では７ＰＵＣＣＨリソースを設定する代わりに、１ＰＵＣＣＨリソースには、１ロットに２シンボルごとの送信機会の周期性があると想定することができる。この手法が、図５６に図示されているが、この図は、２ＯＦＤＭシンボルの周期（Ｐ）を有する１ＯＦＤＭシンボル（すなわち、Ｎｓ＝１）を占有するショートＰＵＣＨＨを示している。この場合、１つのスロットには合計で７つの周期的なＰＵＣＣＨリソースが規定される。
上述のソリューションおよび問題は、ＦＤＤならびにＴＤＤに当てはまる。しかしながら、スロットのＵＬ部分だけがＰＵＣＣＨリソースを含むことができるため、固定された「ミニスロット」ＴＤＤパターンについては明示的に示され得る８ＰＵＣＣＨリソースで十分な場合がある。
ＰＤＣＣＨ高度化に関して、ＵＲＬＬＣ用の高信頼性要件では、ダウンリンク制御情報（ＤＣＩ）の送信が、十分に信頼できることが重要である。改善されたＵＥ／ｇＮＢハードウェア能力、高度化されたｇＮＢ／ＵＥ実装形態、および良好なＮＲ ＰＤＤＣＨ設計選択を含むいくつかの手段によって、これを達成することができる。
設計選択の点では、ＮＲ ＰＤＣＣＨは、信頼性を高度化することができるいくつかの特徴を含む。これらには、以下が含まれる：
・ビームフォーミングの使用を可能にするＤＭＲＳベースであること；
・周波数の分散送信スキームのサポート；
・アグリゲーションレベル１６；
・ＣＲＣ長の増大（２４ビット）。
ＮＲは、２つの主なＤＣＩフォーマット、すなわち、通常サイズのＤＣＩフォーマット０－１および１－１、ならびに小さなサイズのフォールバックＤＣＩフォーマット０－０および１－０をサポートする。スケジューリングの柔軟性は限定されている可能性があるが、所与のアグリゲーションレベル用の低い符号化レートによるＰＤＣＣＨロバスト性を得るべく、データのスケジューリングのためにフォールバックＤＣＩを考慮することが、やはり妥当な場合がある。その上、通常のＤＣＩは、帯域幅部分インジケータ、ＣＢＧ関連フィールド、および第２のＴＢ関連フィールドなどの、ＵＲＬＬＣに関連性のない、いくつかのフィールドを含むことに留意されたい。
１つの可能な高度化は、ＵＲＬＬＣ特有のＤＣＩフォーマットである。アグリゲーションレベル（ＡＬ）およびＤＣＩサイズの両方は、ＰＤＣＣＨパフォーマンスにインパクトを有する可能性がある。アグリゲーションレベルは、異なるチャネル符号化レートを有しており、ＰＤＣＣＨ用にリンク適応で用いられるが、ＤＣＩペイロードサイズは、設定された接続についてはむしろ固定されている。ＰＤＣＣＨ送信をよりロバストにするために、高ＡＬおよび／または小ＤＣＩペイロードサイズを使用してＰＤＣＣＨ符号レートを低くすることができる。様々なＤＣＩサイズ同士のＰＤＣＣＨパフォーマンス比較を、表１５に要約する。ここで、ＤＣＩサイズ４０ビットは、Ｒｅｌｅａｓｅ１５フォールバックＤＣＩサイズ用の基準として機能するが、ＤＣＩサイズ３０および２４は、コンパクトＤＣＩサイズと称される場合もある。ＤＣＩサイズが４０から２４ビットに減少させる際のゲインは、特に高ＡＬで小さく、ゲインは、ＤＣＩサイズを４０から３０ビットに減少させる場合、なお小さいことが分かる。ゲインは、本質的に符号レート減少のレベルに依存する。
Figure 0007241899000015
ＵＲＬＬＣ用の高信頼性要件では、ダウンリンク制御情報（ＤＣＩ）の送信が、十分に信頼できることが重要である。改善されたＵＥ／ｇＮＢハードウェア能力、強化されたｇＮＢ／ＵＥ実装形態、および良好なＮＲ ＰＤＤＣＨ設計選択を含むいくつかの手段によって、これを達成することができる。
設計選択の点では、ＮＲ ＰＤＣＣＨは、信頼性を高度化することができるいくつかの特徴を含む。これらには、以下が含まれる：
・ビームフォーミングの使用を可能にするＤＭＲＳベースであること；
・周波数の分散送信スキームのサポート；
・アグリゲーションレベル１６；
・ＣＲＣ長の増大（２４ビット）。
ＮＲは、２つの主なＤＣＩフォーマット、すなわち、通常サイズのＤＣＩフォーマット０－１および１－１、ならびに小さなサイズのフォールバックＤＣＩフォーマット０－０および１－０をサポートする。スケジューリングの柔軟性は限定されている可能性があるが、所与のアグリゲーションレベル用の低い符号化レートによるＰＤＣＣＨロバスト性を得るべく、データのスケジューリングのためにフォールバックＤＣＩを考慮することが、やはり妥当な場合がある。その上、通常のＤＣＩは、帯域幅部分インジケータ、ＣＢＧ関連フィールド、および第２のＴＢ関連フィールドなどの、ＵＲＬＬＣに関連性のない、いくつかのフィールドを含むことに留意されたい。
ＵＲＬＬＣ ＵＥが良好なチャネル条件で動作する場合、ＰＤＣＣＨでは低ＡＬを使用することが妥当である。良好なチャネル条件のより多くのＵＥが低ＡＬを使用することができるため、コンパクトなＤＣＩがＰＤＣＣＨマルチプレクシングキャパシティに対してポジティブなインパクトを有し、それによりブロッキング確率が低減されることが主張された。これをチェックするため、コンパクトなＤＣＩをＰＤＣＣＨブロッキング確率に対して使用することのインパクトを、ＤＣＩサイズ、ＵＥの数、およびＣＯＲＥＳＥＴリソースの関数として調べる。１つのセル内のＵＲＬＬＣ ＵＥの数は、４～１０と考える。ＣＯＲＥＳＥＴリソースは、ＣＯＲＥＳＥＴ持続時間および帯域幅に基づいて決定される。ＣＯＲＥＳＥＴは、４０ＭＨｚのＢＷで、１または２ＯＦＤＭシンボルを占有すると想定される。
図５７は、ＤＣＩサイズ、ＵＥの平均数、およびＣＯＲＥＳＥＴサイズの関数として、監視オケージョン当たりのブロッキング確率を示している。シミュレーション想定は、Ｒｅｌｅａｓｅ１５対応のユースケースについてのものである。図５７から、監視オケージョン当たりのＰＤＣＣＨブロッキング確率は、ＤＣＩサイズ、ＵＥの数、およびＣＯＲＥＳＥＴサイズなど、いくつかのパラメータに依存することが分かる。所与の数のＵＥについてのブロッキング確率改善の点では、小さなＤＣＩサイズを使用することが、大きな制御リソースを使用することと比較してずっと小さなゲインを与えることが明白である。
追加的に、ＵＥにおける復調および復号の複雑さの制約に起因して、ＵＥがスロット当たり監視するべきＤＣＩサイズの数にはバジェット、すなわち、Ｃ－ＲＮＴＩによってスクランブルされるＤＣＩに３つの異なるサイズ、Ｒｅｌｅａｓｅ１５で合意されるように、他のＲＮＴＩに追加的に１つであるバジェットが存在する。そのため、別のＤＣＩフォーマットを小さなサイズで導入することは、ＤＣＩサイズの限定を満足するためには、よりずっと困難となる。
Ｒｅｌｅａｓｅ１６におけるＰＤＣＣＨ高度化についてのコンパクトなＤＣＩに対する代替を、検討することができる。ＮＲ Ｒｅｌｅａｓｅ１５では、ユニキャストデータスケジューリング用に、２つの主なＤＣＩフォーマット、すなわち、フォールバックＤＣＩフォーマット０－０／１－０、および通常のＤＣＩフォーマット０－１／１－１がある。フォールバックＤＣＩは、ＤＣＩサイズが帯域幅部分のサイズに依存する、リソース割り当てタイプ１をサポートする。これは、柔軟性が限定されている、例えばマルチアンテナ関連のパラメータを持たない、単一のＴＢ送信が意図されている。他方では、通常のＤＣＩは、マルチレイヤ送信を伴う柔軟なスケジューリングを提供することができる。
ＵＲＬＬＣの高信頼性要件のため、良好なＰＤＣＣＨパフォーマンスのためには、小さなサイズのフォールバックＤＣＩを使用することが有益であることが分かる。同時に、高信頼の送信をサポートするために、マルチアンテナ関連のパラメータなどの、パラメータを有することが有益な可能性がある。これは、フォールバックＤＣＩと同じサイズを有するが、フォールバックＤＣＩから改善された新しいＤＣＩフォーマットが、いくつかの有用なフィールド、例えば、通常ＤＣＩ内に存在するがフォールバックＤＣＩには存在しない、いくつかのフィールドにおいてスワップするように動機付けすることができる。新しいＤＣＩフォーマットに既存のＤＣＩフォーマットと同じサイズを持たせることにより、ブラインド復号の複雑さを同じに保つことができる。この使用はＵＲＬＬＣに限定されなくてもよいことに留意されたい。妥当なスケジューリング柔軟性を伴う高ＰＤＣＣＨ信頼性を必要とするあらゆるユースケースは、同様に新しいＤＣＩフォーマットを活用できるべきである。
改善されたパフォーマンスについての別の領域が、ブラインド復号およびＣＣＥの数に対する限度に関連する。上で議論したように、ＰＤＳＣＨ／ＰＵＳＣＨマッピングタイプＢ（柔軟な開始位置でのミニスロット）は、ＵＲＬＬＣユースケースのためのキーとなるイネーブラである。タイプＢスケジューリングの十分なレイテンシ利点を達成するために、１スロット内に、複数のＰＤＣＣＨ監視オケージョンを有することが必須である。例えば、２ＯＦＤＭシンボル送信の十分な利点を得るためには、２ＯＦＤＭシンボルごとにＰＤＣＣＨ監視を有することが好ましい。スロット内のチャネル推定用のブラインド復号（ＢＤ）および非オーバラップＣＣＥの総数に対するＲｅｌｅａｓｅ１５における限度は、検索空間で候補数を限定する場合でも、これらの種類の設定についてのスケジューリングオプションを強く制限する。
ＮＲにおける１５ｋＨｚのＳＣＳ用の現在の限度は、ＬＴＥにおける１ｍｓ ＴＴＩ用の限度と一致するが、これらの限度は、ＬＴＥにショートＴＴＩが導入された後に拡張された。表９および表１０の第１行目に示されるような、これらのＲｅｌｅａｓｅ１５の限度は、ＵＲＬＬＣフレームワークの範囲内でＮＲのＲｅｌｅａｓｅ１６で改版されることが期待できる。例えば、現在のＣＣＥの限度数では、ＡＬ１６が使用される場合、スロット当たり最大３送信機会しかない。
複数の新しいＵＥ能力レベルを指定するのではなく、Ｒｅｌｅａｓｅ１５と比べて数が倍になる、ＰＤＣＣＨブラインド復号用に１つの追加的なレベルのサポートを指定することが提案される。この追加的なレベルのサポートには、スロットベースごとに単純に規定するのではなく、ＢＤ／ＣＣＥがミニスロット動作のためにスロット内でどのように分散されるかを考慮するほうが、理にかなっている。１つの可能な選択は、スロットの半分ごとにＢＤ／ＣＣＥ限度を規定することである。スロットの前半分は、他のケースと同じ数を想定することが自然である。スロットの後ろ半分では、ＵＥがスロットの前半分でＰＤＣＣＨの処理を終えていると想定すると、ＵＥは、スロットの後ろ半分において、同一のＰＤＣＣＨ処理能力を有するはずである。したがって、最初のスロットと同じ数を想定することが妥当である。
上のすべてを考慮して、ＢＤ限度における対応する増大を、表１６に要約することができる。
Figure 0007241899000016
同様に、ＣＣＥ限度における対応する増大を、表１７に要約することができる。
Figure 0007241899000017
表１６および表１７に対する代替的なソリューションとして、スライディングウインドウごとに限度を導入することを検討することができ、スライディングウインドウサイズおよびウインドウ当たりのブラインド復号またはＣＣＥの数は、仕様でさらに規定することができる。
ブラインド復号およびＣＣＥ限度の数を増加させる結果は、１スロット内のＰＤＣＣＨ機会が多くなることであり、それによりＵＥは、結果的にスケジューリングされるチャンスが多くなる。表１８は、セル当たり異なる数のＵＥについての、一定数のＰＤＣＣＨ機会の後のＰＤＣＣＨブロッキング確率を示している。（ＤＣＩサイズ＝４０ビット、ＣＯＲＥＳＥＴ持続時間＝１シンボル。）ＰＤＣＣＨ機会が多くなると、１スロット内のＰＤＣＣＨブロッキング確率が著しく低減され得ることが明白である。
Figure 0007241899000018
ＰＤＣＣＨに対する限度がアラインメント遅延を改善することができる一方、処理遅延低減が合計のレイテンシの減少に対して追加的に寄与できる。したがって、ＵＥ処理能力は、以下のように対処される。
図５８には、１再送信の場合の、ダウンリンクデータ送信のタイムラインが図示されている。図５９には、１再送信の場合の、設定ＵＬグラントを介するＰＵＳＣＨについてのＵＬデータ送信のタイムラインが図示されている。遅延コンポーネントは以下の通りである：
・ＴＵＥ，ｐｒｏｃ：ＵＬ送信についてのＵＥ処理時間。ＴＵＥ，ｐｒｏｃは、ＤＬデータｖｓＵＬデータ、最初の送信ｖｓ再送信などに応じて変化する。ＵＥ能力＃１およびＵＥ能力＃２の議論では、変数Ｎ１およびＮ２が使用される：
〇Ｎ１は、ＵＥの観点から、ＵＥが、ＰＤＳＣＨの終わりから、ＰＵＳＣＨまたはＰＵＣＣＨ上の対応するＡＣＫ／ＮＡＣＫ送信の最も早い可能な開始までを処理するために必要とされるＯＦＤＭシンボルの数である。
〇Ｎ２は、ＵＥの観点から、ＵＥが、ＵＬグラント受信を含むＰＤＣＣＨの終わりから、対応する同じＰＵＳＣＨ送信の最も早い可能な開始までを処理するために必要とされるＯＦＤＭシンボルの数である。
・ＴＵＬ，ｔｘ：ＵＬデータの送信時間。これは、概ねＰＵＳＣＨ持続時間に等しい。
・ＴＵＬ，ａｌｉｇｎ：次のＵＬ送信機会を待機する時間アラインメント。
・ＴｇＮＢ，ｐｒｏｃ：ＤＬ送信用のｇＮＢ処理時間。ＴｇＮＢ，ｐｒｏｃは、ＤＬデータｖｓＵＬデータ、最初の送信ｖｓ再送信などに応じて変化する。例えば、ＰＤＳＣＨ再送信では、これにはＵＬで送信されるＨＡＲＱ－ＡＣＫの処理時間が含まれる。ＰＵＳＣＨでは、これにはＰＵＳＣＨの受信時間が含まれる。
・ＴＤＬ，ｔｘ：ＤＬデータの送信時間。これは、概ねＰＤＳＣＨ持続時間に等しい。
・ＴＤＬ，ａｌｉｇｎ：次のＤＬ送信機会を待機する時間アラインメント。
ＴＵＥ，ｐｒｏｃは、改善すべき重要なレイテンシコンポーネントである。Ｒｅｌｅａｓｅ１５では、ＵＥ処理時間能力＃１および＃２が規定されており、能力＃１は１５／３０／６０／１２０ｋＨｚのＳＣＳ用に規定されており、能力＃２は１５／３０／６０ｋＨｚのＳＣＳ用に規定されている。よりアグレッシブな能力＃２は、１ｍｓレイテンシ制約には、まだ不適切である。ｅＵＲＬＬＣ向けのレイテンシ要件が１ｍｓのオーダ（例えば、０．５ｍｓ）であるため、レイテンシ要件を遂行するために、新しいＵＥ能力＃３を、Ｒｅｌｅａｓｅ１６ ＮＲで規定することができる。提案されるＵＥ能力＃３を、表１９に要約する。提案される能力のインパクトを、図６０、図６１および図６２に見ることができる。図６０は、表１９に示したＲｅｌｅａｓｅ１５と新しいＵＥ能力＃３との間のダウンリンクデータレイテンシの比較を示している。図６１は、Ｒｅｌｅａｓｅ１５でのグラントベースのアップリンクデータレイテンシと、新しいＵＥ能力＃３との間の比較を示している。図６２は、Ｒｅｌｅａｓｅ１５と新しいＵＥ能力＃３との間の、設定グラントアップリンクのレイテンシの比較を示している。
Figure 0007241899000019
別の遅延コンポーネントＴＤＬ，ａｌｉｇｎは、ＰＤＣＣＨ周期性によって著しく影響を受ける。最悪ケースＴＤＬ，ａｌｉｇｎは、ＰＤＣＣＨ周期性に等しい。Ｒｅｌｅａｓｅ１５では、ＰＤＣＣＨ周期性は、以下を含むいくつかの制約によって影響される：（ａ）ブラインド復号限度、（ｂ）＃ＣＣＥ限度）、（ｃ）ＤＣＩサイズ。ｅＵＲＬＬＣに、より短いＰＤＣＣＨ周期性を提供するために、ブラインド復号限度およびＣＣＥ限度の数が、Ｒｅｌｅａｓｅ１６では緩和されることが必須である。
別の重要なＵＥ能力は、ＣＳＩレポート生成の時間に関連する。ＵＥがＣＳＩレポートを提供するのが速いほど、リンク適応の観点から、スケジューリング決定がより正確になる。Ｒｅｌｅａｓｅ１５仕様では、２つのキーとなる値が規定される：
・Ｚは、ＰＤＣＣＨのトリガから、ＣＳＩレポートを搬送するＰＵＳＣＨの開始までのタイミング要件に対応し、そのため、これはＤＣＩ復号化時間、可能なＣＳＩ－ＲＳ測定時間、ＣＳＩ計算時間、ＵＣＩ符号化時間、ならびに可能なＵＣＩマルチプレクシングおよびＵＬ－ＳＣＨマルチプレクシングを包含するべきである。
・他方では、Ｚ’は（もし、使用されていれば）非周期的なＣＳＩ－ＲＳからレポートを搬送するＰＵＳＣＨの開始までのタイミング要件に対応する。
したがって、ＺとＺ’との差は、単にＤＣＩ復号化時間である。
Ｒｅｌｅａｓｅ１５では、「高度ＣＳＩ処理能力」が存在しない。すなわち、すべてのＵＥがサポートしなければならないと規定されるベースラインＣＳＩ処理能力しかない。Ｒｅｌｅａｓｅ１５に、そのような高度ＣＳＩ処理能力を含めるための議論があったが、時間不足によって含められなかった。
ＣＳＩコンテンツ向けに、Ｒｅｌｅａｓｅ１５では３つの「レイテンシクラス」が規定される。
・ビームレポーティングクラス：ＣＲＩ／ＳＳＢＲＩを用いるＬ１－ＲＳＲＰレポーティング
・低レイテンシＣＳＩ：ＴｙｐｅＩの単一のパネルコードブックまたは非ＰＭＩレポーティングモードのいずれかを使用する、最大４ＣＳＩ－ＲＳポートを伴う（ＣＲＩレポーティングを伴わない）単一のワイドバンドＣＳＩレポートとして規定される。
・高レイテンシＣＳＩ：他のすべてのタイプのＣＳＩコンテンツ
これらの３つのクラスのそれぞれで、（Ｚ，Ｚ’）に対して異なる要件が規定される（ＣＳＩ計算遅延要件２に従う）。より厳格なＣＳＩ要件である、ＣＳＩ計算遅延要件１も存在し、これは、ＵＬ－ＳＣＨまたはＵＣＩマルチプレクシングなしに、またＵＥが有するすべてのＣＳＩ処理ユニットが占有されていない（すなわち、他の何らかのＣＳＩレポートが、まだ計算されていない）場合に、ＵＥが単一の低レイテンシＣＳＩレポートでトリガされた場合にのみ適用される。
ＮＲ Ｒｅｌｅａｓｅ１５では、必須のＵＥ ＣＳＩ処理能力は、ＵＥが５つ同時のＣＳＩレポートの計算をサポートすることを必要とする（これは、同じキャリア内、または複数のＣＳＩ－ＲＳリソースでの単一のレポートとして、様々なキャリアにまたがる可能性がある）。値（Ｚ，Ｚ’）は、ＣＳＩ処理要件２であり、すべてのＵＥがこのタイムフレーム内に５つのＣＳＩレポートを計算できるべきであると定められている。いくつかのＵＥ実装形態は、複数のＣＳＩレポートを連続して計算するため、これは、大まかに説明すると、ＣＳＩ要件２は、単一のＣＳＩレポートだけを計算する必要がある要件の場合よりも約５倍長くなることを意味している。
典型的なＵＲＬＬＣシナリオでは、また実際、多くの典型的なデプロイメントおよびシナリオでは、ｇＮＢはその時の単一のＣＳＩレポートをトリガすることにしか興味がない。したがって、この場合、タイミング要件があるべきよりも５倍長いことは、少し残念である。データのトリガおよびＨＡＲＱ－ＡＣＫ遅延（Ｋ１）要件までのデータのためのＮ２要件がＣＳＩ処理要件よりもずっと低いため、この過剰に長いＣＳＩ計算時間は、追加的な実装制約をスケジューラに課す。
さらなる改善が可能である。ｅＵＲＬＬＣのためのＣＳＩ処理タイムラインの高度化には、ｇＮｂにおけるチャネル状態を素早く得る目的で、新しいＣＳＩタイミング要件の導入（「ＣＳＩ計算遅延要件３」）が、散発的なトラフィックに有益である。ＵＥが単一のＣＳＩレポートでトリガされると、求められる可能性がある。開始位置は、ＣＳＩタイミング要件２に規定された値を取り、ファクタ５で除算される場合がある。別の可能なＣＳＩ処理タイムライン高度化は、高度ＣＳＩ処理能力を導入することである。すなわち、２つの既存のＣＳＩタイミング要件（ならびに提案したばかりの第３のもの）のためのテーブルの新しいセットを導入することである。この時、ＵＥは、ＰＤＳＣＨ／ＰＵＳＣＨ用の高度処理能力と同様に、よりアグレッシブなＣＳＩタイムラインをサポートすることであるその能力を示すことができる。
高速なＨＡＲＱは、別の改善である。前セクションで議論した高速処理およびＵＥ能力により、より速いＨＡＲＱ再送信が可能となる。ｇＮＢが、ＵＥと類似する処理速度で動作できると想定する。ＨＡＲＱ再送信で動作して、レイテンシを低く保つためには、頻繁なＰＤＣＣＨ監視オケージョンだけでなく、ＨＡＲＱ－ＡＣＫを送信することができるＰＵＣＣＨ機会も必要である。簡略化の理由のため、現実には想定できないがゼロタイミングアドバンスを想定することになる。非ゼロタイミングアドバンスを用いると、レイテンシ値は変化する。
ここで、Ｒｅｌｅａｓｅ１５とＲｅｌｅａｓｅ１６との比較に注目することができる。評価結果を、以下に示す。Ｒｅｌｅａｓｅ１５の能力＃２では、ＰＤＣＣＨ周期性を５ＯＦＤＭシンボル（ｏｓ）と想定する。スロット当たりのＣＣＥ限度を５６として、スロット当たり最大３ＰＤＣＣＨ監視オケージョンが可能となり、この場合、各オケージョンが少なくとも１つのＡＬ１６候補を含むことに留意されたい。Ｒｅｌｅａｓｅ１６では、改善された値Ｎ１およびＮ２（前セクションで議論された能力＃３）、およびブラインド復号とＣＣＥの数の限度に対する潜在的な改善の結果としてのＰＤＣＣＨ周期性２シンボルを想定する。
ＵＥ間プリエンプションは、別の改善である。様々なサービスの動的マルチプレクシングは、システムリソースの効率的な使用のため、またそのキャパシティを最大化するために、非常に望ましい。ダウンリンクでは、リソースの割り振りは、瞬間的であり得、スケジューラ実装形態によって限定されるだけであるが、アップリンクでは、標準的な特定のソリューションが必要とされる。以下では、Ｒｅｌｅａｓｅ１５の既存のソリューション、およびＲｅｌｅａｓｅ１６での追加的なソリューションを議論する。
様々なサービスの動的マルチプレクシングは、システムリソースの効率的な使用のため、またそのキャパシティを最大化するために、非常に望ましい。ダウンリンクでは、リソースの割り振りは、瞬間的であり得、スケジューラ実装形態によって限定されるだけである。いったんバッファ内に低レイテンシデータが現れると、基地局は、リソースが正常に割り当てられ得る（すなわち、そのＵＥについて既に進行中のダウンリンク送信について割り当てられたリソースと衝突することのない）時間的に最も早い瞬間を選ぶべきである。これは、スロット、またはミニスロットが任意のＯＦＤＭシンボルで開始することができるミニスロットのいずれかの初めである可能性がある。したがって、ダウンリンクプリエンプションは、長期の割り当て（例えば、スロットベース）がリソース（特にワイドバンドのリソース）を占有し、典型的には、ミニスロットであり得るクリティカルなデータ送信の余地がない場合に、生じる可能性がある。この場合、スケジューラはＤＣＩをクリティカルなデータＵＥに送信して、ダウンリンクで進行中の送信をオーバライドすることができる。スロットｅＭＢＢ送信がプリエンプトされると、元のメッセージのプリエンプトされた部分はソフトバッファを汚染し、再送信において良好なパフォーマンスを与えるためフラッシュされなければならないが、これは起こりやすい。ＮＲ Ｒｅｌｅａｓｅ１５仕様は、明示的なシグナリングによるプリエンプションについて示すことを可能にしており、次のいずれかによって搬送される：
・オプション１．グループ共通ＰＤＣＣＨ上での特殊なＤＣＩフォーマット２＿１による、または；
・オプション２．マルチＣＢＧ再送信ＤＣＩ「ＣＢＧフラッシュアウト情報」における特殊なフラグによる。
オプション１は、インジケーションを１４ビットのビットマップとして与え、これは２つのプリエンプションインジケーションメッセージ間においてダウンリンクリソースドメインを参照するようアドレッシングする。このシグナリングの最高分解能は、時間では１ＯＦＤＭシンボルであり、周波数では１／２ＢＷＰ（帯域幅部分）であるが、同時にではない。メッセージの周期性が長くなると、分解能は粗くなる。これは、グループ共通のシグナリングであるため、ＢＷＰ内のすべてのＵＥがこれを読むことができる。
オプション２は、ユーザ特有のシグナリングの方法である。ＣＢ／ＣＢＧのセットを含むＨＡＲＱ再送信ＤＣＩは、ＵＥは最初にソフトバッファの関連部分をフラッシュし、次に再送信されたＣＢ／ＣＢＧをソフトバッファに記憶しなければならないことを示すための特殊なビットを有することができる。
Ｒｅｌｅａｓｅ１５ ＵＲＬＬＣの３ＧＰＰ議論の間、アップリンクプリエンプション特徴は、時間不足のため３ＧＰＰ ＵＲＬＬＣ作業項目において範囲を狭められた。しかしながら、この特徴は、Ｒｅｌｅａｓｅ１６で議論中である。ＵＬプリエンプションは、長いｅＭＢＢ ＵＬ送信が、緊急のＵＲＬＬＣ ＵＬ送信で中断された場合に生ずる可能性がある。さらには、これは２つのフレーバーを有することができる：
・両方の送信が同一ＵＥに属する、ＵＥ内プリエンプション。ＵＥ内プリエンプションは、ｇＮＢの代わりに、ＵＥがＵＬ方向において送信を優先するＤＬプリエンプションのケースに類似している。このために、ｅＭＢＢ送信ではなく入来ＵＲＬＬＣ送信のｇＮＢに、ある種のインジケーションが必須である。
・高い優先度のＵＬトラフィックの緊急な送信（ＵＲＬＬＣトラフィック）のためにいくつかのＵＥからの要求に基づくＵＥ間マルチプレクシングの場合、ｇＮＢは送信をできるだけ早く受け入れて遅延要件を満足するためにリソースを提供する必要がある。これは、遅延の点からあまり厳密ではない要件でＵＬ送信用に（ｅＭＢＢトラフィック）、ｇＮＢが、既に適切なＵＬリソースを１つまたは複数の他のＵＥに割り振っている場合に生じる可能性がある。したがって、ｇＮＢは優先されたＵＲＬＬＣ送信用に、これらのリソースを再スケジューリングする必要がある。
ＵＥ内プリエンプションはＭＡＣメカニズムをより含意するが、第２のオプションはクリアな物理レイヤ範囲を有するため、以下でさらに議論する。
電力制御およびミューティングに基づく２つのイネーブルメカニズムを考える場合、プリエンプションは、１）進行中または予定されているＵＬ送信を変更することによるＵＥおよびｇＮＢ両方における追加的なシグナリングおよび複雑性、２）ｅＭＢＢトラフィックのパフォーマンスに対するインパクト、を犠牲にして達成される。投資する価値のある犠牲として、ＵＲＬＬＣ送信の必要とされる品質を最良に確実にするメカニズムを採用することが重要である。両方の手法を図６３に図示することができる。
電力制御ベースのスキームに伴う欠点は、ＵＲＬＬＣ送信は、実際にはこれらの送信が優先度を下げられている可能性があるサービングｇＮＢによって制御される送信から発せられる干渉を被ることである。さらには、ＵＲＬＬＣ送信の電力急上昇は、近隣セルへの干渉を増すだけでなく、ｅＭＢＢトラフィックのパフォーマンスにもインパクトを与える。したがって、プリエンプションベースのスキームでは、ｇＮＢがＵＲＬＬＣ送信に使用しようと意図している適切なリソース上の進行中またはプリスケジューリングされたｅＭＢＢ ＵＬ送信をキャンセルすることによって、ｇＮＢは、自傷行為的な干渉によるＵＲＬＬＣトラフィックパフォーマンスの少なくとも可能性のある悪化を回避する。ここでの議論は、信頼性の制御には他のオプションがより適切な場合のＰＵＳＣＨ送信に関することに留意されたい。ＰＵＣＣＨ向けには、オプションがより限定されている。
４ＧＨｚ、ＤＳ １００ｎｓのＴＤＬ－Ｃ、４ｘ２アンテナ設定およびＭＭＳＥ－ＭＲＣ受信機で、スロットベースのｅＭＢＢ送信がミニスロットＵＲＬＬＣと干渉する場合の電力制御ベースのスキームのパフォーマンスを、図６４に示す。低ＳＥ ＭＣＳテーブルが使用されている。
上の議論に基づいて、インジケーションベースのスキームは、ＵＲＬＬＣ信頼性を確実にすることができるが、電力制御ベースのスキームは、Ｒｅｌｅａｓｅ１５／１６のインターワーキングシナリオにおける後方互換的なソリューションとして考えることができる。しかしながら、前者は多大なシグナリングコストが伴う。
これは、ＵＬプリエンプションインジケーションは、ＵＥ特有の様式では実際に効果的であるが、必要であれば単一ＵＥから複数ＵＥへ、シナリオに応じてグループサイズを調節するための柔軟性を有するグループ共通のＵＬプリエンプションインジケーションを検討するほうがより良好な設計選択であることを含意している。この手法は、単一ＵＥの場合での性質を保存しつつ、複数のＵＥがプリエンプトされる必要がある場合、シグナリングのオーバヘッドおよびブロッキング確率を低減する。
既存のメカニズムを再使用することを目的として、可能な場合、ＵＬプリエンプションのグループ共通シグナリング用に、以下の２つのオプションが主に検討される：
・オプション１：ＤＣＩフォーマット２＿０に基づく、ＵＬプリエンプションインジケーション（動的ＳＦＩ）
・オプション２：ＤＣＩフォーマット２＿１（ＤＬプリエンプションインジケーション）に類似するＵＬプリエンプションインジケーション設計
オプション１では、既存の動的ＳＦＩを使用して以下のような新しい（または拡張した）ＵＥ挙動を規定することが提案される。ＵＥが、ＵＬ送信用にＵＥ特有のシグナリングによって既にスケジューリングされているシンボル用の柔軟な（またはＤＬ）割り振りを検出すると、ＵＥは完全にＵＬ送信をキャンセルする。この設計選択は、２つの想定に基づいている。すなわち、ＵＬプリエンプションを目的として、１）動的ＳＦＩがＵＥ特有のシグナリングをオーバライドする、２）プリエンプトされたＵＬ送信は、遅延せず、再開されるが、単純にキャンセルされる。この手法は単純であり、ＵＬ送信だけをキャンセルする必要があるため、ＵＥにおいてあまり処理時間を必要としない。しかしながら、これは新しい挙動の規定を必要とし、これは後のＳＦＩが前のＵＥ特有のＤＣＩをオーバライドするという想定に基づいているが、それ自体がＲｅｌｅａｓｅ１５で使用される設計哲学と矛盾する。さらには、単純さの理由から既存のＳＦＩレジームに依拠することは、Ｒｅｌｅａｓｅ１５用に指定されたＳＦＩテーブルが使用されるべきであることを含意する。このテーブルのエントリを注意深く調べることで、十分な柔軟性を与えるビットマップパターンと比較して、どこでＵＬ送信のキャンセルが発生し得るかの限度を観察することができる。
オプション２では、ＤＬプリエンプションのメカニズムを、ＵＬプリエンプションインジケーションに採用することができる。この手法は、ｇＮＢがＵＥに対して、ビットマップパターンを使用することによってどのリソースがプリエンプトされる必要があるか、より細かな細分性を示すことができるようにする。このメカニズムは、ＵＥ挙動がどのように規定されるか、またはその能力に応じて、ビットマップパターンを使用して、後に送信を再開することなく、いつＵＬ送信が停止されるべきかを示すことができるという意味で、柔軟性がある。または代替的に、ＵＬ送信をいつ停止して再開するかについて、ＵＥが妥当な時間内にそのような動作を行うことができる場合、ＵＥに示すために使用することができる。
低ＢＬＥＲターゲットのための低ＭＣＳおよびＣＱＩが、追加的な問題である。上で提示した評価に基づいて、ＵＲＬＬＣ用のレイテンシ要件に応じて、１無線送信のためだけの時間が存在し得ることを観察することができる。この例では、無線インターフェースはＵＲＬＬＣサービスに必要な非常に低いＢＬＥＲを保証することができなければならない。この目的のため、Ｒｅｌｅａｓｅ１５では、いくつかの高度化があった：
・新６４ＱＡＭ ＣＱＩテーブルが、ターゲットＢＬＥＲ１０＾－５でのレポーティング用に導入されている。新しいテーブルは、低スペクトル効率（ＳＥ）値を含む。
・低スペクトル効率の６４ＱＡＭ ＭＣＳテーブルが、変換プリコーディングなしに使用するために導入されている。
・ＤＦＴ拡散ＯＦＤＭ波形テーブル用の低スペクトル効率の６４ＱＡＭ ＭＣＳテーブルが、導入されている。
例として、ＴＢＳ＝２５６ビット（＝３２バイト）、送信持続時間は１ＤＭＲＳシンボルのオーバヘッドを伴う４ＯＦＤＭシンボルを考える。４０ＭＨｚ内のＢＷでサポートされる異なるＭＣＳ用のＰＤＳＣＨ ＢＬＥＲを、図６５に与える。ここで、符号化率ＭＣＳ６は、レガシー６４ＱＡＭテーブルの符号化率ＭＣＳ０に相当する。
ネットワークは、ＲＲＣによって半静的に、ハイライトされたＭＣＳテーブルを設定することができる。さらには、ＭＣＳテーブル用の動的シグナリングは、ＵＥを、ＭＣＳ－Ｃ－ＲＮＴＩが常に低ＳＥ ＭＣＳテーブルに関連付けられる常時的なＣ－ＲＮＴＩに加え、ＭＣＳ－Ｃ－ＲＮＴＩで設定することによってもサポートされる。ＵＥは、ＰＤＣＣＨ ＣＲＣとスクランブルしたＭＣＳ－Ｃ－ＲＮＴＩを検出すると、常に低ＳＥ ＭＣＳテーブルを適用し、それ以外では半静的に設定されたＭＣＳテーブル（６４ＱＡＭまたは２５６ＱＡＭ）を適用する。代替として、ＵＥがＵＲＬＬＣトラフィックしか有していない場合、ＭＣＳテーブルを半静的に設定することが可能であるが、ＵＥがｅＭＢＢであり、同時にＵＲＬＬＣ対応である場合は、動的な方法が好ましい。動的なＭＣＳテーブルシグナリングの欠点は、新しいＭＣＳ－Ｃ－ＲＮＴＩ導入に起因する、ＰＤＣＣＨ ＣＲＣの誤ったアラーム率が高いことである。
ＣＱＩおよびＭＣＳテーブルは、独立的に設定可能であり、例えば、レガシー６４ＱＡＭ ＭＣＳテーブルを、新しい６４ＱＡＭ ＣＱＩテーブルの１０＾－５ ＢＬＥＲレポーティングと使用することができることに留意しなければならない。
マルチアンテナ技法は、別の問題である。データレートの向上（マルチプレクシング）と、信頼性の向上（ダイバーシティ）との間には、周知のトレードオフが存在する。これは、一方での向上が必ず他方での悪化を犠牲にして実現することを意味している。モバイルブロードバンドでは、ネットワークのデータレートおよびスペクトル効率を向上させるために典型的にはＭＩＭＯ技法が使用される。他方で、ＵＲＬＬＣには、ＭＩＭＯによって与えられる自由度を使って信頼性を高めることがより良好な場合がある。したがって、スループットを最適化するメトリックとして使用する代わりに、ネットワークは、故障停止確率などの信頼性メトリックを最適化する可能性がある。例えば、ＵＬパフォーマンスは、図６６に示されるように、ＵＬプリコーディングとサイト内ＵＬ ＣｏＭＰ（ジョイント受信）との両方によって改善することができ、この図では、ＵＬ ＣｏＭＰ （３セクタサイト内ジョイント受信）およびＵＬプリコーディング（Ｒｅｌ－１０ランク１ ４ポートプリコーダ）がある場合とない場合の、様々なマルチアンテナ技法向けのＵＬ ＳＩＮＲが示されている。「プリコーディングなし」では、単一のアンテナ送信が使用されるが、「プリコーディング」では、４アンテナ要素が使用される（１ｘ２ Ｘ－ｐｏｌ、分離＝０．５ラムダ）。
巡回遅延ダイバーシティ（ＣＤＤ）または空間時間符号は、スペクトル的にトランスペアレントな様式で、さらなる周波数ダイバーシティを与えると考えることもできる。複数の受信アンテナは、受信ダイバーシティを与え、受信した信号対干渉ノイズ比（ＳＩＮＲ）を、受信機側で受信結合した後に、最大化する手段を与える。ダイバーシティスキームは、プリコーディングよりもチャネル知識を必要としないという利点を有する。
マルチアンテナ要素を使用して、受信したＳＩＮＲひいては信頼性を向上させるために、送信機側および／または受信機側で方向性アンテナビームを作成することもできる。明らかに、ビームが正しい方向を指向し、ひいてはビームフォーミングが、ビームの正しい方向を決定するよう、少なくともいくつかのチャネル知識を必要とするため、改善されたＳＩＮＲが提供される。
Ｌ２特徴
このセクションでは、ＵＲＬＬＣのプロビジョニングをサポートするための、ＲＡＮにおけるレイヤ２特徴を説明する。Ｒｅｌｅａｓｅ１５には、ＬＴＥおよびＮＲのための複数の特徴が導入されて、基礎的なＵＲＬＬＣサポートを提供しているが、Ｒｅｌｅａｓｅ１６標準化のための現在の研究は、ＵＲＬＬＣを提供する際のシステムの効率を改善するための高度化を模索しており、特にＴＳＮ統合化のサポート、すなわち、様々なＱｏＳ要件の複数のトラフィックフローのサポートをターゲットにもしている。ここでは、非クリティカルなトラフィックが効率的に送信されるべきということだけではなく、他のクリティカルなトラフィックフローも確定的なレイテンシでサービングされるべきであることを想定する。ＴＳＮシナリオでは、これらのトラフィックフローは、典型的には周期的であるが、必ずしもそうではない。一般的には、トラフィックが、いつ、どれくらいのサイズで、およびどのパターン／周期でｇＮＢまたはＵＥに到来するかの十分な知識が、事前には利用可能ではないシナリオに対処する。ＳＲおよびＢＳＲ、巡回トラフィック用のプリスケジューリング、ＵＥマルチプレクシング、ならびにＰＤＣＰ複製に関する以下のセクションで、Ｒｅｌｅａｓｅ１５ベースラインおよび高度化を検証する。
Ｌ２特徴は、一般的にはＦＤＤまたはＴＤＤが使用されているかどうかに無関係であることに留意されたい。
バッファステータスレポート（ＢＳＲ）およびスケジューリングリクエスト（ＳＲ）は、データが送信バッファで利用可能であることを示すためにＵＥが使用することができる２方法である。これらのインジケーションは、ネットワークが、グラント、すなわち、ＵＬ－ＳＣＨリソースをＵＥに提供して、データ送信を許可する結果となり得る。これは、普通、動的スケジューリングとして知られている。ＳＲおよびＢＳＲ動作の例を、図６７に示す。
一言でいうと、ＳＲとＢＳＲとの主な違いの１つは、ＳＲは、ＵＥが送信用のデータを有していることをシグナリングするＰＵＣＣＨ内の１ビットインジケーションである一方で、ＢＳＲは論理チャネルグループごとにＵＥがバッファ内に有しているデータの量のおおよその値を、明示的に与えることである。ＢＳＲは、ＰＵＳＣＨで送信されるＭＡＣ制御要素（ＣＥ）内で送信される。
ＮＲ Ｒｅｌｅａｓｅ１５では、１つのＳＲ設定は、論理チャネルごとに設定することができ、いくつかの論理チャネルは同じＳＲ設定で設定される場合がある。ＳＲは、ＰＵＣＣＨ内で送信される。１帯域幅部分（ＢＷＰ）では、ＳＲは最大１ＰＵＣＣＨリソースで設定することができる。これは、ＮＲでは、ネットワークが、潜在的に様々なタイプのトラフィックで使用することができる複数のＳＲ設定を設定することができることを意味している。
手順は、以下のように要約することができる：
・一定の論理チャネルからデータが到来する。
・トリガ指定基準が満足されると、到来により常時ＢＳＲがトリガされる。
・ＢＳＲを送信するために利用可能なＰＵＳＣＨリソースはない。
・ＳＲがトリガされ、ＢＳＲをトリガした論理チャネルに関連付けられるＳＲリソース内で送信される。
動的スケジューリングは、図６７に示されるように、データ送信に遅延を導入する。この遅延は、ＳＲ設定の周期性／オフセット、およびネットワークがリソースを割り当て、グラントを送信するために要する時間に依存する。
一部の産業用ＩｏＴサービスおよびトラフィックは、タイトな遅延要件を満たす必要がある場合がある。したがって、Ｒｅｌｅａｓｅ１５で指定されるような「複数ＳＲ設定」は、トラフィックの区別を確実にするための、および遅延要件が満たされることを確実にするための、キーとなる役割を果たすことが可能な特徴である。異なるトラフィックにマッピングされた複数のＳＲ設定を示す例が、図６８に描かれている。
バッファステータスレポート（ＢＳＲ）は、指定されるように、ＵＥによってＰＵＳＣＨ内で送信される。ＢＳＲは、ＭＡＣ ＰＤＵ内でＭＡＣ制御要素として送信される。ＢＳＲの目的は、バッファ内のおおよそのデータの量を示すことである。このレポートは、論理チャネルグループ（ＬＣＧ）ごとに示される。各論理チャネルは、ＬＣＧに関連付けられる。８つのＬＣＧが、ある。トラフィックプロファイル（ＤＲＢ）の限定されるセット同士を区別する必要があるシナリオでは、ＬＣＧの数は、論理チャネルとＬＣＧとの１対１マッピングを提供するために十分である可能性がある。
４つの異なるＢＳＲフォーマットがあり、選択されたフォーマットに応じて、ＵＥは１つまたは複数の論理チャネルグループのバッファステータスを示すことができる場合がある。
ＢＳＲは、以下のメカニズムのうちの１つによってトリガすることができる：
・常時ＢＳＲ：常時ＢＳＲは、一定のＬＣＧに属する論理チャネルが、送信用の新しいＵＬデータを受信した時にトリガされる。加えて、この新しいデータは、以下の２つの条件のうちの１つを遂行しなければならない：新しいデータは、データを有している他の論理チャネルのどれよりも高い優先度で論理チャネルに属すること；または、論理チャネルのどこにも、ＬＣＧ内での送信用に利用可能な他のデータがないこと。
常時ＢＳＲは、より多くのデータが別の一定の論理チャネルで受信される場合、トリガされることはなく、その論理チャネルは既にバッファにデータを有している。
常時ＢＳＲは、ショートおよびロングＢＳＲフォーマットを使用することができるだけである。
・周期的なＢＳＲ：周期的なＢＳＲは、ネットワークによって与えられる設定にしたがって周期的にトリガされる。
周期的なＢＳＲは、ショートおよびロングＢＳＲフォーマットを使用することができるだけである。
・パッディングＢＳＲ：ＵＥがデータを送信するために必要とするよりも大きなグラントを受信すると、ＵＥは、パッディングビットの代わりにＢＳＲを送信することができる場合がある。パッディングビット数に応じて、ＵＥは異なるＢＳＲフォーマットを送信する。
パッディングＢＳＲは、すべてのＢＳＲフォーマットを使用することができる。
ＳＲおよびＢＳＲは、産業用ＩｏＴトラフィックを支援して、特にトラフィックの周期性とサイズが予測不可能な場合に、それぞれのトラフィックの異なる要件を満足するために、重要な役割を果たす。
「複数のＳＲ設定」は、厳密な遅延要件およびＵＬネットワークリソースを割り当てるために好ましい方法として動的なスケジューリングを有するトラフィックを区別するためにキーとなる特徴であり得る。特定のＳＲ設定を、特定の論理チャネル（特定の要件、例えば、非常に低いレイテンシ要件でトラフィックを搬送することができる）にマッピングすることができる。ネットワークが、この特定のＳＲ（それに割り当てられた特定のリソースによって識別され得る）を受信すると、ネットワークは、送信を待機している低レイテンシ要件のトラフィックが存在することを識別することができる。次に、ネットワークは、このトラフィックに対するリソースの割り当てを優先することができる。
１つの可能性としては、予測可能な産業用ＩｏＴトラフィック（既知の周期性／パケットサイズ）が、特定のＳＲ設定にマッピングされる。この時、ＳＲ設定は、ネットワークがその特定のトラフィックに適当なリソースを割り当てることができるトラフィックを識別する。次に、他方では、非予測可能なトラフィック（パケットサイズが未知である）を伴うＬＣＨが汎用ＳＲ設定、複数の他のＬＣＨによって共有される汎用ＳＲにマッピングされ得る。この場合、ＳＲ設定は、ネットワークがトラフィックを識別する支援をすることができないため、ＬＣＨはＢＳＲインジケーションに依拠して、スケジューリング決定を支援することができるネットワークに関連情報を提供する必要がある。したがって、バッファステータスレポーティングは、特に非予測可能なトラフィックが期待されるシナリオにおいて、やはりキーとなる特徴となる。
産業用ＩｏＴは、Ｒｅｌｅａｓｅ１５で設計されたＳＲ手順に基づくことが期待されるが、マイナーな高度化がＲｅｌｅａｓｅ１６に導入される可能性がある。例えば、ペンディング中のＳＲが複数ある場合、どのＳＲ設定を使用するか決定することは、ＵＥ次第である。このＵＥ挙動は、最高優先度の論理チャネルにリンクされるＳＲ設定がＵＥによって選択されるように、変更することができる。しかしながら、このことは、可能な合意に達することなくＲｅｌｅａｓｅ１５で議論された。さらには、現在は、重要なデータが到来した時に迅速なＳＲ送信を可能にするよう、頻繁なＰＵＣＣＨリソースが割り当てられるが、ロングＰＵＳＣＨ送信が進行中の場合、ＰＵＣＣＨとＰＵＳＣＨは現在の仕様によりオーバラップすることができないため、ＳＲはこのロングＰＵＳＣＨ持続時間の後にＰＵＣＣＨリソースで送信できるだけである。この場合、ＢＳＲは代わりにＰＵＳＣＨを介して送信される可能性があるが、ＰＵＳＣＨがロングである（スロット長、低ＯＦＤＭヌメロロジー）場合は、長い復号化／処理遅延に関連付けられる場合もある。これは、進行中のロングＵＬ－ＳＣＨに起因する遅延したＳＲを示す図６９に示される。したがって、Ｒｅｌｅａｓｅ１６では、オーバラップしたＰＵＳＣＨリソース上でＳＲ用の並列なＰＵＣＣＨ送信を可能にして、ＳＲ用のレイテンシを低減することが構想される。
産業用ＩｏＴ向けのＢＳＲは、やはりＲｅｌｅａｓｅ１５に基づいており、マイナーな高度化も導入され得る。Ｒｅｌｅａｓｅ１５の開発の間、新しいデータは、常にＢＳＲをトリガすることが提案された。この挙動は受け入れられず、ＬＴＥ挙動が採用された。これは、論理チャネルグループが既にバッファリングされたデータを有していた場合、論理チャネルに入来する新しいデータは常時ＢＳＲをトリガしないこと、または新しいデータは優先度の低い論理チャネルに属することを意味している。それにも関わらず、産業用ＩｏＴのＲｅｌｅａｓｅ１６に向けて、新しいデータが常にＢＳＲをトリガするかどうか再度議論されており、他の方法では必要とされる頻繁で周期的なＢＳＲ送信を回避できるという優位性を有する。
これらのＳＲ／ＢＳＲセクションで議論されない別の態様は、論理チャネルの優先順位付け手順におけるＢＳＲ用のＭＡＣ ＣＥの優先度である。ＢＳＲ用のＭＡＣ ＣＥは、パッディングＢＳＲを例外として、あらゆるＤＲＢからのデータよりも高い優先度を有する。換言すると、ＢＳＲ用のＭＡＣ ＣＥは、現在の動作ごとに、あらゆるユーザデータの前に送信される。しかしながら、ＮＲ産業用ＩｏＴをターゲットとするいくつかの最適化が可能である：
・ＢＳＲ用のＭＡＣ ＣＥの優先度は、設定可能である。すなわち、ネットワークによって修正（低減）することができる。
・このやり方で、一定のＤＲＢ、例えば、非常に低い遅延要件でデータを搬送するＤＲＢは、ＭＡＣ ＣＥのＢＳＲよりも高い優先度を有する可能性がある。
以下では、Ｒｅｌｅａｓｅ１５および１６の両方で使用されるプリスケジューリンググラントに対処する。そのようなグラントは、ＳＲ送信機会を待機することによって導入された遅延および対応する応答（すなわち、グラント）を取り除く。
Ｒｅｌｅａｓｅ１５では、ＵＥが割り当てられたＵＬリソースを有していない場合、データは利用可能となり、ＵＥはスケジューリング要求手順を経る、すなわち、ｇＮＢにＵＬリソースを要求し、次いでグラントされる必要がある。これには、クリティカルなトラフィックの送信に望ましくない、ＴＳＮストリームデータなどの追加的なＵＬアクセス遅延が伴う。グラントのプリスケジューリングは、図７０に示されるような動的なスケジューリングを使用する場合に、ＳＲからグラントまでの手順から生ずる余分なレイテンシを回避する技法である。
プリスケジューリングは、潜在的なＵＬ送信のために複数のＵＬグラントを積極的に送出しているｇＮＢによる実装形態によって行うことができる。ＬＴＥおよびＮＲのＲｅｌｅａｓｅ１５の標準は、複数の周期的に反復するＵＬグラントのプリスケジューリングを許可することにより、この概念をサポートしている。これは、元々ＬＴＥ ＶＯＩＰに導入された半永続スケジューリング概念（ＳＰＳ）上に成り立つ。ＮＲでは、そのようなプリスケジューリングスキームは、ダウンリンク（ＤＬ）における半永続スケジューリングと呼ばれるが、アップリンク（ＵＬ）では設定グラント（Ｔｙｐｅ１およびＴｙｐｅ２）と呼ばれる。
ＮＲのＤＬ ＳＰＳ割り振りは、ＬＴＥにおけるものと同じであり、ＰＤＣＣＨ／Ｌ１信号によって与えられる設定される割り振りである（非アクティブ化／アクティブ化することもできる）。
ＮＲのＵＬ設定グラント（ＣＧ）は、２つの変形である、設定グラントタイプ１およびタイプ２で指定されている。両方の変形において、ｇＮＢは、以下を含むグラントのリソースを（様々なシグナリングを介して）事前割り当てする：
・時間－周波数リソース（Ｔｙｐｅ１にはＲＲＣ、Ｔｙｐｅ２にはＤＣＩを介する）
・期間（ＲＲＣを介する）、オフセット（Ｔｙｐｅ１にはＲＲＣを介して、Ｔｙｐｅ２には非明示的にＤＣＩ受信において）
・ＭＣＳ、電力パラメータ（Ｔｙｐｅ１にはＲＲＣ、Ｔｙｐｅ２にはＤＣＩを介する）
・ＤＭＲＳ、繰り返し（Ｔｙｐｅ１にはＲＲＣ、Ｔｙｐｅ２にはＤＣＩを介する）
・ＨＡＲＱ設定；（ＲＲＣを介する）
・メッセージをアクティブ化／非アクティブ化する（Ｔｙｐｅ２にはＤＣＩを介する）。
両方の設定グラントタイプ１およびタイプ２は、次のような、いくつかの共通性を共有する：
・アクティブ化／非アクティブ化および再送信用に、ＰＤＣＣＨ上で使用される「設定スケジューリング」ＣＳ ＲＮＴＩ。
・両方のＴｙｐｅ１およびＴｙｐｅ２用の再送信は、ＣＳ ＲＮＴＩへの動的なグラントのみに基づいている（すなわち、再送信は、周期的に反復するＵＬグラントを使用して送信されない）。
・Ｃ－ＲＮＴＩを有する動的グラントは、時間ドメインでオーバラップする場合、初期の送信用に設定グラントをオーバライドする。
・サービングセルおよびＢＷＰごとに、最大１つのアクティブなＴｙｐｅ１またはＴｙｐｅ２設定が存在する。
Ｔｙｐｅ１とＴｙｐｅ２との間の１つの違いは、セットアップ手順である。Ｔｙｐｅ１ＣＧの手順を、図７１に図示し、Ｔｙｐｅ２ＣＧの手順を図７２に図示する。Ｔｙｐｅ１ＣＧは、ＲＲＣを介してアクティブ化されるため、（ＴＳＮ特性の）確定的な到達周期性を有するトラフィックに最適であると主張することができる。他方では、Ｔｙｐｅ２ＣＧは、不確定なアラインメントずれのあるストリームをサポートするために適しており、グラントはＤＣＩ（ＰＨＹ信号）で素早く再設定することができる。
設定グラントの不利な点は、予測不可能であるがクリティカルなトラフィックにサービングするために使用される場合に、グラントされたリソースの低い利用率であり、これは、ｇＮＢが、トラフィックが到達するかどうかを知らずにリソースを割り当てるためである。
ＴＳＮトラフィックハンドリングは、Ｒｅｌｅａｓｅ１６で重要な問題となる。複数のトラフィックフローをサポートするためのいくつかの手法、すなわち、ＴＳＮストリームをここで議論するが、図７３および図７４で図示されるように、それぞれのストリームは、特定の特性、すなわち、周期性、時間オフセット、ターゲット信頼性、レイテンシなどを有している。図７３は、様々な到来およびペイロードサイズを伴う、産業用確定的ストリームを図示している。図７４は、様々なパターン、および周期性、ならびに異なるレイテンシ、および信頼性要件を伴う、産業用確定的ストリームの図である。
ＴＳＮストリーム特性のそれぞれは、ユーザをスケジューリングする際に、主な役割を果たす。例えば、ネットワークがそのようなＴＳＮストリームデータの周期性および到来を確実に知っている場合、周期的なデータだが、なお超低レイテンシ要件を有するＴＳＮストリームが、最も良好に（最小の可能なネットワークリソースで）受け入れられる可能性がある。しかしながら、ネットワークがそのような特性を知らない場合、タイトなレイテンシ要件に違反することを回避するよう、グラントをオーバディメンジョンし、それによって潜在的に無線リソース管理が非効率になる。さらには、ＵＥのＴＳＮデータストリームのターゲット信頼性が、特定のＭＣＳインデックスおよび複数の繰り返しにより到達され得ることが想定される。無線ネットワークがそのような要件を正確に知っている場合のみ、リソースを越えてまたは下回って割り当てることをしない。以下では、これらのトラフィック特性は、特に複数のオーバラップしているＴＳＮストリームおよび他の非クリティカルなトラフィックに関しては、必ずしも知られていないことが想定される。したがって、特徴を以下で検証し、ｇＮＢがトラフィックミックスをなお効率的ならびにロバストにスケジューリングするための可能性を与える。
Ｒｅｌｅａｓｅ１５では、セル／ＢＷＰ内の単一のＣＧ設定は、産業用のストリーム／フローを、類似の期間および他の要件（レイテンシ、信頼性、ジッタなど）でサポートすることができる。しかしながら、産業用のネットワークでは、Ｒｅｌｅａｓｅ１６でターゲットにされるように、ノードで生成された複数ストリーム（データフロー）は、非常に一般的なユースケース、例えば、いくつかの作動装置、センサ、および監視デバイスを備えるロボットアームである。
結果として、そのような複数のストリームは、図７３に示されるように、例えば、到来時刻およびペイロードサイズなど、その特性において、異なっている。ストリームのうちの１つは、（他のものと比べて、中間サイズのペイロードを有する。また、このストリームからのパケットは、オフセットゼロで到来し、続いて他の２つのストリームからのパケットが続き、それぞれオフセットＴ、および２Ｔで到来する。
さらには、複数のストリームが、図７４に示されるように、異なる周期性、レイテンシ、および信頼性要件によって特徴付けられる可能性がある。網掛けされた輪郭のストリームが、それほどクリティカルな信頼性およびレイテンシを必要としないのに対し、他のストリームは両方とも要求の厳しい信頼性およびレイテンシパフォーマンスを必要としているとする。ＭＣＳおよび繰り返しなどのグラントの設定パラメータは、後者と比較して前者では異なる。また、いくつかのストリームは、到来パターンと周期性が他のものとは異なっている。これらのすべてのストリームは、ストリーム特性が異なっていることにより、ＣＧが非常に短い周期性を使用してサポートされていたとしても、単一の設定（ＣＧ）でサポートすることができないが、この理由は、ＣＧが、設定パラメータの単一のセット、例えばＭＣＳインデックス、レイテンシ、スロット期間、Ｋ繰り返しを有することになるためである。
ｇＮＢには、ＣＧの設定を割り当てる責任があるため、無線ネットワークの知識を伴って設定同士のあらゆるオーバラップが発生する。ｇＮＢは、いくつかのシナリオに対処するようオーバラップする設定を割り当てることができる：１）クリティカルなデータ到来のアラインメントずれを克服すること、２）複数のＴＳＮストリームを異なる特性で受け入れること。設定の特性に応じて、オーバラップは、いくつかのケースに分けることができる：
・ケースａ）開始シンボル（オフセット）を除く類似の特性（例えば、ＭＣＳ、期間、Ｋ－Ｒｅｐ）。
・ケースｂ）類似の開始時間および同じ周期性（完全にオーバラップする設定）、ただし異なる（ＭＣＳおよびＫ－Ｒｅｐ）。
・ケースｃ）異なるオフセットならびに／または異なる優先度およびＭＣＳ／Ｋ－Ｒｅｐ。
オーバラップする設定における問題は、オーバラップする設定のどれを選択するかについての未規定のＵＥ決定基準である。図７５に示すように、クリティカルなデータ到来におけるアラインメントずれを克服するために、ｇＮＢが類似のオーバラップする設定を時間が異なるオフセットで割り当てると想定する。そのような場合、クリティカルなトラフィックが到来すると、ＵＥは（時間的に）最も近い設定を選択する。
産業用の用途では、論理チャネル優先順位付け（ＬＣＰ）の制限およびマルチプレクシングに関連する追加的な懸念が提起される。続いて、ベースラインＬＣＰ手順を説明する。次に、産業用の混合型サービスシナリオのためのマルチプレクシングを高度化するための技法を説明する。
混合型サービスの通信システムは、ＵＥ間、およびＵＥ内の両方のシナリオに対処するべきであるが、このセクションではＵＥ内のシナリオに着目する。そのようなシステムでは、ＵＥは、クリティカルおよび非クリティカルなトラフィックとしてカテゴライズされる、いくつかのトラフィックタイプを有するものと想定される。設定グラントでは、クリティカルなトラフィックがより良好にサービングされると想定されるが、このトラフィックは、アップリンクにおいて非常に低レイテンシ高信頼を必要とするからである。トラフィックパターンについての不確定性のため、ｇＮＢが、そのようなトラフィックにサービングするために設定グラントリソースをオーバプロビジョンすることがさらに予期される。他方では、非クリティカルなトラフィックは緩いレイテンシおよび信頼性要件を有しており、ロバスト過ぎる送信から恩恵を得られない。反対に、システムリソースは、キャパシティが限られるシナリオにおいて、大量の非クリティカルなトラフィックをロバストなグラントで送信して、消費される可能性がある。そのような混合型サービスケースを代表および動機付けする一般のユースケースは、作動装置、センサ、および同一の通信デバイス／ＵＥに統合および接続されるカメラを有する産業用のロボットアームである。そのようなクリティカルなトラフィックが非クリティカルなトラフィックとオーバラップする場合、いくつかのＲＡＮ１／２問題が表面化する。
新しい送信が行われる場合はいつでもＬＣＰ手順が適用され、これを主に使用して、どのＬＣＨがどのように、ＰＨＹを介してＰＵＳＣＨ上で送られることになるＭＡＣ ＰＤＵを埋めるかを指定する。ＬＣＰ手順には主に、２つの部分があり、１つはＭＡＣ ＰＤＵに含められるＬＣＨを選択することに着目し、もう一方は、ＭＡＣ ＰＤＵを埋めるための（選択されたものの中での）各ＬＣＨのデータの量および優先順位付けに着目する。
ＬＣＨの選択は、ＬＣＰ制限手順と呼ばれる。そのような手順は、ＲＲＣを介して設定されるいくつかの制限によって制御される。これらの制限はそれぞれ、構築されたＭＡＣ ＰＤＵにＬＣＨが含まれることを許可／禁止する。以下は、Ｒｅｌｅａｓｅ１５の既存のＬＣＰ制限である：
・送信用に許可されるサブキャリア間隔をセットする、ａｌｌｏｗｅｄＳＣＳ－Ｌｉｓｔ；
・送信用に許可される最大ＰＵＳＣＨ持続時間をセットする、ｍａｘＰＵＳＣＨ－Ｄｕｒａｔｉｏｎ；
・設定グラントＴｙｐｅ１を、送信用に使用することができるかどうかをセットする、ｃｏｎｆｉｇｕｒｅｄＧｒａｎｔＴｙｐｅ１Ａｌｌｏｗｅｄ；
・送信用に許可されるセルをセットする、ａｌｌｏｗｅｄＳｅｒｖｉｎｇＣｅｌｌ。
論理チャネル優先度は、論理チャネルごとのＭＡＣエンティティごとに設定される。ＲＲＣは、ＬＣＰパラメータを設定して、ＭＡＣ内でアップリンクＬＣＨのデータのマルチプレクシングを制御する。そのようなＬＣＰパラメータは、次のように表現される。
・優先度の値が高くなると、優先度レベルが低下することを示す、ｐｒｉｏｒｉｔｙ；
・優先されたビットレート（ＰＢＲ）をセットする、ｐｒｉｏｒｉｔｉｓｅｄＢｉｔＲａｔｅ；
・バケットサイズ持続時間（ＢＳＤ）をセットする、ｂｕｃｋｅｔＳｉｚｅＤｕｒａｔｉｏｎ。
図７６に、ＬＣＰマルチプレクシングがどのように発生するかの例を図示する。この例では、「ｍａｘＰＵＳＣＨＤｕｒａｔｉｏｎ」制限だけを考慮している。図面では、論理チャネルを左から右に、優先度の高いほうから低いほうを配置した。優先度の高いＬＣＨを、最初にＭＡＣ ＰＤＵに置き、優先度の低いものを続けた。また、優先度ビットレート（ＰＢＲ）は、ＬＣＨ当たりのＭＡＣ ＰＤＵに含められるビット数を制御する。
以下では、ＵＥ内混合型サービス想定から得られるいくつかのシナリオが対処される。そのようなシナリオでは、単一のＵＥが、クリティカルなトラフィックおよび非クリティカルなトラフィックの両方にサービングしなければならないと想定する。クリティカルなトラフィックは、非周期的または周期的であってもよく、非クリティカルなトラフィックグラント要件と比較すると、比較的小さなサイズのグラントで、よりロバストな符号化を必要とする。クリティカルなデータの要件は、ＳＲおよびその応答手順によって引き起こされるレイテンシを回避するために、周期的で、ロバストに符号化された設定グラントを使用してスケジューリングすることである。
スケジューラには、クリティカルなデータの到来の完全な知識が存在しないことを、さらに想定する。これは、クリティカルなトラフィックが、非周期的である、または全体的に周期的ではないこと、すなわち、トラフィックの周期的な到来が、いくらかのジッタによって影響され得る、またはいくつかの周期的な送信機会が（利用可能ではないデータのために）単純にスキップされ得ることを意味している。そのような場合、ネットワーク／スケジューラは、周期的な設定グラントのスケジューリングを、パケットの到来発生に理想的にアラインメントすることができず、次のサブセクションで説明する問題につながる。
さらには、クリティカルなトラフィックの非常に低いレイテンシ要件に対応するために設定グラントの短い周期性が必要とされる場合、短い周期性の設定グラントは、ＵＥ内の他の非クリティカルなトラフィックにスケジューリング限度を課すことになる。そのように課されるスケジューリング限度の例は、１）短くて動的なグラント持続時間のみが、設定グラント間に割り当てることができる、２）動的なグラントは、設定グラントとオーバラップしていなければならない、である。
問題１：ロバストな設定グラントで送られる非クリティカルなトラフィック
このサブセクションでは、非クリティカルなトラフィックがロバストな設定グラント（すなわち、クリティカルなトラフィックを意図されている）を使用して受け入れられる場合に生ずる問題に対処する。散発的な利用可能性を持つ非クリティカルなトラフィックの存在を想定する。そのようなトラフィックは、短い周期性を有する散発的なクリティカルなトラフィックに与えられる必要があるロバストな設定グラントリソースでスケジューリングされる。図７７に図示されるように、ｅＭＢＢトラフィック（１０ＫＢとラベル付けされている）が、そのような設定グラントに受け入れられる場合（送信機会当たり１ＫＢ）、ｅＭＢＢ送信は長過ぎ（例えば、最大ファクタ１０、またはＢＳＲがネットワークによって受信されるまで）、不必要なＵＬ干渉につながり、これは設定グラントリソースがユーザ間で共有される場合、特に有害である。
非クリティカルなトラフィックを保持している論理チャネル（ＬＣＨ）に対する新しいＬＣＨ制限を、図７８に示すように、この問題を軽減するために導入することができる。例えば、「ＣｏｎｆｉｇｕｒｅｄＧｒａｎｔＴｙｐｅ２Ａｌｌｏｗｅｄ」または「ｍａｘ ＲｅｌｉａｂｉｌｉｔｙＡｌｌｏｗｅｄ」などの制限を、クリティカルなトラフィックをサポートしているＬＣＨに適用することにより、ＵＥは、ロバスト過ぎるリソースを使用して送られている非クリティカルなＬＣＨからのデータを回避することができる。
問題２：非ロバストな動的グラントでのクリティカルなトラフィック
ｇＮＢが、散発的なクリティカルなトラフィックを意図したロバストな設定グラントに加え、非クリティカルなトラフィック用にスペクトル上効率的な動的グラントをスケジューリングする必要がある場合に、別の問題が生じる。クリティカルなトラフィックが非ロバストなショートグラントで送られる場合の、余分なレイテンシを示している図７９に、これを示す。設定された動的グラントの同一のＰＵＳＣＨ持続時間を想定すると、既存の「ｍａｘＰＵＳＣＨＤｕｒａｔｉｏｎ」制限は、効果的／十分ではない。クリティカルなトラフィックは、非ロバストな動的グラントで送られるよう優先されるため、送信は失敗し、再送信遅延となる可能性がある。
そのような問題を克服するため、新しいＬＣＨ制限、すなわち、「ＤｙｎａｍｉｃＧｒａｎｔＡｌｌｏｗｅｄ」＊または「ｍｉｎｉｍｕｍＲｅｌｉａｂｉｌｉｔｙＲｅｑｕｉｒｅｄ」を導入することができる。図８０に図示されるように、そのような制限は、クリティカルなＬＣＨが非ロバストな動的グラントで送られることをブロックする。
問題３：動的グラントが設定グラントをオーバライドする問題
現在の仕様によると、設定グラントは、オーバラップする動的グラントが割り当てられた場合、常にオーバライドされる。図８１に図示されるように、いくつかのシナリオでは、非ロバストな動的グラントは、ロバストな設定グラントとオーバラップする場合もある。そのようなシナリオの理由は、ｇＮＢは、散発的な低レイテンシのクリティカルなトラフィックを受け入れるために、短い周期性設定グラントを割り当てなければならないことである。
この問題を解決するために、設定グラントを、条件付きで優先することができる。すなわち、クリティカルなデータが、オーバラップする動的グラントがある時にロバストな設定グラント上での送信用に利用可能である場合、次いでこの時クリティカルなデータは図８２に図示されるように常に優先され、この図は、クリティカルなデータの到来の際、設定グラントが動的グラントを条件付きでオーバライドできるようにする利点を示している。それ以外では、動的グラントが優先されてもよい。このように、オーバラップする大きなスペクトル上効率的なリソースは、クリティカルなデータがそこで送信される可能性があるというリスクを冒さずに、非クリティカルなデータ用にスケジューリングすることができる。しかしながら、この方法を採用するために、ｇＮＢは、動的グラントおよび設定グラントの、２つの可能な送信を復号する必要がある。この問題は、問題２のソリューション、すなわち、クリティカルなトラフィックＬＣＨに動的グラントで送信しないよう制限を与えることで解決することもできることは、注目に値する。このソリューションを用いない場合、頻繁な動的グラントがスケジューリングされ、クリティカルなトラフィックに不可避な遅延をもたらすケースがあり得る。
問題４：ＵＥ内の、異なるＰＵＳＣＨ持続時間のグラント同士のＵＬプリエンプション
産業用の混合型トラフィックシナリオでは、スペクトル上高い効率を可能にするために、ｇＮＢは、非クリティカルなトラフィックを受け入れるために、より長いグラントを割り当てたい場合がある。図８３に図示されるように、これは、あらゆる散発的なクリティカルなデータの送信遅延を大きくし、この図は、異なるＰＵＳＣＨ持続時間とオーバラップするグラントの例を示しているが、これはＲｅｌｅａｓｅ１５では、現在の送信を別の送信によって中断することができないからである。これを解決するために、図８４に図示されるように、物理レイヤ（ＰＨＹ）は、進行中の（ロング）ＰＵＳＣＨの停止を可能にし、オーバラップするショートグラントにしたがって新しい（優先度の高いショート）ＰＵＳＣＨを送信するべきであり、この図は、シナリオに応じて、ＵＥ内プリエンプションがどのようにネットワーク効率を高度化することができるかを示している。
ＰＤＣＰ複製は、議論するべき別の問題である。ＬＴＥ、ＮＲおよびＥＮ－ＤＣにおける信頼性を改善するための方法として、ＲＡＮ内の多接続が検討される。これらの特徴は、以前は異なるキャリアのリソースをアグリゲートすることによってユーザスループットの改善に着目していたが、３ＧＰＰでの着目点は、最近シフトしてきており、送信信頼性を改善するためにＬＴＥ向け（同様に、ＮＲ向け）の新しい特徴が開発されている。
３ＧＰＰは、ＵＥが複数キャリアを介して単一の基地局に接続するための方法として、Ｒｅｌｅａｓｅ１０でキャリアアグリゲーション（ＣＡ）を導入した。ＣＡでは、アグリゲーションポイントは、媒体アクセス制御（ＭＡＣ）エンティティであり、集中型のスケジューラがパケットを分散させ、例えばすべてのキャリア間のチャネル知識にしたがって、リソースを割り当てられるようにしているが、やはり関与する無線プロトコルのタイトな統合を必要としている。ＤＣまたは多接続では、リソースアグリゲーションは、ＰＤＣＰで起こる。このように、別個のスケジューリングエンティティを有する２つのＭＡＣプロトコルは、互いの相互接続に対する厳密な要件なしに、２つの別のノードで実行することができるが、ユーザスループットの向上を実現することをなお可能にしている。
３ＧＰＰ Ｒｅｌｅａｓｅ１５のＬＴＥおよびＮＲでは、ＣＡおよびＤＣの両方のアーキテクチャ概念が、ＰＨＹ特徴によって与えられる信頼性高度化に対する補完として、信頼性の改善を支援するために再使用される。これは、ＰＤＣＰレイヤで採用されることが決定されている、パケットの複製によって達成される。それによって、例えばＵＲＬＬＣサービスの、入来データパケットは、ＰＤＣＰで複製され、各複製は低レイヤプロトコルＲＬＣ、ＭＡＣ、ＰＨＹで手順を経て、例えば再送信信頼性スキームから個別に恩恵を受ける。最終的に、データパケットはこのように異なる周波数キャリアを介してＵＥに送信され、これは周波数ダイバーシティのために相関のない送信経路を確実にし、異なるサイトからのＤＣ送信の場合、それによりマクロなダイバーシティを与える。その方法を、ＣＡおよびＤＣの両方について、図８５に図示する。
キャリア間の周波数ダイバーシティは、同一キャリア上の物理レイヤによって提供されるダイバーシティスキームを上回る。時間ダイバーシティ、例えば繰り返しスキームと比較して、キャリア間の周波数ダイバーシティは繰り返しの潜在的な時間相関を軽減する優位性を有し、これは例えば一時的なブロッキング状況によってキャリア上で発生する可能性がある。さらには、キャリアダイバーシティは、ＤＣについて図８５に示すように、異なる場所で送信ポイントの配置を許可し、そのため導入される空間ダイバーシティによって送信の潜在的な相関をさらに低減する。
ＰＤＣＰ上でのパケット複製を伴う多接続性は、低レイヤの再送信スキーム（ハイブリッド自動再送要求（ＨＡＲＱ）およびＲＬＣ再送信）を利用することに、あまり依拠しないという優位性を有し、ターゲット信頼性メトリックを達成し、これにより、レイテンシを低下させることが、一定の信頼性で保証される。例えば、ＰＨＹが、ＨＡＲＱ送信ごとに残存誤差確率０．１％を達成すると想定する。このケースの０．１％では、再送信が要求され、余分なＨＡＲＱラウンドトリップタイム（ＲＴＴ）による送信レイテンシを増加させる。パケット複製では、両方の非相関ＨＡＲＱ送信が失敗する確率は、０．１％＊０．１％である。これは、単純に、第１の復号可能なパケット複製は、受容されて送達されるが、第２のものは破棄されるため（ＰＤＣＰにおいて）、このケースの１～１０＾－６では、余分なＨＡＲＱ ＲＴＴのない低レイテンシが達成されることを意味している。この関係の図を、図８６に見ることができ、この図は複製がある場合とない場合の残存誤差を示している。
パケット複製は、ユーザプレーンおよび制御プレーンの両方に適用可能であると考え、ＲＲＣメッセージもＰＤＣＰレイヤで複製することができることを意味している。このように、ＲＲＣメッセージ転送のレイテンシ／信頼性は、改善することができ、例えば、これはハンドオーバ関連のシグナリングが無線リンク障害を回避するために重要である。
さらには、多接続性は、ユーザプレーンデータに対するハンドオーバ中断なく、信頼できるハンドオーバを可能にする潜在性を有している。それにより、ハンドオーバは、２つのステップで行われ得る。すなわち、１つのキャリアが、ソースからターゲットノードに一度に動かされ、そのためＵＥは常に少なくとも１つの接続を維持する。手順の間、パケットが、中断のないＵＥへの送信のために両方のノードで利用可能となるように、パケット複製が採用される場合がある。
ＣＡでのＰＤＣＰ複製をサポートするため、セカンダリＲＬＣエンティティが、複製のサポートで使用される（非スプリット）無線ベアラ用に設定される。図８５を参照されたい。ダイバーシティゲインを確実にするよう、これらの２つのＲＬＣエンティティに関連付けられる論理チャネルに制限を規定することができ、それによって各ＲＬＣエンティティの送信は、設定されたキャリア（プライマリセルまたはセカンダリセル）上で許可されるのみとなる。
さらには、ＰＤＣＰ複製を「スケジューリングツール」として使用すること、すなわち、必要な時にだけ複製をアクティブ化および非アクティブ化することを許可すること、すなわち、動的にスケジューラであること、を許可するために、ＭＡＣ制御要素が指定されている。
Ｒｅｌｅａｓｅ１６では、ＮＲ産業用ＩｏＴ内では、ＮＲにおけるＰＤＣＰ複製に対する高度化が構想され、これは２つより多いリンク上での複製を可能にする。すなわち、ＤＣベースおよびＣＡベースの複製を共に使用することができるか、または２つより多いキャリアでのＣＡベースの複製が、考えられる。さらには、複製効率に関する高度化が、検証される：常に複製するのではなく、オリジナルが既に一定時間飛ばされている場合は、送信機は、複製を送ることを延期することができる。その理由は、複製は、レイテンシバウンドに到達する信頼性を、オリジナルと複製の両方がこのレイテンシバウンド内に受信された時だけ、向上させるという、その目的を果たすためである。複製は、再送信と一緒に送信されるだけである、すなわち、ＮＡＣＫベースで送信されるだけであるシナリオを構想することもできる。すなわち、再送信の信頼性は改善されるが、最初の送信信頼性は同じままである。
表２０は、ＵＰ、ＣＰなど、複製がサポートされるベアラオプションを図示している。
Figure 0007241899000020
参照時間のプロビジョニング
対象となるＮＲ産業用ＩｏＴ特徴は、ＵＥベースのアプリケーション（例えば、イーサネットポートを介してＵＥに接続された産業用ＩｏＴデバイスに常駐する）に、５Ｇネットワーク外部のネットワークに常駐するソースクロックから導出したクロック情報を提供する特徴である。外部のソースクロックは、５Ｇシステム内部の５Ｇシステムクロックに加えて、設けることができる。外部ソースから導出したクロックは、図８７によって示されるような「ユニバーサルドメイン」のコンテキスト内にあるワーキングドメインに対応するワーキングクロックとして見ることができる。
「ユニバーサルドメイン」は、５Ｇシステムクロックに基づいており、工場内（ユニバーサルドメイン）の動作および事象を時系列的にアラインメントするために使用される。ワーキングクロックは、ユニバーサルドメイン内でローカルワーキングドメインをサポートするために使用され、各ローカルワーキングドメインは、マシンのセットから成る。様々なワーキングドメインが、様々なタイムスケールを有する可能性があり、それによる同期の正確性は、ユニバーサルドメイン内で２つ以上のワーキングクロックのサポートを必要とする。
Ｒｅｌｅａｓｅ１５の範囲内では、ＲＡＮ２は主に、単一の参照時間値が無線インターフェースでｇＮＢからＵＥに送達され得る方法に着目しており、複数の参照時間値が１つのＵＥに伝達される必要があるユースケースを懸念していなかった、または気付いていなかった。複数の参照時間／ワーキングクロック値をＵＥに送達させる潜在的な必要性に関するＳＡ２／ＲＡＮ３内における進行中の議論が、この領域でさらなる高度化を進めるために継続されている。
５Ｇシステムは、非常に正確かつ安定しているクロックソース（例えば、ＧＰＳ時間）に基づいており、参照時間情報としてｅＮＢおよびＵＥへの送達を含め、必要に応じて５Ｇネットワークを通じて分散され得る内部的な５Ｇクロックをサポートしている。５Ｇシステムは、外部ノード（本明細書ではこれ以上考えない）から参照時間情報を獲得することも可能である。ＬＴＥ Ｒｅｌｅａｓｅ１５は、参照時間情報（ｅＮＢで利用可能であると想定する）の単一のインスタンスを、以下のように、またＢＳ ＳＦＮ送信を示している図８８に図示されるように、ＲＲＣメッセージおよびＳＩＢベースの方法の両方を使用してＵＥへ送達するための方法をサポートする：
・ｅＮＢは、まず参照時間値を獲得する（例えば、５Ｇネットワーク内部のＧＰＳ受信機から）
・ｅＮＢは、獲得した参照時間を、システムフレーム構造内の特定の基準点（例えば、ＳＦＮｚの終わり）がＢＳアンテナ基準点（ＡＲＰ）（図８８の基準点ｔＲを参照されたい）において発生した時に取ると予測される値に修正する。
・予測された参照時間値および対応する基準点（ＳＦＮｚの値）を含むＳＩＢ／ＲＲＣメッセージは、次いでＳＦＮｘの間、送信され、ｔＲに先立ってＵＥによって受信される。
・ＳＩＢ／ＲＲＣメッセージは、基準点ｔＲに適用可能な参照時間の値に関する不確定性値を示す場合がある。不確定性値は、（ａ）ｅＮＢ実装形態が、基準点ｔＲ（ＳＦＮｚの終わり）が示された参照時間に実際にＡＲＰで発生することを確実にすることができる正確性、および（ｂ）参照時間がｅＮＢによって獲得できる正確性を反映する。
〇（ａ）によって導入される不確定性は、実装形態に特有であるが、無視できるものと期待され、そのためこれ以上は考えない。
〇ＴＳＮノードが参照時間情報のソースである（すなわち、ＴＳＮノードがグランドマスタノードとして機能する）場合、グランドマスタノードおよびｅＮＢにおけるハードウェアタイムスタンピングの使用が（ｂ）に用いられると想定され、このケースでは、グランドマスタクロックをｅＮＢに伝達する際、対応する不確定性が導入されると期待される。
ＮＲ Ｒｅｌｅａｓｅ１６では、上述のようにＬＴＥ Ｒｅｌｅａｓｅ１５に類似の方法が、参照時間情報のソーシングおよびｇＮＢから１つまたは複数のＵＥへの送達に使用されると期待される。しかしながら、ＮＲ Ｒｅｌｅａｓｅ１６は、１つまたは複数のワーキングクロック（ＴＳＮネットワークにおいて外部ノードによってソーシングされる）用のサポートを、補完クロック情報（すなわち、ユニバーサル時間ドメイン用に与えられる参照時間に対して補完的）として導入することも期待される。図８９は、３つの時間ドメインを有する産業用のユースケースを示しており、内部的な５Ｇクロックは、ユニバーサル時間ドメイン（５Ｇ時間ドメインで）に適用可能な参照時間として、ならびにＴＳＮワーキングドメイン１およびＴＳＮワーキングドメイン２に適用可能な２つの補完的なワーキングクロックとしても機能する。
内部的な５Ｇクロック（５Ｇグランドマスタとして示されている）は、無線関連機能のサービングに使用されるため、ｇＮＢおよびＵＥの両方に送達される（しかし、ＵＰＦには利用可能になっていない）。ｇＮＢが内部的な５Ｇクロック（実装形態に特有）を獲得すると、ｇＮＢはそのクロックを、ブロードキャスティング（例えば、ＳＩＢ）方法またはＲＲＣユニキャスティング方法のいずれかを使用して、ＵＥに伝達し得る。Ｕｕインターフェースで送られたＳＦＮは、５Ｇ内部クロックと同期され、その意味では、５Ｇ内部クロックが明示的にＵＥに伝達されなくても、ＵＥは常に５Ｇ内部クロックと同期されることになる。
ｇＮＢは、異なる外部ＴＳＮノードから（すなわち、ＴＳＮワークドメインクロックを制御しているＴＳＮノードから直接）ワーキングクロック情報を受信し、それにより、ＴＳＮネットワークと通信するためのＰＴＰシグナリングおよび複数のＰＴＰドメイン（複数ＰＴＰクロックインスタンス）をサポートするようｇＮＢに要求する。次に、ｇＮＢは、以下の２つの方法のうちの１つを使用して、ワーキングクロック（スタンドアロンのクロックとして、または主要な内部５Ｇクロックに対するオフセットとして）を対応するＵＥに伝達する：
ａ）方法１：ＳＦＮベースの同期
・この送達の方法は、図８９のコンテキスト内でサポートされ、内部５Ｇクロック（黒いクロック）をＵＥに送達するために使用される手法と同一であり、クロック情報は、ＳＦＮフレーム構造における特定のポイントと同期される。
・ｇＮＢは、ＵＥ内のワーキングクロックを、これらのワーキングクロック用の更新値をＵＥに提供しているＰＴＰベースのシグナリングを受信する都度、リフレッシュする必要はない。これは、ＵＥがこれらのクロックのドリフトを、ソースＴＳＮノードで進行中である場合があるクロックドリフト率と比較して高度化された正確性で（内部５Ｇクロックを使用して）管理することができる場合があるからである。最終的な結果としては、ｇＮＢはＴＳＮネットワーク内でワーキングクロック更新が発生する都度、ＵＥにそのような更新を送る必要がないため、ワーキングクロックのメンテナンス用に消費された無線インターフェース帯域幅は低くなる可能性がある。
・この方法では、ｇＮＢは、ワーキングクロックがマッピングされるＳＦＮ構造内での場所にしたがって受信したワーキングクロック情報の値を直接調節し、次いで調節された値をＳＩＢ１６またはＲＲＣメッセージ内で送る。
ｂ）方法２：タイムスタンピング
・この方法（図８０のコンテキストにおいてもサポートされる）では、ｇＮＢは８０２．１ＡＳにしたがって境界クロック機能をサポートし、そのためワーキングクロックのソースノードが送ると決めるといつでもＴＳＮネットワークからワーキングクロックを取得する（ＰＴＰ同期メッセージ交換を使用して）。
・次いで、ｇＮＢは、ワーキングクロック情報（またはそこにある情報のサブセット）を含むＰＴＰメッセージを、より高次レイヤのペイロードとしてＵＥに中継する。
・中継されたＰＴＰメッセージは、ｇＮＢによってＰＴＰメッセージが受信されたポイントで内部５Ｇクロックの値を提供するタイムスタンプも含む。
・中継されたＰＴＰメッセージを受信すると、ＵＥは、それに含まれるワーキングクロックの値を、内部５Ｇクロックの現在の値とやはり中継されたＰＴＰメッセージに含まれるタイムスタンプされた値との差にしたがって調節し、それによりワーキングクロックの現在の値を取得する。
・方法１の通り、ｇＮＢは、ワーキングクロックを含むＰＴＰメッセージを、それをＴＳＮネットワークから受信するたびにＵＥに中継する必要はない可能性がある（ＵＥは、高度化された正確性でこれらのクロックのドリフトを管理することができる可能性があるため）。
・この方法では、ｇＮＢは、受信したワーキングクロック情報の値を調節しないが、ワーキングクロック情報を送るために使用される同一ＰＴＰメッセージに直接挿入されたタイムスタンプ情報でこの値を補完する。次いで、ＳＩＢもしくはＲＲＣメッセージ内で修正されたＰＴＰメッセージを送るか、または帯域幅効率のためにペイロードサイズを低減することができ、代わりにｇＮＢは、未修正のワーキングクロック情報および対応するタイムスタンプを、ＳＩＢ１６またはＲＲＣメッセージにマッピングすることだけができる。
上の方法１および２では、ＵＥがワーキングクロックをエンドステーションに配信する周波数は、実装形態に特有と見ることができる。実施されると、ＴＳＮネットワークで実施されるＰＴＰ同期メッセージ交換を利用する。換言すると、ＵＥは、（ｇ）ＰＴＰプロトコルを使用してＴＳＮエンドステーションに対して、マスタクロックとして作用し、いつワーキングクロック値がエンドステーション内でリフレッシュされるべきかを決定する。ＵＥは、受信するすべてのワーキングクロックを、管理しているすべてのエンドステーションに転送する（すなわち、エンドステーションは、どのワーキングクロックに興味があるかを決定する）。
ＮＲ Ｒｅｌｅａｓｅでは、ＵＰＦ連続ＰＴＰチェーン方法（Ｃｏｎｔｉｎｕｏｕｓ ＰＴＰ Ｃｈａｉｎ Ｍｅｔｈｏｄ）を使用することができる。図９０に図示される、この方法では、ＴＳＮネットワークは、ワーキングクロック情報を送達する目的でＵＰＦとインターフェースし、ＵＰＦからＵＥへの経路は、５Ｇネットワークの右にあるＴＳＮワーキングドメインと５Ｇネットワークの左にあるエンドステーションとの間に仮想的に連続的なＰＴＰチェーンが存在するように、ＰＴＰリンクをエミュレートする（すなわち、ＰＴＰ同期メッセージ交換が、ＵＥとワーキングクロックをサポートしているＴＳＮノードとの間で実施される）。
ＵＰＦは、ワーキングクロック（例えば、図９０の右側にある緑色のクロック）を、各ＵＥにトランスペアレントに中継し、ＵＰＦは、これらのワーキングクロックに、ＰＴＰメッセージが中継されるポイントに適用可能な内部５Ｇクロックの値で、タイムスタンプを与える。
・５Ｇネットワークは、補完的なタイムスタンプ情報をこれらのＰＴＰメッセージに提供する必要が出てくるため、ワーキングクロック情報を含むＰＴＰメッセージをいつ中継するか何らかの気付きを必要とする。
・ＰＴＰメッセージの、ＵＰＦからｇＮＢへの中継に使用されるトランスポートレイヤＰＤＵは、ＰＴＰメッセージがこれらのＰＤＵによって搬送される上位レイヤペイロードをいつ構成するかのインジケーションをサポートするために、潜在的には高度化することができる。これは、無線インターフェース帯域幅効率の点から（すなわち、ＰＴＰメッセージを送達するためのＲＲＣベースのオプションを使用することに加えて）ＳＩＢベースのＰＴＰメッセージペイロードの送信を使用するｇＮＢの可能性が開かれる。
・中継されたＰＴＰメッセージを受信すると、ＵＥは、それに含まれるワーキングクロックの値を、内部５Ｇクロックの現在の値と中継されたＰＴＰメッセージに含まれるタイムスタンプされた値との差にしたがって調節し、それによりワーキングクロックの現在の値を取得する。
・ＵＥは、（ｇ）ＰＴＰプロトコルを使用してＴＳＮエンドステーションに対して、マスタクロックとして作用し、いつワーキングクロック値がエンドステーション内でリフレッシュされるべきかを決定する。ＵＥは、受信するすべてのワーキングクロックを、管理しているすべてのエンドステーションに転送する（すなわち、エンドステーションは、どのワーキングクロックに興味があるかを決定する）。
・この方法は、均一にしたアップリンクとダウンリンクとの遅延を使用する必要がなく、優位的である（アップリンクとダウンリンクとの対称的な遅延はさらなる複雑性を課すためである）。
・しかしながら、可能性として挙げられる不利な点は、ワーキングクロックがＴＳＮネットワーク内で対応するソースノードによってリフレッシュされる頻度が、どの程度の頻度で５Ｇネットワークを通じてＵＥまで中継されるかを決定することである（例えば、ＴＳＮネットワーク内であらゆるワーキングクロックがリフレッシュされるたびに、各ＵＥにクロックリフレッシュ情報を含むユーザプレーンペイロードを個々に送られると、これは無線インターフェース帯域幅に重大なインパクトを与える可能性がある）。
イーサネットヘッダ圧縮
３ＧＰＰシステム上での従来のＩＰトランスポートでは、ヘッダ圧縮、すなわち、ロバストなヘッダ圧縮（ＲｏＨＣ）が指定され、無線インターフェース上で送られるデータ量を削減しており、そのためＲｏＨＣはＵＤＰ／ＴＣＰ／ＩＰレイヤに適用され、ＲｏＨＣ圧縮／解凍は、ＵＥとｇＮＢにおいてＰＤＣＰレイヤによって実施される。
イーサネットトランスポートが構想されるＴＳＮでは、ヘッダ圧縮がやはり適用される可能性がある。これは、イーサネットフレームがｇＮＢとＵＥとの間で伝達されるべきである、イーサネットＰＤＵセッションタイプの場合である。
一般的に、ＵＲＬＬＣでは非常に低い残存誤差率でのロバストな送信が必要とされるとすると、使用される符号レートは、自然に非常に低く、これはＵＲＬＬＣトランスポートが、無線インターフェース上ではリソースコストがかかることを意味している。したがって、可能性としてはイーサネットのヘッダなどの不必要な冗長性の除去を、Ｒｅｌｅａｓｅ１６のＮＲ産業用ＩｏＴ ３ＧＰＰ研究の一部として研究されることが重要である。以下では、イーサネット／ＴＳＮヘッダ構造およびこれらを圧縮することから得られるゲインの分析が行われる。
レイヤ２（Ｌ２）ネットワークにおける転送は、通常Ｌ２フレームヘッダで利用可能な情報に基づいている。各イーサネットフレームは、イーサネットヘッダで始まり、これは先頭の２フィールドとして宛先およびソースＭＡＣアドレスを含んでいる。イーサネットフレームのさらなるヘッダフィールドは、タギングを使用して極めて単純に構築される。ヘッダフィールドの一部は、必須であり、一部は任意選択であり、これはネットワークシナリオに応じたものとなる。
イーサネットフレームには複数のフォーマットがある（例えば、８０２．３、８０２．２ＬＬＣ、８０２．２ＳＮＡＰ）。これらは、ＥｔｈｅｒＴｙｐｅの値とＬｅｎｇｔｈフィールドに基づいて識別される。図９１は、フレームフォーマットの例を示している。
３ＧＰＰネットワーク上でのイーサネットフレーム送信に関しては、イーサネットフレームの一部分は、送信を必要としない（例えば、プリアンブル、ＳＦＤ（開始フレーム識別子）、ＦＣＳ（フレームチェックサム）、ＰＤＵセッションタイプＴＳ２３．５０１について既存の仕様も参照されたい）。イーサネットヘッダのフィールドは、圧縮することができるが、圧縮によって達成されるゲインは、ネットワークシナリオ次第である。イーサネットリンクは、アクセスリンクまたはトランクリンクのいずれかの可能性がある。トランクリンクでは、セッションの数が著しく大きくなり、イーサネットのトポロジ変化によって影響を受け、一時的なフラッディングとなる可能性がある。他方では、アクセスリンクは、Ｌ２セッションの観点からより安定している。イーサネットヘッダ圧縮は、上で例示したように、Ｌ２リンク特有、すなわち、単一のＬ２ホップ（別名、リンク－バイ－リンクベース）をカバーするものでなければならない。
イーサネットヘッダ圧縮用の、以下のフィールドを検討する：ＭＡＣソースおよび宛先アドレス（それぞれ６バイト）、タグ制御情報（６バイト）、ＶＬＡＮタグおよびＥｔｈｅｒｔｙｐｅなどの保持情報。３ＧＰＰネットワーク上でのイーサネットフレームの送信は、イーサネットフレームの一部分の転送を必要としない（すなわち、プリアンブル、ＳＦＤ、ＦＣＳ）。そのため、合計で１８バイトを圧縮することができる。
５Ｇシステムが、イーサネットアクセスリンクとして使用されることを想定すると、限られた数のＬ２セッションのみが存在することになり、３～５バイトまでの圧縮（保守的な想定）が可能であり、図９２に示すように、これは小さなパケットサイズ（ＵＲＬＬＣでは典型的）には有意なゲインとなる。
イーサネット用のヘッダ圧縮が、どのように、そしてどこでサポートされ得るかに関して、以下の問題が生じる可能性がある。
・プロトコルおよび標準化団体は、どれか：３ＧＰＰでは、ＩＥＴＦによって規定されるようなＲｏＨＣが、ＩＰヘッダ圧縮に使用される。イーサネットを考慮しているプロファイルが存在しない。さらには、標準化グループが解散している。静的コンテキストヘッダ圧縮（ＳＣＨＣ）、またＩＥＴＦは、まだアクティブであり、低電力ＷＡＮのユースケース向けにイーサネットヘッダ圧縮を考慮している。また、３ＧＰＰベースのソリューションが、考えられることができる。
・アンカーポイント：現在のＲｏＨＣネットワークアンカーポイントは、ＰＤＣＰを有するｇＮＢである。別の可能性としては、イーサネットＰＤＵセッションがセットアップされたＵＰＦが挙げられる。図９３は、可能なイーサネットヘッダ圧縮アンカーポイントを図示している。
・ＩＰがある場合とない場合：イーサネットヘッダ圧縮を、ＩＰヘッダ圧縮と統合して考慮すべきか、または別個に考慮すべきか。
信頼できる制御プレーン
このセクションでは、信頼できる制御プレーンプロビジョニングのための方法、すなわち、ＵＥとｇＮＢとの間で無線リソース制御（ＲＲＣ）接続をロバストに維持するための方法を、説明する。
まず初めに、制御プレーン、すなわち、ＲＲＣシグナリング（ＳＲＢ）送信はハンドリングされるユーザプレーンデータ送信として無線プロトコル、すなわち、ＲＲＣシグナリングのロバスト性は、上のレイヤ１およびレイヤ２で説明したものと同じ特徴で確立することができる。さらには、ＤＣにおけるスプリットベアラの場合では、ＣＡについてと同様に、ＰＤＣＰ複製も、ＲＲＣシグナリング（ＳＲＢ）にも適用可能である。
以下で分かるように、ＳＲＢシグナリングのロバスト性の他に、ノード障害に対するレジリエンスおよび無線リンク障害（ＲＲＣ）のハンドリングにも対処することができる：ＲＲＣを終了させるネットワークノードの障害の場合では、ＵＥはその接続を失う。さらには、現在のＲｅｌｅａｓｅ１５ ＬＴＥおよびＮＲでは、無線リンク障害のハンドリングは、対称的にハンドリングされない。つまり、プライマリセルに関する障害の場合、無線リンク障害（ＲＬＦ）がトリガされ、接続の中断に至り、この場合、ＵＥは切断し、接続する新しいノードを探索する。しかしながら、セカンダリセルグループ（ＳＣＧ）のプライマリセルに関する障害の場合では、障害インジケーションだけがＲＲＣに送られるが、接続は継続する。ＣＡ複製の場合では、類似の手順が、セカンダリセルの障害用にも実装される。
現在（Ｒｅｌｅａｓｅ１５）のＲＲＣダイバーシティでは２つの障害の場合をハンドリングすることができる。具体的には、ＰＤＣＰ複製を用いるＤＣアーキテクチャでは、セカンダリ無線リンク障害の場合、ならびにＳｇＮＢ全体の故障停止の場合の両方で、ＵＥとの接続性が維持され得る。しかし、プライマリセル障害またはＭｇＮＢ障害の場合では、こうはならない。Ｒｅｌｅａｓｅ１５での、これらの障害のケースを図９４に図示する。
「真のＲＲＣダイバーシティ」を可能とするために、したがって、さらなる高度化を検討する必要がある。すなわち、ノード障害の場合では、ＲＲＣコンテキストの別のノードへの高速／積極的なハンドオーバまたはフェイルオーバのいずれか、そして一般的に、障害がどのセルで発生したかとは無関係に無線リンク障害を対称的にハンドリングする。ＲＬＦの、この対称的なハンドリングは、Ｒｅｌｅａｓｅ１６におけるＮＲ ＷＩ ＤＣ内で検討される。ここで企図される手法は、プライマリセルに関連付けられる障害が発生した場合、障害をトリガし、ＵＥがデータおよび制御シグナリングを中断するのではなく、ＵＥはセカンダリセルを介してネットワークに通知し、ネットワークによって再設定されるまで、そのデータおよび制御の通信を、セカンダリセルを介して継続することである。
コストがかかるが、代替の方法は、複数のコンパニオンＵＥが、同一の産業用デバイスに使用される手法である。この場合、複製および複製排除がＵＥの高次レイヤで生じる。ネットワーク側では、リンク障害、ＵＥ障害またはノード障害の場合では、接続が無関係なコンパニオンＵＥを介して維持することができるよう、ＵＥは（設定オプションとして）異なるｅＮＢ／ｇＮＢに接続される。
ハンドオーバおよびモビリティの高度化
ＲＲＣ接続モードのＵＥでは、Ｒｅｌｅａｓｅ１５のＮＲモビリティメカニズムは、そのＬＴＥベースラインに従い、これを図９５に図示する。ソースｇＮＢは、ＵＥをターゲットｇＮＢにハンドオーバするよう決定する（例えば、ＵＥ測定レポートに基づいて）。ターゲットｇＮＢがＵＥを認めると、ハンドオーバ肯定応答インジケーションがソースｇＮＢに送られ、ソースｇＮＢは直ちにハンドオーバコマンドをＵＥに送る。次いで、ＵＥはハンドオーバコマンドで示された新しいセルにスイッチし、ハンドオーバ完了インジケーションをターゲットｇＮＢに送る。スイッチの間、ＵＥはＭＡＣをリセットし、ＲＬＣを再確立して、必要であればＰＤＣＰを再確立してセキュリティキーを変更する。関与するＲＡＣＨ手順は、コンテンションフリーに設定することができる。つまり、使用されるＲＡＣＨプリアンブルが、手順の間にＵＥに提供される。
ハンドオーバを中断フリーにするために、すなわち、０ｍｓハンドオーバ中断時間を達成するために、ＵＥによるスイッチング時間を、最小化しなければならない。このために、ＬＴＥ Ｒｅｌｅａｓｅ１５（ＮＲではなく）では、デュアルＴｘ－ＲｘのＵＥは、０ｍｓハンドオーバ中断時間を確実にするよう高度化されたメークビフォアブレークなソリューションを実施可能でなければならないことが合意された。このソリューションでは、ＵＥはソースｇＮＢへの接続を、ＵＥがターゲットｅＮＢとデータの送信／受信を開始するまで、維持する。デュアルプロトコルスタックが、ＵＥにおいてどのようにハンドリングされるかの詳細は、ＵＥの実装形態次第であった。
Ｒｅｌｅａｓｅ１６では、ＬＴＥとＮＲの両方で、いくつかのさらなるモビリティ高度化が構想される。ＮＲにおいてハンドオーバ中断時間を削減するために、デュアルＴｘ－Ｒｘ ＵＥについて議論中のいくつかのソリューションがある。その１つが、ＬＴＥライクな高度化されたメークビフォアブレークな手法である（上述）。他の手法は、ＤＣアーキテクチャに依拠して、ＭＮとＳＮとの間でロールスイッチ動作を考慮することにより０ｍｓ「ハンドオーバ」を可能にしている。すなわち、ハンドオーバを行いつつ、ノードのうちの１つに対して常に接続を維持している。ＵＥが、デュアルＴｘ－Ｒｘ機能性を有していないシナリオでは、改善されたＴＡ計算手法に基づく、改善された、つまり高速のＲＡＣＨレスなハンドオーバ、またはソースノードへの高速のフォールバック可能性などの他の手法が構想される。一般的な（ＵＲＬＬＣまたはエアリアルドメインからの様々なシナリオに適用可能な）ハンドオーバロバスト性を改善するために、高ネットワークリソース使用オーバヘッドと引き換えにハンドオーバ障害／ピンポン可能性を低減する条件付きハンドオーバコマンド（一定のネットワーク設定条件が満足された時にハンドオーバ実行を実施する）に基づいたソリューションが予見される。
ハンドオーバによるレイテンシを増加させることなく、またＵＥにおける如何なる能力高度化も必要とせずにモビリティを提供するための一方法は、いわゆるｃｏｍｂｉｎｅｄ ｃｅｌｌのデプロイである。
ｃｏｍｂｉｎｅｄ ｃｅｌｌは、ＥｒｉｃｓｓｏｎのＬＴＥネットワークで市販されている特徴である。ｃｏｍｂｉｎｅｄ ｃｅｌｌでは、複数のリモート無線が同一のベースバンドデジタルユニットに接続され、同一セルをサービングする。これは、複数セクタのキャリアが同一セルに属することを許可する。ｃｏｍｂｉｎｅｄ ｃｅｌｌを使用して、セルのカバレッジを拡張することができ、以下の追加的な優位性を与える：
・様々なアンテナサイトからのオーバラップするカバレッジエリアを可能にすることにより、カバレッジホールを低減する、または排除する。
・ＵＥで受信される信号強度を大きくする。
・アップリンクのマクロダイバーシティを提供する。
・ｃｏｍｂｉｎｅｄ ｃｅｌｌ内で、セル間ハンドオーバの必要性を排除する。
ＵＲＬＬＣは、上で列挙した優位性のすべてから恩恵を受ける。工場フロアでは、例えば、大きな金属面の存在に起因するシャドーイングが問題となる可能性がある。ｃｏｍｂｉｎｅｄ ｃｅｌｌは、アンテナサイトの慎重な選択により、この問題を減少または排除することを助けることができる。ＵＥにおいて信号強度を大きくすることは、マクロダイバーシティ同様に、高信頼性のためには明らかに有益である。ハンドオーバの必要性を回避する、または低減することは、ハンドオーバは典型的には著しくレイテンシを増すため、移動するＵＥにも非常に有益である。さらには、ｃｏｍｂｉｎｅｄ ｃｅｌｌは、屋内－屋外、またはそれ以外ではハンドオーバを（さらに）必要とする屋内－屋内（例えば、数階建てのホール）間の遷移エリアにおいてシームレスなカバレッジを提供する。ｃｏｍｂｉｎｅｄ ｃｅｌｌは、例えば、工場フロアを拡大する時などに望まれる、ネットワークのカバレッジエリアを大きくするために、ロバストなメカニズムを提供する。
最後に、ｃｏｍｂｉｎｅｄ ｃｅｌｌは、キャリアアグリゲーションと共に使用することができ、これは独自の利点をもたらす。
３ＧＰＰ Ｒｅｌｅａｓｅ１５および１６におけるＵＲＬＬＣ特徴の導入を、表２１に要約する。網掛けは、厳密なＵＲＬＬＣ要件を有する産業用ＩｏＴユースケースをサポートするために必要とされる特徴を示しており、網掛けのないものは、効率最適化またはスケジューリング柔軟性のための特徴と考える。
Ｒｅｌｅａｓｅ１５は、１ｍｓレイテンシで信頼性９９．９９９％のＩＭＴ－２０２０ＵＲＬＬＣ要件を遂行するよう、ＬＴＥ ＦＤＤおよびＮＲ、ＦＤＤおよびＴＤＤ両方を可能にするコアＵＲＬＬＣ特徴を確立する。ＬＴＥでは、産業用ＩｏＴに必須な特徴は、ショートＴＴＩ、ＨＡＲＱフィードバックなしの自動繰り返し、ＵＬ半永続スケジューリング（ＳＰＳ）、信頼できるＰＤＣＣＨ、制御プレーン信頼性を達成するためのＲＲＣダイバーシティ、ならびにネットワーク内の複数のデバイス間で等時的動作を可能にする高精度時間同期から成る。ＬＴＥ ＦＤＤは、ＩＭＴ－２０２０ ＵＲＬＬＣ要件を達成するが、ＬＴＥ ＴＤＤは、しかしながら、ＴＤＤ設定の限度のため要件を達成しない。データ送信用の最低の一方向ユーザプレーンレイテンシは、ＬＴＥ ＴＤＤでは４ｍｓに限定される。
Ｒｅｌｅａｓｅ１５ＮＲは、ＬＴＥより高い効率でＩＭＴ－２０２０ ＵＲＬＬＣ要件を満足する。１つのキーとなる高度化は、ＮＲで使用されるスケーラブルなＯＦＤＭヌメロロジーであり、これはショートＴＴＩと組み合わせると、大幅に送信時間を短くする。ＮＲにおける別のキーとなる高度化は、ダイナミックＴＤＤおよび高速ＤＬおよびＵＬスイッチングである。ＮＲ ＴＤＤは、０．５１ｍｓ程度の短さで一方向ユーザプレーンレイテンシを達成することができる。
産業用ＩｏＴサポートの進化は、ＮＲ Ｒｅｌｅａｓｅ１６で継続される。１つの主要な高度化は、ＴＳＮ統合であり、ＮＲが確立された産業用イーサネットプロトコルで動作できるようにしている。ＮＲ Ｒｅｌｅａｓｅ１６はまた、ＵＲＬＬＣ高度化を導入して、ＮＲがよりずっと厳密な要件、例えば、レイテンシ０．５ｍｓで信頼性９９．９９９９％を満足できるようにしている。
Figure 0007241899000021
要約では、ＮＲは、低レイテンシを達成すること、および最初から高信頼性を確実にすることという明確な目的で設計されている。Ｒｅｌｅａｓｅ１５におけるレイヤ１とレイヤ２特徴のアレイは、ＵＲＬＬＣを可能にしている：
・スケーラブルなヌメロロジーおよびショートＴＴＩ。スケーラブルなヌメロロジーを用いて、より大きなサブキャリア間隔を採用することによりＯＦＤＭシンボルおよびスロット持続時間を低減することができる。送信時間間隔は、ミニスロットスケジューリングを使用することによりさらに低減することができ、これはパケットを２ＯＦＤＭシンボル程度の小さい時間単位で送信することを可能にしている。
・スケジューリング設計。ＮＲは頻繁なＰＤＣＣＨ監視をサポートしており、ＤＬおよびＵＬデータの両方についてスケジューリング機会を多くしている。これはレイテンシを低減するのに役立つ。ＵＬでは、設定グラントを使用して、ＵＥが最初にスケジューリング要求を送らなければならず、アップリンクグラントを待機していることによって生じる遅延を排除することができる。混合型のトラフィックシナリオでは、ＮＲはＵＲＬＬＣトラフィックを優先することができる。スケジューラがＵＲＬＬＣ ＵＥをサービングするために十分な無線リソースを有していない事象では、ＮＲは、ＤＬ ＵＲＬＬＣトラフィックのサービングに使用するために、既に割り当てられたｅＭＢＢタイプのリソースをプリエンプトするためのメカニズムを有する。
・高速ＨＡＲＱ。ＤＬデータ送信は、ＨＡＲＱ肯定応答によって完了し、そのため高速ＨＡＲＱのターンアラウンドタイムが、低レイテンシを達成するために必要とされる。ＮＲでは、これはより厳密なＵＥ受信機処理時間要件（すなわち、ＵＥ能力２）を規定すること、およびＵＥがショートＰＵＣＣＨの使用を通じて短い時間間隔でＨＡＲＱ送信を完了できるようにすることによっても促進される。高速ＨＡＲＱターンアラウンドタイムは、低レイテンシに寄与するだけでなく、所与のレイテンシバジェット内でより多くのＨＡＲＱ再送信を許可することによりデータ送信の信頼性またはスペクトル効率を改善するためにも使用することができる。さらには、ＮＲでは、ＨＡＲＱのない繰り返し（ＨＡＲＱフィードバックを期待する前に、送信側がＫ繰り返しを送信する）も採用され、ＨＡＲＱターンアラウンドタイムによって導入される遅延なく信頼性を改善する。
・低レイテンシ最適化のダイナミックＴＤＤ。ＮＲは、非常に柔軟なＴＤＤ設定をサポートし、シンボルレベルでのＤＬおよびＵＬ割り振りスイッチングを可能にしている。
・ロバストなＭＣＳ。低ＢＬＥＲターゲットのための低ＭＣＳおよびＣＱＩオプションを含むことにより、信頼性が高度化される。
加えて、ＲＡＮアーキテクチャオプションが、先に言及した特徴、つまりデータを複数のｇＮＢを通じておよび／または複数キャリアを通じて複製することによる特徴よりも、信頼性を高度化するために利用可能である。
したがって、Ｒｅｌｅａｓｅ１５ ＮＲはＵＲＬＬＣサービスをサポートする確固たる基礎を成す。３ＧＰＰ ＩＭＴ－２０２０自己評価の作業では、Ｒｅｌｅａｓｅ１５ ＮＲは、１ｍｓレイテンシで信頼性９９．９９９％と、十分にＩＭＴ－２０２０ ＵＲＬＬＣ要件を満たすことも確認されている。
Ｒｅｌｅａｓｅ１５における確固たるＵＲＬＬＣ基礎に成り立つものとして、産業用ＩｏＴは、今度はＲｅｌｅａｓｅ１６で着目される。優先されたユースケースには、工場自動化、電力配分、およびトランスポートが含まれる。これらの優先されたユースケースの要件は変わることがあるが、ほとんどの要求の高いユースケースは０．５ｍｓ程度の小さなレイテンシでの信頼性９９．９９９９％を必要とする。さらには、ＮＲ産業用ＩｏＴのキーとなる態様は、ＮＲが確立された産業用イーサネットプロトコルで動作できるようにすることである。産業用イーサネットプロトコルの基礎としてＴＳＮが登場するため、フラッグシップＲｅｌｅａｓｅ１６特徴は「ＮＲとＴＳＮの統合」である。
・Ｒｅｌｅａｓｅ１６でのＮＲは、ＵＥ側のＴＳＮデバイスをネットワーク側のＴＳＮワーキング時間ドメインと無線で同期させるために、ＵＥへの正確な時間参照プロビジョニングをサポートする。
・混合型のＴＳＮトラフィックシナリオにより効率的に対処できるように、設定グラントスケジューリングおよびＵＥマルチプレクシングおよびプリエンプションを高度化することが提案されている。
・ＰＤＣＰ複製は、より効率的に信頼性プロビジョニングをハンドリングするように設計される。
・イーサネットヘッダ圧縮は、ＲＡＮにおけるオーバヘッド削減のために研究されている。
・レイテンシをさらに削減するため、信頼性およびスペクトル効率を改善するため、ならびにマルチプレクシングアップリンク制御および異なるサービスタイプからのデータのハンドリング（例えば、ｅＭＢＢからのデータで多重化されたＵＲＬＬＣ向けの制御、またはその逆）を改善するために、レイヤ１ＵＲＬＬＣ高度化も、やはりＲｅｌｅａｓｅ１６で検討される。
ＴＳＮ統合およびさらなるＵＲＬＬＣ高度化を用いて、ＮＲ Ｒｅｌｅａｓｅ１６は、スマートな無線製造を可能にし、産業デジタル化および変革において新しい時代を先導することに向けて大きく進歩する。
ＴＳＮおよび５Ｇと並ぶ産業用通信技術およびプロトコル
ＴＳＮおよび５Ｇが、将来的な工場および他の産業用ユースケースで基礎的な接続技術となると考えることは広く受け入れられる。しかしながら、ほとんどの産業側関係者は、自身の産業用ＩｏＴのストーリーをグリーンフィールドデプロイメントにおいてゼロから始めない。むしろ、多くの産業用プロセスは、自身の産業規定の接続メカニズムを使用して既に接続されたデバイスを伴っている。これらのデプロイメントを、一般的にはブラウンフィールドと称する。ほとんどのブラウンフィールドデプロイメント（９４％）は有線であるが、特にデータ収集については多くの無線ソリューションも存在している。産業界は、保守的であり、既に行われた投資はガードされている。したがって、多くの場合、著しい付加価値が示されない限り、産業サイトで既存のインフラストラクチャに補完的なソリューションとして導入される新しい技術が必要となる。
産業用ＩｏＴ用のプロトコルスタックは、異なるプロトコルレイヤでの選択に応じて、非常に異なって見える。図９６は、Ｏｐｅｎ Ｓｙｓｔｅｍｓ Ｉｎｔｅｒｃｏｎｎｅｃｔ（ＯＳＩ）プロトコルスタックレイヤにマッピングされる異なるレイヤにおける、いくつかの可能なプロトコル代替を描いている。
全体像をつかむため、この章では、今日使用される有線および無線両方の通信技術を導入する。ブラウンフィールドデプロイメント用の４Ｇおよび５Ｇの使用に関して、２つの態様が重要であり、カバーされる：
・レガシーな有線技術とのインターワーキング（例えば、Ｐｒｏｆｉｎｅｔなど）
・他の無線技術との競合（あらゆるＩＥＥＥ８０２．１１技術など）
さらには、ＯＰＣ－ＵＡおよびＳＥＣＳ／ＧＥＭが、今日工場自動化で使用される２つの通信プロトコルとして導入されており、将来的に主要な役割を果たすことが想定される。
物理的および媒体アクセスレイヤに関して、産業用使用に特化した多くの有線通信技術が過去に開発されていた。最初、いわゆるフィールドバス技術が、例えばＩＥＣ ６１１５８で標準化され、使用されていた。現在、産業用イーサネットソリューションに向けてのシフトが生じており、そのような一例がＰｒｏｆｉｎｅｔである。これらの技術の主な特質は、１ｍｓ以下のタイトな時間制約の下でデータを送達するよう設計されることである。フィールドバスおよびいくつかの産業用イーサネット変形の不利な点は、互いに汎用的な互換性がないこと、およびこれらの技術を実行するための、標準的なオフィスのイーサネット機器を上回る特殊なハードウェアの必要性である。時間センシティブなネットワーキング（ＴＳＮ）は、ＩＥＥＥ標準のセットであり、信頼性と確定的な低レイテンシ能力を標準化されたイーサネット（ＩＥＥＥ８０２．３）上に加える。野望としては、分裂した産業用有線通信技術マーケットに共通標準を確立することである。産業用機器ベンダーの多くが、まさに自身のポートフォリオ用のＴＳＮに向けて動き出しているか、または少なくとも動くことを示している。
イーサネットは他のドメインでも主要な通信標準となってもいるため、産業用イーサネットは、極めてポピュラーとなっており、レガシーなフィールドバス技術よりもマーケットシェアを得ている。安価であること、ならびに共通の部品およびケーブルなどが１つの理由である可能性がある。様々な産業用イーサネット技術は互換性がなく、特殊なゲートウェイまたは類似の追加的な機器の使用なしにはインターワーキングを可能にしないことは、既に言及した。これは、産業用イーサネットが異なる概念を使用して産業用ユースケースの要件を満足するからである。それにもかかわらず、産業用イーサネットにはいくつかの共通事実が存在する：
・産業用イーサネットは、ほとんど常に「スイッチングイーサネット」である
・１００Ｍｂｉｔ／ｓかつ、ｆｕｌｌ－ｄｕｐｌｅｘリンク
・様々なトポロジー（直線状、星形、リング状など）が可能であるが、技術により厳密に規定される場合がある
・冗長化方法（例えば、並列冗長化プロトコル（ＰＲＰ））
・マスタ／コントローラ－スレーブアーキテクチャ
・通信エラーを検出するための機能（パケットロス用のタイマおよびカウンタなど）
図９７は、産業用イーサネットの概念、および産業用イーサネットがどのように標準イーサネットの上で構築されるかを示している。レイヤ２では、いくつかの産業用イーサネット技術は時間スケジュール送信（Ｐｒｏｆｉｎｅｔ ＲＴなど）に基づいており、ネットワーク内での確定的レイテンシを達成している。ネットワークサイクル時間は、技術を促進して比較する（サポートされるネットワークサイクル時間が低いほど、より良好である）ために広く使用されるメトリックである。普通、ネットワークサイクル時間は、サポートされる最小のアプリケーションサイクル時間である（つまり、アプリケーションは、一定のメッセージをネットワークサイクルごとに送信する）。非常に困難なユースケースでは、５０マイクロ秒を下回る、恐ろしく小さいアプリケーションサイクル時間が要求され、例えば、モーション制御に十分な正確さを達成する。例えば、ＥｔｈｅｒＣａｔは、新しいイーサネットレイヤ２を規定して、非常に低いネットワークサイクル時間を達成する。
図９７から分かるように、Ｐｒｏｆｉｎｅｔは異なるフレーバーを有する：
・Ｐｒｏｆｉｎｅｔ ＣＢＡ（コンポーネントベースの自動化）－送信特性および要件があまり厳密ではないプロセス自動化のみに向けたもの
・Ｐｒｏｆｉｎｅｔ－ＩＯ ＲＴ（リアルタイム）
・Ｐｒｏｆｉｎｅｔ－ＩＯ ＩＲＴ（等時的リアルタイム）－この変形は、アプリケーションサイクル時間を３１．２５マイクロ秒までサポートする（ネットワークサイクル時間３１．２５マイクロ秒を使用することにより）
図９８は、Ｐｒｏｆｉｎｅｔにおける時間スケジュール送信の例を示しており、図面は周期的に繰り返される１ネットワークサイクルを描いている。図面では、ネットワークアクセス時間は、厳しいＱｏＳと非ＲＴフェーズの両方を提供するために、サイクリックＩＲＴフェーズとサイクリックＲＴフェーズとの間で共有されており、これはＱｏＳに対する保証のないベストエフォートなフェーズと等価である。Ｐｒｏｆｉｎｅｔは、ＩＥＥＥ１５８８などの時間同期プロトコルを使用して、すべてのノード間で時間の共通概念を確立する。非常に厳しい用途向けに、ＲＴまたは非ＲＴフェーズがまったく関与しない場合がある。ＩＲＴ通信は、常にピュアなレイヤ２通信であり、ＵＤＰ／ＴＣＰ／ＩＰを使用しない。Ｐｒｏｆｉｎｅｔ ＩＲＴフレームを、図９９に図示する。
Ｐｒｏｆｉｎｅｔの場合（ならびに他の技術について）のネットワーク管理は、手作業で事前設定され、普通はすぐにデバイスを追加することはできない。そのため、プラグアンドプレイは、ほとんど可能ではないが、代わりに産業界では間違いなく弱点である、これらのネットワークをセットアップするために必要とされるいくつかの専門技術が存在する。
同じように、産業用イーサネット機器は、標準的なイーサネットとは異なる：
・特定のスイッチ－頑丈で、ＱｏＳ最適化された、高度に利用可能な実装形態
・ほとんどの技術は、特定のＡＳＩＣを必要とし、いくつかはソフトウェアに基づいており、一部のベンダはやはり多技術ＡＳＩＣ（例えば、ＨＭＳ、Ｈｉｌｓｃｈｅｒ、ＡＤ）を販売している
・普通、複数の技術をサポートするために、ＰＬＣは様々な通信モジュールを提供する
・（センサからロボットまでの）デバイスは、普通、技術インターフェースの限定されたセットだけを提供する
産業用イーサネット技術の一部は、恐らくは消滅し、遅かれ早かれＴＳＮ製品によって取って代わられる。それにもかかわらず、製品ライフサイクルは、産業界では非常に長い。ＴＳＮは、既存の産業用イーサネット技術でも使用される多くの特徴を採用する。さらには、ＰｒｏｆｉｎｅｔおよびＥｔｈｅｒＣａｔを支える組織は、ＴＳＮに伴う運用がどのように機能するかを説明する白書を既に発行した。これらの組織は、ＴＳＮをＰｒｏｆｉｎｅｔおよび他の技術が共存し得る共通のインフラストラクチャとして考える可能性がある。
産業用イーサネットが今日デプロイされる方法は、島と類似している。高ＱｏＳは、そのような島内部でのみ保証することができる。１つの島は、１つの通信技術、例えばＰｒｏｆｉｎｅｔを使用してデプロイされる。普通、プログラム可能論理コントローラ（ＰＬＣ）は、島のマスタとして使用される（例えば、Ｐｒｏｆｉｎｅｔマスタ）。島は、普通、同一の店舗フロアだけにある、いくつかのデバイスから成る。例えば、Ｐｒｏｆｉｎｅｔとセルラとのインターワーキングは、これらのデバイスのうち１つ（例えば、ＰＬＣ）が仮想化される場合に（中央リンク）、または、１つのデバイス（島へのデバイス）もしくはゲートウェイを使用するデバイスのグループ（島間リンク）が店舗フロアの島から分離されている場合に、特に関連性がある。Ｐｒｏｆｉｎｅｔと、例えばＬＴＥとのインターワーキングは、既に一部の研究的な概念実証研究で示されている－ＬＴＥネットワークの設定に応じて、アプリケーションサイクル時間が一定限度（例えば、一例として３２ｍｓ）を上回る場合、これは可能である。
レイテンシおよびパケット誤り率（ＰＥＲ）の点における、セルラネットワークに対する要件は、例えばＰｒｏｆｉｎｅｔなどの通信技術によってセットされず、それらを使用するアプリケーション、または個別に使用されるアプリケーションサイクル時間によってセットされる。たいてい、サポートされる最も低いネットワークサイクル時間は、産業用通信技術向けのＫＰＩである。ＰｒｏｆｉｎｅｔＩＲＴはネットワークサイクル時間を３１．２５ｕｓｅｃまでサポートするが、ずっと低い要件のアプリケーション用でも使用されている（つまり、これよりもずっと高いアプリケーションサイクル時間）。ＰｒｏｆｉｎｅｔＩＲＴは、最大４ｍｓのアプリケーションサイクル時間に使用することができる。Ｐｒｏｆｉｎｅｔの場合では、より高いネットワークサイクル時間のみをサポートするＲＴバージョンは、とにかく、より関連性があるように思われ、少なくとも産業用パートナにより常にあらゆるトライアルで使用された。
他の無線ソリューションは、５Ｇと同時に、この分野に入ろうとしている。１つの興味深い技術は、ＭｕｌｔｅＦｉｒｅであり、これは産業用接続向けに大量に販売されている。技術としてのＭｕｌｔｅＦｉｒｅは、ＬＴＥに非常に類似しているが、免許不要スペクトル上のみで動作するため、システム内でスケジューリングおよびモビリティ上の利点がある。デバイスの利用可能性は、現時点ではＭｕｌｔｅＦｉｒｅにとって課題である。ＷｉＭＡＸは、産業界における無線技術として部分的に使用されてきたが、経済規模が小さいため問題があった。
産業用グレードのＷｉ－Ｆｉは、産業用デバイスを接続する際、フットプリントが小さい。信頼性およびレイテンシの問題は、実装を通じて対処される。グローバルな証明書は存在せず、ソリューションはむしろベンダ特有であり、相互動作しない。より一般的には、ラップトップ、タブレット、および携帯電話からの従業員用インターネットアクセスを許可するために、産業用空間には常時Ｗｉ－Ｆｉがデプロイされる。この接続は、店舗フロアの人物には貴重で重要である。
図１００は、増大する信頼性需要および増大するエンドツーエンド（Ｅ２Ｅ）のレイテンシ需要に関して、Ｗｉ－Ｆｉ、ＭｕｌｔｅＦｉｒｅ、ＬＴＥ、および５Ｇ ＮＲの間の推定される違いを描いている。例示のユースケースを図面に配置して、おおまかにそれぞれにどの種類の要件が遂行される必要があるかを示す。
無線センサネットワークを使用して、センサデータを収集し、機械類を監視する。ベンダ特有のソリューションとしての産業用のＢｌｕｅｔｏｏｔｈ実装形態が存在する。典型的には、Ｂｌｕｅｔｏｏｔｈは、近距離で機械類から読取り値を獲得するための個人用の接続として使用される。連続的な接続のためにゲートウェイをデプロイすることに対して興味が高まっている。また、産業用途にＩＥＥＥ８０２．１５．４プロトコルの多くの様々な変形が存在する。最も周知のものとしては、ＷｉｒｅｌｅｓｓＨＡＲＴおよびＩＳＡ１００．１１ａがあり、これらは産業界関係者によって規定され、認証される。確定論および信頼性をＩＥＥＥ８０２．１５．４無線インターフェースにもたらすべく、６ＴｉＳＣＨがＩＥＴＦによって標準化されている。
ＩＯ－Ｌｉｎｋ無線標準は、１０＾－９のＰＥＲを達成して５ｍｓまでのサイクル時間をサポートできると言われているため、同様に興味深い場合がある。しかしながら、スケーラビリティが限定され、通信範囲が限定されている。
ＭｕｌｔｅＦｉｒｅは、免許不要スペクトル上で十分に動作するＬＴＥベースの技術である。ＭｕｌｔｅＦｉｒｅの主なゴールは、免許不要スペクトルにおいて、Ｗｉ－Ｆｉライクなデプロイメントの容易さで、ＬＴＥライクなパフォーマンスを実現することである。ｅＬＡＡと比較して、ＭｕｌｔｅＦｉｒｅ ＲＡＮは、独立的な動作を有するように設計された。特に、ＭｕｌｔｅＦｉｒｅは、免許不要スペクトル上で、すべての制御シグナリングおよびデータシグナリングを実施する。現在、ＭｕｌｔｅＦｉｒｅは無線アクセス技術（ＲＡＴ）としてｅＭＴＣ－ＵおよびＮＢ－ＩｏＴ－Ｕをさらに含み、モバイルブロードバンドからマシンタイプ通信に渡る広範囲な用途をサポートする。
ＭｕｌｔｅＦｉｒｅ（ＭＦ）は、３ＧＰＰ ｒｅｌｅａｓｅ１３および１４ＬＡＡに基づいている、キャリア選択、間欠送信、およびリッスンビフォアトーク（ＬＢＴ）の原理を用いる。ＭｕｌｔｅＦｉｒｅは、５．０ＧＨＺグローバルスペクトルをターゲットとしており、いくつかの追加を伴ってＲｅｌｅａｓｅ－１３ＬＢＴ手順を利用する。ＬＴＥプロトコルスタックと比較して、ＭＦはＵＬ、ＤＬ、物理レイヤ、ＤＲＳ送信、ＳＩＢ－ＭＦブロードキャストおよびその内容、ＲＡＣＨ手順に一意であり、追加的なＳ１、Ｘ２情報シグナリングを有する。
ＭｕｌｔｅＦｉｒｅ１．０は、グラントアップリンクアクセス、ワイドバンドカバレッジ拡張（ＷＣＥ）、自律型モビリティ（ＡＵＭ）、ｓＸＧＰ１．９ＧＨＺサポート、ｅＭＴＣ－ＵおよびＮＢ－ＩｏＴ機能性などの追加的な特徴でさらに拡張された。これらの特徴は、より産業向けのデプロイメントをターゲットにしており、マシンタイプ通信をサポートしている。
グラントアップリンクアクセスは、ＵＬ制御シグナリングオーバヘッドをさらに削減し、低負荷シナリオで非常に良好に動作する。この特徴は、３ＧＰＰ Ｒｅｌｅａｓｅ１５で規定されるような、３ＧＰＰ特徴である自律的ＵＬに基づいている。ＷＣＥ特徴は、カバレッジをレガシーＭＦ ＭＢＢ動作に比べて最大８ｄＢに大きくすることを目標としている。免許スペクトルと比べて、ＬＢＴおよびＲＲＭとＲＬＦ用のいくつかの測定値は、モビリティを非常に困難なものにする。これに対処すべく、ＭＦは、高速変化チャネル品質およびハンドオーバを扱うためにＡＵＭを指定しており、ＵＥおよび潜在的なｅＮＢは、ハンドオーバ関連パラメータで事前設定することができる。特に、ＵＥは、最大８ＡＵＭセルに対し、ＡＵＭ関連モビリティ支援情報で設定することができる。これらのセルは、基本的には潜在的な候補ターゲットセルであり、潜在的なＵＥコンテキストで用意されている。ＵＥに対して共有されるパラメータは、周波数および候補ターゲットセルの物理セルＩＤ（ＰＣＩ）を含む。
大規模なＩｏＴユースケースをサポートするために、ＭＦは、２．４ＧＨＺ周波数帯域に適用される１．４ＭＨＺキャリア帯域幅に基づいて３ＧＰＰ Ｒｅｌ－１３ｅＭＴＣ技術を適応させた。しかしながら、２．４ＧＨＺ周波数帯域では、規制は米国、欧州、日本、および中国に一意である。この中で、欧州のＥＴＳＩは、厳しい規則を有しており、規制にしたがうため、周波数ホッピングメカニズムが採用された。ｅＭＴＣ－ライクなパフォーマンスを可能とするため、２つの固定時間、アンカーチャネルである第１の時間、およびデータチャネル滞留である第２の時間を有する、新しい時間－周波数フレーム構造が規定される。データチャネルには、たいていＬＢＴが先行するＵＬ／ＤＬ送信が含まれ、常にＤＬ送信で開始する。アンカーチャネルは常に同一のチャネルに留まり、いくつかのアンカーチャネルは、送信するためにｅＮＢが１つを選択できるものから規定される。データチャネルは、周波数ホッピングを使用して送信を滞留させるが、これはホッピングチャネル間１．４ＧＨＺ間隔で８２．５ＭＨＺを５６チャネルに分離することによって行われる。仕様は、現在、免許不要帯域でＲｅｌ－１３ＮＢ－ＩｏＴサポートをさらに拡張するようファイナライズされている。
ＩＥＥＥ８０２．１１技術ファミリは、一般にはＷｉ－Ｆｉと称され、無線インターネットアクセスを我々の家庭に提供するためのポピュラーな技術である。先のセクションで列挙した産業用グレードのＷｉ－Ｆｉソリューションは、典型的にはＩＥＥＥ８０２．１１Ｗｉ－Ｆｉに対する修正版である。産業用グレードのＷｉ－Ｆｉは、たいていＭＡＣレイヤが主に削がれたＩＥＥＥ８０２．１１Ｗｉ－Ｆｉ認証チップセットに基づいている。特に、Ｗｉ－ＦｉにおけるＬＢＴメカニズムは、スペクトル規制に必須であるのにしばしば除去される。それぞれの産業用グレードのＷｉ－Ｆｉは他とは独立的に開発されるため、産業用グレードのＷｉ－Ｆｉでの問題は、相互運用性である。対照的に、ＩＥＥＥ８０２．１１は周知の標準であり、互いに良好に動作するよう異なるベンダからの製品を期待することができる。このセクションでは、簡略にいくつかのメカニズムを考える：チャネルアクセス（レイテンシに大きくインパクトを与える）、サービス品質（優先順にインパクトを与える）、およびリンク適応（スペクトル効率）。
Ｗｉ－Ｆｉのチャネルアクセスを理解するためには、免許不要帯域における設計原理の一部に対する背景を理解しなければならない。免許不要帯域は、免許帯域とは反対に、典型的には物理的な制御エンティティが存在しない。スペクトル規則のセットがあるが、これらの規則にしたがう誰もが、無線媒体にアクセスするための同じ権利および優先順を有する。したがって免許不要帯域における主要な設計原理は、協調されていない、競争ベースのチャネルアクセスである。これは、ＣＳＭＡ／ＣＡ（搬送波感知多重アクセス／衝突回避方式）と呼ばれる。基礎的な理念は、それぞれのチャネルアクセスに関連付けられる乱数があり、乱数がバックオフ時間を決定することである。チャネルアクセスに失敗するたびに、この乱数は大きくなる。このチャネルアクセスの結果、ラウンドトリップレイテンシにランダムなファクタが含まれる。無線媒体の大部分が未使用となる場合、レイテンシは非常に低いが、無線媒体がかなり占有される場合、レイテンシが非常に大きくなる可能性がある。産業用シナリオでは、レイテンシにおける、この不確定性が懸念事項となる。典型的なチャネルアクセスおよびデータ送信を図１０１に示す。Ｗｉ－Ｆｉにおけるチャネルアクセスは、保証されるレイテンシが可能ではない主な理由であり、これは規制に準拠する必要がある特徴である。セルラ技術の強みは、スペクトルの排他的な使用のために設計されていることであり、これは保証されたレイテンシが得られることを意味している。
ランダムなバックオフに加えて、Ｗｉ－Ｆｉではフレーム間間隔時間（ＩＦＳ）がある。フレーム間間隔時間には主に３つある：ショートＩＦＳ（ＳＩＦＳ）、ＰＣＦ（地点協調機能）ＩＦＳ（ＰＩＦＳ）、ＤＣＦ（分散協調機能）ＩＦＳ（ＤＩＦＳ）。要約すると、ＩＦＳ＜ＰＣＦ＜ＤＩＦＳであり、ＩＦＳは、特殊な応答フレーム、つまりＡＣＫに使用される。ＰＣＦは、一定の優先フレームに使用され、ＤＩＦＳは標準的なフレームに使用される。
Ｗｉ－Ｆｉは、高度分散チャネルアクセス（ＥＤＣＡ）と呼ばれるサービス品質（ＱｏＳ）メカニズムを有する。ＥＤＣＡは、主にチャネルアクセスを実施する際のランダムバックオフ時間を調節することに基づいているが、調停（ａｒｂｉｔｒａｔｉｏｎ）ＩＦＳ（ＡＩＦＳ）と呼ばれる新しいＩＦＳも導入する。高い優先度は、バックオフ時間が低減されていることにより、平均的に優先アクセスを得る。しかしながら、それぞれのチャネルアクセスには、なおランダム性があり、保証が与えられない可能性があることに留意されたい。ＥＤＣＡに導入される優先クラスには４つ存在する：音声、動画、ベストエフォート、およびバックグラウンド。異なる優先クラスがどのようにチャネルアクセスを得ることができるかの図を、図１０２に示す。それぞれの優先クラスは、個別のＩＦＳを有し、ランダムバックオフが異なることに留意されたい。
Ｗｉ－Ｆｉにおけるリンク適応は、十分なデータ再送信に基づいている。パケットの復号に失敗した場合、パケットは再度送られる（恐らくは別の符号化および変調により）。Ｗｉ－Ｆｉにおけるデータパケットは内蔵型であり、パケットが失敗するとすべての情報が典型的には捨てられることに留意されたい。これは、初期送信の間に受信したソフトな情報が再送信の間に受信したソフトな情報と合成されるＬＴＥまたはＮＲと比較して、主たる不利な点である。ソフト合成によるゲインは、再送信が以前に符号化されたビット（Ｃｈａｓｅ合成と呼ばれる）の繰り返しであるか、または追加的なパリティビット（増分的冗長性と呼ばれる）が送信されるかに応じて、３～６ｄＢのオーダである。
選択される符号化および変調は、典型的にはＭｉｎｓｔｒｅｌアルゴリズムによって選ばれる。Ｍｉｎｓｔｒｅｌアルゴリズムは、様々な符号化および変調で送られたパケットに対して試行錯誤の統計を続けることにより機能し、スループットを最大化するよう試みる。アルゴリズムは、干渉がほとんどない静的な環境で良好に機能するが、チャネル特性が高速に変化する場合では悪化する。結果としてこれは、図１０３に示されるように典型的にはＭｉｎｓｔｒｅｌが改善されたチャネルに適合するのが遅くなり、この図は単一リンク無線シミュレータによるＭｉｎｓｔｒｅｌアルゴリズムのシミュレーションを図示している。
ＩＰ／イーサネットレイヤ上の産業用サービスは、多様なプロトコルを使用して手元のタスクを達成する。参照文献は、制約アプリケーションプロトコル（ＣｏＡＰ）、Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）およびＨＴＴＰ／２、Ｍｅｓｓａｇｅ Ｑｕｅｕｅ Ｔｅｌｅｍｅｔｒｙ Ｔｒａｎｓｐｏｒｔ（ＭＱＴＴ）、Ｏｐｅｎ Ｃｏｎｎｅｃｔｉｖｉｔｙ Ｆｏｕｎｄａｔｉｏｎ（ＯＣＦ）、リアルタイムシステム向けのＤａｔａ Ｄｉｓｔｒｉｂｕｔｉｏｎ Ｓｅｒｖｉｃｅ（ＤＤＳ）などのプロトコルを紹介している。以下では、産業用領域における主なプロトコルのうちの１つ、すなわち、ＯＰＣ ＵＡを手短に紹介する。最後に、半導体産業で使用されるＳＥＣＳ／ＧＥＭを、簡単に見る。
上で紹介したように、通常、レガシーな産業用通信技術同士のインターワーキングは可能ではない。結果として、エンドカスタマおよびデバイス製造業者は、製作、実行、診断、維持、および在庫の維持が必要な多くの技術に直面している。製品およびサービスの利用可能性は広く満足できるものであるが、複数のソリューションを扱うことは、途方もないコストを生み出し、ＩｏＴ能力を限定する。ＯＰＣ－ＵＡ（Ｏｐｅｎ Ｐｌａｔｆｏｒｍ Ｃｏｍｍｕｎｉｃａｔｉｏｎ－Ｕｎｉｆｉｅｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）は、これらの問題に対処しようとするものである。ＯＰＣ－ＵＡは、次世代のＯＰＣ技術である。オリジナルのＯＰＣ「ＯＰＣ Ｃｌａｓｓｉｃ」よりも良好なセキュリティおよび完全な情報モデルを提供するはずである。ＯＰＣ Ｃｌａｓｓｉｃは、（元々は）Ｍｉｃｒｏｓｏｆｔによる自動化向けに良く確立されたプロトコルである。ＯＰＣ－ＵＡは、エンタープライズタイプのシステムと、実世界データと対話する制御、監視デバイス、およびセンサの種類との間でデータを移動するために、非常に柔軟で適合可能なメカニズムであると言われる。ＯＰＣ－ＵＡは、プラットフォーム独立的であり、複数のベンダによるデバイス間の情報のシームレスな流れを確実にする。ＯＰＣ Ｆｏｕｎｄａｔｉｏｎは、この標準の開発および維持の責任を負う。図１０４は、ＯＰＣ－ＵＡのプロトコルスタックを図示している。
ＴＳＮでの使用のために、ＯＰＣ－ＵＡ標準は、より確定的であるよう適合され、一定のＴＳＮ特徴をサポートする。図１０５は、ＴＳＮ上のＯＰＣ－ＵＡの使用を図示している。一般に、ＴＳＮネットワークインフラストラクチャは、ハードなリアルタイムからベストエフォートまでのすべてのタイプの産業用トラフィックを、同時的に搬送することができるが、それぞれのタイプの個々の性質を維持する。ＯＰＣ－ＵＡ ＴＳＮイニシアチブは、発行者－サブスクライバ通信モデル、およびＴＣＰ／ＵＤＰ／ＩＰによらないＯＰＣ－ＵＡの使用を使用する。
ＯＰＣ－ＵＡは、ＴＳＮにおいて設定－プロトコルとして使用されるとも想定される。
ＯＰＣ－ＵＡおよびＴＳＮのタイムラインに関して：Ｑ４ ２０１８には、ほとんどの産業用自動化サプライヤ（Ｓｉｅｍｅｎｓ、Ｂｏｓｃｈ、Ｃｉｓｃｏ、ＡＢＢ、Ｒｏｃｋｗｅｌｌ、Ｂ＆Ｒ、ＴＴＴＥｃｈなどを含む）は、「現場レベルまでのＴＳＮを含むＯＰＣ ＵＡ」イニシアチブをサポートしているとの通知があった。作業は、産業用自動化に向けてＴＳＮ用の共通プロファイルを規定するＩＥＣ／ＩＥＥＥ６０８０２における作業に密接に連携すると言われる。現在、２０２１年の間に、６０８０２における作業を結論付けるよう計画されており、これは、恐らくＯＰＣ－ＵＡおよびＴＳＮを説明するいくつかの最終文書を発行する同じ日となる可能性がある。
ＳＥＭＩ（以前、国際半導体製造装置材料協会として知られた）標準は、ＳＥＭＩ装置通信スタンダード／包括的装置モデル（ＳＥＣＳ／ＧＥＭ）を規定し、ＳＥＣＳ／ＧＥＭは装置がデータ通信をホストするためのプロトコルインターフェースを提供する。ＳＥＭＩの目的は、半導体製造プラント、別名ｆａｂにおける電子機器製造向けの製造サプライチェーンをサービングすることである。
ＳＥＣＳ／ＧＥＭは、半導体産業で使用されるＯＰＣ ＵＡに対する代替である。仕様は、工場内で装置がどのようにしてホストと通信するかを規定した。
産業用ＩｏＴに対する具体的な応用
以下は、産業用ＩｏＴのコンテキストで上述の、技術および技法のいくつかの応用の、詳細な議論である。もちろん、これらの応用はこのコンテキストに限定されないことを諒解されたい。リソースのスケジューリング、５Ｇネットワークにおける時間センシティブなデータストリームのハンドリング、ＴＳＮ用のシステムサポートの検出、様々なネットワークからの異なるタイミングのハンドリング、ならびにデータ圧縮および解凍のための技法を含めて、いくつかの異なる応用が説明される。さらには、これらの技法のいくつかの組合せを説明する。しかしながら、ある要因または他の産業的なセッティングの特殊な必要性に対処するために、これらの技法のいずれも、他の技法のいずれか、同様に上述の他の技法および技術のうちのいずれか１つまたは複数と組み合わせることができることを諒解されたい。
ＲＡＮにおけるリソースのスケジューリング
上で議論したように、５Ｇは、Ｌｏｎｇ－Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ（ＬＴＥ）および／または新無線（ＮＲ）技術を使用した無線通信に基づいているが、ＴＳＮは、ＩＥＥＥ８０２．３イーサネット標準、「ベストエフォート型」のサービス品質（ＱｏＳ）向けに設計された無線通信標準に基づいている。ＴＳＮは、レガシーなイーサネットパフォーマンスをより確定的にすることを意図された特徴の集合を説明しており、時間同期、低レイテンシ送信の保証、および信頼性の向上を含む。今日利用可能なＴＳＮ特徴は、次のカテゴリにグループ化することができる（ＩＥＥＥ仕様に関連付けて以下で示す）：
・時間同期（例えば、ＩＥＥＥ８０２．１ＡＳ）；
・低く境界付けされたレイテンシ（例えば、ＩＥＥＥ８０２．１Ｑａｖ、ＩＥＥＥ８０２．１Ｑｂｕ、ＩＥＥＥ８０２．１Ｑｂｖ、ＩＥＥＥ８０２．１Ｑｃｈ、ＩＥＥＥ８０２．１Ｑｃｒ）；
・超高信頼性（例えば、ＩＥＥＥ８０２．１ＣＢ、ＩＥＥＥ８０２．１Ｑｃａ、ＩＥＥＥ８０２．１Ｑｃｉ）；
・ネットワーク設定および管理（例えば、ＩＥＥＥ８０２．１Ｑａｔ、ＩＥＥＥ８０２．１Ｑｃｃ、ＩＥＥＥ８０２．１Ｑｃｐ、ＩＥＥＥ８０２．１ＣＳ）。
図１０６、図１０７、および図１０８に図示されるように、ＴＳＮネットワークの設定および管理は、様々な方法で実装することができる。より具体的には、図１０６～図１０８は、ＩＥＥＥ標準８０２．１Ｑｂｖ－２０１５で指定されるように、それぞれ分散型、集中型、および十分に集中型の時間センシティブなネットワーキング（ＴＳＮ）設定モデルを図示するブロック図である。ＴＳＮネットワーク内では、通信エンドポイントは、「トーカ」および「リスナ」と呼ばれる。トーカとリスナとの間にあるすべてのスイッチおよび／またはブリッジは、ＩＥＥＥ８０２．１ＡＳ時間同期などの一定のＴＳＮ特徴をサポートすることができる。「ＴＳＮドメイン」は、ネットワーク内で同期されるすべてのノードを含み、ＴＳＮ通信は、そのようなＴＳＮドメイン内でのみ可能である。
トーカとリスナの間の通信は、ストリーム内にある。それぞれのストリームは、トーカおよびリスナの両方で実装されるアプリケーションのデータレートおよびレイテンシ要件に基づいている。ＴＳＮ設定および管理特徴を使用して、ストリームをセットアップして、ネットワーク全体のストリームの要件を保証する。図１０６による分散型のモデルでは、トーカおよびリスナは、例えばＳｔｒｅａｍ Ｒｅｓｅｒｖａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＳＲＰ）を使用して、ＴＳＮネットワーク内のトーカからリスナまでの経路に沿うすべてのスイッチにおいてＴＳＮストリームをセットアップおよび設定することができる。
それにもかかわらず、いくつかのＴＳＮ特徴は、図１０７に示されるような集中型ネットワーク設定（ＣＮＣ）と呼ばれる中央管理エンティティを必要とする場合がある。ＣＮＣは、ＴＳＮストリームごとにネットワーク内のスイッチを設定するために、例えばＮｅｔｃｏｎｆおよびＹＡＮＧモデルを使用することができる。これは、ＴＳＮネットワークにおいて確定的レイテンシでデータトランスポートを可能にする、時間ゲートされたキューイング（ＩＥＥＥ８０２．１Ｑｂｖで規定される）の使用を促進することもできる。各スイッチにある時間ゲートされたキューイングを用いて、精密なスケジュールにしたがってキューは開く、または閉じ、それにより高優先度パケットが最小のレイテンシとジッタで通過できるようにしている。もちろん、パケットは、ゲートが開くようにスケジュールされるよりも早く、スイッチイングレスポートに到達する場合がある。図１０８に示される十分に集中型のモデルは、さらに集中型ユーザ設定（ＣＵＣ）エンティティを含み、リスナとトーカの接触ポイントとして使用される。ＣＵＣは、ストリーム要件およびエンドポイント能力をデバイスから収集して、直接ＣＮＣに通信する。ＩＥＥＥ８０２．１Ｑｃｃには、ＴＳＮ設定についてのさらなる詳細が与えられている。
図１０９は、図１０８に示される完全に集中化された設定モデルに基づいている、例示的なＴＳＮストリーム設定手順のシーケンス図を示している。図１０９において、ナンバリングされた動作は以下の説明に対応する。それでも、数値ラベルは、動作の順序を指定するというよりも、説明のために使用される。換言すると、図１０９に示される動作は、様々な順序で実施することが可能であり、組み合わせておよび／または分割して、図面に示される順序とは異なる動作にすることが可能である。
１ ＣＵＣは、例えば産業用アプリケーションならびに／または時間センシティブなストリームを交換するデバイスおよび／もしくはエンドステーションを指定するエンジニアリングツール（例えば、プログラム可能論理制御（ＰＬＣ））から、入力を受信することができる。
２ ＣＵＣは、ユーザトラフィックの期間／間隔およびペイロードサイズを含む、エンドステーションおよびＴＳＮネットワーク内のアプリケーションの能力を読み取る。
３ 上記の情報に基づいて、各ＴＳＮストリーム、ストリームランク、およびＵｓｅｒｔｏＮｅｔｗｏｒｋ要件用の識別子として、ＣＵＣはストリームＩＤを作成する。ＴＳＮネットワークでは、ストリームＩＤは、ストリーム設定を一意に識別して、ＴＳＮリソースをユーザのストリームに割り振るために使用される。ストリームＩＤは、２つのタプルから成る：１）ＴＳＮトーカに関連付けられるＭａｃＡｄｄｒｅｓｓ、２）ＭａｃＡｄｄｒｅｓｓで特定されたエンドステーション内で複数のストリームを区別するためのＵｎｉｑｕｅＩＤ。
４ ＣＮＣは、例えば、リンクレイヤ発見プロトコル（ＬＬＤＰ）およびあらゆるネットワーク管理プロトコルを使用して、物理的なネットワークトポロジを発見する。
５ ＣＮＣは、ネットワーク管理プロトコルを使用して、ＴＳＮネットワーク内のブリッジ（例えば、ＩＥＥＥ８０２．１Ｑ、８０２．１ＡＳ、８０２．１ＣＢ）のＴＳＮ能力を読み取る。
６ ＣＵＣは、ネットワークリソースを設定するために、１トーカから１リスナに向けたＴＳＮストリームのためのブリッジにおいてジョイン要求を開始する。
７ トーカおよびリスナのグループ（ＴＳＮストリームを指定する要素のグループ）は、ＩＥＥＥ８０２．１Ｑｃｃ、４６．２．２で指定されるように、ＣＵＣによって作成される。ＣＮＣは、ＴＳＮドメインを設定し、物理的なトポロジをチェックし、時間センシティブなストリームがネットワーク内のブリッジによってサポートされている場合。ＣＮＣは、ストリームの経路およびスケジュール計算も実施する。
８ ＣＮＣは（例えば、以下でさらに説明されるような送信スケジュールの設定）において計算された経路に沿ってブリッジ内のＴＳＮ特徴を設定する。
９ ＣＮＣは、得られたストリームのリソース割り振りのステータス（成功または失敗）をＣＵＣに返す。
１０ ＣＵＣは、最初にリスナとトーカとの間で規定された通りにユーザプレーン（ＵＰ）トラフィック交換を開始するために、エンドステーションをさらに設定する。
図１０６で図示されたような分散型の設定モデルでは、ＣＵＣもＣＮＣも存在しない。したがって、トーカはＴＳＮストリームの開始についての責任を負っている。ＣＮＣが存在しないため、ブリッジは自分自身を設定し、これは上で言及した時間ゲートされたキューイングを使用することができない。対照的に、図１０７で示されるような集中型のモデルでは、トーカはストリーム初期化に責任を負うが、ブリッジはＣＮＣによって設定される。
３ＧＰＰ標準化５Ｇネットワークは、無線デバイスおよび／またはエンドステーションを８０２．１ＴＳＮネットワークに接続するための１ソリューションである。一般に、５Ｇネットワークアーキテクチャは、次世代無線アクセスネットワーク（ＮＧ－ＲＡＮ）および５Ｇコアネットワーク（５ＧＣ）から成る。ＮＧ－ＲＡＮは、１つまたは複数のＮＧインターフェースを介して５ＧＣに接続されるｇＮｏｄｅＢ（ｇＮＢ、基地局とも称される）のセットを含むことができるが、ｇＮＢは１つまたは複数のＸｎインターフェースを介して互いに接続することができる。ｇＮＢのそれぞれは、周波数分割複信（ＦＤＤ）、時分割複信（ＴＤＤ）、またはその組合せをサポートすることができる。ユーザ機器（ＵＥ）とも称されるデバイスは、ｇＮＢを介して５Ｇネットワークと無線通信する。
図１１０は、５Ｇネットワークアーキテクチャの、制御プレーン（ＣＰ）およびデータまたはユーザプレーン（ＵＰ）機能への例示的な分割を図示するブロック図である。例えば、ＵＥは、データパケットを、サービングｇＮＢを介してユーザプレーン機能（ＵＰＦ）に送ることにより、データパケットを外部ネットワーク（例えば、インターネット）上のデバイスおよび／またはアプリケーションに通信することができ、これは５Ｇネットワークから他の外部ネットワークへのインターフェースを提供する。ＣＰ機能は、ＵＰ機能と協働的に動作することができ、アクセス管理機能（ＡＭＦ）およびセッション管理機能（ＳＭＦ）を含む図１１０に示される様々な機能を含むことができる。
たとえそうであっても、５ＧおよびＴＳＮネットワークの適切なインターワーキングのために解決する必要があるいくつかの課題および／または問題が存在する。特に、５Ｇネットワークではなく、外部ネットワークによって決定される時間クリティカルなスケジュールの対象となる外部ネットワーク（例えば、ＴＳＮネットワーク）とのデータ通信をハンドリングするために、５Ｇネットワークを設定することに関するいくつかの課題がある。
図１１１は、図１１０に示される５Ｇネットワークアーキテクチャと例示的な十分に集中型のＴＳＮネットワークアーキテクチャとの間で、インターワーキングするための例示的な配置を図示するブロック図である。以下の議論では、５Ｇネットワークに接続されたデバイスは５Ｇエンドポイントと称され、ＴＳＮドメインに接続されたデバイスは、ＴＳＮエンドポイントと称される。図１１１に示される配置は、トーカＴＳＮエンドポイントおよびＵＥに接続されるリスナ５Ｇエンドポイントを含む。他の配置では、代わりにＵＥは、少なくとも１つのＴＳＮブリッジおよび少なくとも１つのＴＳＮエンドポイントを含むＴＳＮネットワークに接続することができる。この設定において、ＵＥは、ＴＳＮ－５Ｇゲートウェイの一部である可能性がある。
５ＧおよびＴＳＮネットワークの両方が、ネットワーク管理および設定のための特定の手順、ならびに特定のメカニズムを利用して、確定的パフォーマンスを達成する。産業用ネットワークのためのエンドツーエンドの確定的なネットワーキングを促すために、これらの様々な手順およびメカニズムは、共に協働的に機能しなければならない。
ＩＥＥＥ８０２．１Ｑｂｖ－２０１５で説明されているように、ＴＳＮは、特定の時間認識トラフィックスケジューリングを提供して、サイクル時間が事前に分かっている産業用の用途向けの確定的な低レイテンシを容易にしている。このトラフィックスケジューリングは、所定の時間スケールにしたがって各キューからの送信を可能にする時間認識ゲートに基づいている。図１１２は、ＩＥＥＥ規格８０２．１Ｑｂｖ－２０１５で指定されるような、ゲートに基づいてトラフィックキュー間でのゲートベースの送信選択を図示するブロック図である。所与のキューに関して、送信ゲートには、開く、または閉じる、の２つの状態があり得る。
さらには、各送信ゲートは、特定のキュー、潜在的には所与のポートに関連付けられる複数のキューに関連付けられる、トラフィッククラスに関連している。任意の時間的瞬間において、ゲートはオンまたはオフのいずれかを取ることができる。このメカニズムは、時間認識的であり、例えば、ＴＳＮブリッジまたはＴＳＮエンドステーション内でのＰＴＰ適用に基づくことができる。このメカニズムにより、ネットワーク全体でゲート制御リストの実行を精密に協調させることができ、所与のトラフィックのクラスについてのタイトにスケジューリングされた送信を容易にする。本明細書では、送信スケジュールは、送信が時間的にいつ発生することになるかを示すスケジュールとして規定することができる。また、時間クリティカルな送信スケジュールは、時間センシティブなネットワーク（ＴＳＮ）の送信が時間的にいつ発生することになるかを示すスケジュールとして規定することができる。
図１０９に関連して上述したように、ＴＳＮストリームスケジュールについての情報は、十分に集中型のＴＳＮモデルにおいて、トーカおよび／またはリスナによって提供される（および／またはＣＵＣエンティティを介して）ネットワーク要件（例えば、ＩＥＥＥ８０２．１Ｑｃｃの§４６．２．３．６）に対するユーザに基づいて、ＣＮＣエンティティによって計算される。加えて、標準的な管理オブジェクト（例えば、ＩＥＥＥ８０２．１Ｑｖｃで規定されている）およびリモートネットワーク管理プロトコルは、ＣＮＣによって使用され、ＴＳＮブリッジでの送信スケジュールを設定する（図１０９の動作８）。
それにもかかわらず、これらの特徴は、ＴＳＮネットワークに特有であり、図１１１に図示されるようなインターワーキング５Ｇネットワークアーキテクチャを考慮していない。例えば、５Ｇネットワークは、ＵＥとｇＮＢとの間の無線インターフェース上で送信をスケジューリングする場合、外部ネットワーク（例えば、ＴＳＮネットワーク）によって確立された時間クリティカルな送信スケジュールを考慮するための要素（例えば、ＵＥ、ｇＮＢなど）のためのあらゆるメカニズムを提供しない。例えば、そのような時間クリティカルな送信スケジュールが（例えば、ＴＳＮエンドポイントに接続された）ＵＥに既知であっても、ＵＥがｇＮＢにそのようなスケジュールを知らせるメカニズムはない。さらには、ｇＮＢまたはＵＥが、５Ｇネットワークから来るスケジュール要求を理解して処理できるようにするメカニズムはない。
本開示の例示的な実施形態は、（例えば、外部ネットワークからの）時間認識送信スケジュールに基づいて、特定のユーザ用および／またはＱｏＳフロー用の所定の時間スケジューリングのための新奇な技法を提供して、特定の境界付けられたレイテンシ要件を満足することにより、これらならびに他の問題および／または先行ソリューションの欠点に対処する。例えば、これらの技法は、ＵＥ（またはネットワークノード、例えば、ｇＮＢ）がそのような送信時間スケジュールを知り、スケジュールをネットワークノード（または、ＵＥ）に知らせるためのメカニズムを提供することができる。このやり方で、そのような新奇な技法は、様々なスケジューラおよび／またはスケジューリングメカニズムを利用するセルラ（例えば、５Ｇ）とＴＳＮネットワークとの間の協働的なインターワーキングを含む様々な利点を提供することができ、それによって５Ｇネットワークを介してトーカ／リスナのエンドポイント間の時間クリティカルな送信の境界付けられたレイテンシを容易にすることができる。
図１１３は、本開示のいくつかの例示的な実施形態による、５ＧおよびＴＳＮネットワークを介する、２つのＴＳＮトーカ／リスナユニット間の例示的な通信シナリオを図示するブロック図である。このシナリオでは、ＵＥはＴＳＮトーカ／リスナに接続されており、次いで所定のサイクル時間にしたがってアプリケーションを実行する必要があるプラント機器（例えば、ロボット制御）に接続することができる。このシナリオにおける１つの課題は、機器および／またはアプリケーションによって必要とされる境界付けられたレイテンシにしたがって、ｇＮＢからＵＥへのＴＳＮストリームパケットのタイムリーな送信を促すことである。
図１１４は、これらの例示的な実施形態による、図１１３に示されるネットワーク設定を介するＴＳＮストリームパケットのタイムリーな送信を設定するための、例示的な方法および／または手順のシーケンス図である。図１１４において、ナンバリングされた動作は以下の説明に対応する。それでも、数値ラベルは、動作の順序を指定するというよりも、説明のために使用される。換言すると、図１１４に示される動作は、様々な順序で実施することが可能であり、組み合わせておよび／または分割して、図面に示される順序とは異なる動作にすることが可能である。
動作１１では、ＣＵＣはＣＮＣに、ユーザがＴＳＮネットワークに参加するためのジョイン要求を送る。例えば、この要求は、ＴＳＮストリームをセンサ（トーカ）とＰＬＣコントローラ（リスナ）との間でスケジューリングすることを要求するプログラム可能論理制御（ＰＬＣ）アプリケーションに基づいている、および／またはＰＬＣに応答することができる。動作１２では、ＣＮＣは、動作１１で識別されたＴＳＮストリームの特定の要件に基づいて送信スケジュールを計算する。
動作１３では、ＣＮＣは、センサとＰＬＣコントローラとの間の経路にあるＴＳＮスイッチの管理オブジェクトを設定する。高度化時間認識スケジューリングのために設定される例示的な管理オブジェクトは、ＩＥＥＥ８０２．１Ｑｂｖ－２０１５§１２に説明されている。例示的な実施形態において、ＣＮＣは、５Ｇネットワークを経路上のＴＳＮスイッチとして扱い、そのため５Ｇコアネットワーク（５ＧＣ）に、このＴＳＮストリーム用にリソースを設定するよう要求する。例えば、これは、ＣＮＣが、アクセス管理機能（ＡＭＦ、図１１０～図１１１を参照されたい）に、サイクル時間およびＴＳＮストリーム内のトラフィッククラスについてのゲート制御リストを送ることによって行うことができる。
動作１４では、５ＧＣにある受信エンティティ（例えば、ＡＭＦ）は、要求されたＴＳＮストリーム要件（例えば、サイクル時間、ゲート制御リストなど）を、ＴＳＮトーカ／リスナ（例えば、センサ）に接続されたＵＥ向けのＱｏＳ要件に変換することができる。加えて、ＡＭＦは、要求されたＴＳＮストリーム要件を、ＵＥがこのＴＳＮストリームを送信および／または受信するｇＮＢの、時間ウィンドウおよび周期性に変換することができる。
いくつかの実施形態では、動作１４は、様々なサブ動作を伴う可能性がある。例えば、ＵＥおよびＴＳＮストリームに対応するＰＤＵセッションを識別することができ、このＴＳＮストリーム内のトラフィッククラスとＵＥのＱｏＳフローとのマッピングを識別することができる。ＱｏＳフロー（１つまたは複数のトラフィッククラスに対応することができる）ごとに、一定のＱｏＳ要件が、ｇＮＢに示される可能性がある。いくつかの実施形態では、ｇＮＢに対するこのインジケーションは、ＱｏＳフローのパケットが送信されることを保証されるべき時間ウィンドウのインジケータを含むことができる。この時間ウィンドウは、例えば、時間ウィンドウ開始の絶対時間参照をウィンドウの長さ（例えば、レイテンシバウンドとして）と共に提供することによって示すことができる。例えば、絶対時間参照は、全球測位衛星システム（ＧＮＳＳ、例えば、ＧＰＳ）から提供されるようなｇＮＢサブフレーム（ＳＦＮ）タイミングまたは協定世界時（ＵＴＣ）のような一定の絶対参照時間に対するオフセットとして示すことができる。いくつかの実施形態では、ｇＮＢに対するインジケーションは、時間ウィンドウの周期性（または周期）も含むことができる。これは、例えば、ＴＳＮストリームが周期的なスケジュールにしたがって発生する複数の送信事象を含む場合に、含められ得る。
ＵＥのＱｏＳフローごとのこの時間ウィンドウ情報を示すことによって、１つまたは複数のＴＳＮストリームの複数のトラフィッククラスが、独立的にサービングされ得る。換言すると、この情報は、影響を受けるｇＮＢが、ＱｏＳフローのそれぞれの無線リソースを、これらのＱｏＳフローに関連付けられる個々の時間ウィンドウの間に予約することを容易にする。例えば、これは、ｇＮＢが様々なＱｏＳフローを様々な無線ベアラにマッピングし、リソース割り当て／予約を無線ベアラごとに適用することを容易にすることができる。本明細書では、無線ベアラは、第３世代パートナーシッププロジェクト（３ＧＰＰ）による通常の規定を用いる。
動作１４では、上で議論したように情報を決定した後、ＡＭＦはインジケーションおよび／または要求をｇＮＢに送り、ＱｏＳ、時間ウィンドウ、および／または周期性要件が満足され得るかを確認する。動作１５では、動作１４で送られた要求／インジケーションを受信した後、ｇＮＢ（または場合によっては複数のｇＮＢ）は、それがこの追加的なＱｏＳフローを示された時間ウィンドウ要件でサービングできるかどうかを判断する。例えば、この判断を行う際、ｇＮＢは、現在のトラフィック負荷および推定されたトラフィック負荷に使用されるリソース、ＵＥの能力（例えば、スペクトル効率、サポートされる送信／受信モードなど）、ＲＡＮとＵＥとの間のチャネル品質、ならびに追加的な保証されたリソースをＵＥに割り当てる必要があるかどうか（および／またはいくつあるか）を考慮することができる。この判断を行った後、ｇＮＢは、要求を受け入れること（「はい」）、または要求を拒否すること（「いいえ」）により、５ＧＣ機能（例えば、ＡＭＦ）に応答する。いくつかの実施形態では、要求を拒否した場合、ｇＮＢは、ｇＮＢが対応する要求を受け入れることができる代替の時間ウィンドウを（例えば、要求された時間ウィンドウまでのオフセットによって）示すことができる。ｇＮＢが要求を受け入れる状況では、ｇＮＢは、要求された送信スケジュールを満足するよう、必要に応じて、識別されたあらゆる追加的なリソースを予約することも可能である。
動作１６では、ｇＮＢから応答を受信した後、５ＧＣ機能は、次にこの応答（ＱｏＳフローごとのマッピングに基づいている）をトラフィックフロー／ＴＳＮストリームレベルの細分性に変換する場合があり、ＴＳＮ ＣＮＣに応答を与える。応答は、ＴＳＮ ＣＮＣによって復号できるフォーマットであってもよい。動作１７では、この応答を受信した後、ＣＮＣはＣＵＣに、動作１１で受信したジョイン要求に対する対応する応答を与える。動作１８では、ジョイン要求をＣＮＣから受信した後、ＣＵＣは、オリジナルの要求に関連付けられるすべてのトーカおよびリスナエンドステーションをさらに設定する。いくつかの実施形態では、ＣＵＣは、５ＧＣにＵＥへの接続を開始するよう要求することもできるが、他の実施形態では、５ＧＣまたはそれは、デフォルトおよび／または既存のＰＤＵセッションを使用することもある。
図１１５は、本開示の例示的な他の実施形態による、５Ｇネットワークを介する、ＴＳＮトーカ／リスナユニットと仮想化コントローラとの間の別の例示的な通信シナリオを図示するブロック図である。このシナリオでは、ＴＳＮネットワークは、ＵＥに接続され、これは５Ｇネットワークへの無線リンク上で、トーカ／リスナのエンドステーションへ接続するためのゲートウェイとして作用する。このシナリオにおける１つの課題は、ＴＳＮネットワーク内でＣＮＣによって計算されたスケジュールによって必要とされる境界付けられたレイテンシにしたがって、ＵＥからｇＮＢへのＴＳＮストリームパケットのタイムリーな送信を促すことである。
図１１６は、これらの例示的な実施形態による、図１１５に示されるネットワーク設定を介するＴＳＮストリームパケットのタイムリーな送達を設定するための、例示的な方法および／または手順のシーケンス図である。図１１６において、ナンバリングされた動作は以下の説明に対応する。それでも、数値ラベルは、動作の順序を指定するというよりも、説明のために使用される。換言すると、図１１６に示される動作は、様々な順序で実施することが可能であり、組み合わせておよび／または分割して、図面に示される順序とは異なる動作にすることが可能である。
動作２１では、ＣＮＣは、ＣＵＣによって与えられた要件に基づいて、送信スケジュールを計算して、それを、この場合ではＵＥである５ＧネットワークのＴＳＮインターフェースに送る。動作２２では、ＵＥは、メッセージに含むことができる、ＣＮＣによって与えられた送信スケジュールにしたがって、メッセージ要求アップリンク（ＵＬ）無線リソースセットを作成して送る。例えば、ＵＥは、メッセージを５ＧＣ内のＡＭＦに送ることができる。動作２３では、このメッセージを受信した後、ＡＭＦはＵＥプロファイルを５ＧＣにおけるユーザデータ管理（ＵＤＭ）機能から検索し、この情報に基づいて、ＵＥがどのｇＮＢに接続するかを決定する。動作２４では、ＡＭＦは、要求をｇＮＢに送り、要求に含むことができる、送信スケジュールに基づいてＵＥに向けたＴＳＮ ＱｏＳ特徴を有効にする。いくつかの実施形態では、ＡＭＦは、修正された時間参照を５Ｇネットワークに接続された他のトーカ／リスナ（例えば、仮想化されたコントローラ）に送ることもできる（動作２４ａ）。
動作２５では、ｇＮＢを受信することは、図１１４の動作１５を参照して説明された動作に実質的に類似した動作を実施することができるが、ダウンリンクではなく、アップリンクに関してのものである。動作２５で送られたｇＮＢからの応答を受信した後、ＡＭＦは動作２２でＵＥから受信したリソースの要求に対して応答することができる（動作２６）。図１４４に示される動作１６と同様に、ＡＭＦはｇＮＢ応答（ＱｏＳフローごとのマッピングに基づいている）をトラフィックフロー／ＴＳＮストリームレベルの細分性に変換することができ、このフォーマットでの応答をＵＥに与える。動作２７では、ＵＥは、動作２１で受信した要求された送信スケジュールに応答して、この情報をＣＮＣに転送することができる。図１１４で図示した一定の実施形態に関連して上で議論したように、ｇＮＢが要求された送信スケジュールを拒否するが、受け入れることができる代替の時間ウィンドウを提案する場合、図１１４の動作１５～動作１７、および図１１６の動作２５～動作２７で送られる応答は、そのような代替の時間ウィンドウを、個別の受信側のプロトコルおよび／または要件にしたがってフォーマットされて、および／または変換されて含むことができる。
上述より理解できるように、これらおよび他の例示的な実施形態は、ＴＳＮネットワークなどの外部ネットワークの時間センシティブな（例えば、境界付けられたレイテンシ）要件にしたがってセルラネットワーク（例えば、５Ｇネットワーク）における送信の時間認識のスケジューリングを容易にする。例示的な実施形態は、提供されたトラフィック外部ネットワークに関連付けられるタイミングおよび周期性についての情報を（ＵＥを介するか、またはＡＭＦなどのネットワーク機能を介してのいずれかで）収集するため、およびそのような情報をセルラネットワーク内の１つまたは複数の基地局（例えば、ｇＮＢ）に転送するための新奇な技法を通じて、そのような特徴を容易にする。そのような場合、基地局は、要求されたトラフィックの外部の時間センシティブな要件をサポートできるかどうかを判断することができ、サポートできる場合、ＵＥと基地局との間でアップリンクまたはダウンリンク送信をスケジューリングするためのそのような情報を利用することができる。
図１１７は、本開示の様々な例示的な実施形態による、外部ネットワークに関連付けられる送信スケジュールにしたがって無線アクセスネットワーク（ＲＡＮ）でリソースをスケジューリングするための例示的な方法および／または手順を図示するフロー図である。図１１７に示される例示的な方法および／または手順は、本明細書の他の図面で示される、または関連して説明されるような、コアネットワークノード（例えば、ＡＭＦ）などによって、ＲＡＮ（例えば、ＮＧ－ＲＡＮ）に関連付けられるコアネットワーク（例えば、５ＧＣ）に実装することができる。さらには、以下で説明するように、図１１７に示される例示的な方法および／または手順は、図１１８および／または図１１９（以下で説明する）に示される、例示的な方法および／または手順と協働的に利用して、本明細書で説明する様々な例示的な利点を提供することができる。図１１７は、特定の順序でブロックを示しているが、この順序は単に例示的であり、例示的な方法および／または手順の動作は、図１１７で示される順序とは異なる順序で実施することができ、異なる機能性を有するブロックに組み合わせるおよび／または分割することができる。任意選択的な動作は、破線で表す。
図１１７に示される例示的な方法および／または手順は、ブロック１２１０の動作を含むことができ、ブロック１２１０では、ネットワークノードは外部ネットワークから、時間センシティブなデータストリームに関連付けられる送信スケジュールを受信することができる。本明細書では、時間センシティブなデータストリームは、時間センシティブなネットワーク（ＴＳＮ）のデータストリームであり得る。したがって、いくつかの実施形態では、本明細書において説明されるＩＥＥＥ標準で説明されるように、外部ネットワークは時間センシティブなネットワーク（ＴＳＮ）を含む。そのような実施形態では、データストリームは、例えばＴＳＮ内のトーカおよび／またはリスナのエンドステーションに関連付けられて、ＴＳＮストリームを含むことができる。そのような実施形態では、送信スケジュールは、サイクル時間、およびＴＳＮストリームを含む１つまたは複数のトラフィッククラスについてのゲート制御リストを含むことができる。
例示的な方法および／または手順は、ブロック１２２０の動作を含むこともでき、ブロック１２２０では、ネットワークノードは、ＲＡＮに、ＲＡＮとユーザ機器（ＵＥ）との間でのデータストリームの通信用に無線リソースを割り当てるよう要求を送ることができ、要求は送信スケジュールに関連する情報をさらに含む。いくつかの実施形態では、送信スケジュールに関連する情報には、以下のうちの１つまたは複数が含まれる：ＵＥの識別子、データストリームに関連付けられる１つまたは複数のサービス品質（ＱｏＳ）フローの識別子、およびＱｏＳフローのそれぞれに関連付けられるＱｏＳ要件。いくつかの実施形態では、それぞれのＱｏＳ要件は、データストリームが送信される必要がある１つまたは複数の時間ウィンドウを含むことができる。いくつかの実施形態では、それぞれのＱｏＳ要件は、初期時間ウィンドウおよび後続の時間ウィンドウを識別する周期性を含む。
例示的な方法および／または手順は、ブロック１２３０の動作をさらに含むことができ、ブロック１２３０では、ネットワークノードはＲＡＮから、無線リソースがデータストリームに関連付けられる送信スケジュールを満足するよう割り当てることができるかどうかを示す応答を受信することができる。いくつかの実施形態では、サブブロック１２３５によると、無線リソースがデータストリームの送信スケジュールを満足するよう割り当てることができないことを応答が示す場合、応答は、無線リソースを割り当てることができる１つまたは複数のさらなる時間ウィンドウのインジケーションをさらに含む。
いくつかの実施形態では、応答は、ＱｏＳフローのそれぞれに関連付けられるＱｏＳ要件が満足され得るかどうかを示すことができる。そのような実施形態では、例示的な方法および／または手順は、ブロック１２４０の動作をさらに含むことができ、ブロック１２４０では、ネットワークノードは、送信スケジュールがＱｏＳフローのそれぞれに関連付けられるＱｏＳ要件が満足され得るかどうかのインジケーションに基づいて満足され得るかどうかを判断することができる。いくつかの実施形態では、例示的な方法および／または手順は、ブロック１２５０の動作をさらに含むことができ、ブロック１２５０では、ネットワークノードは、外部ネットワークに、送信スケジュールが満足され得るかどうかのインジケーションを送ることができる。
いくつかの実施形態では、方法は、５Ｇコアネットワーク（５ＧＣ）のアクセス管理機能（ＡＭＦ）によって実施することができる。いくつかの実施形態では、送信スケジュールは、外部ネットワークから受信することができる。無線リソースは、ＲＡＮからＵＥへのダウンリンク通信に向けたものである。いくつかの実施形態では、送信スケジュールは、ＵＥから受信される。無線リソースは、ＵＥからＲＡＮへのアップリンク通信に向けたものである。
図１１８は、本開示の様々な例示的な実施形態による、外部ネットワークに関連付けられる送信スケジュールにしたがって無線アクセスネットワーク（ＲＡＮ）でリソースをスケジューリングするための例示的な方法および／または手順を図示するフロー図である。図１１８に示される例示的な方法および／または手順は、本明細書の他の図面で示される、または関連して説明されるような、ＲＡＮノード（例えば、ｇＮＢ）などによって、コアネットワーク（例えば、５ＧＣ）に関連付けられるＲＡＮ（例えば、ＮＧ－ＲＡＮ）に実装することができる。さらには、以下で説明するように、図１１８に示される例示的な方法および／または手順は、図１１７および／または図１１９（上述の、および以下で説明する）に示される、例示的な方法および／または手順と協働的に利用して、本明細書で説明する様々な例示的な利点を提供することができる。図１１８は、特定の順序でブロックを示しているが、この順序は単に例示的であり、例示的な方法および／または手順の動作は、図１１８で示される順序とは異なる順序で実施することができ、異なる機能性を有するブロックに組み合わせるおよび／または分割することができる。任意選択的な動作は、破線で表す。
図１１８に示される例示的な方法および／または手順は、ブロック１３１０の動作を含むことができ、ブロック１３１０では、ネットワークノードはコアネットワークから、時間センシティブなデータストリームの通信用にＲＡＮとユーザ機器（ＵＥ）との間で無線リソースを割り当てるよう要求を受信することができ、要求はデータストリームに関連付けられる送信スケジュールに関連する情報をさらに含む。いくつかの実施形態では、外部ネットワークは、時間センシティブなネットワーク（ＴＳＮ）を含み、データストリームはＴＳＮストリームを含む。
いくつかの実施形態では、送信スケジュールに関連する情報には、以下のうちの１つまたは複数が含まれる：ＵＥの識別子、データストリームに関連付けられる１つまたは複数のサービス品質（ＱｏＳ）フローの識別子、およびＱｏＳフローのそれぞれに関連付けられるＱｏＳ要件。いくつかの実施形態では、それぞれのＱｏＳ要件は、データストリームが送信される必要がある１つまたは複数の時間ウィンドウを含むことができる。いくつかの実施形態では、それぞれのＱｏＳ要件は、初期時間ウィンドウおよび後続の時間ウィンドウを識別する周期性を含む。
図１１８に示される例示的な方法および／または手順は、ブロック１３２０の動作をさらに含むことができ、ブロック１３２０では、ネットワークノードは、送信スケジュールに関連する情報に基づいて、無線リソースが送信スケジュールを満足するよう割り当てることができるかどうかを判断することができる。いくつかの実施形態では、無線リソースが送信スケジュールを満足するよう割り当てることができるかどうかを判断することは、以下のうちの１つまたは複数にさらに基づく可能性がある：現在のトラフィック負荷および推定されたトラフィック負荷に必要なリソース、ＵＥの能力、ＲＡＮとＵＥとの間のチャネル品質、および追加的な保証されたリソースがＵＥに割り当てられる必要性。
いくつかの実施形態では、ブロック１３２０で無線リソースをデータストリームに関連付けられる送信スケジュールを満足するよう割り当てることができないと判断された場合、例示的な方法および／または手順は、ブロック１３３０の動作を含み、ネットワークノードは、無線リソースを割り当てることができる１つまたは複数のさらなる時間ウィンドウを決定することができる。いくつかの実施形態では、ブロック１３２０で無線リソースをデータストリームに関連付けられる送信スケジュールを満足するよう割り当てることができると判断された場合、例示的な方法および／または手順は、ブロック１３４０の動作を含み、ネットワークノードは、１つまたは複数のＱｏＳフローをＲＡＮとＵＥとの間の少なくとも１つの無線ベアラにマッピングし、少なくとも１つの無線ベアラ用の送信リソースを予約することができる。
例示的な方法および／または手順は、ブロック１３５０の動作をさらに含むことができ、ブロック１３５０では、ネットワークノードはコアネットワークに、無線リソースが送信スケジュールを満足するよう割り当てることができるかどうかを示す応答を送ることができる。いくつかの実施形態では、ブロック１３２０で無線リソースを、送信スケジュールを満足するよう割り当てることができないと判断された場合、ブロック１３５０で送られた応答は、任意選択のサブブロック１３３０で決定された１つまたは複数のさらなる時間ウィンドウのインジケーションも含むことができる。これを、任意選択のサブブロック１３５５によって図示する。
図１１９は、本開示の様々な例示的な実施形態による、外部ネットワークに関連付けられる送信スケジュールにしたがって無線アクセスネットワーク（ＲＡＮ）でリソースをスケジューリングするための例示的な方法および／または手順を図示するフロー図である。図１１９で示される例示的な方法および／または手順は、本明細書の他の図面で示される、または関連して説明されるような、例えば、コアネットワーク（例えば、５ＧＣ）に関連付けられるＲＡＮ（例えば、ＮＧ－ＲＡＮ）と通信するユーザ機器（ＵＥ、例えば、無線デバイス、ＩｏＴデバイス、Ｍ２Ｍデバイスなど）によって実装することができる。さらには、以下で説明するように、図１１９に示される例示的な方法および／または手順は、図１１７および／または図１１８（上で説明した）に示される、例示的な方法および／または手順と協働的に利用して、本明細書で説明する様々な例示的な利点を提供することができる。図１１９は、特定の順序でブロックを示しているが、この順序は単に例示的であり、例示的な方法および／または手順の動作は、図１１９で示される順序とは異なる順序で実施することができ、異なる機能性を有するブロックに組み合わせるおよび／または分割することができる。任意選択的な動作は、破線で表す。
図１１９に示される例示的な方法および／または手順は、ブロック１４１０の動作を含むことができ、ブロック１４１０では、ＵＥは外部ネットワークから、時間センシティブなデータストリームに関連付けられる送信スケジュールを受信することができる。いくつかの実施形態では、本明細書において議論されるＩＥＥＥ標準で説明されるように、外部ネットワークは時間センシティブなネットワーク（ＴＳＮ）を含む。そのような実施形態では、データストリームは、例えばＴＳＮ内のトーカおよび／またはリスナのエンドステーションに関連付けられて、ＴＳＮストリームを含むことができる。そのような実施形態では、送信スケジュールは、サイクル時間およびＴＳＮストリームを含む１つまたは複数のトラフィッククラスについてのゲート制御リストを含むことができる。
例示的な方法および／または手順は、ブロック１４２０の動作を含むこともでき、ブロック１４２０では、ＵＥは、ＲＡＮに関連付けられるコアネットワークに、ＵＥとＲＡＮとの間でのデータストリームの通信用に無線リソースを割り当てるよう要求を送ることができ、要求は送信スケジュールに関連する情報をさらに含む。いくつかの実施形態では、送信スケジュールに関連する情報は、送信スケジュールを含む。
例示的な方法および／または手順は、ブロック１４３０の動作を含むこともでき、ブロック１４３０では、ＵＥはコアネットワークから、無線リソースがデータストリームに関連付けられる送信スケジュールを満足するよう割り当てることができるかどうかを示す応答を受信することができる。いくつかの実施形態では、無線リソースがデータストリームの送信スケジュールを満足するよう割り当てることができないことをコアネットワークからの応答が示す場合、応答は、無線リソースを割り当てることができる１つまたは複数のさらなる時間ウィンドウのインジケーションをさらに含む。これを、任意選択のサブブロック１４３５によって図示する。いくつかの実施形態では、要求（ブロック１４２０）を５ＧＣ内のアクセス管理機能（ＡＭＦ）に送ることができ、応答（ブロック１４３０）を５ＧＣ内のＡＭＦから受信することができる。
いくつかの実施形態では、例示的な方法および／または手順は、ブロック１４４０の動作をさらに含むことができ、ブロック１４４０では、ＵＥは、外部ネットワークに、送信スケジュールが満足され得るかどうかのインジケーションを送ることができる。いくつかの実施形態では、ブロック１４３０で受信した応答が、無線リソースを割り当てることができる（サブブロック１４３５）１つまたは複数のさらなる時間ウィンドウのインジケーションを含む場合、外部ネットワークに送られたインジケーションは、１つまたは複数のさらなる時間ウィンドウに関連する情報をさらに含む。これを、任意選択のサブブロック１４４５によって図示する。
図１２０は、セルラ通信システムおよび／またはネットワークの一例を図示しており、本明細書において説明される例示的な方法のいずれかを実装するために使用可能な様々なデバイスおよび／またはシステムを含んでいる。本明細書において説明される実施形態では、セルラ通信ネットワーク１５００は、５ＧのＮＲネットワークである。この例では、セルラ通信ネットワーク１５００は、基地局１５０２－１および１５０２－２を含み、これらはＬＴＥではｅＮＢと称され、５ＧのＮＲではｇＮＢと称され、対応するマクロセル１５０４－１および１５０４－２を制御している。基地局１５０２－１および１５０２－２は、本明細書では一般的に（複数の）基地局１５０２と総称し、個別には基地局１５０２と称する。同じく、マクロセル１５０４－１および１５０４－２は、本明細書では一般的に（複数の）マクロセル１５０４と総称し、個別にはマクロセル１５０４と称する。
セルラ通信ネットワーク１５００は、対応するスモールセル１５０８－１から１５０８－４を制御する、いくつかの低電力ノード１５０６－１から１５０６－４も含むことができる。低電力ノード１５０６－１から１５０６－４は、小型の基地局（ピコまたはフェムト基地局など）、リモート無線ヘッド（ＲＲＨ）などであり得る。特に、図示していないが、スモールセル１５０８－１から１５０８－４のうちの１つまたは複数は、代替的に（複数の）基地局１５０２によって実現される場合がある。低電力ノード１５０６－１から１５０６－４は、本明細書では一般的に（複数の）低電力ノード１５０６と総称し、個別には低電力ノード１５０６と称する。同じく、スモールセル１５０８－１から１５０８－４は、本明細書では一般的に（複数の）スモールセル１５０８と総称し、個別にはスモールセル１５０８と称する。（複数の）基地局１５０２（および任意選択に（複数の）低電力ノード１５０６）は、コアネットワーク６１５０に接続される。
（複数の）基地局１５０２および（複数の）低電力ノード１５０６は、対応するセル１５０４および１５０８において、無線デバイス１５１２－１から１５１２－５にサービスを提供する。無線デバイス１５１２－１から１５１２－５は、本明細書では一般的に（複数の）無線デバイス１５１２と総称し、個別には無線デバイス１５１２と称する。（複数の）無線デバイス１５１２は、本明細書では、時にＵＥとも称される。（複数の）無線デバイス１５１２は、ＭＴＣおよび／またはＮＢ－ＩｏＴ対応の形態を含む、様々な形態を取ることができる。
図１２１は、本開示のいくつかの実施形態による、無線アクセスノード２２００の概略ブロック図である。無線アクセスノード２２００は、本明細書において１つまたは複数の他の図面と関連して説明される、例えば基地局（例えば、ｇＮＢまたはｅＮＢ）であってもよい。図示されるように、無線アクセスノード２２００は、制御システム２２０２を含み、制御システム２２０２は、１つまたは複数のプロセッサ２２０４（例えば、中央処理装置（ＣＰＵ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）など）、メモリ２２０６、およびネットワークインターフェース２２０８をさらに含む。加えて、無線アクセスノード２２００は、１つまたは複数の無線ユニット２２１０を含み、無線ユニット２２１０は、１つまたは複数のアンテナ２２１６に連結される１つまたは複数の送信機２２１２、および１つまたは複数の受信機２２１４を、それぞれ含む。いくつかの実施形態では、無線ユニット２２１０は、制御システム２２０２の外部にあり、例えば有線接続（例えば、光ケーブル）を介して制御システム２２０２に接続される。しかしながら、いくつかの他の実施形態では、無線ユニット２２１０および潜在的にはアンテナ２２１６は、制御システム２２０２と共に一体化される。１つまたは複数のプロセッサ２２０４は、本明細書に記載されるように無線アクセスノード２２００の１つまたは複数の機能を提供するよう動作する。いくつかの実施形態では、機能は、例えばメモリ２２０６に記憶されるソフトウェアで実装され、１つまたは複数のプロセッサ２２０４によって実行される。
図１２２は、本開示のいくつかの実施形態による、無線アクセスノード２２００の仮想化された実施形態を図示する概略ブロック図である。この議論は、他のタイプのネットワークノードに同じように適用可能である。さらには、他のタイプのネットワークノードは、類似の仮想化されたアーキテクチャを有することができる。
本明細書で使用される場合、「仮想化された」無線アクセスノードは、ノード２２００の機能性の少なくとも一部が仮想コンポーネントとして（例えば、ネットワーク内の物理的な処理ノードで実行される仮想マシンを介して）実装される無線アクセスノード２２００の実装形態である。図示されるように、この例では、上述の通り、無線アクセスノード２２００は、制御システム２２０２を含み、制御システム２２０２は、１つまたは複数のプロセッサ２２０４（例えば、ＣＰＵ、ＡＳＩＣ、ＦＰＧＡなど）、メモリ２２０６、およびネットワークインターフェース２２０８を含み、ならびに１つまたは複数のアンテナ２２２３に連結される１つまたは複数の送信機２２１２、および１つまたは複数の受信機２２１４をそれぞれ含む、１つまたは複数の無線ユニット２２１０を含む。制御システム２２０２は、例えば光ケーブルなどを介して無線ユニット２２１０に接続される。制御システム２２０２は、ネットワークインターフェース２３０８を介してネットワーク２３０２の一部に連結されるか、含められる、１つまたは複数の処理ノード２３００に接続される可能性がある。各処理ノード２３００は、１つまたは複数のプロセッサ２３１０（例えば、ＣＰＵ、ＡＳＩＣ、ＦＰＧＡなど）、メモリ２３０６、およびネットワークインターフェース２３０８を含むことができる。
この例では、本明細書で説明される無線アクセスノード２２００の機能２３１０は、１つまたは複数の処理ノード２３００に実装されるか、または制御システム２２０２の全体、および１つまたは複数の処理ノード２３００に任意の所望のやり方で分散される。いくつかの特定の実施形態では、本明細書で説明される無線アクセスノード２２００の機能２３１０の一部またはすべては、処理ノード２３００によってホストされる仮想環境に実装される１つまたは複数の仮想マシンによって実行される仮想コンポーネントとして実装される。当業者により諒解されるように、所望の機能２３１０の少なくとも一部を実行するために、処理ノード２３００と制御システム２２０２との間の追加的なシグナリングまたは通信が使用される。特に、いくつかの実施形態では、制御システム２２０２が含まれない場合があり、その場合は無線ユニット２２１０が適当なネットワークインターフェースを介して処理ノード２３００と直接通信する。
いくつかの実施形態では、少なくとも１つのプロセッサによって実行されると、少なくとも１つのプロセッサに、本明細書で説明される実施形態のいずれかにしたがって、無線アクセスノード２２００または仮想環境において無線アクセスノード２２００の機能２３１０の１つまたは複数を実装するノード（例えば、処理ノード２３００）の機能性を実行させる命令を含むコンピュータプログラムが提供される。いくつかの実施形態では、前述のコンピュータプログラム製品を含むキャリアが提供される。キャリアは、電子的な信号、光学的な信号、無線信号、またはコンピュータ可読記憶媒体（例えば、メモリなどの非一時的なコンピュータ可読媒体）のうちの１つである。
図１２２は、本開示のいくつかの他の実施形態による、無線アクセスノード２２００の概略ブロック図である。無線アクセスノード２２００は、１つまたは複数のモジュール２４００を含み、モジュール２４００のそれぞれは、ソフトウェアに実装される。モジュール２４００は、本明細書で説明される無線アクセスノード２２００の機能性を提供する。この議論は、モジュール２４００が１つまたは複数の処理ノード２３００および／または制御システム２２０２の全体に実装されるおよび／または分散され得る、図１２３の処理ノード２３００に同じように適用可能である。
図１２４は、本開示のいくつかの実施形態による、ＵＥ２５００の概略ブロック図である。図示されるように、ＵＥ２５００は、１つまたは複数のプロセッサ２５０２（例えば、ＣＰＵ、ＡＳＩＣ、ＦＰＧＡなど）、メモリ２５０４、ならびに１つまたは複数のアンテナ２５１２に連結される１つまたは複数の送信機２５０８および１つまたは複数の受信機２５１０をそれぞれ含む、１つまたは複数の送受信機２５０６を含む。いくつかの実施形態では、上述のＵＥ２５００の機能性は、例えばメモリ２５０４に記憶され、プロセッサ２５０２によって実行されるソフトウェアに、全体的または部分的に実装され得る。
いくつかの実施形態では、少なくとも１つのプロセッサによって実行されると、少なくとも１つのプロセッサに、本明細書で説明される実施形態のいずれかにしたがって、ＵＥ２５００の機能性を実行させる命令を含むコンピュータプログラムが提供される。いくつかの実施形態では、前述のコンピュータプログラム製品を含むキャリアが提供され得る。キャリアは、電子的な信号、光学的な信号、無線信号、またはコンピュータ可読記憶媒体（例えば、物理的なメモリなどの非一時的なコンピュータ可読媒体）のうちの１つであることができる。
図１２５は、本開示のいくつかの他の実施形態による、ＵＥ２５００の概略ブロック図である。これらの実施形態では、ＵＥ２５００は、１つまたは複数のモジュール２６００を含むことができ、モジュール２６００のそれぞれは、ソフトウェアに実装される。モジュール２６００は、本明細書で上述されるＵＥ２５００の機能性の少なくとも一部を提供することができる。
セルラネットワーク上でのデータフローのトランスポート
図１２６は、５Ｇネットワークのアーキテクチャを図示しており、ユーザプレーン機能（ＵＰＦ）などの関連するコアネットワーク機能を紹介する。
ＮＲ ＰＤＣＰでは、ヘッダ圧縮が使用される。プロトコルは、ＩＥＴＦ ＲＦＣ５７９５”Ｔｈｅ Ｒｏｂｕｓｔ Ｈｅａｄｅｒ Ｃｏｍｐｒｅｓｓｉｏｎ（ＲｏＨＣ） Ｆｒａｍｅｗｏｒｋ”で規定されるロバストなヘッダ圧縮（ＲＯＨＣ）フレームワークに基づいている。基本的な理念は、新しいパケットのプロトコルヘッダにおける冗長性を利用することであり、つまりこれらが以前に受信したパケットに類似しているか、または以前に受信したパケットと同一である事実を使用する。したがって、完全なプロトコルヘッダ情報は以前に受信したパケットから既に分かっているため、後続のパケットはこの情報を含む必要がない。圧縮／解凍のコンテキストは、その情報を追跡するために維持される。異なるヘッダ圧縮アルゴリズム／変形を伴ういくつかの異なるＲｏＨＣプロファイルが存在し、ＮＲ ＰＤＣＰ仕様で規定／参照される。
ＵＥは、プライマリセルを変更する際、ハンドオーバ手順を経る。ソースおよびターゲットセルは、異なるｇＮＢに属している場合もある。この手順に関与するユーザプレーンプロトコルスタックに着目すると：ＵＥは、ＭＡＣをＨＡＲＱプロセスでリセットし、同様にＲＬＣエンティティを再確立（フラッシュ）する。ＰＤＣＰプロトコルは、ハンドオーバアンカとして機能し、ＰＤＣＰが確認型モードでは、ハンドオーバでＭＡＣ／ＨＡＲＱおよびＲＬＣフラッシングのために失われたかもしれない、まだ確認されていないデータの再送信を行うことを意味している。
デュアルコネクティビティでは、ハンドオーバの他に、無線ベアラをＭＣＧタイプからＳＣＧタイプに／から、またはＳｐｌｉｔタイプに／から変更することができる。これは、ＰＤＣＰ再確立を含むハンドオーバ手順で、または代替的にＰＤＣＰデータリカバリ手順で実現することができる。
５Ｇネットワーク上でのイーサネットＰＤＵセッションのためのサポートは、３ＧＰＰ ＴＳ２３．５０１およびＴＳ２３．５０２で導入された（例えば、これらの両方の仕様のバージョン１５．２．０を参照されたい）。
図１２７は、３ＧＰＰ ＴＳ２９．５６１、“Ｉｎｔｅｒｗｏｒｋｉｎｇ ｂｅｔｗｅｅｎ ５Ｇ Ｎｅｔｗｏｒｋ ａｎｄ Ｅｘｔｅｒｎａｌ Ｄａｔａ Ｎｅｔｗｏｒｋｓ；Ｓｔａｇｅ ３”のリリース１５で規定されるような、イーサネットＰＤＵタイプデータ（ユーザプレーン）用のプロトコルスタックを示している。外部データネットワークは、例えばイーサネットＬＡＮを含むことができる。外部データネットワーク（ＤＮ）とのそのようなインターワーキングに向けたキーとなる特性には、以下が含まれる：
・ＵＰＦは、ＤＮまたはＵＥから受信したＭＡＣアドレスを記憶する。５Ｇネットワークは、ＭＡＣアドレスをＵＥに割り振らない
・イーサネットプリアンブル、開始フレーム識別子（ＳＦＤ）およびフレームチェックシーケンス（ＦＣＳ）は、５ＧＳ上で送られない
・ＳＭＦは、イーサネットフレーム構造およびＵＥ ＭＡＣアドレスに基づいて、イーサネットフィルタセットおよび転送規則を、ＵＰＦに提供する
・ＰＤＵセッション確立の間、ＤＮ－ＡＡＡ（データネットワーク－認証、認可、およびアカウンティング）サーバは、この特定のＰＤＵセッションに許可されたＭＡＣアドレスのリストを用意することができる（３ＧＰＰ ＴＳ２９．５６１のリリース１５参照）。
・ＩＰレイヤは、イーサネットＰＤＵセッションの一部ではないアプリケーションレイヤとして考えられる（３ＧＰＰ ＴＳ２９．５６１のリリース１５参照）
時間センシティブなネットワーキング（ＴＳＮ）は、イーサネットベースの有線通信ネットワークにおいて、確定的なネットワーキングを可能にする特徴のセットである。ＴＳＮネットワーク内では、通信エンドポイントは、トーカおよびリスナと呼ばれる。トーカとリスナとの間にあるすべてのスイッチ（例えば、ブリッジ）は、一定のＴＳＮ特徴、例えば、ＩＥＥＥ８０２．１ＡＳ時間同期などをサポートする必要がある。ネットワーク内で同期されるすべてのノードは、いわゆるＴＳＮドメインに属している。ＴＳＮ通信は、そのようなＴＳＮドメイン内だけで可能である。確定的な通信を可能にするために、ＴＳＮ通信はストリーム内で生じ、これはデータ通信が起こる前にＴＳＮドメインでセットアップされる。ＴＳＮネットワークでは、ＩＥＥＥ８０２．１ＣＢで規定されるように、フレームがどのように識別されて、ＴＳＮストリームにマッピングされるかについて、様々な可能性が存在する。識別は、ＭＡＣアドレスならびにＶＬＡＮヘッダおよび／またはＩＰヘッダに基づくことができる。しかし、ＴＳＮ標準は現在開発中であるため、フレームを識別するために、他の態様（例えば、Ｅｔｈｅｒ－Ｔｙｐｅフィールド）をＴＳＮ標準に導入することもできる。ＴＳＮストリームがＴＳＮネットワークに確立された後、フレームは、特定のストリーム識別子に基づいてＴＳＮネットワーク全体で識別される。
現在どのヘッダ圧縮も、５Ｇネットワーク向けのイーサネットフレームには規定されていない。これにより圧縮されていないイーサネットフレームが送信される場合があり、産業用ＩｏＴ／ＵＲＬＬＣトラフィックなど、一定のタイプのトラフィックが典型的に小さいペイロードサイズの場合、これは著しいオーバヘッドを伴う。
ハンドオーバの再確立およびデータリカバリの間、ＲｏＨＣパフォーマンスは、保証することが可能ではなく、保証された送信成功に依拠するサービスには問題である。サービス用により多くのリソースを（例えば、ＲｏＨＣを用いずに）プロビジョニングすることによって、この問題に対抗することは、受け入れ難いリソースの無駄につながる可能性が高い。
ＲｏＨＣに揃えたイーサネットヘッダ圧縮用のプロトコルは、時に良好な圧縮率を与えることができる場合があるが、例えば、上のハンドオーバ状況では確定的ではない。これにより、無線アクセスノード（例えば、ｇＮＢ）も、必要最低限のリソースを確定的に予約できないという不利な点が生じる。つまり、ヘッダ圧縮が完全な圧縮に至らず、さらなるリソースが無駄となる場合、そのようなノードは、より多くのリソースを予約する必要がある場合がある。
ＲｏＨＣ圧縮のコンテキストロス（例えば、ハンドオーバによる）は、受信機側でのパケット転送に遅延をもたらし、これはＵＲＬＬＣトラフィックには受け入れ難い場合がある。
本開示の一定の態様およびその実施形態は、これらまたは他の課題に対するソリューションを提供することができる。
本開示は、３ＧＰＰ ＮＲ無線技術（例えば、３ＧＰＰ ＴＳ３８．３００ Ｖ１．３．０）のコンテキストで説明される。しかしながら、当業者であれば、本開示の実施形態は、他のセルラ通信ネットワークにも当てはまることを理解されよう。本開示の実施形態は、冗長な情報を圧縮することにより、セルラ（例えば、５Ｇ）ネットワーク上でのデータフロー（例えば、時間センシティブなネットワーキング（ＴＳＮ）のためのデータフローなどの、時間センシティブなデータフロー）の効率的なトランスポートを可能にする。これは、１つまたは複数のコアネットワークノードをＴＳＮ認識にして、ＴＳＮフローのハンドリングをサポートしつつ不必要なオーバヘッドを削減することによって達成される。
方法は、本開示では、５Ｇネットワークにおける、イーサネットのヘッダ圧縮／ＴＳＮストリームベースの送信について、概説される。ＩＰヘッダ圧縮用のＲｏＨＣのような既知の方法と比較して、本明細書で概説される方法は、イーサネット／ＴＳＮストリームの特定の性質に依拠し、確定的な圧縮率を可能にしている。
本明細書では、本明細書で開示される問題のうちの１つまたは複数に対処する様々な実施形態が提案される。
一定の実施形態は、以下の技術上の優位性のうちの１つまたは複数を提供することができる。セルラネットワークにおけるイーサネットヘッダ圧縮は、一般的にリソース使用量を低下させ、キャパシティを増加させる。本開示の実施形態により、確定的な圧縮率が可能となる。つまり、この最適な圧縮率を満足することができない状況を考慮することを必要とする代わりに、フロー／ＵＥのために確定的な必要最低限のリソース予約が可能となる。この方法では、システムのキャパシティが改善される。
以下で説明するように、本開示の実施形態は、データパケットヘッダ（例えば、イーサネットヘッダ）内の１つまたは複数のフィールドについての値が、ＴＳＮストリームなどの確立されたデータストリームに関して静的であると想定する。このコンテキストでは、値がデータストリーム内のシーケンスにおいて複数のデータパケットに対して同じままである場合に、値は「静的」であると考えることができる。したがって、これはヘッダ内のフィールドの値が必要に応じて更新される（つまり、準静的）実施形態を排除するものではない。フィールド用の値は、データストリームの寿命の間、同じままであってもよく、同じままでなくてもよい。
ＴＳＮストリームが確立され、設定はあらゆるデータパケットが送信される前にＴＳＮストリームに関与するすべてのノードに対して適用される。これには、ＴＳＮストリーム識別子が通知されることも含まれる。
図１２８は、ＴＳＮデータパケット用のフレーム構造を示している。ＴＳＮストリーム内では、ヘッダフィールドはストリームを識別するために使用される。これらのフィールドは、例えば、ＤＳＴ ＭＡＣアドレス（６バイト）、ＶＬＡＮヘッダ（４バイト）、およびＩＰヘッダフィールド（様々なフィールド）から成る。これらのフィールドは、通常ＴＳＮストリームがセットアップされた後は、変更されない。したがって、これらのフィールドは、５Ｇネットワーク全体を通じて、例えば、ＵＰＦからＵＥへ、ｇＮＢからＵＥへなど、静的な圧縮の可能性を提供する。
本開示の一実施形態によると、データパケット用のヘッダ内の１つまたは複数のフィールドは、データ送信が行われる前に、ＵＥおよび／もしくはｇＮＢまたはＵＰＦ用に設定される。例えば、１つまたは複数のフィールドは、イーサネットヘッダを含む場合があり、例えばＴＳＮストリーム識別に使用される場合におけるＩＰヘッダの部分として他のヘッダフィールドでもよい。
ＱｏＳフローにおいて受信または送信されたパケット用のヘッダ内のフィールド用の値は、ＱｏＳフローごとに設定することができる。追加的に、または代替的に、ＰＤＵセッションにおいて受信または送信されたパケット用のヘッダ内のフィールド用の値は、ＰＤＵセッションごとに設定することができる。
ダウンリンクでの手順を、図１２９に図示する。
ダウンリンクにおけるＴＳＮストリームでは、５Ｇ ＣＮ（例えば、ＡＭＦもしくはＵＰＦまたは両方の組合せなどのコアネットワークノード）は、ＴＳＮストリーム識別情報およびどのフィールドを静的として扱えるか否かに関して、ＴＳＮネットワークからの情報を使用することができるか、またはこのための事前設定を使用することができる。
識別子は、ＰＤＵセッションまたはＱｏＳフローの中にあるデータパケットに追加される場合があり、同一のセッションまたはフロー内で、複数のＴＳＮ／イーサネットストリームを区別する（したがって、識別子は、特定のＴＳＮ／イーサネットストリームについてのものである）。例えば、識別子は、送信のために統計的に除去されたイーサネットヘッダフィールドの代わりに使用してもよい。８ビットヘッダは、セッションまたはフロー内のＴＳＮストリームを別個にするために十分な場合がある。
ＵＰＦとＵＥとの間のヘッダ圧縮には（５Ｇ ＣＮによって開始される）、ＮＡＳシグナリングが使用される。シグナリングするために、これは、統計的にＵＥにマッピングされたヘッダコンテンツ、および任意選択的に、異なるＴＳＮストリーム同士を区別するためのＰＤＵセッション内またはＱｏＳフロー内で使用されるストリーム識別子も含む。５Ｇ ＣＮは、静的なマッピング用にＵＰＦを設定する。
ｇＮＢとＵＥとの間のヘッダ圧縮に関してダウンリンク送信では、ＲＲＣシグナリングを使用することができる。つまり、ＵＥに対し新しいＱｏＳフローが確立される際、ＵＥはこのＱｏＳフローで受信されたパケット用に設定されたヘッダを利用するように命令される。代替的な実施形態では、ＰＤＣＰ制御シグナリングは、それ以外の静的ヘッダコンテキストに更新を示すために採用され（つまり、ＵＥに新しいヘッダコンテキストを提供する）、ＵＥに準静的なヘッダ設定を可能にしている。
さらには、上のすべての場合で、静的なヘッダの更新が示された場合、または新しい静的なヘッダが示された場合、シーケンス番号が共に示される場合があり、それ以降では、新しいヘッダが解凍に使用されるべきパケットを識別している。
さらなる実施形態では、受信側となるエンティティ（例えば、ＤＬにおけるＵＥ）では、ヘッダ解凍に先立って、シーケンス番号にしたがって受信したパケットの並べ替えが適用されるべきである。このように、シーケンス番号と共に新しく設定されたヘッダを示すと、新しく設定されたヘッダが有効な第１のパケットが特定される。
アップリンクでの手順を、図１３０に図示する。
アップリンクにおけるＴＳＮストリームでは、ＵＥは、ＴＳＮストリーム識別情報およびどのフィールドが静的として扱えるか否かに関して、ＴＳＮネットワークから情報を得て、それに応じて５Ｇ ＣＮに知らせる場合がある（例えば、ＴＳＮネットワークからの要求を５Ｇ ＣＮに転送することによって）。
識別子は、ＰＤＵセッションまたはＱｏＳフローの中にあるデータパケットに追加される場合があり、同一のセッションまたはフロー内で、複数のＴＳＮ／イーサネットストリームを区別する（したがって、識別子は、特定のＴＳＮ／イーサネットストリームについてのものである）。例えば、識別子は、送信のために統計的に除去されたイーサネットヘッダフィールドの代わりに使用してもよい。８ビットヘッダは、セッションまたはフロー内のＴＳＮストリームを別個にするために十分な場合がある。
ＵＥとＵＰＦとの間のヘッダ圧縮には（ＵＥによって開始される）、やはりＮＡＳシグナリングが使用される。ＵＥは、ＴＳＮストリームパケットヘッダに関してＴＳＮネットワークから受信した任意のＴＳＮ設定データと共に要求をＮＡＳ上でシグナリングすることにより、静的なヘッダ圧縮を５ＧＣＮに要求することができる。次いで５ＧＣＮは、ＵＰＦにおいて静的なマッピングを設定し、可能であれば、複数のＴＳＮストリームを区別するためのＰＤＵセッション内またはＱｏＳフロー内で使用されるストリーム識別子を割り振ることもできる。５ＧＣＮは、ＮＡＳシグナリングを使用して、静的なマッピング、ならびに使用するべき潜在的な識別子について、ＵＥに知らせることができる。５ＧＣＮは、静的なマッピング用にＵＰＦを設定する。
さらには、上のすべての場合で、静的なヘッダの更新が示された場合、または新しい静的なヘッダが示された場合、シーケンス番号が共に示される場合があり、それ以降では、新しいヘッダが解凍に使用されるべきパケットを識別している。
アップリンク送信では、ＵＥは送信の前にイーサネットヘッダフィールドを除去するよう設定される。設定は、ＲＲＣシグナリングまたはＮＡＳシグナリングを介して示される可能性がある。ヘッダ除去機能は、ＳＤＡＰまたはＰＤＣＰ送信アルゴリズムで実装することができる。シーケンス番号が示される可能性があり、それ以降では、イーサネットヘッダフィールドの除去を適用する第１のパケットを識別する。
アップリンク送信では、５ＧネットワークがＵＥからパケットを受信した時にヘッダを考慮できるように、ＵＥは、あらゆるデータ送信に先立って（除去された）ヘッダを５Ｇネットワークに示す。また、この場合、ヘッダは、ＱｏＳフローごと、またはＰＤＵセッションごとに、設定することができる。さらには、シーケンス番号が示される可能性があり、ヘッダが除去されており、また設定ヘッダが適用されるべき第１のパケットを識別する。
さらなる実施形態では、受信側となるエンティティ（例えば、ｇＮＢまたはＵＬにおけるＵＰＦ）では、ヘッダ解凍に先立って、シーケンス番号にしたがって受信したパケットの並べ替えが適用されるべきである。このように、シーケンス番号と共に新しく設定されたヘッダを示すと、新しく設定されたヘッダが有効な第１のパケットが特定される。
ＴＳＮストリームを無線でハンドリングするために、無線リソースは、例えば半永続スケジューリング（ＳＰＳ）またはインスタントアップリンクアクセス（ＩＵＡ：ｉｎｓｔａｎｔ－ｕｐｌｉｎｋ ａｃｃｅｓｓ）を使用して、予め割り当てることができる。リソースの事前割り当ては、送信用の既知のペイロードサイズの恩恵を受ける。ＲｏＨＣフレームワークでは、最悪ケースのペイロードサイズは、さらにすべてのヘッダを含めたパケット全体である：コンテキスト全体を送信するためにいつ必要とされるかを判断できないため、最悪ケースに対してリソースを予約する必要がある。これは、上で概説した静的なヘッダ圧縮方法には当てはまらない。
ＴＳＮは、パケットのタイムリーな送達に基づいている。コンテキストを認識しないことが原因で、再送信またはバッファリングしなくてはならなかったパケットにより、最も受け入れ難い可能性があるパケットレイテンシを生じる。これは、パケットを破棄するか、または代わりに古いコンテキストを再使用する（または、本開示で紹介するように、統計的に設定する）かのいずれかのほうが良いであろう。
図１３１は、特定の実施形態による方法を描いている。方法は、１つまたは複数のコアネットワークノードによって実施することができる。例えば、方法は、ＡＭＦおよび／またはＵＰＦ（例えば、図１２６に関して上述したＡＭＦおよびＵＰＦなど）によって実施することができる。さらには、方法は、上述の図１２９における要素「５Ｇ ＣＮ」のアクションに関連するか、または対応することができる。方法は、外部データネットワーク（イーサネットのネットワークまたはＬＡＮなど）におけるデータストリーム（ＴＳＮまたは他の時間クリティカルなデータストリームなど）に関連付けられるデータパケットのトランスポートを可能にする。
方法は、ステップＶＶ１０２で始まり、ステップＶＶ１０２では、コアネットワークノードは、外部データネットワークにおけるデータストリーム用の設定情報を取得する。設定情報は、静的のままであるデータストリームに関連付けられるデータパケットのヘッダ内の１つまたは複数のフィールドの個々の値を示す。コアネットワークノードは、そのような設定情報を外部データネットワークから直接受信する（例えば、データストリームを確立するための要求メッセージ内で）か、または情報で事前設定することができる。値が静的であり得る１つまたは複数のフィールドは、次のうちの１つまたは複数（あるいは、すべて）などの、１つまたは複数のイーサネットヘッダフィールドを含むことができる：宛先アドレスフィールド、ソースアドレスフィールド、仮想ＬＡＮタグフィールド、およびタイプ／長さフィールド。１つまたは複数のフィールドは、追加的にまたは代替的に、ＩＰヘッダ内に１つまたは複数のフィールドを含むことができる。
ステップＶＶ１０４では、コアネットワークノードは設定情報の送信を、データストリームを受信する無線デバイスに向けて開始する。例えば、設定情報は、ＮＡＳシグナリングを介して送信することができる。
コアネットワークノードは、データストリーム用の識別子を確立して、このデータストリームを他のデータストリームと区別できるようにすることができる。データパケットがＰＤＵセッションまたはＱｏＳフローの一部として無線デバイスに送信される実施形態では、識別子は、ＰＤＵセッションまたはＱｏＳフロー内で一意であることができる（したがって、そのような実施形態では、識別子の値は、ＰＤＵセッションまたはＱｏＳフロー外部では異なるデータフローに再使用することができる）。設定情報は、関連付けられるデータストリーム用の識別子を追加的に含むことができる。
ステップＶＶ１０６では、コアネットワークノードは外部データネットワークからデータストリームに関連付けられるデータパケットを受信する。データパケットは、あらゆる適切なメカニズムによってデータストリームに関連付けられる、またはデータストリームに属するものとして識別することができる。識別は、ＭＡＣアドレスならびにＶＬＡＮヘッダおよび／またはＩＰヘッダに基づくことができる。代替的に、または追加的に、データパケットを識別するために、他の態様（例えば、Ｅｔｈｅｒ－Ｔｙｐｅフィールド）を導入することもできる。
ステップＶＶ１０８では、コアネットワークノードは１つまたは複数のフィールドをデータパケットから除去して、圧縮されたデータパケットを生成する。つまり、コアネットワークノードは、ステップＶＶ１０２で取得された設定情報で識別された１つまたは複数のフィールドを除去する。任意選択的に、コアネットワークノードは、データストリーム用の識別子を圧縮されたデータパケットに追加することができる。識別子は、１つまたは複数のフィールドが除去される前、または後に、データパケットに追加できることが理解されよう。
ステップＶＶ１１０では、コアネットワークノードは、圧縮されたデータパケットの無線デバイスへの送信を、開始する。例えば、コアネットワークノードは、それ以降の無線デバイスへの送信のために、圧縮されたデータパケットを無線アクセスノード（ｇＮＢまたは他の基地局など）に送ることができる。
本開示のさらなる実施形態では、データストリーム用の設定情報は、上の設定が確立された後に更新されるようになる場合がある。そのような実施形態では、更新された設定情報は、データストリーム用に取得することができ（例えば、外部データネットワークから）、静的なままであるデータストリームに関連付けられるデータパケットのヘッダ内の１つまたは複数のフィールドの個々の更新された値のインジケーションを含んでいる。静的な値を有する１つまたは複数のフィールドは、元々識別された１つまたは複数のフィールドと同じである場合もあり、異なる場合もある。次いで、更新された設定情報は、無線デバイスに（例えば、ＮＡＳシグナリングを介して）送信することができ、無線デバイスが更新された設定にしたがってヘッダ情報が除去されているデータパケットを解凍できるようにする。更新された設定情報には、更新された設定が適用されるデータストリームに関連付けられる一連のデータパケット内のデータパケットを示すシーケンス番号が含まれる場合がある。
図１３２は、特定の実施形態による方法を描いている。方法は、１つまたは複数のコアネットワークノードによって実施することができる。例えば、方法は、ＡＭＦおよび／またはＵＰＦ（例えば、図１２６に関して上述したＡＭＦおよびＵＰＦなど）によって実施することができる。さらには、方法は、上述の図１３０における要素「５Ｇ ＣＮ」のアクションに関連するか、または対応することができる。方法は、外部データネットワーク（イーサネットのネットワークまたはＬＡＮなど）におけるデータストリーム（ＴＳＮまたは他の時間クリティカルなデータストリームなど）に関連付けられるデータパケットのトランスポートを可能にする。
方法は、ステップＶＶ２０２で始まり、ステップＶＶ２０２では、コアネットワークノードは、外部データネットワークにおけるデータストリーム用の設定情報を取得する。設定情報は、静的のままであるデータストリームに関連付けられるデータパケットのヘッダ内の１つまたは複数のフィールドの個々の値を示す。コアネットワークノードは、そのような設定情報を外部データネットワークから直接（例えば、データストリームを確立するための要求メッセージ内で）、データストリームに関連付けられるもしくはデータストリームに属するデータパケットを送信する無線デバイスから（例えば、ＮＡＳシグナリングなどのシグナリング上で無線デバイスによって転送された外部データネットワークからの要求メッセージ内で）受信することができる、または、情報で事前設定される場合がある。値が静的であり得る１つまたは複数のフィールドは、次のうちの１つまたは複数（あるいは、すべて）などの、１つまたは複数のイーサネットヘッダフィールドを含むことができる：宛先アドレスフィールド、ソースアドレスフィールド、仮想ＬＡＮタグフィールド、およびタイプ／長さフィールド。１つまたは複数のフィールドは、追加的にまたは代替的に、ＩＰヘッダ内に１つまたは複数のフィールドを含むことができる。
データストリーム用の識別子は、他のデータストリームから区別できるように確立されてもよい。データパケットがＰＤＵセッションまたはＱｏＳフローの一部として無線デバイスによって送信される実施形態では、識別子は、ＰＤＵセッションまたはＱｏＳフロー内で一意であることができる（したがって、そのような実施形態では、識別子の値は、ＰＤＵセッションまたはＱｏＳフロー外部では異なるデータフローに再使用することができる）。設定情報は、関連付けられるデータストリーム用の識別子を追加的に含むことができる。代替的に、コアネットワークノードがデータストリーム用の識別子を確立する場合、識別子は、コアネットワークノードによって無線デバイスに送信される場合がある。
任意選択的に、方法は、設定情報を、データストリームに関連付けられるまたはデータストリームに属するデータパケットを送信する無線デバイスに送るステップをさらに含む場合がある（図示せず）。このステップは、特にステップＶＶ２０２において設定情報が無線デバイスから受信されない場合、または無線デバイスが、設定情報それ自身を（例えば、外部データネットワークから受信した要求メッセージから）処理および取得することができない場合に当てはまる場合がある。設定情報は、例えばＮＡＳシグナリングを介して送られてもよい。
ステップＶＶ２０４では、コアネットワークノードは無線デバイスからデータストリームに関連付けられるデータパケットを受信する。データパケットは、ステップＶＶ２０２で取得された設定情報にしたがって、ヘッダ内の１つまたは複数のフィールドの除去によって（例えば、図１３３の下部で説明される方法にしたがって無線デバイスにより）圧縮される。
ステップＶＶ２０６では、解凍されたデータパケットを生成するために、コアネットワークノードは１つまたは複数のフィールドをデータパケットから追加する。つまり、コアネットワークノードは、ステップＶＶ２０２で取得された設定情報で識別された１つまたは複数のフィールドを追加する。
ステップＶＶ２０８では、コアネットワークノードは、外部データネットワーク上で解凍されたデータパケットの送信を、開始する。
本開示のさらなる実施形態では、データストリーム用の設定情報は、上の設定が確立された後に更新されるようになる場合がある。そのような実施形態では、更新された設定情報は、データストリーム用に取得することができ（例えば、外部データネットワークまたは無線デバイスから）、静的なままであるデータストリームに関連付けられるデータパケットのヘッダ内の１つまたは複数のフィールドの個々の更新された値のインジケーションを含んでいる。静的な値を有する１つまたは複数のフィールドは、元々識別された１つまたは複数のフィールドと同じである場合もあり、異なる場合もある。特に、更新された設定情報が外部データネットワークから直接受信される場合、無線デバイスに（例えば、ＮＡＳシグナリングを介して）送信される更新された設定情報。追加的に、または代替的に、更新された設定情報は、更新された設定にしたがって無線デバイスによって圧縮されている、将来的に受信するデータパケットを解凍するために利用される。更新された設定情報には、更新された設定が適用されるデータストリームに関連付けられる一連のデータパケット内のデータパケットを示すシーケンス番号が含まれる場合がある。したがって、コアネットワークノードは、更新された設定情報内で示されるシーケンス番号に続くすべてのデータパケットの更新された設定にしたがって、ヘッダフィールドを追加することができる。任意選択的に、コアネットワークノードは、受信したデータパケットをその個々のシーケンス番号にしたがって並べ替えて、この処理を容易にすることができる。
図１３３は、特定の実施形態による方法を描いている。方法は、無線デバイス（例えば、図１２６に関して上述したＵＥなど）によって実施することができる。さらには、方法は、上述の図１２９における要素「ＵＥ」のアクションに関連するか、または対応することができる。方法は、外部データネットワーク（イーサネットのネットワークまたはＬＡＮなど）におけるデータストリーム（ＴＳＮまたは他の時間クリティカルなデータストリームなど）に関連付けられるデータパケットのトランスポートを可能にする。
方法は、ステップＸＸ１０２で始まり、ステップＸＸ１０２では、無線デバイスは、外部データネットワークにおけるデータストリーム用の設定情報を取得する。設定情報は、静的のままであるデータストリームに関連付けられるデータパケットのヘッダ内の１つまたは複数のフィールドの個々の値を示す。無線デバイスは、そのような設定情報を外部データネットワークから直接（例えば、データストリームを確立するための要求メッセージ内で）、または１つまたは複数のコアネットワークノードから（例えば、ｇＮＢまたは他の基地局などの無線アクセスネットワークノードからの送信を介して、ＮＡＳシグナリングを介して）受信することができる。値が静的であり得る１つまたは複数のフィールドは、次のうちの１つまたは複数（あるいは、すべて）などの、１つまたは複数のイーサネットヘッダフィールドを含むことができる：宛先アドレスフィールド、ソースアドレスフィールド、仮想ＬＡＮタグフィールド、およびタイプ／長さフィールド。１つまたは複数のフィールドは、追加的にまたは代替的に、ＩＰヘッダ内に１つまたは複数のフィールドを含むことができる。
データストリーム用の識別子は、他のデータストリームから区別できるように確立されてもよい。データパケットがＰＤＵセッションまたはＱｏＳフローの一部として無線デバイスによって受信される実施形態では、識別子は、ＰＤＵセッションまたはＱｏＳフロー内で一意であることができる（したがって、そのような実施形態では、識別子の値は、ＰＤＵセッションまたはＱｏＳフロー外部では異なるデータフローに再使用することができる）。設定情報は、関連付けられるデータストリーム用の識別子を追加的に含むことができる。
ステップＸＸ１０４では、無線デバイスは、無線アクセスネットワークノードからデータストリームに関連付けられるデータパケットを受信する。データパケットは、ステップＸＸ１０２で取得された設定情報にしたがって、ヘッダ内の１つまたは複数のフィールドの除去によって（例えば、上で説明される方法にしたがって、コアネットワークノードまたは無線アクセスネットワークノードそれ自身によって）圧縮される。
ステップＸＸ１０６では、解凍されたデータパケットを生成するために、無線デバイスは１つまたは複数のフィールドをデータパケットから追加する。つまり、無線デバイスは、ステップＸＸ１０２で取得された設定情報で識別された１つまたは複数のフィールドを追加する。任意選択的に、解凍されたデータパケットは、それ以降、外部データネットワーク上で送信することができる。
本開示のさらなる実施形態では、データストリーム用の設定情報は、上の設定が確立された後に更新されるようになる場合がある。そのような実施形態では、更新された設定情報は、データストリーム用に取得することができ（例えば、コアネットワークノードから）、静的なままであるデータストリームに関連付けられるデータパケットのヘッダ内の１つまたは複数のフィールドの個々の更新された値のインジケーションを含んでいる。静的な値を有する１つまたは複数のフィールドは、元々識別された１つまたは複数のフィールドと同じである場合もあり、異なる場合もある。次に、更新された設定情報は、更新された設定にしたがってコアネットワークノードまたは無線アクセスネットワークノードによって圧縮されている、将来的に受信するデータパケットを解凍するために利用される。更新された設定情報には、更新された設定が適用されるデータストリームに関連付けられる一連のデータパケット内のデータパケットを示すシーケンス番号が含まれる場合がある。したがって、無線デバイスは、更新された設定情報内で示されるシーケンス番号に続くすべてのデータパケットの更新された設定にしたがって、ヘッダフィールドを追加することができる。任意選択的に、無線デバイスは、受信したデータパケットをその個々のシーケンス番号にしたがって並べ替えて、この処理を容易にすることができる。
図１３４は、特定の実施形態による方法を描いている。方法は、無線デバイス（例えば、図１２６に関して上述したＵＥなど）によって実施することができる。さらには、方法は、上述の図１３０における要素「ＵＥ」のアクションに関連するか、または対応することができる。方法は、外部データネットワーク（イーサネットのネットワークまたはＬＡＮなど）におけるデータストリーム（ＴＳＮまたは他の時間クリティカルなデータストリームなど）に関連付けられるデータパケットのトランスポートを可能にする。
方法は、ステップＸＸ２０２で始まり、ステップＸＸ２０２では、無線デバイスは、外部データネットワークにおけるデータストリーム用の設定情報を取得する。設定情報は、静的のままであるデータストリームに関連付けられるデータパケットのヘッダ内の１つまたは複数のフィールドの個々の値を示す。無線デバイスは、そのような設定情報を外部データネットワークから直接（例えば、データストリームを確立するための要求メッセージ内で）、または１つまたは複数のコアネットワークノードから（例えば、ＮＡＳまたはＲＲＣシグナリングを介して）受信することができる。値が静的であり得る１つまたは複数のフィールドは、次のうちの１つまたは複数（あるいは、すべて）などの、１つまたは複数のイーサネットヘッダフィールドを含むことができる：宛先アドレスフィールド、ソースアドレスフィールド、仮想ＬＡＮタグフィールド、およびタイプ／長さフィールド。１つまたは複数のフィールドは、追加的にまたは代替的に、ＩＰヘッダ内に１つまたは複数のフィールドを含むことができる。
データストリーム用の識別子は、他のデータストリームから区別できるように（例えば、１つまたは複数のコアネットワークノードによって）確立されてもよい。データパケットがＰＤＵセッションまたはＱｏＳフローの一部として無線デバイスによって受信される実施形態では、識別子は、ＰＤＵセッションまたはＱｏＳフロー内で一意であることができる（したがって、そのような実施形態では、識別子の値は、ＰＤＵセッションまたはＱｏＳフロー外部では異なるデータフローに再使用することができる）。設定情報は、関連付けられるデータストリーム用の識別子を追加的に含むことができる。
ステップＸＸ２０４では、無線デバイスは、データストリームに関連付けられるまたはデータストリームに属するデータパケットを取得する。例えば、データパケットは、外部データネットワークから受信され得る、または（例えば、何らかのユーザ対話に応じて、または無線デバイス上でアプリケーションを実行することによって）無線デバイスによって生成され得る。
ステップＸＸ２０６では、圧縮されたデータパケットを生成するために、無線デバイスは１つまたは複数のフィールドをデータパケットから除去する。つまり、無線デバイスは、ステップＸＸ２０２で取得された設定情報で識別された１つまたは複数のフィールドを除去する。任意選択的に、無線デバイスは、データストリーム用の識別子を圧縮されたデータパケットに追加することができる。識別子は、１つまたは複数のフィールドが除去される前、または後に、データパケットに追加できることが理解されよう。ヘッダ除去機能は、ＳＤＡＰまたはＰＤＣＰ送信アルゴリズムで実装することができる。
ステップＸＸ２０８では、無線デバイスは、外部データネットワーク上で圧縮されたデータパケットの送信を、開始する。例えば、無線デバイスは、それ以降の１つまたは複数のコアネットワークノードおよびその後の外部データネットワークへの送信のために、圧縮されたデータパケットを無線アクセスネットワークノード（ｇＮＢまたは他の基地局など）への送信中に送ることができる。１つまたは複数のコアネットワークノードは、圧縮されたデータパケットを、例えば、上述の方法にしたがうことによって）、外部データネットワーク上での送信に先立って解凍することができる。
さらなる実施形態では、データストリーム用の設定情報は、上の設定が確立された後に更新されるようになる場合がある。そのような実施形態では、更新された設定情報は、データストリーム用に取得することができ（例えば、外部データネットワークから）、静的なままであるデータストリームに関連付けられるデータパケットのヘッダ内の１つまたは複数のフィールドの個々の更新された値のインジケーションを含んでいる。静的な値を有する１つまたは複数のフィールドは、元々識別された１つまたは複数のフィールドと同じである場合もあり、異なる場合もある。次に、更新された設定情報は、無線デバイスによって、１つまたは複数のコアネットワークノードに送信することができ（例えば、ＮＡＳシグナリングを介して）、これらのコアネットワークノードが更新された設定にしたがってヘッダ情報が除去されているデータパケットを解凍できるようにする。更新された設定情報には、更新された設定が適用されるデータストリームに関連付けられる一連のデータパケット内のデータパケットを示すシーケンス番号が含まれる場合がある。
図１３１～図１３４で示される方法は、図１２０～図１２５で示されるノードのうちの１つまたは複数に、適宜実装できることを諒解されたい。
リソーススケジューリングとヘッダ圧縮技法との組合せ
上で示したように、本明細書で説明される様々な技法は、互いに組み合わせて、レイテンシ、信頼性などに関する優位性を与えることができる。例えば、有利である１つの特定の組合せは、リソースをスケジューリングするための上述の技法とＴＳＮフレームのヘッダを圧縮するための説明した技法との組合せである。
したがって、例えば、図１１７に図示される方法は、図１３１で示される方法と組み合わせることが可能であり、結果として、方法は、ユーザ機器（ＵＥ）および外部ネットワークに関連付けられる時間センシティブなデータストリームをハンドリングするために、無線アクセスネットワーク（ＲＡＮ）に関連付けられるコアネットワークのうちの１つまたは複数のノードで実施される。この方法は、図１１７のブロック１２１０で示されるように、外部ネットワークから時間センシティブなデータストリームに関連付けられる送信スケジュールを受信するステップを含み、同図のブロック１２２０で示されるように、ＲＡＮと第１のＵＥとの間のデータストリームの通信用の無線リソースを割り当てる要求をＲＡＮに送るステップをさらに含み、要求は、送信スケジュールに関連する情報をさらに含む。図１１７のブロック１２３０で示されるように、方法は、ＲＡＮから、無線リソースがデータストリームに関連付けられる送信スケジュールを満足するよう割り当てることができるかどうかを示す応答を受信することをさらに含む。
方法は、データストリームの設定情報を取得するステップをさらに含み、設定情報は、静的のままであるデータストリームに関連付けられるデータパケットのヘッダ内の１つまたは複数のフィールドの個々の値を示す。このステップは、図１３１のブロックＶＶ１０２で示される。図１３１のブロックＶＶ１０４、ＶＶ１０６、ＶＶ１０８、およびＶＶ１１０で示されるように、方法は、設定情報の第１のＵＥへの送信を開始するステップと、データストリームに関連付けられるデータパケットを外部データネットワークから受信するステップと、１つまたは複数のフィールドをデータパケットから除去して圧縮されたデータパケットを生成するステップと、圧縮されたデータパケットの第１のＵＥへの送信を開始するステップとをさらに含む。
これらの技法について上で議論した変形のいずれも、ここでは組み合わされた技法に当てはまることを諒解されたい。したがって、例えば、外部ネットワークは、時間センシティブなネットワーク（ＴＳＮ）を含み、いくつかの実施形態では、データストリームはＴＳＮストリームを含む。ここで、送信スケジュールは、サイクル時間およびＴＳＮストリームを含む１つまたは複数のトラフィッククラスについてのゲート制御リストを含むことができる。
いくつかの実施形態では、送信スケジュールに関連する情報には、以下のうちの１つまたは複数が含まれる：第１のＵＥの識別子、データストリームに関連付けられる１つまたは複数のサービス品質（ＱｏＳ）フローの識別子、およびＱｏＳフローのそれぞれに関連付けられるＱｏＳ要件。これらの実施形態のうちの一部では、各ＱｏＳ要件は、データストリームが送信される必要がある１つまたは複数の時間ウィンドウ、ならびに／あるいは初期時間ウィンドウおよび後続の時間ウィンドウを識別する周期性を含む。後者の実施形態の一部では、無線リソースがデータストリームの送信スケジュールを満足するよう割り当てることができないことを応答が示す場合、応答は、無線リソースを割り当てることができる１つまたは複数のさらなる時間ウィンドウのインジケーションをさらに含む。いくつかの実施形態では、応答は、ＱｏＳフローのそれぞれに関連付けられるＱｏＳ要件が満足され得るかどうかを示し、方法は、送信スケジュールがＱｏＳフローのそれぞれに関連付けられるＱｏＳ要件が満足され得るかどうかのインジケーションに基づいて満足され得るかどうかを判断することをさらに含む。
いくつかの実施形態では、方法は、外部ネットワークに、送信スケジュールが満足され得るかどうかのインジケーションを送ることをさらに含む。これらの実施形態の一部および他の実施形態では、方法は、５Ｇコアネットワーク（５ＧＣ）のアクセス管理機能（ＡＭＦ）によって実施される。いくつかの実施形態では、送信スケジュールは、外部ネットワークから受信することができ、無線リソースは、ＲＡＮから第１のＵＥへのダウンリンク通信用であることができ、または他の実施形態もしくは事例においては、送信スケジュールは、第１のＵＥから受信することができ、無線リソースは、第１のＵＥからＲＡＮへのアップリンク通信用であることができる。
いくつかの実施形態では、設定情報を取得するステップは、外部データネットワークから設定情報を受信することを含む。他では、設定情報は、コアネットワークのうちの１つまたは複数のノードにおいて事前設定される。
いくつかの実施形態では、圧縮されたデータパケットは、データストリーム用の識別子を含む。識別子は、コアネットワークノードのうちの１つまたは複数のノードによって追加される。
いくつかの実施形態では、圧縮されたデータパケットは、プロトコルデータユニット（ＰＤＵ）セッションまたはサービス品質（ＱｏＳ）フローの一部として第１のＵＥに送信される。これらのいくつかの実施形態の一部では、上で言及した識別子は、ＰＤＵセッションまたはＱｏＳフロー内で一意であることができる。
いくつかの実施形態では、設定情報は、非アクセス階層（ＮＡＳ）シグナリングを使用して第１のＵＥに送信される。一部では、設定情報は、データストリーム用の識別子を含む。
いくつかの実施形態では、方法は、データストリームの更新された設定情報を取得することであって、更新された設定情報は、静的なままであるデータストリームに関連付けられるデータパケットのヘッダ内の１つまたは複数のフィールドの個々の更新された値のインジケーションを含んでいる、取得することと、更新された設定情報の第１のＵＥへの送信を開始することをさらに含む。この更新された設定情報は、個々の更新された値が適用されるデータストリームに関連付けられるデータパケットを識別するシーケンス番号のインジケーションをさらに含むことができる。
先の実施形態のいずれにおいても、データパケットは、ユーザデータを含むことができ、圧縮されたデータパケットの第１のＵＥへの送信を開始するステップは、基地局への送信を介してユーザデータを第１のＵＥへ転送することを含むことができる。
上述の解凍技法は、これらの技法と組み合わせることもできる。したがって、図１３２のブロックＶＶ２０４、ＶＶ２０６、およびＶＶ２０８で示されるように、コアネットワークのうちの１つまたは複数のノードによって実行されるいくつかの方法は、データストリームに関連付けられるデータパケットを第２のＵＥから受信することと、１つまたは複数のフィールドをデータパケットに追加して解凍されたデータパケットを生成することと、解凍されたデータパケットの送信を外部データネットワーク上で開始することとを含むことができる。
いくつかの実施形態では、方法は、静的なままであるデータストリームに関連付けられるデータパケットのヘッダ内の１つまたは複数のフィールドの個々の値のインジケーションの、第２のＵＥへの送信を開始することをさらに含むことができる。データパケットは、ユーザデータを含むことができ、解凍されたデータパケットの送信を外部データネットワーク上で開始するステップは、外部データネットワーク上でユーザデータをホストコンピュータへ転送することを含むことができる。
ＲＡＮ上のＴＳＮ
自律的、多機能、および／またはモバイルの機械類ならびにロボットなどの、工場自動化の少なくとも一部のユニットは、ワイヤレス無線通信によるネットワーキングを必要とする。しかしながら、ＲＡＮのモバイル端末、例えば３ＧＰＰユーザ機器（ＵＥ）として作用する工場用ユニットは、ＲＡＮの無線基地局との無線接続を、この特定の無線基地局はＴＳＮをサポートしないことを確認するだけのために確立する必要がある。
そのため、ワイヤレス無線通信上でのＴＳＮを可能にする技法が必要である。代替的またはより具体的な目的は、好ましくはモバイル端末と無線基地局との間の無線接続を確立することに先立って、モバイル端末がＴＳＮをサポートする無線基地局を具体的に選択できるようにすることである。
図１３５は、ＲＡＮ上でＴＳＮをハンドリングする方法４００のフローチャートを示している。方法４００は、ＲＡＮのＲＢＳからＳＩを受信するステップ４０２を含む。ＳＩは、ＲＢＳを通じるＴＳＮのサポートに関して、暗示的または示唆的である。ＳＩは、ＲＢＳ特有であってもよい。方法４００は、受信したＳＩに応じて、ＲＢＳを通じてＴＳＮの少なくとも１つのＴＳＮストリームを確立する、または確立を開始するステップ４０４をさらに含む。方法４００は、ＲＡＮへ無線接続されたＵＥ、または無線接続可能なＵＥによって実施することができる。
図１３６は、ＲＡＮ上でＴＳＮを通知する方法５００のフローチャートを示している。方法５００は、ＲＡＮのＲＢＳからＳＩを送信するステップ５０２を含む。ＳＩは、ＲＢＳを通じるＴＳＮのサポートに関して、暗示的または示唆的である。ＳＩは、ＲＢＳ特有であってもよい。方法５００は、送信されたＳＩにしたがって、ＲＢＳを通じてＴＳＮの少なくとも１つのＴＳＮストリームをサポートするステップ５０４をさらに含む。方法５００は、例えば、ＲＡＮのＲＢＳによって実施することができる。
図１３７は、ＲＡＮ上でＴＳＮのための設定メッセージを配信する方法６００のフローチャートを示している。方法６００は、ＲＡＮの少なくとも１つのＲＢＳを通じるＴＳＮのためのサポートに関して、少なくとも１つの設定メッセージが示唆的かまたは暗示的かを判断するステップ６０２を含む。方法６００は、少なくとも１つの設定メッセージを、ＣＮからＲＡＮの少なくとも１つのＲＢＳのそれぞれに送るステップ６０４をさらに含む。
方法６００は、ＣＮによって、および／またはＣＮ、ＡＭＦ、もしくはＭＭＥのネットワークコンポーネントを使用することによって、および／またはＴＳＮ機能を使用することによって、実施することができる。ＴＳＮ機能は、集中型ネットワーク設定（ＣＮＣ）または集中型ユーザ設定（ＣＵＣ）であることができる。
受信したＳＩに応じて、少なくとも１つのＴＳＮストリームを確立する、または確立を開始するステップ４０４は、少なくとも１つのＴＳＮストリームを、選択的に（例えば、条件付きで）確立すること、または選択的に（例えば、条件付きで）確立を開始することを含むことができる。選択性（例えば、条件性）は、受信したＳＩに依存的であり得る。ＵＥは、ＲＢＳからのＳＩに基づいて、例えば基地局へアクセスすることまたは接続することに先立って、ＴＳＮストリームの確立を試行するかどうかを決定することができる。
少なくとも１つのＴＳＮストリームを確立する、または確立を開始するステップ４０４は、ＲＡＮのＲＢＳとのランダムアクセス手順、ＲＡＮのＲＢＳとの無線リソース制御（ＲＲＣ）接続セットアップ、およびＲＡＮに接続されたＣＮとのネットワークアタッチ手順のうちの少なくとも１つを選択的に実施すること、または選択的に実施を開始することを含むことができる。選択性は、受信したＳＩに依存的であり得る。
確立するステップ４０４は、少なくとも１つの確立されたＴＳＮストリームを使用するＴＳＮアプリケーションを実施すること、または実施を開始することを含むことができる。ＴＳＮアプリケーションまたはＴＳＮアプリケーションのクライアントは、ＵＥで実施することができる。ステップ４０４における選択性（例えば、条件性）は、受信したＳＩが、ＴＳＮアプリケーションによって必要とされるＴＳＮ特徴を示している場合、遂行され得る。
ＳＩを受信するステップ４０２は、ＲＡＮの複数のＲＢＳのそれぞれについて、実施される。少なくとも１つのＴＳＮストリームを確立する、または確立を開始するステップ４０４は、複数のＲＢＳの中から、そのＳＩがＴＳＮアプリケーションによって必要とされるＴＳＮ特徴を示すＲＢＳを選択することを含むことができる。
個々のＳＩにしたがって必要とされるＴＳＮ特徴を最良に遂行するＲＢＳが、選択され得る（例えば、複数のＲＢＳのいずれも、必要とされるＴＳＮ特徴を遂行しない場合）。代替的に、または追加で、そのＳＩが最も好ましくＴＳＮ特徴を示すＲＢＳが、選択され得る（例えば、複数のＲＢＳのうちの２つ以上が、必要とされるＴＳＮ特徴を遂行する場合）。
方法４００は、制御メッセージをＣＮに送るステップをさらに含むことができる。制御メッセージは、ＴＳＮアプリケーションによって必要とされるＴＳＮ特徴を示す場合がある。制御メッセージは、非アクセス階層（ＮＡＳ）メッセージである可能性がある。
制御メッセージは、ＴＳＮへの要求を示す場合がある。制御メッセージは、ＣＵＣへ転送される場合がある。
ＳＩは、ＲＢＳによってサポートされる、またはＲＢＳを通じる少なくとも１つのＴＳＮ特徴を暗示するまたは示唆する場合がある。ＳＩは、ＲＢＳ特有であってもよい。ステップ４０４における選択性（例えば、条件性）は、少なくとも１つのサポートされるＴＳＮ特徴に依存する可能性がある。代替的に、または追加で、ＴＳＮストリームは、少なくとも１つのサポートされるＴＳＮ特徴に応じてＲＡＮ上で確立することができる。例えば、少なくとも１つのＴＳＮストリームを確立することは、少なくとも１つのサポートされるＴＳＮ特徴に応じて、ＲＢＳとのランダムアクセスを実施すること、または実施を開始することを含むことができる。
本明細書では、ＴＳＮ特徴は、ＴＳＮ用のＲＢＳにおいて利用可能なあらゆる特徴または機能性を包含することができる。ＲＢＳを通じてサポートされる少なくとも１つのＴＳＮ特徴は、ＲＢＳのＴＳＮ能力と称される場合もある。
少なくとも１つのＴＳＮ特徴は、時間同期、少なくとも１つのＴＳＮストリームのレイテンシバウンド、および少なくとも１つのＴＳＮストリームの信頼性尺度のうちの少なくとも１つを含むことができる。時間同期は、ＲＢＳおよび／またはネットワークコンポーネントが少なくとも１つのＴＳＮストリームを処理すること（例えば、トランスポートすること）の時間同期であることができる。
代替的に、または追加で、ＳＩは、ＲＢＳを通じるＴＳＮのＴＳＮ設定（また、ＴＳＮ設定スキーム）を示す場合がある。例えば、少なくとも１つのＴＳＮストリームの確立すること４０４は、ＴＳＮ設定にしたがってＴＳＮセットアップを実施すること、または開始することを含むことができる。ＴＳＮ設定は、ＣＮＣおよびＣＵＣのうちの少なくとも１つの利用可能性または利用不可能性を示す場合がある。
ＳＩは、ステップ５０２において、ＲＢＳからブロードキャストされ得る。ＳＩは、ブロードキャストメッセージであり得る。ＳＩは、１つまたは複数のシステム情報ブロック（ＳＩＢ）に含まれる可能性がある。
方法５００は、ＲＢＳにおいてＣＮからのＴＳＮのサポートを示す設定メッセージを受信するステップをさらに含むことができる。ＲＢＳによって送信されたＳＩは、受信した設定メッセージから導出することができる。
ＳＩは、ＲＢＳによってサポートされる、またはＲＢＳを通じる少なくとも１つのＴＳＮ特徴を暗示するまたは示唆する場合がある。ＳＩは、１つまたは複数のＳＩＢにおいてブロードキャストされ得る。方法５００は、ＵＥおよび方法４００のコンテキストで開示されるあらゆる特徴および／もしくはステップ、またはそれに相当するあらゆる特徴もしくはステップをさらに含むことができる。
設定メッセージは、ＣＮのＡＭＦから送ることができる。設定メッセージは、ＲＢＳによってサポートされる、もしくはサポートされることになっている、またはＲＢＳを通じる少なくとも１つのＴＳＮ特徴を暗示するまたは示唆する場合がある。
方法６００は、方法４００および方法５００のあらゆる特徴もしくはステップ、またはそれに相当するあらゆる特徴もしくはステップをさらに含むことができる。
技法の実施形態は、「Ｓｙｓｔｅｍ Ａｒｃｈｉｔｅｃｔｕｒｅ ｆｏｒ ｔｈｅ ５Ｇ Ｓｙｓｔｅｍ」（Ｓｔａｇｅ ２）を指定する３ＧＰＰ文書ＴＳ２３．５０１、バージョン１５．１．０またはその後継との互換性を維持する。
ネットワーク（例えば、３ＧＰＰによって規定されるようなＮＲアクセスを提供するＲＡＮを含む５Ｇネットワーク）は、少なくとも一部のＲＢＳを通じてＴＳＮ送信をサポートするように設定される。ＵＥがＲＡＮ上（例えば、５Ｇ無線またはＮＲ）でそのようなＴＳＮネットワークにアタッチされるようになるための、ネットワーク全般、具体的にはＲＢＳ（例えば、ｇＮＢ）がＴＳＮ送信をサポートするか否かについての情報を得るための既存の方法がない。技法の実施形態では、ＳＩは、無線リソース制御（ＲＲＣ）接続モードに入り、５Ｇネットワークとさらにシグナリングする前に、ＵＥが一定のＴＳＮ特徴がサポートされるかどうか、および／またはどのようにサポートされるか判断できるようにする。このように、技法は、ＵＥひいてはＵＥが接続されるＴＳＮアプリケーションも、どのＴＳＮ特徴がネットワーク、具体的にはＲＡＮおよび／またはＳＩを送信するＲＢＳによって、サポートされるか、および／またはどのようにサポートされるかを認識できるようにする。
ＳＩは、ＴＳＮ特徴のサポートに関して暗示的または示唆的である場合がある。ＴＳＮ特徴は、時間同期、冗長性、信頼性、およびレイテンシ（例えば、推定されるエンドツーエンドのレイテンシ）のうちの少なくとも１つを含むことができる。
技法の実施形態は、ＵＥが、５Ｇネットワークにアタッチする前に、ＳＩ内で必要なＴＳＮ関連情報を受信できるようにする。この方法では、ＵＥは、どのＴＳＮ特徴が５Ｇネットワークによってサポートされるか認識する。さらには、５Ｇネットワークは、同じやり方で、ＴＳＮネットワークの設定詳細について、および／または例えば時間同期とネットワーク管理をどのように実施するかについて、１つまたは複数のＵＥに知らせる。
例えば、あるエリアをカバーする（例えば、工場ホールにデプロイされる）すべてのＲＢＳ（例えば、ｇＮＢ）がＴＳＮトラフィックをサポートしている訳ではない。技法は、一定のＲＢＳ（例えば、ｇＮＢ）、例えばＴＳＮをサポートしていないＲＢＳ、またはＵＥによって必要とされるＴＳＮ特徴をサポートしていないＲＢＳからのＴＳＮトラフィックを必要とするＵＥ（ＴＳＮ－ＵＥも）をブロックするよう実装することができる。
ＳＩは、１つまたは複数のシステム情報ブロック（ＳＩＢ）によって実装することができる。
マスタ情報ブロック（ＭＩＢ）の全体的な機能性および構造ならびにＮＲ向けのＳＩＢは、本質的にＬＴＥ向けのものと同一であり得る。ＮＲとＬＴＥとの間の違いは、ＮＲでは２つの異なるタイプのＳＩＢが提供されることである。第１のタイプのＳＩＢは、周期的に、例えばＬＴＥにおけるＳＩＢ送信と等しく、または類似して、送信される。第２のタイプのＳＩＢは、ＵＥから要求があった場合のみ送信される。
ＳＩＢは、ＲＢＳ（例えば、ｇＮＢ）によってブロードキャストされ、ＵＥがＲＢＳによってサービングされるセルにアクセスするために必要なシステム情報の主要部分、およびセル再選択についての他の情報を含む。ＳＩＢは、ダウンリンク共有チャネル（ＤＬ－ＳＣＨ）上で送信される。サブフレーム内のＤＬ－ＳＣＨについてのシステム情報の存在は、特殊なシステム情報無線ネットワーク一時識別子（ＳＩ－ＲＮＴＩ）でマークされた対応する物理ダウンリンク制御チャネル（ＰＤＣＣＨ）の送信によって示される。
複数の異なるＳＩＢが、ＬＴＥおよびＮＲ向けの３ＧＰＰによって規定され、例えば、ＳＩＢに含まれる情報のタイプによって特徴付けられる。このシステム情報は、ＵＥにネットワーク能力について知らせる。すべてのＳＩＢが存在するようサポートされる訳ではない。ＳＩＢはＲＢＳ（例えば、ｇＮＢ）によって繰り返しブロードキャストされる。
ＴＳＮネットワーク内、すなわち、ＴＳＮをサポートするネットワーク内では、通信のエンドポイントは、ＴＳＮトーカおよびＴＳＮリスナと呼ばれる。ＴＳＮトーカおよびＴＳＮリスナのうちの少なくとも１つは、ＵＥである。ＴＳＮのサポートのため、ＴＳＮトーカとＴＳＮリスナとの間にあるすべてのＲＢＳおよびネットワークコンポーネント（例えば、スイッチ、ブリッジ、またはルータ）は、一定のＴＳＮ特徴、例えばＩＥＥＥ８０２．１ＡＳ時間同期をサポートする。ネットワーク内で同期されるすべてのノード（例えば、ＲＢＳおよび／またはネットワークコンポーネント）は、いわゆるＴＳＮドメインに属している。ＴＳＮ通信は、そのようなＴＳＮドメイン内でのみ可能である。
ＲＡＮ用のＴＳＮまたはＴＳＮ用に設定されたＲＡＮは、ＴＳＮ特徴とも称される確定的なネットワーキングのための特徴を含むことができる。ＴＳＮ特徴は、時間同期、保証された（例えば、低い）レイテンシ送信（例えば、レイテンシに対する上限）、および保証された（例えば、高い）信頼性（例えば、パケット誤り率に対する上限）のうちの少なくとも１つを含むことができる。時間同期は、ＲＡＮのコンポーネント（例えば、ＲＢＳ）同士および／またはネットワークコンポーネント同士（例えば、バックホールドメインおよび／またはＣＮにおいて）の時間同期を含むことができる。
任意選択的に、ＳＩは、個々のＲＢＳを通じてサポートされるＴＳＮ特徴を示す。
サポートされるＴＳＮ特徴は、以下のカテゴリのグループのうちの少なくとも１つを含む、または少なくとも１つと互換性があることができる。第１のカテゴリは、例えば標準ＩＥＥＥ８０２．１ＡＳによる時間同期を含む。第２のカテゴリは、例えば標準ＩＥＥＥ８０２．１Ｑａｖ、ＩＥＥＥ８０２．１Ｑｂｕ、ＩＥＥＥ８０２．１Ｑｂｖ、ＩＥＥＥ８０２．１ＱｃｈおよびＩＥＥＥ８０２．１Ｑｃｒのうちの少なくとも１つによる、低く境界付けされたレイテンシを含むことができる。第３のカテゴリは、例えば標準ＩＥＥＥ８０２．１ＣＢ、ＩＥＥＥ８０２．１Ｑｃａ、およびＩＥＥＥ８０２．１Ｑｃｉのうちの少なくとも１つによる、超高信頼性を含むことができる。第４のカテゴリは、例えば標準ＩＥＥＥ８０２．１Ｑａｔ、ＩＥＥＥ８０２．１Ｑｃｃ、ＩＥＥＥ８０２．１Ｑｃｐ、およびＩＥＥＥ８０２．１ＣＳのうちの少なくとも１つによる、ネットワーク設定および管理を含む。
ＲＡＮを含むＴＳＮネットワークの設定および／または管理は、様々なやり方で、例えば標準ＩＥＥＥ８０２．１Ｑｃｃで規定されるような集中型または分散型のセットアップで実装することが可能である。様々な設定モデルの例を、図１３８、図１３９および図１４０を参照して説明する。
図１３８は、図１３５、図１３６、および図１３７に図示される方法をそれぞれ実行するように設定することができるデバイス１００、２００、および３００の実施形態を含む通信システム７００の第１の例のブロック図を概略的に図示している。通信システム７００は、ＲＡＮ７１０およびＣＮ７３０を含む。ＲＡＮ７１０は、デバイス２００の少なくとも１つの実施形態を含むことができる。ＣＮ７３０は、デバイス３００の少なくとも１つの実施形態、例えばネットワークコンポーネント３００－１を含むことができる。ネットワークコンポーネント３００－１は、スイッチ、ブリッジまたはルータであることができる。バックホールドメイン７２０は、ＲＡＮ７１０のＲＢＳ２００同士の間、および／または少なくとも１つのＲＢＳ２００とＣＮ７３０との間にデータリンクを提供する。データリンクは、マイクロ波リンク、イーサネットリンク、および光ファイバーリンクのうちの少なくとも１つを含むことができる。
ＳＩ７１２は、ステップ４０２および５０２にしたがって、ＲＢＳ２００によってＵＥ１００にブロードキャストされる。ＲＢＳ２００は、ステップ５０２にしたがってＳＩ７１２をブロードキャストし、ネットワークコンポーネント３００－１から受信した、またはネットワークコンポーネント３００－１を通じて受信した設定メッセージ７２２－１に応じて、ステップ５０４にしたがって、ＴＳＮストリームをサポートするように設定される。
図１３８において第１の例で図示される、分散型のＴＳＮ設定用のスキームでは、ＴＳＮネットワーク用には、ＣＵＣもＣＮＣも存在しない。したがって、ステップ４０４では、ＴＳＮトーカ１００が、ＴＳＮストリームの開始についての責任を負っている。ＣＮＣが存在しないため、ネットワークコンポーネント３００－１（例えば、スイッチ、またはブリッジ）は、自分自身を設定しており、これにより例えばＩＥＥＥ８０２．１Ｑｂｖで規定されるような時間ゲートされたキューイングの使用を許可しない場合がある。分散型のＴＳＮ設定は、ＩＥＥＥ ＴＳＮ Ｔａｓｋ Ｇｒｏｕｐによる、文書ＩＥＥＥ Ｐ８０２．１Ｑｃｃ／Ｄ２．３「Ｄｒａｆｔ Ｓｔａｎｄａｒｄ ｆｏｒ Ｌｏｃａｌ ａｎｄ ｍｅｔｒｏｐｏｌｉｔａｎ ａｒｅａ ｎｅｔｗｏｒｋｓ－Ｂｒｉｄｇｅｓ ａｎｄ Ｂｒｉｄｇｅｄ Ｎｅｔｗｏｒｋｓ Ａｍｅｎｄｍｅｎｔ：Ｓｔｒｅａｍ Ｒｅｓｅｒｖａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＳＲＰ） Ｅｎｈａｎｃｅｍｅｎｔｓ ａｎｄ Ｐｅｒｆｏｒｍａｎｃｅ Ｉｍｐｒｏｖｅｍｅｎｔｓ」、例えばドラフトステータス０３－０５－２０１８と互換性があり得る、または一貫性があり得る。
通信システム７００の第２の例について図１３９に概略的に描かれている集中型ＴＳＮ設定用の第１のスキームでは、ＴＳＮトーカ１００が、ステップ４０４におけるＴＳＮストリームの初期化の責任を負っているが、ネットワークコンポーネント３００－１は、ＣＮＣ３００－２によって設定される。集中型ＴＳＮ設定は、文書ＩＥＥＥ Ｐ８０２．１Ｑｃｃ／Ｄ２．３と互換性があり得る、または一貫性があり得る。
ＳＩ７１２は、ステップ４０２および５０２にしたがって、ＲＢＳ２００によりＵＥ１００にブロードキャストされる。設定メッセージ７２２－１に代替的に、または追加的に、ＲＢＳ２００は、ステップ５０２にしたがってＳＩ７１２をブロードキャストし、ＣＮＣ３００－２から受信した、またはＣＮＣ３００－２を通じて受信した設定メッセージ７２２－２に応じて、ステップ５０４にしたがって、ＴＳＮストリームをサポートするように設定される。
通信システム７００の第３の例について図１４０に概略的に描かれている集中型ＴＳＮ設定（十分に集中型のＴＳＮ設定も）向けの第２のスキームでは、ネットワークコンポーネント３００－１は、ネットワーク設定情報およびユーザ設定情報をそれぞれ有するＣＮＣ３００－２およびＣＵＣ３００－３によって設定される。一実装形態では、ＣＵＣ３００－３は、ＴＳＮトーカ１００がＲＢＳ２００に無線接続されるとすぐにＴＳＮストリームを確立するよう、ネットワークコンポーネントを設定することができる。一実装形態に組み合わせることができる別の実装形態では、ＴＳＮトーカ１００が少なくとも１つのＴＳＮストリームの初期化に責任を負っているが、ＴＳＮトーカ１００用の少なくとも１つのＴＳＮストリームおよび／または複数のＴＳＮストリームのためのＴＳＮトーカ１００の品質要件は、ＣＵＣ３００－３によって設定される。十分に集中型のＴＳＮ設定は、文書ＩＥＥＥ Ｐ８０２．１Ｑｃｃ／Ｄ２．３と互換性があり得る、または一貫性があり得る。
ＳＩ７１２は、ステップ４０２および５０２にしたがって、ＲＢＳ２００によりＵＥ１００にブロードキャストされる。設定メッセージ７２２－１および／または設定メッセージ７２２－２に代替的に、または追加的に、ＲＢＳ２００は、ステップ５０２にしたがってＳＩ７１２をブロードキャストし、ＣＵＣ３００－３から受信した設定メッセージ７２２－３に応じて、ステップ５０４にしたがって、ＴＳＮストリームをサポートするように設定される。
任意選択的に、例えば通信システム７００についての３つの例のいずれにおいても、ＳＩ７１２は、ＲＡＮ７１０のブロードキャストチャネル上で送信される。ＳＩ７１２は、例えばユーザおよび／またはネットワーク設定情報なしに、ＴＳＮのサポートを（例えば、正確に）示す場合がある。ＵＥ１００は、ＴＳＮ特有プロトコルにより、ダウンリンク制御チャネル上でＲＢＳ２００から、および／または非アクセス階層（ＮＡＳ）プロトコルを使用してＣＮ７１０（例えば、デバイス３００－１）からユーザおよび／またはネットワーク設定情報を受信することができる。代替的に、または組み合わせて、ＳＩ７１２はユーザおよび／またはネットワーク設定情報を（少なくとも部分的に）含むことができる。
ＴＳＮトーカ（デバイス１００の実施形態として）とＴＳＮリスナ（デバイス１００のさらなる実施形態であってもよいし、そうでなくてもよい）との間のＴＳＮ通信は、ＴＳＮストリーム内で生じる。ＴＳＮストリームは、データレートならびにＴＳＮトーカおよびＴＳＮリスナで実装されるアプリケーション（ＴＳＮアプリケーション）によって与えられるレイテンシの観点から、一定の要件に基づいている。ＴＳＮ設定および管理特徴を使用して、ＴＳＮストリームをセットアップして、ネットワーク全体のＴＳＮストリームの要件を保証する。
（例えば、図１３８における第１の例による）分散型スキームでは、ＴＳＮトーカ１００およびＴＳＮリスナ１００は、ストリーム予約プロトコル（ＳＲＰ）を使用して、ＴＳＮネットワークにおいてＴＳＮトーカ１００からＴＳＮリスナ１００までの経路に沿って、すべてのＲＢＳ２００および／またはすべてのネットワークコンポーネント３００－１で（例えば、すべてのスイッチ）、少なくとも１つのＴＳＮストリームをセットアップして設定することができる。任意選択的に、いくつかのＴＳＮ特徴は、（例えば、図１３９における第２の例による）中央管理エンティティとしてＣＮＣ３００－２を必要とする。ＣＮＣ３００－２は、例えば、Ｎｅｔｗｏｒｋ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（Ｎｅｔｃｏｎｆ）および／または「Ｙｅｔ Ａｎｏｔｈｅｒ Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ」（ＹＡＮＧ）モデルを使用して、ＴＳＮストリームごとにネットワーク内でＲＢＳ２００および／またはネットワークコンポーネント３００－１（例えば、スイッチ）を設定する。これは、ＴＳＮネットワークにおいて確定的レイテンシでデータトランスポートを可能にする、ＩＥＥＥ８０２．１Ｑｂｖで規定されるような時間ゲートされたキューイングの使用を可能にもする。各ＲＢＳ２００および／または各ネットワークコンポーネント３００－１（例えば、スイッチ）で時間ゲートされたキューイングを用いて、優先度の高いパケットがゲートが開かれるようスケジュールされた時間内にイングレスポートに到達する場合、そのパケットを最小レイテンシおよびジッタでＲＢＳ２００またはネットワークコンポーネント３００－１を通過させる精密なスケジュールにしたがって、キューは開く、または閉じる。（例えば、図１４０における第３の例による）十分に集中型のスキームでは、通信システム７００は、ＴＳＮリスナ１００および／またはＴＳＮトーカ１００用の接触ポイントとしてＣＵＣ３００－３を含む。ＣＵＣ３００－３は、ストリーム要件および／またはエンドポイント能力を、ＴＳＮリスナ１００および／またはＴＳＮトーカ１００から収集する。ＣＵＣ３００－３は、ＣＮＣ３００－２と、直接通信することができる。ＴＳＮ設定は、標準ＩＥＥＥ８０２．１Ｑｃｃで詳細に説明される通りに実装することができる。
図１４１は、デバイス１００、２００、および３００の実施形態を含む、通信システム７００の第４の例の機能ブロック図を示している。第４の例は、第１、第２、および／または第３の例で説明した特徴のいずれかをさらに含むこともでき、同じ参照符号は互換可能、または等価な特徴を指している。（例えば、ＲＡＮ７１０およびＣＮ７３０を含む）５Ｇネットワークと、ＴＳＮネットワークアーキテクチャ（例えば、ＣＮＣ３００－２およびＣＵＣ３００－３）との任意選択的なインターワーキングは、例えば図１４１で図示されるように、それぞれＣＮＣ３００－２およびＣＵＣ３００－３からの制御メッセージ７２２－２および７２２－３のうちの少なくとも１つに基づくことができる。制御メッセージ７２２－２および７２２－３のうちの少なくとも１つは、５Ｇネットワークの制御プレーンを使用して、（ＣＮ７３０では）ＡＭＦ３００－４および／または（ＲＡＮ７１０では）ＲＢＳ２００に転送される場合がある。代替的に、または追加で、ＣＮ７３０、例えばＡＭＦ３００－４は、ＣＮＣ３００－２およびＣＵＣ３００－３のうちの少なくとも１つを実装することができる。
技法は、例えば３ＧＰＰによって規定されるように５Ｇネットワークを使用して、ＴＳＮリスナ１００およびＴＳＮトーカ１００をＴＳＮネットワークに無線で接続できるようにする。３ＧＰＰによって規定されるような５Ｇ標準は、特に（例えば、５Ｇ ＮＲを提供する）ＲＡＮに対する複数の特徴により、工場のユースケースに対処して、エボルブドＵＭＴＳ無線アクセスネットワーク（Ｅ－ＵＴＲＡＮ、すなわち４Ｇ ＬＴＥの無線アクセス技術）と比較すると、より信頼できるようにして、送信レイテンシを低減する。
５Ｇネットワークは、ＵＥ１００、ｇＮＢ２００としてインスタンス化されるＲＡＮ７３０、およびコアネットワーク（５Ｇ ＣＮ）内のノード３００－４を含む。５Ｇネットワークのアーキテクチャの例を、図１４１の左側に図示する。ＴＳＮネットワークのアーキテクチャの例を、図１４１の右側に図示する。
５ＧネットワークおよびＴＳＮネットワークの両方の技術は、ネットワーク管理および／または設定のために自身の方法を規定している。通信確定論を達成するための様々なメカニズムが、エンドツーエンドの確定的なネットワーキングを可能にしてＴＳＮストリームをサポートするために、例えば産業用ネットワーク向けに、構成される。来る３ＧＰＰリリース１６での研究項目が、例えば工場自動化ユースケース用にＴＳＮをサポートするために、３ＧＰＰ文書ＲＰ－１８１４７９で開始されている。
ここで、ＲＡＮ７１０（ひいては５Ｇネットワーク）に接続された無線デバイスであるＵＥ１００は、５Ｇエンドポイントと称される場合もある。ＴＳＮネットワーク（また、ＴＳＮドメイン）に接続されるデバイスは、ＴＳＮエンドポイントと称される場合もある。
図１４１に示されているにも関わらず、ＵＥ１００が単一のエンドポイントに接続されず、少なくとも１つのＴＳＮブリッジおよび少なくとも１つのエンドポイントを含むＴＳＮネットワークに接続される可能性もある。この時、ＵＥ１００は、ＴＳＮ－５Ｇゲートウェイの一部である。
５Ｇネットワークの制御プレーンは、ネットワークリポジトリ機能（ＮＲＦ）、ＡＭＦ３００－４、セッション管理機能（ＳＭＦ）、ネットワーク公開機能（ＮＥＦ）、ポリシ制御機能（ＰＣＦ）、および統合データ管理（ＵＤＭ）のうちの少なくとも１つを含むことができる。
５Ｇネットワークのデータプレーンは、ユーザプレーン機能（ＵＰＦ）、ＲＢＳ２００の少なくとも１つの実施形態、および／またはＵＥ１００の少なくとも１つの実施形態を含む。
ＴＳＮリスナ１００２は、ＵＥ１００によって（例えば、アプリケーションとして）具体化され得る、またはＵＥ１００で実施され得る。ＵＥ１００は、図１４１に示される通信システム７００の第４の例におけるＴＳＮリスナ１００２として動作する、またはそのようなＴＳＮリスナ１００２によって使用されるが、ＵＥ１００は、代替的または追加的に、あらゆる例においてＴＳＮトーカとして動作してもよい。任意選択的に、ＴＳＮトーカ１００４は、同一または別のＲＢＳ２００を通じて、通信システム７００に接続される別のＵＥ１００によって具体化される。
方法６００のステップ６０４は、以下の変形例のうちの少なくとも１つにしたがって（例えば、図１３８～図１４１の通信システム７００の第４の例のいずれかのコンテキストにおいて）実装することができる。第１の変形例では、ＣＮＣ３００－２は、設定メッセージ７２２－２を送ることにより、ｇＮＢ２００を設定する。第２の変形例では、ＣＵＣ３００－３は、設定メッセージ７２２－３をＡＭＦ３００－４に送り、それによってｇＮＢ２００が設定される。例えば、ＡＭＦ３００－４は、設定メッセージ７２２－３をｇＮＢ２００に転送する、または設定メッセージ７２２－４を設定メッセージ７２２－３から導出する。第３の変形例（図示せず）では、ＣＵＣ３００－３は設定メッセージ７２２－３をｇＮＢ２００に送る。第４の変形例（図示せず）では、ＣＮＣ３００－２は設定メッセージ７２２－２をＡＭＦ３００－４に送る。任意選択的に、例えば変形例のいずれかにおいて、ＡＭＦ３００－４は、ＣＮＣ３００－２およびＣＵＣ３００－３のうちの少なくとも１つを実装する。
代替的に、または追加で、ＣＮＣ３００－２は、設定メッセージ７２２－２をネットワークコンポーネント３００－１（例えば、スイッチまたはルータ）に送り、それによってｇＮＢ２００を設定する。例えば、ネットワークコンポーネント３００－１は、設定メッセージ７２２－２をｇＮＢ２００に転送する、または設定メッセージ７２２－１を設定メッセージ７２２－２から導出する。
本明細書では、明瞭さと正確性のために製造および工場自動化のコンテキストにおける実施形態を用いて技法を説明するが、技法は自動車通信および家庭向け自動化に向けてさらに適用可能な場合がある。
図１４２は、デバイス１００（例えば、ＴＳＮトーカとしてのＵＥ１００、および／またはＴＳＮリスナとしてのＵＥ１００）の例示的な実施形態、およびデバイス３００（すなわち、３００－１、３００－２、および３００－３）の例示的な実施形態を伴うＴＳＮストリーム設定のためのシグナリング図１１００を示している。デバイス１００および３００のこれら複数の実施形態は、組み合わせて示されて説明されるが、あらゆるサブ組合せが実現されてもよい。例えば、ネットワークコンポーネント３００－１、ＣＮＣ３００－２、およびＣＵＣ３００－３のうちの１つだけが、デバイス３００を具体化する場合がある。代替的に、または追加で、ＴＳＮトーカおよびＴＳＮリスナのうちの１つだけが、デバイス１００の実施形態である場合がある。
（例えば、シグナリング図１１００にしたがう）ＴＳＮストリーム設定のためのステップは、ＵＥ１００がステップ４０２で受信したＳＩに基づいてＲＢＳ２００（簡略のため図１４１では示さず）にアクセス（例えば、無線接続および／またはアタッチ）することを決定した後に、実施することができる。ステップ４０４は、ＴＳＮストリーム設定のためのステップのうちの少なくとも１つを開始することができる。
ＴＳＮトーカまたはＴＳＮリスナを実装する各ＵＥ１００は、ＲＢＳ２００の実施形態を通じて、ネットワークコンポーネント３００－１、ＣＮＣ３００－２、およびＣＵＣ３００－３のうちの少なくとも１つに無線接続される。ＵＥ１００は、同じＲＢＳ２００または異なるＲＢＳ２００を通じて、無線接続されてもよい。ＴＳＮストリーム設定は、ＩＥＥＥ８０２．１Ｑｃｃと互換性があり得る、または一貫性があり得る。
十分に集中型の設定スキームによるＴＳＮストリーム設定（つまり、ＴＳＮネットワーク内で少なくとも１つのＴＳＮストリームをセットアップすること）は、以下のステップのうちの少なくとも１つを含む。
第１のステップ１１０２では、ＣＵＣ３００－３は、例えば、時間センシティブなストリーム（すなわち、ＴＳＮストリーム）を交換することになっているデバイスを指定する、例えば、産業用アプリケーションまたはエンジニアリングツール（例えば、プログラム可能論理コントローラ（ＰＬＣ））からの入力を得ることができる。ＰＬＣは、組み立てラインもしくはロボティックデバイスなどの製造プロセス、または高信頼制御および／もしくはプログラミングとプロセス障害診断の容易性を必要とするあらゆるアクティビティを制御するように適合することができる。
第２のステップ１１０４では、ＣＵＣ３００－２は、ユーザトラフィックの期間および／または間隔ならびにペイロードサイズを含む、エンドステーションおよびＴＳＮネットワーク内のアプリケーションの能力を読み取る。
第３のステップ１１０６では、上述の情報に基づいて、ＣＵＣ３００－３は、各ＴＳＮストリーム用の識別子としてのストリームＩＤ、ストリームランク、およびＵｓｅｒｔｏＮｅｔｗｏｒｋ要件のうちの少なくとも１つを作成する。
第４のステップ１１０８では、ＣＮＣ３００－２は、例えば、リンクレイヤ発見プロトコル（ＬＬＤＰ）およびあらゆるネットワーク管理プロトコルを使用して、物理的なネットワークトポロジを発見する。
第５のステップ１１１０では、ＣＮＣ３００－２は、ネットワーク管理プロトコルを使用して、ＴＳＮネットワーク内のブリッジ（例えば、ＩＥＥＥ８０２．１Ｑ、８０２．１ＡＳ、８０２．１ＣＢ）のＴＳＮ能力を読み取る。
第６のステップ１１１２では、ＣＵＣ３００－３は、１つのＴＳＮトーカ１００から１つのＴＳＮリスナ１００に向けたＴＳＮストリームのために、ブリッジ３００－１においてネットワークリソースを設定するために、少なくとも１つのＴＳＮストリームを設定するようジョイン要求を開始する。
第７のステップでは、ＴＳＮトーカ１００およびＴＳＮリスナ１００のグループ（すなわち、ＴＳＮストリームを指定する要素のグループ）が、例えば標準ＩＥＥＥ８０２．１Ｑｃｃ、条項４６．２．２に指定される通りに、ＣＵＣ３００－３によって作成される。
第８のステップ１１１４では、ＣＮＣ３００－２は、ＴＳＮドメインを設定し、物理的なトポロジをチェックし、時間センシティブなストリームがネットワーク内のブリッジによってサポートされるかどうかをチェックし、ストリームの経路およびスケジュールの計算を実施する。
第９のステップ１１１６では、ＣＮＣ３００－２は、ＴＳＮネットワーク内の経路に沿ってブリッジ内のＴＳＮ特徴を設定する。
第１０のステップ１１１８では、ＣＮＣ３００－２は、少なくとも１つのＴＳＮストリームの結果のリソース割り振りのステータス（例えば、成功または失敗）をＣＵＣ３００－３へ返す。
第１１のステップ１１２０では、ＣＵＣ３００－３は、エンドステーションをさらに設定して（この情報交換に使用されるプロトコルは、ＩＥＥＥ８０２．１Ｑｃｃ仕様の範囲外である可能性がある）、最初にＴＳＮリスナ１００とＴＳＮトーカ１００との間で規定された通りにユーザプレーントラフィック交換を開始させる。
ＴＳＮネットワークでは、ストリームＩＤは、ストリーム設定を一意に識別するために使用される。ストリームＩＤは、ＴＳＮリソースをＴＳＮトーカのＴＳＮストリームに割り振るために使用される。ストリームＩＤは、ＭａｃＡｄｄｒｅｓｓおよびＵｎｉｑｕｅＩＤの２つのタプルを含む。ＭａｃＡｄｄｒｅｓｓは、ＴＳＮトーカ１００に関連付けられる。ＵｎｉｑｕｅＩＤは、同じＭａｃＡｄｄｒｅｓｓで識別されるエンドステーション内で複数のストリーム同士を区別する。
技法のあらゆる実施形態および実装形態は、１つまたは複数のＳＩＢにおいて専用の情報要素内のＳＩ７１２を符号化することができる。ステップ４０２および５０２により、ＵＥ１００は、ネットワークのＲＢＳ２００によってサポートされるＴＳＮ特徴、および／またはどのようにサポートされるかを検出することが可能である。ＵＥ１００は、ＵＥ１００がネットワークにアタッチする前にＳＩ７１２を受信し、まずリッスンすることによりＳＩ７１２を含むＳＩＢメッセージをチェックすることができる。受信されたＳＩ７１２は、ＵＥ１００がサービングしているＴＳＮアプリケーション１００２または１００４に転送される場合があり、および／またはＵＥ１００はＳＩ７１２を使用して５Ｇネットワークへの接続をセットアップする。
ＲＢＳ２００のあらゆる実施形態は、例えば具体的にはＲＢＳ２００である５ＧネットワークによってサポートされるＴＳＮ特徴および／またはＴＳＮ設定詳細をＵＥ１００に示すために、１つまたは複数のＳＩＢおよび／またはＳＩＢ中の情報要素を含むことにより、技法を実装することができる。
ＵＥ１００のあらゆる実施形態は、１つまたは複数のＳＩＢおよび／またはＳＩＢに含まれる情報要素を読み取ることによって、ステップ４０２を実装することができる。任意選択的に、サポートされるＴＳＮ特徴および／またはＴＳＮ設定に関して含まれる情報は、それがサービングしているＴＳＮアプリケーションに転送される。条件的に、つまりＳＩ７１２でサポートされるとして示される特徴に応じて、ＲＢＳ（例えば、５Ｇネットワーク）への接続を確立するために情報が使用される。
ステップ４０２および５０２におけるＳＩ７１２のＳＩＢブロック構造の（例えば、拡大可能な）例を、Ａｂｓｔｒａｃｔ Ｓｙｎｔａｘ Ｎｏｔａｔｉｏｎ Ｏｎｅ（ＡＳＮ．１）を用いて、以下で概説する。同一の情報が、方法６００の設定メッセージ７２２にも含まれる場合がある。
Figure 0007241899000022
さらには、ＳＩＢブロックは、将来的に例えば予約フィールドを規定されるよう導入することによって、ＴＳＮ特徴の将来的なバージョンに適合される可能性がある。
エンドツーエンドの時間同期のために（例えば、絶対時間参照のプロビジョニング）、実装形態の複数の方法が可能である。ＳＩ７１２は、時間同期がＲＡＮ（例えば、５Ｇネットワーク）によってどのように扱われるかについての情報を含むことができる。
「ＦＲＥＲ」パラメータは、５Ｇネットワークによってサポートされる冗長性特徴を参照する。ネットワークが冗長性をサポートしない場合、例えば冗長プロトコルデータユニット（ＰＤＵ）セッションを確立する必要はない。
ＴＳＮ設定は、ＴＳＮネットワークおよび／またはサポートされる特定のＴＳＮ設定スキームにおける、ＣＵＣ３００－３および／またはＣＮＣ３００－２の存在を含むことができる。
「Ｍａｘ．Ｌａｔｅｎｃｙ ａｄｄｅｄ ｂｙ ５Ｇ ｎｅｔｗｏｒｋ」パラメータは、５Ｇネットワークによってサポートすることができるレイテンシおよび／または信頼性の点で、ＱｏＳレベルをＵＥ１００にシグナリングするために使用することができる。このパラメータを表現するフィールドは、十分な信頼性で保証することができるレイテンシ値（例えば、ミリ秒単位で）または分類値（例えば、非リアルタイム、リアルタイム、ハードなリアルタイムなど）を含むことができる。値は、所定のインデックス値によって示すことができる。この情報は、接続確立の前に、ＲＢＳ２００（または５Ｇネットワーク）への接続が、ＴＳＮアプリケーション１００２または１００４の要件をサポートできるか否かを知るために、ＵＥ１００（またはＵＥ１００の後ろのＴＳＮネットワークのエンドポイント１００２または１００４）によって使用される場合がある。
ＲＢＳ２００（例えば、ｇＮＢ）は、現在のセル負荷および／または他のメトリックを、そのフィールドの計算にさらに含める場合がある。任意選択的に、ＳＩ７１２は、ＲＢＳ（例えば、５Ｇネットワーク）によって保証することができるサービス品質（ＱｏＳ）を参照するトラフィックシェイパサポートを示す。例えば、ＳＩ７１２は、シェイパがクレジット（例えば、時間およびＵＥ当たりのデータ量）に基づいているのか、ＴＳＮ用の時間認識シェイパ（ＴＡＳ）に基づいているのか示している場合がある。
図１４３は、デバイス１００、２００、および３００の実施形態によってそれぞれ実施される方法４００、５００、および６００の実装形態から得られるシグナリング図１２００を示している。より具体的には、技法は、ＵＥ１００の実施形態が、１つまたは複数のＳＩＢに含まれるＳＩ７１２上のネットワークによってサポートされるＴＳＮ特徴を認識できるようになることを可能にする。ＴＳＮストリーム設定のためのシグナリング図１２００（および対応するフローチャート）は十分に集中型の設定スキームを使用するが（例えば、図１４０で示される通り）、技法は、他の設定スキームに容易に適用可能である（例えば、図１３８、または図１３９に示される通り）。
方法４００、５００、および６００の実装形態は、ＵＥ１００がネットワークによって、および／または具体的にはＲＢＳ２００によって、ＳＩ７１２を含む１つまたは複数のＳＩＢ上でサポートされるＴＳＮ特徴を認識できるようになることを可能にする。
ステップ６０４では、５Ｇコア機能（例えば、ＡＭＦ３００－４）は、特定のＲＢＳ２００（例えば、ｇＮＢ）に設定メッセージ７２２を送ることによって、（例えば、上の非網羅的なリストにしたがって）どのＴＳＮ特徴がサポートされるか、または可能にされることになっているか（例えば、すべてのｇＮＢのうちサブセットだけがＴＳＮをサポートすることができる）、およびこれらのＴＳＮ特徴がどのようにサポートされるかを示す。
設定メッセージ７２２（例えば、上の実装形態７２２－１から７２２－４のいずれか）の受信に応じて、ＲＢＳ２００（例えば、ｇＮＢ）は、ＳＩ７１２（例えば、上で概説したＳＩＢブロック情報）を生成し、例えばステップ５０２のＤＬ－ＳＣＨ上で、ＳＩ７１２のブロードキャストを開始する。
ＵＥ１００は、ステップ４０２において、ＳＩＢ内のＳＩ７１２を受信する、および／または読み取る。任意選択的に、ＵＥ１００は、ＳＩ７１２内の情報の少なくとも一部、例えば、ＲＢＳ２００によってサポートされるＴＳＮ特徴のリストを、ＴＳＮアプリケーション１００２または１００４に伝送する。ＴＳＮ特徴のサポートされるリストが、ステップ４０４における条件性または選択性の例として十分である場合、ＴＳＮアプリケーション１００２または１００４は、ＴＳＮ接続をＵＥ１００に向けて要求する場合がある。
ステップ４０４でＴＳＮストリームを開始するために、ＵＥ１００は、まだＲＲＣ接続モードになっていない場合はＲＲＣ接続モードに入って、Ｅｔｈｅｒｎｅｔ ｔｙｐｅであり得るＰＤＵセッションを要求する。ＵＥは、ＴＳＮ特徴が必要とされるＮＡＳシグナリングにより情報をさらに提供することができる。
ＴＳＮコントローラ（例えば、ＣＮＣ３００－２）は、ＣＮ７３０から確認を受信し、経路計算および時間スケジューリングを実施する。ＴＳＮストリーム通信が開始され、ＲＢＳ２００は、ステップ５０４にしたがってＴＳＮストリームをサポートする。
あらゆる実施形態において、ＵＥ１００は、ＴＳＮアプリケーションが一定のＴＳＮ特徴を必要とし、ステップ４０４における条件性または選択性の例として、ＵＥ１００がＳＩＢにおいて、これらの特徴のうちの１つまたは複数がサポートされるというブロードキャスト４０２を受信しない場合、ステップ４０４におけるＲＲＣ接続セットアップを要求することを延期または控える場合がある。
同じまたは別の実施形態では、ＵＥ１００は、複数のＲＢＳ２００（例えば、ｇＮＢ）のＳＩ７１２（つまり、１つまたは複数のＳＩＢに含まれるＴＳＮ情報）を読み取り、ＵＥ１００のＴＳＮ要件を最良に遂行するＲＢＳ２００を選択する。すべてのＲＢＳ２００が要件を遂行する場合、ＵＥ１００は選択規則にしたがって作用し、例えば、最低レイテンシを示すＲＢＳ２００を選択する。
あらゆる実施形態において、ＵＥ１００は、ステップ４０２で受信したＳＩ７１２を記憶することができる。技法は、ステップ４０２を含め、最大ステップ４０２まで、説明したように実装することができる。ＴＳＮアプリケーション１００２または１００４がＴＳＮ通信（すなわち、１つまたは複数のＴＳＮストリーム）を要求する場合、ＵＥ１００は記憶されたＳＩ７１２を使用して、少なくとも１つのＴＳＮストリームをサポートされる方法でセットアップするか、またはサポートされない場合はＴＳＮ要求を拒否するかのいずれかである。
ＵＥ１００は、例えばＴＳＮ送信のために到来するパケットのパケットフィルタリングを初期化するためにＳＩＢからのＳＩ７１２をさらに使用することができる。さらには、受信したＳＩ７１２は、５ＧネットワークとのデフォルトＰＤＵセッションを確立するために使用することができる。
ＴＳＮサポート検出とヘッダ圧縮技法との組合せ
再度になるが、上で示したように、本明細書で説明される様々な技法は、互いに組み合わせて、レイテンシ、信頼性などに関する優位性を与えることができる。例えば、有利である１つの特定の組合せは、ＴＳＮのサポートを検出するための上述の技法とＴＳＮフレームのヘッダを圧縮することのために説明した技法との組合せである。
したがって、例えば、図１３５に図示される方法は、図１３３で示される方法と組み合わせることが可能であり、結果として、方法は、無線通信ネットワークに関連付けられる無線デバイスによって、外部データネットワークにおけるデータストリームに関連付けられるデータパケットのトランスポートのために実施される。この方法は、図１３５のブロック４０２で示されるように、無線アクセスネットワーク（ＲＡＮ）の無線基地局（ＲＢＳ）からシステム情報（ＳＩ）を受信するステップであって、ＳＩはＲＢＳを通じて、時間センシティブなネットワーキング（ＴＳＮ）のサポートを示す、受信するステップ、ならびに図１３５のブロック４０４で示されるように、ＲＢＳを通じて外部データネットワークとの少なくとも１つのＴＳＮストリームを確立するステップを含む。方法は、図１３３のブロックＸＸ１０２で示されるように、ＴＳＮストリームの設定情報を取得するステップであって、設定情報は、静的のままであるＴＳＮストリームに関連付けられるデータパケットのヘッダ内の１つまたは複数のフィールドの個々の値を示す、取得するステップと、図１３３のブロックＸＸ１０４で示されるように、ＲＢＳからＴＳＮストリームに関連付けられるデータパケットを受信するステップとをさらに含む。方法は、図１３３のブロックＸＸ１０６で示されるように、１つまたは複数のフィールドをデータパケットに追加して解凍されたデータパケットを生成するステップをさらになお含む。
いくつかの実施形態では、ＳＩは、１つまたは複数のシステム情報ブロック（ＳＩＢ）に含まれる。いくつかの実施形態では、設定情報を取得するステップは、無線通信ネットワークのネットワークノードから設定情報を受信することを含む。データパケットは、ＴＳＮストリーム用の識別子を含む場合があり、いくつかの実施形態では、この識別子はコアネットワークノードによって追加される。
いくつかの実施形態では、圧縮されたデータパケットは、プロトコルデータユニット（ＰＤＵ）セッションの一部またはサービス品質（ＱｏＳ）フローとして受信される。これらのいくつかの実施形態の一部では、ＴＳＮストリーム用の識別子は、ＰＤＵセッションまたはＱｏＳフロー内で一意である。
いくつかの実施形態では、設定情報は、非アクセス階層（ＮＡＳ）シグナリングを使用して無線デバイスに送信される。設定情報は、ＴＳＮストリーム用の識別子を含むことができる。
いくつかの実施形態では、方法は、ＴＳＮストリームの更新された設定情報を取得することであって、更新された設定情報は、静的なままであるＴＳＮストリームに関連付けられるデータパケットのヘッダ内の１つまたは複数のフィールドの個々の更新された値のインジケーションを含んでいる、取得することをさらに含むことができる。これらの実施形態では、方法は、１つまたは複数のフィールドの個々の更新された値をＲＢＳから受信したデータパケットに追加するために更新された設定情報を利用するステップをさらに含む場合がある。これらの実施形態の一部では、更新された設定情報は、個々の更新された値が適用されるＴＳＮストリームに関連付けられるデータパケットを識別するシーケンス番号のインジケーションをさらに含む。
いくつかの実施形態は、図１３４に示される方法のステップをさらに含むことができる。そのような実施形態は、図１３４のブロックＸＸ２０４で示されるように、ＴＳＮストリームに関連付けられるデータパケットを取得するステップ、ならびに図１３４のブロックＸＸ２０６に示されるように、圧縮されたデータパケットを生成するために、データパケットから１つまたは複数のフィールドを除去するステップを含むことができる。方法は、図１３４のブロックＸＸ２０６で示されるように、ＲＢＳへ送信を介して外部データネットワーク上での圧縮されたデータパケットの送信を開始することをさらに含むことができる。
設定情報を取得するステップは、いくつかの実施形態では無線通信ネットワークのコアネットワークノードから設定情報を受信すること、または他の実施形態では、外部データネットワークから設定情報を受信することを含むことができる。いくつかの実施形態では、方法は、コアネットワークノードが圧縮されたデータパケットを、外部データネットワーク上でのその送信に先立って解凍できるように、静的のままであるＴＳＮストリームに関連付けられるデータパケットのヘッダ内の１つまたは複数のフィールドの個々の値のインジケーションの、無線通信ネットワークのコアネットワークノードへの送信を開始することをさらに含む。
これらの実施形態の一部では、データパケットは、ユーザデータを含み、圧縮されたデータパケットの送信を外部データネットワーク上で開始するステップは、外部データネットワーク上でユーザデータをホストコンピュータへ転送することを含む。
ＴＳＮサポート検出とリソーススケジューリング技法との組合せ
再度になるが、上で示したように、本明細書で説明される様々な技法は、互いに組み合わせて、レイテンシ、信頼性などに関する優位性を与えることができる。例えば、有利である１つの特定の組合せは、ＴＳＮのサポートを検出するための上述の技法とＴＳＮフレームのヘッダを圧縮することのために説明した技法との組合せである。
したがって、例えば、図１３５に図示される方法は、図１１９で示される方法と組み合わせることが可能であり、結果として、方法は、外部ネットワークに関連付けられる送信スケジュールにしたがってＲＡＮ内でリソースをスケジューリングするために、無線アクセスネットワーク（ＲＡＮ）との通信用に設定された無線デバイスによって実施される。この方法は、図１３５のブロック４０２で示されるように、無線アクセスネットワーク（ＲＡＮ）の無線基地局（ＲＢＳ）からシステム情報（ＳＩ）を受信するステップであって、ＳＩはＲＢＳを通じて、時間センシティブなネットワーキング（ＴＳＮ）のサポートを示す、受信するステップ、ならびに図１３５のブロック４０４で示されるように、ＲＢＳを通じて外部データネットワークとの少なくとも１つのＴＳＮストリームを確立するステップとを含む。方法は、図１１９のブロック１４１０に示されるように、外部ネットワークから、ＴＳＮストリームに関連付けられる送信スケジュールを受信するステップと、図１１９のブロック１４２０に示されるように、ＲＢＳに関連付けられるネットワークに、無線デバイスとＲＡＮとの間のＴＳＮストリームの通信用に無線リソースを割り当てるための要求を送るステップであって、要求は送信スケジュールに関する情報をさらに含む、送るステップとをさらに含む。図１１９のブロック１４３０で示されるように、方法は、ネットワークから、無線リソースがＴＳＮストリームに関連付けられる送信スケジュールを満足するよう割り当てられる可能性があるかどうかを示す応答を受信することをさらに含むことができる。
いくつかの実施形態では、送信スケジュールは、サイクル時間およびＴＳＮストリームを含む１つまたは複数のトラフィッククラスについてのゲート制御リストを含む。いくつかの実施形態では、無線リソースがデータストリームの送信スケジュールを満足するよう割り当てることができないことをネットワークからの応答が示す場合、応答は、無線リソースを割り当てることができる１つまたは複数のさらなる時間ウィンドウのインジケーションをさらに含む。いくつかの実施形態では、方法は、ネットワークからの応答に基づいて、外部ネットワークに、送信スケジュールが満足され得るかどうかのインジケーションを送ることをさらに含む。これらの実施形態の一部では、応答が、１つまたは複数のさらなる時間ウィンドウのインジケーションを含む場合、外部ネットワークに送られたインジケーションは、１つまたは複数のさらなる時間ウィンドウに関連する情報をさらに含む。
いくつかの実施形態では、ネットワークは、５Ｇコアネットワーク（５ＧＣ）を含み、要求は５ＧＣのアクセス管理機能（ＡＭＦ）に送られ、応答はＡＭＦから受信される。
ＴＳＮ送信をサポートするための、５Ｇにおける複数の時間ドメインのサポート
５ＧとＴＳＮとのインターワーキングを、図１４４に図示する。両方の技術が、ネットワーク管理および設定の自身の方法、および産業用ネットワーク向けに、何からの形でエンドツーエンドの確定的なネットワーキングを可能にするよう構成されなければならない通信確定論を達成するための様々なメカニズムを規定している。以下では、５Ｇネットワークに接続されるデバイスを、５Ｇエンドポイントと称する。ＴＳＮドメインに接続されるデバイスを、ＴＳＮエンドポイントと称する。
図１４４に示されているにも関わらず、ＵＥが単一のエンドポイントに接続されず、代わりに少なくとも１つのＴＳＮブリッジおよび少なくとも１つのエンドポイントを含むＴＳＮネットワークに接続される可能性もある。この時、ＵＥは、ＴＳＮ－５Ｇゲートウェイの一部である。
図１４４のＵＰＦは、高精度時間プロトコル（ＰＴＰ）をサポートすることを想定されており、したがって、ＵＤＰ／ＩＰを使用して（例えば、ＩＥＥＥ１５８８－２００８にしたがって）トランスポートされるＰＴＰメッセージを使用してＴＳＮネットワーク内のグランドマスタクロックに同期できることに留意されたい。
この後にＵＰＦが（グランドマスタクロックから導出した）クロック情報をｇＮＢに転送する方法は、実装形態特有であると考えられる。
ｇＮＢは、必要とされれば、複数のソース（例えば、ＧＰＳベース、グランドマスタベース）から導出したクロック情報の複数のインスタンスを、５Ｇネットワークベースの方法を使用して、ＵＥに送ることができる。
ＵＥから１つまたは複数のエンドポイントに向けて、クロック情報のさらなる分散が可能である（例えば、クロック情報を所有するＵＥは、１つまたは複数のエンドポイントに対してソースクロックとして機能することができる）。
図１４４は、イーサネットＰＤＵ処理用に２つの基本的なシナリオをサポートすることができる。第１のシナリオは、５Ｇネットワーク上で中継されるイーサネットＰＤＵである。このシナリオは、単一のＵＥが、それぞれ別個のイーサネットＭＡＣレイヤアドレスを有する複数のエンドポイントをサポートする必要がある場合を想定している（つまり、１つのＵＥが複数のイーサネットポートをサポートする）。
ＴＳＮスイッチをインターフェースするＵＰＦは、ＩＰパケットを高次レイヤのペイロードとして搬送しないイーサネットＰＤＵの受信および送信をサポートすると想定される。ＴＳＮスイッチからイーサネットＰＤＵを受信すると、ＵＰＦは、宛先ＭＡＣアドレスを特定のＩＰアドレスに関連付けるための方法を行ってから、イーサネットＰＤＵを、５Ｇネットワーク内の適当なノード（例えば、ＰＤＮ－ＧＷ）に中継する必要がある。適当な５Ｇネットワークノードは、ＩＰアドレスを使用して、特定のＵＥおよびその対応するＲＮＴＩを識別し、それによって、その後、識別されたＲＮＴＩを使用して送達用にイーサネットＰＤＵを適当なｇＮＢに転送することができる。
ｇＮＢは、イーサネットＰＤＵ送信をサポートするために適当な信頼性およびレイテンシ属性で、データ無線ベアラ（ＤＲＢ）を使用してイーサネットＰＤＵをＵＥに送る。ＵＥは、イーサネットＰＤＵを（例えば、ＰＤＣＰレイヤから）回収して、イーサネットＰＤＵを宛先ＭＡＣアドレスに関連付けられるエンドポイントに送る（つまり、１つのＵＥが、１つまたは複数のイーサネット接続のエンドポイントをサポートすることができる）。
要約すると、ＵＰＦによってＴＳＮスイッチから受信したオリジナルのイーサネットＰＤＵは、５Ｇネットワークを通じてトランスペアレントに送達される。
アップリンク方向で、５Ｇネットワークは、いつＲＮＴＩがイーサネット動作に関連付けられ、それによって、そのようなＲＮＴＩに関連付けられるアップリンクペイロード（すなわち、イーサネットＰＤＵ）をＵＰＦにルーティングできるかを決定するよう期待される。次いで、ＵＰＦは単純に、受信したイーサネットＰＤＵをＴＳＮスイッチに送る。
第２のシナリオは、５Ｇネットワーク上で終端されるイーサネットＰＤＵである。このシナリオは、単一のＵＥが単一のエンドポイントをサポートする場合を想定しており、この場合、ＵＥはイーサネットポートをサポートする必要はない。ＴＳＮスイッチをインターフェースするＵＰＦは、ＩＰパケットを高次レイヤのペイロードとして搬送するイーサネットＰＤＵの受信および送信をサポートすると想定される。
ＴＳＮスイッチからイーサネットＰＤＵを受信すると、ＵＰＦは、ＩＰパケットをイーサネットＰＤＵから抽出して、それをさらなるルーティングのために適当な５Ｇネットワークノードに送る。５Ｇネットワークは、宛先ＩＰアドレスを使用して、特定のＵＥおよびその対応するＲＮＴＩを識別し、それによって、識別されたＲＮＴＩを使用して送達用にＩＰパケットを適当なｇＮＢに転送することができる。
ｇＮＢは、イーサネットＰＤＵ送信をサポートするために適当な信頼性およびレイテンシ属性で、データ無線ベアラ（ＤＲＢ）を使用してＩＰパケットをＵＥに送る（つまり、イーサネットＰＤＵはＵＰＦで終端しているが、５Ｇネットワークは、イーサネットＰＤＵによって搬送されるＩＰパケットを送達する時、イーサネットライクなＱｏＳ属性をサポートしなければならない）。ＵＥは、ＩＰパケットを（例えば、ＰＤＣＰレイヤから）回収し、ＩＰパケットをＩＰレイヤのアプリケーションに送る。
要約すると、イーサネットＰＤＵがＵＰＦによってＴＳＮスイッチから受信されるとイーサネットプロトコルレイヤは終端されるが、そのＩＰパケットのペイロードは５Ｇネットワークを通じてトランスペアレントに送達される。
アップリンク方向で、５Ｇネットワークは、いつＲＮＴＩがイーサネット動作に関連付けられ、それによって、そのようなＲＮＴＩに関連付けられるアップリンクペイロード（すなわち、ＩＰパケット）がＵＰＦにルーティングできるかを決定するよう期待される。次に、ＵＰＦは、ソースおよび宛先ＩＰアドレスを、ソースおよび宛先ＭＡＣアドレスに（例えば、ＡＲＰを使用して）マッピングすることができる方法を有していなければならず、それによって、ＵＰＦは、これらのＭＡＣアドレスおよびＴＳＮスイッチへの送信用のペイロードとしてのＩＰパケットを含むイーサネットＰＤＵを構築することができる。
多くのＴＳＮ特徴は、すべてのピア同士の精密な時間同期に基づいている。上で紹介したように、これは例えばＩＥＥＥ８０２．１ＡＳまたはＩＥＥＥ８０２．１ＡＳ－ｒｅｖを使用して達成される。したがって、ＴＳＮネットワーク内では、サブミリ秒の誤差で同期を達成することが可能である。このレベルの正確性を達成するために、例えばパケットのタイムスタンピング用に、ハードウェアのサポートが必須である。
ネットワークでは、グランドマスタ（ＧＭ）は、マスタ－スレーブアーキテクチャにあるすべての他のノードにタイミング情報を送信するノードである。ＧＭは、選択されるグランドマスタを優位にする一定基準により、いくつか可能性のあるノードから選出することができる。
８０２．１ＡＳのＴＳＮ拡張では、主ＧＭの隣には、やはり冗長なバックアップＧＭを設定できるように規定されていた。第１のＧＭが何らかの理由で障害となった場合、ＴＳＮドメイン内のデバイスは、第２のＧＭに同期することができる。冗長なＧＭは、ホットスタンバイ設定で動作することができる。
ＩＥＥＥ８０２．１ＡＳ－ｒｅｖに基づくＴＳＮ（汎用高精度時間プロトコル（ｇＰＴＰ）とも呼ばれる）では、ＴＳＮネットワークでサポートされる複数の時間ドメインが存在する。ある時間ドメインは、例えばＰＴＰエポックに基づくグローバル時間ドメインであることが可能であり、別の時間ドメインは任意のエポックのローカル時間ドメインである可能性がある。ｇＰＴＰによってサポートされるタイムスケールには２つある。
・タイムスケールＰＴＰ：エポックはＰＴＰエポック（詳細は、ＩＥＥＥ８０２．１ＡＳ－ｒｅｖセクション８．２．２参照）であり、このタイムスケールは連続的である。時間の尺度の単位は、回転周期において実現されるＳＩ秒である。
・タイムスケールＡＲＢ（ａｒｂｉｔｒａｒｙ）：この時間スケールのエポックは、ドメインスタートアップ時間であり、運用管理的な手順によってセットアップすることができる（さらなる詳細は、ＩＥＥＥ８０２．１ＡＳ－ｒｅｖセクション３．２参照）。
ＴＳＮネットワーク内のデバイスは、複数の時間ドメインに同期される可能性がある。ローカル任意時間ドメインは、ワーキングクロックとも称される。ワーキングクロックは、ＴＳＮ機能のために、産業用ネットワークで使用される。
ＴＳＮストリームをセットアップするための最初のステップのうちの１つは、ＣＮＣによって、時間センシティブなストリームを交換することになっているエンドポイント（トーカおよびリスナ）をグループ化することにより、ＴＳＮドメインを確立することである。このリストは、ＣＵＣによってＣＮＣに提供される。ＣＮＣは、これらのエンドポイントを接続するブリッジをさらに設定して、各ＴＳＮドメイン（トーカ、リスナ、およびブリッジ）が自身のワーキングクロックを有するようにする。技術的には、これは外部ポートのロール設定、メカニズムを設定することにより、ＩＥＥＥ８０２．１ＡＳ－ｒｅｖにしたがって行うことができる。
次に、産業用アプリケーションシナリオにおける複数の時間ドメインを説明する。上で紹介したように、ＴＳＮドメインは、様々なクロック（グローバルおよびワーキングクロック）と機能する。さらには、各ＴＳＮドメインのクロック同士は、必ずしも同期されず、工場ネットワークはいくつかのＴＳＮドメインを有する場合がある。したがって、工場ネットワーク全体では、様々な恐らくは重複しているデバイスのサブセットが同期される必要がある、任意の時間スケールを有するいくつかの独立的なＴＳＮドメインが存在する可能性がある。図１４５に示されるように、各ＴＳＮドメインは、それ自身のワーキングクロックを有することができる。
製造業ユースケースにおけるＴＳＮ向けの時間同期要件を満足するために、セルラネットワークはすべてのマシン（センサまたは作動装置）が同期することができる時間参照を提供することを必要とされる。
現在、３ＧＰＰ標準化において、Ｒｅｌｅａｓｅ１５のＬＴＥ無線アクセス上で時間同期を実現するための努力がみられる。
１つの可能な手法では、２つの情報要素（ＩＥ）、つまり０．２５μｓ細分性および不確定な値による時間参照がＳＩＢ１６に追加され、ＧＰＳ時間をＵＥに知らせるためのＤＬ ＲＲＣメッセージＵＥＴｉｍｅＲｅｆｅｒｅｎｃｅではＲＲＣメッセージに３つのＩＥが追加される。この手順の主な目的は、ＧＰＳベースの時間参照情報を、その情報の不正確さと共にＵＥに伝送することである。
ＬＴＥは、ＳＩＢ１６におけるタイミング情報に関連する、いくつかのシステム情報ブロック（ＳＩＢ）を規定しており、ＳＩＢ１６にはＧＰＳ時間および協定世界時（ＵＴＣ）に関する情報が含まれる。ＳＩＢは、ダウンリンク共有チャネル（ＤＬ－ＳＣＨ）上で送信される。サブフレーム中のＳＩＢの存在は、特殊なシステム情報ＲＮＴＩ（ＳＩ－ＲＮＴＩ）でマークされた対応するＰＤＣＣＨの送信によって示される。ＩＥ ＳＩＢ１６は、ＧＰＳ時間とＵＴＣに関連した情報を含む。ＵＥは、パラメータブロックを使用してＧＰＳおよびローカル時間を取得する。
これは、ＳＩＢ１６メッセージの構造である：
Figure 0007241899000023
情報要素は、表２２で規定される
Figure 0007241899000024
ＲＲＣシグナリングにおける時間参照情報メッセージは、ＧＰＳ時間をＵＥに送信するためにも使用することができる。
一定の問題が存在する。例えば、最先端のように、ＵＥは、自身が接続されるＢＳ（例えば、ｅＮＢ）によってサポートされる１つのクロックに同期されることだけが可能である。この場合の主な問題は、３ＧＰＰ無線上で時間参照を提供するために使用されるクロックは、ＴＳＮドメインに時間参照を提供するために使用されるワーキングクロック（任意のＧＭクロック）とは異なっている可能性があることである。現在、ＢＳからＵＥへの時間参照送信に使用されているクロックとは同期していないＴＳＮドメイン時間クロックを提供するそのようなメカニズムは存在しない。
やはり、別の問題は、ＵＥがＴＳＮセルラゲートウェイとして使用されている場合、無関係なクロックグランドマスタがセルラネットワークのＵＥ側に存在することがさらに可能なことである。この時、ＴＳＮアプリケーションは、動作するＴＳＮネットワーク用のＢＳではなく時間同期ソースに接続される。このシナリオではまた、現在ＵＥがこのタイミング情報をセルラネットワーク内の他のピアに伝送する方法がない。
本開示の一定の態様およびその実施形態は、これらまたは他の課題に対するソリューションを提供することができる。例えば、一定の実施形態によると、方法は、精密なセルラネットワーク同期に基づいて、ＢＳ側またはＵＥ側の両方において複数の時間ドメインの確立を可能にするよう提供される。それにより、セルラネットワークは、ＵＥに常駐するＴＳＮアプリケーション、つまりＢＳからの時間同期情報を受信することに基づいているアプリケーションに向けて、例えば２つ以上の異なる時間ドメイン（例えば、グローバルクロックとワーキングクロック）をサポートすることができる。さらには、現在の発明は、セルラネットワークにおいて、ワーキングクロックＧＭがＵＥ側に存在する場合にＵＥが時間をＢＳにシグナリングすることが可能であり、それによりＵＥが同じＴＳＮドメインに配置される他のＴＳＮ機器に接続することを必要とされる（つまり、精密なセルラネットワーク同期情報を他のＴＳＮ機器に提供する）方法を提供する。
一定の実施形態は、以下の技術上の優位性のうちの１つまたは複数を提供することができる。例えば、ある技術的優位性は、一定の実施形態により、無線での単一の精密な時間参照シグナリングに基づいて複数の時間ドメインとのエンドツーエンドの時間同期が可能となることであり得る。追加的な時間ドメインをサポートするための努力は、本明細書で提示される方法により低減される。
いくつかの実施形態では、より一般的な用語「ネットワークノード」が使用される場合があり、ＵＥおよび／または別のネットワークノードと（直接または別のノードを介して）通信する、あらゆるタイプの無線ネットワークノードまたはあらゆるネットワークノードに対応することができる。ネットワークノードの例としては、ＮｏｄｅＢ、ＭｅＮＢ、ＥＮＢ、ＭＣＧまたはＳＣＧに属するネットワークノード、基地局（ＢＳ）、ＭＳＲ ＢＳなどのマルチスタンダード無線（ＭＳＲ）の無線ノード、ｅＮｏｄｅＢ、ｇＮｏｄｅＢ、ネットワークコントローラ、無線ネットワークコントローラ（ＲＮＣ）、基地局コントローラ（ＢＳＣ）、中継器、中継器を制御するドナーノード、無線基地局（ＢＴＳ）、アクセスポイント（ＡＰ）、送信ポイント、送信ノード、ＲＲＵ、ＲＲＨ、分散アンテナシステム（ＤＡＳ）のノード、コアネットワークノード（例えば、ＭＳＣ、ＭＭＥなど）、Ｏ＆Ｍ、ＯＳＳ、ＳＯＮ、ポジショニングノード（例えば、Ｅ－ＳＭＬＣ）、ＭＤＴ、試験機器（物理ノードまたはソフトウェア）などが挙げられる。
いくつかの実施形態では、非限定的な用語であるユーザ機器（ＵＥ）または無線デバイスが使用される場合があり、セルラまたは移動体通信システムにおいて、ネットワークノードおよび／または別のＵＥと通信するあらゆるタイプの無線デバイスを称する場合がある。ＵＥの例としては、ターゲットデバイス、Ｄ２Ｄ（ｄｅｖｉｃｅ－ｔｏ－ｄｅｖｉｃｅ）ＵＥ、マシンタイプＵＥまたはマシンツーマシン（Ｍ２Ｍ）通信対応ＵＥ、ＰＤＡ、ＰＡＤ、タブレット、モバイル端末、スマートフォン、ラップトップ組込み装備（ＬＥＥ）、ラップトップ搭載機器（ＬＭＥ）、ＵＳＢドングル、ＵＥカテゴリＭ１、ＵＥカテゴリＭ２、ＰｒｏＳｅ ＵＥ、Ｖ２Ｖ ＵＥ、Ｖ２Ｘ ＵＥなどが挙げられる。
追加的に、基地局／ｇＮｏｄｅＢおよびＵＥなどの用語は、非限定的と考えられるべきであり、特に二者間の一定の階層関係を暗示するものではない。一般に、「ｇＮｏｄｅＢ」をデバイス１と考えることができ、また「ＵＥ」をデバイス２と考えることができ、これらの２つのデバイスは何らかの無線チャネル上で互いに通信する。以下では、送信機または受信機は、ｇＮＢまたはＵＥのいずれかであり得る。
一定の実施形態によると、ＵＥが、時間同期ソリューションに基づいて１つまたは複数のＴＳＮドメインワーキングクロックに同期することができる方法が提供される。さらには、ソリューションは、ＵＥ（この場合ＵＥはＴＳＮゲートウェイとして作用する）の後ろで実行するＴＳＮドメインのワーキングクロックと同期されるデバイス（セルラリンク上でＴＳＮドメインに接続される）をサポートするために拡張される。また、関連ＧＭクロックがＵＥ側にデプロイされる場合では、ＵＥはこのクロック信号を、例えば基地局（ＢＳ）などのセルラネットワークにシグナリングすることができる。セルラネットワークは、この情報をＴＳＮエンドポイントまたはそれが接続されるネットワークに転送する場合がある。
本明細書では、十分な精度でセルラネットワークにおいてＵＥをＢＳに同期させるメカニズムが存在すると想定する。ＴＳＮ特徴によって必要とされるＴＳＮのエンドツーエンドの同期（例えば時間認識のトラフィックスケジューラ）では、この誤差は１ミリ秒のオーダであり得る。普通、ＧＰＳ信号などの利用可能な信頼できるソースからの共通グローバルクロックに基づくセルラネットワークにおける同期。
本明細書では、５Ｇ同期信号の誤差は、ＴＳＮ通信に所望のワーキングクロック正確性をサポートするために十分に小さいと想定する。図１４６は、ＢＳがどのようにＵＥをセル側参照時間に同期させることができるかを図示している。
一定の実施形態によると、紹介される方法は、以下で説明され、図１４７～図１４９で示される３つのシナリオによって例証される。デバイス（Ｄｅｖ ｘ）は、ＴＳＮエンドポイントと想定され、ＧＭはＴＳＮネットワーク用のクロックＧＭとして作用するＴＳＮエンドポイントである。
具体的には、図１４７はＤｅｖｉｃｅ（Ｄｅｖ１）が、ＴＳＮドメインへのセルラリンクで接続されると想定されるシナリオを図示している。このＴＳＮドメインは、そのワーキングクロック（ＧＭ）を有することができる。セルラネットワークは、専用のＲＲＣシグナリングで、または例えばＧＰＳに基づいて高度化されたＳＩＢブロックを用いて（上セクションで説明した通り）時間参照情報をＵＥに提供している。一定の実施形態によると、Ｄｅｖ１が、セルラネットワークにより既に提供された時間参照および例えばＧＰＳに基づいて、ＴＳＮワーキングクロックに対する情報を得る方法が提案される。
図１４８は、セルラリンクで仮想コントローラ（Ｄｅｖ２）に接続されるＴＳＮドメインを想定する店舗フロアシナリオである。ここでの問題は、Ｄｅｖ２を、ＵＥを介して接続されるＴＳＮドメインのワーキングクロック（ＧＭ）と、どのように同期させることができるかである。ＵＥが、ＧＭのこのローカルワーキングクロックを、ＢＳおよびＤｅｖ２にそれぞれ通信できるようにする方法が提案される。
図１４９は、セルラリンク上で接続される２つのＴＳＮネットワークを想定する第３のシナリオを図示している。ネットワークの第１の部分はセルラネットワークのバックボーンとして考え、他の部分は店舗フロアとして想定する。ＧＭクロックは、ネットワークのバックボーン側または店舗フロア側のいずれにあってもよい。これはシナリオａ）とｂ）との一般的な組合せである。
上の３つのシナリオで例証される課題に対処するために、本発明は、実施形態として２つの方法を規定する：
方法１：共通セルラ参照タイミング信号同士のタイミングオフセットおよび偏差（例えば、ＧＰＳに基づいて）、ならびに様々な他のタイミング信号を（例えば、ＴＳＮ ＧＭのワーキングクロックなど）測定する、ＢＳにおける方法。このオフセットは、ＴＳＮドメインにマッピングすることができる。オフセットは、専用のＲＲＣシグナリング上でＵＥに送信することができるか、またはＳＩＢブロック情報要素を使用してブロードキャストすることができる（ＳＩＢ上のブロードキャストの場合では、オフセット値は、ＴＳＮドメイン識別パラメータにマッピングする必要がある）。ＵＥは、このオフセットを使用して、共通セルラ参照時間に基づいてオリジナルの時間信号を再確立する。次いで、ＵＥは、この時間をＴＳＮアプリケーションに提供することができる。図１５０は、方法１の手順を図示している。
方法２：ＵＥがセルラネットワークから受信する共通セルラ参照タイミング信号のタイミングオフセットおよび偏差（例えば、ＧＰＳに基づいて）、ならびにＵＥが異なるＴＳＮドメインからまたはその一部である単一のＴＳＮドメインから受信する様々なワーキングクロックのような様々な他のタイミング信号を測定する、ＵＥ方法である。この場合ＵＥは、ＴＳＮネットワーク（ＴＳＮクロックグランドマスタを含む）とセルラネットワークとの間でゲートウェイとして作用する。ＵＥは、例えばＲＲＣシグナリングを介して、このオフセットをＢＳに送信する。ＢＳは、このオフセットを使用して、共通セルラ参照時間に基づいてオリジナルの（つまり、ＵＥがその一部であるＴＳＮネットワークに対応する）時間信号を再確立する。次いで、ＢＳはこの追加的な時間信号を同一のＴＳＮドメインで動作しているアプリケーションに提供することができる。図１５１は、一定の実施形態による、方法２の手順を図示している。
両方の方法とも、複数の時間ドメインをサポートできるようにするために、タイミングオフセットについてセルラネットワークのもう一方と通信するための、時間オフセットの周期的なシグナリングを考慮している。
次に、方法１をより詳細に説明する。方法１の手順のベースとなる想定は、ワーキングクロックのエポックと５Ｇ時間参照とが同一であるか、またはＵＥとＢＳとの間で予め交渉されること、あるいは追加的な時間信号のエポックが任意であることである。さらには、ＵＥおよびＢＳで使用されるクロックは、時間信号をサポートするために十分な精度のものである。また、ＵＥは共通セルラ参照時間で十分にＢＳと同期される。ＵＥおよびＢＳの両方は、複数のクロック、および様々な時間信号を並行してサポートするための関連機能を備えることができる。
図１５２は、一定の実施形態による、方法１のシーケンスフローを図示している。方法１のシーケンスを、以下でさらに与える：
・（ＴＳＮネットワークからの）ＧＭクロックは、ローカル時間参照をセルラネットワーク内のＢＳに提供する。
・セルラネットワーク内のＢＳは、ＧＭから受信したローカル時間参照を、ＵＥに周期的に送信されるセルラ参照時間（例えば、グローバルＧＰＳベースのセルラ参照時間）と比較することによって、オフセットを計算する。
・計算されたオフセットは、他の必要な情報（例えば、エポック、ＴＳＮドメイン番号、時間ドメイン識別子）と共に、例えば専用のＲＲＣ信号を介して１つまたは複数のＵＥに送達される。
・ＵＥは、オフセットを復号化して、それを例えばＴＳＮデバイス、ブリッジまたはＴＳＮエンドポイントに提供する前に、示されるオフセットごとにローカル時間参照を調節する。
一定の実施形態によると、方法１の実施形態により、セルラＵＥ用に複数の時間ドメインの規定が可能になる。そのようにして、（例えば、ＧＰＳに基づく）セルラ参照時間は、すべてのＵＥにブロードキャストされる。
追加的に、ＴＳＮドメイン特有のワーキング時間は、個々のＵＥへ時間オフセットを送信することによって、ＢＳとＵＥとの間で確立される。オフセットは、共通のブロードキャストされたセルラ参照時間に基づいて、ＢＳにおいて計算される。
特定の実施形態によると、ＢＳはブロードキャストまたはユニキャストによって、オフセットをＴＳＮドメイン識別子と共に所与のドメイン内のＵＥに送信する。ＵＥは、必要とするＴＳＮドメインを識別して（または特定のＴＳＮドメインを使うよう設定され）、そのＴＳＮドメインに対応する時間オフセットを考慮して、自身のクロックを特定のＴＳＮドメインワーキング時間／ローカル参照時間に調整する。つまり、セルラ参照時間に特定の時間オフセットをプラスしたものを考慮する。
図１５０では、５Ｇセルラネットワークおよびバックボーン内のＴＳＮドメインからの１つの追加的な時間信号を想定して方法１が説明されている。一定の実施形態によると、ＢＳはセルラ参照時間（１０：００、１０：１０、１０：２０・・・）を、規定の時間的ポイントですべてのＵＥにブロードキャストする。加えて、ＢＳは、オフセットをセルラ参照時間にシグナリングすることによって、ＴＳＮドメイン特有のワーキングクロックをＵＥ１にも送信する。ＢＳとＵＥとの間のベースラインセルラ参照時間同期方法と比較して、送信および処理時間の計算が不要となるため、オフセットの送信に対する要件は、低くなる。やはり、オフセットは十分な周期性で、および不確定性／正確性のインジケーションと共に通信される必要がある。
図１５３は、一定の実施形態による、方法２のシーケンスフローを図示している。方法２のステップを、以下でさらに与える：
・ＵＥは、ＵＥが接続されるＴＳＮネットワークから直接ワーキングクロック時間参照を受信し、次いでＵＥは、個々のオフセットを計算するために、この時間参照をＢＳから受信したセルラ時間参照と比較する。
・ＵＥは、例えばＲＲＣシグナリングによって、計算したオフセットをＢＳにさらに送達した。ＢＳは、オフセットメッセージをＵＥから受信し、ＵＥから受信したオフセットに基づいて時間参照を調節する。続いて、ＢＳは、シナリオ２で説明されるように、修正された時間参照をセルラネットワーク上のＴＳＮデバイスに送る。このように、ネットワーク側のＴＳＮデバイスは、セルラ参照時間ではなくＴＳＮワーキング時間に調整される。
方法２は、方法１と同じ想定に基づいている。
図１５１では、５ＧセルラネットワークおよびＵＥ側のＴＳＮドメインからの１つの追加的な時間信号を想定して方法２が説明されている。特定の実施形態では、方法２は、ＢＳにおいて複数のクロック、または複数のクロックを並行してサポートするセルラ参照時間に基づいてＴＳＮネットワーク用のワーキングクロックを計算するためにオフセットを使用するコアネットワーク機能を有する必要性を含む場合がある。
一定の他の実施形態によると、タイムスタンプを使用して受信機側のオフセット計算が実施される場合がある。具体的には、説明されるソリューションは、例えば外部のグランドマスタからのＰＴＰ時間情報を、時間認識のやり方でＵＥとｇＮＢとの間で送信するために使用される場合がある。したがって、共通の参照時間が、パケットを両方のノードの一方の１つのレイヤから他方のノードの別のレイヤに送信するためにかかった可変時間ｔ＿ｄを評価するために使用される。
ＵＥとｇＮＢとの間の共通の参照時間を使用して、ｔ＿ｄを推定する。上で既に説明したように、ＰＴＰは、産業用のコンテキストではシステムを同期させるために使用されることが多い。このメカニズムは、もちろん逆にも機能し、ＵＥがＰＴＰグランドマスタに同期される。ｐｔｐパケットのこの送信は、外部ＰＴＰデバイスに対してトランスペアレントに、またはＵＥおよびｇＮＢを共に境界クロックのように作用させることによって行われることができる。言及するべき重要なことは、この場合のタイムスタンピングは、ＰＴＰでラウンドトリップ遅延を計算するために行われるような回りくどいやり方では必要とされないことである。タイムスタンピングは、高次レイヤで生じることが可能であり、ＵＥおよびｇＮＢの両方ともベースラインとして既に十分に同期されているため、一方向遅延ｔ＿ｄだけが必要とされる。
これは、ｇＮＢのＵＥ同期について、図１５４に図示されている。
与えられた詳細な説明を鑑みて、図１５５は、一定の実施形態による、共通セルラ参照タイミング信号間の偏差を低減するために無線デバイスによって実施される方法２６００を描いていることが諒解されよう。方法は、無線デバイスがセルラネットワークから第１のタイミング信号を受信するとステップ２６０２で開始する。ステップ２６０４では、無線デバイスは、無線デバイスが接続される少なくとも１つのＴＳＮから第２のタイミング信号を受信する。オフセットを決定するために、ステップ２６０６において、第１のタイミング信号は、第２のタイミング信号と比較される。ステップ２６０８において、無線デバイスは、オフセットをネットワークノードに送信する。
図１５６は、無線ネットワーク内の仮想装置２７００の概略ブロック図を図示している。装置は、無線デバイスまたはネットワークノードに実装することができる。装置２７００は、図１５５を参照して説明される例示的な方法、および可能性としては本明細書で開示されるあらゆる他のプロセスまたは方法を実行するために動作可能である。図１５５の方法は、必ずしも装置２７００だけによって実行される訳ではないことも理解されたい。方法の少なくともいくつかの動作が、１つまたは複数の他のエンティティによって実施される可能性がある。
仮想装置２７００は、１つまたは複数のマイクロプロセッサまたはマイクロコントローラ、ならびにデジタル信号プロセッサ（ＤＳＰ）、特殊目的デジタルロジックなどを含み得る他のデジタルハードウェアを含むことができる処理回路を備える場合がある。処理回路は、メモリに記憶されたプログラムコードを実行するように設定することができ、メモリは、読み取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ、キャッシュメモリ、フラッシュメモリデバイス、光学記憶デバイスなどの１つまたはいくつかのタイプのメモリを含むことができる。メモリに記憶されたプログラムコードは、１つまたは複数の通信および／またはデータ通信プロトコルを実行するためのプログラム命令、ならびにいくつかの実施形態において本明細書で説明される技法のうちの１つまたは複数を実行するための命令を含む。いくつかの実装形態では、処理回路を使用して、第１の受信モジュール２７１０、第２の受信モジュール２７２０、比較モジュール２７３０、送信モジュール２７４０、および装置２７００のあらゆる他の適切なユニットに、本開示の１つまたは複数の実施形態による対応する機能を実施させることができる。
一定の実施形態によると、第１の受信モジュール２７１０は、装置２７００の受信機能のいくらかを実施することができる。例えば、第１の受信モジュール２７１０は、セルラネットワークから第１のタイミング信号を受信することができる。
一定の実施形態によると、第２の受信モジュール２７２０は、装置２７００の受信機能の他のいくらかを実施することができる。例えば、第２の受信モジュール２７２０は、無線デバイスが接続される少なくとも１つのＴＳＮから第２のタイミング信号を受信することができる。
一定の実施形態によると、比較モジュール２７３０は、装置２７００の比較機能のいくらかを実施することができる。例えば、比較モジュール２７３０は、オフセットを決定するために、第１のタイミング信号を第２のタイミング信号と比較することができる。
一定の実施形態によると、送信モジュール２７４０は、装置２７００の送信機能のいくらかを実施することができる。例えば、送信モジュール２７４０は、オフセットをネットワークノードに送信することができる。
用語、ユニットは、エレクトロニクス、電気デバイスおよび／または電子デバイスの分野における従来の意味を有することができ、例えば、電気的および／または電子的な回路、デバイス、モジュール、プロセッサ、メモリ、ロジックソリッドステートおよび／またはディスクリートデバイス、個別のタスク、プロシージャ、計算、出力、および／または表示機能を実行するためのコンピュータプログラムまたは命令、ならびに本明細書で説明されるようなものを含むことができる。
図１５７は、例えば一定の実施形態による、共通セルラ参照タイミング信号間の偏差を低減するための基地局などのネットワークノードによって、方法を描写している。方法は、ネットワークノードが、セルラネットワーク用の第１のタイミング信号を無線デバイスに送信するとステップ２８０２で開始する。２８０４において、ネットワークノードは、無線デバイスによって測定されたオフセットを、無線デバイスから受信する。オフセットは、セルラネットワーク用の第１のタイミング信号と、無線デバイスが接続される少なくとも１つの時間センシティブなネットワーク（ＴＳＮ）に関連付けられる第２のタイミング信号との差に基づいている。無線デバイスから受信したオフセットに基づいて、セルラネットワーク用の第３のタイミング信号が、ステップ２８０６で決定される。第３のタイミング信号は、第１のタイミング信号の調節された時間信号である。ステップ２８０８において、ネットワークノードは、第３のタイミング信号ネットワークノードを無線デバイスに送信する。
図１５８は、無線ネットワーク内の仮想装置２９００の概略ブロック図を図示している。装置は、無線デバイスまたはネットワークノードに実装することができる。装置２９００は、図１５７を参照して説明される例示的な方法、および可能性としては本明細書で開示されるあらゆる他のプロセスまたは方法を実行するために動作可能である。図１５７の方法は、必ずしも装置２９００だけによって実行される訳ではないことも理解されたい。方法の少なくともいくつかの動作が、１つまたは複数の他のエンティティによって実施される可能性がある。
仮想装置２９００は、１つまたは複数のマイクロプロセッサまたはマイクロコントローラ、ならびにデジタル信号プロセッサ（ＤＳＰ）、特殊目的デジタルロジックなどを含み得る他のデジタルハードウェアを含むことができる処理回路を備える場合がある。処理回路は、メモリに記憶されたプログラムコードを実行するように設定することができ、メモリは、読み取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ、キャッシュメモリ、フラッシュメモリデバイス、光学記憶デバイスなどの１つまたはいくつかのタイプのメモリを含むことができる。メモリに記憶されたプログラムコードは、１つまたは複数の通信および／またはデータ通信プロトコルを実行するためのプログラム命令、ならびにいくつかの実施形態において本明細書で説明される技法のうちの１つまたは複数を実行するための命令を含む。いくつかの実装形態では、処理回路を使用して、第１の送信モジュール２９１０、受信モジュール２９２０、決定モジュール２９３０、第２の送信モジュール２９４０、および装置２９００のあらゆる他の適切なユニットに、本開示の１つまたは複数の実施形態による対応する機能を実施させることができる。
一定の実施形態によると、第１の送信モジュール２９１０は、装置２９００の送信機能のいくらかを実施することができる。例えば、第１の送信モジュール２９１０は、セルラネットワーク用の第１のタイミング信号を、無線デバイスに送信することができる。
一定の実施形態によると、受信モジュール２９２０は、装置２９００の受信機能のいくらかを実施することができる。例えば、受信モジュール２９２０は、無線デバイスによって測定されたオフセットを、無線デバイスから受信することができる。オフセットは、セルラネットワーク用の第１のタイミング信号と、無線デバイスが接続される少なくとも１つの時間センシティブなネットワーク（ＴＳＮ）に関連付けられる第２のタイミング信号との差に基づいている。
一定の実施形態によると、決定モジュール２９３０は、装置２９００の決定機能のいくらかを実施することができる。例えば、決定モジュール２９３０は、セルラネットワーク用の第３のタイミング信号を、無線デバイスから受信したオフセットに基づいて決定することができる。
一定の実施形態によると、第２の送信モジュール２９４０は、装置２９００の送信機能の他のいくらかを実施することができる。例えば、第２の送信モジュール２９４０は、第３のタイミング信号ネットワークノードを、無線デバイスに送信することができる。
用語、ユニットは、エレクトロニクス、電気デバイスおよび／または電子デバイスの分野における従来の意味を有することができ、例えば、電気的および／または電子的な回路、デバイス、モジュール、プロセッサ、メモリ、ロジックソリッドステートおよび／またはディスクリートデバイス、個別のタスク、プロシージャ、計算、出力、および／または表示機能を実行するためのコンピュータプログラムまたは命令、ならびに本明細書で説明されるようなものを含むことができる。
図１５９は、一定の実施形態による、共通セルラ参照タイミング信号間の偏差を低減するために無線デバイスによって実施される方法３０００を描写している。方法は、無線デバイスがセルラネットワークから第１のタイミング信号を受信するとステップ３００２で開始する。ステップ３００４では、無線デバイスは、少なくとも１つの時間センシティブなネットワーク（ＴＳＮ）から第２のタイミング信号を受信する。ステップ３００６において、無線デバイスは、セルラネットワークに関連付けられるネットワークノードから、ネットワークノードによって測定されたオフセットを受信する。オフセットは、セルラネットワーク用の第１のタイミング信号と、少なくとも１つのＴＳＮからの第２のタイミング信号との差に基づいている。ステップ３００８において、オフセットは、第１の時間信号と第２の時間信号との偏差を低減するために使用される。
図１６０は、無線ネットワーク内の仮想装置３１７０の概略ブロック図を図示している。装置は、無線デバイスまたはネットワークノードに実装することができる。装置３１００は、図１５９を参照して説明される例示的な方法、および可能性としては本明細書で開示されるあらゆる他のプロセスまたは方法を実行するために動作可能である。図１５９の方法は、必ずしも装置３１００だけによって実行される訳ではないことも理解されたい。方法の少なくともいくつかの動作が、１つまたは複数の他のエンティティによって実施される可能性がある。
仮想装置３１００は、１つまたは複数のマイクロプロセッサまたはマイクロコントローラ、ならびにデジタル信号プロセッサ（ＤＳＰ）、特殊目的デジタルロジックなどを含み得る他のデジタルハードウェアを含むことができる処理回路を備える場合がある。処理回路は、メモリに記憶されたプログラムコードを実行するように設定することができ、メモリは、読み取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ、キャッシュメモリ、フラッシュメモリデバイス、光学記憶デバイスなどの１つまたはいくつかのタイプのメモリを含むことができる。メモリに記憶されたプログラムコードは、１つまたは複数の通信および／またはデータ通信プロトコルを実行するためのプログラム命令、ならびにいくつかの実施形態において本明細書で説明される技法のうちの１つまたは複数を実行するための命令を含む。いくつかの実装形態では、処理回路を使用して、第１の受信モジュール３１１０、第２の受信モジュール３１２０、第３の受信モジュール３１３０、使用モジュール３１４０、および装置３１００のあらゆる他の適切なユニットに、本開示の１つまたは複数の実施形態による対応する機能を実施させることができる。
一定の実施形態によると、第１の受信モジュール３１１０は、装置３１００の受信機能のいくらかを実施することができる。例えば、第１の受信モジュール３１１０は、セルラネットワークから第１のタイミング信号を受信することができる。
一定の実施形態によると、第２の受信モジュール３１２０は、装置３１００の受信機能の他のいくらかを実施することができる。例えば、第２の受信モジュール３１２０は、少なくとも１つの時間センシティブなネットワーク（ＴＳＮ）から第２のタイミング信号を受信することができる。
一定の実施形態によると、第３の受信モジュール３１３０は、装置３１００の受信機能の他のいくらかを実施することができる。例えば、第３の受信モジュール３１３０は、セルラネットワークに関連付けられるネットワークノードから、ネットワークノードによって測定されたオフセットを受信することができる。オフセットは、セルラネットワーク用の第１のタイミング信号と、ＴＳＮからの第２のタイミング信号との差に基づいている。
一定の実施形態によると、使用モジュール３１４０は、装置３１００の使用機能のいくらかを実施することができる。例えば、使用モジュール３１４０は、第１の時間信号と第２の時間信号との偏差を低減するためにオフセットを使用することができる。
用語、ユニットは、エレクトロニクス、電気デバイスおよび／または電子デバイスの分野における従来の意味を有することができ、例えば、電気的および／または電子的な回路、デバイス、モジュール、プロセッサ、メモリ、ロジックソリッドステートおよび／またはディスクリートデバイス、個別のタスク、プロシージャ、計算、出力、および／または表示機能を実行するためのコンピュータプログラムまたは命令、ならびに本明細書で説明されるようなものを含むことができる。
図１６１は、例えば一定の実施形態による、共通セルラ参照タイミング信号間の偏差を低減するための基地局などのネットワークノードによって、方法を描写している。方法は、ネットワークノードが少なくとも１つの時間センシティブなネットワーク（ＴＳＮ）から第２のタイミング信号を受信するとステップ３２０２で開始する。ステップ３２０４では、ネットワークノードは、第２のタイミング信号とセルラネットワーク用の第１の時間信号との比較を実施する。比較に基づいて、セルラネットワーク用の第１のタイミング信号と、ＴＳＮからの第２のタイミング信号との差を含むオフセットが、ステップ３２０６で決定される。ステップ３２０８において、オフセットは、ＴＳＮに接続される無線デバイスに送信される。
図１６２は、無線ネットワーク内の仮想装置３３００の概略ブロック図を図示している。装置は、無線デバイスまたはネットワークノードに実装することができる。装置３３００は、図１６１を参照して説明される例示的な方法、および可能性としては本明細書で開示されるあらゆる他のプロセスまたは方法を実行するために動作可能である。図１６１の方法は、必ずしも装置３３００だけによって実行される訳ではないことも理解されたい。方法の少なくともいくつかの動作が、１つまたは複数の他のエンティティによって実施される可能性がある。
仮想装置３３００は、１つまたは複数のマイクロプロセッサまたはマイクロコントローラ、ならびにデジタル信号プロセッサ（ＤＳＰ）、特殊目的デジタルロジックなどを含み得る他のデジタルハードウェアを含むことができる処理回路を備える場合がある。処理回路は、メモリに記憶されたプログラムコードを実行するように設定することができ、メモリは、読み取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ、キャッシュメモリ、フラッシュメモリデバイス、光学記憶デバイスなどの１つまたはいくつかのタイプのメモリを含むことができる。メモリに記憶されたプログラムコードは、１つまたは複数の通信および／またはデータ通信プロトコルを実行するためのプログラム命令、ならびにいくつかの実施形態において本明細書で説明される技法のうちの１つまたは複数を実行するための命令を含む。いくつかの実装形態では、処理回路を使用して、受信モジュール３３１０、実施モジュール３３２０、決定モジュール３３３０、送信モジュール３３４０、および装置３３００のあらゆる他の適切なユニットに、本開示の１つまたは複数の実施形態による対応する機能を実施させることができる。
一定の実施形態によると、受信モジュール３３１０は、装置３３００の受信機能のいくらかを実施することができる。例えば、受信モジュール３３１０は、少なくとも１つの時間センシティブなネットワーク（ＴＳＮ）から第２のタイミング信号を受信することができる。
一定の実施形態によると、実施モジュール３３２０は、装置３３００の実施機能のいくらかを実施することができる。例えば、実施モジュール３３２０は、第２のタイミング信号とセルラネットワーク用の第１の時間信号との比較を実施し得る。
一定の実施形態によると、決定モジュール３３３０は、装置３３００の決定機能のいくらかを実施することができる。例えば、決定モジュール３３３０は、比較に基づいて、セルラネットワーク用の第１のタイミング信号と、ＴＳＮからの第２のタイミング信号との差を含むオフセット。
一定の実施形態によると、送信モジュール３３４０は、装置３３００の送信機能のいくらかを実施することができる。例えば、送信モジュール３３４０は、オフセットを、ＴＳＮに接続される無線デバイスに送信することができる。
ＴＳＮ検出と複数時間ドメインのサポートとの組合せ
やはり、上で示したように、本明細書で説明される様々な技法は、互いに組み合わせて、レイテンシ、信頼性などに関する優位性を与えることができる。例えば、有利である１つの特定の組合せは、ＴＳＮのサポートを検出するための上述の技法と、すぐ上で説明した複数の時間ドメインをサポートするための技法との組合せである。
したがって、例えば、図１３５に図示される方法は、図１５５で示される方法と組み合わせることが可能であり、結果として、方法は、無線通信ネットワークに関連付けられる無線デバイスによって実施される。この方法は、図１３５のブロック４０２で示されるように、無線アクセスネットワーク（ＲＡＮ）の無線基地局（ＲＢＳ）からシステム情報（ＳＩ）を受信するステップであって、ＳＩはＲＢＳを通じて、時間センシティブなネットワーキング（ＴＳＮ）のサポートを示す、受信するステップ、ならびに図１３５のブロック４０４で示されるように、ＲＢＳを通じて外部データネットワークとの少なくとも１つのＴＳＮストリームを確立するステップを含む。方法は、図１５５のブロック２６０２に示されるように、ＲＢＳを介して無線通信ネットワークから、第１のタイミング信号を受信するステップと、図１５５のブロック２６０４に示されるように、無線デバイスが接続される外部のＴＳＮデータネットワークから第２のタイミング信号を受信するステップをさらに含む。図１５５のブロック２６０６および２６０８に示されるように、方法は、オフセットを決定するために第１のタイミング信号を第２のタイミング信号と比較することと、オフセットを無線通信ネットワークに送信することとを、さらになお含む。
これらの実施形態の一部では、ＳＩは、１つまたは複数のシステム情報ブロック（ＳＩＢ）に含まれる。いくつかの実施形態では、第１のタイミング信号は、セルラ時間参照を含む。いくつかの実施形態では、第２のタイミング信号は、ワーキングクロック時間参照を含む。いくつかの実施形態では、オフセットは、第１のタイミング信号と第２のタイミング信号との間の時間における差の測定値である。いくつかの実施形態では、オフセットは、ＲＲＣシグナリングを介して無線通信ネットワークに送信される。
いくつかの実施形態では、ＲＢＳから、無線通信ネットワークからの第３のタイミング信号を受信するステップであって、第３のタイミング信号は第１のタイミング信号の調節された時間信号である、受信するステップをさらに含むことができる。
いくつかの実施形態では、方法は、オフセットに基づいてローカル時間参照を調節することをさらに含む。いくつかの実施形態では、方法は、オフセットを外部のＴＳＮデータネットワークに送信することをさらに含む。方法は、エポック、ＴＳＮドメイン番号、時間ドメイン識別子のうちの少なくとも１つを、ＲＢＳおよび外部のＴＳＮデータネットワークのうちの少なくとも１つに送信することをさらに含むことができる。
グラントの優先順位付け
アップリンク（ＵＬ）トラフィックは、動的ＵＬグラントまたは設定ＵＬグラントでスケジューリングすることができる。動的グラントの場合、ｇＮＢはＵＬ送信ごとに、ＵＬグラントをＵＥに提供する。設定グラントは、事前割り当てされる、つまりいったんＵＥに提供され、その後、設定ＵＬグラントは、設定された周期性にしたがって、ＵＬ送信の利用について有効となる。ＵＥは、送信に利用可能なＵＬデータがない場合は、それらＵＬリソースに対するパディングを送信する必要はなく、つまりそのようなグラントに対してはＵＬ送信をスキップすることができる。
典型的なＮＲ－ＩｏＴデバイスは、複数のサービスタイプ、例えば周期的な超高信頼低レイテンシ通信（ＵＲＬＬＣ）タイプのロボット制御メッセージ、周期的なリソースが設定される必要のあるＵＲＬＬＣタイプのオケージョナルなアラーム信号、オケージョナルなセンサデータ送信、オケージョナルな動画送信またはソフトウェアアップデートなどの他のモバイルブロードバンド（ＭＢＢ）タイプのトラフィック向けの通信をハンドリングする。これは、ＵＬ送信のためにＵＥによって多重化されるトラフィックミックスにつながる。つまり、メディアアクセス制御（ＭＡＣ）に対して、異なる優先度を有する複数の論理チャネルが設定される必要がある。
周期的なＵＲＬＬＣトラフィックが、確定的なレイテンシ内で送達されなければならない。つまり、ロバストな送信が保証されなければならず、これはリソース利用の点からコスト高である。他方では、センサ／ＭＢＢタイプのトラフィックが、同様にサービングされなければならないが、これに対してリソースは可能な限り効率的に、つまりあまりロバストではなく、使用されるべきである。現在は、異なる要件を有する両方のトラフィックタイプのＵＥマルチプレクシングが、ＮＲシステム内で、どのように効率的にハンドリングされ得るか、明確ではない。
特に、現在の標準によると、例えば、例えばあまりロバストではなくＭＢＢには大きい動的ＵＬグラント、または他のＵＬグラントは、例えばＵＲＬＬＣ送信用の非常にロバストである設定ＵＬグラントをオーバライドし、ＵＲＬＬＣ送信の確定論を壊すか、またはｇＮＢがすなわち設定ＵＬグラントの「周り」をスケジューリングすることによってこれらのオーバライドを回避するには高度に複雑化するかのいずれかであり、これは一部のリソース状況では実現可能でない場合がある。したがって、これは無線通信ネットワークのパフォーマンスを低減または限定する結果となり得る。
本明細書における実施形態によると、ｇＮＢまたは他の無線基地局（ＲＢＳ）などの無線ネットワークノードは、ＵＥを設定グラントおよび／またはＵＬ送信用の動的グラントで設定する。動的なグラント、または設定グラントのどちらが、ＵＥによってＵＬ送信に使用されかの決定は、論理チャネル優先順位付け決定にしたがって、ＵＬデータが設定グラントＵＬリソースで送信するために取得されているかどうかによって条件的である。つまり、特にＭＡＣプロトコルデータユニット（ＰＤＵ）がＭＡＣマルチプレクシング／アセンブリエンティティから取得可能かどうか、つまり、設定ＵＬグラントで送信することが可能な論理チャネルで利用可能なデータがないことにより、アップリンクグラントがスキップされるかどうかによる。
設定可能である論理チャネル制限条件により、一部の論理チャネルのデータ送信は設定ＵＬグラントで許可されていないと想定する。つまりＭＢＢタイプの非クリティカル論理チャネル用である。このように、貴重なロバストなリソースは、ロバストなリソースを必要としないＭＢＢタイプのトラフィックを送ることにより無駄にはならないが、いくらか長い時間待機／遅延して、より効率的で、あまりロバストではなく動的にスケジューリングされるリソースで送信される可能性がある。
より具体的には、本明細書における実施形態によると、設定ＵＬグラントの場合（所望される頻繁かつロバストな、しかしＵＲＬＬＣデータなどの高信頼で送信されるデータが意図された小さな割り当てで）：
・設定グラント、設定スケジューリング（ＣＳ）－ＲＮＴＩのＰＤＣＣＨでの以前受信した設定グラントが優先された場合でも、それでのＵＬ送信がない、つまり、設定グラントでの送信用の利用可能なＵＬデータがない、つまり、設定グラントでの送信が許可されるＵＲＬＬＣタイプの論理チャネルで利用可能なＵＬデータがないという条件下では、セル無線ネットワーク一時識別子（Ｃ－ＲＮＴＩ）の物理ダウンリンク制御チャネル（ＰＤＣＣＨ）で受信された、受信したＵＬ動的グラント、例えば、効率的な（あまりロバストではない）送信パラメータを有する大きなグラントを新しい送信用に優先する。現在の標準によると、受信した動的ＵＬグラントは、ＵＬデータの利用可能性とは無関係に、いつも優先されることに留意されたい。
・設定論理チャネル制限にしたがってＵＬ設定グラントでの送信が許可されるあらゆる論理チャネル用に、ＵＬ設定グラントでの送信用に利用可能なＵＬデータがある場合、ＵＬ設定グラントを優先する。例えば、ＵＲＬＬＣ論理チャネル（ＬＣＨ）データである。
・さらなる実施形態によると、ＵＬ設定グラントは、上の条件にしたがっており、かつ論理チャネル送信が設定グラントで「のみ」許可される場合にのみ優先される。つまり、それ以外では、動的グラントが優先されると、この論理チャネルデータが送信される可能性はない。
要求される再送信は、いつも優先される可能性があることに留意されたい。つまり、別の実施形態では、以前の設定グラントで送られたＭＡＣ ＰＤＵの再送信は、後からの設定グラントより優先される。より詳細には、動的ＵＬグラントが設定グラントの再送信のためのものである場合、つまり、ＣＳ－ＲＮＴＩでスクランブルされ、受信したハイブリッド自動再送要求（ＨＡＲＱ）情報中のＮｅｗ Ｄａｔａ Ｉｎｄｉｃａｔｏｒ（ＮＤＩ）が１である場合、ＭＡＣ ＰＤＵが取得しているか否かに関わらず、この動的グラントは設定ＵＬグラントをオーバライドする。
別の実施形態では、上記にしたがってＵＬ設定グラントを優先する場合、以下の例外が考慮される：動的グラントだけで送信されるよう制限されているＬＣＨが、設定ＵＬグラントだけで送信するよう制限が設定される別のＬＣＨより高い優先度である場合、ＵＬ設定グラントを優先しない。
一実施形態では、動的ＵＬグラントまたは設定ＵＬグラントのいずれかでの送信を期待しているｇＮＢ、つまり両方の可能性をブラインド復号する。
ＵＬデータが論理チャネル優先順位付け手順にしたがって設定グラントリソースで送信される条件下では、重複しているリソース用に動的ＵＬグラントが受信されても、ＵＥは設定ＵＬを使用する。
一般的なシナリオでは、用語「無線ネットワークノード」は、「送信ポイント」と置き換えることができることに留意されたい。送信ポイント（ＴＰ）同士の違いは、典型的にはＣＲＳまたは送信される様々な同期信号に基づいている可能性がある。いくつかのＴＰは、同一の無線ネットワークノードに論理的に接続することができるが、ＴＰが地理的に別個にされている場合、または異なる伝搬方向を指向している場合、ＴＰは異なる無線ネットワークノードと同じ移動体の問題の対象となり得る。後続のセクションでは、用語「無線ネットワークノード」と「ＴＰ」は、互換可能であると考えることができる。
図１６３は、本明細書の実施形態による、フローチャートとシグナリングスキームの組合せである。図面で図示され、以下で説明されるアクションは、任意の適切な順で実施することができる。
アクション２０１：論理チャネル優先順位付け手順にしたがって設定グラントで送信されるＵＬデータが存在するという条件下で、無線ネットワークノード１２は、ＵＥ１０を設定して、設定された周期的なＵＬグラントを、動的ＵＬグラントのＵＬ送信上で、ＵＬ送信を優先することができる。設定された周期的なＵＬグラントは、第１のタイプの送信、例えば、ＵＲＬＬＣ送信などの重要データ送信用であり得、動的なＵＬグラントは、第２のタイプの送信、例えば、ＭＢＢ送信などの非重要データ送信用であり得る。
アクション２０２：無線ネットワークノード１２は、ＵＥ１０を、第２のタイプのＵＬ送信、例えばブロードバンドサービスまたは類似のサービス向けの、例えば非レイテンシセンシティブな送信などの非重要データ送信用の動的グラントでスケジューリングすることができる。これは、無線ネットワークノードが、動的ＵＬグラントをＵＥ１０に送信することを意味している場合がある。したがって、ＵＥ１０はＵＬ送信用のスケジューリング要求を送り、続いてＵＬ送信用の動的ＵＬグラントを受信することができる。
アクション２０３：論理チャネル優先順位付け手順にしたがって設定された周期的なＵＬグラントで送信されるＵＬデータが存在するという条件下で、ＵＥ１０は、設定された周期的なＵＬグラントを、動的ＵＬグラントのＵＬ送信上で、ＵＬ送信を優先する。設定された周期的なＵＬグラントは、ＵＲＬＬＣ送信などの第１のタイプの送信用であり得、動的なＵＬグラントは、ＭＢＢ送信などの第２のタイプの送信用であり得る。
アクション２０４：アクション２０３においてＵＥ１０が周期的なＵＬグラントを優先してある場合、ＵＥは、ＵＲＬＬＣ送信などの第１のタイプの送信の送信を送信することができる。
アクション２０５：アクション２０３においてＵＥ１０が動的なＵＬグラントを優先してある場合、ＵＥは、ＭＢＢ送信などの第２のタイプの送信の送信を送信することができる。
図１６４は、本明細書における実施形態により、無線通信ネットワーク１において、例えば無線ネットワークノードへの通信をハンドリングまたは可能にする設定をハンドリングするためのＵＥ１０を描写するブロック図である。ＵＥ１０は、処理回路８０１、例えば本明細書の方法を実施するように設定される、１つまたは複数のプロセッサを含むことができる。ＵＥ１０は、受信ユニット８０２、例えば受信機または送受信機を含むことができる。ＵＥ１０、処理回路８０１、および／または受信ユニット８０２は、無線ネットワークノード１２から設定データを受信するように設定することができる。論理チャネル優先順位付け手順にしたがって設定グラントで送信されるＵＬデータが存在するという条件下で、設定データは、ＵＥが、動的ＵＬグラントのＵＬ送信上で、設定された周期的なＵＬグラントのＵＬ送信を優先するよう規定し得る。設定された周期的なＵＬグラントは、ＵＲＬＬＣ送信などの第１のタイプの送信用であり得、動的なＵＬグラントは、ＭＢＢ送信などの第２のタイプの送信用であり得る。ＵＥ１０、処理回路８０１、および／または受信ユニット８０２は、ＵＬ送信用の動的ＵＬグラントを受信するように設定される。
ＵＥ１０は、優先ユニット８０３を含むことができる。論理チャネル優先順位付け手順にしたがって設定された周期的なＵＬグラントで送信されるＵＬデータが存在するという条件下で、ＵＥ１０、処理回路８０１、および／または優先ユニット８０３は、動的ＵＬグラントのＵＬ送信上で、設定された周期的なＵＬグラントのＵＬ送信を優先するように設定され得る。ＵＥ１０は、送信ユニット８０４、例えば送信機または送受信機を含むことができる。論理チャネル優先順位付け手順にしたがって設定された周期的なＵＬグラントで送信されるＵＬデータが存在するという条件下で、ＵＥ１０、処理回路８０１、および／または送信ユニット８０４は、動的ＵＬグラントのＵＬ送信上で、設定された周期的なＵＬグラントのＵＬ送信を優先するように設定され得る。いくつかの例では、優先ユニット８０３は、優先順位付けを実施する。したがって、これらの例では、ＵＥ１０、処理回路８０１、および／または送信ユニット８０４は、ＵＥ１０、処理回路８０１、および／または優先ユニット８０３によって優先される通りに、第１のタイプの送信または第２のタイプの送信を送信するよう設定することができる。
ＵＥ１０は、メモリ８０７をさらに含む。メモリは、ＲＳ、強度、または品質、ＵＬグラント、インジケーション、要求、コマンド、実行されると本明細書において開示される方法を実施するアプリケーション、および類似のものについてのデータを記憶するために使用される１つまたは複数のユニットを含む。ＵＥ１０は、１つまたは複数のアンテナを含む通信インターフェースを含む。
ＵＥ１０に関して本明細書において説明される実施形態による方法は、例えばコンピュータプログラム製品８０５、または、命令、すなわちソフトウェアコード部分を含むコンピュータプログラムによって、それぞれ実装され、コンピュータプログラムは、少なくとも１つのプロセッサで実行されると、少なくとも１つのプロセッサに、ＵＥ１０によって実施されるような、本明細書において説明されるアクションを実行させる。コンピュータプログラム製品８０５は、コンピュータ可読記憶媒体８０６、例えばユニバーサルシリアルバス（ＵＳＢ）スティック、ディスク、または類似のものに記憶することができる。コンピュータプログラム製品が記憶されているコンピュータ可読記憶媒体８０６は、少なくとも１つのプロセッサで実行されると、少なくとも１つのプロセッサに、ＵＥ１０によって実施されるような、本明細書において説明されるアクションを実行させる命令を含むことができる。いくつかの実施形態では、コンピュータ可読記憶媒体は、非一時的または一時的なコンピュータ可読記憶媒体であってもよい。
図１６５は、本明細書の実施形態による、無線通信ネットワーク１内で、設定をハンドリングするため、例えば容易にするための無線ネットワークノード１２を描いたブロック図である。無線ネットワークノード１２は、処理回路１００１、例えば本明細書の方法を実施するように設定される、１つまたは複数のプロセッサを含むことができる。
無線ネットワークノード１２は、設定ユニット１００２を含むことができる。無線ネットワークノード１２、処理回路１００１、および／または設定ユニット１００２は、ＵＥ１０を論理チャネル上でのＵＬ送信用のＵＬグラントで設定するように設定される。無線ネットワークノード１２は、スケジューラなどのスケジューリングユニット１００３を含むことができる。無線ネットワークノード１２、処理回路１００１、および／またはスケジューリングユニット１００３は、ＵＥ１０をブロードバンドサービスまたは類似のもののＵＬ送信用の動的グラントでスケジューリングするようにさらに設定することができる。
無線ネットワークノード１２は、受信ユニット１００４、例えば受信機または送受信機を含むことができる。無線ネットワークノード１２、処理回路１００１、および／または受信モジュール１００４は、無線リソース上のＵＥ１０からデータを受信するように設定される。無線ネットワークノード１２は、メモリ１００５をさらに含む。メモリは、強度、または品質、グラント、スケジューリング情報、実行されると本明細書において開示される方法を実施するアプリケーション、および類似のものついてのデータを記憶するために使用される１つまたは複数のユニットを含む。無線ネットワークノード１２は、送信機、受信機、送受信機、および／または１つもしくは複数のアンテナを含む通信インターフェースを含む。
無線ネットワークノード１２に関して本明細書において説明される実施形態による方法は、例えばコンピュータプログラム製品１００６、または、命令、すなわちソフトウェアコード部分を含むコンピュータプログラム製品によって、それぞれ実装され、コンピュータプログラム製品は、少なくとも１つのプロセッサで実行されると、少なくとも１つのプロセッサに、第１の無線ネットワークノード１２によって実施されるような、本明細書において説明されるアクションを実行させる。コンピュータプログラム製品１００６は、コンピュータ可読記憶媒体１００７、例えばＵＳＢスティック、ディスク、または類似のものに記憶することができる。コンピュータプログラム製品が記憶されているコンピュータ可読記憶媒体１００７は、少なくとも１つのプロセッサで実行されると、少なくとも１つのプロセッサに、無線ネットワークノード１２によって実施されるような、本明細書において説明されるアクションを実行させる命令を含むことができる。いくつかの実施形態では、コンピュータ可読記憶媒体は、非一時的または一時的なコンピュータ可読記憶媒体であってもよい。
ＴＳＮ検出とグラント優先順位付けとの組合せ
再度になるが、上で示したように、本明細書で説明される様々な技法は、互いに組み合わせて、レイテンシ、信頼性などに関する優位性を与えることができる。例えば、有利である１つの特定の組合せは、ＴＳＮのサポートを検出するための上述の技法と、すぐ上で説明したグラントの優先順位付けのための技法との組合せである。
したがって、例えば、図１３５に図示される方法は、図１６３で示される方法と組み合わせることが可能であり、結果として、別の方法が、無線通信ネットワークに関連付けられる無線デバイスによって実施される。この方法は、図１３５のブロック４０２で示されるように、無線アクセスネットワーク（ＲＡＮ）の無線基地局（ＲＢＳ）からシステム情報（ＳＩ）を受信するステップであって、ＳＩはＲＢＳを通じて、時間センシティブなネットワーキング（ＴＳＮ）のサポートを示す、受信するステップ、ならびに図１３５のブロック４０４で示されるように、ＲＢＳを通じて外部データネットワークとの少なくとも１つのＴＳＮストリームを確立するステップとを含む。方法は、図１６３のステップ２０１に示されるように、無線通信ネットワークへのアップリンク送信に使用するアップリンクリソースを示す周期的なアップリンクグラントを設定する設定情報のステップと、図１６３のステップ２０２に示されるように、無線通信ネットワークへのアップリンク送信用の動的アップリンクグラントを受信するステップとをさらに含む。図１６３のステップ２０３に示されるように、この例示的な方法は、論理チャネル優先順位付け手順にしたがって設定された周期的なアップリンクグラントで送信されるアップリンクデータが存在することを条件として、動的アップリンクグラントを使用するアップリンク送信よりも、設定された周期的なアップリンクグラントを使用するアップリンク送信を優先するステップをさらに含む。
いくつかの実施形態では、ＳＩは、１つまたは複数のシステム情報ブロック（ＳＩＢ）に含まれる。いくつかの実施形態では、論理チャネル優先順位付け手順は、設定された周期的なアップリンクグラント上で、一部の論理チャネルの送信を妨げる。この後者の実施形態の一部では、論理チャネル優先順位付け手順は、設定された周期的なアップリンクグラントを使用する送信を、超高信頼低レイテンシ通信（ＵＲＬＬＣ）メッセージに制限する場合がある。いくつかの実施形態では、動的アップリンクグラントは、モバイルブロードバンド（ＭＢＢ）送信向けである。
ＩｏＴ環境におけるデバイスエンロールメント
モノのインターネット（ＩｏＴ）は、一般に、電子機器、ソフトウェア、センサ、アクチュエータ、ならびに、典型的には、デバイスが接続し、データを交換することができる接続を組み込んだ、物理デバイス、車両、家庭電化製品、および／または他の品目のネットワークとして知られている。本明細書で論じられるように、産業用ＩｏＴは、単に、工場内などの産業用の環境に適用されるようなＩｏＴである。
ＩｏＴシステムもしくはＩｏＴ環境（この用語は、本開示で区別なく使用されることがある）に新しいデバイスを追加すること、または、まさに最初にＩｏＴシステム全体を展開することは、典型的には、デバイス、すなわちセンサ、アクチュエータ等を、そのそれぞれの物理的位置に物理的にインストールすることと、例えば地理位置、所有者、目的等などの識別情報および他の属性でデバイスを設定することと、例えば、Ｗｉ－Ｆｉアクセスポイントおよびパスワード、暗号鍵および証明といった、通信パラメータをセットアップすることと、デバイスを使用することになる、およびデバイスが使用することになる（クラウド）サービスにデバイスを登録する、デバイスのエンロールメントと、を含む。
典型的な例は、（住宅用または商業用の）新しいサーベイランスシステムを設置することである。各デバイスは、その機能を事前設定されるが、典型的には、位置（例えば居間）および通信（例えば、ＩｏＴシステムの通信ハブにどのように接触するか）などの、状況、背景、および／または意図した使用に基づいて変化し得る特定の設定を必要とする。通信ハブは、典型的には、（ＧＳＭ／ＧＰＲＳ通信のための）電話番号、または（ＩＰベース通信のための）ネットワークアドレス、およびサービスのためのパスワードなどの、所有者への接触の詳細で設定されるはずである。典型的には、パラメータのいくつかは、（例えば製造中に）一斉に設定することができ、パラメータのいくつかは、設置後に設定されるはずである。
デバイスのエンロールメントを行う様々な方式が存在する。共通の方式は、典型的には、以下を含む。
・設置前／直後にデバイスを設定すること。典型的には、最初にスタートしたときにデバイスを「信頼していること」が可能であることが一般的である（ＴＯＦＵ、Ｔｒｕｓｔ Ｏｎ Ｆｉｒｓｔ Ｕｓｅとして知られる）。これにより、設置者またはオペレータは、全くセキュリティを使用せずに、または、デバイスの全てに共通の、および、インターネット上でしばしば見つけることができる、ユーザもしくはパスワードの組合せなど、製造中に設定されたセキュリティ証明を使用することによって、ＩｏＴデバイスを簡単に設定することができる。このアプローチに伴う典型的な欠点は、中間者攻撃に対して脆弱であること、および、デフォルトパスワードが設定後に変更されないことが多く、さらに改ざんできることにより、セキュリティが簡単に危険にさらされることである。
・典型的には、設定パラメータを受信するために、所定のアドレスに対して、デバイスに「フォンホーム」させることによってデバイスをブートストラップすること。それでも、このアプローチは、インターネットアクセス、または、典型的にはＩＰベース通信を使用した少なくとも１つの所定のアドレスへのアクセスを必要とする。
したがって、ＩｏＴ環境へのデバイスのエンロールメントのための従来のアプローチは、典型的には、セキュアでない、および／または柔軟性がない。したがって、ＩｏＴシステムにおけるデバイスエンロールメントに、セキュアかつ柔軟な手段を提供する必要がある。
ちょうど言及されたように、システムに新しいデバイスを追加すること、または、まさに最初にＩｏＴシステムを展開することは、典型的には、
・デバイスを物理的に設置すること、
・識別情報および他の属性でデバイスを設定すること、
・通信パラメータをセットアップすること、ならびに
・デバイスのエンロールメント
を含む。
典型的な例は、ファクトリオートメーションシステムに新しいコントローラを追加することである。コントローラは、典型的には、制御ループの設定／再設定を誰が許可されているか、および、警告／エラーをどこに、またどのように送るかを、知っている必要がある。コントローラは、さらに典型的には、通信を暗号化するための秘密鍵を必要とし、典型的には、他のデバイスおよびサービスとどのように通信するか（すなわち、証明、鍵等についての情報をどのように受信するか）を知っている必要がある。
それでも、前述のように、従来のエンロールメント処理は、典型的には、同じデフォルトパスワードを使用することによってデバイスの設定を再び実施できるのでセキュアでないシステムにつながる恐れがあり、または、インターネット接続が要求されることによりエンロールメントが阻止される。
典型的には、いずれかのコンピュータアプリケーションをいくつかの形でシリアライズすることができることが知られている。コンピュータシリアライゼーションは、典型的には、（場合によっては、異なるコンピュータ環境に）格納または伝送し、後で再構築することができるフォーマットに、データ構造またはオブジェクトステータスを変換する処理である。一連のバイトからデータ構造を抽出する逆の動作は、典型的には、デシリアライゼーションとして知られている。シリアライゼーションは、それでも、複雑かつ詳細でなければならない可能性があり、したがって、アプリケーションが実行しているはずの環境が、ことによると、かなり複雑な機能の高レベル抽象化をサポートしない限り、より多くのストレージ空間を必要とする。
本明細書で説明されるシリアライゼーション／デシリアライゼーションは、データをシリアライズ／デシリアライズするのに適した任意の方法に従って行うことができる。
本明細書におけるいくつかの実施形態によれば、アプリケーションは、ＩｏＴ環境へのデバイスのエンロールメントの実行を支援する／可能にするためのエンロールメント情報を含むエンロールメントアプリケーションであってもよい。
例えば、ＱＲコードまたはバーコードなどの限定的なフォーマットを使用してエンロールメントアプリケーションを符号化することは、利用可能な空間にいくつかの制約を加える（ことによると、ＨＣＣＢなどの高密度フォーマットが、およそ３００バイト／ｃｍ２に制限される）。
それでも、エンロールメントアプリケーションの高レベルの記述を使用すると、シリアライゼーションを使用することによって限定的な量の空間を使用して、アプリケーションを、内部状態、パラメータ等も付け加えて、文字列、バーコード、またはＱＲコードとして符号化することができる。
いくつかの実施形態によれば、このことは、インターネット接続の必要がないセキュアな符号化されたエンロールメント処理を提供するために利用することができる。
例えば、本明細書におけるいくつかの実施形態によれば、エンロールメントアプリケーションは、いくつかのデバイスにわたって配布することができ、または、いくつかのエンロールメントアプリケーションは、いくつかの実施形態では、別のデバイスのエンロールメントを支援するために１つのデバイスを使用することができる異なるデバイス上で動いていてもよく、地理的＆組織の位置、所有権、暗号鍵、通信パラメータ（例えば、Ｗｉ－Ｆｉアクセスポイント、ログイン認証情報、およびゲートウェイまたはウェブサービスへのアドレス等）についての情報を支援デバイスから検索し、例えば、エンロールメントされているデバイスの１つまたは複数に情報を永続的に格納することができる。さらに、エンロールメントアプリケーションは、アプリケーションの状態で、例えば通信および識別情報についての鍵などの情報が検索されたデバイスの所有権を想定するのに必要な全ての情報を含むことができる。
これらのエンロールメントアプリケーションは、次に、例えば、パッケージ内部の、または、デバイスの側面に印刷された、または、受領書に生成され、印刷された、または、製造業者のウェブサイトからダウンロードされた、または、他のいくつかの形で配布された、ノートによって、１つまたは複数のＩｏＴデバイスとともにシリアライズされ、供給される。
例えば、例えば携帯電話といった支援デバイスによってコードを取得すること、または、別のやり方でコードを検索すること、および、その後、例えば携帯電話におけるアプリケーションまたは機能を使用することによってデシリアライズすることは、エンロールメントアプリケーションのデジタル表現を与え、デジタル表現は、次に、エンロールメントに使用される少なくともＩｏＴ－デバイスおよび（例えば）携帯電話からなるシステム上で展開することができる。
支援デバイスは、必ずしも携帯電話である必要はなく、いくつかの実施形態では、別のＩｏＴデバイス、またはエンロールメント情報をデシリアライズするのに適した他のデバイスであってもよいことに留意されたい。
エンロールメントアプリケーションは、少なくとも２つのデバイス（エンロールメントされることになるＩｏＴデバイス、およびエンロールメントを支援する携帯電話）にわたって配布することができ、ＩｏＴデバイスおよび携帯電話に全ての関係情報を配信することによってエンロールメント処理の実行を開始する。
エンロールメントアプリケーションは、いくつかの実施形態では、支援デバイス（例えば携帯電話）、およびエンロールメントされることになるＩｏＴデバイスのどちらか一方または両方によって実施される必要があり得るエンロールメントのステップに関するエンロールメント情報も含むことができる。
ＩｏＴデバイスは、エンロールメント情報を永続的に格納し、アプリケーションを終了させ、その後、その意図した動作を再開する。
ＩｏＴデバイスは、任意選択として、データの改ざんまたは変更を防ぐために、ヒューズを焼く（ｂｕｒｎ ａ ｆｕｓｅ）こと、または同様の何かを行うことができ、したがって、所有権を永久的なものにする。携帯電話は、任意選択として、登録の結果をサーバに転送することができる。
ＩｏＴフレームワークでは、相当に高レベルの抽象化を使用して機能を記述すると、すなわち、「ｓｅｔ＿ｐｉｎ（１８，０）」などの詳細かつ低レベルのコマンドではなく、「トリガアラーム」などの高レベルの記述を使用して、意味的に高レベルで機能を記述すると、例えばモバイルデバイスによって変換することができるバーコードまたはＱＲコードとして、かなり大きく複雑なアプリケーションさえ符号化することができる。アプリケーション自体は、いくつかのデバイスをカバーする配布型アプリケーション、または、データを交換する別々のアプリケーションであってもよい。
符号化したアプリケーションは、次に、例えば、いくつかの実施形態では、以下を行うことができる。
１）ＩｏＴデバイスに印刷すること。
２）ＩｏＴデバイスパッケージ内のノートに含めること。
３）ＩｏＴデバイスとともに供給される一意の識別子を使用して、ウェブサービスからまとめてダウンロードすること。
符号化したアプリケーションを配信するための他のオプションが、当然可能である。
ＩｏＴデバイスを設置する技術者またはオペレータは、次に、モバイルデバイスを支援デバイスとして使用して、（例えばコードをスキャンすることによって）１つのバーコード／複数のバーコードを取得し、１つまたは複数のアプリケーションを展開することができる。携帯電話上で実行するアプリケーション（またはアプリケーションの一部）は、次に、位置、目的、所有権、資格証明、および他の重要情報などの設定データに書き込み、その一方で、エンロールメントされることになるデバイス上のアプリケーション（またはアプリケーションの一部）は、この情報を永続的に格納する。
設定／エンロールメントが完了した後、アプリケーションは処分され、ＩｏＴデバイスは、供給された設定／エンロールメントデータを使用して、通常の動作を再開する。
このアプローチは、例えばＩｏＴデバイスの簡単な自動登録、設定、およびエンロールメントを可能にし、デバイスは、インターネット、または登録デバイスと通信する手段（Ｂｌｕｅｔｏｏｔｈ、ＮＦＣ、Ｗｉ－Ｆｉ等）以外の他の任意の接続へのアクセスを必要としない。
図１６８は、モノのインターネット（ＩｏＴ）環境への第２のデバイスのエンロールメント処理を始めるための、いくつかの実施形態による第１のデバイスの実例の方法１００を示す。
第１のデバイスは、例えば、携帯電話などの無線通信デバイスであってもよい。第１のデバイスは、ハンドヘルドコンピュータ、ラップトップコンピュータ、またはサーフパッドなどの、高レベルの抽象化をデシリアライズすることができる任意のデバイスであってもよい。モバイルデバイスが好ましいが、第１のデバイスが例えば据置型コンピュータなどの固定式デバイスであることは、除外されない。
第２のデバイスは、例えば、ロボット、物理デバイス、センサ、カメラ、または、ＩｏＴシステムに適した他の任意のデバイスであってもよい。
いくつかの実施形態では、第２のデバイスは、モノのインターネット（ＩｏＴ）デバイスである。いくつかの実施形態では、第１のデバイスは、無線通信デバイスである。
方法１００は、１１０で始まり、第２のデバイスに関連付けられたエンロールメント機能の表現を取得し１１０、エンロールメント機能は、第１および第２のデバイスに関連付けられたエンロールメント情報を含む少なくとも１つのシリアライズされたエンロールメントアプリケーションに関連付けられる。
エンロールメント機能の表現は、例えば、表現をスキャンすることによって取得するか、そうでなければ、例えばカメラまたは他のセンサを使用して表現をキャプチャすることができる。
エンロールメント機能の表現は、第２のデバイス上に印刷された、または、第２のデバイスのパッケージ内に供給された、または同様のＱＲコードであってもよい。エンロールメント機能の表現は、追加または代替として、例えば、シリアライズされたエンロールメント機能のアナログまたはデジタル格納ができるバーコードまたはＲＦ－ＩＤチップであってもよい。他の表現が可能である。
シリアライズされたエンロールメントアプリケーションに含まれる第１および第２のデバイスに関連付けられたエンロールメント情報は、例えば、第１のデバイスと第２のデバイスとの間の通信をセットアップするための命令、エンロールメント処理が行われることになるという指示、エンロールメント処理のステップ、地理位置、組織の位置、所有権、暗号鍵、通信パラメータ、通信鍵、および識別情報の１つまたは複数に関連付けられた情報、ならびに、資格証明など、どのパラメータがデバイス間で交換されるべきであるかについての情報、等の１つまたは複数を含むことができる。
例えば、上記のパラメータは、両方のデバイス間を流れる情報の組合せを表すことができる。例えば、地理位置、組織の位置、および所有権などの第１のデバイスで生じるさらなるデータは、第１のデバイスによって第２のデバイスに送られ、後者によって格納されたデータであってもよい。
暗号化および通信鍵／パラメータは、エンロールメントアプリケーションの展開中に、すなわち、エンロールメント処理中に、（例えば、ハンドシェイク、通信手段の取り決め等の中で）どちらかの方向にさらに送ることができる。
識別情報は、（製造中にセットされたシリアル番号もしくは一意の識別子の場合）第２のデバイスから第１のデバイスに、または、（人が読める名前もしくは組織内識別子の場合）第１のデバイスから第２のデバイスに、送ることができる。
方法１００は、その後、ステップ１２０において続き、第１のデバイスに関連付けられたエンロールメント情報が、第２のデバイスに関連付けられたエンロールメント情報から分離されるように、エンロールメントアプリケーションをデシリアライズする。
したがって、第１および第２のデバイスは、必ずしも同じエンロールメント情報を受信しなくてもよい。第１のデバイスに関連付けられたエンロールメント情報は、例えば、第１のデバイスが第２のデバイスにどのパラメータを供給するべきであるかについての命令を含むことができる。同じ手法で、第２のデバイスに関連付けられたエンロールメント情報は、エンロールメントが行われるべきであるという命令、ならびに、第２のデバイスが第１のデバイスに供給するべき、第２のデバイスに関連付けられたパラメータおよび／または情報が何であるかについての指令を含むことができる。
パラメータは、情報と同じデータを含むことができ、すなわち、パラメータは情報であってもよく、または逆も同様であり、したがって、本開示では、用語、パラメータは、別途明示的に述べられない場合、用語、情報で置き替えることができることに留意されたい。
いくつかの実施形態では、方法１００は、任意選択として、第１のデバイスと第２のデバイスとの間の通信を可能にするために、第２のデバイスに接続するステップ１３０を含むことができる。
例えば、接続は、例えば、Ｂｌｕｅｔｏｏｔｈ、Ｗｉ－Ｆｉ、ＮＦＣ、および、デバイス間の物理接続またはケーブルによって確立することができる。それでも、このステップは、第２のデバイスに関連付けられたエンロールメント情報に基づく第２のデバイスの設定による、第２のデバイスのエンロールメント処理の、第２のデバイスによる実行を始めるために、第２のデバイスに関連付けられたエンロールメント情報を第２のデバイスに伝送する次のステップ１４０に統合することもできる。
したがって、第２のデバイスに関連付けられたデシリアライズされたエンロールメント情報は、エンロールメント処理を始めること、および（第２のデバイスに）関連付けられたエンロールメント情報によって示されたようなエンロールメント処理を第２のデバイスが実行することを可能にするために、第１のデバイスから第２のデバイスに伝送される。
いくつかの実施形態によれば、第２のデバイスに関連付けられたエンロールメント情報は、第２のデバイスに知られていない。したがって、第２のデバイスに関連付けられたデシリアライズされたエンロールメントアプリケーションに含まれるエンロールメント情報を、第１のデバイスが第２のデバイスに供給しない限り、エンロールメントを行うことができない。
さらに、いくつかの実施形態では、第２のデバイスに関連付けられたエンロールメント情報は、ＩｏＴシステムと通信するための公開暗号鍵、ソフトウェアシステム、ＩｏＴ環境の能力および機能のうちの少なくとも１つを含む。
方法は、その後続き、第２のデバイスに関連付けられた設定情報を第２のデバイスから受信する１５０。
上記で詳しく述べたように、第２のデバイスに関連付けられたエンロールメント情報は、第１のデバイスに知られていない第２のデバイスに関連付けられた一定の設定情報／パラメータを、第２のデバイスが第１のデバイスに供給するべきであるという命令を含むことができる。
第２のデバイスに関連付けられたこのような設定情報は、例えば、第２のデバイスの物理識別情報、および第２のデバイスとの通信のための公開暗号鍵であってもよい。第２のデバイスに関連付けられた情報は、いくつかの実施形態では、第２のデバイスの成功したエンロールメントの承認も含むことができる。
第１のデバイスは、例えば、受信した設定情報を格納することができ、いくつかの実施形態では、ＩｏＴシステムへの第２のデバイスの接続を可能にするために、ＩｏＴシステムに設定情報を中継することができる。
例えば、いくつかの実施形態によれば、中央クラウドサービスに依存するＩｏＴシステムについて、（公開鍵および識別情報などの）必要な通信詳細は、（セキュア）通信を可能にするために、クラウドサービスに転送されてもよい。
いくつかの実施形態では、エンロールメント機能は、少なくとも２つのシリアライズされたエンロールメントアプリケーションを含む、または表すことができる。このような場合、１つのアプリケーションは、第１のデバイスのためのものであってもよく、１つのアプリケーションは、第２のデバイスのためのものであってもよい。
方法は、したがって、いくつかの実施形態では、第１のデバイスに関連付けられたエンロールメント情報を含む少なくとも１つのエンロールメントアプリケーションと、第２のデバイスに関連付けられたエンロールメント情報を含む少なくとも１つのエンロールメントアプリケーションに、少なくとも２つのシリアライズされたエンロールメントアプリケーションをデシリアライズすることをさらに含むことができる。第１のデバイスは、次に、第２のデバイスに関連付けられた少なくとも１つのエンロールメントアプリケーションを第２のデバイスに伝送することができる。
したがって、いくつかの実施形態によれば、エンロールメント機能は、１つのアプリケーション（すなわち、両方のデバイスのための１つの分割されたアプリケーション、もしくは第２のデバイスのためのただ１つ）、または２つのアプリケーション（第１のデバイスのための１つ、および第２のデバイスのための１つ）を収めることができ、いくつかの実施形態では、特定の設定データ（アプリケーションのいずれかの一部でないこともあるアドレス等）も含むことができる。
いくつかの実施形態では、方法は、第２のデバイスが成功裏にエンロールメントしたと判定し、第１のデバイス上の少なくとも１つのエンロールメントアプリケーションを終了すること１６０をさらに含むことができる。
第２のデバイスが成功裏にエンロールメントしたという判定は、例えば、成功したエンロールメントについての、第２のデバイスから受信した指示に基づいてもよい。いくつかの実施形態では、成功したエンロールメントについての指示は、第２のデバイスから受信し、第２のデバイスに関連付けられた情報に含まれてもよい。
したがって、方法１００は、いくつかの実施形態による、例えば、ＩｏＴデバイスがＩｏＴシステムにエンロールメントすることを始め、支援するためのステップを説明している。
さらに、図１６９は、第１のデバイスによって始められ、支援されるモノのインターネット（ＩｏＴ）環境へのエンロールメント処理を実行するための、第２のデバイスの実例の方法２００を示す。
第１および第２のデバイスは、例えば、図１６８に関連して説明されたような、第１および第２のデバイスであってもよい。
方法２００は、２１０で始まり、第２のデバイスに関連付けられたエンロールメント情報を第１のデバイスから受信する２１０（方法１００のステップ１４０に似ている）。エンロールメント情報は、少なくとも１つのデシリアライズされたエンロールメントアプリケーションから生じてもよく、エンロールメントアプリケーションは、方法１００による第１のデバイスによってデシリアライズされていてもよい。
いくつかの実施形態では、方法２００は、エンロールメント情報がエンロールメント処理を実行するためのものであると判定すること２２０をさらに含むことができる。
第２のデバイスは、例えば、特定の命令または信号を受信したときに始めることができる種々の機能および処理を備えることができる。第２のデバイスは、例えば、エンロールメント処理を実行するための正しいエンロールメント情報を受信したときだけ利用されるエンロールメントのための機能を備えることができる。
このステップは、それでも、第２のデバイスがエンロールメント情報を受信したとき、自動的に実施することもでき、すなわち、エンロールメント情報を受信することによって、エンロールメント処理を自動的にトリガすることができ、ステップ２２０は、したがって、本方法２００では暗黙的なものであるとみなすことができる。
方法２００は、その後続き、エンロールメント情報に基づいて第２のデバイスを設定することによってエンロールメント処理を実行する２３０。
第２のデバイスは、例えば、既に、エンロールメント処理に少なくとも部分的にアクセスできてもよいが、第１のデバイスによって供給することができる一定の情報またはパラメータを欠いていることがある。第２のデバイスは、例えば、上述のように、エンロールメントのための機能で製造時に設定されていてもよく、この機能は、エンロールメント中にデバイスによって行われるべきいくつかのステップを含むことができるが、例えば、一定の必要なパラメータまたはステップについての情報を欠いていることがある。
エンロールメント情報は、したがって、エンロールメント処理が展開されるまで第２のデバイスに知られていない情報を含むことができる。このような情報は、例えば、例えば、地理位置、組織の位置、ゲートウェイ資格証明、およびＩｏＴシステムとの通信のための（公開）暗号鍵、ならびに、第１のデバイスから第２のデバイスに送り、後者によって格納することができる所有権などの、第１のデバイスで生じた情報に関係していてもよい。
いくつかの実施形態では、第２のデバイスに関連付けられたエンロールメント情報は、公開暗号鍵、ソフトウェアシステム、ＩｏＴ環境の能力および機能の少なくとも１つを含む。
いくつかの実施形態では、第２のデバイスに関連付けられたエンロールメント情報は、第２のデバイスに知られていない。したがって、第１のデバイスによって始められない限り、エンロールメントを行うことができない。
方法２００は、その後、続けることができ、第２のデバイスに関連付けられた設定情報を第１のデバイスに伝送する２４０（方法１００のステップ１５０に似ている）。
第１のデバイスに伝送された第２のデバイスに関連付けられた設定情報は、例えば、第２のデバイスの物理識別情報、および第２のデバイスとの通信のための公開暗号鍵の１つまたは複数であってもよい。第２のデバイスに関連付けられた設定情報は、いくつかの実施形態では、第２のデバイスの成功したエンロールメントの承認も含むことができる。
いくつかの実施形態では、方法２００は、エンロールメントが成功したと判定し、場合によっては、例えば、第２のデバイスからエンロールメント情報を削除することによって、エンロールメントアプリケーションを終了すること２５０をさらに含むことができる。
エンロールメント処理のセキュリティをさらに強化し、データの将来の改ざんを妨げるために、第２のデバイスは、例えば、ヒューズを飛ばす（ｂｌｏｗ ａ ｆｕｓｅ）こと、または他の手法で、これを再設定する可能性を削除することができる。
さらに、第１のデバイスに伝送された第２のデバイスに関連付けられた情報は、いくつかの実施形態では、第２のデバイスの成功したエンロールメントの承認も含むことができる。
図１７０は、いくつかの実施形態による方法１００および２００の実行を概略的に示す。
エンロールメント機能３３０の表現は、少なくとも１つのシリアライズされたエンロールメントアプリケーション３００を含み、次に、エンロールメントアプリケーション３００は、第１のデバイス３１０および第２のデバイス３２０にそれぞれ関連付けられたエンロールメント情報３０１、３０２を含む。第１および第２のデバイスは、例えば、図１６９および図１７０のいずれかに関連して説明されるような、第１および第２のデバイスであってもよい。
この例では、エンロールメント機能の表現は、ＱＲコードである。しかし、バーコード、数字のシーケンス、ＲＦ－ＩＤチップ等などの、他の表現が可能である。
第１のデバイスは、例えば、スキャナもしくはカメラを使用してスキャンすること、または、表現を検出、獲得、もしくはキャプチャするための他の手段によって、エンロールメント機能の表現を取得する。
第１のデバイス３１０は、次に、第１のデバイス３１０に関連付けられたエンロールメント情報３０１が、第２のデバイス３２０に関連付けられたエンロールメント情報３０２から分離されるように、エンロールメントアプリケーションをデシリアライズすることができる（方法１００のステップ１２０に似ている）。
いくつかの実施形態では、第１のデバイスは、第２のデバイスに関する追加の設定情報を外部データベース３１１からさらに取得することができ、いくつかの実施形態では、前記外部ストレージデータベース３１１から前記追加の設定データを取得するように、エンロールメントアプリケーションによってさらに促すことができる。
第１のデバイスは、第１のデバイスに関連付けられたエンロールメント情報３０１を保存し、第２のデバイス３２０に関連付けられたエンロールメント情報３０２を第２のデバイス３２０に伝送する（方法１００および２００のステップ１４０および２１０にそれぞれ似ている）。
エンロールメント機能は、２つ以上のシリアライズされたアプリケーションを含むことができることに留意されたい。２つ以上のシリアライズされたアプリケーションの場合、第１のデバイスおよび第２のデバイスは、１つのアプリケーションにそれぞれ関連付けられてもよく、第１のデバイスは、第１のデバイスのための１つのアプリケーション、および第２のデバイスのための１つのアプリケーションに、アプリケーションをデシリアライズすることができる。
単一のシリアライズされたアプリケーションの場合、第１のデバイスは、第１のデバイスに関する情報に、および第２のデバイスに関する情報に、アプリケーションをデシリアライズすること、すなわち、２つのデバイス上のアプリケーションを分割することができる。いくつかの実施形態では、１つのシリアライズされたアプリケーションの場合、単一のアプリケーションは、第２のデバイスだけのためのものであってもよい。
第２のデバイスは、今度は、異なる処理に関連付けることができるいくつかの機能を含むことができる。この例では、第２のデバイスは、機能＃１～＃４、３２１、３２２、３２３、および３２４をそれぞれ備えることができる。これらの機能は、製造中に第２のデバイスに設定／追加されていてもよい。
この特定の例では、エンロールメント機能情報３３０の表現は、機能＃３、２２３に対応する。したがって、第２のデバイスが、デシリアライズされた情報を受信したとき、機能＃３が始められるべきであると判定することになる。この場合、機能＃３は、エンロールメント処理である（方法２００のステップ２２０に似ている）。
機能＃３は、いくつかのエンロールメントステップを含むことができるが、デシリアライズされたエンロールメントアプリケーションから取得され、第２のデバイス３２０によって受信したエンロールメント情報の中で提供することができる情報を欠いていることがある、例えば方法１００および２００に似ている。
第２のデバイスは、次に、受信したエンロールメント情報によるエンロールメントを実施することができる。いくつかの実施形態では、第１のデバイスも、それ自体を設定するために、第１のデバイスに関連付けられたエンロールメント情報、および、第２のデバイスから受け取り、第２のデバイスに関連付けられた情報を使用することができる。
第２のデバイスの他の機能も、エンロールメントのために使用できることに留意されたい。したがって、エンロールメント機能は、単一の機能（例えば機能＃３）を含むわけではないが、第２のデバイス上の他の機能の１つまたは複数を含む命令であってもよいことを理解されたい。例えば、エンロールメント情報は、例えば、パラメータａ、ｂを使用して機能＃１を実行すること、および、パラメータｘ、ｙを使用して機能＃４を実行すること、等を行うように第２のデバイスに命じる命令を含むことができ、機能＃１および＃４は、事前に存在する機能である。
方法１００および２００は、第２のデバイスのエンロールメントを可能にするために、第１のデバイスおよび第２のデバイスによってそれぞれ実施されるとき、密接に関連していることに留意されたい。したがって、方法１００および２００は、いくつかの実施形態では、図１７１で示したような、１つの方法４００に結合することができる。
図１７１では、第１のデバイス（ＤＥＶ１）４０１、および第２のデバイス（ＤＥＶ２）４０２は、互いに通信することができる。第１のデバイス４０１および第２のデバイス４０２は、例えば、図１～図３のいずれかに関連してそれぞれ説明されたような、第１および第２のデバイスであってもよい。同じ手法で、方法４００は、前述のように、方法１００および２００の組合せであってもよい。
方法４００は、４１０でスタートし、ここで、第１のデバイス４０１は、第２のデバイス４０２に関連付けられたエンロールメント機能の表現を取得する（方法１００のステップ１１０に似ている）。表現は、例えば、ＱＲコード、バーコード、または同様のものの１つまたは複数であってもよい。表現は、例えば、スキャンまたはＮＦＣリーダの他の適切な手段を通じて取得することができる。
エンロールメント機能の表現は、少なくとも１つのシリアライズされたエンロールメントアプリケーション含むか、これに関連付けられ、エンロールメントアプリケーションは、第１のデバイスおよび第２のデバイスそれぞれに関連付けられたエンロールメント情報を含むことができる。シリアライゼーションは、限定的な空間を使用して表現内に大量データを格納できるようにする。
表現は、いくつかの実施形態では、第２のデバイスに格納することができる。バーコードは、例えば、第２のデバイスの筐体に印刷されてもよく、または、例えば１枚の紙に供給することができ、第２のデバイスのパッケージの一部であってもよい。いくつかの実施形態では、例えばインターネットから、表現を検索することも可能であってもよい。
第１のデバイスがエンロールメント機能の表現を取得すると、方法は、４１１において続き、ここで、第１のデバイスは、情報のデジタル表現を抽出すること、および、第２のデバイスに関連付けられたエンロールメント情報からの第１のデバイスに関連付けられたエンロールメント情報を分離することを行うために、シリアライズされたエンロールメントアプリケーションをデシリアライズする（方法１００のステップ１２０に似ている）。
エンロールメント機能は、いくつかの実施形態では、第１または第２のデバイスに関する情報の異なるブロックにデシリアライズされた単一のシリアライズされたエンロールメントアプリケーションを備えることができる。いくつかの実施形態では、エンロールメント機能は、２つ以上のシリアライズされたエンロールメントアプリケーションを備えることができ、２つ以上のエンロールメントアプリケーションは、第１のデバイスのための１つまたは複数のアプリケーション、および、第２のデバイスのための１つまたは複数のアプリケーションにデシリアライズすることができる。
いくつかの実施形態では、単一のアプリケーションの場合、単一のアプリケーションは、全面的にデバイスの１つのためのものであってもよい。
取得後、方法４００は、通信のために、第１のデバイスと第２のデバイスとの間の接続を確立することを含むことができる（第１のデバイスと第２のデバイスとの間の破線矢印で示されるようなものであり、方法１００のステップ１３０に似ている）。接続は、例えば、Ｂｌｕｅｔｏｏｔｈ接続、ＮＦＣ、もしくはＷｉ－Ｆｉを通じて、または、ケーブルによって確立することができ、インターネットまたはネットワークアクセスを必ずしも必要としない。
接続は、方法の分離したステップとして始めることができ、または、表現を取得した後、自動的に実施またはトリガすることができる。接続は、したがって、デシリアライズされたエンロールメントアプリケーションから抽出された第２のデバイスに関連付けられたエンロールメント情報を第２のデバイスに伝送するという次のステップ４１２に、暗黙的なアクションとして統合することができる（方法１００のステップ１４０に似ている）。
エンロールメントアプリケーションに含まれるエンロールメント情報は、エンロールメント処理の展開の前に、ある程度、デバイスに知られていなくてもよい。したがって、エンロールメント機能の表現は、情報で以前に設定されていなかったとき、第２のデバイスが認識していない、例えば第２のデバイスに関連付けられたエンロールメント情報を含むことができる。
例えば、このようなエンロールメント情報は、例えば、第１のデバイスに、または、第２のデバイスがエンロールメントすることになるＩｏＴシステムに、関連付けられた資格証明であってもよい。ＩｏＴシステムにおける他のデバイスまたはサービスと通信するために必要な例えば資格証明、および、所有権、位置（例えばＧＰＳ座標もしくはアドレス）、第２のデバイスの人が読める名前、または、エンロールメントの時間の前に知られていない他の情報など。他のこのような情報は、例えば、第２のデバイスの地理位置、組織の位置、および所有権であってもよい。
方法４００のステップ４２０では、第２のデバイスは、デシリアライズされたエンロールメントアプリケーションに含まれる第２のデバイスに関連付けられたエンロールメント情報を受信する（方法２００のステップ２１０に似ている）。この受信は、エンロールメント処理を第２のデバイスが始めることをトリガすることができる（例えば、図１６９、および方法２００のステップ２２０～２３０に似ている）。
したがって、方法４００のステップ４２１では、第２のデバイスは、受信したエンロールメント情報に基づいてエンロールメント処理を実行する（方法２００のステップ２３０に似ている）。
エンロールメント処理中、第１のデバイスと第２のデバイスとの間で、さらなるデータを交換することができ、このようなデータは、例えば、暗号鍵、資格証明、デバイスの識別情報等であってもよい。
第２のデバイスは、例えば、ステップ４２２において、第２のデバイスに関連付けられた情報を第１のデバイスに伝送することができる（方法２００のステップ２４０に似ている）。このような情報は、例えば、公開暗号鍵、ソフトウェアバージョン、第２のデバイスに関連付けられた能力および機能、等であってもよい。
第２のデバイスは、エンロールメントが成功したという指示または承認も第１のデバイスに伝送することができる。
方法４００のステップ４１３において、第１のデバイスは、第２のデバイスに関連付けられた情報を第２のデバイスから受信する（方法１００のステップ１５０に似ている）。第１のデバイスは、例えば、ＩｏＴシステムへの第２のデバイスの接続を可能にするために、この情報を格納し、ＩｏＴシステムに中継することができる。
次に、エンロールメントが成功した後、ステップ４１４および４２３において、第１および第２のデバイスは、それ自体のエンドでそれぞれエンロールメントアプリケーションを終了することができる（方法１００および２００のステップ１６０および２５０にそれぞれ似ている）。セキュリティをさらに強化するために、エンロールメントを完了すると、第２のデバイスは、例えば、データのさらなる改ざんを妨げるヒューズを焼くか、エンロールメント機能を完全に削除することができる。
エンロールメント情報は、エンロールメントが完了したときに何のアクションが行われるべきかについての、第２のデバイスへの命令を含むことができ、または、第２のデバイスは、既に、これらのステップを事前設定されていてもよいことが想定される。
第１のデバイスは、第２のデバイスのエンロールメント処理中に設定することができることも想定される。これは、第１のデバイスがＩｏＴシステムの一部であり、第２のデバイスの知識を維持しなければならないときのケースであってもよい。第１のデバイスは、このようなケースでは、シリアライズされたエンロールメントアプリケーションに含まれるエンロールメント情報、および、エンロールメント処理の実行中に第２のデバイスから受信した情報に基づいて、第１のデバイス自体を設定することができる。これは、例えば、ＩｏＴシステムとの通信のために第２のデバイスが利用するゲートウェイとして、第１のデバイスが機能するときのケースである。
本明細書で説明される第１および第２のデバイスは、典型的には、物理デバイスであるが、いくつかの実施形態では、第１のデバイスは、第２のデバイスより多くのコンピューティングリソースを備える。それでも、第１のデバイスと第２のデバイスの両方がＩｏＴデバイスであってもよいことに留意されたい。
図１７２は、いくつかの実施形態による、モノのインターネット（ＩｏＴ）環境への第２のデバイスのエンロールメント処理を始め、支援するための第１のデバイスの実例の配置５００を示す。
本開示では、用語、配置は、例えば、統合された、または除去できるように取り付けられた、構成要素を伴う回路基板などの、アグリゲートされた構成要素のシステムとして解釈されるべきであるということに留意されたい。用語、配置は、例えば、用語、システムによって置き替えることができる。
第１のデバイスは、例えば、図１６８～図１７１のいずれかに関連して説明されるような第１のデバイスであってもよい。第２のデバイスは、例えば、図１６８～図１７１のいずれかに関連して説明されるような第２のデバイスであってもよい。
配置５００は、図１６８～図１７１のいずれかに関連して説明されるような方法を実行するようにさらに設定することができる。
配置５００は、制御回路機器（ＣＮＴＲ；例えばコントローラ）５２０、およびトランシーバ回路機器（ＲＸ／ＴＸ；例えばトランシーバ）５１０を備える。いくつかの実施形態では、制御回路機器は、取得回路機器（ＯＢ；取得モジュール）５２３、デシリアライズ回路機器（ＤＥＳＥＲ；例えばデシリアライザ）５２２、および判定回路機器（ＤＥＴ；例えば判定器）５２１をさらに備えることができる。
トランシーバ回路機器５１０は、いくつかの実施形態では、分離した送信機および分離した受信機であってもよい。
制御回路機器５２０は、第２のデバイスに関連付けられたエンロールメント機能の表現を、例えば取得回路機器５２３に行わせることによって、取得を行うように設定することができ、エンロールメント機能は、第１および第２のデバイスに関連付けられたエンロールメント情報を含む少なくとも１つのシリアライズされたエンロールメントアプリケーションに関連付けられる（方法１００のステップ１１０に似ている）。
取得回路機器は、例えば、携帯電話に供給されたカメラを備えることができる。取得回路機器５２３は、いくつかの実施形態では、画像またはチップまたは同様のものに含まれる情報を取得またはキャプチャするのに適した任意の回路機器／手段であってもよい。
制御回路機器５２０は、第１のデバイスに関連付けられたエンロールメント情報が、第２のデバイスに関連付けられたエンロールメント情報から分離されるように、エンロールメント機能情報を、例えばデシリアライズ回路機器５２２に行わせることによって、デシリアライズを行わせるようにさらに設定することができる（方法１００のステップ１２０に似ている）。
制御回路機器５２０は、第１のデバイスと第２のデバイスとの間の通信が可能になるように、例えばトランシーバ回路機器が第２のデバイスに信号を送ることによって、第２のデバイスへの接続を行うようにさらに設定することができる（方法１００のステップ１３０に似ている）。
制御回路機器５２０は、第２のデバイスに関連付けられたエンロールメント情報に基づく第２のデバイスの設定によって、第２のデバイスのエンロールメント処理の第２のデバイスによる実行を始めるために、例えばトランシーバ回路機器５１０が第２のデバイスに信号を送ることによって、第２のデバイスに関連付けられたエンロールメント情報を第２のデバイスに伝送するようにさらに設定することができる（方法１００のステップ１４０に似ている）。
エンロールメント処理の実行中および／または実行後、制御回路機器は、例えばトランシーバ回路機器が受信することによって、第２のデバイスに関連付けられた設定情報の第２のデバイスからの受信を行うようにさらに設定することができる（方法１００のステップ１５０に似ている）。
いくつかの実施形態では、制御回路機器５２０は、例えば第２のデバイスからの情報の受信に基づいて、エンロールメント処理が実行されているか、完了したという判定を、例えば判定回路機器５２１が行うことによって、行うようにさらに設定することができる。制御回路機器は、次に、（例えば図５に示していないメモリに）第２のデバイスから受信した情報を格納すること、および、ＩｏＴシステムへの情報を中継することを行うように設定することができる。
いくつかの実施形態では、制御回路機器５２０は、例えば、第２のデバイスのエンロールメントが完了したと判定したとき、および／または、第１のデバイスに関連付けられたエンロールメント情報を含むデシリアライズされたエンロールメントアプリケーションに基づいて、第１のデバイス自体の設定を第１のデバイスが実施したとき、エンロールメントアプリケーションを終了するようにさらに設定することができる（方法１００のステップ１６０に似ている）。
配置５００は、例えば、無線通信デバイスに含まれてもよい。無線通信デバイスは、例えば、携帯電話、スマートフォン、サーフパッド、ラップトップコンピュータ、ハンドヘルドコンピュータ、または同様のものであってもよい。配置５００は、いくつかの実施形態では、カメラ、ロボット、センサ等などのＩｏＴデバイスにも含まれてよい。
図１７３は、モノのインターネット（ＩｏＴ）環境へのエンロールメント処理を実行するための、および、第１のデバイスによって支援される第２のデバイスの配置６００を示す。
第１および第２のデバイスは、それぞれ、例えば、図１６８～図１７２のいずれかに関連して説明される第１および第２のデバイスであってもよい。
配置６００は、図１７２および配置５００に関連して説明されるものと同じまたは同様の特徴とさらに組み合わせるか、特徴を備えることができることに留意されたい。
配置６００は、例えば、図１６８～図１７１のいずれかに関連して説明されるような方法を実行するように設定することができる。
配置６００は、制御回路機器（ＣＮＴＲ；例えばコントローラ）６２０、およびトランシーバ回路機器（ＲＸ／ＴＸ；例えばトランシーバ）６１０を備えることができる。トランシーバ回路機器６１０は、いくつかの実施形態では、分離した送信機および分離した受信機であってもよく、ならびに／または複数のアンテナを備えてもよい。
制御回路機器６２０は、いくつかの実施形態では、機能回路機器（ＦＵＮＣ；例えば機能モジュール）６２２、および判定回路機器（ＤＥＴ；例えば判定器）６２１をさらに備えることができる。
制御回路機器６２０は、いくつかの実施形態では、第２のデバイスに関連付けられたエンロールメント情報の第１のデバイスからの受信を、例えばトランシーバ回路機器６１０に行わせることによって、行うように設定することができる（方法２００のステップ２１０に似ている）。
いくつかの実施形態では、制御回路機器６２０は、エンロールメント情報がエンロールメント処理を実行するためのものであるという判定を、例えば判定回路機器６２１に行わせることによって行うようにさらに設定することができる（方法２００のステップ２２０に似ている）。
いくつかの実施形態では、制御回路機器６２０は、エンロールメント情報に基づいて第２のデバイスを設定することによってエンロールメント処理の実行を、例えば機能回路機器６２２に行わせることによって、行うこと（方法２００のステップ２３０に似ている）、および、例えばトランシーバ回路機器６１０が第１のデバイスに伝送することによって、第１のデバイスへの第２のデバイスに関連付けられた設定情報の伝送を行うこと（方法２００のステップ２４０に似ている）、を行うようにさらに設定することができる。
いくつかの実施形態では、制御回路機器６２０は、エンロールメント／設定が完了したときにエンロールメントアプリケーションを終了するようにさらに設定することができる（方法２００のステップ２５０に似ている）。
配置６００は、いくつかの実施形態では、モノのインターネット（ＩｏＴ）デバイス内に含まれてもよい。このようなデバイスは、例えば、ロボット、台所用品、カメラ、センサ、交通信号灯、機械等であってもよい。
本明細書で説明される実施形態による長所は、実行可能アプリケーションが、例えばＱＲコードとして符号化され、ＩｏＴデバイスと一緒に配布されることである。ＩｏＴデバイスを登録するとき、アプリケーションは、ＩｏＴデバイス上、および、例えば、ＩｏＴデバイスのエンロールメントのために使用される携帯電話といった別のデバイス上に、分散型アプリケーションとしてデコードされ、展開される。本明細書で開示された実施形態は、したがって、中央サーバ／ソフトウェアのリポジトリに依存しない。
さらに、本明細書における実施形態は、例えば、インターネット、または、登録デバイスとの通信手段（例えばＢｌｕｅｔｏｏｔｈ、ＮＦＣ、Ｗｉ－Ｆｉ等など）以外の他の任意の接続へのアクセスを必要としない、デバイスの簡単な自動登録、設定、およびエンロールメントを可能にする。
さらに、エンロールメントされることになるデバイスは、エンロールメントのための全ての必要情報で事前設定されるわけではないので、セキュリティが強化される。
説明した実施形態およびその同等物は、ソフトウェアもしくはハードウェアまたはその組合せで実現することができる。これらは、デジタル信号プロセッサ（ＤＳＰ）、中央処理装置（ＣＰＵ）、コプロセッサユニット、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、もしくは他のプログラム可能ハードウェアなどの通信デバイスに関連付けられたもしくは統合された汎用回路によって、または、例えば特定用途向け集積回路（ＡＳＩＣ）などの特殊回路によって、実施することができる。全てのこのような形が、本開示の範囲内にあるものと想定される。
実施形態は、回路機器／ロジックを備えるか、実施形態のいずれかによる方法を実施する、（無線通信デバイスなどの）電子装置内に現れてもよい。電子装置は、例えば、携帯型もしくはハンドヘルドモバイル無線通信機器、モバイル無線端末、携帯電話、基地局、基地局コントローラ、ポケットベル、通信器、電子オーガナイザ、スマートフォン、コンピュータ、ノートブック、ＵＳＢスティック、プラグインカード、組込型ドライブ、またはモバイルゲーミングデバイスであってもよい。
転送されたコードモジュールを使用したセキュアなデバイス動作
デバイスの機能を使用するために、ローカルであるかネットワーク上であるかに関わらず、ユーザは、典型的には、このデバイスで認証しなければならない。認証されると、ユーザは、次に、デバイスを使用して、１つまたは複数の機能を実施することができる。
認証は、デバイスで認識された一定の資格証明を提供することによって実施されることが多い。例えば、ユーザは、パスワードを提供することができ、または、アプリケーションは、デジタル鍵を提供することができる。パスワードまたは鍵が盗まれるか偽造されると、デバイスのセキュリティは、危険にさらされる恐れがある。このようなデバイスが危険にさらされると、任意の数のデバイスの機能が活用される恐れがある。一般に、悪意のあるユーザがますます高度化すると、デバイスをセキュアにするための新しくより良い技法を考案するという、開発者に対する継続する圧力を作り出してきた。
本開示の実施形態は、従来のアプローチとは異なったようにデバイス機能を起動する。ほんの一例として、スマートロックが、アンロック機能をサポートするランタイム環境を実行する。アンロック機能にアクセスするために、別のデバイス（例えば、ユーザのスマートフォン）は、スマートロックにコードモジュールを転送するための権限を取得する。コードモジュールは、スマートロックのランタイム環境内で実行し、（例えば無線通信を介して）ユーザのスマートフォンにアンロック機能を露出するように設定される。アンロック機能をユーザのデバイスに露出すると、ユーザのデバイス上のランタイム環境内で動くアプリケーションは、コードモジュールを介してアンロック機能を起動することができる。
特定の実施形態によれば、このようなシステムは、侵入に対して丈夫である。例えば、いくつかの方式で、上記で論じたスマートロックが危険にさらされたとしても、コードモジュールのない状態では、アンロック機能を容易に起動するための方式がない可能性がある。追加または代替として、ユーザのデバイスにダウンロードされた悪意のあるソフトウェアエージェントは、スマートロックと、ユーザデバイスのランタイム環境との間で交換された資格証明を傍受できない可能性がある。他の長所が下記で論じられ、または、第１のデバイスが第２のデバイスを使用する他の実施形態とともに当業者には明らかであろう。
本開示の実施形態は、別のデバイスにデバイスの機能を露出するコードモジュールを含む。コードモジュールは、機能をリモートに起動できるように、ランタイム環境の間で無線通信を介してセキュアに転送される。この転送は、互いの近くに来たデバイスによってトリガすることができる。コードモジュールを転送するための権限は、デバイスによって使用される何らかの特定のセキュリティ方式をリモートアプリケーションがサポートする必要がないように、ランタイム環境の間で扱われる。機能は、コードモジュールのない状態でリモート起動を介してアクセスできなくすることができ、コードモジュールは、例えば、他のデバイスが権限のない機能を起動するのを防ぐために、機能が起動された後、および／または、デバイスがもはや近くにいなくなると、削除するか、返すことができる。
いくつかの実施形態では、デバイスは、分散型モノのインターネット（ＩｏＴ）システムの一部である。このようなシステムの例は、カルバンアプリケーション環境に基づくことができる。このようなカルバンベースのシステムでは、アプリケーションは、デバイスに結びつけられたランタイム上で実行する（行為者と呼ばれることもある）機能ブロックから構築することができる。実施形態によれば、行為者は、特定のデバイス上でデバイスの機能を実行するために、必要に応じてランタイムの間を移動することができる。
図１７４は、第１のデバイス１１０および第２のデバイス１１５を含む実例のネットワーク環境１００を示す。第１のデバイス１１０および第２のデバイス１１５は、両方、（例えば、無線で、ポイントツーポイント接続を介して）互いに通信接続され、信号を交換する。いくつかの実施形態では、第１のデバイス１１０および／または第２のデバイス１１５は、ネットワーク１０５に接続され、リモートデバイス１４５と、および／または互いに、ネットワーク１０５を介して通信するように設定される。したがって、第１および第２のデバイス１１０、１１５は、それぞれ、例えば、近距離無線通信（ＮＦＣ）、Ｗｉ－Ｆｉ、ＢＬＵＥＴＯＯＴＨ、ＺＩＧＢＥＥ、Ｌｏｎｇ－Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ（ＬＴＥ）、新無線（Ｎｅｗ Ｒａｄｉｏ）（ＮＲ）、イーサネットなどの、１つまたは複数の互換技術を介して、有線および／または無線通信をサポートすることができる。
第１および第２のデバイス１１０、１１５は、第１および第２のランタイム環境１２０、１２５をそれぞれ実行する。第１のデバイス１１０の第１のランタイム環境１２０は、例えば、第１のデバイス１１０の無線送信機を制御することによって、第２のデバイス１１５の第２のランタイム環境１２５にコードモジュール１４０を転送するように設定される。これに対応して、第２のデバイス１１５は、例えば、第２のデバイス１１５の無線受信機を能動的に制御することによって、または、第１のデバイス１１０によって第２のデバイス１１５のメモリに書き込むことを受動的に許可することによって、第１のランタイム環境１２０から第２のランタイム環境１２５にコードモジュール１４０を転送するように設定される（例えば、第１のデバイス１１０からのＲＦ送信をメモリ書込命令にコンバートする回路を使用し、このような回路は、いくつかの実施形態では、これらの送信のＲＦエネルギーで動く）。
コードモジュール１４０は、第２のランタイム環境１２５内で実行し、第２のランタイム環境１２５によってサポートされる第２のデバイス１１５の機能を第１のデバイス１１０に露出するように設定される。下記でさらに論じられるように、第１のデバイス１１０の第１のランタイム環境１２０内で実行するアプリケーション１３０は、転送されたコードモジュール１４０および第２のランタイム環境１２５を介して、第２のデバイス１１５の機能を起動する。
第１のデバイス１１０の典型的な例は、スマートフォン、ユーザ機器、ラップトップコンピュータ、タブレット型コンピュータ、および／またはウェアラブルコンピュータなどのモバイルデバイスを含む（がこれらに限定されない）。第２のデバイス１１５の典型的な例は、コンピュータおよび／またはスマートアプライアンスを含む（がこれらに限定されない）。第１および第２のデバイス１１０、１１５の他の例は、他のタイプのコンピューティングデバイスを含む。
ネットワーク１０５は、第１および／または第２のデバイス１１０、１１５と通信信号を交換することができる１つまたは複数の物理デバイスおよび／または信号媒体を含む。このようなネットワーク１０５の例は、インターネット（もしくはその一部）、１つもしくは複数のローカルエリアネットワーク、１つもしくは複数の無線ネットワーク、１つもしくは複数のセルラネットワーク、１つもしくは複数のインターネットプロトコルベースのネットワーク、１つもしくは複数のイーサネットネットワーク、１つもしくは複数の光ネットワーク、および／または、１つもしくは複数の回線交換型ネットワークの、１つまたは複数を含む（がこれらに限定されない）。このようなネットワーク１０５は、このような通信信号の交換をサポートするルータ、ゲートウェイ、スイッチ、ハブ、ファイアウォール等（図示せず）などの、任意の数のネットワーキングデバイスを備えることができる。
リモートデバイス１４５は、第１および／または第２のデバイス１１０、１１５にネットワーク１０５を介して通信連結された任意のコンピューティングデバイスであってもよい。リモートデバイス１４５は、例えば、異なる能力のものを除いて、第１のデバイス１１０として機能することができる。例えば、リモートデバイス１４５は、例えば、第２のデバイス１１５への物理的にセキュアなまたは暗号化されたネットワーク接続を介するなど、ネットワーク１０５を介して、第２のデバイス１１５にセキュアにアクセスできるアドミニストレータワークステーションであってもよい。したがって、リモートデバイス１４５のユーザは、例えば、第１のデバイス１１０のユーザを支援するために、第２のデバイスにコードモジュール１４０も転送すること、および、特定の機能を起動することによって、第２のデバイス１１５の同じおよび／または異なる機能を起動できてもよい。リモートデバイス１４５の典型的な例は、ワークステーション、パーソナルコンピュータ、ラップトップコンピュータ、および／またはタブレット型コンピュータを含む（がこれらに限定されない）。
図１７５は、上記で論じられた態様に一致した、モバイルデバイス２１０とスマートロック２１５との間の実例のコールフローを示す。図１７５の例では、モバイルデバイス２１０は、第１のデバイス１１０の例であり、スマートロック２１５は、第２のデバイス１１５の例である。図１７５は、モバイルデバイス２１０とスマートロック２１５が相互作用する特定の例を示すが、代替実施形態は、下記で説明される機能以外の機能にセキュアにアクセスするために、第１および／または第２のデバイス１１０、１１５として機能する他のデバイスを含んでもよい。
図１７４の全体的な議論に一致して、図１７５に示されたモバイルデバイス２１０は、モバイルランタイム環境２２０を実行する。ロック制御ソフトウェア２３０は、例えば、サービスとして、または、モバイルデバイス２１０のユーザによって起動されるのに応答して、モバイルランタイム環境２２０内で実行する。スマートロック２１５は、スマートロックランタイム２２５を実行する。スマートロックランタイム２２５は、例えば、スマートロック２１５をロックおよびアンロックする、ロック制御動作をサポートする。それでも、スマートロックランタイム２２５は、この例ではモバイルデバイス２１０によって提供されるコードモジュール１４０のない状態での、これらの動作のリモート起動を許可しない。
図１７５に示されている例によれば、モバイルおよびスマートロックランタイム環境２２０、２２５のそれぞれは、例えば、他のデバイスによって生み出された無線周波数（ＲＦ）エネルギーを検知することによって互いに検出する（ステップ２５０）。いくつかの実施形態では、デバイス２１０、２１５のどちらか一方または両方は、例えば、対応するセンサおよび／または受信機を介した光学および／または聴覚検出といった、追加のまたは代替の近接検出技術を使用して、互いに検出することができる。
互いに検出することに応答して、モバイルおよびスマートロックランタイム環境２２０、２２５は、認証手順に関与する（ステップ２５２）。この認証手順は、スマートロック２１５の一定の保護された機能（例えばアンロック機能）をモバイルデバイス２１０が使用するのを許可されるか否かをスマートロックランタイム環境２２５が判定することができる１つまたは複数の資格証明の交換を含むことができる。具体的には、この認証手順の実施によって、モバイルおよびスマートロックランタイム環境２２０、２２５の間の信頼関係を確立することができる。
認証が成功した後、モバイルランタイム環境２２０は、スマートロックランタイム環境２２５にコードモジュール１４０を転送する（ステップ２５４）。コードモジュール１４０は、スマートロックランタイム環境２２５内で実行し、スマートロック２１５のアンロック機能をモバイルデバイス２１０に露出するように設定される。
ロック制御ソフトウェア２３０は、次に、例えば、ファンクションコール「ｍｏｄｕｌｅ．ｕｎｌｏｃｋ（）」で図１７５に表されたような、コードモジュール１４０のアプリケーションプログラミングインターフェース（ＡＰＩ：Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）への適切なファンクションコールを使用して、転送されたコードモジュール１４０を介してスマートロック２１５のアンロック機能を起動する（ステップ２５６）。特に、ロック制御ソフトウェア２３０は、信頼関係が確立された資格証明を必要とする状態で、アンロック機能を起動するために、モバイルおよびスマートロックランタイム環境２２０、２２５の間で確立された信頼関係を利用することができる。これは、例えば、一定のアプリケーションへの機密の資格証明の提供を回避する際に、有利になり得る。具体的には、実施形態は、アプリケーションがいずれかのデバイス２１０、２１５の資格証明を取得できるようになるという懸念のない状態で、第三者のおよび／または信頼できないアプリケーションをユーザが自由にダウンロードして使用し、機能の起動を可能にすることができる。
コードモジュール１４０は、ファンクションコール「ｒｕｎｔｉｍｅ．ｕｎｌｏｃｋ（）」（ステップ２５８）によって図１７５に表された、スマートロックランタイム環境によってサポートされるＡＰＩを対応して起動することによって、「ｍｏｄｕｌｅ．ｕｎｌｏｃｋ（）」ファンクションコールをハンドリングするために、スマートロックランタイム環境２２５内で実行する。このように、図１７５に示された実施形態によれば、コードモジュール１４０は、数あるものの中でも、モバイルデバイス２１０上のロック制御ソフトウェア２３０と、スマートロック２１５のアンロック機能を制御するスマートロックランタイム環境２２５との間の変換レイヤとしてサーブすることができる。コードモジュール１４０からのアンロックファンクションコールに応答して、スマートロックランタイム環境２２５は、スマートロック２１５を適宜制御することによって、すなわち、スマートロック２１５をアンロックすることによって、応答する（ステップ２６０）。
アンロックが実施された後、スマートロックランタイム環境２２５は、コードモジュール１４０を削除するための１つまたは複数の基準が満たされたことを検出する（ステップ２６６）。この特定の例では、コードモジュール１４０は、スマートロック２１５上にロードされたままであることを無期限に許可されるわけではない。したがって、スマートロックランタイム環境には、コードモジュール１４０がいつ削除されるべきかを判定するための１つまたは複数の基準がある。コードモジュール１４０を削除するための基準は、モバイルデバイス２１０を検出できるか否か、および／または、コードモジュール１４０が転送されてから閾値期間が過ぎたかどうかを含むことができる。
例えば、コードモジュール１４０がスマートロック２１５上に存在する間、スマートロック２１５は、例えば、認証することなく、および／または、モバイルデバイス２１０のなりすまし特性によって、コードモジュール１４０を介してスマートロック２１５の保護された機能を起動する他のいくつかのデバイス（図示せず）に対して脆弱になる恐れがある。したがって、コードモジュール１４０が転送されてから閾値期間が過ぎた後、および／または、モバイルデバイス２１０がもはやスマートロック２１５の近くにない場合、スマートロックランタイム環境２２５は、コードモジュール１４０を削除するべきであると判定することができる。具体的には、スマートロックランタイム環境２２５は、モバイルデバイス２１０からの一定のＲＦエネルギーを検出できないことによって、スマートロック２１５の周辺のエリアをモバイルデバイス２１０が去ったと判定することができる。
一定のモジュール削除基準が満たされたことを検出すると、スマートロックランタイム環境２２５は、コードモジュール１４０を削除する（ステップ２６８）。いくつかの実施形態では、スマートロックランタイム環境２２５は、また、モバイルデバイス２１０に（例えば、モバイルランタイム環境２２０に）コードモジュール１４０を転送して戻す。このように、いくつかの実施形態では、コードモジュール１４０は、ロック制御ソフトウェア２３０が使用される方法を限定するトークンとして機能することができる。すなわち、コードモジュール１４０がスマートロック２１５に転送される間、ロック制御ソフトウェア２３０は、例えば、異なるデバイスにｍｏｄｕｌｅ．ｕｎｌｏｃｋ（）コマンドを送るのを防ぐことができる。
いくつかの実施形態では、スマートロックランタイム環境２２５は、コードモジュール１４０を必要としない他の機能をサポートする。このような機能は、例えば、認証の必要のなく起動することができるパブリックおよび／またはリードオンリ機能であってもよい。したがって、いくつかの実施形態では、モバイルランタイム環境２２０および／またはロック制御ソフトウェア２３０は、スマートロックランタイム環境２２５と直接通信することによって、スマートロック２１５の機能を起動することができる。図１７５の例では、これは、スマートロックランタイム環境２２５の「ｒｕｎｔｉｍｅ．ｉｎｆｏ（）」ファンクションコールをそれぞれ起動するモバイルランタイム環境２２０およびロック制御ソフトウェア２３０によって示されている（ステップ２６２、２６４）。このようなファンクションコールは、例えば、スマートロック２１５についてのデバイスステータス情報を返すことができる。このような情報は、デバイス識別情報、所有者識別情報、アドミニストレータについての連絡先情報、ロックがロックされるかアンロックされるか、および／またはスマートロック２１５に関する他の情報を含むことができる。
例えば、モバイルデバイス２１０のユーザは、スマートロック２１５をアンロックしようとする際に困難に直面することがある。このようなシナリオでは、ユーザは、リモートデバイス１４５を使用してスマートロックランタイム環境２２５にコードモジュール１４０を転送し、スマートロック２１５を自分でアンロックすることができるアドミニストレータに接触する方法、または、モバイルデバイス２１０のユーザが、自分のロック制御ソフトウェア２３０を使用してこれをすることを可能にする方法についての情報を、ロック制御ソフトウェア２３０を使用して取得することができる。このようなアドミニストレータの１つの例は、トラブルを抱えているゲストが自分の部屋に入るのを、システムを使用してリモートに助けることができるホテルのマネージャであってもよいが、他のデバイス、背景、および／またはユーザの役割を含むことができる無数の実施形態がある。
ステップ２５４、２５６、２５８、２６２、および２６４、ならびに２６８で実施されるアクションは、一定方向のアクションとして示されているが、これらのステップの１つまたは複数は、例えば、図示のアクションの結果を示すために、値が返される、対応する応答をトリガできることにさらに留意されたい。例えば、スマートロックランタイム環境２２５は、スマートロックが成功裏にアンロックしたか否かにそれぞれ基づくゼロまたはゼロ以外の値で、ｒｕｎｔｉｍｅ．ｕｎｌｏｃｋ（）ファンクションコールに応答することができる。
上記に一致して、本開示の実施形態は、図１７６に示されている方法３００などの、第１のデバイス１１０によって実行される第２のデバイス１１５を使用するという方法３００を含む。方法３００は、第１のデバイス１１０上で実行する第１のランタイム環境１２０を使用して、第２のデバイス１１５上で実行する第２のランタイム環境１２５にコードモジュール１４０を転送すること（ブロック３１０）を含む。コードモジュール１４０は、第２のランタイム環境１２５内で実行し、第２のランタイム環境１２５によってサポートされる第２のデバイス１１５の機能を第１のデバイス１１０に露出するように設定される。方法３００は、第１のランタイム環境１２０内でアプリケーション１３０を実行すること（ブロック３２０）をさらに含む。アプリケーションは、転送されたコードモジュール１４０および第２のランタイム環境１２５を介して第２のデバイス１１５の機能をリモートに起動する。
他の実施形態は、図１７７に示されるような、第２のデバイス１１５によって実行される第２のデバイス１１５の機能へのアクセスを第１のデバイス１１０に提供するという方法４００を含む。方法４００は、第２のランタイム環境１２５によってサポートされる第２のデバイス１１５の機能を第１のデバイス１１０に露出するために、第１のデバイス１１０上で実行する第１のランタイム環境１２０から第２のデバイス１１５上で実行する第２のランタイム環境１２５にコードモジュール１４０を転送することを含む（ブロック４１０）。方法４００は、第１のランタイム環境１２０内で実行するアプリケーション１３０からコードモジュール１４０を介して受信した機能のリモート起動に応答して、第２のランタイム環境１２５を使用して第２のデバイス１１５の機能の実施を制御すること（ブロック４２０）をさらに含む。
図１７８は、１つまたは複数の実施形態による第１および／または第２のデバイス１１０、１１５の実行および／またはサポートに適したハードウェア５００を示す。図示のように、ハードウェア５００は、処理回路５１０および無線回路機器５２０を含む。無線回路機器５２０は、ハードウェア５００の一部であるか、ハードウェア５００に連結された１つまたは複数のアンテナ（図示せず）を介して伝送および／または受信するように設定することができる。処理回路５１０は、メモリ５３０に格納された命令を実行することなどによって、例えば、図１７５および／または図１７６の、上記で説明した処理を実施するように設定される。下記で論じられるように、処理回路５１０は、この点に関して、１つまたは複数の物理ユニットを備えることができる。追加または代替として、メモリ５３０に格納された命令は、１つまたは複数のソフトウェアモジュールに含まれてもよい。
図１７９は、この点に関して、特定の実施形態による第１のデバイス１１０のさらなる詳細を示す。具体的には、第１のデバイス１１０は、転送ユニットまたはモジュール６０５、および実行ユニットまたはモジュール６１０を含むことができる。転送ユニットまたはモジュール６０５は、第１のデバイス１１０上で実行する第１のランタイム環境１２０を使用して、第２のデバイス１１５上で実行する第２のランタイム環境１２５にコードモジュール１４０を転送するように設定することができる。コードモジュール１４０は、第２のランタイム環境１２５内で実行し、第２のランタイム環境１２５によってサポートされる第２のデバイス１１５の機能を第１のデバイス１１０に露出するように設定される。
図１８０は、特定の実施形態による第２のデバイス１１５のさらなる詳細を示す。具体的には、第２のデバイス１１５は、転送ユニットまたはモジュール７０５、および制御ユニットまたはモジュール７１０を含むことができる。転送ユニットまたはモジュールは、第２のランタイム環境１２５によってサポートされる第２のデバイス１１５の機能を第１のデバイス１１０に露出するために、第１のデバイス１１０上で実行する第１のランタイム環境１２０から第２のデバイス１１５上で実行する第２のランタイム環境１２５にコードモジュール１４０を転送するように設定することができる。制御ユニットまたはモジュール７１０は、第１のランタイム環境１２０内で実行するアプリケーション１３０からコードモジュール１４０を介して受信した機能のリモート起動に応答して、第２のランタイム環境１２５を使用して第２のデバイス１１５の機能の実施を制御するように設定することができる。
転送されたコードモジュールを使用したデバイスエンロールメントとセキュアデバイス動作の組合せ
もう一度、上記で示したように、本明細書で説明される様々な技法は、信頼性、セキュリティ等を伴う長所を提供するために、互いに組み合わせることができる。例えば、有利な１つの特定の組合せは、ＩｏＴ環境におけるデバイスエンロールメント、および、転送されたモジュールを使用したセキュアデバイス動作のための上記で説明した技法の組合せである。
このように、例えば、図１６８に示した方法は、モノのインターネット（ＩｏＴ）環境への第２のデバイスのエンロールメントを支援するための、および第２のデバイスを使用するための、第１のデバイスの方法を取得するために、図１７６に示した方法と組み合わせることができる。この実例の方法は、図１６８のブロック１１０、１２０、および１４０に示されているように、第２のデバイスに関連付けられたエンロールメント機能の表現を取得することであって、エンロールメント機能が、第１および第２のデバイスに関連付けられたエンロールメント情報を含む少なくとも１つのシリアライズされたエンロールメントアプリケーションに関連付けられる、取得すること、第１のデバイスに関連付けられたエンロールメント情報が、第２のデバイスに関連付けられたエンロールメント情報から分離されるように、エンロールメントアプリケーションをデシリアライズすること、ならびに、第２のデバイスに関連付けられたエンロールメント情報に基づいて第２のデバイスを設定することによって、第２のデバイスのエンロールメント処理の第２のデバイスによる実行を始めるために、第２のデバイスに関連付けられたエンロールメント情報を第２のデバイスに伝送することというステップを含む。方法は、図１６８のブロック１５０に示されているように、第２のデバイスに関連付けられた設定情報を第２のデバイスから受信することをさらに含む。
この例は、図１７６のブロック３１０に示されているように、第１のデバイス上で実行する第１のランタイム環境を使用して、第２のデバイス上で実行する第２のランタイム環境にコードモジュールを転送するというステップをさらに含み、コードモジュールは、第２のランタイム環境内で実行し、第２のランタイム環境によってサポートされる第２のデバイスの機能を第１のデバイスに露出するように設定される。最後に、この実例の方法は、第１のランタイム環境内でアプリケーションを実行するというステップを含み、アプリケーションは、転送されたコードモジュールおよび第２のランタイム環境を介して第２のデバイスの機能をリモートに起動する。
第２のデバイスは、モノのインターネット（ＩｏＴ）デバイスであってもよく、いくつかの実施形態では、第１のデバイスは、無線通信デバイスであってもよい。エンロールメント機能の表現は、例えば、ＱＲコード、バーコード、およびＲＦ－ＩＤチップの１つまたは複数であってもよい。第２のデバイスに関連付けられたエンロールメント情報は、いくつかの実施形態では、公開暗号鍵、ソフトウェアシステム、能力、ＩｏＴ環境のエンロールメント処理および機能に関するステップの少なくとも１つを含むことができる。エンロールメント情報は、いくつかの実施形態では、地理位置、組織の位置、所有権、暗号鍵、通信パラメータ、通信鍵および識別情報の１つまたは複数に関連付けられた情報を含むことができる。
いくつかの実施形態では、エンロールメント機能は、少なくとも２つのシリアライズされたエンロールメントアプリケーションを含み、方法は、第１のデバイスに関連付けられたエンロールメント情報を含む少なくとも１つのエンロールメントアプリケーションと、第２のデバイスに関連付けられたエンロールメント情報を含む少なくとも１つのエンロールメントアプリケーションに、少なくとも２つのシリアライズされたエンロールメントアプリケーションをデシリアライズすること、および、第２のデバイスに関連付けられた少なくとも１つのエンロールメントアプリケーションを第２のデバイスに伝送することをさらに含む。
いくつかの実施形態では、方法は、第２のデバイスが成功裏にエンロールメントしたと判定すること、および、第１のデバイス上の少なくとも１つのエンロールメントアプリケーションを終了することをさらに含む。
いくつかの実施形態では、方法は、第２のランタイム環境内での実行のために、第２のランタイム環境にコードモジュールを転送するための権限を取得するために、第２のランタイム環境で第１のランタイム環境を認証すること、および／または、第２のデバイスの異なる機能を起動するために第２のランタイム環境と直接通信することをさらに含む。
いくつかの実施形態では、第２のランタイム環境へのコードモジュールの転送は、第１のデバイスと第２のデバイスとの間の無線ポイントツーポイント接続で実施される。第２のデバイスは、例えば電子ロックであってもよく、ここで、第２のランタイム環境によってサポートされる機能が、電子ロックをロックまたはアンロックする。
同様に、図１６９に示した方法は、第１のデバイスによって支援されるモノのインターネット（ＩｏＴ）環境へのエンロールメント処理を実行し、第２のデバイスの機能へのアクセスを第１のデバイスに提供するための、第２のデバイスの方法を取得するために、図１７７に示した方法と組み合わせることができる。この実例の方法は、図１６９のブロック２１０、２３０、および２４０で示されているように、第２のデバイスに関連付けられたエンロールメント情報を第１のデバイスから受信すること、エンロールメント情報に基づいて第２のデバイスを設定することによってエンロールメント処理を実行すること、および、第２のデバイスに関連付けられた設定情報を第１のデバイスに伝送することというステップを含む。方法は、図１７７のブロック４１０および４２０で示されているように、第２のランタイム環境によってサポートされる第２のデバイスの機能を第１のデバイスに露出するために、第１のデバイス上で実行する第１のランタイム環境から第２のデバイス上で実行する第２のランタイム環境にコードモジュールを受信すること、および、第１のランタイム環境内で実行するアプリケーションからコードモジュールを介して受信した機能のリモート起動に応答して、第２のランタイム環境を使用して、第２のデバイスの機能の実施を制御することというステップをさらに含む。
いくつかの実施形態では、方法は、エンロールメントが成功したと判定すること、および、第２のデバイスからエンロールメント情報を削除することをさらに含む。いくつかの実施形態では、第２のデバイスに関連付けられたエンロールメント情報は、公開暗号鍵、ソフトウェアシステム、能力、ＩｏＴ環境のエンロールメント処理および機能に関するステップの少なくとも１つを含む。
いくつかの実施形態では、方法は、第２のランタイム環境内での実行のために、第２のランタイム環境へのコードモジュールの転送を認証するために、第２のランタイム環境で第１のランタイム環境を認証することをさらに含む。いくつかの実施形態では、方法は、第１のデバイスから第２のランタイム環境への直接通信に応答して、第２のランタイム環境を使用して、第２のデバイスの異なる機能の実施を制御することをさらに含む。
第１のランタイム環境からのコードモジュールの転送は、いくつかの実施形態では、第１のデバイスと第２のデバイスとの間の無線ポイントツーポイント接続で実施することができる。第２のデバイスは、例えば電子ロックであってもよく、ここで、第１のランタイム環境によってサポートされる機能が、電子ロックをロックまたはアンロックする。
裁判管轄プライバシ制約に適合した連合データベースへの問合せ
ヘルスケア、ｅコマース、政府、および小売りなど、多くのビジネスセクタにおける会社および組織は、識別可能情報（例えば、個人情報、プライベート情報、秘密情報、または同様のもの）を託されており、これらのエンティティにとって最大の懸念についての、この情報のプライバシの保護を行う。ほとんどの場合、これらのエンティティは、この情報のプライバシがどのように保護されるべきであるかを指定および規定する。
「Ｈｉｐｐｏｃｒａｔｉｃ Ｄａｔａｂａｓｅ：Ａ Ｐｒｉｖａｃｙ－Ａｗａｒｅ Ｄａｔａｂａｓｅ」という名称の白書の著者は、それぞれのプライバシポリシテーブルおよびプライバシ認証テーブルに格納されたプライバシポリシおよびプライバシ認証からなるメタデータを使用するデータベースアーキテクチャを提案した。Ｎ．Ｇｈａｎｉ、Ｚ．Ｓｉｄｅｋ、Ｈｉｐｐｏｃｒａｔｉｃ Ｄａｔａｂａｓｅ：Ａ Ｐｒｉｖａｃｙ－Ａｗａｒｅ Ｄａｔａｂａｓｅ、Ｉｎｔ’ｌ Ｊ．Ｃｏｍｐｕｔｅｒ Ｉｎｆｏ．Ｅｎｇｉｎｅｅｒｉｎｇ、ｖｏｌ．２、Ｎｏ．６（２００８）。著者は、クエリ処理中にプライバシチェックをデータベースが実施するフレームワークを説明する。例えば、データベースは、クエリを発行したユーザが、データベースにアクセスするために認証されているかどうかをチェックする。データベースは、プライバシ認証テーブルに明示的にリストアップされた属性だけにクエリがアクセスしたかどうかもチェックする。また、データベースは、その目的属性がクエリの目的を含むデータベース内の情報へのアクセスしか許可しない。したがって、意図した目的のために認証されたユーザだけが、データベース内の情報にアクセスすることができる。それでも、このプライバシ配慮型データベース（ｐｒｉｖａｃｙ－ａｗａｒｅ ｄａｔａｂａｓｅ）は、データベースが位置する裁判管轄のプライバシ制約を考慮していない。さらに、このデータベースは、複数のデータベースからのクエリへの応答から推測できる識別可能情報を保護していない。
連合データベースシステムは、単一の連合データベースに設定データベースをマッピングするメタデータベース管理システムである。したがって、連合データベースは、連合データベースが表す設定データベースの合成である仮想データベースである。連合データベースシステムは、各設定データベースにクエリを送り、各設定データベースから受信したクエリへの応答を結合することによって、１つのデータベースシステムであると理解される。さらに、各設定データベースは、他のデータベースと独立して通信すること、各設定データベースの動作を実行および制御すること、または、他のデータベースと各設定データベース自体を関連付けること（もしくは切り離す）ことができる自律的データベースであってもよい。それでも、現在の連合データベースシステムは、連合データベースシステムが表す裁判管轄のプライバシ制約を考慮しておらず、同じまたは異なる裁判管轄における複数のデータベースからのクエリへの応答から推測できる識別可能情報を保護していない。
以前に論じられたように、現在のプライバシ配慮型データベースおよび連合データベースシステムは、これらのデータベースが表す裁判管轄のプライバシ制約を考慮していない。それでも、データベースユーザは、典型的には、同じまたは異なる裁判管轄におけるデータベースからのクエリへの応答を結合させたいと思っている。そうすることによって、応答に含まれる、または応答によって推測される識別可能情報を、各アクセスされるデータベースの裁判管轄のプライバシ法に適合して保護することができない。１つの例では、２つの異なるデータベースからの、特定の範囲の所得、および一定の範囲の教育を含む人数のカウントに関するクエリは、個人識別可能情報（例えば、名前、社会保障番号、住所、または同様のもの）に基づくクエリへの応答を結合する必要があるが、これは、各データベースの裁判管轄におけるプライバシ制約に違反する恐れがある。別の例では、第１のデータベースにおける人物（例えばユーザ識別子）のリスト、および、訪問者（例えばユーザ識別子）でインデックスを付けられた訪れたウェブページのログに関するクエリは、各データベースの裁判管轄のプライバシ制約に違反して結合することができない（例えば、ネット検索の癖（ｓｕｒｆｉｎｇ ｈａｂｉｔｓ）が米国のデータベースに格納されたＥＵ市民）。さらに別の例では、食習慣への予想のようなリンク付けに関するクエリは、食料雑貨店チェーンからの食料品の買い物のレシートを伴うデータベースからの第１の応答、クレジットカード会社からのレストランのレシートを伴うデータベースからの第２の応答、および、識別可能情報に基づく政府の税務署からの生活期間（ｌｉｆｅ ｄｕｒａｔｉｏｎ）を伴うデータベースからの第３の応答を、各データベースの裁判管轄のプライバシ制約に違反して、応答に結合できる可能性がある。
したがって、裁判管轄プライバシ制約に適合した連合データベースに問い合わせるための技法を改善する必要がある。さらに、本開示の他の望ましい特徴および特性が、添付の図および前述の技術分野および背景と併用して、その後の詳細な説明および実施形態から明らかになる。
本開示は、裁判管轄プライバシ制約に適合した連合データベースに問い合わせることについてのシステムおよび方法の説明を含む。さらに、本開示は、同じまたは異なる裁判管轄内に位置するデータベースから受信したクエリへの応答を、これらのデータベースに格納された個人データの整合性を尊重しつつ、設定または結合することについての斬新な技法を説明する。例えば、図１８１は、本明細書で説明されるような様々な態様による連合データベースに問い合わせるためのシステム１００の１つの実施形態の流れ図である。図１８１では、システム１００は、クライアントノード１０１（例えば、スマートフォン）、連合データベースを備えるネットワークノード１２１（例えば、コンピュータサーバ）、および、自律的データベース（例えば、国税庁における個人記録）を備えるネットワークノード１４１（例えば、コンピュータサーバ）を含む。連合データベースは、一定の裁判管轄（例えば米国）内に位置する１つまたは複数の自律的データベースを、準連合データベースを介して直接または間接的に表す。
図１８１では、１つの実施形態では、クライアントデバイス１０１は、参照番号１６１で表したように、自律的データベースに格納された識別可能情報に関する、または、同じ裁判管轄内に位置する自律的データベース、および別の自律的データベースから受信したクエリ１６１への応答の結合から判定できる、（例えば、一定の所得範囲を有する人数を識別する）クエリを送る。連合ネットワークノード２２１は、クエリを受信し、ブロック１２３で表したように、自律的データベースの裁判管轄についての１つまたは複数のプライバシ制約に基づいて、この自律的データベースのためにクエリを適合させる。連合ネットワークノード１２１は、次に、参照番号１６３で表したように、自律的ネットワークノード１４１に適合後のクエリを送る。自律的ネットワークノード１４１は、適合後のクエリを受信し、ブロック１４３で表したように、クエリへの適合後の応答１６７を自律的データベースから取得する。自律的ネットワークノード１４１は、参照番号１６５で表したように、連合ネットワークノード２２１に応答を送る。連合ネットワークノード１２１は、ブロック１２７で表したように、受信した応答に基づいて、クエリへの適合後の応答を設定する。さらに、連合ネットワークノード１２１は、参照番号１７１で表したように、適合後の応答をクライアントノード１０１に送る。
クライアントノード１０１は、ユーザ機器、移動局（ＭＳ）、端末、セルラフォン、セルラハンドセット、パーソナルデジタルアシスタント（ＰＤＡ）、スマートフォン、無線電話、オーガナイザ、ハンドヘルドコンピュータ、デスクトップコンピュータ、ラップトップコンピュータ、タブレット型コンピュータ、セットトップボックス、テレビ、アプライアンス、ゲームデバイス、医療デバイス、表示デバイス、計量デバイス、または同様のものであってもよい。各ネットワークノード１２１、１４１は、コンピュータサーバ、基地局、コアネットワークノード、ハンドヘルドコンピュータ、デスクトップコンピュータ、ラップトップコンピュータ、タブレット型コンピュータ、セットトップボックス、テレビ、アプライアンス、医療デバイス、または他のいくつかの同様の用語などの、ネットワーク内の通信再分配ポイントまたは通信エンドポイントであるコンピュータ実行ノードであってもよい。
識別可能情報は、特定の人物、場所、または物に関連付けられた任意の情報であってもよい。さらに、識別可能情報は、人物、ビジネス、組織、政府機関、または同様のものに関連付けられた個人情報を含むことができる。識別可能情報は、秘密または極秘情報も含むこともできる。極秘情報は、不正な第三者に開示されないという期待で共有される情報を含む。裁判管轄は、責任の規定された分野（例えば、米国連邦法、ミシガン税法、Ｉｎｔｅｒｎａｌ Ｒｅｖｉｅｗ Ｓｅｒｖｉｃｅ、環境保護庁など）の中で一定のプライバシ制約を管理するために特定の団体に認められた権威を表すことができる。さらに、裁判管轄は、連盟（例えばＥＵ）、国、州（ｓｔａｔｅ）、州（ｐｒｏｖｉｎｃｅ）、市、郡、自治体、タウンシップ等）などの特定の地域に関連付けることができる。プライバシ制約は、裁判管轄の法律、ルール、または規制に関連付けられる。例えば、プライバシ制約は、名前、住所、電話番号、財務記録、医療記録、位置、個人属性、または同様のものなどの個人情報を共有する能力を制約または制限することができる。
図１８２は、本明細書で説明されるような様々な態様による連合データベースに問い合わせるためのシステム２００の１つの実施形態の流れ図である。図１８２では、システム２００は、クライアントノード２０１、連合データベースを備えるネットワークノード２２１、第１の自律的データベース（例えば、Ｉｎｔｅｒｎａｌ Ｒｅｖｉｅｗ Ｓｅｒｖｉｃｅにおける個人記録）を備えるネットワークノード２４１ａ、および第２の自律的データベース（例えば、米国国勢調査局における個人記録）を備えるネットワークノード２４１ｂを含む。連合データベースは、同じまたは異なる裁判管轄（例えば米国）に位置する第１および第２のデータベースを、準連合データベースを介して直接または間接的に表す。
図１８２では、１つの実施形態では、クライアントデバイス２０１は、参照番号２６１で表したように、第１もしくは第２の自律的データベースに格納された識別可能情報に関するものであり、または、第１および第２のデータベースから受信したクエリへの応答の結合から判定できる、クエリを送る。連合ネットワークノード２２１は、クエリを受信し、ブロック２２３で表したように、対応する自律的データベースの裁判管轄についての１つまたは複数のプライバシ制約に基づいて、識別可能情報に対応するクエリの１つまたは複数のデータフィールドを識別する。クエリの１つまたは複数のフィールドが識別可能情報に対応すると識別したことに応答して、連合ネットワークノード２２１は、ブロック２２５で表したように、クエリのためのランダムなソルトを判定する。連合ネットワークノード２２１は、次に、参照番号２６３ａで表したように、自律的ネットワークノード２４１ａにクエリおよびソルトを送る。
本実施形態では、自律的ネットワークノード２４１ａは、クエリおよびソルトを受信し、ブロック２４３ａで表したように、第１の自律的データベースからクエリへの応答を取得する。自律的ネットワークノード２４１ａは、次に、ブロック２４５ａで表したように、ソルトに基づいて応答の識別可能情報を匿名化する。１つの例では、識別可能情報およびソルトは、匿名情報を取得するために、暗号学的ハッシュ関数で処理される。自律的ネットワークノード２４１ａは、参照番号２６５ａで表したように、匿名情報を含む応答を連合ネットワークノード２２１に送る。連合ネットワークノード２２１は、ブロック２２７で表したように、応答およびその匿名情報に基づいて、クエリへの適合後の応答を設定する。さらに、連合ネットワークノード２２１は、参照番号２７１で表したように、適合後の応答をクライアントノード２０１に送る。
別の実施形態では、連合ネットワークノード２２１は、参照番号２６３ａ、２６３ｂで表したように、各自律的ネットワークノード２４１ａ、２４１ｂに同じクエリおよびソルトを送る。自律的ネットワークノード２４１ａ、２４１ｂは、同じ裁判管轄内または異なる裁判管轄内にあってもよい。各自律的ネットワークノード２４１ａ、２４１ｂは、クエリおよびソルトを受信し、その自律的データベースを介して、クエリへの対応する応答を取得する。さらに、各自律的ネットワークノード２４１ａ、２４１ｂは、ソルトに基づいて、対応する応答の識別可能情報を匿名化する。各自律的ネットワークノード２４１ａ、２４１ｂは、それぞれの参照番号２６５ａ、２６５ｂで表したように、匿名情報を含む対応する応答を連合ネットワークノード２２１に送る。連合ネットワークノード２２１は、次に、各応答の中で受信した匿名情報に基づいて、第１および第２の自律的データベースからのクエリへの応答を結合する。
上記で説明した装置は、任意の機能的手段、モジュール、ユニット、または回路機器を実行することによって、本明細書における方法および他の任意の処理を実施できることに留意されたい。１つの実施形態では、例えば、装置は、方法の図で示したステップを実施するように設定されたそれぞれの回路または回路機器を備える。回路または回路機器は、この点に関して、一定の機能的処理の実施に専用の回路、および／または、メモリとともに１つもしくは複数のマイクロプロセッサを備えることができる。例えば、回路機器は、１つまたは複数のマイクロプロセッサまたはマイクロコントローラ、および、デジタル信号プロセッサ（ＤＳＰ）、専用デジタルロジックなどを含むことができる他のデジタルハードウェアを含むことができる。処理回路は、メモリに格納されたプログラムコードを実行するように設定することができ、メモリは、リードオンリメモリ（ＲＯＭ）、ランダムアクセスメモリ、キャッシュメモリ、フラッシュメモリデバイス、光ストレージデバイス等などの、１つまたはいくつかのタイプのメモリを含むことができる。メモリに格納されたプログラムコードは、いくつかの実施形態では、１つまたは複数のテレコミュニケーションおよび／またはデータ通信プロトコルを実行するためのプログラム命令、ならびに、本明細書で説明される技法の１つまたは複数を実行するための命令を含むことができる。メモリを採用する実施形態では、メモリは、１つまたは複数のプロセッサによって実行されると、本明細書で説明される技法を実行するプログラムコードを格納する。
図１８３は、本明細書で説明されるような様々な態様による連合データベースを備えるネットワークノード３００の１つの実施形態を示す。図示のように、ネットワークノード３００は、処理回路３１０および通信回路機器３３０を含む。通信回路機器３３０は、例えば任意の通信技術を介して、１つまたは複数の他のノードとの間で情報を伝送および／または受信するように設定される。処理回路３１０は、メモリ３２０に格納された命令を実行することなどによって、上記で説明した処理を実施するように設定される。処理回路３１０は、この点に関して、一定の機能的手段、ユニット、またはモジュールを実行することができる。
図１８４は、本明細書で説明されるような様々な態様による連合データベースを備えるネットワークノード４００の別の実施形態を示す。図示のように、ネットワークノード４００は、様々な機能的手段、ユニット、もしくはモジュール（例えば、図１８３の処理回路３１０を介して、ソフトウェアコードを介して）、または回路を実行する。１つの実施形態では、（例えば、本明細書における方法を実行するための）これらの機能的手段、ユニット、モジュール、または回路は、例えば、少なくとも１つの自律的データベースに格納された識別可能情報に関するものであり、または、少なくとも２つの自律的もしくは準連合データベースから受信したクエリへの応答の結合から判定することができる、クエリを取得するための取得ユニット４１３、各自律的または準連合データベースの裁判管轄についての１つまたは複数のプライバシ制約４３１に基づいて、各自律的または準連合データベースのためにクエリを適合させるための適合ユニット４１５、各自律的または準連合データベースのための適合後のクエリを各自律的または準連合データベースに送るための送信ユニット４２１、対応する適合後のクエリへの応答を各自律的または準連合データベースから受信するための受信ユニット４１１、および、各自律的または準連合データベースの裁判管轄についての１つまたは複数のプライバシ制約４３１を適合後の応答が満たすように、各自律的または準連合データベースから受信した対応する適合後のクエリへの応答に基づいて、クエリへの適合後の応答を設定するための設定ユニット４２３を含むことができる。
別の実施形態では、これらの機能的手段、ユニット、モジュール、または回路は、例えば、少なくとも１つの自律的データベースに格納された識別可能情報に関するものであり、または、少なくとも２つの自律的もしくは準連合データベースから受信したクエリへの応答の結合から判定することができる、クエリを取得するための取得ユニット４１３、クエリについてのランダムなソルトを判定するためのソルト判定ユニット４１９、各自律的または準連合データベースのための適合後のクエリを各自律的または準連合データベースに送るための送信ユニット４２１、対応する適合後のクエリへの応答を各自律的または準連合データベースから受信するための受信ユニット４１１、および、各応答の中で受信した匿名情報に基づいて、自律的または準連合データベースからの適合後のクエリへの応答を結合するための結合ユニット４２５を含むことができる。
別の実施形態では、これらの機能的手段、ユニット、モジュール、または回路は、例えば、自律的または準連合データベースの裁判管轄についての１つまたは複数のプライバシ制約４３１に基づいて、識別可能情報に対応するクエリの１つまたは複数のデータフィールドを識別するための識別ユニット４１７を含むことができる。
別の実施形態では、これらの機能的手段、ユニット、モジュール、または回路は、例えば、各自律的または準連合データベースの裁判管轄についての１つまたは複数のプライバシ制約４３１に適合して、各自律的または準連合データベースに問い合わせることを連合データベースに認証する各自律的または準連合データベースからの認証鍵４３３を、各自律的または準連合データベースから受信するための受信ユニット４１１を含むことができる。
別の実施形態では、これらの機能的手段、ユニット、モジュール、または回路は、例えば、各自律的または準連合データベースの対応する裁判管轄についての１つまたは複数のプライバシ制約４３１を、各自律的または準連合データベースから受信するための受信ユニット４１１を含むことができる。
別の実施形態では、これらの機能的手段、ユニット、モジュール、または回路は、例えば、適合後の応答をクライアントデバイスに送るための送信ユニット４２１を含むことができる。
別の実施形態では、これらの機能的手段、ユニット、モジュール、または回路は、例えば、匿名情報から識別可能情報を判定する能力が、各自律的または準連合データベースから匿名情報を受信することと、ソルトを削除することとの間でしか発生しないように、応答を結合することに応答して、クエリについてのソルトを削除するための削除ユニット４２７を含むことができる。
別の実施形態では、これらの機能的手段、ユニット、モジュール、または回路は、例えば、裁判管轄についての１つまたは複数のプライバシ制約を取得するための制約取得ユニット４３１を含むことができる。
図１８５は、本明細書で説明されるような様々な態様による同じまたは異なる裁判管轄内に位置する１つまたは複数の自律的または準連合データベースを表す連合データベースを備えるネットワークノードによって実施される方法５００ａの１つの実施形態を示す。図１８５では、方法５００ａは、例えばブロック５０１ａでスタートすることができ、ここで、ブロック５０１ａは、各自律的または準連合データベースの裁判管轄についての１つまたは複数のプライバシ制約に適合して、各自律的または準連合データベースに問い合わせることを連合データベースに認証する各自律的または準連合データベースからの認証鍵を、各自律的または準連合データベースから受信することを含むことができる。さらに、方法５００ａは、ブロック５０３ａで参照されるように、各自律的または準連合データベースの対応する裁判管轄についての１つまたは複数のプライバシ制約を、各自律的または準連合データベースから受信することを含むことができる。ブロック５０５ａにおいて、方法５００ａは、少なくとも１つの自律的データベースに格納された識別可能情報に関するものであり、または、少なくとも２つの自律的もしくは準連合データベースから受信したクエリへの応答の結合から判定することができる、クエリを取得すること（例えば、クライアントデバイスから受信すること）を含む。また、方法５００ａは、ブロック５０７ａで参照されるように、自律的もしくは準連合データベースの裁判管轄についての１つまたは複数のプライバシ制約に基づいて、識別可能情報に対応するクエリの１つまたは複数のデータフィールドを識別することを含むことができる。
図１８５では、ブロック５０９ａにおいて、方法５００ａは、識別可能情報を識別することに応答することができる、各自律的または準連合データベースの裁判管轄についての１つまたは複数のプライバシ制約に基づいて、各自律的または準連合データベースのためにクエリを適合させることを含む。ブロック５１１ａにおいて、方法５００ａは、各自律的または準連合データベースのための適合後のクエリを、各自律的または準連合データベースに送ることを含む。ブロック５１３ａにおいて、方法５００ａは、対応する適合後のクエリへの応答を各自律的または準連合データベースから受信することを含む。ブロック５１５ａにおいて、方法５００ａは、各自律的または準連合データベースの裁判管轄についての１つまたは複数のプライバシ制約を適合後の応答が満たすように、各自律的または準連合データベースから受信した対応する適合後のクエリへの応答に基づいてクエリへの適合後の応答を設定することを含む。さらに、方法５００ａは、ブロック５１７ａで表したように、適合後の応答をクライアントデバイスに送ることを含むことができる。
図１８６は、本明細書で説明されるような様々な態様による同じまたは異なる裁判管轄内に位置する１つまたは複数の自律的または準連合データベースを表す連合データベースを備えるネットワークノードによって実施される方法５００ｂの１つの実施形態を示す。図１８６では、方法５００ｂは、例えばブロック５０５ｂでスタートすることができ、ここで、方法５０５ｂは、少なくとも１つの自律的データベースに格納された識別可能情報に関するものであり、または、少なくとも２つの自律的もしくは準連合データベースから受信したクエリへの応答の結合から判定することができる、クエリを取得することを含むことができる。さらに、方法５００ｂは、ブロック５０７ｂで表したように、自律的または準連合データベースの裁判管轄についての１つまたは複数のプライバシ制約に基づいて、識別可能情報に対応するクエリの１つまたは複数のデータフィールドを識別することを含むことができる。各自律的または準連合データベースについての適合後のクエリは、各自律的または準連合データベースが、ソルトに基づくクエリへの各応答の中で、識別可能情報を匿名化するように動作できるように、クエリおよびランダムなソルトを含む。したがって、ブロック５０９ｂにおいて、方法５００ｂは、クエリについてのソルトを判定することを含む。ブロック５１１ｂにおいて、方法５００ｂは、各自律的または準連合データベースに、クエリおよびソルトを送ることを含む。ブロック５１３ｂにおいて、方法５００ｂは、各応答の中の識別可能情報がソルトに基づいて匿名化されたクエリへの応答を、各自律的または準連合データベースから受信することを含む。ブロック５１５ｂにおいて、方法５００ｂは、各応答の中で受信した匿名情報に基づいて、自律的または準連合データベースからの適合後のクエリへの応答を結合することを含む。さらに、方法は、ブロック５１９ｂで表したように、匿名情報から識別可能情報を判定する能力が、各自律的または準連合データベースから匿名情報を受信することと、ソルトを削除することとの間でしか発生しないように、応答を結合することに応答して、クエリについてのソルトを削除することを含むことができる。
図１８７は、本明細書で説明されるような様々な態様による自律的データベース６４０を備えるネットワークノード６００の１つの実施形態を示す。図示のように、ネットワークノード６００は、処理回路６１０、通信回路機器６２０、および自律的データベース６４０を含む。通信回路機器６２０は、例えば、任意の通信技術を介して、１つまたは複数の他のノードとの間で情報を伝送および／または受信するように設定される。処理回路６１０は、メモリ６３０に格納された命令を実行することなどによって、処理を実施するように設定される。さらに、処理回路６１０は、自律的データベース６４０に関連付けられた処理を実施するように設定される。処理回路６１０は、この点に関して、一定の機能的手段、ユニット、またはモジュールを実行することができる。
図１８８は、本明細書で説明されるような様々な態様による自律的データベース７３５を備えるネットワークノード７００の別の実施形態を示す。図示のように、ネットワークノード７００は、様々な機能的手段、ユニット、もしくはモジュール（例えば、図１８７の処理回路６１０を介して、および／またはソフトウェアコードを介して）、または回路を実行する。１つの実施形態では、（例えば、本明細書における方法を実行するための）これらの機能的手段、ユニット、モジュール、または回路は、例えば、クエリおよびクエリについてのランダムなソルトを、連合または準連合データベースから受信するための受信ユニット７１１、応答が識別可能情報を含む自律的データベース７３５からのクエリへの応答を取得するための応答取得ユニット７１３、受信したソルトに基づいて応答の識別可能情報を匿名化するための匿名化ユニット７１５、ならびに、自律的データベースの裁判管轄についての１つまたは複数のプライバシ制約７３１を応答が満たすように、連合または準連合データベースに、匿名情報を含む応答を送るための送信ユニット７１７を含むことができる。
別の実施形態では、これらの機能的手段、ユニット、モジュール、または回路は、例えば、裁判管轄についての１つまたは複数のプライバシ制約に適合して、自律的データベース７３５に問い合わせるために連合または準連合データベースを認証する認証鍵７３３を取得するための鍵取得ユニット７２１、連合または準連合データベースに認証鍵７３３を送るための送信ユニット７１７、クエリ、クエリについてのランダムなソルト、および鍵を、連合または準連合データベースから受信するための受信ユニット７１１、受信した鍵および認証鍵７３３に基づいて、自律的データベース７３５に問い合わせることを連合または準連合データベースが認証されるかどうかを判定するための認証判定ユニット７１９を含むことができる。
別の実施形態では、これらの機能的手段、ユニット、モジュール、または回路は、例えば、自律的データベース７３５の裁判管轄についての１つまたは複数のプライバシ制約７３１を取得するための制約取得ユニット７２３、および、裁判管轄についての１つまたは複数のプライバシ制約７３１を連合または準連合データベースに送るための送信ユニット７１７を含むことができる。
図１８９は、本明細書で説明されるような様々な態様による連合または準連合データベースによって表された、一定の裁判管轄内の自律的データベースを備えるネットワークノードによって実施される方法８００ａの１つの実施形態を示す。図１８９では、方法８００ａは、例えばブロック８０１ａでスタートすることができ、ここで、ブロック８０１ａは、クエリおよびクエリについてのランダムなソルトを、連合または準連合データベースから受信することを含む。さらに、クエリは、自律的データベースに格納された識別可能情報に関するものであり、または、連合もしくは準連合データベースによって表された、自律的データベースおよび１つもしくは複数の他の自律的もしくは準連合データベースから、連合もしくは準連合データベースによって受信されたクエリへの応答の結合から判定することができる。さらに、方法８００ａは、ブロック８０３ａで表したように、応答が識別可能情報を含むクエリへの応答を自律的データベースから取得することを含む。また、方法８００ａは、ブロック８０５ａで表したように、受信したソルトに基づいて、応答の識別可能情報を匿名化することを含む。さらに、方法８００ａは、ブロック８０７ａで表したように、自律的データベースの裁判管轄についての１つまたは複数のプライバシ制約を応答が満たすように、匿名情報を含む応答を、連合または準連合データベースに送ることを含む。
図１９０は、本明細書で説明されるような様々な態様による連合または準連合データベースによって表された、一定の裁判管轄内の自律的データベースを備えるネットワークノードによって実施される方法８００ｂの１つの実施形態を示す。図１９０では、方法８００ｂは、例えばブロック８０１ｂでスタートすることができ、ここで、ブロック８０１ｂは、裁判管轄についての１つまたは複数のプライバシ制約に適合して、自律的データベースに問い合わせるために連合または準連合データベースを認証する認証鍵を取得することを含む。さらに、方法８００ｂは、ブロック８０３ｂで表したように、連合または準連合データベースに認証鍵を送ることを含む。ブロック８０５ｂにおいて、方法８００ｂは、自律的データベースの裁判管轄についての１つまたは複数のプライバシ制約を取得することを含むことができる。また、方法８００ｂは、ブロック８０７ｂで表したように、裁判管轄についての１つまたは複数のプライバシ制約を、連合または準連合データベースに送ることを含むことができる。
図１９０では、ブロック８０９ｂにおいて、方法８００ｂは、クエリ、クエリについてのランダムなソルト、および鍵を、連合または準連合データベースから受信することを含む。クエリは、自律的データベースに格納された識別可能情報に関するものであり、または、連合もしくは準連合データベースによって表された、自律的データベースおよび１つもしくは複数の他の自律的もしくは準連合データベースから、連合もしくは準連合データベースによって受信されたクエリへの応答の結合から判定することができる。さらに、方法８００ｂは、ブロック８１１ｂで表したように、受信した鍵および認証鍵に基づいて、連合または準連合データベースが自律的データベースに問い合わせることを認証されているかどうかを判定することを含む。連合または準連合データベースが自律的データベースに問い合わせることを認証されていると判定することに応答して、方法８００ｂは、ブロック８１３ｂで表したように、クエリへの応答を取得し、受信したソルトに基づいて応答の識別可能情報を匿名化し、連合または準連合データベースに匿名情報を含む応答を送ることを含む。
図１９１は、本明細書で説明されるような様々な態様による連合データベースに問い合わせるためのシステム９００の別の実施形態を示す。図１９１では、システム９００は、一定の裁判管轄内に位置する連合データベースを備えるネットワークノード９０１、および自律的データベースを備えるネットワークノード９４１ａを含む。連合ネットワークノード９０１は、ブロック９０３で表したように、自律的ネットワークノード９４１ａにクエリおよび任意選択の鍵を送る。さらに、鍵は、自律的データベースの裁判管轄についてのプライバシ制約に適合して、自律的データベースに問い合わせるために、連合または準連合データベースを認証するために使用される。
図１９１では、自律的ネットワークノード９４１ａは、ブロック９４３ａで表したように、クエリおよび任意選択の鍵を受信する。自律的ネットワークノード９４１ａは、ブロック９４５ａで表したように、受信した鍵、および自律的ネットワークノード９４１ａに格納された認証鍵に基づいて、クエリが認証されているかどうかを判定することができる。自律的ネットワークノード９４１ａは、ブロック９４７ａで表したように、この自律的データベースからのクエリへの応答を取得する。さらに、自律的ネットワークノード９４１ａは、ブロック９４９ａで表したように、連合ネットワークノード９０１にクエリへの応答を送る。連合ネットワークノード９０１は、ブロック９０５、９０９でそれぞれ表したように、応答を受信し、受信した応答に基づいてクエリへの適合後の応答を設定し、クライアントデバイスなどに適合後の応答を送る。
別の実施形態では、連合ネットワークノード９０１は、自律的ネットワークノード９４１ａ、９４１ｂにクエリおよび任意選択の鍵を送る。自律的ネットワークノード９４１ａ、９４１ｂは、同じ裁判管轄または異なる裁判管轄内に位置することができる。各自律的ネットワークノード９４１ａ、９４１ｂは、クエリおよび任意選択の鍵を受信し、受信した鍵、およびこの自律的ネットワークノード９４１ａ、９４１ｂに格納された認証鍵に基づいてクエリが認証されているかどうかを判定することができる。各自律的ネットワークノード９４１ａ、９４１ｂは、この自律的データベースからのクエリへの応答を取得し、連合ネットワークノード９０１に応答を送る。連合ネットワークノード９０１は、ブロック９０５、９０９でそれぞれ表したように、各応答を受信し、クエリへの応答を結合する。連合ネットワークノード９０１は、次に、ブロック９０９で表したように、クライアントデバイスなどに結合した応答を送ることができる。
図１９２は、本明細書で説明されるような様々な態様による連合データベースに問い合わせるためのシステム１０００の別の実施形態を示す。図１９２では、システム１０００は、連合データベースを備えるネットワークノード１００１、一定の裁判管轄に関連付けられた準連合データベースを備えるネットワークノード１０２１、および、この一定の裁判管轄に関連付けられた自律的データベースを備えるネットワークノード１０４１を含む。連合ネットワークノード１００１は、ブロック１００３で表したように、準連合ネットワークノード１０２１にクエリおよび任意選択の鍵を送る。
図１９２では、準連合ネットワークノード１０２１は、ブロック１０２３で表したように、クエリおよび任意選択の鍵１０６１を受信する。準連合ネットワークノード１０２１は、ブロック１０２５で表したように、このデータベースについての適合後のクエリを取得するために、クエリのデータフィールド、およびこのデータベースのプライバシ制約に基づいて、各自律的データベースについてのクエリを分割するまたは適合させることを判定することができる。準連合ネットワークノード１０２１は、ブロック１０２５で表したように、クエリ、または適合後のクエリ、および任意選択の鍵を自律的ネットワークノード１０４１に送る。自律的ネットワークノード１０４１は、ブロック１０４３で表したように、クエリ、または適合後のクエリ、および任意選択の鍵を受信する。さらに、自律的ネットワークノード１０４１は、ブロック１０４５で表したように、受信した鍵、および、ネットワークノード１０４１に格納された認証鍵に基づいて、クエリ、または適合後のクエリが認証されているかどうかを判定することができる。自律的ネットワークノード１０４１は、次に、ブロック１０４７で表したように、この自律的データベースからのクエリへの応答、または適合後のクエリを取得する。自律的ネットワークノード１０４１は、ブロック１０４９で表したように、準連合ネットワークノード１０２１に応答を送る。
さらに、準連合ネットワークノード１０２１は、ブロック１０２９で表したように、応答を受信し、受信した応答に基づいて応答を設定する（または、自律的データベースを備える２つ以上のネットワークノードからの場合、受信した応答を結合する）。準連合ネットワークノード１０２１は、ブロック１０３１で表したように、別のデータベースを更新すること、リレーショナルデータベースモデル（例えばＭＬモデル）を適用すること、指示（例えば、テキストメッセージ、電子メール）を送ること、または同様のものなど、裁判管轄によって許可される他の機能を実施することができる。準連合ネットワークノード１０２１は、ブロック１０３３で表したように、連合ネットワークノード１００１に応答を送る。連合ネットワークノード１００１は、応答１０６３を受信し、次に、受信した応答１０６３に基づいて応答を設定する（または、自律的データベースを備える２つ以上のネットワークノードからの場合、受信した応答を結合する）。連合ネットワークノード１００１は、設定した応答（または結合した応答）を送ることができる。
図１９３は、本明細書で説明されるような様々な態様による連合データベースに問い合わせるためのシステム１１００の別の実施形態を示す。図１９３では、システム１１００は、一定の裁判管轄内に位置する、連合または準連合データベースを備えるネットワークノード１１０１、および自律的データベースを備えるネットワークノード１１４１ａを含む。準／連合ネットワークノード１１０１は、ブロック１１０３で表したように、クエリ、このクエリについてのランダムなソルト、および任意選択の鍵１１６１ａを自律的ネットワークノード１１４１ａに送る。
図１９３では、自律的ネットワークノード１１４１ａは、ブロック１１４３ａで表したように、クエリ、ランダムなソルト、および任意選択の鍵を受信する。自律的ネットワークノード１１４１ａは、ブロック１１４５ａで表したように、受信した鍵、および自律的ネットワークノード１１４１ａに格納された認証鍵に基づいて、クエリが認証されているかどうかを判定することができる。自律的ネットワークノード１１４１ａは、ブロック１１４７ａで表したように、この自律的データベースからのクエリへの応答を取得する。さらに、自律的ネットワークノード１１４１ａは、ブロック１１４９ａで表したように、受信したソルトに基づいて、応答内の識別可能情報を匿名化する。自律的ネットワークノード１１４１ａは、次に、ブロック１１５１ａで表したように、準／連合ネットワークノード１１０１に匿名情報を含む応答を送る。準／連合ネットワークノード１１０１は、ブロック１１０５で表したように、応答を受信する。また、準／連合ネットワークノード１１０１は、ブロック１１０９で表したように、受信した応答および匿名情報に基づいて、応答を設定する。準／連合ネットワークノード１１０１は、次に、ブロック１１０９で表したように、設定した応答を送ることができる。
別の実施形態では、連合ネットワークノード１１０１は、クエリ、ランダムなソルト、および任意選択の鍵を自律的ネットワークノード１１４１ａ、１１４１ｂに送る。自律的ネットワークノード１１４１ａ、１１４１ｂは、同じ裁判管轄または異なる裁判管轄内に位置することができる。各自律的ネットワークノード１１４１ａ、１１４１ｂは、クエリ、ランダムなソルト、および任意選択の鍵を受信し、受信した鍵、およびこの自律的ネットワークノード１１４１ａ、１１４１ｂに格納された認証鍵に基づいて、クエリが認証されているかどうかを判定することができる。各自律的ネットワークノード１１４１ａ、１１４１ｂは、その自律的データベースからのクエリへの応答を取得する。さらに、各自律的ネットワークノード１１４１ａ、１１４１ｂは、受信したソルトに基づいて、クエリへの応答内の識別可能情報を匿名化する。各自律的ネットワークノード１１４１ａ、１１４１ｂは、次に、匿名情報を含む応答を連合ネットワークノード１１０１に送る。連合ネットワークノード１１０１は、各応答を受信し、ブロック１１０５、１１０７でそれぞれ表したように、匿名情報に基づいて、クエリへの応答を結合する。連合ネットワークノード１１０１は、次に、ブロック１１０９で表したように、クライアントデバイスなどに、結合した応答を送ることができる。
図１９４は、本明細書で説明されるような様々な態様による連合データベースに問い合わせるためのシステム１２００の別の実施形態を示す。図１９４では、連合データベース１２０１は、裁判管轄１２０３内に位置する。連合データベース１２０１は、それぞれの裁判管轄１２１３、１２２３内に位置する準連合データベース１２１１、１２２１を表す。さらに、各準連合データベース１２１１、１２２１は、それぞれの裁判管轄１２１１、１２２１内に位置するそれぞれの自律的データベース１２１５～１２１７、１２２５～１２２７を表す。連合データベース１２０１は、準連合データベース１２１１、１２１１を介して、これらのそれぞれの自律的データベースも表す。
１つの実施形態では、連合データベース１２０１は、１つまたは複数の第１のプライバシ制約を伴う第１の裁判管轄１２１３内に位置する１つまたは複数の第１の自律的データベース１２１５～１２１７を備える第１の準連合データベース１２１１を表す。
追加または代替として、連合データベース１２０１は、１つまたは複数の第２のプライバシ制約を伴う第２の裁判管轄１２２３内に位置する１つまたは複数の第２の自律的データベース１２２５～１２２７を備える第２の準連合データベース１２２３を表す。
別の実施形態では、連合データベース１２０１は、１つまたは複数のプライバシ制約を伴う一定の裁判管轄１２１３内に位置する単一の自律的データベース１２１５を表す。
別の実施形態では、連合データベース１２０１は、１つまたは複数のプライバシ制約を伴う同じ裁判管轄１２１３内に位置する複数の自律的データベース１２１５～１２１７を表す。
別の実施形態では、連合データベース１２０１は、１つまたは複数の異なるプライバシ制約を伴う異なる裁判管轄１２１３、１２２３内に位置する複数の自律的データベース１２１５～１２１７、１２２５～１２２７を表す。
図１９５は、本明細書で説明されるような様々な態様によるネットワークノードの別の実施形態を示す。いくつかの事例では、ネットワークノード１３００は、サーバ、基地局、コアネットワークノード、ハンドヘルドコンピュータ、デスクトップコンピュータ、ラップトップコンピュータ、タブレット型コンピュータ、セットトップボックス、テレビ、アプライアンス、医療デバイス、または他のいくつかの同様の用語として言及されることもある。他の例では、ネットワークノード１３００は、ハードウェア構成要素のセットであってもよい。図１９５では、ネットワークノード１３００は、無線周波数（ＲＦ）インターフェース１３０９、ネットワーク接続インターフェース１３１１、ランダムアクセスメモリ（ＲＡＭ）１３１７、リードオンリメモリ（ＲＯＭ）１３１９、ストレージ媒体１３３１、もしくは同様のものを含むメモリ１３１５、通信サブシステム１３５１、電源１３３３、別の構成要素、またはこれらの任意の組合せに動作可能なように連結されたプロセッサ１３０１を含むように設定することができる。メモリ１３１５は、１つまたは複数のデータベースを格納するために使用することができる。ストレージ媒体１３３１は、オペレーティングシステム１３３３、アプリケーションプログラム１３３５、データまたはデータベース１３３７、あるいは同様のものを含むことができる。特定のデバイスは、図１３に示した構成要素の全て、または構成要素のサブセットだけを利用することができ、統合のレベルは、デバイスごとに変化してもよい。さらに、特定のデバイスは、複数のプロセッサ、メモリ、トランシーバ、送信機、受信機等など、構成要素の複数のインスタンスを収めることができる。例えば、コンピューティングデバイスは、プロセッサおよびメモリを含むように設定することができる。
図１９５では、プロセッサ１３０１は、コンピュータ命令およびデータを処理するように設定することができる。プロセッサ１３０１は、（例えば、ディスクリートロジック、ＦＰＧＡ、ＡＳＩＣ等における）１つもしくは複数のハードウェア実行ステートマシン、適切なファームウェアを合わせたプログラム可能ロジック、１つもしくは複数のストアドプログラム、適切なソフトウェアを合わせたマイクロプロセッサもしくはデジタル信号プロセッサ（ＤＳＰ）などの汎用プロセッサ、または上記の任意の組合せなどの、機械可読コンピュータプログラムとしてメモリに格納された機械語命令を実行するように動作可能な任意のシーケンシャルステートマシンとして設定することができる。例えば、プロセッサ１３０１は、２つのコンピュータプロセッサを含むことができる。１つの規定では、データは、コンピュータによる使用に適した形の情報である。様々なオペレーティングシステム、またはオペレーティングシステムの組合せを使用して本開示の主題を実行できることを当業者が認識するであろうということに留意することが重要である。
図１９５では、ＲＦインターフェース１３０９は、送信機、受信機、およびアンテナなどのＲＦ構成要素への通信インターフェースを提供するように設定することができる。ネットワーク接続インターフェース１３１１は、ネットワーク１３４３ａへの通信インターフェースを提供するように設定することができる。ネットワーク１３４３ａは、ローカルエリアネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）、コンピュータネットワーク、無線ネットワーク、テレコミュニケーションネットワーク、別の同様のネットワーク、またはこれらの任意の組合せなどの、有線および無線通信ネットワークを含むことができる。例えば、ネットワーク１３４３ａは、Ｗｉ－Ｆｉネットワークであってもよい。ネットワーク接続インターフェース１３１１は、イーサネット、ＴＣＰ／ＩＰ、ＳＯＮＥＴ、ＡＴＭ、または同様のものなど、当技術分野で知られた、または開発される可能性がある、１つまたは複数の通信プロトコルによる通信ネットワークで、１つまたは複数の他のノードと通信するために使用される受信および送信インターフェースを含むように設定することができる。ネットワーク接続インターフェース１３１１は、（例えば、光、電気などの）通信ネットワークリンクに適切な受信および送信機能を実行することができる。送信および受信機能は、回路構成要素、ソフトウェア、もしくはファームウェアを共有することができ、または代替として、別々に実装されてもよい。
本実施形態では、ＲＡＭ１３１７は、オペレーティングシステム、アプリケーションプログラム、およびデバイスドライバなどのソフトウェアプログラムの実行中に、データまたはコンピュータ命令のストレージまたはキャッシュを提供するために、バス１３０３を介してプロセッサ１３０１にインターフェースするように設定することができる。ＲＯＭ１３１９は、コンピュータ命令またはデータをプロセッサ１３０１に提供するように設定することができる。例えば、ＲＯＭ１３１９は、不揮発性メモリに格納された、基本入出力（Ｉ／Ｏ）、始動、またはキーボードからのキーストロークの受信などの基本システム機能のための、不変の低レベルシステムコードまたはデータであるように設定することができる。ストレージ媒体１３３１は、ＲＡＭ、ＲＯＭ、プログラマブルリードオンリメモリ（ＰＲＯＭ）、消去可能プログラマブルリードオンリメモリ（ＥＰＲＯＭ）、電気的消去可能プログラマブルリードオンリメモリ（ＥＥＰＲＯＭ）、磁気ディスク、光ディスク、フロッピーディスク、ハードディスク、取外し可能カートリッジ、フラッシュドライブなどのメモリを含むように設定することができる。１つの例では、ストレージ媒体１３３１は、オペレーティングシステム１３３３、ウェブブラウザアプリケーション、ウィジェットもしくはガジェットエンジンまたは別のアプリケーションなどのアプリケーションプログラム１３３５、およびデータファイル１３３７を含むように設定することができる。
図１９５では、プロセッサ１３０１は、通信サブシステム１３５１を使用してネットワーク１３４３ｂと通信するように設定することができる。ネットワーク１３４３ａおよびネットワーク１３４３ｂは、同じネットワークもしくは複数のネットワーク、または異なるネットワークもしくは複数のネットワークであってもよい。通信サブシステム１３５１は、ネットワーク１３４３ｂと通信するために使用される１つまたは複数のトランシーバを含むように設定することができる。１つまたは複数のトランシーバは、ＩＥＥＥ８０２．ｘｘ、ＣＤＭＡ、ＷＣＤＭＡ、ＧＳＭ、ＬＴＥ、ＮＲ、ＮＢ ＩｏＴ、ＵＴＲＡＮ、ＷｉＭａｘ、または同様のものなどの、当技術分野で知られた、または開発される可能性がある、１つまたは複数の通信プロトコルによる別のネットワークノードまたはクライアントデバイスの１つまたは複数のリモートトランシーバと通信するために使用することができる。
別の例では、通信サブシステム１３５１は、ＩＥＥＥ８０２．ｘｘ、ＣＤＭＡ、ＷＣＤＭＡ、ＧＳＭ、ＬＴＥ、ＮＲ、ＮＢ ＩｏＴ、ＵＴＲＡＮ、ＷｉＭａｘ、または同様のものなどの、当技術分野で知られた、または開発される可能性がある、１つまたは複数の通信プロトコルによる別のネットワークノードまたはクライアントデバイスの１つまたは複数のリモートトランシーバと通信するために使用される１つまたは複数のトランシーバを含むように設定することができる。各トランシーバは、（例えば、周波数配分などの）ＲＡＮリンクに適切な送信または受信機能をそれぞれ実行するための送信機１３５３または受信機１３５５を含むことができる。さらに、各トランシーバの送信機１３５３および受信機１３５５は、回路構成要素、ソフトウェア、またはファームウェアを共有することができ、または代替として、別々に実装されてもよい。
現在の実施形態では、通信サブシステム１３５１の通信機能は、データ通信、音声通信、マルチメディア通信、Ｂｌｕｅｔｏｏｔｈなどの短距離通信、近距離無線通信、位置を判定するための全地球測位システム（ＧＰＳ：ｇｌｏｂａｌ ｐｏｓｉｔｉｏｎｉｎｇ ｓｙｓｔｅｍ）の使用などの位置に基づく通信、別の同様の通信機能、またはこれらの任意の組合せを含むことができる。例えば、通信サブシステム１３５１は、セルラ通信、Ｗｉ－Ｆｉ通信、Ｂｌｕｅｔｏｏｔｈ通信、およびＧＰＳ通信を含むことができる。ネットワーク１３４３ｂは、ローカルエリアネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）、コンピュータネットワーク、無線ネットワーク、テレコミュニケーションネットワーク、別の同様のネットワーク、またはこれらの任意の組合せなどの、有線および無線通信ネットワークを含むことができる。例えば、ネットワーク１３４３ｂは、セルラネットワーク、Ｗｉ－Ｆｉネットワーク、および近距離無線ネットワークであってもよい。電源１３１３は、ネットワークノード１３００の構成要素に交流電流（ＡＣ）または直流電流（ＤＣ）の電力を提供するように設定することができる。
図１９５では、ストレージ媒体１３３１は、独立ディスクの冗長アレイ（ＲＡＩＤ）、フロッピーディスクドライブ、フラッシュメモリ、ＵＳＢフラッシュドライブ、外部ハードディスクドライブ、サムドライブ、ペンドライブ、キードライブ、高密度デジタル多用途ディスク（ＨＤ－ＤＶＤ）光ディスクドライブ、内部ハードディスクドライブ、ブルーレイ光ディスクドライブ、ホログラフィーデジタルデータストレージ（ＨＤＤＳ）光ディスクドライブ、外部ミニデュアルインラインメモリモジュール（ＤＩＭＭ）シンクロナスダイナミックランダムアクセスメモリ（ＳＤＲＡＭ）、外部マイクロＤＩＭＭ ＳＤＲＡＭ、加入者識別モジュールまたはリムーバブルユーザ識別（ＳＩＭ／ＲＵＩＭ）モジュールなどのスマートカードメモリ、他のメモリ、またはこれらの任意の組合せなどの、いくつかの物理ドライブユニットを含むように設定することができる。ストレージ媒体１３３１は、データをオフロードするため、またはデータをアップロードするために、一時的または非一時的メモリ媒体に格納されたコンピュータ実行可能命令、アプリケーションプログラム、または同様のものに、ネットワークノード１３００がアクセスすることを可能にすることができる。通信システムを利用するものなどの製品は、コンピュータ可読媒体を含むことができるストレージ媒体１３３１に現実に含めることができる。
本明細書で説明される方法の機能は、ネットワークノード１３００の構成要素の１つで実行されてもよく、または、ネットワークノード１３００の複数の構成要素にわたって分割されてもよい。さらに、本明細書で説明された方法の機能は、ハードウェア、ソフトウェア、またはファームウェアの任意の組合せで実行することができる。１つの例では、通信サブシステム１３５１は、本明細書で説明される構成要素のいずれかを含むように設定することができる。さらに、プロセッサ１３０１は、このような構成要素のいずれかとバス１３０３で通信するように設定することができる。別の例では、このような構成要素のいずれかは、プロセッサ１３０１によって実行されると、本明細書で説明される対応する機能を実施する、メモリに格納されたプログラム命令で表されてもよい。別の例では、このような構成要素のいずれかの機能は、プロセッサ１３０１と通信サブシステム１３５１との間に分割されてもよい。別の例では、このような構成要素のいずれかの計算負荷の大きくない機能が、ソフトウェアまたはファームウェアで実行されてもよく、計算負荷の大きな機能が、ハードウェアで実行されてもよい。
本明細書における実施形態が、対応するコンピュータプログラムをさらに含むことも当業者は認識するであろう。コンピュータプログラムは、装置の少なくとも１つのプロセッサで実行されると、上記で説明したそれぞれの処理のいずれかを装置に実行させる命令を含む。コンピュータプログラムは、この点に関して、上記で説明した手段またはユニットに対応する１つまたは複数のコードモジュールを備えることができる。実施形態は、このようなコンピュータプログラムを収める担体をさらに含む。この担体は、電子信号、光信号、無線信号、またはコンピュータ可読ストレージ媒体の１つを含むことができる。
この点に関して、本明細書における実施形態は、非一時的コンピュータ可読（ストレージまたは記録）媒体に格納され、装置のプロセッサによって実行されると、上記で説明したように装置に実施させる命令を含む、コンピュータプログラム製品も含む。実施形態は、コンピュータプログラム製品がコンピューティングデバイスによって実行されたとき、本明細書における実施形態のいずれかのステップを実施するためのプログラムコード部分を含むコンピュータプログラム製品をさらに含む。このコンピュータプログラム製品は、コンピュータ可読記録媒体に格納されてもよい。
さらなる実施形態をここで説明する。これらの実施形態の少なくともいくつかは、例証のために、一定の背景および／または無線ネットワークタイプに適用可能なものとして説明することがあるが、実施形態は、明示的に説明されない他の背景および／または無線ネットワークタイプに同様に適用可能である。
前述のように、現在の連合型、準連合型、および自律的データベースは、クエリを実施するときに、裁判管轄法を考慮していない。したがって、本開示は、この問題に対する実施形態を説明し、裁判管轄内、または裁判管轄間の、データベースシステム間の個人識別可能情報に基づいてデータが結合されなければならないときのための統計学的クエリの実施についての種々の方法を使用することを含む。
１つの例示的実施形態では、データベースシステムを結合する必要がある他の任意の適合を含む、正式な裁判管轄規制に基づいてクエリおよび応答を適合させる修正された連合データベースシステムにクエリが送られる。自律的データベースは、「識別情報」、「機密情報」、「一般情報」、「裁判管轄Ｘへの輸出規制」、「非営利用途のみ」、「低減した解像度を輸出することができる」（例えば、位置、画像、所得のような数字）などのようなタグなど、自律的データベースが収める情報のタイプでデータに注釈をつける。これらのタグは、関連付けられたデータに対する連合または準連合データベースによる処理／トランザクションを正式なものにする。したがって、連合または準連合データベースは、クエリを適合させる方法を連合または準連合データベースに知らせるために、自律的データベースからこれらのタグを受信する。
別の実施形態では、同じまたは異なる裁判管轄内に位置するもう１つの自律的データベースを表し、各識別情報が自律的データベースの１つの中にある、連合または準連合データベースを備えるデータベースシステム内で統計学的動作を必要とするクエリについて、連合または準連合データベースは、各自律的データベースにクエリを送る。さらに、連合または準連合データベースは、各自律的データベースから結果を受信し、次に、１つまたは複数の統計学的動作に基づいて結果を結合する。例えば、（例えば、識別情報、時間、およびウェブページのログを用いて）いくつかの自律的データベースからのデータに基づいてウェブページへの訪問をカウントすることに関連付けられたクエリについて、連合または準連合データベースは、クエリへの各応答でカウントを実施し、次に、カウントを結合する。これらの統計学的動作は、中央値、平均、合計、いくつかのデータベースを利用する先進的なフィルタリング、または同様のものに関連付けられてもよい。さらに、これらの統計学的動作は、ベクトル、テーブル、列、または同様のものに関連付けられてもよい。
別の実施形態では、裁判管轄内の自律的データベースからの応答を結合することを必要とし、このような結合を許可する、裁判管轄からのものを含む、異なる裁判管轄からの応答を受信するクエリについて、異なる裁判管轄内の１つまたは複数の準連合データベースを備える連合データベースを含むデータベース階層が使用されてもよく、各準連合データベースは、同じ裁判管轄内の１つまたは複数の自律的データベースを表す。例えば、この階層は、異なる裁判管轄（例えば異なる地方）内の人物からのウェブページへの訪問をカウントするために使用することができる。さらに、各準連合データベースは、同じ裁判管轄内にある各自律的データベースから受信したクエリへの応答を結合する。連合データベースは、次に、各準連合データベースからの応答を結合する。
別の実施形態では、連合データベースは、各準連合データベースにクエリを送る。各準連合データベースは、任意の識別情報を抽出するためにクエリを分割する。例えば、ウェブページの訪問、各ウェブページ訪問者の識別情報のログ、および各ウェブページの訪問の時間を含む第１の自律的データベースと、各ウェブページ訪問者の識別情報、各ウェブページ訪問者のアドレス、および各アドレスが地方のアドレスであるかどうかについての指示を含む、第１の自律的データベースと同じ裁判管轄内の第２の自律的データベースと、を表す準連合データベースからのデータに基づいて、地方のアドレスからのウェブページへの訪問をカウントすることに関連付けられたクエリについて、準連合データベースは、ウェブページを訪れた各カウントから識別した情報を抽出するためにクエリを分割することになる。したがって、準連合データベースは、分割したクエリを第２のデータベースに送り、地方のアドレスの識別情報を受信する。さらに、準連合データベースは、地方のアドレスからの個々のカウントを小計カウントに加算し、小計カウントは、連合データベースに送られる。連合データベースは、総カウントを取得するために、各準連合データベースからの小計カウントを加算する。
追加または代替として、異なる裁判管轄内の自律的または準連合データベースからの応答を結合する連合データベースについて、自律的または準連合データベースは、連合データベースが応答を結合する前に、クエリへの応答を匿名化することができる。ランダムソルトを使用する一方向暗号学的ハッシュ関数を利用することができ、新しいソルトは、各クエリが匿名情報を生成するために使用される。さらに、ソルトのいずれかおよび全てのレコードは、連合または準連合データベースによって、各クエリ（１つのクエリは、例えばいくつかのＳＱＬステートメントを収めることができ、ただ１つのステートメントに限定されない）の処理の完了時に破棄することができる。したがって、クエリの処理中のみ、匿名情報から識別可能情報を導出することができる。さらに、匿名情報から識別可能情報を導出することについての演算的複雑性を考えると、この簡単なクエリ処理期間中に識別可能情報を導出できる可能性は小さい。
さらに、連合データベースは、ランダムソルトを作り出し、ランダムソルトを各クエリまたはサブクエリとともに、自律的または準連合データベースに送る。さらに、連合、準連合、および自律的データベースのデータベース階層は、同じ一方向暗号学的ハッシュ関数をソルトともに使用して、各応答とともに送られる識別可能情報を匿名化する。したがって、連合データベースは、同じ識別可能情報に対応する同じ匿名情報を含む自律的または準連合データベースからの応答を受信し、例えば、各地方のアドレスについてのウェブページへの訪問を、この地方のアドレスについての匿名情報に基づいてカウントできるようにする。
１つの例では、このウェブページから購入を生じるウェブページへの訪問の数をカウントすることに関するクエリは、連合データベースによって処理される。連合データベースは、ウェブページ訪問ログを含む第１の自律的データベースを表し、第１のデータベースは、識別した情報が裁判管轄から輸出されるのを許可されない裁判管轄内にある。さらに、第２の自律的データベースは、クレジットカード情報を保持し、第２のデータベースは、第１のデータベースとは異なる裁判管轄内にあり、識別可能情報は、この裁判管轄から輸出されるのを許可されない。また、第１および第２のデータベースは、同じ識別可能情報を収める。連合データベースは、第１のクエリについてのランダムなソルトを生成し、第１のクエリおよびランダムなソルトを第１のデータベースに送る。第１のデータベースは、第１のクエリおよびソルトを受信し、ウェブページ訪問ログに関連付けられた第１のクエリへの応答を取得し、ランダムなソルトおよび一方向暗号学的ハッシュ関数に基づいて応答の識別可能情報（例えば訪問者の名前）を匿名化し、匿名情報を伴う応答を連合データベースに送る。
さらに、連合データベースは、第２のクエリおよびランダムなソルトを第２のデータベースに送る。第２のデータベースは、第２のクエリおよびソルトを受信し、クレジットカード情報に関連付けられたクエリへの応答を取得し、ランダムなソルトおよび一方向暗号学的ハッシュ関数に基づいて応答の識別可能情報（例えばクレジットカード所有者）を匿名化し、匿名情報を伴う応答を連合データベースに送る。連合データベースは、匿名情報に基づいて、受信した応答を結合する。
一方向暗号学的ハッシュ関数は、連合データベースによって同様に結合することができる識別可能情報以外のデータカテゴリに適用することができる。さらに、この結合処理は、カテゴリベースのデータに適用することができる。例えば、カテゴリベースのデータは、医療診断データ、低減された解像度の位置、都市、または同様のものを含むことができる。さらに、連合データベースシステムは、クラスタまたは結合から特定の診断または都市を識別できないように、カテゴリベースのデータをクラスタ化または結合することができる。
別の実施形態では、機密スカラ情報のための他の一方向関数に対して、準同形暗号化スキームを使用することができる。これは、この暗号化された機密スカラ情報を伴う応答が、連合データベースによって比較されること（例えば、より大きい、より小さい、に相当する、など）を可能にする。これは、同じ準同形暗号化スキームおよび鍵を自律的データベースが使用することを必要とする。ランダムなソルトは、連合データベースシステムによって、前述のような同じ手法で自律的または準連合データベースに提供することができる。
クエリは、構造化問合せ言語（ＳＱＬ：ｓｔｒｕｃｔｕｒｅｄ ｑｕｅｒｙ ｌａｎｇｕａｇｅ）クエリ、非ＳＱＬ（ＮＯＱＬ）クエリ、グラフデータベースクエリ、リレーショナルデータベースクエリ、分析クエリ（例えば、ＳｐａｒｋまたはＨａｄｏｏｐ）、機械学習クエリ、深層学習クエリ、情報へのウェブベースフロントエンドクエリ（ｗｅｂ－ｂａｓｅｄ ｆｒｏｎｔ－ｅｎｄ ｔｏ ｉｎｆｏｒｍａｔｉｏｎ ｑｕｅｒｙ）などを含むものと理解されるべきである。
実際のデータに基づいて手動でまたは自動的に注釈をつけることができる。後者の１つの例は、名前であり、またはアドレスは、識別した情報として自動的に認識することができ、医療記録または位置情報は、機密情報として識別することができ、顔を示す画像は、非営利用途のみに注釈をつけることができる、等である。
無線通信ネットワークと有線通信ネットワークとの間の連係動作
上述のように、進行中のリサーチの難題は、５ＧとＴＳＮの連係動作である。何らかの方法で配置されなければならない通信決定論を実現して、産業用ネットワークのためのエンドツーエンドの決定論的ネットワーキングを可能にするために、両方の技術が、ネットワーク運営および設定ならびに種々のメカニズムについての独自の方法を規定する。
５Ｇ－ＴＳＮ連係動作の１つの方式は、５ＧシステムをＴＳＮブリッジとして機能させることである。５Ｇネットワークは、上記で説明したような、選ばれたＴＳＮ設定モデルに応じて、ＴＳＮネットワークに向けたいくつかの制御インターフェースを提供する必要がある。中央設定モデルでは、中央制御エンティティＣＵＣ／ＣＮＣが、５Ｇネットワークの両側で発生することがある。さらに、単一のエンドポイントだけしかＵＥの背後に描写されていない図５とは対照的に、様々なトポロジのＴＳＮネットワークを両側に展開することができる。５ＧネットワークがＴＳＮブリッジとして機能する場合、例えばブリッジおよびエンドポイントといったＴＳＮ対応デバイスが、５Ｇネットワークの両側に展開されることが要求される。
３ＧＰＰ ＴＳ２３．５０１のセクション５．６．１０．２では、５Ｇネットワークにおけるタイプイーサネットのプロトコルデータユニット（ＰＤＵ：Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ）セッションのサポートが説明されている。ＰＤＵセッションアンカー（ＰＳＡ：ＰＤＵ Ｓｅｓｓｉｏｎ Ａｎｃｈｏｒ）ＵＰＦとデータネットワーク（ＤＮ：Ｄａｔａ Ｎｅｔｗｏｒｋ）との間のＮ６インターフェース上で、タイプイーサネットのＰＤＵセッションについての２つの潜在的なオプションが説明される。第１に、Ｎ６インターフェースとＰＤＵセッションとの間の１対１のマッピング、および、第２のオプションとして、複数のＰＤＵセッションのＭＡＣアドレスに基づくＮ６インターフェースへのマッピングを含むことができる。本明細書で説明されるソリューションは、いずれかの設定オプションに適用することができる。
図１９６は、３ＧＰＰ ＴＳ２９．５６１で説明されるような、イーサネットタイプＰＤＵセッションのためのＰＳＡ ＵＰＦにおけるプロトコル推移、すなわち、ＵＰＦにおけるイーサネットフレームハンドリングを示す。
５Ｇを使用したデバイスの接続を可能にするために利用可能な方法はなく、５ＧネットワークでのＴＳＮネットワークへのＴＳＮ特徴の限定的セットをサポートしない、または限定的セットしかサポートしない。
ＴＳＮストリームとしてＴＳＮドメインに（上記で説明したように）登録されていないＴＳＮネットワークにブリッジされた任意のトラフィックは、サービス品質（ＱｏＳ：ｑｕａｌｉｔｙ－ｏｆ－ｓｅｒｖｉｃｅ）を保証しないベストエフォートトラフィックとしてハンドリングされることになる。このように、エンドツーエンドＱｏＳを、保証することができない。
したがって、例えば５Ｇネットワークといった無線通信ネットワークと、例えばＴＳＮネットワークといった有線通信ネットワークとの間で、ＱｏＳが保証されたエンドツーエンド接続を可能にするための方法を提供することが、本明細書における実施形態の目的である。
本明細書における実施形態によれば、ソリューションは、ＴＳＮネットワークに５Ｇで接続されているデバイスのために一定のＴＳＮ特徴をハンドリングする５Ｇユーザプレーンにおける機能を規定する。したがって、ソリューションは、エンドツーエンドのＱｏＳを保証した５ＧとＴＳＮネットワークとの間の連係動作を可能にする。この機能は、仮想エンドポイント（ＶＥＰ：Ｖｉｒｔｕａｌ Ｅｎｄｐｏｉｎｔ）と呼ぶことがある。ＶＥＰは、例えば最上位でそれぞれ動くＵＥまたはアプリケーションといった、５Ｇデバイスの役割に応じて、仮想リスナおよび／または仮想トーカとして実現することができる。
ＶＥＰは、任意のＴＳＮ設定モードで、したがって、上記で紹介したように、分散型、集中型、または完全集中型で使用することができる。
分散型ＴＳＮ設定モデルの場合、ＶＥＰは、ＴＳＮネットワーク内の最も近いスイッチに直接通信することができる。完全集中型モデルでは、ＶＥＰは、ＣＵＣへの参照ポイントであってもよい。
複数のＶＥＰインスタンスを５Ｇネットワークで実行することができる。ＴＳＮでは、１つのエンドポイントが、複数のＴＳＮストリームを使用して通信することができる。ＴＳＮ観点からのＶＥＰは、単一のエンドポイントである。最も一般的なシナリオでは、ＶＥＰも、５Ｇネットワークにおける１つのＰＤＵセッションを伴う１つの５Ｇデバイスに対応する。１つのＴＳＮストリームからのトラフィックは、１つのＱｏＳフローにＶＥＰにおいてマッピングされることになり、逆もまた同様である。複数のＴＳＮストリームからのトラフィックは、同じＰＤＵセッション内の複数のＱｏＳフローにマッピングされることになる。
５Ｇユーザプレーンに仮想エンドポイント（ＶＥＰ）機能を展開することによって複数の利益を実現することができる。
・エンドツーエンドＱｏＳが保証されたＴＳＮネットワークに非ＴＳＮデバイスを接続することができる。
・エンドツーエンドＱｏＳが保証されたＴＳＮネットワークに非イーサネットデバイスを接続することができる。
・例えば、エアインターフェース上での設定を回避するために、または、エンドポイントもしくはブリッジにおいて機能を欠いている場合に、５ＧネットワークにおいてＴＳＮ特徴を中心的に実行することができる。
・例えば、リンクレイヤディスカバリプロトコル（ＬＬＤＰ）、時刻同期等の、ＴＳＮおよびイーサネット制御トラフィックを、５Ｇ無線インターフェース上で搬送する必要がなく、ＶＥＰによってハンドリングされる。
本明細書における実施形態によれば、ＴＳＮネットワークに５Ｇエンドポイントを接続するというソリューションは、新しい５Ｇユーザプレーン機能を展開することである。新しい５Ｇユーザプレーン特徴は、５ＧおよびＴＳＮ部分を含むネットワークにおけるエンドツーエンドＱｏＳが保証された接続を可能にする。展開される機能または特徴は、仮想エンドポイント（ＶＥＰ）と呼ばれることがある。
産業ドメインからＶＥＰを使用できる包括的な例が図１９７に示されており、図１９７は、産業用セットアップにおいて連係動作する５Ｇ－ＴＳＮを示す。この中の５Ｇエンドポイントは、５Ｇネットワークに無線接続された産業用ロボットであってもよい。ロボットは、工場の製造現場にあってもよい。例えばプログラマブルロジックコントローラ（ＰＬＣ）といった、対応するロボットコントローラは、例えば工場のＩＴルーム内のＴＳＮネットワークに接続される。エンドツーエンドＱｏＳ対応方式でコントローラに通信できるようになるロボットについて、上記で説明したように、同じＴＳＮドメインに両方が属する必要がある。ＶＥＰは、ＴＳＮ特徴の完全なセットまたは一部、および、ＴＳＮ－５Ｇ連係動作に必要な５Ｇ ＱｏＳ機能への対応するマッピングを実行する。
ＶＥＰは、ユーザプレーン機能（ＵＰＦ）の近くに、またはその一部として、５Ｇユーザプレーンにおいて実行される。ＶＥＰは、５Ｇネットワークにおいて、およびＴＳＮネットワークにおいて、ＱｏＳをマッピングすることを担当し、設定に含まれる。
ＶＥＰは、タイプイーサネットまたはタイプＩＰのＰＤＵセッションのために使用することができる。最も一般的なシナリオでは、ＶＥＰは、１つのＱｏＳフローからのトラフィックを１つのＴＳＮストリームにマッピングするために使用することができ、逆もまた同様である。それでも、１つまたは複数のＴＳＮストリームと１つまたは複数のＱｏＳフローとの間のトラフィックを、１つのＶＥＰインスタンスを使用してマッピングすることも可能になることがある。これは、１つのＰＤＵセッションに対して１つのＶＥＰインスタンスを使用することを意味する。さらに、複数のＰＤＵセッションからのトラフィックを単一のＶＥＰに結合することも可能になることがある。
複数のＶＥＰインスタンスは、１つのＵＰＦ内で使用することができる。１つのＰＤＵセッションに対して１つのＶＥＰインスタンスが使用される場合、複数のＴＳＮストリームをこのＶＥＰに接続すること、および、例えば、上記で説明したように、ＰＤＵセッション内の複数のＱｏＳフローに１対１でマッピングすることができる。
図１９８は、例えばＵＥの背後にある非イーサネット、非ＴＳＮデバイスといった、例えばタイプＩＰのＰＤＵセッションに対して、全てのイーサネットおよびＴＳＮ制御プレーントラフィックがＶＥＰにおいてハンドリングされる場合に、ＶＥＰを展開するときの、制御およびユーザプレーンのフローを示す。
図１９９は、タイプＩＰの、またはタイプイーサネットのＰＤＵセッションに対してＵＰＦの一部としてＶＥＰがどのように実行されるかを示す。パケットフィルタリングのようなＵＰＦのさらなる機能は、ここでは表示されていないが、ＶＥＰとともに使用することもできる。ＴＳＮを完全にサポートしないＰＤＵセッションのためのＶＥＰが、タイプイーサネットのＰＤＵセッションと同時にＵＰＦ内で使用されてもよく、ここで、ＴＳＮは、図２００にも示されているように、５Ｇネットワークを横切る２つのエンドポイント間のエンドツーエンドでサポートされる。
ＶＥＰの主な機能は、以下の通りである。
・ＴＳＮストリームへのＰＤＵセッションのマッピング（ＰＤＵセッションがタイプＩＰのものである場合、関連するものだけ、そうでなければ、これは、ＵＰＦにおいて行われる標準アクションである）。
・ＴＳＮストリームまたはＰＤＵセッションまたはＱｏＳフローの確立または修正、および、これに対応した異なるＱｏＳドメインの変換。
・８０２．１Ｑｂｖで規定されているような時間認識トラフィック形成、および、このために使用される８０２．１ＡＳ－ｒｅｖで規定されているような時刻同期のような、ＴＳＮにおいて使用される一定のユーザおよび制御プレーン特徴の実行およびサポート。
・ＴＳＮドメインにおけるＣＵＣおよびまたは最も近いＴＳＮブリッジとのインターフェース。
ＶＥＰは、上記で説明したように、１つまたは複数のＰＤＵセッションまたはＱｏＳフローに１つまたは複数のＴＳＮストリームをマッピングする。したがって、ＶＥＰは、マッピングテーブルを内部で維持する。マッピングのために、ＶＥＰは、ＴＳＮストリームＩＤまたはＰＤＵセッションＩＤまたはＱｏＳフローＩＤ（ＱＦＩ：ＱｏＳ Ｆｌｏｗ ＩＤ）をそれぞれ使用することができる。例えば１つのＴＳＮストリームへの１つのＱｏＳフローの１対１のマッピングの場合、このマッピングは、当然、より単純である。
タイプＩＰのＰＤＵセッションが使用される場合、ＶＥＰは、ローカル媒体アクセス制御（ＭＡＣ：Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）アドレスのプールからの、または、例えば手動で割り当てられたＭＡＣアドレスのような別のソースからの、ＭＡＣアドレスを使用することになる。したがって、外部イーサネットＤＮネットワークへの、ＩＰ ＰＤＵセッションからのＩＰパケットのイーサネット転送が可能である。このＭＡＣアドレスは、ＤＮに向けて通知され、ＴＳＮ制御インスタンスに向けてさらにポピュレートされることになる。
マッピングのために、ＶＥＰが、８０２．１ＡＳ、８０２．１Ｑｂｖ、８０２．１Ｑｃｃ等のような、様々なＴＳＮ特徴もサポートできることがさらに必要である。
ＰＤＵセッションを作り出すことまたは修正することができるようにするために、ＶＥＰは、５Ｇネットワーク内でＳＭＦをインターフェースする必要があることがある。このインターフェースは、ＵＰＦの一部としてＶＥＰが実装される場合、既存のＮ４インターフェースを使用して行うことができる。さらに、下記は、２つの実施形態の方法であり、トーカ、すなわちデータの送信機、またはリスナ、すなわちデータの受信機として機能する、ＶＥＰと５Ｇエンドポイントとの間の一連の通信を説明する。
５Ｇエンドポイントがトーカである場合の手順。
１． ５Ｇエンドポイントにおけるアプリケーションが、ＵＥからの通信リンクをリクエストすることになる。
２． ＵＥ ＰＤＵセッションが、ＶＥＰ／ＵＰＦへの既存の１つをリクエストまたは使用する。
３． ＶＥＰが、以下のいずれか、または組合せによって、ＴＳＮストリームに要求されるＱｏＳを推定する。
ａ． ＴＳＮストリームのＱｏＳへのＵＥによって選択されたＱｏＳフローＩＤ（ＱＦＩ）のマッピング
ｂ． ＵＥまたは最上位のアプリケーションによって示されたＴＳＮに固有の専用アプリケーションＱｏＳ
ｃ． ＴＳＮネットワークのためのＶＥＰ内の事前設定されたＱｏＳ設定
ｄ． ＴＳＮネットワークのためのＴＳＮネットワーク内のＣＵＣによるチェックＱｏＳ設定
４． ＱｏＳ設定に基づいて、ＶＥＰは、ＴＳＮストリームを確立すること、あるいは、ＱｏＳ設定を既存のＴＳＮストリームにマッピングすること、または、例えば８０２．１Ｑｃｃにおいて規定されているように、ＴＳＮ特徴を使用することによってＶＥＰが認識していなければならないＴＳＮネットワークがどのように設定されるかに応じて、ＣＮＣもしくはＣＵＣに向けたＴＳＮストリームのセットアップを始めること、を行おうとすることになる。
５． ＴＳＮストリームのセットアップが成功した場合、ユーザプレーン通信がスタートし、ＶＥＰが、次に、ＴＳＮネットワークで使用されるＴＳＮ特徴によって規定された必要なアクションを実施するだけでなく、上記で説明したようなＰＤＵセッションまたは特定のＱｏＳフローからのユーザプレーンパケットを、確立したＴＳＮストリームにマッピングすることになる。
１つの実施形態によれば、ステップ３）においてＴＳＮストリームに要求されるＱｏＳを推定するとき、ＶＥＰは、例えば、一方向もしくは往復レイテンシ、パケットエラー率、または信頼性指標等といった、５Ｇネットワーク内の、すなわちＶＥＰとエンドデバイスとの間の、内部通信性能パラメータを考慮する。ＶＥＰがＴＳＮネットワークにＱｏＳ要件を伝えるとき、ＶＥＰは、ＶＥＰとエンドポイントが同じであるとＴＳＮネットワークが「考える」ので、これらの内部性能パラメータを考慮する。したがって、例えば、Ｘｍｓという実際の要件を示す代わりに、要求されるエンドツーエンドレイテンシ値がＴＳＮネットワークに伝えられることになるとき、Ｘｍｓという、より厳しい要件（エンドデバイスに対するＶＥＰの遅延）が示される。内部通信性能パラメータを知るために、以下などの、５Ｇネットワーク内の通信プロトコルを使用することができる。
・ＶＥＰは、ＵＥ－ｇＮＢの測定値または推定値、すなわち５Ｇ無線インターフェース通信性能を取得するために、ｇＮＢと直接、またはさらなる５Ｇコア機能を介して通信する。例えば、レイテンシ測定値または推定値。ｇＮＢは、ＵＥ自体に対する測定値を使用することができ、どの程度良くまたは速く特定のＵＥをサーブすることができるかをさらに推定するために、独自のトラフィックまたは負荷状況も考慮することができる。
・ＶＥＰとＵＥとの間にプローブパケットを使用することができ、例えば、ＶＥＰとＵＥとの間のレイテンシを取得するために戻すことができる。
５Ｇエンドポイントがリスナである場合の手順。
１． ＴＳＮエンドポイントにおけるアプリケーションが、ＴＳＮストリームをリクエストすることになる、または、ＴＳＮストリームが、設定モデルに応じてＣＵＣによってリクエストされることになる。
２． ＴＳＮストリームリクエストが、ＶＥＰで受信されることになる。
３． ＶＥＰが、ＴＳＮストリームについてのＱｏＳも受信し、ＱｏＳを５Ｇ ＱｏＳにマッピングすることになる。マッピングは、固定設定用設定に基づいてもよい。５ＧネットワークがＱｏＳをサポートできないとＶＥＰが分析した場合、ＶＥＰは、ＴＳＮストリームリクエストを辞退することができる。
４． ＱｏＳ設定に基づいて、ＶＥＰが、新しいＰＤＵセッションを確立するか、既存のＰＤＵセッションを使用するか、リクエストされたＱｏＳを満たすために既存のＰＤＵセッションを修正することになる。
５． ＴＳＮストリームおよびＰＤＵセッションのセットアップが成功した場合、ユーザプレーン通信がスタートする。ＶＥＰは、次に、ＴＳＮネットワークで使用されるＴＳＮ特徴によって規定された必要なアクションを実施するだけでなく、対応するＰＤＵセッションおよびＱｏＳフローに、ＴＳＮストリームからのユーザプレーンパケットをマッピングすることになる。
１つの実施形態によれば、ステップ３）において、ＴＳＮストリームのＱｏＳを満たせるかどうかを判定できるようにするために、ＶＥＰは、ＶＥＰとエンドデバイスとの間の５Ｇ内部通信性能の測定値または推定値を考慮する。これらの測定値は、トーカ手順についてのステップ３）について上記で説明したように取得することができる。
ＶＥＰがサポートできる特定の特徴は、例えば、ＩＥＥＥ８０２．１Ｑｂｖで規定されるような時間認識スケジューリングをサポートするための、例えば、ＩＥＥＥ８０２．１ＡＳ－ｒｅｖにおいて説明されているような外部グランドマスタクロックへの時刻同期である。ＶＥＰは、時間認識ＴＳＮ通信のセットアップに関与し、時間認識していない５Ｇエンドポイントとの間でパケットを適宜転送することになる。
将来、５Ｇネットワークが、産業ユースケースを可能にするＴＳＮと連係動作することが想定される。このような状況では、複雑なＴＳＮ特徴をＵＥ側で実行することは、厄介なタスクになる。本明細書における実施形態は、ＴＳＮと５Ｇネットワークの連係動作を可能にする仮想エンドポイント（ＶＥＰ）と呼ばれる５Ｇユーザプレーンへの新しい特徴を提案する。これは、５Ｇを使用したＴＳＮネットワークへの、非ＴＳＮデバイス、およびさらに非イーサネットデバイスの接続もさらに可能にする。
例えば５Ｇといった無線通信ネットワークと、例えばＴＳＮネットワークといった有線通信ネットワークとの間のエンドツーエンド接続を可能にするための方法の実施形態の例を以下で説明する。
実施形態１：例えば５Ｇといった無線通信ネットワークと、例えばＴＳＮネットワークといった有線通信ネットワークとの間のエンドツーエンド接続を可能にするための通信ネットワークにおける方法。方法は、以下を含む。
・無線通信ネットワーク内に仮想エンドポイント（ＶＥＰ）を実装すること。
・有線通信ネットワークで使用される一定のユーザおよび制御プレーン特徴をＶＥＰに実装すること。
・サービス品質（ＱｏＳ）に基づいて、無線通信ネットワーク内のデバイスと、有線通信ネットワーク内のデバイスとの間のデータトラフィックを、ＶＥＰにおいてマッピングすること。
・有線通信ネットワークで使用される特徴によって規定された必要なアクションを実施すること。
いくつかの実施形態によれば、ＶＥＰは、ユーザプレーン機能（ＵＰＦ）の近くに、またはユーザプレーン機能（ＵＰＦ）の一部として、５Ｇネットワークユーザプレーン内で実装されてもよい。
いくつかの実施形態によれば、ＱｏＳに基づいて、無線通信ネットワーク内のデバイスと、有線通信ネットワーク内のデバイスとの間のデータトラフィックをマッピングすることは、ＴＳＮストリームまたはプロトコルデータユニット（ＰＤＵ）セッションまたはＱｏＳフローを確立または修正すること、および、これに対応して、異なるＱｏＳドメインを変換することを含むことができる。
実施形態２：有線通信ネットワークへのエンドツーエンド接続を可能にするための、無線通信ネットワークにおいて実行される仮想エンドポイント（ＶＥＰ）において実施される方法。方法は、以下を含む。
・無線通信ネットワークまたは有線通信ネットワーク内のデバイスからの通信リクエストを受信すること。
・要求されるＱｏＳを推定すること。
・要求されるＱｏＳに基づいて、無線通信ネットワーク内のデバイスと、有線通信ネットワーク内のデバイスとの間のデータトラフィックをマッピングすること。
・有線通信ネットワークで使用される特徴で規定された必要なアクションを実施すること。
無線通信ネットワークは、第５世代（５Ｇ）ネットワークであってもよく、有線通信ネットワークは、タイムセンシティブネットワーキング（ＴＳＮ）ネットワークであってもよい。通信セッションは、プロトコルデータユニット（ＰＤＵ）セッションであり、データストリームは、ＴＳＮストリームである。
実施形態３：有線通信ネットワークへのエンドツーエンド接続を可能にするための、無線通信ネットワークにおいて実行される仮想エンドポイント（ＶＥＰ）において実施される方法。無線通信ネットワーク内のエンドポイントまたはデバイスはトーカであり、方法は以下を含む。
・無線通信ネットワーク内のデバイスからの通信セッションリクエストを受信すること。
・有線通信ネットワークにおけるデータストリームに要求されるＱｏＳを推定すること。
・要求されるＱｏＳに基づいて、有線通信ネットワークにおけるデータストリームを確立すること。
・通信セッションまたは特定のＱｏＳフローからのユーザプレーンパケットを確立したデータストリームにマッピングすること。
・有線通信ネットワークで使用される特徴で規定された必要なアクションを実施すること。
無線通信ネットワークは、第５世代（５Ｇ）ネットワークであってもよく、有線通信ネットワークは、タイムセンシティブネットワーキング（ＴＳＮ）ネットワークであってもよい。通信セッションは、プロトコルデータユニット（ＰＤＵ）セッションであってもよく、データストリームは、ＴＳＮストリームであってもよい。
本明細書におけるいくつかの実施形態によれば、要求されるＱｏＳに基づいてデータストリームを確立することは、既存のデータストリームにマッピングすること、または、有線通信ネットワークにおけるデータストリームのセットアップを始めることを含む。
本明細書におけるいくつかの実施形態によれば、要求されるＱｏＳを推定することは、以下の１つまたは組合せによって実施することができる。
・デバイスによって選択されたＱｏＳフローＩＤ（ＱＦＩ）をＴＳＮストリームのＱｏＳにマッピングすること。
・デバイスによって示されたＴＳＮに固有の専用アプリケーションのＱｏＳを選ぶこと。
・ＴＳＮネットワークのためにＶＥＰ内で事前設定されたＱｏＳ設定から選ぶこと。
・ＴＳＮストリームのためにＴＳＮネットワーク内のＣＵＣでＱｏＳ設定をチェックすること。
実施形態４：有線通信ネットワークへのエンドツーエンド接続を可能にするための、無線通信ネットワークにおいて実行される仮想エンドポイント（ＶＥＰ）において実施される方法。無線通信ネットワーク内のエンドポイントまたはデバイスはリスナであり、方法は以下を含む。
・有線通信ネットワーク内のデバイスからのデータストリームリクエストを受信すること。
・データストリームについてのＱｏＳを受信すること。
・無線通信ネットワークのＱｏＳが、データストリームのＱｏＳを満たすかどうかをチェックすること。
・無線通信ネットワークのＱｏＳが、データストリームのＱｏＳを満たした場合、以下を行う。
ａ． データストリームについてのＱｏＳに基づいて、無線通信ネットワークにおける通信セッションを確立すること。
ｂ． 有線通信ネットワークで使用される特徴で規定された必要なアクションを実施すること。
本明細書におけるいくつかの実施形態によれば、データストリームのＱｏＳに基づいて通信セッションを確立することは、新しい通信セッションを確立すること、または、既存の通信セッションを使用すること、または、データストリームのＱｏＳを満たすように既存の通信セッションを修正することを含む。
分散された格納データに基づく動作の実施
データストレージでは、データは、例えば、迅速なデータ可用性を得るため、および／またはデータの破損／損失を防ぐために、いくつかのノードにしばしば複製される。したがって、同じデータのいくつかの表現が、異なるストレージエンティティに保存されることがある。例えば、クラウドベースシステムにおいて、およびエッジ計算システムにおいて、ストレージは、いくつかのノード（例えば、コンピュータ、サーバ、ストレージユニット等）にわたって、および、（例えば、キャッシュ、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）、フラッシュディスク、回転ディスク等の）動作のいくつかの階層にわたって、しばしば分散される。
異なるストレージエンティティに保存された、いくつかの表現として格納されたデータに基づいて動作のセットを実施することは、時間の浪費であることもあり、動作の実施の結果が提供されるまでのレイテンシは、いくつかの状況では受け入れられないほど大きくなることがある。
したがって、データの複数の表現が、複数のストレージエンティティのそれぞれの１つに保存される、データに基づいて動作のセットを実施するための代替アプローチが必要である。好ましくは、このようなアプローチは、動作のセットの実施の結果が提供されるまで、データクエリを送ることからのレイテンシの低下をもたらす。
上記または他の短所の少なくともいくつかを解決するか軽減する、緩和する、または除くことが、いくつかの実施形態の目的である。
第１の態様は、データの複数の表現が、複数のストレージエンティティのそれぞれの１つに保存される、データに基づいた動作のセットの実施の管理のためのコントローラの方法である。
方法は、（複数のストレージエンティティのうちの２つ以上のストレージエンティティのそれぞれのために）データに関するそれぞれのクエリをストレージエンティティに送ること、およびストレージエンティティに保存されたデータの表現を含む応答をストレージエンティティから受信することを含む。
方法は、（２つ以上のストレージエンティティのうちの少なくとも２つのそれぞれのために）応答に含まれるデータの表現に基づいて動作のセットの実施の活動を始めることも含む。
さらに、方法は、データの最終的な表現に基づくものとして開始後の活動～最終的な活動のうちの１つを（応答に含まれるデータの表現に基づいて）判定すること、および、データに基づいた動作のセットの実施についての結果として最終的な活動の結果を提供することを含む。
いくつかの実施形態では、動作のセットの実施の活動は、応答に含まれるデータの表現が、以前に受信した応答に含まれるデータの表現と異なるストレージエンティティのためだけに始められる。
いくつかの実施形態では、方法は、応答に含まれるデータの表現の中から過半数、または重みを付けた過半数判定を行うことによって、データの最終的な表現を判定することをさらに含む。
いくつかの実施形態では、最終的な活動の判定は、全ての開始後の活動が完了する前に実施される。
いくつかの実施形態では、活動は、最終的な活動の判定の前に始められる。
いくつかの実施形態では、最終的な表現は、２つ以上のストレージエンティティの少なくとも１つについてのストレージエンティティに保存されたデータの表現と同時に起こる。
いくつかの実施形態では、方法は、最終的な活動を判定することに応答して、最終的な表現に基づいていない開始後の活動をキャンセルすることをさらに含む。
いくつかの実施形態では、方法は、最終的な活動を判定することに応答して、最終的な表現に基づいているものを除いて、全ての開始後の活動をキャンセルすることをさらに含む。
いくつかの実施形態では、方法は、最終的な活動を判定する前に、データの最終的な表現に基づいているという確率が確率閾値を下回る開始後の活動をキャンセルまたは休止することをさらに含む。
いくつかの実施形態では、２つ以上のストレージエンティティのうちの少なくとも２つが、コントローラとストレージエンティティとの間で異なる信号遅延を含む。
いくつかの実施形態によれば、異なる信号遅延を含むことは、異なる信号遅延を含むことと解釈することができる。
いくつかの実施形態では、ストレージクライアントは、コントローラと、２つ以上のストレージエンティティのうちの１つとを備え、１つのストレージエンティティは、デフォルト表現または最新の既知の表現であるデータの表現を保存する。
第２の態様は、データの複数の表現が、複数のストレージエンティティのそれぞれの１つに保存される、データに基づいた動作のセットの実施の管理のためのコントローラの方法である。
方法は、（複数のストレージエンティティのうちの２つ以上のストレージエンティティのそれぞれのために）データに関するそれぞれのクエリをストレージエンティティに送ること、これにより、ストレージエンティティに保存されたデータの表現に基づいて動作のセットの実施の活動を開始すること、およびストレージエンティティに保存されたデータの表現の指標を含む応答をストレージエンティティから受信することを含む。
方法は、最終的な指標に対応するデータの表現に基づいているものとして開始後の活動～最終的な活動のうちの１つを（応答に含まれる指標に基づいて）判定すること、および、データに基づいた動作のセットの実施についての結果として最終的な活動の結果を提供することも含む。
いくつかの実施形態では、方法は、応答に含まれる指標の中から過半数、または重みを付けた過半数判定を行うことによって、最終的な指標を判定することをさらに含む。
いくつかの実施形態では、最終的な活動の判定は、全ての開始後の活動が完了する前に実施される。
いくつかの実施形態では、活動は、最終的な活動の判定の前に始められる。
いくつかの実施形態では、最終的な指標に対応するデータの表現は、２つ以上のストレージエンティティの少なくとも１つについてのストレージエンティティに保存されたデータの表現と同時に起こる。
いくつかの実施形態では、方法は、最終的な活動を判定することに応答して、最終的な指標に対応するデータの表現に基づいていない開始後の活動をキャンセルすることをさらに含む。
いくつかの実施形態では、方法は、最終的な活動を判定することに応答して、最終的な指標に対応するデータの表現に基づいているものを除いて、全ての開始後の活動をキャンセルすることをさらに含む。
いくつかの実施形態では、方法は、最終的な活動を判定する前に、最終的な指標に対応するデータの表現に基づいているという確率が確率閾値を下回る開始後の活動をキャンセルまたは休止することをさらに含む。
いくつかの実施形態では、２つ以上のストレージエンティティのうちの少なくとも２つが、コントローラとストレージエンティティとの間で異なる信号遅延を含む。
いくつかの実施形態によれば、異なる信号遅延を含むことは、異なる信号遅延を含むことと解釈することができる。
いくつかの実施形態では、ストレージクライアントは、コントローラと、２つ以上のストレージエンティティのうちの１つとを備え、１つのストレージエンティティは、デフォルト表現または最新の既知の表現であるデータの表現を保存する。
第１および第２の態様は、データの複数の表現が、複数のストレージエンティティのそれぞれの１つに保存される、データに基づいた動作のセットの実施の管理のためのコントローラの方法として説明することができる。
方法は、（複数のストレージエンティティのうちの２つ以上のストレージエンティティのそれぞれのために）データに関するそれぞれのクエリをストレージエンティティに送ること、およびストレージエンティティに保存されたデータの表現に関する情報（例えば、表現、または表現の指標を含む情報）を含む応答をストレージエンティティから受信することを含む。
方法は、（２つ以上のストレージエンティティのうちの少なくとも２つのそれぞれのために）データの表現に基づいて動作のセットの実施の活動を開始することも含む（開始は、例えば、クエリを送ることによって、または開始を実施することによって行うことができる）。
さらに、方法は、データの表現に関する最終的な情報に対応するデータの表現に基づいているものとして開始後の活動～最終的な活動のうちの１つを（応答に含まれるデータの表現に関する情報に基づいて）判定すること（最終的な情報は、例えば、データの最終的な表現、または最終的な指標であってもよい）、および、データに基づいた動作のセットの実施についての結果として最終的な活動の結果を提供することを含む。
一般に、最終的な活動は、動作のセットの実施の開始後の活動の１つである。動作のセットの実施の開始後の活動は、本明細書において後で、憶測の活動とも呼ばれる。したがって、この専門用語では、最終的な活動は、憶測の活動のうちの１つである。最終的な活動は、典型的には、データ一貫性判定に基づいて、開始後の活動の中から選ばれる。
データ一貫性判定は、例えば、データの表現の１つを最終的な表現として判定することができ、最終的な活動は、最終的な表現に基づいて開始された活動として選ぶことができる。例えば、受信した応答に含まれるデータの表現の中からの過半数判定は、最終的な表現を提供することができる。
代替または追加として、データ一貫性判定は、例えば、データの表現の指標の１つを最終的な指標として判定することができ、最終的な活動は、最終的な指標に対応するデータの表現に基づいて開始された活動として選ぶことができる。例えば、受信した応答に含まれる指標の中からの過半数判定は、最終的な指標を提供することができる。
第３の態様は、プログラム命令を備えるコンピュータプログラムを含む、非一時的コンピュータ可読媒体を備えるコンピュータプログラム製品である。コンピュータプログラムは、データ処理ユニットにロードすることができ、コンピュータプログラムがデータ処理ユニットによって実行されるとき、第１および第２の態様のいずれかによる方法を実行するように設定される。
第４の態様は、コントローラのための、および、データの複数の表現が、複数のストレージエンティティのそれぞれの１つに保存される、データに基づいた動作のセットの実施の管理のための装置である。
装置は、（複数のストレージエンティティのうちの２つ以上のストレージエンティティのそれぞれのために）データに関するそれぞれのクエリをストレージエンティティに送ること、およびストレージエンティティに保存されたデータの表現を含む応答をストレージエンティティから受信することを行うように設定された制御回路機器を備える。
制御回路機器は、また、（２つ以上のストレージエンティティのうちの少なくとも２つのそれぞれのために）応答に含まれるデータの表現に基づいて動作のセットの実施の活動を開始するように設定される。
さらに、制御回路機器は、データの最終的な表現に基づくものとして開始後の活動～最終的な活動のうちの１つを（応答に含まれるデータの表現に基づいて）判定すること、および、データに基づいた動作のセットの実施についての結果として最終的な活動の結果を提供することを行うように設定される。
第５の態様は、コントローラのための、および、データの複数の表現が、複数のストレージエンティティのそれぞれの１つに保存される、データに基づいた動作のセットの実施の管理のための装置である。
装置は、（複数のストレージエンティティのうちの２つ以上のストレージエンティティのそれぞれのために）データに関するそれぞれのクエリをストレージエンティティに送ること、これにより、ストレージエンティティに保存されたデータの表現に基づいて動作のセットの実施の活動を開始すること、およびストレージエンティティに保存されたデータの表現の指標を含む応答をストレージエンティティから受信することを行うように設定された制御回路機器を備える。
さらに、制御回路機器は、最終的な指標に対応するデータの表現に基づいているものとして開始後の活動～最終的な活動のうちの１つを（応答に含まれる指標に基づいて）判定すること、および、データに基づいた動作のセットの実施についての結果として最終的な活動の結果を提供することを行うように設定される。
第４および第５の態様は、コントローラのための、および、データの複数の表現が、複数のストレージエンティティのそれぞれの１つに保存される、データに基づいた動作のセットの実施の管理のための装置として説明することができる。
装置は、第１および第２の態様のいずれかの、または第１および第２の態様を結合した方法の方法ステップを行うように設定された制御回路機器を備える。
第６の態様は、第４および第５の態様のいずれかの装置を備えるストレージクライアントである。
第７の態様は、第４および第５の態様のいずれかの装置、ならびに／または第６の態様のストレージクライアントを備えるクライアントノードである。
いくつかの実施形態では、上記の態様のいずれかは、追加として、他の態様のいずれかについて上記で説明したような、様々な特徴のいずれかと同一の、または、これに対応する、特徴を有することができる。
いくつかの実施形態の長所は、データの複数の表現が、複数のストレージエンティティのそれぞれの１つに保存される、データに基づいた動作のセットを実施するために代替アプローチが提供されることである。
いくつかの実施形態の別の長所は、動作のセットの実施の結果が提供されるまでのデータクエリを送ることによるレイテンシの低減を実現できることである。
さらに、いくつかの実施形態の長所は、電力消費量の低減、および／または動作実施リソースの利用の低減を実現できることである。
さらに、さらなる長所は、動作のセットの実施の何らかの活動が始まる前にデータ一貫性が得られるときに達成される結果に、動作のセットの実施の結果が対応することである。
上述のように、それぞれのストレージエンティティによってそれぞれ保存された、いくつかの表現で格納されたデータに基づいて動作のセットが実施されることになるときに、レイテンシ問題が存在する可能性がある。
いくつかの表現で格納されたデータに基づいて動作のセットが実施されることになるとき、表現の２つ以上が典型的には取得され、動作のセットが実施されるときに、データのどの表現を使用するべきかを判定するために、データ一貫性判定（例えば過半数判定）が行われる。動作のセットを実施するために使用されるデータの表現は、データの最終的な表現と呼ぶことができる。
例えば、７つのデータの表現があり、表現のうちの４つが同一の（同時に起こる）場合、この表現は、過半数判定が適用される場合の最終的な表現として選択される。この例をさらに示すために、７つの表現のうちの４つが第１の値「ａ」を保持すること、７つの表現のうちの２つが第２の値「ｂ」を保持すること、および、７つの表現のうちの１つが第３の値「ｃ」を保持することを仮定する。次に、第１の値「ａ」を保持する表現が、７つの表現の中の過半数を占めているので、過半数の判定が適用される場合、最終的な表現は、第１の値「ａ」を保持する。
典型的には、データクエリを送った後、データの表現を取得できる前に遅延が存在する。遅延は、例えば、クエリを送るデバイスと、データの表現を保存するストレージエンティティとの間の地理的距離が比較的大きいとき、および／または、データの表現を保存するストレージエンティティが、低速アクセスストレージエンティティであるときなど、いくつかのケースで、より突出していることがある。さらに、遅延は、種々のストレージエンティティによって異なることがある。
例えば、（データの表現を含む）第１の応答は、例えば、データのこの表現がローカルに、および場合によっては、ことによると、問い合わせる当事者と同じ装置に含まれるメモリ／キャッシュに保存されている場合、クエリが送られた後、比較的速く到着することがある。データ一貫性を得ることが必要な（データの表現を含む）他の応答は、地理的に分散したシステムに対してクエリが送られた後、例えばおよそ１００ミリ秒以上といった、桁違いに後で到着することがある。
このように、データの表現は、異なる時間的ポイントに異なる遅延で到着することがある。これらの遅延問題は、全ての表現が取得されるまで、過半数判定（およびこれによる、データの最終的な表現に基づく動作の実施、およびその結果の提供）を先に延ばす。
以下では、データの複数の表現が、複数のストレージエンティティのそれぞれの１つに保存される、データに基づいた動作のセットの実施の管理のための実施形態を説明する。
コントローラ（例えば、制御回路機器または制御エンティティ／モジュール）は、動作のセットの実施を管理することができる。コントローラは、例えば、ストレージクライアント内に備えることができる。
データの複数の表現は、データについての真実のいくつかのソースを提供する。データの複数の表現は、例えば、一貫性ハンドリング、冗長性、信頼性、有効性、エラー保護、エラー検出、エラー訂正等の１つまたは複数のためのものであってもよい。
データの複数の表現の１つまたは複数は、同じデータの他の表現とは異なっていてもよい。例えば、いくつかの表現は、書込み動作を介して更新を終えていることがあり、一方で、他の表現は、（例えば信号遅延により）更新を終えていないことがある。
データは、１つまたは複数のスカラ値または複素数値、１つまたは複数のベクトル、１つまたは複数の行列、１つまたは複数の他のデータ構造、１つまたは複数のドキュメント、１つまたは複数のデータファイル、１つまたは複数の画像、１つまたは複数のビデオ、１つまたは複数のオーディオトラック等を含む（がこれらに限定されない）任意の適切な形式を保持することができる。
複数のストレージエンティティは、例えば、異なる（物理もしくは仮想）ノードにおけるストレージ、および／または、同じ（物理もしくは仮想）ノードにおける異なる階層におけるストレージを備えることができる。いくつかの実施形態では、異なる階層が、同じストレージ配置（例えば、同じデータセンタ、またはコンピュータの同じラック、におけるいくつかのコンピュータの配置）に含まれてもよい。
一般に、異なる階層は、大きい方の番号の階層に格納されたデータのいくつかの部分セットを小さい方の番号の階層が保存することを指すことができ、小さい方の番号の階層は、大きい方の番号の階層よりレイテンシが小さくなる。例えば、階層０は、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）であってもよく、階層１は、ソリッドステートドライブ（ＳＳＤ）ディスクであってもよく、階層２は、回転式ハードディスクであってもよい。
さらに、ストレージエンティティの１つまたは複数は、クラウドベースストレージを適用することができる。ストレージエンティティの全てというわけではないが、１つまたは複数は、動作のセットの実施を管理するコントローラのローカルストレージエンティティ（例えば、キャッシュメモリまたはレジスタ）であってもよい。例えば、ストレージクライアントは、デフォルト表現または最新の既知の表現であるデータの表現を保存するコントローラ、および１つのストレージエンティティを備えることができる。
このように、データの複数の表現の格納は、（例えば、異なる階層、異なるノード、異なる地理位置等の１つまたは複数にわたって）分散される。
いくつかの実施形態によれば、動作のセットの実施の活動は、データ一貫性判定が行われる前に始められる。典型的には、これは、動作のセットの実施がいくつかのインスタンスで始められ、インスタンスのそれぞれを、動作のセットの実施についての憶測の活動とみなすことができることを意味する。例えば、動作のセットの実施についての憶測の活動は、データのいくつかの表現（例えば、データのいくつかの一意の表現）のそれぞれに基づいて始められてもよい。
本明細書で使用されるとき、用語「動作のセットの実施の活動」は、例えば、動作のセットの実施を含む（または、からなる）活動を指すことができる。
動作のセットの実施についての憶測の活動は、データ一貫性判定が行われる前に、動作のセット（の少なくとも一部）を実施するものと規定することができる。典型的には、全ての始められた憶測の活動は、動作の同じセットの実施を含むが、動作のセットが基づいて実施されるデータの表現は、動作のセットの実施の始められた憶測の活動の間で異なっていてもよい。
次に、データ一貫性判定が行われたとき、いくつかの実施形態は、データ一貫性判定に対応するデータの表現に基づいていない動作のセットの実施についての憶測の活動をキャンセルすること（および場合によっては、データ一貫性判定に対応するデータの表現に基づいている動作のセットの実施についての重複した憶測の活動をキャンセルすること）を含む。いくつかの実施形態は、憶測の活動の１つもしくは複数が重複していても、および／または、データ一貫性判定に対応するデータの表現に基づいていなくても、データ一貫性判定が行われた後、憶測の活動の１つまたは複数を続けることを含むことができる。
一般に、動作のセットの実施の活動をキャンセルすることは、動作のセットの実施の活動を中止すること、停止すること、または途中で終わらせることとみなされてもよい。
いずれにせよ、データ一貫性判定が行われたとき、データ一貫性判定に対応するデータの表現に基づく動作のセットの実施についての憶測の活動の結果は、データに基づいた動作のセットの実施についての結果として提供することができる。
データ一貫性判定は、データの最終的な（一貫した）表現、および／またはデータの表現の最終的な（一貫した）指標を提供することとして、本明細書で呼ばれることになる。データの最終的な表現は、例えば、データの表現の１つに対応してもよい。データ一貫性判定は、例えば、データの取得した表現、またはデータの表現の取得した指標の中からの、例えば、過半数、または重みを付けた過半数判定といった、コンセンサスに基づく判定であってもよい。
憶測の活動での動作のセットの実施は、例えば、ソフトウェアコード部分を実行することを含むことができる。動作のセットは、実行ファイル、またはソフトウェアアーチファクトを含むことができる。代替または追加として、動作のセットは、ハードウェアでの実行を含むことができる。実行ファイル、またはソフトウェアアーチファクトの例は、ソフトウェア機能、方法、スクリプト、バイナリ実行可能モジュール、実行可能コンテキスト、ソフトウェアコード部分等を含む。動作のセットのこれらおよび／または他の例のいずれかは、憶測の活動で実施することができる。動作のセットの実施についての憶測の活動は、いくつかのシナリオでは、憶測による実行と呼ばれることがある。
図２０１は、いくつかの実施形態による実例の方法１００を示す。方法は、コントローラのための、および、データの複数の表現が、複数のストレージエンティティのそれぞれの１つに保存される、データに基づいた動作のセットの実施の管理のためのものである。
ステップ１１０において、複数のストレージエンティティのうちのストレージエンティティの集合体の各ストレージエンティティにそれぞれのクエリを送る。ストレージエンティティの集合体が複数のストレージエンティティからどのように選択されるかは、任意の適切なアプローチによってもよい。非常に多くのこのような適切なアプローチが、当技術分野で知られている。
クエリは、データに関連したものである。例えば、クエリは、データ（ストレージエンティティに保存されたデータの表現）についてのリクエストまたはプロンプトを含むことができる。
ステップ１２０において、エンティティの集合体のうちの２つ以上のストレージエンティティから応答（例えばクエリ応答）を受信する。応答は、応答を受信したストレージエンティティに保存されたデータの表現を含む。典型的には、応答は、ストレージエンティティとコントローラとの間の、異なるストレージエンティティによって異なる遅延により、異なる時間的ポイントで受信される。以前に述べたように、異なる遅延は、例えば、（例えば、異なる地理的距離による）異なる信号遅延によるもの、および／または異なるストレージアクセス時間によるものであってもよい。
図２０１では、第１のストレージエンティティ、第ｎのストレージエンティティ、第ｐのストレージエンティティ、および第ｘのストレージエンティティと表された４つのストレージエンティティによって、２つ以上のストレージエンティティが表されている。
いくつかの実施形態では、ストレージエンティティの集合体（すなわち、２つ以上のエンティティからなるストレージエンティティの集合体）における全てのストレージエンティティから応答を受信する。いくつかの実施形態では、ストレージエンティティの集合体（すなわち、２つ以上のエンティティ、および１つまたは複数の他のストレージエンティティからなるストレージエンティティの集合体）における全てではないストレージエンティティから応答を受信する。いずれにせよ、ストレージエンティティの集合体は、２つ以上のエンティティを備える。このように、ストレージエンティティの集合体のうちの各ストレージエンティティにそれぞれのクエリを送ることは、２つ以上のストレージエンティティのそれぞれにそれぞれのクエリを送ることを含む。
例えば、７つのストレージエンティティから応答を受信することができ、したがって、データの７つの表現を提供し、例えば、表現のうちの４つが値「ａ」を保持し、表現のうちの２つが値「ｂ」を保持し、表現のうちの１つが値「ｃ」を保持する。
ステップ１３０によって示されているように、次に、２つ以上のストレージエンティティのうちの少なくとも２つについて、動作のセットの実施の活動を始める。典型的には、対応する応答の受信に応答して、各開始が直接実施される。次に、異なる時間的ポイントで応答を受信した場合、開始は、異なる時間的ポイントで実施されることになる。
動作のセットは、コントローラ自体で、または、コントローラに接続された、もしくはそうでなければ関連付けられた装置で、実施することができる。例えば、動作のセットは、ストレージクライアントで実施されてもよく、または、分散して実施されてもよい（例えば、クラウドベースの実行）。
開始後の活動は、応答に含まれるデータの表現に基づく。
典型的には、動作のセットの実施の活動は、応答に含まれるデータの表現が、（動作のセットの実施についての同じリクエストに関連した）以前に受信した応答に含まれるデータの表現と異なるストレージエンティティについてのみ始められる。このように、動作のセットの実施の活動は、データの一意の表現についてのみ始められる。これには、動作のセットを実施するためにリソース（処理ハードウェア、電力消費量等）を必要以上に利用しないという長所がある。
例えば、動作のセットの実施の活動は、典型的には、（対応するステップ１３０について実線によって示されている）第１のストレージエンティティについて始められる。次に、それぞれの新しい応答に対して、応答に含まれるデータの表現が、既に受信した応答に含まれるデータの表現と一致するかどうかが判定される。
その場合、（対応するステップ１３０について断続線によって第ｎおよび第ｘのストレージエンティティについて示されている）このストレージエンティティについて動作のセットの実施のいずれの活動も始めないものと判定されてもよい。
応答に含まれるデータの表現が、既に受信した応答に含まれるデータの表現のいずれにも一致しない場合（すなわち、応答に含まれるデータの表現が一意である場合）、（対応するステップ１３０について実線によって第ｐのストレージエンティティについて示されている）このストレージエンティティについて動作のセットの実施の活動が始められる。
表現のうちの４つが値「ａ」を保持し、表現のうちの２つが値「ｂ」を保持し、表現のうちの１つが値「ｃ」を保持する７つの受信した応答を用いた例について、動作のセットの実施の３つの（憶測による）活動が、１つは値「ａ」に基づいて、１つは値「ｂ」に基づいて、１つは値「ｃ」に基づいて始められてもよい。
ステップ１５０において、動作のセットの実施の開始後の活動の１つは、データの最終的な表現に基づいているものと判定される。この活動は、最終的な活動と呼ばれる。このように、最終的な活動は、動作のセットの実施の開始後の活動の１つである。最終的な活動の判定は、応答に含まれるデータの表現に基づく。例えば、ステップ１５０は、応答に含まれるデータの表現の中からの過半数、または重みを付けた過半数判定を行うことによって、データの最終的な表現を判定すること、および、データの最終的な表現に対応する（例えば一致する）データの表現に基づく動作のセットの実施の開始後の活動として、最終的な活動を選択することを含むことができる。
データの最終的な表現を判定すること、および／または最終的な活動を判定することは、データ一貫性判定に含まれるとみなされてもよい。
このように、最終的な活動は、データ一貫性判定に基づいて、開始後の活動の中から選ばれ、データ一貫性判定は、最終的な表現としてデータの表現の１つを判定し、最終的な活動は、最終的な表現に基づいて開始した活動として選ばれる。
ステップ１５０は、ストレージエンティティの集合体の全てのストレージエンティティから応答を受信したときに実施することができる。代替として、ステップ１５０は、例えば、一定数の応答を受信したとき（例えば、数が閾値を超過する）、またはデータの同じ表現を含む一定数の応答を受信したとき（例えば、数が閾値を超過する）など、ストレージエンティティの集合体の全てのストレージエンティティから応答を受信する前に実施することができる。
典型的には、ステップ１５０は、動作のセットの実施の全ての開始後の活動が完了する前に実施される。
任意選択のステップ１６０で示されているように、最終的な活動を判定することに応答して、最終的な表現に基づいていない開始後の活動をキャンセルすることができる。代替または追加として、任意選択のステップ１６０で同様に示されているように、最終的な活動を判定することに応答して、最終的な表現に基づいているものを除き、全ての開始後の活動をキャンセルすることができる。
これには、動作のセットを実施するためにリソース（処理ハードウェア、電力消費量等）を必要以上に利用しないという長所がある可能性がある。
いくつかの実施形態では、最終的な活動以外の開始後の活動（例えば、全ての開始後の活動）も、最終的な活動が判定された後でも、完了できることに留意されたい。これは、例えば、動作の実施をキャンセルするより、動作の継続実施を許可することが、演算的におよび／または信号の点で安くなる場合、有益である可能性がある。
いくつかの実施形態では、任意選択のステップ１４０で示されているように、最終的な活動が判定される前でも、いくつかの開始後の活動をキャンセルまたは休止することができる。例えば、データの最終的な表現に基づいているという確率が確率閾値を下回る開始後の活動をキャンセルまたは休止することができる。
閾値は、ゼロに等しくてもよく（最終的な表現になるはずのない表現についてのみキャンセル／休止する）、または、ゼロより大きく１より小さくてもよい（最終的な表現になるはずのない表現について、および、最終的な表現になる可能性が低い表現についてキャンセル／休止する）。
最終的な表現に基づいているという確率は、中間のデータ一貫性判定を介して推定することができる。例えば、最終的な表現を判定するのに１０個の応答が必要な場合、かつ、データの第１の表現を含む８つの応答を一回、データの第２の表現を３回、およびデータの第３の表現を４回受信した場合、データの第１の表現が最終的な表現になり得ないことが明らかである。したがって、データの第１の表現に基づく動作のセットの実施の開始後の活動をキャンセルすることができる。
これには、動作のセットを実施するためにリソース（処理ハードウェア、電力消費量等）を必要以上に利用しないという長所がある可能性がある。
ステップ１７０において、データに基づく動作のセットの実施についての結果として、最終的な活動の結果を提供する（または提供することが行われる）。
最終的な活動は、データ一貫性判定の前に（動作のセットの実施についての憶測の活動の１つとして）始められるので、全体的なレイテンシは、動作のセットを実施する前にデータ一貫性判定が行われるときに比べて、減少させることができる。
表現のうちの４つが値「ａ」を保持し、表現のうちの２つが値「ｂ」を保持し、表現のうちの１つが値「ｃ」を保持する７つの受信した応答を用いた例を続けると、過半数判定が適用される場合、最終的な表現は値「ａ」を保持する。値「ｂ」に基づいて、および値「ｃ」に基づいて始められた２つの（憶測による）活動は、最終的な表現が判定されたときにキャンセルすることができ、値「ａ」に基づいて始められた（憶測による）活動の結果は、データに基づいた動作のセットの実施についての結果として提供することができる。
図２０２は、いくつかの実施形態による実例の方法１０５を示す。方法は、コントローラのための、および、データの複数の表現が、複数のストレージエンティティのそれぞれの１つに保存される、データに基づいた動作のセットの実施の管理のためのものである。
例えば、データの７つの表現は、異なるストレージエンティティに保存されてもよく、例えば、表現のうちの４つが値「ａ」を保持し、表現のうちの２つが値「ｂ」を保持し、表現のうちの１つが値「ｃ」を保持する。
ステップ１１０において、複数のストレージエンティティのうちのストレージエンティティの集合体の各ストレージエンティティにそれぞれのクエリを送る。ストレージエンティティの集合体が複数のストレージエンティティからどのように選択されるかは、任意の適切なアプローチによってもよい。非常に多くのこのような適切なアプローチが、当技術分野で知られている。
クエリは、データに関するものである。例えば、クエリは、データ（ストレージエンティティに保存されたデータの表現）についてのリクエストまたはプロンプト、または、データの表現の指標についてのリクエストを含むことができる。指標は、データより簡単に伝えることができる（例えば、よりコンパクトであってもよい）。指標は、データ（の表現）から導出することができる。例えば、指標は、データの圧縮バージョン、データのハッシュ関数、データのチェックサム、データ指紋、データの暗号学的ハッシュ関数等であってもよい。
さらに、クエリは、第１のストレージエンティティ、第ｎのストレージエンティティ、第ｐのストレージエンティティ、および第ｘのストレージエンティティと表された４つの実例のストレージエンティティについて、サブステップ１３５によって示されているように、ストレージエンティティに保存されたデータの表現に基づいて動作のセットの実施の活動を開始するように設定される。これは、例えば、動作リクエスト、ソフトウェア機能識別子、実行ファイル、または同様のものをクエリに含めることによって実現することができる。開始後の活動は、ストレージエンティティに保存されたデータの表現に基づく。典型的には、各開始は、クエリの受信に応答して直接実施される。
動作のセットは、対応するストレージエンティティにおいて実施することができる。動作のセットは、ストレージエンティティ自体で、または、ストレージエンティティに接続されるか、そうでなければ関連付けられた装置で、実施することができる。例えば、動作のセットは、分散して実施されてもよい（例えば、クラウドベースの実行）。
例えば、ＳＱＬ（構造化問合せ言語）クエリは、応答を返す前に、動作のセットの実施の活動を始めることができる。このような活動の例は、簡単な処理（例えば、合計）および高度な処理（例えば、登録済のソフトウェア機能の実行）を含む。
表現のうちの４つの表現が値「ａ」を保持し、表現のうちの２つが値「ｂ」を保持し、表現のうちの１つが値「ｃ」を保持する７つの表現を用いた例について、動作のセットの実施の７つの（憶測による）活動を、４つは値「ａ」に基づいて、２つは値「ｂ」に基づいて、および１つは値「ｃ」に基づいて始めることができる。
ステップ１２５において、エンティティの集合体のうちの２つ以上のストレージエンティティから応答（例えばクエリ応答）を受信する。応答は、応答を受信したストレージエンティティに保存されたデータの表現の指標を含む。典型的には、応答は、ストレージエンティティとコントローラとの間の、異なるストレージエンティティによって異なる遅延により、異なる時間的ポイントで受信される。以前に述べたように、異なる遅延は、例えば、（例えば、異なる地理的距離による）異なる信号遅延によるもの、および／または異なるストレージアクセス時間によるものであってもよい。
いくつかの実施形態では、ストレージエンティティの集合体（すなわち、２つ以上のエンティティからなるストレージエンティティの集合体）における全てのストレージエンティティから応答を受信する。いくつかの実施形態では、ストレージエンティティの集合体（すなわち、２つ以上のエンティティ、および１つまたは複数の他のストレージエンティティからなるストレージエンティティの集合体）における全てではないストレージエンティティから応答を受信する。いずれにせよ、ストレージエンティティの集合体は、２つ以上のエンティティを備える。このように、ストレージエンティティの集合体のうちの各ストレージエンティティにそれぞれのクエリを送ることは、２つ以上のストレージエンティティのそれぞれにそれぞれのクエリを送ることを含む。
典型的には、応答は、動作のセットの実施の開始後の活動が完了する前に受信される。
ステップ１５０において、最終的な指標に対応するデータの表現に基づいているものとして、動作のセットの実施の開始後の活動の１つを判定する。動作のセットの実施のこの活動は、最終的な活動と呼ばれる。このように、最終的な活動は、動作のセットの実施の開始後の活動の１つである。
最終的な活動の判定は、応答に含まれるデータの表現の指標に基づく。例えば、ステップ１５０は、応答に含まれる指標の中から過半数、または重みを付けた過半数判定を行うことによって、最終的な指標を判定すること、および、最終的な指標に対応するデータの表現に基づく動作のセットの実施の開始後の活動として、最終的な活動を選択することを含むことができる。
最終的な指標を判定すること、および／または最終的な活動を判定することは、データ一貫性判定に含まれるとみなされてもよい。
このように、最終的な活動は、データ一貫性判定に基づいて、開始後の活動の中から選ばれ、データ一貫性判定は、最終的な指標としてデータの表現の指標の１つを判定し、最終的な活動は、最終的な指標に対応するデータの表現に基づいて開始した活動として選ばれる。
好ましくは、最終的な活動は、最初に完了することが期待される、開始後の活動として、最終的な指標に対応する表現に基づく開始後の活動の中から選択される。
ステップ１５０は、ストレージエンティティの集合体の全てのストレージエンティティから応答を受信したときに実施することができる。代替として、ステップ１５０は、例えば、一定数の応答を受信したとき（例えば、数が閾値を超過する）、または、同じ指標を含む一定数の応答を受信したとき（例えば、数が閾値を超過する）といった、ストレージエンティティの集合体の全てのストレージエンティティから応答を受信する前に実施することができる。
典型的には、ステップ１５０は、動作のセットの実施の全ての開始後の活動が完了する前に実施される。
任意選択のステップ１６０によって示されているように、最終的な活動を判定することに応答して、最終的な指標に対応する表現に基づいていない動作のセットの実施の開始後の活動は、キャンセルすることができる。代替または追加として、任意選択のステップ１６０によって同様に示されているように、動作のセットの実施の全ての開始後の活動は、最終的な指標に対応する表現に基づいているものを除いて、最終的な活動を判定することに応答して、キャンセルすることができる。
これには、動作のセットを実施するためにリソース（処理ハードウェア、電力消費量等）を必要以上に利用しないという長所がある可能性がある。
いくつかの実施形態では、最終的な活動以外の開始後の活動（例えば、全ての開始後の活動）も、最終的な活動が判定された後でも、完了できることに留意されたい。これは、例えば、動作の実施をキャンセルするより、動作の継続実施を許可することが、演算的におよび／または信号の点で安くなる場合、有益である可能性がある。
いくつかの実施形態では、任意選択のステップ１４０によって示されているように、動作のセットの実施のいくつかの開始後の活動は、最終的な活動が判定される前でも、キャンセルまたは休止することができる。例えば、データの最終的な指標に対応する表現に基づいているという確率が確率閾値を下回る開始後の活動をキャンセルまたは休止することができる。
確率閾値は、ゼロに等しくてもよく（最終的な指標になるはずのない指標に対応する表現についてのみキャンセル／休止する）、または、ゼロより大きく１より小さくてもよい（最終的な指標になるはずのない指標に対応する表現について、および、最終的な指標になる可能性の低い指標に対応する表現について、キャンセル／休止する）。
最終的な指標に対応する表現に基づいているという確率は、図２０１に関して上記で説明したように、中間のデータ一貫性判定を介して推定することができる。
これには、動作のセットを実施するためにリソース（処理ハードウェア、電力消費量等）を必要以上に利用しないという長所がある可能性がある。
ステップ１７０において、データに基づく動作のセットの実施についての結果として、最終的な活動の結果を提供する（または提供することが行われる）。
最終的な活動は、データ一貫性判定の前に（動作のセットの実施についての憶測の活動の１つとして）始められるので、全体的なレイテンシは、動作のセットを実施する前にデータ一貫性判定が行われるときに比べて、減少させることができる。
表現のうちの４つの表現が値「ａ」を保持し、表現のうちの２つが値「ｂ」を保持し、表現のうちの１つが値「ｃ」を保持する７つの表現を用いた例を続けると、４つが（値「ａ」を保持する表現から導出可能な）値「ａ１」を保持する指標を含み、２つが（値「ｂ」を保持する表現から導出可能な）値「ｂ１」を保持する指標を含み、１つが（値「ｃ」を保持する表現から導出可能な）値「ｃ１」を保持する指標を含む７つの応答を受信することができる。したがって、最終的な指標は、過半数判定が適用される場合、（値「ａ」を保持する表現に対応する）値「ａ１」を保持する。値「ａ」に基づいて始められた４つの（憶測による）活動のうちの３つだけでなく、値「ｂ」に基づいて始められた２つの（憶測による）活動、および値「ｃ」に基づいて始められた（憶測による）活動も、最終的な表現が判定されたとき、キャンセルすることができる。値「ａ」に基づいて始められたキャンセルされない（憶測による）活動の結果は、データに基づいた動作のセットの実施についての結果として提供することができる。
図２０３は、図２０１の方法１００を実行するいくつかの実施形態を例示するための方法ステップおよびシグナリングを示す。
図２０３は、アプリケーション（ＡＰＰ）２０１およびストレージクライアント（ＳＣ）２０２を備えるクライアントノード（ＣＮ）２００を概略的に示し、ストレージクライアント（ＳＣ）２０２は、ストレージクライアントライブラリ（ＳＣＬ）２０３およびローカルストレージエンティティ（ＳＥ）２０４を備える。ローカルストレージエンティティは、例えば、キャッシュメモリであってもよい。図２０３は、３つのストレージノード（ＳＮ）２９１、２９２、２９３も概略的に示し、ストレージノード２９１は、ストレージエンティティ（ＳＥ）２９４を備え、ストレージノード２９２は、２つのストレージエンティティ（ＳＥ）２９５、２９６を備え、ストレージノード２９３は、ストレージエンティティ（ＳＥ）２９７を備える。２つのストレージエンティティ２９５、２９６は、例えば、階層０のストレージエンティティ２９５、および階層１のストレージエンティティ２９６であってもよい。
ストレージクライアントおよび／またはストレージクライアントライブラリは、データに基づいた動作のセットの実施の管理のための、図２０１の方法１００を実施するように設定されたコントローラを備えるものと解釈されてもよい。ストレージエンティティ２０４、２９４、２９５、２９６、２９７のそれぞれの１つに、データの複数の表現が保存される。
図２０３の処理は、アプリケーション２０１でスタートし、ストレージクライアント２０２にトリガ信号２８０を送る。トリガ信号は、典型的には、例えば、クエリおよびソフトウェア機能識別子を含むことができる。トリガ信号２８０は、２０５によって示されているように、ストレージクライアントライブラリ２０３で受信される。
ステップ２１０において（図２０１のステップ１１０に似ている）、それぞれのクエリ２８１ａ～２８１ｅが、ストレージエンティティのそれぞれに送られる。それぞれのクエリは、典型的には、トリガ信号２８０に基づいていてもよい。例えば、トリガ信号２８０に含まれるクエリは、クエリ２８１ａ～２８１ｅとして使用してもよく、またはクエリ２８１ａ～２８１ｅに変換してもよい。
ステップ２２０ａ～２２０ｅにおいて（図２０１のステップ１２０に似ている）、ストレージエンティティのそれぞれから応答２８２ａ～２８２ｅが受信される。応答は、応答を受信したストレージエンティティに保存されたデータの表現を含む。応答は、ストレージエンティティとストレージクライアントライブラリとの間の異なるストレージエンティティよって異なる遅延により、異なる時間的ポイントで受信される。
まず、ステップ２２０ａにおいて、ローカルストレージエンティティ２０４から応答２８２ａが受信される。ローカルストレージエンティティ２０４に保存され、応答２８２ａに含まれるデータの表現に基づく動作のセットの実施の活動が、ステップ２３０ａ（図２０１のステップ１３０に似ている）によって示されているような、応答２８２ａの受信、および開始信号２８３ａに応答して始められる。この例では、ローカルストレージエンティティ２０４についての動作のセットは、２３１ａによって示されているように、ストレージクライアントで実施される。
その後、ステップ２２０ｂにおいて、ストレージエンティティ２９４から応答２８２ｂが受信される。応答２８２ｂに含まれるデータの表現が、応答２８２ａに含まれるデータの表現と異なるかどうかがチェックされる。その場合、ストレージエンティティ２９４に保存され、応答２８２ｂに含まれるデータの表現に基づく動作のセットの実施の活動が、ステップ２３０ｂ（図２０１のステップ１３０に似ている）によって示されているような、応答２８２ｂの受信、および開始信号２８３ｂに応答して始められる。この例では、ストレージエンティティ２９４についての動作のセットも、２３１ｂによって示されているように、ストレージクライアントで実施される。
さらにその後、ステップ２２０ｃ～２２０ｅにおいて、ストレージエンティティ２９５、２９６、２９７から応答２８２ｃ～２８２ｅが受信される。各応答について、応答に含まれるデータの表現が以前に受信したいずれかの応答に含まれるデータの表現と異なるかどうかがチェックされる。その場合、ストレージエンティティに保存され、応答に含まれるデータの表現に基づく動作のセットの実施の活動が、応答の受信に応答して始められる（図２０１のステップ１３０に似ている）。そうでない場合、新しい動作のセットの実施の活動は始まらない。後者は、応答２８２ｃ～２８２ｅに関する図２０３の例についての場合である。
例えば、応答２８２ｃおよび２８２ｅは、応答２８２ａに含まれるデータの表現と一致したデータの表現を含むことができ、応答２８２ｄは、応答２８２ｂに含まれるデータの表現と一致したデータの表現を含むことができる。
ステップ２５０（図２０１のステップ１５０に似ている）において、動作のセットの実施の開始後の活動２３１ａ、２３１ｂの１つは、データの最終的な表現に基づいているものと判定される。最終的な活動の判定は、応答に含まれるデータの表現に基づいている。例えば、ステップ２５０は、応答に含まれるデータの表現の中から過半数判定を行うことによってデータの最終的な表現を判定すること、および、データの最終的な表現と一致したデータの表現に基づく動作のセットの実施の開始後の活動として最終的な活動を選択することを含むことができる。
図２０３の例では、開始後の活動２３１ａは、最終的な活動と判定される。これは、例えば、応答２８２ａ～２８２ｅの過半数２８２ａ、２８２ｃ、２８２ｅに含まれていたデータの表現に基づいているということによるものであってもよい。
最終的な活動２３１ａを判定することに応答して、開始後の活動２３１ｂは、最終的な表現に基づいていないので、ステップ２６０（図２０１のステップ１６０に似ている）およびキャンセル信号２８４によって示されているように、キャンセルされる。
最終的な活動が完了したとき、その結果２８５は、ステップ２７０（図２０１のステップ１７０に似ている）および結果信号２８６によって示されているように、データに基づく動作のセットの実施についての結果としてアプリケーション２０１に提供される。
図２０４は、図２０２の方法１０５を実行するいくつかの実施形態を例示するための方法ステップおよびシグナリングを示す。
図２０４は、アプリケーション（ＡＰＰ）３０１およびストレージクライアント（ＳＣ）３０２を備えるクライアントノード（ＣＮ）３００を概略的に示し、ストレージクライアント（ＳＣ）３０２は、ストレージクライアントライブラリ（ＳＣＬ）３０３を備える。図２０４は、３つのストレージノード（ＳＮ）３９１、３９２、３９３も概略的に示し、ストレージノード３９１は、ストレージエンティティ（ＳＥ）３９４を備え、ストレージノード３９２は、２つのストレージエンティティ（ＳＥ）３９５、３９６を備え、ストレージノード３９３は、ストレージエンティティ（ＳＥ）３９７を備える。２つのストレージエンティティ３９５、３９６は、例えば、階層０のストレージエンティティ３９５、および階層１のストレージエンティティ３９６であってもよい。
ストレージクライアントおよび／またはストレージクライアントライブラリは、データに基づく動作のセットの実施の管理のために、図２０２の方法１０５を実施するように設定されたコントローラを備えるものと解釈されてもよい。データの複数の表現は、ストレージエンティティ３９４、３９５、３９６、３９７のそれぞれの１つに保存される。
図２０４の処理は、アプリケーション３０１が、ストレージクライアント３０２にトリガ信号３８０を送ることによってスタートする。トリガ信号は、典型的には、例えばクエリおよびソフトウェア機能識別子を含むことができる。トリガ信号３８０は、３０５によって示されているように、ストレージクライアントライブラリ３０３で受信される。
ステップ３１０では（図２０２のステップ１１０に似ている）、それぞれのクエリ３８１ｂ～３８１ｅが、ストレージエンティティのそれぞれに送られる。それぞれのクエリは、典型的には、トリガ信号３８０に基づいていてよい。例えば、トリガ信号３８０に含まれるクエリは、クエリ３８１ｂ～３８１ｅとして使用することができるか、クエリ３８１ｂ～３８１ｅに変換することができる。
クエリ３８１ｂ～３８１ｅは、データに関するものである。例えば、クエリ３８１ｂ～３８１ｅは、データのハッシュ関数についてのリクエストを含むことができる。さらに、クエリ３８１ｂ～３８１ｅは、３３１ｂ～３３１ｅによって示されているように、ストレージエンティティに保存されたデータの表現に基づく動作のセットの実施の活動を開始する（図２０２のサブステップ１３５に似ている）ように設定される。
ステップ３２０ｂ～３２０ｅにおいて（図２０２のステップ１２５に似ている）、応答３８２ｂ～３８２ｅは、ストレージエンティティのそれぞれから受信される。応答は、応答を受信したストレージエンティティに保存されたデータの表現の指標（この例では、ハッシュ関数）を含む。応答は、ストレージエンティティとストレージクライアントライブラリとの間の異なるストレージエンティティによって異なる遅延により、異なる時間的ポイントで受信される。
例えば、応答３８２ｂ、３８２ｃ、および３８２ｅは、同じ指標値（ハッシュ値）を含むことができ、応答３８２ｄは、別の指標（ハッシュ値）を含むことができる。
ステップ３５０において（図２０２のステップ１５０に似ている）、動作のセットの実施の開始後の活動３３１ｂ～３３１ｅの１つが、最終的な指標に対応するデータの表現に基づいているものと判定される。最終的な活動の判定は、応答に含まれる指標に基づいている。例えば、ステップ３５０は、応答に含まれる指標の中から過半数判定を行うことによって最終的な指標を判定すること、および、最終的な指標に対応するデータの表現に基づく動作のセットの実施の開始後の活動として最終的な活動を選択することを含むことができる。
図２０４の例では、開始後の活動３３１ｂは、最終的な活動と判定される。これは、例えば、応答３８２ｂ～３８２ｅの過半数３８２ｂ、３８２ｃ、３８２ｅに含まれたデータの表現に基づくことによるもの、ならびに、開始後の活動３３１ｃおよび３３１ｅの前に完了することが期待されることによるものであることがある。
最終的な活動３３１ｂを判定することに応答して、開始後の活動３３１ｃ～３３１ｅは、最終的な指標に対応する表現に基づいていない、または、最終的な活動の重複とみなされるので、ステップ３６０（図２０２のステップ１６０に似ている）およびキャンセル信号３８４ｃ～３８４ｅによって示されているように、キャンセルされる。
最終的な活動が完了すると、その結果３８５は、ステップ３７０（図２０２のステップ１７０に似ている）および結果信号３８６によって示されているように、データに基づく動作のセットの実施についての結果としてアプリケーション３０１に提供される。
上述の方法のトリガ（信号２８０、３８０をトリガすることに似ている）のいくつかの例をここで示す。このようなトリガは、例えば、アプリケーションインターフェースで実行することができる。
典型的には、アプリケーションは、動作のセットの憶測による実施（例えば、憶測による実行）をトリガするためにストレージクライアントに命令を送る。命令は、典型的には、動作リクエスト、ソフトウェア機能識別子、実行ファイル、または同様のものを含む。
例えば、（アプリケーションの）実行可能な画像におけるシンボルまたは位置を参照することによって、実行可能なブロブのコピーによって、解釈可能なコードまたはスクリプトによって、バイトコードのコピーまたはバイトコードへの参照によって、等、多くの異なる方式で実行ファイルを表すことができる。
命令は、憶測による実行のスケジューリングのためのスケジューリングポリシも含むことができる。実例のスケジューリングポリシは、（第１の開始した実行をできる限り早期に終了できるように）処理スピードを連続的に遅くして、リソース上での憶測による実行の開始をスケジューリングすることになる可能性がある。
命令は、例えば、他の場所で宣言された実行ファイル、ソフトウェア機能またはライブラリ等へのいずれかのコールの前に宣言されたデータ構造といった、コンテキストも含むことができる。
命令は、クエリをさらに含むことができる。クエリは、例えば、値探索の鍵として、ＳＱＬクエリとして、グラフクエリとして、等、多くの方式で作ることができる。
直接アプリケーションインターフェースの例は、以下のような疑似コードで表現することができる。
ｄｅｆ ｍｙｆｕｎｃ（ｖａｌｕｅ）：
ｒｅｔｕｒｎ ｈｅａｖｙｐｒｏｃｅｓｓｉｎｇ．ｄｏ（ｖａｌｕｅ）
ｍｙｋｅｙ＝“ｓｏｍｅｔｈｉｎｇ”
ｒｅｓｐｏｎｓｅ＝ｓｔｏｒａｇｅｃｌｉｅｎｔ．ｇｅｔｋｅｙ（ｍｙｆｕｎｃ， ｍｙｋｅｙ）
より進化したアプリケーションインターフェースの例は、以下のような疑似コードで表現することができる。
ｍｙｋｅｙ＝“ｓｏｍｅｔｈｉｎｇ”
ｗｉｔｈ ＳｔｏｒａｇｅＣｌｉｅｎｔ（ｋｅｙ＝ｍｙｋｅｙ） ａｓ ｃｌｉｅｎｔ：
ｒｅｓｐｏｎｓｅ＝ｓｐａｗｎ ｈｅａｖｙｐｒｏｃｅｓｓｉｎｇ．ｄｏ（ｃｌｉｅｎｔ．ｖａｌｕｅ）
ここで、ｍｙｆｕｎｃは、実行ファイルを示し、ｖａｌｕｅは、データの表現を示し、ｍｙｋｅｙは、クエリを示す。より進化したアプリケーションインターフェースでは、実行ファイルは、生み出したキーワードの後の表現である。
図２０５は、いくつかの実施形態による実例の装置４１０を概略的に示す。装置は、例えば、クライアントノード（ＣＮ）４３０に含まれてもよい。クライアントノードは、アプリケーション（ＡＰＰ）４４０および／またはローカルストレージエンティティ（ＬＳ）４５０をさらに備えることができる。
装置は、データの複数の表現が、複数のストレージエンティティのそれぞれの１つに保存される、データに基づく動作のセットの実施の管理のための制御回路機器（ＣＮＴＲ；例えばコントローラ）４００を備える。制御回路機器は、例えば、図２０７、図２０８、図２０９、および図２１０に関して上記で説明したように、方法ステップの１つまたは複数の実行を行う（例えば、実行する）ように設定することができる。
制御回路機器は、（複数のストレージエンティティのうちの２つ以上のストレージエンティティのそれぞれのために）データに関するそれぞれのクエリをストレージエンティティに送ることを行うように設定される（１１０、２１０、３１０に似ている）。
制御回路機器は、（複数のストレージエンティティのうちの２つ以上のストレージエンティティのそれぞれのために）クエリへの応答をストレージエンティティから受信することも行うように設定される（１２０、１２５、２２０ａ～２２０ｅ、３２０ｂ～３２０ｅに似ている）。応答は、ストレージエンティティに保存されたデータの表現、またはストレージエンティティに保存されたデータの表現の指標を含むことができる。
このために、制御回路機器は、通信インターフェース（Ｉ／Ｏ）４２０に関連付けられてもよい（例えば、接続されるか、接続可能であってもよい）。通信インターフェースは、ローカルストレージエンティティ以外のストレージエンティティのために、データに関するそれぞれのクエリを送ること、およびクエリへの応答を受信することを行うように設定することができる。
さらに、制御回路機器は、（２つ以上のストレージエンティティのうちの少なくとも２つのそれぞれのために）データの表現に基づく動作のセットの実施の活動の開始を行うように設定される（１３０、１３５、２３０ａ～２３０ｂ、３１０に似ている）。
このために、通信インターフェース４２０は、いくつかの実施形態による開始信号を送るように設定することができる。代替として、制御回路機器は、動作のセットを制御回路機器自体が実施するように設定することができる。
制御回路機器は、データの最終的な表現、または最終的な指標に対応するデータの表現に基づいているものとして、動作のセットの実施の開始後の活動の１つ（最終的な活動と呼ばれる）を、応答に含まれるデータの表現、または指標に基づいて判定することも行うように設定される（１５０、２５０、３５０に似ている）。
このために、制御回路機器は、判定器（ＤＥＴ；例えば判定回路機器）４０１を備えることができるか、そうでなければ判定器に関連付けられてもよい（例えば、接続されるか、接続可能であってもよい）。判定器は、最終的な活動を判定するように設定することができる。
制御回路機器は、データに基づく動作のセットの実施についての結果として最終的な活動の結果を、例えばアプリケーション４４０に、提供することを行うようにさらに設定される。このために、通信インターフェース４２０は、データに基づく動作のセットの実施についての結果として最終的な活動の結果を提供するように設定することができる。
全体的に、本明細書で配置に言及するとき、これは、例えば装置といった、物理製品として理解されるべきである。物理製品は、１つもしくは複数のコントローラ、１つもしくは複数のプロセッサ、または同様のものの形で、制御回路機器などの１つまたは複数の部品を備えることができる。
説明される実施形態およびその同等物は、ソフトウェアもしくはハードウェアまたはその組合せで実現することができる。実施形態は、汎用回路機器で実施することができる。汎用回路機器の例は、デジタル信号プロセッサ（ＤＳＰ）、中央処理装置（ＣＰＵ）、コプロセッサユニット、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、および他のプログラム可能ハードウェアを含む。代替または追加として、実施形態は、特定用途向け集積回路（ＡＳＩＣ）などの専用回路機器で実施することができる。汎用回路機器および／または専用回路機器は、例えば、クライアントノード（例えば、サーバ、コンピュータ等）などの装置に関連付けられるか、含まれてもよい。
実施形態は、本明細書で説明される実施形態のいずれかによる配置、回路機器、および／またはロジックを備える（クライアントノードなどの）電子装置内に現れることがある。代替または追加として、（クライアントノードなどの）電子装置は、本明細書で説明される実施形態のいずれかによる方法を実施するように設定することができる。
冗長経路の設定
上記で深く論じられたように、将来の移動体通信システムは、工業生産ドメインなどの分野での通信をサポートすることをねらっている。通話およびインターネットデータなどのモバイル通信トラフィックの典型的なユースケースに比べると、工業生産アプリケーション／サービスは、より高い信頼性、可用性、および低く決定的なレイテンシを必要とする。リモートの手術、自律車両等などの他のユースケースに、同様の要件があることもある。
このような通信は、典型的には、無線ネットワーク（例えば、ＬＴＥ、ＮＲ等といった３ＧＰＰによって標準化されたものなどのセルラネットワーク）と、有線ネットワーク（例えば、イーサネットネットワーク等）の両方を横断する経路を介して進むことになる。有線および無線通信ネットワークにおいて、高信頼性、可用性、および低く決定的なものを達成するために、様々な努力が行われてきた。
ＩＥＥＥ８０２．１タイムセンシティブネットワーキング（ＴＳＮ）は、ＩＥＥＥ８０２．３イーサネット規格に基づいており、したがって、有線通信規格である。ＴＳＮは、ベストエフォート通信のために以前、主として使用された、イーサネットを決定的なものにするための、例えば、時刻同期、保証された低レイテンシ伝送、および高信頼性についての機能の集合体を説明する。機能は、以下のカテゴリにグループ化することができる。
・時刻同期（例えば、ＩＥＥＥ８０２．１ＡＳ）
・境界型低レイテンシ（Ｂｏｕｎｄｅｄ Ｌｏｗ Ｌａｔｅｎｃｙ）（例えば、ＩＥＥＥ８０２．１Ｑａｖ、ＩＥＥＥ８０２．１Ｑｂｕ、ＩＥＥＥ８０２．１Ｑｂｖ、ＩＥＥＥ８０２．１Ｑｃｈ、ＩＥＥＥ８０２．１Ｑｃｒ）
・超信頼性（例えば、ＩＥＥＥ８０２．１ＣＢ、ＩＥＥＥ８０２．１Ｑｃａ、ＩＥＥＥ８０２．１Ｑｃｉ）
・ネットワーク設定および管理（例えば、ＩＥＥＥ８０２．１Ｑａｔ、ＩＥＥＥ８０２．１Ｑｃｃ、ＩＥＥＥ８０２．１Ｑｃｐ、ＩＥＥＥ８０２．１ＣＳ）
ＴＳＮは、１つまたは複数のトーカと１つまたは複数のリスナとの間のデータの交換のためのストリーム（またはフロー）の概念を使用する。トーカおよびリスナも、「エンドデバイス」、すなわち、ＴＳＭストリームのソースおよび宛先デバイスと呼ばれることがある。ＴＳＮストリームを設定するために、リスナおよびトーカは、例えば、リスナとトーカとの間で（スイッチまたはイーサネットスイッチとしても知られる）ブリッジがどのようにふるまうべきかなど、スケジューリングおよび設定判定のために使用されるＴＳＮネットワークへの要件を提供する。
ＩＥＥＥ８０２．１Ｑｃｃ規格は、完全分散型モデル、集中型ネットワークおよび分散型ユーザモデル、ならびに完全集中型モデルという、３つのＴＳＮ設定モデルを指定する。工業生産ユースケースについては、完全集中型設定モデルが最も適していることがある。それでも、本開示の実施形態は、代替として、完全分散型モデル、または、集中型ネットワークおよび分散型ユーザモデルを使用することができる。
完全集中型設定モデルについて、中央ユーザ設定（ＣＵＣ）および中央ネットワーク設定（ＣＮＣ）は、ネットワーク内の実際の物理ノードではなく、論理機能である。ＣＵＣは、リスナおよびトーカの設定を担当するエンティティである。ＣＮＣは、ネットワーク内のブリッジにおけるＴＳＮ特徴を設定するエンティティである。
無線通信ネットワークの説明は、ロングタームエボリューション（ＬＴＥ）および／または新無線（Ｎｅｗ Ｒａｄｉｏ）（ＮＲ）を使用する、５Ｇネットワークの背景におけるものである。本開示の実施形態は、代替として、３ＧＰＰによって標準化されたものなどの、特にセルラネットワークといった、他の無線通信ネットワークに関するものであってもよい。
ＴＳ２３．５０１、ｖ１５．３．０において説明されているような５Ｇシステム（５ＧＳ）アーキテクチャは、イーサネットプロトコルデータユニット（ＰＤＵ）セッションのサポートを指定する。このＰＤＵセッションのための媒体アクセス制御（ＭＡＣ）アドレスは、５Ｇシステムによって提供されない。
イーサネットＰＤＵセッションセットアップのために、セッション管理機能（ＳＭＦ）およびユーザプレーン機能（ＵＰＦ）は、ＰＤＵセッションアンカーとして機能する。また、設定に基づいて、ＳＭＦは、アドレス解決プロトコル（ＡＲＰ）トラフィックをＵＰＦからＳＭＦにリダイレクトするように、ＰＤＵセッションアンカーとして機能するＵＰＦにリクエストすることができる。また、ＵＰＦは、ＵＥから受信したＭＡＣアドレスを格納し、ＭＡＣアドレスを適切なＰＤＵセッションに関連付けなければならない。
その上、サービス品質（ＱｏＳ）の提供のために、ＳＭＦは、イーサネットフレーム構造、およびユーザ機器のＭＡＣアドレスに基づいて、イーサネットパケットフィルタセットおよび転送ルールを提供する。
３ＧＰＰシステムアーキテクチャにおけるアプリケーション機能（ＡＦ）は、機能ノードであり、例えば以下のようなサービスを提供するために３ＧＰＰコアネットワークと相互作用する。
・トラフィックルーティングに対するアプリケーションの影響（ＴＳ２３．５０１、ｖ１５．３．０、節５．６．７）
・ネットワーク公開機能へのアクセス（ＴＳ２３．５０１、ｖ１５．３．０、節５．２０）
・ポリシ制御のためのポリシ制御フレームワークとの相互作用（ＴＳ２３．５０１、ｖ１５．３．０、節５．１４）
さらに、ＡＦは、例えばＰＤＵセッション修正といった、特定のサービスをＵＥのためにトリガすることができる。アプリケーショントリガサービスについてのさらなる詳細は、３ＧＰＰ ＴＳ２３．５０１、ｖ１５．３．０、節４．４．５で説明されている。
現在、５ＧＳで冗長なＴＳＮストリームを設定する方法についてのメカニズムはない。現在の３ＧＰＰ規格は、２相または多相接続性（ＤＣ）、キャリアアグリゲーション（ＣＡ）、およびパケット重複など、伝送の信頼性を向上させるための種々の方式をサポートする。それでも、（伝送信頼性を向上させるこれらの方法を使用できる）冗長性をセットアップする方法について、５ＧＳとＴＳＮネットワークとの間で規定されたインターフェースまたは通信はない。
ユースケースの例として、５ＧＳとＴＳＮネットワークとの間の連係動作が、産業用ネットワーク展開に非常に関係している。残念ながら、このタイプのシームレスなインターネットワーキングは、現在のネットワークを用いて実現できない。
本開示の一定の態様およびその実施形態は、これらまたは他の難題に対するソリューションを提供することができる。
例えば、１つの態様で、本開示は、無線通信ネットワークのためのコアネットワークノードにおける方法を提供する。方法は、有線通信ネットワークに関連付けられた設定ノードとのインターフェースを介して設定メッセージを受信することであって、設定メッセージが、有線通信ネットワークに連結された第１のノードと、無線通信ネットワークに連結された第２のノードとの間の複数の経路のための設定を含み、複数の経路が、第１のノードと第２のノードとの間で複数のデータストリームを搬送し、複数のデータストリームが、少なくとも１つの冗長なデータストリームを含む、受信することと、設定に応じて無線通信ネットワーク内に複数の経路を設定することとを含む。
別の態様では、本開示は、有線通信ネットワークのための設定ノードにおける方法を提供する。方法は、無線通信ネットワークのためのコアネットワークノードとのインターフェースを介してリクエストメッセージを伝送することであって、リクエストメッセージが、無線通信ネットワークのトポロジに関する情報についてのリクエストを含む、伝送することと、コアネットワークノードとのインターフェースを介して情報メッセージを受信することであって、情報メッセージが、無線通信ネットワークのトポロジに関する情報を含む、受信することとを含む。
一定の実施形態は、ＴＳＮおよび５ＧＳでのエンドツーエンドの決定的なパケットトランスポート、５ＧＳでのＴＳＮストリーム冗長特徴設定、および、５Ｇコアネットワークのアーキテクチャへのシームレスな統合という技術的長所の１つまたは複数をもたらすことができる。
図２０６は、冗長経路を使用するＴＳＮデータストリームの伝送を示す。
将来、５Ｇ無線リンクで５ＧがＴＳＮ特徴をサポートすることになり、ＴＳＮストリームをトランスポートすることになることが想定される。これは、ＴＳＮが、このセクタにおける主要な通信技術になることが期待されるので、産業用ユースケースに非常に関連がある。５ＧネットワークにおけるＴＳＮトラフィックのサポートにより、ＴＳＮで展開された産業用ネットワークのために、ケーブルの代わりに、無線通信を使用することができる。ＴＳＮの重要な特徴の１つは、ＩＥＥＥ８０２．１ＣＢ（信頼性のためのフレーム複製および除去）であり、これは、伝送経路の１つの故障が出現した場合、冗長伝送が信頼性を向上させるのを可能にする。
このシナリオは、図２０６に示されている。灰色の矢印は、ネットワーク全体の重複したフレームを示す。黒い矢印は、単一のＴＳＮストリームを描写する。トーカのストリームは、左に示されており、データストリームは、図の右の部分にあるリスナに配信される。
本開示の実施形態によれば、ＴＳＮネットワークとのこのような相互作用を可能にする５ＧＳにおけるインターフェースが提案される。５Ｇ側におけるこのインターフェースは、アプリケーション機能（ＡＦ）の一部、または、（別のコアネットワークノードもしくは機能などの）別のネットワークエンティティであってもよい。この新しく提案されたインターフェースの１つの役割は、ネットワークを通るフレームの冗長経路を設定する、例えばＣＮＣなどの、ＴＳＮネットワーク内の１つまたは複数のノードと相互作用すること、および、ＴＳＮストリームについての要件を５ＧＳ上の関連機能にコンバートすることである。
図２０７は、このような統合の例を示す。５ＧＳは、ＡＦ（または、上記で説明したような、代替のコアネットワークノードもしくは機能）を使用することによって、１つまたは複数のＴＳＮスイッチとして機能し、ＴＳＮネットワーク内のＣＮＣおよび他のＴＳＮスイッチによって、１つまたは複数のＴＳＮスイッチとみなされる。
ＴＳＮ内の２つの独立したデータ経路の設定は、アプリケーションソフトウェア（例えば、プログラマブルロジックコントローラ（ＰＬＣ））からの要件によって決まる。関連する設定パラメータは、ＩＥＥＥ８０２．１Ｑｃｃ ４６．２．３．６．１で指定されている「ＮｕｍＳｅａｍｌｅｓｓＴｒｅｅｓ」であってもよい。このパラメータの値が１より大きい場合、ＣＮＣは、ディスジョイント木を計算し、最大限にセットアップしなければならない（２の値に対して、ほぼ２つのディスジョイント木がある）。
本開示の１つの実施形態では、（ＡＦと相互作用する）５Ｇコアネットワーク機能は、２つの独立した経路（シームレスな木）を５Ｇネットワーク内にセットアップできるかどうかを判定する。これを行うために、例えば単一のｇＮＢに、または複数のｇＮＢになど、ＲＡＮに、リクエストを送ることができる。５Ｇネットワークは、５Ｇネットワークからの１つまたは複数の技法を使用することによって、（例えば信頼性を向上させるために）伝送パケットの冗長性をサポートすることができる。適切な例は、デュアルコネクティビティ、キャリアアグリゲーション、および重複を含むことができる。５ＧＳにおいてＴＳＮストリームのための冗長経路または複数の経路を使用するために、同じイーサネットネットワークまたはデバイスに２つ以上のＵＥを取り付けること、および、冗長性のために他の機能への代替として、または他の特徴と組み合せて、使用することができる。図２０９～図２１１は、無線ネットワークにおける冗長経路の様々な例を示す。
図２１１は、冗長性のために、２つのＵＥが使用されるアーキテクチャを示す。図２０９は、５ＧＳが異なるＴＳＮ経路をシミュレートすることを示す。図２１０は、このような向上した冗長性を可能にすることについての可能な５Ｇの並べ替えのいくつかを示すことによって、これらの複数の経路をどのようにシミュレートできるかについての、より多くの見識を提供する。
例えば、最も単純なケースでは、両方の入ってくる冗長ストリームが、同じＵＰＦ、ｇＮＢ、およびＵＥ上で転送される。ＵＥは、複数の冗長なＴＳＮノードに、冗長ストリームを転送してもよい。
このシナリオは、物理的な冗長性を使用しなくても、５ＧＳが十分信頼できると仮定される場合に適用できることがある。別のオプションは、コアネットワークにおける単一のＵＰＦを使用するのではなく、無線ネットワークにおける冗長性だけを使用すること、またはデュアルコネクティビティではなく単一のＵＥを使用することである。複数のオプションがあることを当業者は理解するであろう。
本開示のいくつかの実施形態によれば、５ＧＳにおいて冗長性がどのようにサポートされるかは、外部ＴＳＮネットワークに露出されず、このような実施形態では、ＡＦを通じて通信されるものだけが、冗長性がサポートされるかどうか、およびどの程度までサポートされるか（例えば、どれだけ多くの冗長経路があるか、冗長なトポロジがどのように見えるか）であってもよい。
上述のように、本開示の実施形態は、（ＴＳＮネットワークなどの）有線通信ネットワークと、（５Ｇネットワークなどの）無線通信ネットワークとの間のエンドツーエンドの冗長性をセットアップし、有効にするように、機能を可能にする新しいインターフェースを提供する。
図２０７は、本開示の実施形態による通信システムを示し、特に、図２０６について上記で論じられたＴＳＮネットワーキングへの完全集中型アプローチについて、５ＧＳとＴＳＮとの間のこの相互作用が描写されていることを示す。
図２０７におけるシナリオは、ＡＦが無線ネットワークドメインの一部であると仮定する。無線ネットワークと有線ネットワークとの間の通信のためのインターフェースを提案する。明瞭さを向上させる観点から、ＡＦとＣＮＣとの間の例を提供するが、このタイプの相互作用は、両方のネットワークの他の部品／エンティティで行うこともできる。ＴＳＮネットワーク内のデバイスは、トーカであってもよく、５Ｇネットワークに接続されたデバイスは、リスナであってもよい。他の実施形態では、このシナリオは異なってもよく、例えば、トーカが無線ネットワーク（例えば５ＧＳ）内にあり、リスナが有線ネットワーク（例えばＴＳＮ）内にあってもよい。
図２０８は、本開示の実施形態による信号図であり、ＡＦとＣＮＣとの間の相互作用を示す。ＴＳＮフローをセットアップするための相互作用のシーケンスは、以下のようなものである。
０． ５ＧＳは、ＴＳＮネットワークに接続し、リンクレイヤディスカバリプロトコル（ＬＬＤＰ）または別の適切な管理プロトコル（例えば、簡易ネットワーク管理プロトコル（ＳＮＭＰ）、ネットワーク設定プロトコル（ＮＥＴＣＯＮＦ）、リプレゼンテーショナルステートトランスファ設定プロトコル（ＲＥＳＴＣＯＮＦ））を使用して、ＴＳＮネットワーク内のＴＳＮブリッジを発見し、ＴＳＮブリッジによるＬＬＤＰリクエストにリプライすることができる。
１． ＰＬＣは、デバイスＩＤ、および場合によっては、パブリック３ＧＰＰ識別子（例えば、移動局国際加入者ディレクトリ番号（ＭＳＩＳＤＮ））をＣＵＣ、または、ＭＡＣアドレスのような他のアドレスに提供することによって通信を始める。ＣＵＣまたは他のアドレスに送られるメッセージは、以下の情報コンテンツの１つまたは複数を含むことができる。
ｉ． デバイスＩＤとともにセンサとアクチュエータとの間で転送されるデータのペイロードサイズ
ｉｉ． 時間間隔
ｉｉｉ． ３ＧＰＰ ＵＥパブリック識別子（ＭＳＩＳＤＮ）（任意選択）
２． ＣＮＣは、ネットワークの物理トポロジ（例えば、ネットワークノード、およびネットワークノード間のリンク）を発見する。終端局とブリッジとの間の物理リンクを発見するために、ＣＮＣは、ＩＥＥＥ Ｓｔｄ８０２．１ＡＢ（例えばＬＬＤＰ）、および／または任意のリモート管理プロトコルを使用することができる。
・本開示の１つの実施形態では、ＡＦは、トポロジリクエストに応答し、いずれかの冗長性の必要性を満たせるように、５ＧＳ全体の複数の経路を公表する。複数の経路は、２つ以上の経路を含むことができる。例えば、単一のＴＳＮスイッチ、または経路ごとの複数のＴＳＮスイッチだけでなく、種々のトポロジを用いた５ＧＳにおける冗長経路を内部で公表することができる。
・この公表は、ＰＤＣＰ重複および／または複数のＵＥ接続、トランスポートおよびコアネットワークおよび機能冗長性（これは、５ＧＳのエンドツーエンドにおける完全な物理冗長性を含むことができる）など、向上した伝送信頼性をサポートすることができる関連する５Ｇメカニズム全てを知らせることによって行うことができる。
・本開示のさらなる実施形態として、冗長性は、ＴＳＮネットワークのためにシミュレートされてもよい。５ＧＳは、複数の経路をシミュレートすることができ、次に、必要な信頼性を関連メカニズムがサポートすることを可能にし、ＡＦは、これらのシミュレートしたディスジョイント経路を、ＣＮＣのための合法的なディスジョイント経路としてアナウンスすることになる。
・ＡＦが複数の経路をＣＮＣにアナウンスした場合、複数の経路を内部で動的に変更または修正することができるが、同時に、ＣＮＣのために静的であってもよい。確立したストリームについて、これらの経路は、特定のストリームの同意が有効である限り、変更してはならない。
３． ＣＮＣは、（ＡＦからのトポロジ情報を含む）ネットワークから、およびＣＵＣから検索した情報に基づいて、ならびに、特定のＰＬＣアプリケーションのために、以下の１つまたは複数を含むことができるＴＳＮ設定パラメータを生成する。
・トラフィック仕様：例えば、ストリームのためのフレームをトーカがどのように伝送するかを指定する。
・ストリームＩＤ。
・ユーザからネットワークへの要件：レイテンシおよび冗長性など、ストリームについての１つまたは複数のユーザ要件を指定する。
上記および追加のパラメータは、ＩＥＥＥ８０２．１Ｑｃｃ、節４６．２．３に指定されている。このような設定情報も、集中型および分散型ユーザアプローチなどの、種々のＴＳＮ設定モデル内で収集し、作り出すことができる。
４． ＣＵＣは、トーカグループおよびリスナグループ（要求される情報）を作り出し、ＣＮＣへの結合リクエストを作り出す。
５． ＣＮＣは、結合リクエストを受信し、（エッジブリッジから終端局への５ＧＳを通る経路を含む）ＴＳＮストリームの経路計算を実施する。計算アルゴリズムは、規格で指定されておらず、経路を計算するための複数の方法およびアルゴリズムが存在することを当業者は理解するであろう。本開示は、この点に限定されない。このようなアルゴリズムは、ネットワークスループット、全体的なネットワークレイテンシ、経路レイテンシ、等などの、例えば、１つまたは複数のネットワーク性能尺度を最小化または最大化しようと努めることができる。
○ 経路計算は、５Ｇ経路を含む、トーカからリスナにフレームを伝送するために使用される経路を計算することを含む。
○ ＣＵＣも、宛先ＭＡＣアドレス、ＶＬＡＮ ＩＤおよびＰＣＰ（プライオリティコードポイント）を含む一意の識別子（ＳｔｒｅａｍＩＤ）を各ストリームに配分し、ＳｔｒｅａｍＩＤをＣＮＣに通信する。
６． ＣＮＣは、スケジュール設定のための出力を提供する。このスケジュールおよび経路設定は、ステータスグループを介してＣＵＣに返される（ＩＥＥＥ８０２．１Ｑｃｃ、４６．２．５）。
７． ＣＮＣは、例えば、ＩＥＥＥ８０２．１Ｑで指定されるような、ブリッジにおける、ｎｅｔｃｏｎｆ、または、さらに別の次世代（ＹＡＮＧ：Ｙｅｔ Ａｎｏｔｈｅｒ Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ）管理オブジェクトのような、管理プロトコルを介してブリッジにおける経路設定を設定する。
・これらの設定は、スイッチがパケットをどのように転送するかを規定する。
・１つの実施形態では、ＡＦは、ＣＮＣからこの設定情報を得て、セットされた経路について知り、冗長性について認識する（これは、この情報を使用して、冗長性特徴を可能にし、保証する）。
８． ステータスグループがどの故障コードも収めていない場合、ＣＮＣは、設定用設定をＡＦに提供する。
９． ＡＦは、５ＧＳのためのＴＳＮ設定用設定をコンバートし、ＰＤＵセッションの修正をトリガし、さらに、関連する転送ルールおよびパケットフィルタセットをＳＭＦに提供し、関連する転送ルールおよびパケットフィルタセットは、ＵＰＦ転送ルールおよびパケットフィルタセットを設定するためにＳＭＦによってさらに使用される。これは、５ＧＳにおけるストリームトラフィックを転送するために、ＣＮＣによってどの経路が選択されたかについての知識を含むことができ、この知識は、ストリームをルートするために、５ＧＳによって適宜使用されることがある。
上記の説明は、ＣＮＣ、ＣＵＣ、およびＡＦ（または他のコアネットワークノードもしくは機能）の間の相互作用に焦点を合わせてきた。中央の協調をＴＳＮネットワークが使用しない（すなわち、ＣＮＣもＣＵＣも存在しない）実施形態では、本開示で説明される方法は、同様に適用することができるが、ＡＦは、５ＧＳに接続されたスイッチ（例えば、ＴＳＮスイッチ）に直接交信することになる。
図２０９は、本開示の実施形態による無線ネットワークにおける冗長経路を示す概略図である。冗長経路は、有線ネットワーク内の複数のスイッチから５ＧＳに到着し、無線ネットワーク内の対応する経路に向けることができることがわかる。
図２１０は、本開示のさらなる実施形態による無線ネットワークにおける冗長経路を示す概略図である。冗長経路はより詳細に示されており、共通の１つまたは複数の要素を備えることができる（例えば、無線ネットワーク内の単一の要素を２つ以上の経路で利用することができる）。このうちの極端な例では、経路は、互いに同一の２つ以上の経路を含むことができる（例えば、同じ物理または仮想経路を介して同じデータが２回以上伝送される）。経路は、互いに異なる１つまたは複数の要素も含むことができる（例えば、２つ以上の経路が、１つまたは複数の点で異なっていてもよい）。例えば、経路は、（図２１０に示されているユーザプレーン機能などの）異なるコアネットワークノードまたは機能、（図２１０に示されているｇＮｏｄｅＢなどの）異なる無線アクセスネットワークノード、および、（図２１０に示されているＵＥなどの）異なる端末デバイス、の１つまたは複数を含むことができる。経路は、このように、最大限にディスジョイントした、および／または全面的にディスジョイントした、２つ以上の経路を含むことができる。
図２１１は、本開示のさらなる実施形態による無線ネットワークにおける冗長経路を示す概略図であり、最大の詳細を含む。本実施形態では、２つの冗長経路が示されており、これは、トーカとリスナとの間で（すなわち、ＰＬＣにおけるイーサネットホストと、イーサネットホストが制御するデバイスとの間で）ディスジョイントしたものである。各イーサネットホストは、（すなわち、トーカまたは伝送デバイスにおいて）フレームが複製されるのを許可する、信頼性モジュールのためのフレーム複製および除去（ＦＲＥＲ）、ならびに（例えば、リスナまたは受信デバイスにおける）重複解除または除去を含む。
図２１２は、本開示の実施形態によるコアネットワークノードまたは機能における方法の流れ図である。コアネットワークノードは、例えば、図２１３、図２１４、および図２１７の１つまたは複数について上記で説明した、ＡＦのシグナリングおよび機能を実施することができ、したがって、アプリケーション機能（ＡＦ）を備えるか、実行することができる。上述のように、それでも、この機能は、代替のコアネットワークノードまたは機能において実行されてもよい。さらに、下記で、および図２１２について提示されたステップは、２つ以上のコアネットワーク機能において実施することができる。
ステップ７００において、コアネットワークノードは、有線通信ネットワークに関連付けられた設定ノード（例えば、上記で説明したようなＣＮＣまたはＴＳＮスイッチ）からリクエストメッセージを受信する。リクエストメッセージは、ＬＬＤＰ、ＳＮＭＰ、ＮＥＴＣＯＮＦ、ＲＥＳＴＣＯＮＦ、または任意の適切なネットワーク管理プロトコルに応じて設定することができる。リクエストメッセージは、例えば、無線通信ネットワーク内の１つまたは複数のノードの識別情報、これらのノード間のリンク、これらのノードが冗長経路を可能にする能力、等といった、無線通信ネットワークのトポロジに関する情報についてのリクエストを含むことができる。
ステップ７０２において、コアネットワークノードは、無線通信ネットワークのトポロジに関する情報を含む設定ノードへの情報メッセージを伝送する。例えば、情報メッセージは、無線ネットワークが冗長経路を提供する能力についての指示を含むことができる。情報メッセージは、（リクエストメッセージの中で識別された可能性のある）特定のエンドポイントまたはデバイスへの、無線通信ネットワーク内に設定することができるいくつかの経路についての指示を含むことができる。情報メッセージも、ＬＬＤＰ、ＳＮＭＰ、ＮＥＴＣＯＮＦ、ＲＥＳＴＣＯＮＦ、または任意の適切な管理プロトコルを介して設定することができる。
ステップ７０４において、コアネットワークノードは、設定ノードから設定メッセージを受信する。設定メッセージは、有線通信ネットワークに連結された第１のノードと、無線通信ネットワークに連結された第２のノードとの間の複数の経路についての設定を含む。例えば、設定は、複数の経路のそれぞれのための入力ポートと出力ポートとの間の関連付けのセット、すなわち、それぞれの入力ポートからのどの出力ポートデータが転送されることになるかについての命令を含むことができる。例えば、図２１５および図２１６を参照されたい。複数の経路は、少なくとも１つの冗長なデータストリームを含む、第１のノードと第２のノードとの間の複数のデータストリームを搬送する。
１つの実施形態では、複数の経路は、無線通信ネットワーク内に互いに共通の少なくとも１つの要素を含む第１の経路および第２の経路を含む。例えば、１つの実施形態では、第１の経路および第２の経路は、無線通信ネットワーク内で同一である。
別の実施形態では、複数の経路は、無線通信ネットワーク内に互いに共通でない少なくとも１つの要素を含む（上記で開示した第１および第２の経路に加えて、または代替であってもよい）第３の経路および第４の経路を含む。例えば、第３の経路および第４の経路は、無線通信ネットワーク内のディスジョイント経路、または無線通信ネットワーク内の最大限のディスジョイント経路であってもよい。第３の経路と第４の経路との間の共通でない少なくとも１つの要素は、ユーザ機器、無線アクセスネットワークノード、およびコアネットワークノードまたは機能、の１つまたは複数を含むことができる。第３および第４の経路は、ユーザ機器と複数の無線アクセスネットワークノードとの間のデュアルコネクティビティメカニズム、および／または、ユーザ機器と、１つもしくは複数の無線アクセスネットワークノードとの間のキャリアアグリゲーションメカニズムを利用することができる。
経路は、１つもしくは複数の物理経路および／または１つもしくは複数の仮想経路を含むことができる。
ステップ７０６において、コアネットワークノードは、パケットフィルタセット、および１つまたは複数の転送ルールの１つまたは複数に、設定メッセージ内の設定をコンバートする。例えば、ＡＦは、この機能を実施することができ、または代替として、この機能を実施するために、ポリシ制御機能（ＰＣＦ）などの、別のコアネットワークノードまたは機能に設定を転送することができる。ＡＦまたはＰＣＦは、（例えば、上記で説明した技法のいずれかを使用して）無線通信ネットワーク内で冗長性がどのようにサポートされることになるかについての情報で設定することができる。ＰＣＦまたはＡＦは、この情報をリクエストすることができる（すなわち、これが無関係なＣＮＣの視点から、無線通信ネットワーク内で、これらの冗長経路がどのように実際にセットアップされるか。内部では、いくつかの無線ネットワーク機能が、仮想的に冗長であるだけでもよく、例えば、１つのＵＰＦだけが使用される）。
ステップ７０８において、コアネットワークノードは、設定に従って無線通信ネットワークにおける複数の経路を設定する。任意選択として、特に、ステップ７０６においてパケットフィルタセットおよび転送ルールの１つまたは複数に設定をコンバートしていた場合、ステップ７０８は、パケットフィルタセットおよび／または転送ルールを第２のコアネットワークノード（例えばＳＭＦ）に転送することを含むことができる。例えば、ＡＦ（またはＰＣＦ）は、ＡＦ入力、および、５ＧＳで冗長性がどのようにサポートされるかについての情報、に基づいて冗長性をサポートするように、必要に応じて、修正したＰＤＵセッションをセットアップするために、ＳＭＦに信号を送ることができる。ＳＭＦは、その後、ＵＰＦにおいてＰＤＵセッションを適宜修正することになる。
さらなる実施形態では、ＡＭＦは、ＡＦからの入力、および、冗長性がどのようにサポートされるかについての５ＧＳ内部情報に従って、ＲＡＮにおいて冗長性をどのようにセットアップしなければならないかについて知らされる。
図２１３は、本開示の実施形態による設定ノードにおける方法の流れ図であり、設定ノードは、イーサネットネットワークなどの有線通信ネットワークに関連付けられる。設定ノードは、例えば、図２１３、図２１４、および図２１７の１つまたは複数について上記で説明したＣＮＣのシグナリングおよび機能、ならびに／またはＣＵＣ機能を実施することができ、したがって、ＣＮＣおよび／またはＣＵＣを備えることまたは実行することができる。代替実施形態では、それでも、特に、有線ネットワークが中心に設定されない場合（およびしたがって、ＣＮＣまたはＣＵＣが存在しない場合）、設定ノードは、有線ネットワークのスイッチ（例えばＴＳＮスイッチ）を備えることができる。さらに、下記でおよび図２１３について提示されているステップは、２つ以上のネットワークノードまたは機能で実施することができる。
ステップ８００において、設定ノードは、無線通信ネットワークに関連付けられたコアネットワークノード（例えば、上記で説明したようなＡＦ）にリクエストメッセージを伝送する。リクエストメッセージは、ＬＬＤＰ、ＳＮＭＰ、ＮＥＴＣＯＮＦ、ＲＥＳＴＣＯＮＦ、または任意の適切なネットワーク管理プロトコルに応じて設定することができる。リクエストメッセージは、例えば、無線通信ネットワーク内の１つまたは複数のノードの識別情報、これらのノード間のリンク、冗長経路を可能にするためのこれらのノードの能力、等といった、無線通信ネットワークのトポロジに関する情報についてのリクエストを含むことができる。
ステップ８０２において、設定ノードは、無線通信ネットワークのトポロジに関する情報を含むコアネットワークノードからの情報メッセージを受信する。例えば、情報メッセージは、冗長経路を提供するための無線ネットワークの能力の指示を含むことができる。情報メッセージは、（リクエストメッセージ内で識別されている可能性のある）特定のエンドポイントまたはデバイスへの、無線通信ネットワークにおいて設定することができるいくつかの経路の指示を含むことができる。情報メッセージも、ＬＬＤＰ、ＳＮＭＰ、ＮＥＴＣＯＮＦ、ＲＥＳＴＣＯＮＦ、または任意の適切な管理プロトコルを介して設定することができる。
いくつかの実施形態では、無線通信ネットワークを通る冗長経路は、情報メッセージ内で無線通信ネットワーク自体が知らされなくてもよい。すなわち、設定ノードは、無線通信ネットワークにおける冗長経路がどのように確立されるか、または、（例えば、デュアルコネクティビティ、パケット重複、キャリアアグリゲーション、等といった）冗長性を達成し、信頼性を向上させるために無線ネットワークにおいて採用される冗長性技法、を認識していなくてもよい。それでも、情報メッセージは、例えば、無線通信ネットワークにおいてサポートすることができる冗長経路の数の指示を含むことができる。
ステップ８０４において、設定ノードは、有線通信ネットワークに連結された第１のノードと、無線通信ネットワークに連結された第２のノードとの間の冗長なデータストリームのための複数の経路を判定する。複数の経路は、少なくとも１つの冗長なデータストリームを含む、第１のノードと第２のノードとの間の複数のデータストリームを搬送する。
１つの実施形態では、無線通信ネットワークにおける正確な経路を設定ノードが認識していない場合、このステップは、無線通信ネットワーク全体が１つまたは複数のＴＳＮブリッジに相当すると仮定してもよい。
ステップ８０６において、設定ノードは、複数の経路のそれぞれについての設定を含むコアネットワークノードへの設定メッセージを伝送する。例えば、設定は、複数の経路のそれぞれについての、入力ポートと出力ポートとの間の関連付けのセット、すなわち、それぞれの入力ポートからのデータをどの出力ポートに転送するべきかについての命令、を含むことができる。例えば、図２１５および図２１６を参照されたい。
タイムセンシティブネットワークからのプリサイスタイミングプロトコルシグナリングのハンドリング
タイムセンシティブネットワーキング（ＴＳＮ）は、ＩＥＥＥ８０２．３イーサネット規格に基づいている。ＴＳＮは、ベストエフォート通信のためにデザインされた旧式のイーサネットを決定的なものにするために、例えば、時刻同期、保証された低レイテンシ伝送、および高信頼性など、ＩＥＥＥ８０２．３ネットワークを通じて決定的なサービスを提供する。今日利用できるＴＳＮ特徴は、以下のカテゴリにグループ化することができる。
・時刻同期（例えばＩＥＥＥ８０２．１ＡＳ）
・境界型低レイテンシ（例えば、ＩＥＥＥ８０２．１Ｑａｖ、ＩＥＥＥ８０２．１Ｑｂｕ、ＩＥＥＥ８０２．１Ｑｂｖ、ＩＥＥＥ８０２．１Ｑｃｈ、ＩＥＥＥ８０２．１Ｑｃｒ）
・超信頼性（例えば、ＩＥＥＥ８０２．１ＣＢ、ＩＥＥＥ８０２．１Ｑｃａ、ＩＥＥＥ８０２．１Ｑｃｉ）
・ネットワーク設定および管理（例えば、ＩＥＥＥ８０２．１Ｑａｔ、ＩＥＥＥ８０２．１Ｑｃｃ、ＩＥＥＥ８０２．１Ｑｃｐ、ＩＥＥＥ８０２．１ＣＳ）
ＴＳＮネットワークの設定および管理は、種々の手法で、つまり、ＩＥＥＥ８０２．１Ｑｃｃで規定されているような、集中型セットアップで、または分散型セットアップで、実行されてもよい。種々の設定モデルが、図１０６～図１０８に示されている。ＩＥＥＥ Ｐ８０２．１Ｑｃｃ／Ｄ２．３で規定されているように、図１０６は、分散型ＴＳＮ設定モデルを示し、図１０７は、集中型ＴＳＮ設定モデルを示し、図１０８は、完全集中型ＴＳＮ設定モデルを示す。
ＴＳＮ内部の通信エンドポイントは、トーカおよびリスナと呼ばれる。ＴＳＮネットワークは、複数のエンティティおよび特徴からなる。図１０６から図１０８ではブリッジと呼ばれるスイッチ全てが、トーカとリスナとの間で、例えばＩＥＥＥ８０２．１ＡＳ時刻同期のような一定のＴＳＮ特徴をサポートしなければならない。ＴＳＮドメインは、ノード間の同期通信を可能にする。トーカとリスナとの間の通信は、ストリームで実施される。ストリームは、トーカおよび／またはリスナにおいて実行されるアプリケーションによって示されたデータレートおよびレイテンシの観点からの一定の要件に基づいている。ＴＳＮ設定および管理特徴は、ストリームをセットアップし、ネットワーク全体のストリームの要件を保証するために使用される。図１０６に示されている分散型モデルでは、トーカおよびリスナは、例えば、ストリームリザベーションプロトコル（ＳＲＰ）を使用して、ＴＳＮネットワークにおけるトーカからリスナへの経路に沿ったあらゆるスイッチにおいてＴＳＮストリームをセットアップおよび設定することができる。それでも、いくつかのＴＳＮ特徴は、図１０７に示されているような、集中型ネットワーク設定（ＣＮＣ）ツールと呼ばれる中央管理エンティティを必要とする。ＣＮＣは、例えば、ＮｅｔｃｏｎｆおよびＹＡＮＧモデルを使用して、各ＴＳＮストリームのためにネットワーク内のスイッチを設定することができる。これは、決定的なレイテンシでのＴＳＮネットワークにおけるデータトランスポートを可能にする、ＩＥＥＥ８０２．１Ｑｂｖで規定されているような、時間ゲートキューイングの使用も可能にする。ゲートが開かれるようにスケジュールされた時間内に入口ポートにストリームが到着した場合、最小レイテンシおよびジッタで高優先パケットがスイッチを通過できるようにする正確なスケジュールに従って、各スイッチでの時間ゲートキューイングによりキューが開かれるか、閉じられる。完全集中型モデルでは、図１０８に示されているように、リスナおよびトーカのための接触点として使用される集中型ユーザ設定（ＣＵＣ）エンティティがさらに追加される。ＣＵＣは、ストリーム要件およびエンドポイント能力をデバイスから収集し、ＣＮＣと直接通信する。ＴＳＮ設定についての詳細は、ＩＥＥＥ８０２．１Ｑｃｃでさらに詳細に説明されている。
図１０９は、図１０８に示されているような完全集中型設定モデルを使用した、ＴＳＮストリーム設定の手順のシーケンスチャートを示す。
ＴＳＮネットワーク内のＴＳＮストリームを完全集中型設定モードでセットアップするために実施されるステップは、以下の通りである。
１． ＣＵＣは、タイムセンシティブストリームを交換することになっているデバイスを指定する、例えばプログラマブルロジックコントローラ（ＰＬＣ）などの、例えば産業用アプリケーション／エンジニアリングツールからの、入力を受信することができる。
２． ＣＵＣは、ユーザトラフィックの期間／間隔、およびペイロードサイズについての情報を含む、ＴＳＮネットワーク内の終端局およびアプリケーションの能力を読み取る。
３． この上記の情報に基づいて、ＣＵＣは、以下を作り出す。
－ 各ＴＳＮストリームについての識別子としてのＳｔｒｅａｍＩＤ、
－ ＳｔｒｅａｍＲａｎｋ、および
－ ＵｓｅｒｔｏＮｅｔｗｏｒｋ要件。
４． ＣＮＣは、例えば、リンクレイヤディスカバリプロトコル（ＬＬＤＰ）、および任意のネットワーク管理プロトコルを使用して、物理ネットワークトポロジを発見する。
５． ＣＮＣは、例えば、ネットワーク管理プロトコルによって、ＴＳＮネットワーク内のブリッジのＴＳＮ能力（例えば、ＩＥＥＥ８０２．１Ｑ、８０２．１ＡＳ、８０２．１ＣＢ）を読み取る。
６． ＣＵＣは、１つのトーカから１つのリスナへのＴＳＮストリームのための、ブリッジにおけるネットワークリソースを設定するために、ストリームを設定するための結合リクエストを始める。
７． ＩＥＥＥ８０２．１Ｑｃｃ、４６．２．２で指定されているように、トーカおよびリスナのグループ（ＴＳＮストリームを指定する要素のグループ）が、ＣＵＣによって作り出される。
８． ＣＮＣは、ＴＳＮドメインを設定する。
９． ＣＮＣは、物理トポロジをチェックし、タイムセンシティブストリームが、ネットワーク内のブリッジによってサポートされるかどうかをチェックする。
１０． ＣＮＣは、ストリームのスケジューリングおよび経路計算を実施する。
１１． ＣＮＣは、ＴＳＮネットワークにおける経路に沿ったブリッジにおけるＴＳＮ特徴を設定する。
１２． ＣＮＣは、ストリームについての、結果として生じるリソース割当てのステータス（成功または失敗）をＣＵＣに返す。
１３． ＣＵＣは、リスナとトーカとの間で最初に規定されたように、ユーザプレーントラフィック交換をスタートするように終端局をさらに設定する。
ＴＳＮネットワークにおいて、ＳｔｒｅａｍＩＤは、ストリーム設定を一意に識別するために使用することができる。ＳｔｒｅａｍＩＤは、ユーザのストリームにＴＳＮリソースを割り当てるために使用される。ＳｔｒｅａｍＩＤは、２つのタプルからなり、すなわち、以下の通りである。
１． ＴＳＮトーカに関連付けられたＭａｃＡｄｒｅｓｓ
２． ＭａｃＡｄｒｅｓｓによって識別された終端局内の複数のストリームを区別するためのＵｎｉｑｕｅＩＤ
図１０６に示されているような分散型設定モデルでは、ＣＵＣもＣＮＣもない。したがって、トーカがＴＳＮストリームの開始を担当する。ＣＮＣが存在しないので、例えば８０２．１Ｑｂｖで規定されているような時間ゲートキューイングの使用を許可されていないブリッジが自身を設定している。
図１０７に描写されているような集中型モデルでは、トーカがストリームの初期化を担当するが、ブリッジは、ＣＮＣによって設定される。
ＴＳＮネットワークにデバイスを無線で接続するために、５Ｇは、有望なソリューションである。５Ｇ規格は、５Ｇ規格をより信頼できるものにし、４Ｇに比べて伝送レイテンシを低減させるために、特にＲＡＮ上で、多くの新しい機能を通じて工場のユースケースにも取り組んでいる。５Ｇネットワークは、ＵＥ、ｇＮＢとして例示されるＲＡＮ、および５Ｇコアネットワーク（５ＧＣＮ）内のユーザプレーン機能（ＵＰＦ）などのノードである、３つの主な構成要素を備える。５Ｇネットワークアーキテクチャは、図１１０に示されている。５Ｇネットワークの制御プレーンは、ネットワークリポジトリ機能（ＮＲＦ）、アクセス管理機能（ＡＭＦ）、セッション管理機能（ＳＭＦ）、ネットワーク公開機能（ＮＥＦ）、ポリシ制御機能（ＰＣＦ）、および統合型データ管理（ＵＤＦ）をさらに含む。
進行中のリサーチの難題は、図１１１に示されているような５ＧとＴＳＮの連係動作である。ネットワーク管理および設定のための独自の方法、ならびに、産業用ネットワークのためのエンドツーエンドの決定的なネットワーキングを何らかの方法で配置しなければならない通信決定論を実現するための種々のメカニズムを両方の技術が規定する。以下では、５Ｇネットワークに接続されたデバイスは、５Ｇエンドポイントと呼ばれる。ＴＳＮドメインに接続されたデバイスは、ＴＳＮエンドポイントと呼ばれる。
図１１１に示されているものにかかわらず、ＵＥは単一のエンドポイントに接続されるのではなく、代わりに、少なくとも１つのＴＳＮブリッジおよび少なくとも１つのエンドポイントを備えるＴＳＮネットワークに接続されることも可能である。ＵＥは、このような状況では、ＴＳＮ－５Ｇゲートウェイの一部であり、この中で、終端局は、５Ｇネットワークによって主要なＴＳＮネットワークから孤立したローカルＴＳＮネットワークの背景の中でＵＥと通信する。
以下では、図１１１に示されているシナリオによる５Ｇシステム（５ＧＳ）におけるイーサネットトランスポートをどのように作動させることができるかについての例を説明する。
・このシナリオは、それぞれが、別個のイーサネットＭＡＣレイヤアドレスを保持する、１つまたは複数のエンドポイントを単一のＵＥがサポートしなければならないケースを仮定する。言い換えれば、ＵＥは、複数のイーサネットポートをサポートすることができる。
・ＴＳＮスイッチとインターフェースするユーザプレーン機能（ＵＰＦ）は、イーサネットＰＤＵの受信および伝送をサポートすると仮定される。
・ＴＳＮスイッチからイーサネットＰＤＵを受信すると、ＵＰＦは、例えば、宛先ＭＡＣアドレスに関連付けられたＵＥのＩＰアドレスに基づいて、１つまたは複数の宛先ＭＡＣアドレスを、例えばＰＤＵセッションに関連付け、次に、５Ｇネットワーク内の適切なノードにイーサネットＰＤＵを中継することができなければならない。
・ｇＮＢは、イーサネットＰＤＵ伝送をサポートするのに適した信頼性およびレイテンシ属性を伴うデータ無線ベアラ（ＤＲＢ）を使用して、ＵＥにイーサネットＰＤＵを送る。
・ＵＥは、１つまたは複数のイーサネット接続したエンドポイントをサポートすることができるので、例えばＰＤＣＰレイヤから、イーサネットＰＤＵを回復し、宛先ＭＡＣアドレスに関連付けられたエンドポイントにイーサネットＰＤＵを送る。
・要約すると、ＴＳＮスイッチからＵＰＦが受信した元のイーサネットＰＤＵは、５Ｇネットワークを通じて透過的に配信される。
・アップリンク方向に対して、５Ｇネットワークは、無線ネットワーク一時識別子（ＲＮＴＩ）が、いつイーサネット動作に関連付けられるかを判定し、これにより、ＲＮＴＩに関連付けられた、例えばイーサネットＰＤＵなどの、アップリンクペイロードをＵＰＦにルートできることが期待される。ＵＰＦは、次に、受信したイーサネットＰＤＵをＴＳＮスイッチに単純に送る。
多くのＴＳＮ特徴が、全てのピア間の正確な時刻同期に基づいている。また、多くの産業用アプリケーションが、正確な同期に依存する。上記で紹介したように、これは、例えば、ＩＥＥＥ８０２．１ＡＳまたはＩＥＥＥ Ｐ８０２．１ＡＳ－ｒｅｖを使用して実現される。ＴＳＮネットワーク内では、したがって、マイクロ秒以下の誤差で同期を実現することができる。このレベルの正確さを実現するために、例えばパケットのタイムスタンプについてのハードウェアサポートが要求されることがある。
ネットワークでは、グランドマスタ（ＧＭ：ｇｒａｎｄｍａｓｔｅｒ）は、マスタ－スレーブアーキテクチャにおける他の全てのノードにタイミング情報を伝送するノードである。ＧＭは、選択したグランドマスタを上位にする一定の基準で、いくつかの潜在的なノードから選ばれてもよい。
８０２．１ＡＳ（すなわちＰ８０２．１ＡＳ－ｒｅｖ）のＴＳＮ－拡張では、主なＧＭの次に、第２の冗長なバックアップＧＭも設定できることが規定されてきた。メインのＧＭが何らかの理由で止まった場合、ＴＳＮドメイン内のデバイスは、第２の冗長なＧＭに同期することができる。冗長なＧＭは、ホットスタンバイ設定で作動することができる。
汎用プリサイスタイミングプロトコル（ｇＰＴＰ）とも呼ばれるＩＥＥＥ Ｐ８０２．１ＡＳ－ｒｅｖに基づくＴＳＮでは、ＴＳＮネットワーク内でサポートされる、複数の時間ドメイン、および関連付けられたｇＰＴＰドメインが存在することができる。ｇＰＴＰは、以下の２つのタイムスケールをサポートする。
・タイムスケールＰＴＰ：エポックは、ＰＴＰエポックであり（ＩＥＥＥ８０２．１ＡＳ－ｒｅｖセクション８．２．２で詳しく述べられている）、このタイムスケールは、連続的なものである。時間の測定単位は、回転周期で理解されるような、ＳＩ秒である。
・タイムスケールＡＲＢ（任意）：このタイムスケールについてのエポックは、ドメイン始動時間であり、管理手順でセットアップすることができる（ＩＥＥＥ８０２．１ＡＳ－ｒｅｖ、セクション３．２でより詳しく述べられている）。
ＴＳＮネットワーク内のデバイスは、複数の時間ドメインに同期することができる。任意のローカル時間ドメインは、ワーキングクロックとも呼ばれることがある。
ＴＳＮストリームをセットアップするための最初のステップの１つは、上記で説明したように、および図１０９に示したように、タイムセンシティブストリームを交換することになるエンドポイント（トーカおよびリスナ）をグループ化することによる、ＣＮＣによるＴＳＮドメインの確立である。このリストは、ＣＵＣによってＣＮＣに提供される。ＣＮＣは、各ＴＳＮドメイン（トーカ、リスナ、およびブリッジ）が独自のワーキングクロックを有するように、これらのエンドポイントを接続するブリッジをさらに設定する。技術的に、これは、外部ポート役割設定、メカニズムを設定することによって、ＩＥＥＥ Ｐ８０２．１ＡＳ－ｒｅｖに従って行うことができる。
図２１４は、あらゆるＰＴＰパケットのために使用されるＰＴＰヘッダを示す（いくつかのフィールドの解釈は、ＩＥＥＥ１５８８の新版で、およびこれに対応して、ＩＥＥＥ Ｐ８０２．１ＡＳＲｅｖで見直されつつあることに留意されたい）。ｄｏｍａｉｎＮｕｍｂｅｒは、どの時間ドメインにフレームが属するかを、各フレームに対して規定する。ＰＴＰ時間ドメインは、単一のネットワークインフラストラクチャ上で複数の独立したＰＴＰクロックを使用できるようにする。これらの番号は、各終端局において設定されなければならす、その結果、各終端局は、どの時間ドメインを必要としているかについて認識する。
ＩＥＥＥ Ｐ８０２．１ＡＳ－Ｒｅｖ／Ｄ７．３の通り、アナウンスおよびシグナリングメッセージの宛先アドレスに、マルチキャストアドレス０１－８０－Ｃ２－００－００－０Ｅを予約することが指定される。さらに、ピアツーピアの同期のために全てが使用されるＳＹＮＣ、Ｆｏｌｌｏｗ－Ｕｐ、Ｐｄｅｌａｙ＿Ｒｅｑｕｅｓｔ、Ｐｄｅｌａｙ＿Ｒｅｓｐｏｎｓｅ、およびＰｄｅｌａｙ＿Ｒｅｓｐｏｎｓｅ＿Ｆｏｌｌｏｗ＿Ｕｐの宛先ＭＡＣアドレスにも、マルチキャストアドレス０１－８０－Ｃ２－００－００－０Ｅを予約する。ＩＥＥＥ８０２．１Ｑの通り、このアドレスを伴うフレームは、決して転送されることはない（転送不能アドレス）が、ブリッジで終端にならなければならないことに留意されたい。ソースアドレスとして、これらは、任意の出口物理ポートのＭＡＣアドレスを使用することになる。
上記で紹介したように、ＴＳＮドメインは、例えばグローバルクロックおよびワーキングクロックなどの、種々のクロックで作動する。さらに、各ＴＳＮドメインのクロックは、必ずしも同期せず、工場ネットワークは、いくつかのＴＳＮドメインを含むことができる。したがって、工場ネットワーク全体に、任意のタイムスケールを伴ういくつかの独立したＴＳＮドメインがあってもよく、ここで、デバイスの種々の、場合によっては重複するサブセットを同期しなければならない。図１４５に示されているように、各ＴＳＮドメインは、独自のワーキングクロックを保持することができる。
製造ユースケースにおけるＴＳＮのための時刻同期要件を満たすために、例えばセンサまたはアクチュエータなどの、全ての機械を同期することができる時間基準を提供するために、セルラネットワークが要求される。
現在、ＬＴＥ無線についての３ＧＰＰ標準化リリース１５では、基地局（ＢＳ）とＵＥとの間の時刻同期をマイクロ秒以下の正確さで可能にするメカニズムが開発されてきた。
ＲＲＣメッセージ内に追加された３つのＩＥを伴うＵＥへのＧＰＳ時間を伝送するために、例えば、例えば０．２５μｓといった一定の粒度の時間基準、および不確実値、ならびにＤＬ無線リソース制御（ＲＲＣ）メッセージＵＥＴｉｍｅＲｅｆｅｒｅｎｃｅなどの、２つの情報要素（ＩＥ：Ｉｎｆｏｒｍａｔｉｏｎ Ｅｌｅｍｅｎｔ）をＳＩＢ１６に追加することが、３ＧＰＰ ＲＡＮ２で提案されてきた。
この手順の主な目的は、この情報の不正確さを伴う、ＵＥへのＧＰＳベースの時間基準情報を転送することである。
ＬＴＥは、ＧＰＳ時間および協定世界時（ＵＴＣ）に関する情報を収めるＳＩＢ１６内のタイミング情報に関連した、いくつかのシステム情報ブロック（ＳＩＢ：ｓｙｓｔｅｍ ｉｎｆｏｒｍａｔｉｏｎ ｂｌｏｃｋ）を規定する。
ＳＩＢは、ダウンリンク共有チャネル（ＤＬ－ＳＣＨ）で伝送される。サブフレーム内のＳＩＢの存在は、特殊システム－情報ＲＮＴＩ（ＳＩ－ＲＮＴＩ）でマークされた、対応する物理ダウンリンク制御チャネル（ＰＤＣＣＨ）の伝送で示される。
情報要素（ＩＥ）ＳＩＢ１６は、ＧＰＳ時間およびＵＴＣに関する情報を収める。ＵＥは、パラメータブロックを使用して、ＧＰＳおよび現地時間を取得することができる。
時刻同期を行う別の方法は、ＲＲＣシグナリング内の時間基準情報メッセージを使用して、ＵＥにＧＰＳ時間を伝送することであってもよい。
リリース１６の作業は進行中であり、ＴＳＮおよび産業用アプリケーションによって要求されるような、時刻同期の必要性に取り組むために、種々のオプションが論じられる。特に、５Ｇにおける複数時間ドメインのサポートは、オープンな話題である。
この現在の議論のために、時間情報をトランスポートするために５ＧＳ内部シグナリングを使用することが仮定される。この場合、５ＧＳは、（ＩＥＥＥ１５８８境界クロックに準拠しているものと規定された）ｇＰＴＰ時間認識デバイスとして機能することができ、入口ｇＰＴＰフレームを使用して、５ＧＳ自体が時間を認識することができるか、５Ｇシステムクロック、および外部ＴＳＮクロックをハンドリングする分離したｇＰＴＰインスタンスを含むことができる。ＲＡＮおよびコアにおける内部シグナリングは、関連するｇＰＴＰ情報を内部でトランスポートするために使用することができ、ＵＥによって受信したとき、ＵＥ出口におけるｇＰＴＰマスタとして機能することができる。５ＧＳは、この場合、全てのベストマスタクロックアルゴリズム（ＢＭＣＡ：Ｂｅｓｔ Ｍａｓｔｅｒ Ｃｌｏｃｋ Ａｌｇｏｒｉｔｈｍ）をサポートし、ＢＭＣＡに参加しなければならず（この場合、ｇＰＴＰドメインあたり１つのｇＰＴＰインスタンスが、動作しなければならない）、または、外部エンティティによるそのｇＰＴＰの役割に設定される。静的なＢＭＣＡが実行される場合、簡素化したオプションが可能である。ＢＭＣＡの実際の動作は本開示の範囲外であるが、本明細書で識別されるソリューションは、Ａｎｎｏｕｎｃｅメッセージを介して受信した関連情報の転送をサポートする。カスケード型時間認識システムが実行される場合、Ａｎｎｏｕｎｃｅメッセージの生成も、５ＧＳインターフェースにおいて、または、５ＧＳノードの内部インターフェースにおいて、要求されることがある。
スレーブをマスタに同期させるために、ｇＰＴＰメッセージが送られる。ｇＰＴＰでは、ネットワーク内で複数の時間ドメインを同時に確立するために、例えば、ドメイン番号が使用される。これらの番号は、一定の時間ドメインマスタに、スレーブがそのクロックを同期するのに役立つ。これまでのところ、産業用オートメーションアプリケーションによって要求されるような複数の時間ドメインを、５Ｇシステムが効率的にサポートできる方式はない。これは、例えば３２個のドメインなど、多数のドメインをサポートしなければならず、多数のＵＥを接続する場合、特に重要である。
５ＧＳにおいて時間信号がどのようにトランスポートされるか、および特に、どの伝送タイプ（ブロードキャスト、マルチキャスト、ユニキャスト）がＲＡＮにおいて選ばれるかに応じて、どの時間ドメイン信号をＵＥが必要としているかについてのＲＡＮの知識が、非常に重要なものになり得る。それでも、これは、今日サポートされていない。
図２１５は、本明細書における実施形態を実行することができる第１のシナリオによる通信ネットワーク１００の例を描写する。通信ネットワーク１００は、例えば、ＬＴＥ、Ｅ－Ｕｔｒａｎ、ＷＣＤＭＡ、ＧＳＭネットワーク、任意の３ＧＰＰセルラネットワーク、Ｗｉｍａｘ、または任意のセルラネットワークもしくはシステムなどの無線通信ネットワークである。
通信ネットワーク１００は、無線アクセスネットワーク（ＲＡＮ）およびコアネットワーク（ＣＮ）を含む。通信ネットワーク１００は、少しの可能な実装形態に言及するだけでも、Ｌｏｎｇ－Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ（ＬＴＥ）、ＬＴＥアドバンスト、５Ｇ、広帯域符号分割多元接続（ＷＣＤＭＡ）、汎欧州デジタル移動電話方式／エンハンストデータレートフォーＧＳＭエボリューション（ＧＳＭ／ＥＤＧＥ）、マイクロ波アクセスのための世界的相互運用性（ＷｉＭａｘ）、Ｗｉ－Ｆｉ、またはウルトラモバイルブロードバンド（ＵＭＢ）など、いくつかの異なる技術を使用することができる。通信ネットワーク１００では、１つまたは複数のＵＥ１２０は、例えばＲＡＮといった１つまたは複数のアクセスネットワーク（ＡＮ）を介して、１つまたは複数のＣＮに通信することができる。ＵＥ１２０は、例えば、無線デバイス（ＷＤ）、移動局、非アクセスポイント（ｎｏｎ－ＡＰ）ＳＴＡ、ＳＴＡ、および／または無線端末であってもよい。「無線デバイス」は、任意の端末、無線通信端末、ユーザ機器、マシン型通信（ＭＴＣ）デバイス、Ｄ２Ｄ（ｄｅｖｉｃｅ－ｔｏ－ｄｅｖｉｃｅ）端末、または、例えば、スマートフォン、ラップトップコンピュータ、携帯電話、センサ、中継、モバイルタブレット、もしくはことによると、セル内で通信する基地局といった、ノードを意味する非限定的な用語であることが当業者によって理解されよう。
ＲＡＮは、５ｇ、ＬＴＥ、ＵＭＴＳ、Ｗｉ－Ｆｉ、または同様のものなどの無線アクセス技術（ＲＡＴ）のセル１３０、１３１など、１つまたは複数の地理的領域にわたる無線カバレッジをそれぞれ提供する、無線ネットワークノード１１０、１１１などの、無線ネットワークノードのセットを備える。無線ネットワークノード１１０、１１１は、無線ローカルエリアネットワーク（ＷＬＡＮ）アクセスポイントまたはアクセスポイント局（ＡＰ ＳＴＡ）、アクセスコントローラ、例えば、ｇＮＢ、ノードＢ、エボルブドノードＢ（ｅＮＢ、ｅノードＢ）、ベーストランシーバ基地局、アクセスポイント基地局、基地局ルータ、無線基地局の伝送配置、スタンドアロンアクセスポイント、または、例えば使用される第１の無線アクセス技術および専門用語に応じて、無線ネットワークノード１１０、１１１によってサーブされるサービスエリアとも呼ばれることがあるセル内の無線デバイスをサーブすることができる他の任意のネットワークユニットなどの、無線基地局といった基地局など、無線ネットワークコントローラまたはアクセスポイントなどの無線アクセスネットワークノードであってもよい。
ＣＮは、例えばＳ１インターフェースを介して、無線ネットワークノード１１０、１１１と通信するように設定されたコアネットワークノード１４０をさらに備える。コアネットワークノードは、例えば、モバイルスイッチングセンタ（ＭＳＣ）、モビリティ管理エンティティ（ＭＭＥ）、運用管理（Ｏ＆Ｍ）ノード、運用アドミニストレーション保守（ＯＡＭ）ノード、運用サポートシステム（ＯＳＳ）ノード、および／または自己組織化ネットワーク（ＳＯＮ）ノードであってもよい。コアネットワークノード１４０は、さらに、クラウド１４１に含まれる分散型ノードであってもよい。
ＵＥ１２０は、サービングセルと呼ばれるネットワークノード１１０のセル１３０内に位置し、その一方で、ネットワークノード１１１のセル１３１は、近接セルと呼ばれる。図２１５のネットワークノード１１０は、サービングセル１３０を提供することしか描写されていないが、ネットワークノード１１０は、サービングセル１３０への１つまたは複数の近接セル１３１をさらに提供することができる。
本明細書における実施形態を例示するために、３ＧＰＰ ５Ｇからの専門用語を本開示で使用してきたが、これは、本明細書における実施形態の範囲を、前述のシステムだけに限定するものとみなされるべきではないことに留意されたい。ＷＣＤＭＡ、ＷｉＭａｘ、ＵＭＢ、ＧＳＭネットワーク、任意の３ＧＰＰセルラネットワーク、または任意のセルラネットワークもしくはシステムを含む他の無線システムも、本開示内のカバーされるアイデアを活用することから利益を得ることができる。
以下では、本明細書における実施形態をさらに詳細に説明する。
本明細書における実施形態によれば、５ＧＳは、グランドマスタが展開された外部ネットワークからのｇＰＴＰメッセージを受信することができる。ＧＭからのｇＰＴＰメッセージは、５ＧＳのＵＥまたはＵＰＦ側で受信することができる。上記で紹介したように、産業用ネットワークにおいて複数の時間ドメインが使用されるので、５ＧＳに到着する複数の信号があることもある。グランドマスタが５ＧＳのＵＰＦ側に位置するシナリオについての、５ＧＳにおける複数の時間ドメインサポートの１つの例が図８９に示されている。図８９では、ｇＰＴＰメッセージがｇＮＢに直接トランスポートされ、これは、１つの可能な実装形態である。いずれかのｇＰＴＰメッセージが、ｇＰＴＰメッセージが属する時間ドメインを規定するドメイン番号を含む。
本明細書における本実施形態は、５ＧＳにおけるｇＰＴＰフレームの不透明トランスポートが使用されると仮定し、言い換えれば、情報は、ｇＰＴＰフレームから抽出され、３ＧＰＰシグナリングを使用して５ＧＳを通じて中継される。時間ドメインについて、およびどのＵＥがどの時間ドメインに属すかについての情報は、多くのＵＥが接続され、例えば３つ以上のｇＰＴＰドメインなど、かなりの数のｇＰＴＰドメインをサポートしなければならないケースにとって、特に重要である。
１つのシナリオは、グランドマスタが５ＧＳのダウンリンクのＵＰＦ側にある場合であり、ＵＰＦまたはｇＮＢは、ｇＰＴＰメッセージを受信することができ、外部ＴＳＮネットワークに対するスレーブとして機能することができる。したがって、ＵＰＦで、またはｇＮＢで実行される、例えばｇＰＴＰアプリケーションの具体例などの、１つの特定のｇＰＴＰインスタンスは、ｄｏｍａｉｎＮｕｍｂｅｒ属性で示されるような、この特定のｇＰＴＰドメインに属するｇＰＴＰメッセージをハンドリングし、例えば特定のｇＰＴＰドメインのためのＢＭＣＡの結果として、関連したＧＭにロックすることができる。ＵＰＦが具体例を提供する場合、ＵＰＦは、ＵＰＦが属す時間ドメインについての情報に加えて、ｇＰＴＰメッセージから抽出された時間情報を１つまたは複数のｇＮＢに転送することになる。ＵＰＦは、例えば、対応する時間情報および時間ドメイン情報を１つまたは複数のｇＮＢにＵＰＦが中継することになる、イーサネットＭＡＣマルチキャストアドレスのセットで設定することができる。ＵＥへのさらなる分散のためにＵＰＦがｇＰＴＰメッセージをｇＮＢに中継したｇＰＴＰメッセージから、例えば外部ＴＳＮワーキングクロック値および対応する時間ドメインなどのタイミング情報をＵＰＦが獲得したとき、実際のｇＰＴＰメッセージは中継されないことに留意されたい。ＲＡＮ内でタイミング情報を伝送するために、異なるオプションを利用することができ、具体的には、ｇＮＢの関与を必ずしも必要としない。例えば、分散型時間認識アプローチが実行される場合、５ＧＳのエッジにおけるデバイスのみが、ｇＰＴＰメッセージをハンドリングし、処理しなければならないことがある。それでも、本明細書における実施形態は、ＲＡＮが必ず含まれるケースに焦点を合わせ、タイミング情報をＵＥに伝えるためにＳＩＢベースまたはＲＲＣベースの方法を使用する。
無線ブロードキャスト（例えばＳＩＢメッセージ）がＲＡＮにおいて使用される場合、ＵＥは、どのブロードキャストされた信号がどの時間ドメインに属すかについて知っていなければならない。各時間ドメインは、個別にブロードキャストされてもよく、または１つのブロードキャスト信号が、複数の時間ドメインについての情報を搬送してもよい。
－ １つの実施形態では、これは、例えば、それぞれのブロードキャストされた信号で、または１つの信号の中で複数の、例えば０～１２７までの例えば整数などの、ｄｏｍａｉｎＮｕｍｂｅｒを示すＳＩＢ信号の中でＵＥに送られた追加のパラメータを追加することによって解決することができる。
－ 別の実施形態では、ブロードキャストされた信号は、どの追加のパラメータも搬送しないが、ブロードキャストされると、信号は、ドメイン０、または、ドメイン０、１、２～Ｎなどのドメイン番号のリストなどの特定の時間ドメイン信号を常に搬送する。ブロードキャストメッセージの中で送られた、どのドメイン番号、または、ドメイン番号のどのリストを、事前設定できるか、タイミング情報とともにブロードキャストメッセージを送る前にＵＥに送ることができるか。
－ さらに別の実施形態によれば、ＵＥは、ＵＥが接続された１つまたは複数の終端局がどの時間ドメインを必要とするかを学習することができる。ＵＥ、例えば、終端局によって周期的に配信されるｇＰＴＰ Ａｎｎｏｕｎｃｅメッセージをリッスンすることによって、これを学習することができる。ＢＭＣＡの結果として、ＵＥは、５Ｇネットワークからの時間信号を転送するマスタ状態で動作するＰＴＰポートを実行することになり、サポートしなければならない特定のＰＴＰドメインでしか動作しない。これは、ＵＥが、必要とするブロードキャストされた時間信号情報からの時間ドメインしか選択しないことを意味する。
－ ある意味では、５ＧＳは、例えば、ＵＥ識別子、またはＵＥに接続された終端局のＭＡＣアドレスそれぞれによって、どの時間ドメイン信号がどのＵＥに向けられなければならないかについての、ＴＳＮネットワークコントローラからの情報を取得することができる。情報は、例えば、ＣＮＣがＴＳＮネットワーク内のＴＳＮドメインをセットアップしたとき、アプリケーション機能（ＡＦ）に向けて外部ＴＳＮ ＣＮＣから送られてもよい。ＣＮＣは、どの時間ドメイン信号が、例えばＵＥまたはＭＡＣアドレスなど、どのポートに転送されなければならないかをアナウンスすることができる。ＡＦは、ＳＭＦまたはＡＭＦまたは別のコアネットワーク機能をトリガして、どの時間ドメイン信号をＵＥがリッスンしなければならないかをＵＥに告げることができる。詳細は、以下の通りである。
－ ＣＵＣは、どのクロックドメインを終端局が望んでいるかを正確に知っていてもよい。
－ ＣＵＣは、次に、５Ｇ「ブリッジ」（すなわち、ブリッジ／時間認識中継としてモデル化された５Ｇシステム）を設定することをＣＮＣに告げることができる。ＣＮＣは、例えば、５Ｇブリッジの北行きと、５Ｇブリッジの南行きとの間のリンクをセットアップすることを５ＧＳに求めることができ、その結果、正しいタイミングを、対応する終端局に配信することができる。
－ ５ＧＳは、ＣＮＣからＡＦ情報を受信することができ、ＣＮＣコマンドを５ＧＳシグナリングに変換することができる。これは、スイッチの内部で、または、本明細書における実施形態による５ＧＳの内部で、ｇＰＴＰラピッドスパニング木を規定するために、ＣＮＣによって実施することができる外部ポート設定と呼ばれることがある。ＣＮＣからの情報として外部ポート設定を利用できる場合、ＢＣＭＡは、もはや要求されない。ポートは、各時間ドメイン信号がＩＥＥＥ Ｐ８０２．１ＡＳ－ｒｅｖ規格に従って５ＧＳでルートされなければならない場合に解釈することができる、例えば、ＭａｓｔｅｒＰｏｒｔ、ＳｌａｖｅＰｏｒｔ、ＰａｓｓｉｖｅＰｏｒｔ、またはＤｉｓａｂｌｅｄＰｏｒｔなど、種々の役割を行うように、ＣＮＣによって設定することができる。ＡＦからの５ＧＳ内部シグナリングは、ブロードキャストが使用される場合、例えば、どの時間ドメイン信号をＵＥがリッスンしなければならないかをＵＥに知らせるために使用されてもよい。
（例えばＲＲＣシグナリングを使用した）無線マルチキャストまたはユニキャストが使用される場合、１つまたは複数のｇＮＢは、一般に、どの１つまたは複数のＵＥがどの時間ドメインからのどの時間信号を必要とするかを知っていなければならない。
－ １つの実施形態によれば、これは、どの時間ドメインにＵＥの関心があるか、またはより正確には、ＵＥに接続された１つまたは複数の終端局がどの時間ドメインに関心があるかについての信号を、ＵＥからｇＮＢに送ることによって実現することができる。この情報は、どの時間信号をＵＥがリッスンすべきかを各デバイスが知っているので、ＵＥが接続された終端局で利用可能である。前記情報を取得するために、ＢＣＭＡからの方法を使用することができる。これは、例えば、複数の終端局によってフォローされる単一の終端局またはスイッチになどに、ＵＥがどのように接続されるかに応じて、単一または複数の時間ドメインであってもよく、ブロードキャストするケースに関して説明されるもののような方法が、終端局の関心を学習するために有効である。ｇＮＢは、ＵＥが必要とする時間ドメインについての情報をＵＥに問い合わせることができ、または、ＵＥは、どの時間ドメインをＵＥが必要とするかについての情報を、ネットワークに接続された後、ｇＮＢに送ることができる。これは、例えば、ＵＥとｇＮＢとの間のＲＲＣメッセージングを使用して実施することができる。
－ 別の実施形態によれば、ＵＥは、特定の１つまたは複数の時間ドメインに手動で設定することができ、ＵＥが必要とする時間ドメインについての情報は、コアネットワーク機能で利用可能であってもよい。例えば５ＧＳにおけるデータベースに問い合わせるために、ＵＥの５Ｇ内部識別子が使用されてもよく、どの時間ドメインにＵＥが同期されるべきかがデータベース内に記される。ｇＮＢは、コアネットワーク機能に問い合わせることができる。コアネットワーク機能は、どのＵＥがどの時間ドメイン信号を必要とするかをｇＮＢに告げることができる。１つのソリューションは、ＰＤＵセッションがセットアップされるときに、ＳＭＦがこの情報をＲＡＮに提供することであってもよい。ブロードキャストのケースについて、どの時間ドメイン信号がどのＵＥに転送されなければならないかについてのこの設定または情報は、ＴＳＮドメインセットアップフェーズ中に、例えばＡＦを通じて、外部ＴＳＮ ＣＮＣ（外部ポート設定）から受信することができる。この情報は、どのＵＥがどの時間ドメイン信号を必要としているかをＲＡＮに知らせるために、５ＧＳ内でＲＡＮに内部で転送されてもよい。ＵＥは、ｇＮＢによって、これらの信号だけをＵＥに送ることができるので、他のデバイスに転送するために要求される１つまたは複数の時間信号しか受信しない。ＵＥに送られた種々の時間信号を分離するために、ＵＥとｇＮＢとの間で識別子を取り決めてもよく、または、ＵＥが種々の時間ドメインを区別し、ｇＰＴＰフレームを適宜転送すること、すなわち、正しいｄｏｍａｉｎＮｕｍｂｅｒをｇＰＴＰフレームに入れることができるように事前設定されてもよい。事前設定は、ドメイン番号がユニキャストＲＲＣメッセージの中ではシグナリングされないが、ＵＥが、どのドメイン番号をメッセージが指すかを認識しているようなものであってもよい。ＵＥによってサポートされる時間ドメインが１つしかない場合、これは、わかりやすい。ＵＥによってサポートされる時間ドメインが複数ある場合、ユニキャストメッセージは、例えば時間ドメイン番号の昇順または降順で並べられた、時間情報のリストを含むことができる。
５ＧＳの出口において、すなわち、メッセージが５ＧＳを離れる場合、ＵＥは、ＵＥに接続された任意のデバイスに対するｇＰＴＰマスタとして機能することができる。これは、ｇＮＢからの、例えばｄｏｍａｉｎＮｕｍｂｅｒなどの、タイミング情報および他の情報に基づく、例えば、Ｓｙｎｃ、Ｆｏｌｌｏｗ＿ｕｐ、Ｐｄｅｌａｙ＿Ｒｅｑｕｅｓｔ、Ｐｄｅｌａｙ＿Ｒｅｓｐｏｎｓｅ、Ｐｄｅｌａｙ＿Ｒｅｓｐｏｎｓｅ＿Ｆｏｌｌｏｗ＿ｕｐ、Ａｎｎｏｕｎｃｅ等など、様々なｇＰＴＰフレームの作成または再作成に含まれてもよい。これは、図２１７の、受信デバイスによって実施される方法について説明したアクション１２０２と同様である。
上記で言及した実施形態全てについて、時間信号がユニキャストされるか、マルチキャストされるか、ブロードキャストされるかに加えて、ＲＡＮ内で時間信号がどのようにトランスポートされるか（すなわち、どの信号が使用されるか、および、十分な正確さを実現するために、これらの信号がどのようにデザインされるか）は重要ではない。
上記で言及した実施形態全てについて、例えばＢＭＣＡのハンドリングに関する情報、および、例えばクロック識別子などの、出て行くＰＴＰメッセージを生成するために要求される関連情報など、ＵＥとの間で他のｇＰＴＰ情報を伝送することも、さらに関連していることがある。これは、時間信号伝送の次の専用ＲＲＣもしくはＳＩＢシグナリングとしての、または、ＲＲＣもしくはＳＩＢメッセージにおける時間シグナリングの一部としての、上記で説明した全部で３つのケース、すなわち、ブロードキャスト、マルチキャスト、およびユニキャスト、におけるケースであってもよい。
さらに、インターネットプロトコル（ＩＰ）が、ｇＰＴＰフレームをトランスポートするために使用されてもよい。本明細書における全ての方法は、レイヤ３（Ｌ３）上のイーサネットより上でＩＰが使用されるこのケースに、同様に適用可能であってもよい。
別のシナリオは、グランドマスタが５ＧＳのアップリンクのＵＥ側にあるときであり、グランドマスタが、５ＧＳのＵＥ側にあるとき、ＵＥは、時間情報をｇＮＢに転送しなければならない。ＵＥは、ｇＰＴＰメッセージを受信することができ、したがって、時間認識している。５ＧＳは、伝送された信号がどの時間ドメインに属すかについて知らされなければならない。例えばＲＲＣシグナリングを使用するなど、ユニキャストだけが、アップリンクにおいて可能である。
１つの実施形態では、５Ｇネットワークは、時間ドメイン番号を示す、ＵＥからｇＮＢへの専用ＲＲＣシグナリングによって、時間ドメインについて知らされてもよい。複数の時間ドメインが存在するとき、専用ＲＲＣシグナリングは、複数の時間ドメイン番号を含むことができる。ｇＮＢは、この情報を受信し、ＵＰＦにこの情報を転送することができ、または、正しいｄｏｍａｉｎＮｕｍｂｅｒでｇＰＴＰフレームを最終的に再確立するために、ＵＥからのタイミング情報を正しい時間ドメインに転送するために、この情報自体を使用することができる。ＲＲＣシグナリングは、時間シグナリングの一部として実施することができ、あらかじめ取り決めることができる。複数の時間ドメインからの時間をＵＥがシグナリングすると取り決めた場合、時間信号内の時間ドメインを区別するために、識別子を使用することができる。
さらなる実施形態によれば、時間ドメインも、事前設定されてもよい（ＵＥ＃１２３４５は、時間ドメインｉに属す時間ドメイン信号をアップリンクするようにのみ設定することができる）。複数の時間ドメインからの時間をＵＥがシグナリングすることになると事前設定した場合、時間ドメインを区別するために識別子を使用することができる。事前設定も、ダウンリンクの実施形態について説明したように、例えばＡＦを通じて、外部ＴＳＮ ＣＮＣからの入力に基づいて、上記の実施形態で説明されたように実施することができる。
本明細書における実施形態には、複数の時間ドメインとのエンドツーエンドの時刻同期を可能にするという利益がある。これにより、５ＧＳシステムは、現在、複数の時間ドメインからの時間信号を効率的に転送することができる。
図２１６は、ＴＳＮからのｇＰＴＰシグナリングをハンドリングするために、例えば５Ｇシステムなどの、無線通信システム（１００）における、例えば、ＵＥ１２０、ネットワークノード１１０、および／またはＵＰＦなどの、伝送デバイスによって実施される方法アクションを示す。
－ アクション１１０１：伝送デバイスは、ｇＰＴＰメッセージをＴＳＮネットワークから受信することができる。ｇＰＴＰメッセージは、時間情報、および時間情報に関する時間ドメインを含む。
－ アクション１１０２：伝送デバイスは、時間情報および時間ドメインをｇＰＴＰメッセージから抽出することができる。
－ アクション１１０３：伝送デバイスは、受信デバイスが関連した時間ドメインに関する情報を取得することができる。特定のデバイスが関連した時間ドメインに関する情報は、どの時間ドメインに受信デバイスが関連しているかを示す受信デバイスからの信号を受信することによって取得することができ、指示は、例えば、ＲＲＣシグナリングによってシグナリングすることができる。いくつかの実施形態では、受信デバイスは、１つまたは特定の時間ドメインで事前設定されてもよく、受信デバイスが関連した時間ドメインに関する情報は、特定の受信デバイスがサポートするように設定された時間ドメインを含むデータベースに問い合わせることによって、すなわち、クエリを送ることによって、伝送デバイスで取得することができる。３ＧＰＰメッセージに含まれる時間ドメインは、識別子を使用して示されてもよい。識別子は、データベースに問い合わせるときに使用されてもよい。
－ アクション１１０４：伝送デバイスは、例えば、無線ネットワークノード１１０、ＵＰＦ、および／またはＵＥ１２０などの受信デバイスに、時間情報、および時間情報に関する時間ドメインを含む３ＧＰＰメッセージをさらに伝送することができる。３ＧＰＰメッセージは、例えば、ブロードキャストするために使用されるセッション確立プロトコル（ＳＩＰ）メッセージ、または、無線リソース制御（ＲＲＣ）メッセージであってもよい。
－ アクション１１０４ａ：伝送デバイスは、アクション１１０３で受信した情報に基づいて、マルチキャストまたはユニキャストを使用して、３ＧＰＰメッセージに含まれる時間ドメインに関連した１つまたは複数の受信デバイスに、時間情報、および時間情報に関する時間ドメインを含む３ＧＰＰメッセージを伝送することができる。
－ アクション１１０４ｂ：伝送デバイスが無線ネットワークノードまたはＵＰＦであるとき、伝送デバイスは、ブロードキャストを使用して、受信デバイスに３ＧＰＰメッセージを伝送することができる。伝送デバイスは、３ＧＰＰメッセージの中で追加のパラメータまたは専用シグナリングを伝送することができる。追加のパラメータは、ブロードキャストされた３ＧＰＰメッセージが関係する時間ドメインまたは時間ドメイン番号を示すことができる。
図２１７は、ＴＳＮからのｇＰＴＰシグナリングをハンドリングするために、例えば５Ｇシステムなどの、３ＧＰＰ無線通信システム１００における、例えば、ＵＥ１２０、ネットワークノード１１０、および／またはＵＰＦなどの、受信デバイスによって実施される方法アクションを示す。受信デバイスは、本明細書では、受信エンティティとも呼ばれることがある。
－ アクション１２０１：受信デバイスは、時間情報、および時間情報に関する時間ドメインを含む３ＧＰＰメッセージを、例えば、無線ネットワークノード１１０、ＵＰＦ、および／またはＵＥ１２０などの伝送デバイスから受信することができる。３ＧＰＰメッセージは、マルチキャスト、ユニキャスト、またはブロードキャストを使用して受信することができる。
－ アクション１２０２：受信デバイスは、３ＧＰＰメッセージに含まれる時間情報および時間ドメインに基づいて、時間情報、および時間情報に関する時間ドメインを含むｇＰＴＰメッセージを作り出すこと、および／または再作成することができる。
－ アクション１２０３：ブロードキャストされたメッセージとして３ＧＰＰメッセージを受信すると、受信デバイスは、終端局が受信デバイスに接続された、ＴＳＮネットワーク内の１つまたは複数の終端局によってサポートされる時間ドメインに関する情報をさらに取得することができる。ＴＳＮ内の終端局によってサポートされる時間ドメインに関する情報は、例えば、終端局によって周期的に配信された、例えばｇＰＴＰ Ａｎｎｏｕｎｃｅメッセージなどの、ｇＰＴＰメッセージを受信することによって取得することができる。ＴＳＮ内の終端局によってサポートされる時間ドメインに関する情報は、さらなる実施形態では、ＴＳＮネットワークコントローラからの情報を受信することによって取得することができ、情報は、例えばＵＥ識別子などの受信デバイス識別子、または終端局のＭＡＣアドレスを含む。
－ アクション１２０４：受信デバイスは、ＴＳＮネットワーク内の１つまたは複数の終端局にｇＰＴＰメッセージを伝送することができ、ｇＰＴＰメッセージは、３ＧＰＰメッセージから抽出された、時間情報、および時間情報に関する時間ドメインを含む。
－ アクション１２０４ａ：受信デバイスは、アクション１２０３で取得した情報に基づいて、ＴＳＮの終端局によってサポートされる時間ドメインに関するブロードキャストされた時間情報を終端局に伝送することができる。したがって、受信デバイスに接続されたＴＳＮの終端局によってサポートされる時間ドメインに関係ない、どのブロードキャストされた時間情報も、受信デバイスによって終端局に伝送されることはない。
タイムセンシティブネットワークからのプリサイスタイミングプロトコルシグナリングをハンドリングするための技法のさらなる実施形態を下記で説明する。
本明細書における実施形態によれば、５ＧＳは、グランドマスタ（ＧＭ）が展開された外部ネットワークからｇＰＴＰメッセージを受信することができる。ＧＭからのｇＰＴＰメッセージは、５ＧＳのＵＥまたはＵＰＦ側で受信することができる。上記で紹介したように、産業用ネットワークにおいて複数の時間ドメインが使用されるので、５ＧＳに到着する信号が複数あることもある。下記の実施形態では、ｇＰＴＰフレームが５ＧＳ内で透過的にトランスポートされると仮定される。この場合、多くのＵＥが接続され、例えば３つ以上のｇＰＴＰドメインなど、かなりの数のｇＰＴＰドメインをサポートしなければならない場合のために、どのノードがどの時間ドメイン信号（すなわち、一定のｄｏｍａｉｎＮｕｍｂｅｒに搬送するｇＰＴＰフレーム）を必要とするかについて知っていることが特に重要である。時間信号のアップリンクおよびダウンリンク両方の送信のためのソリューションを紹介する。時間ドメインについて、および、どのＵＥがどの時間ドメインに属すかについての情報は、多くのＵＥが接続され、例えば３つ以上のｇＰＴＰドメインなど、かなりの数のｇＰＴＰドメインをサポートしなければならない場合に特に重要である。
５ＧＳのダウンリンクのＵＰＦ側のグランドマスタ：５ＧＳは、ｇＰＴＰフレームをエンドツーエンドで転送し（すなわち、所与のワーキングクロックをサポートするＴＳＮソースノードは、ＵＥと、または、このＵＥに関連付けられた終端局と、ｇＰＴＰフレームを交換する）、ｇＰＴＰフレームは、時間情報を搬送する。各ｇＰＴＰフレームは、ｇＰＴＰフレームが属す時間ドメインを示すｄｏｍａｉｎＮｕｍｂｅｒヘッダフィールドを含むことができる。ｇＰＴＰフレームは、ＵＥに、または複数のＵＥに、ＰＤＵセッションでトランスポートされなければならないことがある。関連ソリューションの詳細は、例えば、分散型透過クロックとして機能すること、または、対称チャネルを作り出すように両方向の遅延を等しくすることなど、５ＧＳ全体にわたってＰＴＰ時間情報を「透過的に」搬送するために実行される特定のメカニズムに依存する。この場合、５ＧＳがＢＭＣＡに関与する必要はない。
ｇＰＴＰフレームのブロードキャストが５ＧＳで使用される場合：ｇＰＴＰフレームのブロードキャストが、代わりに、例えばｇＮＢによって、５ＧＳで実施される場合、１つまたは複数のＵＥは、一定のブロードキャストをリッスンするか否かを決めなければならない。これは、特定のＰＴＰドメインに属すＡｎｎｏｕｎｃｅメッセージを、ＵＥに接続された任意のデバイスが送るかどうかをチェックすることによって、上記の第１の実施形態と同様に実施することができる。ＵＥは、特定のｇＰＴＰ時間ドメインのブロードキャストを、これ以上リッスンしなくてもよく、または、接続された１つもしくは複数の終端局がこのＰＴＰドメインで動作していない場合、どのｇＰＴＰフレームも転送しなくてもよい。これは、全てのブロードキャストされたｇＰＴＰフレームをＵＥが転送する場合について、図２１８に、または、それぞれの終端局に、関連するｇＰＴＰフレームしかＵＥが転送しない場合について、図２１９に、示されている。ＵＥも、どの終端局がどの時間ドメイン信号を必要としているかを学習するために、一定のドメイン番号へのリプライをチェックするために、例えばアナウンスメッセージなどの、例えばｇＰＴＰフレームを終端局に送ることができる。
ｇＰＴＰフレームのユニキャストまたはマルチキャストが５ＧＳで使用される場合、５ＧＳへの入口フレームは、マルチキャスト宛先ＭＡＣアドレスを搬送することになり、５Ｇネットワーク（例えばＵＰＦ）は、どのＵＥ（すなわちＰＤＵセッション）に、これがｇＰＴＰフレームを転送することになるかを決めなければならず、ｇＰＴＰフレームは、ＰＴＰ固有のＥｔｈｅｒｔｙｐｅフィールドで検出することができる。
１つの実施形態では、ＵＥに接続された終端局は、終端局が動作しているｇＰＴＰドメインについての情報（ＰＴＰヘッダ内で搬送されるｄｏｍａｉｎＮｕｍｂｅｒ）を搬送するＡｎｎｏｕｎｃｅメッセージを生成することになる、または、５ＧＳノードは、例えばＡｎｎｏｕｎｃｅメッセージを使用して、終端局の関心を検出することができる。例えばＵＰＦのような、５ＧＳにおけるノードは、どのＵＥ、ＵＥの背後にあるそれぞれの終端局が、どのｇＰＴＰメッセージに関心があるかを学習すること、および、例えば入ってくるｇＰＴＰフレームを適宜ルーティングするためのルールを、確立することができる。
任意のフォローアップ／同期メッセージは、（この特定のｇＰＴＰドメインで動作するＵＥの１つである）これらのｇＰＴＰパケットに関心があるＵＥにしか伝送されず、ＵＥは、終端局のニーズについて学習するために、ＵＥが接続された１つまたは複数の終端局からのｇＰＴＰメッセージを、例えばＵＰＦに透過的に転送することになる。
この実施形態の例。
・ｇＰＴＰフレーム（例えばアナウンスメッセージまたは同期メッセージまたは他）が、外部ＴＳＮネットワークからＵＰＦに到着し、これらのフレームは、ｇＰＴＰマルチキャストイーサネット宛先ＭＡＣアドレス、および、これらのフレームが参照している時間ドメインを示す特定のｄｏｍａｉｎＮｕｍｂｅｒを搬送する。
・ＵＰＦは、ＭＡＣアドレスがマルチキャストを示すので、どのＵＥがこの時間ドメイン（ｄｏｍａｉｎＮｕｍｂｅｒ）からのフレームに関心があるかについて、その時点では知らず、したがって、ＵＰＦは、ｇＰＴＰフレームの全てもしくはサブセット、または（Ａｎｎｏｕｎｃｅメッセージのような）特定のｇＰＴＰフレームを、全てのＵＥ、または関連するＵＥの任意のサブセットに送る（オプションＡ）。さらに、または別のソリューションとして（オプションＢ）、終端局は、ＵＥが５Ｇネットワークに転送することになる任意のｇＰＴＰフレームを５ＧＳに終端局自体が送る。
・（オプションＡ）５ＧネットワークからｇＰＴＰフレームを受信するＵＥは、ＵＥが接続された終端局に、ｇＰＴＰフレームを転送することになる。終端局、またはこの終端局に接続された他の任意のピアが、（ｄｏｍｍａｉｎＮｕｍｂｅｒをチェックすることによって）この時間ドメインからのｇＰＴＰフレームに関心がある場合、終端局、またはこの終端局に接続された他の任意のピアは、ｇＰＴＰプロトコルで規定された方式でこれらのｇＰＴＰフレームにリプライすることになる（これは、ＰＴＰリンクの挙動を５ＧＳがエミュレートする場合に適用可能になり得るアプローチであり、ここでは、ｐｄｅｌａｙメッセージが、５Ｇシステム全体で交換される）。これらのパケットは、ＵＥが転送して５Ｇネットワークに戻され、これにより、５Ｇネットワークは、どのＵＥがどの時間ドメインからのフレームに関心があるかを検出することができる。
・（オプションＢ）：ＵＥは、例えば、終端局または複数の終端局からのＡｎｎｏｕｎｃｅメッセージまたは他の任意のＰＴＰメッセージを受信し、ＵＥは、これらのメッセージを５Ｇネットワークに転送し、Ａｎｎｏｕｎｃｅメッセージが搬送するｄｏｍａｉｎＮｕｍｂｅｒに基づいて、５ＧＳは、１つもしくは複数の終端局、または１つもしくは複数のＵＥに、それぞれ送られることになる正しいｄｏｍａｉｎＮｕｍｂｅｒを学習する。
別の実施形態によれば、特定の時間ドメインからのフレームをどのＵＥが受信することになるかについて、５Ｇネットワークにおいて事前設定されてもよく、フレームは、ｄｏｍａｉｎＮｕｍｂｅｒに基づいて、ＵＰＦにおいて、ＰＤＵセッションに転送されてもよい。ＳＭＦは、ＰＤＵセッションのセットアップまたは修正時に、ＵＰＦにおいてフィルタを設定するエンティティであってもよい。ある意味、５ＧＳは、どの時間ドメイン信号がどのＵＥ、すなわちＵＥ識別子、またはＵＥに接続された終端局のＭＡＣアドレスにそれぞれ向けなければならないかについて、ＴＳＮネットワークから情報を取得することになる。これは、例えば、ＴＳＮネットワーク内のＴＳＮドメインをＣＮＣがセットアップするとき、アプリケーション機能（ＡＦ）のために外部ＴＳＮ ＣＮＣから取得されてもよい。ＣＮＣは、どの時間ドメイン信号がどのポート、すなわちＵＥまたはＭＡＣアドレスに転送されなければならないかをアナウンスすることができる。ＡＦは、他の任意のコアネットワーク機能をトリガして、ＵＰＦにおいて正しいフィルタまたはルールをセットし、ｄｏｍａｉｎＮｕｍｂｅｒを使用して、正しいＰＤＵセッションにｇＰＴＰフレームを転送することができる。
これは、図２２０に示されている。詳細には、以下の通りである。
１． ＣＵＣは、どのクロックドメインを終端局が望んでいるかについて正確に知っていてもよい。
２． ＣＵＣは、次に、５Ｇ「ブリッジ」（ブリッジ／時間認識中継としてモデル化された５Ｇシステム）を設定することをＣＮＣに告げることができる（これは命令とも呼ぶことができる）。例えば、ＣＮＣは、５Ｇブリッジの北行きと、５Ｇブリッジの南行きとの間のリンクをセットアップすることを５ＧＳに求め、その結果、（例えば、どの入口ポートからどの出口ポートに）正しいタイミングを対応する終端局に配信することができる。
３． ５ＧＳは、トランスレータ機能を備えることができるＡＦで、ＣＮＣからの情報を受信することができ、３ＧＰＰシグナリングとも呼ばれることがある５ＧＳシグナリングにＣＮＣコマンドを変換することができる。ＩＥＥＥ Ｐ８０２．１ＡＳ－ｒｅｖのドキュメントでは、これは、スイッチの内部で、または我々のケースでは５ＧＳの内部で、ｇＰＴＰラピッドスパニング木を規定するために、ＣＮＣによって実施することができる外部ポート設定と呼ばれる。ＣＮＣからの情報として、外部ポート設定を利用できる場合、ＢＣＭＡは、もはや要求されない。ポートは、ＩＥＥＥ Ｐ８０２．１ＡＳｒｅｖ規格に従って、各時間ドメイン信号が５ＧＳ内でルートされなければならない場合、解釈することができる、ＭａｓｔｅｒＰｏｒｔ、ＳｌａｖｅＰｏｒｔ、ＰａｓｓｉｖｅＰｏｒｔ、またはＤｉｓａｂｌｅｄＰｏｒｔのような種々の役割に、ＣＮＣによって設定することができる。ＡＦからの５ＧＳ内部シグナリングは、ＵＰＦからＵＥへのＰＤＵセッションを、例えばセットアップ／更新するために、使用され、この場合、選択された／フィルタにかけられたクロックドメインだけが、対応するＵＥ／終端局に転送されることになる。
（例えばユニキャストまたはブロードキャストなどの）上記で説明した全ての実施形態について、ｇＰＴＰフレームがＵＥにユニキャストされるか、マルチキャストされるか、またはブロードキャストされるかに加えて、５ＧＳにおいてｇＰＴＰがどのようにトランスポートされるかは、さらに関係ない。これは、訂正時間を計算し、５ＧＳにおける様々な遅延を補償するための、５ＧＳ入口および出口におけるｇＰＴＰフレームのタイムスタンプを含むことができる。これは、図２２４、図２２５、および図２２６に示されており、この中で、メッセージが５ＧＳに入ったとき、５ＧＳの時間がメッセージに追加される。全てのｇＰＴＰパケット（Ｓｙｎｃ、Ｆｏｌｌｏｗ＿ｕｐ、Ｐｄｅｌａｙ＿Ｒｅｑｕｅｓｔ、Ｐｄｅｌａｙ＿Ｒｅｓｐｏｎｓｅ、ＰＤｅｌａｙ＿Ｒｅｓｐｏｎｓｅ＿Ｆｏｌｌｏｗ＿ｕｐ、Ａｎｎｏｕｎｃｅ等）を、または、例えば実際のタイムスタンプを収めるＦｏｌｌｏｗ－Ｕｐメッセージだけのように、ＲＡＮでこれらの任意のサブセットだけを、５ＧＳが伝送しなければならない可能性があるかは指定されず、したがって、任意の接続された終端局による有効なｇＰＴＰ通信ハンドリングを保証するために、いずれかの伝送されないパケットを、例えばＵＥ側で、作り出すことができる。１つの実施形態によれば、少なくとも１つのｇＰＴＰフレームが周期的に伝送されることになり、全ての必要情報（ｄｏｍａｉｎＮｕｍｂｅｒ、タイムスタンプ等）を搬送する。ｇＰＴＰフレームは、データパケットとして伝送されてもよい。
さらに、ｇＰＴＰフレームをトランスポートするためのものとして、インターネットプロトコル（ＩＰ）を使用することもできる。本明細書で説明される全ての実施形態は、レイヤ３（Ｌ３）上のイーサネットより上でＩＰが使用される場合、同様に適用可能であってもよい。図２２５および図２２６に示されているようなトランスレータ機能は、個々のエンティティであってもよく、またはＵＰＦ機能の一部であってもよい。トランスレータ機能は、ポイントツーポイントＰＤＵセッションを介してクロック／時間ドメインをＵＥに送ることができ、または、ＰＤＵセッションの内部で複数のフローを送ることができる。トランスレータ機能は、また、本明細書で説明される実例の実施形態による伝送デバイスであってもよい。図２２０は、時間ドメイン信号を転送する方法について、ＴＳＮ ＣＮＣがＵＰＦおよび／またはｇＮＢに入力を提供する実施形態の例を示す。図２２０に示されているシナリオでは、ｇＰＴＰフレームは、ユニキャストおよび／またはマルチキャストを使用して、ＵＰＦによって、例えばＵＥなどの、受信デバイスに転送される。
５ＧＳのアップリンクのＵＥ側のグランドマスタ：グランドマスタが５ＧＳのＵＥ側に位置する場合、ＵＥは、時間情報をｇＮＢに転送しなければならない。この場合、ＵＥは、伝送デバイスであってもよく、ｇＮＢおよび／またはＵＰＦは、受信デバイスであってもよい。ＵＥは、ＴＳＮからのｇＰＴＰメッセージを受信することができ、したがって、時間認識していることになる。５ＧＳは、ＵＥから転送された時間情報が、どの時間ドメインに属すかについて認識するために、時間ドメインに関する情報を要求することができる。
ＵＥは、ユニキャストを常に使用して、５ＧネットワークにｇＰＴＰフレームを転送する。ｇＰＴＰフレームヘッダに基づいて、ネットワークは、時間ドメインを判定することができる。本明細書における１つの実施形態によれば、サブセットだけでなく全てのｇＰＴＰフレームを伝送して、ＵＥ側で他をフィルタにかける必要がないこともある。５Ｇネットワークは、例えばＵＰＦにおいて、任意の伝送されないｇＰＴＰフレームを再作成することができる。
特殊なケースによれば、データネットワークなどの外部ＴＳＮネットワークではなく、別のＵＥに時間信号を転送する必要があることもある。この場合、５ＧＳは、ダウンリンクに関する実施形態に関して上記で紹介された方法のうちの１つを使用することができ、５ＧＳが受信したフレームヘッダから時間ドメイン番号に関する情報を取得する。
本明細書における実施形態には、複数の時間ドメインとのエンドツーエンドの時刻同期を可能にするという利益がある。これにより、５ＧＳシステムは、現在、複数の時間ドメインから時間信号を効率的に転送することができる。
図２２１は、ＴＳＮからのｇＰＴＰシグナリングをハンドリングするために、例えば５Ｇシステムなどの、３ＧＰＰ無線通信システム１００における、例えば、ＵＥ１２０、ネットワークノード１１０、ＵＰＦ、および／またはトランスレータ機能などの、伝送デバイスによって実施される方法アクションを示す。
・アクション１３０１：伝送デバイスは、例えばＡｎｎｏｕｎｃｅメッセージまたは同期メッセージなどの、ｇＰＴＰフレームをＴＳＮネットワークから受信することができる。ｇＰＴＰフレームは、時間情報、時間情報に関する時間ドメインの指示、および／または、受信デバイスに接続された第２の終端局のＭＡＣアドレスを含むことができる。
・アクション１３０２：伝送デバイスは、時間ドメインの指示、および／またはＭＡＣアドレスに基づいて、ｇＰＴＰフレームが関係している受信デバイスを判定することができる。
・アクション１３０２ａ：伝送デバイスは、受信デバイスおよび／または受信デバイスに接続された１つまたは複数の第２の終端局が関連している時間ドメインに関する情報を取得することによって、ｇＰＴＰフレームが関係している受信デバイスを判定することができる。伝送デバイスは、受信デバイスから情報を受信することによって情報を取得することができる。伝送デバイスは、どの受信デバイスが特定の時間ドメインに関連しているかを示す事前設定を受信することによって情報を取得してもよい。伝送デバイスは、ＴＳＮネットワークコントローラからの情報を受信することによって、ＴＳＮ内の１つまたは複数の第２の終端局によってサポートされる時間ドメインに関する情報をさらに取得してもよく、情報は、例えばＵＥ識別子などの受信デバイス識別子、または、１つもしくは複数の第２の終端局のＭＡＣアドレスを含む。
・アクション１３０２ｂ：伝送デバイスは、受信デバイスおよび／または受信デバイスに接続された１つまたは複数の第２の終端局が関連している時間ドメインに関する取得した情報に、ｇＰＴＰフレームに含まれる時間ドメインの指示、またはＭＡＣアドレスが対応するとき、受信したｇＰＴＰフレームが受信デバイスに関連していると判定することによって、ｇＰＴＰフレームが関係している受信デバイスをさらに判定することができる。
・アクション１３０３：伝送デバイスは、ｇＰＴＰフレームを伝送デバイスで受信および／または伝送したとき、第１のタイムスタンプをｇＰＴＰフレームにさらにセットすることができ、第１のタイムスタンプは、３ＧＰＰ無線通信システム１００における様々な遅延を補償するための訂正時間を計算するために使用することができる。
・アクション１３０４：伝送デバイスは、判定した受信デバイスに関連したＰＤＵセッションにおいて、例えば、ＵＬにおける無線ネットワークノード１１０もしくはＵＰＦ、および／または、ＤＬにおけるＵＥ１２０などの、判定した受信デバイスに、ｇＰＴＰフレームを伝送することができる。伝送デバイスは、無線ネットワークノードまたはＵＰＦであってもよく、ｇＰＴＰフレームは、ブロードキャストを使用して伝送されてもよい。伝送デバイスは、マルチキャストまたはユニキャストを使用して、ｇＰＴＰフレームをさらに伝送してもよい。
図２２２は、ＴＳＮからのｇＰＴＰシグナリングをハンドリングするために、例えば５Ｇシステムなどの３ＧＰＰ無線通信システム１００における、例えば、ＵＥ１２０、無線ネットワークノード１１０、ＵＰＦ、および／またはトランスレータ機能などの、受信デバイスによって実施される方法アクションを示す。受信デバイスは、本明細書では、受信エンティティとも呼ばれることがある。
・アクション１４０１：受信デバイスは、例えば、無線ネットワークノード１１０、ＵＰＦ、および／またはＵＥ１２０などの伝送デバイスから、ｇＰＴＰフレームを含むＰＤＵセッションを受信することができ、ｇＰＴＰフレームは、時間情報、時間情報に関する時間ドメインの指示、および／または受信デバイスに接続された１つまたは複数の第２の終端局のＭＡＣアドレスを含む。ＰＤＵセッションは、マルチキャスト、ユニキャスト、またはブロードキャストを使用して受信することができる。
・アクション１４０２：受信デバイスは、時間ドメインの指示、および／またはＭＡＣアドレスに基づいて、受信したｇＰＴＰフレームを伝送することになるＴＳＮネットワーク内の１つまたは複数の第２の終端局を判定することができる。
・アクション１４０３：ブロードキャストされたメッセージとしてＰＤＵセッションを受信したとき、受信デバイスは、終端局が受信デバイスに接続されたＴＳＮネットワーク内の１つまたは複数の第２の終端局によってサポートされる時間ドメインに関する情報をさらに取得することができる。ＴＳＮ内の終端局によってサポートされる時間ドメインに関する情報は、例えば、１つまたは複数の第２の終端局によって周期的に配信される、例えばｇＰＴＰ Ａｎｎｏｕｎｃｅメッセージなどの、ｇＰＴＰメッセージを受信することによって取得することができる。ＴＳＮ内の１つまたは複数の終端局によってサポートされる時間ドメインに関する情報は、さらなる実施形態では、ＴＳＮネットワークコントローラからの情報を受信することによって取得することができ、情報は、例えばＵＥ識別子などの受信デバイス識別子、または、１つもしくは複数の第２の終端局のＭＡＣアドレスを含む。
・アクション１４０４：受信デバイスは、ｇＰＴＰフレームを含むＰＤＵセッションを受信したとき、および／またはｇＰＴＰフレームが受信デバイスによって伝送されたとき、ｇＰＴＰフレームに第２のタイムスタンプをさらにセットすることができる。第２のタイムスタンプは、３ＧＰＰ無線通信システム１００における様々な遅延を補償するための訂正時間を計算するために、ｇＰＴＰフレーム上の受信した第１のスタンプと組み合せて使用することができる。
・アクション１４０５：受信デバイスは、ＴＳＮネットワーク内の１つまたは複数の第２の終端局にｇＰＴＰフレームを伝送することができる。ｇＰＴＰフレームは、ＰＤＵセッションに含まれる時間情報および時間情報に関する時間ドメインを含む。
・アクション１４０５ａ：受信デバイスは、アクション１４０３で取得した情報に基づいて、ブロードキャストしたＰＤＵセッションが、ＴＳＮの、１つまたは複数の第２の終端局によってサポートされる時間ドメインに関するものであるとき、１つまたは複数の第２の終端局に、ブロードキャストした時間情報を伝送することができる。したがって、受信デバイスに接続されたＴＳＮの終端局によってサポートされる時間ドメインに関係ない、どのブロードキャストした時間情報も、受信デバイスによって終端局に伝送されることはない。
上記で説明した方法は、本書類における他の場所で説明されるノードの様々なものによって実行できることが理解されよう。同様に、適切なノードによって実行されるような上記の任意の組合せが可能であり、本開示によって想定される。
無線デバイス／ＵＥ
上記で説明した技法の多くは、無線デバイスまたはＵＥによって全体的または部分的に実行される。本明細書で使用されるように、用語「無線デバイス」、「ユーザ機器」、および「ＵＥ」は、特定の使用の文脈が別途明確に示さない限り区別なく使用され、ネットワーク機器および／または別の無線デバイスと無線通信することを、行う能力がある、行うように設定された、行うように配置された、および／または行うように動作可能な、デバイスを指す。本文脈では、無線通信することは、電磁気信号を使用して無線信号を伝送および／または受信することを伴う。特定の実施形態では、無線デバイスは、直接の人間の相互作用なく、情報を伝送および／または受信するように設定することができる。例えば、無線デバイスは、内部もしくは外部イベントによってトリガされたとき、または、ネットワークからのリクエストに応答して、所定のスケジュールでネットワークに情報を伝送するようにデザインすることができる。一般に、無線デバイスは、例えば無線通信デバイスといった、無線通信することを、行う能力がある、行うように設定された、行うように配置された、および／または行うように動作可能な、任意のデバイスを表すことができる。無線デバイスの例は、スマートフォンなどのユーザ機器（ＵＥ）を含むがこれに限定されない。さらなる例は、無線カメラ、無線対応タブレット型コンピュータ、ラップトップ組込型機器（ＬＥＥ）、ラップトップコンピュータマウント型機器（ＬＭＥ）、ＵＳＢドングル、および／または無線カスタマ構内設備（ＣＰＥ）を含む。
１つの具体例として、無線デバイスは、３ＧＰＰのＧＳＭ、ＵＭＴＳ、ＬＴＥ、および／または５Ｇ規格などの、第３世代パートナーシッププロジェクト（３ＧＰＰ）によって普及した１つまたは複数の通信規格に従って通信するように設定されたＵＥを表すことができる。本明細書で使用されるように、「ユーザ機器」または「ＵＥ」は、関連デバイスを所有および／または動作させる人間ユーザという意味の「ユーザ」を必ずしも含まなくてもよい。代わりに、ＵＥは、人間ユーザに販売するため、または人間ユーザによって動作させるための、しかし、特定の人間ユーザに最初に関連付けることができない、デバイスを表すことができる。以前の詳細な議論では、用語「ＵＥ」は、ＵＥが本質的に「ユーザ」に関連付けられるか否かに関わらず、５Ｇネットワークにアクセスする、および／または５Ｇネットワークによってサーブされる任意のタイプの無線デバイスを、５Ｇの背景において含めるように、さらにいっそう全体的に、便宜上使用されることも認識されたい。このように、上記の詳細な議論で使用されるような用語「ＵＥ」は、例えば、（マシンツーマシン、またはＭ２Ｍデバイスと呼ばれることもある）マシン型通信（ＭＴＣ）デバイス、および、「ユーザ」に関連付けることができるハンドセットまたは無線デバイスを含む。
無線デバイスには、例えば、サイドリンク通信のために３ＧＰＰ規格を実行することによって、Ｄ２Ｄ（ｄｅｖｉｃｅ－ｔｏ－ｄｅｖｉｃｅ）通信をサポートすることができるものもあり、この場合、Ｄ２Ｄ通信デバイスと呼ばれることがある。
さらに別の具体例として、モノのインターネット（ＩＯＴ）のシナリオでは、無線デバイスは、監視および／または測定を実施する機械または他のデバイスを表し、このような監視および／または測定の結果を、別の無線デバイスおよび／またはネットワーク機器に伝送することができる。無線デバイスは、この場合、マシンツーマシン（Ｍ２Ｍ）デバイスであってもよく、Ｍ２Ｍデバイスは、３ＧＰＰの背景では、マシン型通信（ＭＴＣ）デバイスと呼ばれることがある。１つの特定の例として、無線デバイスは、３ＧＰＰ狭帯域モノのインターネット（ＮＢ－ＩｏＴ）規格を実行するＵＥであってもよい。このような機械またはデバイスの特定の例は、センサ、電力計などの計量デバイス、産業用機械設備、または、例えば、冷蔵庫、テレビ、腕時計などの個人用ウェアラブルといった家庭用もしくは個人用アプライアンス、等である。他のシナリオでは、無線デバイスは、車両もしくは他の機器の動作ステータス、または車両もしくは他の機器の動作に関連付けられた他の機能について監視および／またはレポートを行うことができる車両または他の機器を表すことができる。
上記で説明したような無線デバイスは、無線接続のエンドポイントを表すことができ、この場合、デバイスは、無線端末と呼ばれることがある。さらに、上記で説明したような無線デバイスはモバイルであってもよく、この場合、無線デバイスは、モバイルデバイスまたはモバイル端末とさらに呼ばれることがある。
本明細書で論じられる無線デバイスの特定の実施形態は、ハードウェアおよび／またはソフトウェアの様々な適切な組合せのいずれかを含むことができることが理解されるが、本明細書で説明される無線通信ネットワークで動作するように設定された、および／または本明細書で説明される様々な技法による、無線デバイスは、特定の実施形態では、図１６６に示されている実例の無線デバイス１０００で表されてもよい。
図１６６に示されているように、実例の無線デバイス１０００は、アンテナ１００５、無線フロントエンド回路機器１０１０、および処理回路１０２０を含み、処理回路１０２０は、図示の例では、例えば１つまたは複数のメモリデバイスといった、コンピュータ可読ストレージ媒体１０２５を含む。アンテナ１００５は、１つまたは複数のアンテナまたはアンテナアレイを含むことができ、無線信号を送ることおよび／または受信することを行うように設定され、無線フロントエンド回路機器１０１０に接続される。一定の代替実施形態では、無線デバイス１０００は、アンテナ１００５を含まなくてもよく、アンテナ１００５は、代わりに、無線デバイス１０００から分離され、インターフェースまたはポートを通じて無線デバイス１０００に接続可能であってもよい。
無線フロントエンド回路機器１０１０は、例えば、様々なフィルタおよび増幅器を備えることができ、アンテナ１００５および処理回路１０２０に接続され、アンテナ１００５と処理回路１０２０との間で通信される信号を調整するように設定される。一定の代替実施形態では、無線デバイス１０００は、無線フロントエンド回路機器１０１０を含まなくてもよく、処理回路１０２０は、代わりに、無線フロントエンド回路機器１０１０のないアンテナ１００５に接続されてもよい。いくつかの実施形態では、無線周波数回路機器１０１０は、場合によっては同時に、複数の周波数帯域の信号をハンドリングするように設定される。
処理回路１０２０は、無線周波数（ＲＦ）トランシーバ回路機器１０２１、ベースバンド処理回路１０２２、およびアプリケーション処理回路１０２３の１つまたは複数を含むことができる。いくつかの実施形態では、ＲＦトランシーバ回路機器１０２１、ベースバンド処理回路１０２２、およびアプリケーション処理回路１０２３は、別々のチップセット上にあってもよい。代替実施形態では、ベースバンド処理回路１０２２およびアプリケーション処理回路１０２３の一部または全ては、１つのチップセットに統合することができ、ＲＦトランシーバ回路機器１０２１は、別々のチップセット上にあってもよい。さらなる代替実施形態では、ＲＦトランシーバ回路機器１０２１およびベースバンド処理回路１０２２の一部または全ては、同じチップセット上にあってもよく、アプリケーション処理回路１０２３は、別々のチップセット上にあってもよい。さらに他の代替実施形態では、ＲＦトランシーバ回路機器１０２１、ベースバンド処理回路１０２２、およびアプリケーション処理回路１０２３の一部または全ては、同じチップセット内に統合することができる。処理回路１０２０は、例えば、１つもしくは複数の中央処理装置（ＣＰＵ）、１つもしくは複数のマイクロプロセッサ、１つもしくは複数の特定用途向け集積回路（ＡＳＩＣ）、および／または、１つもしくは複数のフィールドプログラマブルゲートアレイ（ＦＰＧＡ）を含むことができる。
特定の実施形態では、ユーザ機器、ＭＴＣデバイス、または他の無線デバイスに関係するような本明細書で説明される機能のいくつかまたは全ては、無線デバイス内に含まれてもよく、または、代替として、図１６６に示されているような、コンピュータ可読ストレージ媒体１０２５に格納された命令を実行する処理回路１０２０によって具体化されてもよい。代替実施形態では、機能のいくつかまたは全ては、配線で接続される手法などで、コンピュータ可読媒体に格納された命令を実行することなく、処理回路１０２０によって提供することができる。これらの特定の実施形態のいずれかでは、コンピュータ可読ストレージ媒体に格納された命令を実行するか否かに関わらず、処理回路１０２０は、説明される機能を実施するように設定されると言える。このような機能によってもたらされる利益は、処理回路１０２０単独で、もしくは無線デバイスの他の構成要素に限定されず、全体として無線デバイスによって、ならびに／または、全体的にエンドユーザおよび無線ネットワークによって享受される。
処理回路１０２０は、本明細書で説明される、いずれかの判定動作を実施するように設定することができる。処理回路１０２０によって実施されるように判定することは、例えば、取得した情報を他の情報にコンバートすること、無線デバイスに格納された情報と、取得した情報もしくはコンバートした情報を比較すること、ならびに／または、取得した情報もしくはコンバートした情報に基づいて、および、判定を行う前記処理の結果として、１つもしくは複数の動作を実施することによって、処理回路１０２０によって取得された処理情報を含むことができる。
アンテナ１００５、無線フロントエンド回路機器１０１０、および／または処理回路１０２０は、本明細書で説明される、いずれかの伝送動作を実施するように設定することができる。任意の情報、データ、および／または信号は、ネットワーク機器および／または別の無線デバイスに伝送することができる。同様に、アンテナ１００５、無線フロントエンド回路機器１０１０、および／または処理回路１０２０は、無線デバイスによって実施されるような、本明細書で説明される、いずれかの受信動作を実施するように設定することができる。任意の情報、データ、および／または信号は、ネットワーク機器および／または別の無線デバイスから受信することができる。
コンピュータ可読ストレージ媒体１０２５は、一般に、ロジック、ルール、コード、テーブル、等の１つもしくは複数を含む、コンピュータプログラム、ソフトウェア、アプリケーションなどの命令、および／または、プロセッサで実行することができる他の命令を格納するように動作可能である。コンピュータ可読ストレージ媒体１０２５の例は、コンピュータメモリ（例えば、ランダムアクセスメモリ（ＲＡＭ）もしくはリードオンリメモリ（ＲＯＭ））、マスストレージ媒体（例えば、ハードディスク）、取外し可能ストレージ媒体（例えば、コンパクトディスク（ＣＤ）もしくはデジタルビデオディスク（ＤＶＤ））、ならびに／または、処理回路１０２０で使用することができる情報、データ、および／もしくは命令を格納する他の任意の揮発性もしくは不揮発性の非一時的コンピュータ可読および／もしくはコンピュータ実行可能メモリデバイスを含む。いくつかの実施形態では、処理回路１０２０およびコンピュータ可読ストレージ媒体１０２５は、統合されたものとみなされてもよい。
無線デバイス１０００の代替実施形態は、本明細書で説明される機能のいずれか、および／または、上記で説明したソリューションをサポートするのに必要ないずれかの機能を含む、無線デバイスの機能の一定の態様の提供を担うことができる、図１６６に示されているもの以外の追加の構成要素を含むことができる。ほんの１つの例として、無線デバイス１０００は、入力インターフェース、デバイス、および回路、ならびに出力インターフェース、デバイス、および回路を含むことができる。入力インターフェース、デバイス、および回路は、無線デバイス１０００に情報を入力できるように設定され、処理回路１０２０が入力情報を処理できるように処理回路１０２０に接続される。例えば、入力インターフェース、デバイス、および回路は、マイクロフォン、近接もしくは他のセンサ、キー／ボタン、タッチディスプレイ、１つもしくは複数のカメラ、ＵＳＢポート、または他の入力要素を含むことができる。出力インターフェース、デバイス、および回路は、無線デバイス１０００から情報を出力できるように設定され、処理回路１０２０が無線デバイス１０００から情報を出力できるように処理回路１０２０に接続される。例えば、出力インターフェース、デバイス、または回路は、スピーカ、ディスプレイ、振動回路機器、ＵＳＢポート、ヘッドホンインターフェース、または他の出力要素を含むことができる。１つまたは複数の入力および出力インターフェース、デバイス、および回路を使用して、無線デバイス１０００は、エンドユーザおよび／または無線ネットワークと通信し、エンドユーザおよび／または無線ネットワークが、本明細書で説明される機能から利益を得ることを可能にすることができる。
別の例として、無線デバイス１０００は、電力供給源回路機器１０３０を含むことができる。電力供給源回路機器１０３０は、電力管理回路機器を備えることができる。電力供給源回路機器は、電源から電力を受け取ることができ、電源は、電力供給源回路機器１０３０に含まれるか、外部にあってもよい。例えば、無線デバイス１０００は、電力供給源回路機器１０３０に接続された、または統合された、バッテリまたはバッテリパックの形の電源を備えることができる。光起電デバイスなどの他のタイプの電源も使用することができる。さらなる例として、無線デバイス１０００は、電気ケーブルなどの入力回路機器またはインターフェースを介して、（電気コンセントなどの）外部電源に接続可能であってもよく、これにより、外部電源は、電力供給源回路機器１０３０に電力を供給する。
電力供給源回路機器１０３０は、無線フロントエンド回路機器１０１０、処理回路１０２０、および／またはコンピュータ可読ストレージ媒体１０２５に接続し、本明細書で説明される機能を実施するための電力を、処理回路１０２０を含む無線デバイス１０００に供給するように設定することができる。
無線デバイス１０００も、例えば、ＧＳＭ、ＷＣＤＭＡ、ＬＴＥ、ＮＲ、ＷｉＦｉ、もしくはＢｌｕｅｔｏｏｔｈ無線技術など、無線デバイス１０００に統合された種々の無線技術のための、処理回路１０２０、コンピュータ可読ストレージ媒体１０２５、無線回路機器１０１０、および／または、アンテナ１００５の複数のセットを含むことができる。これらの無線技術は、無線デバイス１０００内の、同じまたは異なるチップセット、および他の構成要素に統合されてもよい。
無線デバイス１０００は、様々な実施形態では、本明細書で説明される特徴および技法の様々な組合せのいずれかを行うように適合される。いくつかの非限定的な例を下記で説明する。
第１の例では、無線デバイスは、無線通信ネットワークと通信するように設定されたトランシーバ回路機器、および、トランシーバ回路機器に動作可能なように連結された処理回路を備える。処理回路は、トランシーバ回路機器を制御すること、ならびに、無線アクセスネットワーク（ＲＡＮ）の無線基地局（ＲＢＳ）からシステム情報（ＳＩ）を受信することであって、ＳＩが、ＲＢＳを通じたタイムセンシティブネットワーキング（ＴＳＮ）のサポートを示す性質をもつ、受信すること、外部ＴＳＮデータネットワークとの少なくとも１つのＴＳＮストリームを、ＲＢＳを通じて確立すること、および、無線通信ネットワークからの第１のタイミング信号を、ＲＢＳを介して受信すること、を行うように（例えば、メモリに格納されたプログラムコードを使用して）設定される。処理回路は、無線デバイスが接続された外部ＴＳＮデータネットワークから第２のタイミング信号を受信すること、第１のタイミング信号を第２のタイミング信号と比較してオフセットを判定すること、および、無線通信ネットワークにオフセットを伝送すること、を行うようにさらに設定される。この無線デバイスの実施形態に対応する方法について上記で説明した変形形態の全ては、様々な実施形態において、この実例の無線デバイスに適用することができ、この無線デバイスの実施形態は、本明細書で説明される追加の技法を行うように設定することができる。
無線通信ネットワークにおいて使用するように設定された別の実例の無線デバイスは、同様に、無線通信ネットワークと通信するように設定されたトランシーバ回路機器、および、トランシーバ回路機器に動作可能なように連結され、トランシーバ回路機器を制御するように設定された処理回路を備える。この実例の無線デバイスでの処理回路は、ＲＡＮのＲＢＳからＳＩを受信することであって、ＳＩが、ＲＢＳを通じたＴＳＮのサポートを示す性質をもつ、受信すること、外部データネットワークとの少なくとも１つのＴＳＮストリームを、ＲＢＳを通じて確立すること、および、ＴＳＮストリームについての設定情報を取得することであって、設定情報が、静的なままであるべきＴＳＮストリームに関連付けられたデータパケットのヘッダ内の１つまたは複数のフィールドのそれぞれの値を示す、取得すること、を行うようにさらに設定される。処理回路は、ＴＳＮストリームに関連付けられたデータパケットをＲＢＳから受信すること、および、１つまたは複数のフィールドをデータパケットに追加して、解凍したデータパケットを生成すること、を行うようにさらに設定される。再び、この無線デバイスの実施形態に対応する方法について上記で説明した変形形態の全ては、様々な実施形態において、この実例の無線デバイスに適用することができ、この無線デバイスの実施形態は、本明細書で説明される追加の技法を行うように設定することができる。
ＲＡＮと通信するように設定された別の実例の無線デバイスも、無線通信ネットワークと通信するように設定されたトランシーバ回路機器、および、トランシーバ回路機器に動作可能なように連結され、トランシーバ回路機器を制御するように設定された処理回路を備える。この例での処理回路は、ＲＡＮのＲＢＳからＳＩを受信することであって、ＳＩが、ＲＢＳを通じたＴＳＮのサポートを示す性質をもつ、受信すること、外部データネットワークとの少なくとも１つのＴＳＮストリームを、ＲＢＳを通じて確立すること、および、ＴＳＮストリームに関連付けられた伝送スケジュールを外部ネットワークから受信すること、を行うように設定される。無線デバイスは、無線デバイスとＲＡＮとの間のＴＳＮストリームの通信のための無線リソースを配分するために、ＲＢＳに関連付けられたネットワークにリクエストを送ることであって、リクエストが、伝送スケジュールに関する情報をさらに備える、送ること、および、ＴＳＮストリームに関連付けられた伝送スケジュールを満たすために、無線リソースを配分できるかどうかを示す応答をネットワークから受信すること、を行うようにさらに設定される。もう一度、この無線デバイスの実施形態に対応する方法について上記で説明した変形形態の全ては、様々な実施形態において、この実例の無線デバイスに適用することができ、この無線デバイスの実施形態は、本明細書で説明される追加の技法を行うように設定することができる。
無線通信ネットワークで使用するように設定されたさらに別の実例の無線デバイスは、無線通信ネットワークと通信するように設定されたトランシーバ回路機器、および、トランシーバ回路機器に動作可能なように連結され、トランシーバ回路機器を制御するように設定された処理回路を備える。処理回路は、ＲＡＮのＲＢＳからＳＩを受信することであって、ＳＩが、ＲＢＳを通じたＴＳＮのサポートを示す性質をもつ、受信すること、外部ＴＳＮデータネットワークとの少なくとも１つのＴＳＮストリームを、ＲＢＳを通じて確立すること、無線通信ネットワークへのアップリンク送信に使用するためのアップリンクリソースを示す周期的なアップリンクグラントを設定する設定情報を受信すること、および、無線通信ネットワークへのアップリンク送信のための動的なアップリンクグラントを受信すること、を行うように設定される。処理回路は、論理チャネル優先順位付け手順に従って、設定した周期的なアップリンクグラント上で伝送されることになるアップリンクデータがある場合、動的なアップリンクグラントを使用したアップリンク送信で、設定した周期的なアップリンクグラントを使用してアップリンク送信を優先させるようにさらに設定される。再び、この無線デバイスの実施形態に対応する方法について上記で説明した変形形態の全ては、様々な実施形態において、この実例の無線デバイスに適用することができ、この無線デバイスの実施形態は、本明細書で説明される追加の技法を行うように設定することができる。
他の例は、モノのインターネット（ＩｏＴ）環境への第２のデバイスのエンロールメントを支援するように設定された第１のデバイスを含み、第１のデバイスは、第２のデバイスと通信するように設定されたトランシーバ回路機器、および、トランシーバ回路機器に動作可能なように連結され、トランシーバ回路機器を制御するように設定された処理回路を備える。処理回路は、第２のデバイスに関連付けられたエンロールメント機能の表現を取得することであって、エンロールメント機能が、第１および第２のデバイスに関連付けられたエンロールメント情報を含む少なくとも１つのシリアライズされたエンロールメントアプリケーションに関連付けられる、取得すること、第１のデバイスに関連付けられたエンロールメント情報が、第２のデバイスに関連付けられたエンロールメント情報から分離されるように、エンロールメントアプリケーションをデシリアライズすること、ならびに、第２のデバイスに関連付けられたエンロールメント情報に基づいて第２のデバイスを設定することによって、第２のデバイスのエンロールメント処理の第２のデバイスによる実行を始めるために、第２のデバイスに関連付けられたエンロールメント情報を第２のデバイスに伝送すること、を行うように設定される。処理回路は、第２のデバイスに関連付けられた設定情報を第２のデバイスから受信すること、第１のデバイス上で実行する第１のランタイム環境を使用して、第２のデバイス上で実行する第２のランタイム環境にコードモジュールを転送することであって、コードモジュールが、第２のランタイム環境内で実行し、第２のランタイム環境によってサポートされる第２のデバイスの機能を第１のデバイスに露出するように設定される、転送すること、ならびに、第１のランタイム環境内のアプリケーションを実行することであって、アプリケーションが、転送されたコードモジュールおよび第２のランタイム環境を介して第２のデバイスの機能をリモートに起動する、実行すること、を行うようにさらに設定される。もう一度、この無線デバイスの実施形態に対応する方法について上記で説明した変形形態の全ては、様々な実施形態において、この実例の無線デバイスに適用することができ、この無線デバイスの実施形態は、本明細書で説明される追加の技法を行うように設定することができる。
さらに別の例は、第１のデバイスによって支援されるＩｏＴ環境へのエンロールメント処理を実行するように設定された対応する第２のデバイスであり、第２のデバイスは、第１のデバイスと通信するように設定されたトランシーバ回路機器、および、トランシーバ回路機器に動作可能なように連結され、トランシーバ回路機器を制御するように設定された処理回路を備える。この第２のデバイスにおける処理回路は、第２のデバイスに関連付けられたエンロールメント情報を第１のデバイスから受信すること、エンロールメント情報に基づいて第２のデバイスを設定することによってエンロールメント処理を実行すること、および、第２のデバイスに関連付けられた設定情報を第１のデバイスに伝送すること、を行うように設定される。処理回路は、第２のランタイム環境によってサポートされる第２のデバイスの機能を第１のデバイスに露出するために、第２のデバイス上で実行する第２のランタイム環境への、第１のデバイス上で実行する第１のランタイム環境からのコードモジュールを受信すること、および、第１のランタイム環境内で実行するアプリケーションからのコードモジュールを介して受信した機能のリモート起動に応答して、第２のランタイム環境を使用して、第２のデバイスの機能の実施を制御すること、を行うようにさらに設定される。さらに再び、この無線デバイスの実施形態に対応する方法について上記で説明した変形形態の全ては、様々な実施形態において、この実例の無線デバイスに適用することができ、この無線デバイスの実施形態は、本明細書で説明される追加の技法を行うように設定することができる。
ネットワーク機器および方法
本明細書で使用されるように、用語「ネットワーク機器」または「ネットワークノード」は、無線デバイスへの無線アクセスを可能にする、および／または提供する、無線通信ネットワーク内の無線デバイスと、および／または他の機器と、直接的または間接的に通信することを、行う能力がある、行うように設定された、行うように配置された、および／または行うように動作可能な、機器を指す。ネットワーク機器の例は、アクセスポイント（ＡＰ）、特に、無線アクセスポイントを含むがこれに限定されない。ネットワーク機器は、無線基地局などの基地局（ＢＳ）を表すことができる。無線基地局の特定の例は、ノードＢ、およびエボルブドノードＢ（ｅＮＢ）を含む。基地局は、基地局が提供するカバレッジの量（または、別の言い方をすれば、基地局の伝送出力レベル）に基づいてカテゴライズすることができ、したがって、フェムト基地局、ピコ基地局、マイクロ基地局、またはマクロ基地局と呼ばれることもある。「ネットワーク機器」は、リモート無線ヘッド（ＲＲＨ：Ｒｅｍｏｔｅ Ｒａｄｉｏ Ｈｅａｄ）と呼ばれることもある、集中型デジタルユニットおよび／またはリモートラジオユニット（ＲＲＵ：ｒｅｍｏｔｅ ｒａｄｉｏ ｕｎｉｔ）などの分散型無線基地局の１つまたは複数（または全て）の部分も含む。このようなリモートラジオユニットは、アンテナ統合型無線のように、アンテナと統合されても、されなくてもよい。分散型無線基地局の一部も、分散アンテナシステム（ＤＡＳ）におけるノードと呼ばれることがある。
特定の非限定的な例として、基地局は、中継を制御する中継ノードまたは中継ドナーノードであってもよい。
ネットワーク機器のさらなる例は、ＭＳＲ ＢＳなどのマルチスタンダード無線機（ＭＳＲ）無線機器、無線ネットワークコントローラ（ＲＮＣ）もしくは基地局コントローラ（ＢＳＣ）などのネットワークコントローラ、ベーストランシーバ基地局（ＢＴＳ）、伝送ポイント、伝送ノード、マルチセル／マルチキャスト協調エンティティ（ＭＣＥ）、コアネットワークノード（例えば、ＭＳＣ、ＭＭＥ）、Ｏ＆Ｍノード、ＯＳＳノード、ＳＯＮノード、ポジショニングノード（例えば、Ｅ－ＳＭＬＣ）、および／またはＭＤＴを含む。より一般には、それでも、ネットワーク機器は、無線通信ネットワークへの無線デバイスアクセスを可能にすること、および／もしくは提供すること、または、無線通信ネットワークにアクセスした無線デバイスにいくつかのサービスを提供することを、行う能力がある、行うように設定された、行うように配置された、および／または行うように動作可能な、任意の適切なデバイス（またはデバイスのグループ）を表すことができる。
本明細書で使用されるように、用語「無線ネットワーク機器」は、無線能力を含むネットワーク機器を指すために使用される。このように、無線ネットワーク機器の例は、上記で論じられた、無線基地局および無線アクセスポイントである。いくつかの無線ネットワーク機器は、上記で論じられた（ＲＲＨおよび／またはＲＲＵを伴う）分散型無線基地局などの、分散された機器を備えることができることが理解されよう。ｅＮＢ、ｅＮｏｄｅＢ、ノードＢなどへの本明細書における様々な言及は、無線ネットワーク機器の例に言及しているものと理解されよう。本明細書で使用されるような用語「無線ネットワーク機器」は、場合によっては、単一の基地局もしくは単一の無線ノード、または、例えば異なる位置にある複数の基地局もしくはノードを指すことができることも理解されたい。場合によっては、本ドキュメントは、無線機器の複数の別個の実施形態または設備が含まれる一定のシナリオを、より明確に説明するために、無線ネットワーク機器の「インスタンス」を指すことができる。それでも、無線ネットワーク機器の議論に関して「インスタンス」への言及がなくても、単一のインスタンスにしか言及していないことを意味するものとみなされるべきではない。無線ネットワーク機器の所与のインスタンスは、代替として、「無線ネットワークノード」と呼ばれることがあり、ここで、単語「ノード」の使用は、ネットワーク内の論理ノードとして機器が動作するものと言及されたことを示すが、全ての構成要素が必ず同じ場所に位置することを意味するものではない。
無線ネットワーク機器は、ハードウェアおよび／またはソフトウェアの任意の適切な組合せを含むことができるが、無線ネットワーク機器１１００のインスタンスの例は、図１６７によって、より詳細に示されている。図１６７に示されているように、実例の無線ネットワーク機器１１００は、アンテナ１１０５、無線フロントエンド回路機器１１１０、および処理回路１１２０を含み、処理回路１１２０は、図示の例では、例えば１つまたは複数のメモリデバイスといった、コンピュータ可読ストレージ媒体１０２５を含む。アンテナ１１０５は、１つまたは複数のアンテナまたはアンテナアレイを含むことができ、無線信号を送ること、および／または受信することを行うように設定され、無線フロントエンド回路機器１１１０に接続される。一定の代替実施形態では、無線ネットワーク機器１１００は、アンテナ１００５を含まなくてもよく、アンテナ１００５は、代わりに、無線ネットワーク機器１１００とは分離していて、インターフェースまたはポートを通じて無線ネットワーク機器１１００に接続可能であってもよい。いくつかの実施形態では、無線フロントエンド回路機器１１１０の全てまたは一部は、例えばＲＲＨまたはＲＲＵ内など、処理回路１１２０から離れた１つまたはいくつかの位置に位置してもよい。同様に、処理回路１１２０の一部は、互いに物理的に分離されてもよい。無線ネットワーク機器１１００は、例えば、コアネットワーク内の他の無線ネットワーク機器と、およびノードと、など、他のネットワークノードと通信するための通信インターフェース回路機器１１４０も含むことができる。
無線フロントエンド回路機器１１１０は、例えば様々なフィルタおよび増幅器を備えることができ、アンテナ１１０５および処理回路１１２０に接続され、アンテナ１１０５と処理回路１１２０との間で通信される信号を調整するように設定される。一定の代替実施形態では、無線ネットワーク機器１１００は、無線フロントエンド回路機器１１１０を含まなくてもよく、代わりに、無線フロントエンド回路機器１１１０のない処理回路１１２０がアンテナ１１０５に接続されてもよい。いくつかの実施形態では、無線周波数回路機器１１１０は、複数の周波数帯域の信号を、場合によっては同時にハンドリングするように設定される。
処理回路１１２０は、ＲＦトランシーバ回路機器１１２１、ベースバンド処理回路１１２２、およびアプリケーション処理回路１１２３の１つまたは複数を含むことができる。いくつかの実施形態では、ＲＦトランシーバ回路機器１１２１、ベースバンド処理回路１１２２、およびアプリケーション処理回路１１２３は、別々のチップセット上にあってもよい。代替実施形態では、ベースバンド処理回路１１２２およびアプリケーション処理回路１１２３の一部または全てを、１つのチップセットに組み合わせることができ、ＲＦトランシーバ回路機器１１２１は、分離したチップセット上にあってもよい。さらなる代替実施形態では、ＲＦトランシーバ回路機器１１２１およびベースバンド処理回路１１２２の一部または全てが、同じチップセット上にあってもよく、アプリケーション処理回路１１２３は、分離したチップセット上にあってもよい。さらなる他の代替実施形態では、ＲＦトランシーバ回路機器１１２１、ベースバンド処理回路１１２２、およびアプリケーション処理回路１１２３の一部または全てを、同じチップセットに組み合わせることができる。処理回路１１２０は、例えば、１つもしくは複数の中央ＣＰＵ、１つもしくは複数のマイクロプロセッサ、１つもしくは複数のＡＳＩＣ、および／または、１つもしくは複数のフィールドＦＰＧＡを含むことができる。
特定の実施形態では、無線ネットワーク機器、無線基地局、ｅＮＢ、ｇＮＢ等に関するもののような、本明細書で説明される機能のいくつかまたは全ては、無線ネットワーク機器に含まれてもよく、または、代替として、図１８３に示されているような、コンピュータ可読ストレージ媒体１１２５に格納された命令を実行する処理回路１１２０によって具体化されてもよい。代替実施形態では、機能のいくつかまたは全ては、配線で接続された手法などで、コンピュータ可読媒体に格納された命令を実行することなく、処理回路１１２０によって提供することができる。これらの特定の実施形態のいずれかでは、コンピュータ可読ストレージ媒体に格納された命令を実行するか否かに関わらず、処理回路は、説明される機能を実施するように設定されると言える。このような機能によってもたらされる利益は、処理回路１１２０単独で、もしくは無線ネットワーク機器の他の構成要素に限定されないが、無線ネットワーク機器１１００によって全体として、ならびに／またはエンドユーザおよび無線ネットワークによって全体的に享受される。
処理回路１１２０は、本明細書で説明されるいずれかの判定動作を実施するように設定することができる。処理回路１１２０によって実施されるような判定は、例えば、取得した情報を他の情報にコンバートすること、無線ネットワーク機器に格納された情報と、取得した情報もしくはコンバートした情報を比較すること、および／または、取得した情報もしくはコンバートした情報に基づいて、および、前記処理が判定を行った結果として、１つもしくは複数の動作を実施すること、によって、処理回路１１２０によって取得された処理情報を含むことができる。
アンテナ１１０５、無線フロントエンド回路機器１１１０、および／または処理回路１１２０は、本明細書で説明されるいずれかの伝送動作を実施するように設定することができる。任意の情報、データ、および／または信号は、任意のネットワーク機器および／または無線デバイスに伝送することができる。同様に、アンテナ１１０５、無線フロントエンド回路機器１１１０、および／または処理回路１１２０は、無線ネットワーク機器によって実施されるような、本明細書で説明されるいずれかの受信動作を実施するように設定することができる。任意の情報、データ、および／または信号は、任意のネットワーク機器および／または無線デバイスから受信することができる。
コンピュータ可読ストレージ媒体１１２５は、一般に、ロジック、ルール、コード、テーブル等の１つもしくは複数を含むコンピュータプログラム、ソフトウェア、アプリケーションなどの命令、および／または、プロセッサが実行できる他の命令を格納するように動作可能である。コンピュータ可読ストレージ媒体１１２５の例は、コンピュータメモリ（例えば、ＲＡＭもしくはＲＯＭ）、マスストレージ媒体（例えば、ハードディスク）、取外し可能ストレージ媒体（例えば、ＣＤもしくはＤＶＤ）、ならびに／または、処理回路１１２０が使用できる情報、データ、および／もしくは命令を格納する他の任意の揮発性もしくは不揮発性の非一時的コンピュータ可読および／もしくはコンピュータ実行可能メモリデバイスを含む。いくつかの実施形態では、処理回路１１２０およびコンピュータ可読ストレージ媒体１１２５は、統合されたものとみなされてもよい。
無線ネットワーク機器１１００の代替実施形態は、本明細書で説明される機能のいずれか、および／または、上記で説明したソリューションをサポートするのに必要ないずれかの機能を含む、無線ネットワーク機器の機能の一定の態様を提供することを担うことができる図１６７に示したもの以上の追加の構成要素を含むことができる。ただ１つの例として、無線ネットワーク機器１１００は、入力インターフェース、デバイス、および回路、ならびに、出力インターフェース、デバイス、および回路を含むことができる。入力インターフェース、デバイス、および回路は、無線ネットワーク機器１１００に情報を入力できるように設定され、処理回路１１２０が入力情報を処理できるように処理回路１１２０に接続される。例えば、入力インターフェース、デバイス、および回路は、マイクロフォン、近接もしくは他のセンサ、キー／ボタン、タッチディスプレイ、１つもしくは複数のカメラ、ＵＳＢポート、または他の入力要素を含むことができる。出力インターフェース、デバイス、および回路は、無線ネットワーク機器１１００から情報を出力できるように設定され、処理回路１１２０が無線ネットワーク機器１１００からの情報を出力できるように処理回路１１２０に接続される。例えば、出力インターフェース、デバイス、または回路は、スピーカ、ディスプレイ、ＵＳＢポート、ヘッドホンインターフェース、または他の出力要素を含むことができる。１つまたは複数の入力および出力インターフェース、デバイス、および回路を使用して、無線ネットワーク機器１１００は、エンドユーザおよび／または無線ネットワークと通信すること、ならびに、エンドユーザおよび／または無線ネットワークが本明細書で説明される機能から利益を得られるようにすることができる。
別の例として、無線ネットワーク機器１１００は、電力供給源回路機器１１３０を含むことができる。電力供給源回路機器１１３０は、電力管理回路機器を備えることができる。電力供給源回路機器１１３０は、電源から電力を受け取ることができ、電源は、電力供給源回路機器１１３０に含まれても、または外部にあってもよい。例えば、無線ネットワーク機器１１００は、電力供給源回路機器１１３０に接続された、または統合された、バッテリまたはバッテリパックの形の電源を備えることができる。光起電デバイスなどの他のタイプの電源も使用することができる。さらなる例として、無線ネットワーク機器１１００は、外部電源が電力供給源回路機器１１３０に電力を供給する、電気ケーブルなどの入力回路機器またはインターフェースを介して、（電気コンセントなどの）外部電源に接続可能であってもよい。
電力供給源回路機器１１３０は、無線フロントエンド回路機器１１１０、処理回路１１２０、および／またはコンピュータ可読ストレージ媒体１１２５に接続することができ、本明細書で説明される機能を実施するための電力を、処理回路１１２０を含む無線ネットワーク機器１１００に供給するように設定されてもよい。
無線ネットワーク機器１１００は、例えば、ＧＳＭ、ＷＣＤＭＡ、ＬＴＥ、ＮＲ、ＷｉＦｉ、またはＢｌｕｅｔｏｏｔｈ無線技術などの、無線ネットワーク機器１１００に統合された種々の無線技術のための、処理回路１１２０、コンピュータ可読ストレージ媒体１１２５、無線回路機器１１１０、アンテナ１１０５、および／または通信インターフェース回路機器１１４０の複数のセットも含むことができる。これらの無線技術は、無線ネットワーク機器１１００内の、同じまたは異なるチップセット、および他の構成要素に統合されてもよい。
無線ネットワーク機器１１００の１つまたは複数のインスタンスは、無線基地局、ｇＮＢ、または同様のものによって行われるような、本明細書で説明される方法および技法を含む、様々な組合せのいずれかで、本明細書で説明される技法のいくつかまたは全てを実行するように適合させることができる。所与のネットワークの実装形態では、無線ネットワーク機器１１００の複数のインスタンスが使用中であることが理解されよう。場合によっては、無線ネットワーク機器１１００のいくつかのインスタンスが同時に、所与の無線デバイス、または無線デバイスのグループと通信していても、所与の無線デバイス、または無線デバイスのグループに信号を伝送していてもよい。したがって、無線ネットワーク機器１１００の単一のインスタンスによって、本明細書で説明される技法の多くを実行することができるが、これらの技法は、場合によっては協調して、無線ネットワーク機器１１００の１つまたは複数のインスタンスのシステムによって実行されるものと理解できることを理解されたい。図１６７に示されている無線ネットワーク機器１１００は、したがって、このシステムの最も単純な例である。
本明細書で説明されるネットワーク機器またはネットワークノードの他のものは、１つまたは複数の無線デバイスと通信するための無線トランシーバを欠いているという点で無線ネットワーク機器ではないが、代わりに、典型的には標準インターフェースを介して、通信システム内の１つまたは複数の他のネットワークノードと通信するように設定される。これらの他のネットワークノードは、図１６７に示されている実例の無線ネットワーク機器１１００に示されている同じ特徴の多くを備えるものと理解することができるが、無線機能はない。これらの他のネットワークノードの１つまたは組合せは、処理回路による実行のために、例えば、コンピュータ可読媒体に格納された適切なプログラムコードで、本明細書で説明される方法および技法の多くを実行するように設定することができる。
上記で説明したもののようなネットワークノードは、本明細書で説明された方法の１つまたはいくつかを実行するように設定することができる。１つの非限定的な例では、ユーザ機器ＵＥおよび外部ネットワークに関連付けられたタイムセンシティブデータストリームをハンドリングするために、ＲＡＮに関連付けられたコアネットワークで使用するように設定されたネットワークノードは、１つまたは複数の他のネットワークノードと通信するように設定された通信インターフェース回路機器、および、通信インターフェース回路機器に動作可能なように連結された処理回路を備える。処理回路は、タイムセンシティブデータストリームに関連付けられた伝送スケジュールを外部ネットワークから受信すること、ＲＡＮと第１のＵＥとの間のデータストリームの通信のための無線リソースを配分するというリクエストをＲＡＮに送ることであって、リクエストが、伝送スケジュールに関する情報をさらに含む、送ること、および、データストリームに関連付けられた伝送スケジュールを満たすために、無線リソースを配分できるかどうかについて示す応答をＲＡＮから受信すること、を行うように設定される。処理回路は、データストリームについての設定情報を取得することであって、設定情報が、静的なまま存続することになるデータストリームに関連付けられたデータパケットのヘッダ内の１つまたは複数のフィールドのそれぞれの値を示す、取得すること、第１のＵＥへの設定情報の伝送を始めること、データストリームに関連付けられたデータパケットを外部データネットワークから受信すること、１つまたは複数のフィールドをデータパケットから除去して圧縮データパケットを生成すること、および、第１のＵＥへの圧縮データパケットの伝送を始めること、を行うようにさらに設定される。このネットワークノードの実施形態に対応する方法について上記で説明した変形形態の全てを、様々な実施形態における、この実例のネットワークノードに適用することができ、このネットワークノードの実施形態は、本明細書で説明される追加の技法を実行するように設定することができる。
本明細書で開示されるいずれかの適切なステップ、方法、特徴、機能、または利益は、１つまたは複数の仮想装置の１つまたは複数の機能ユニットまたはモジュールを通じて実施することができる。各仮想装置は、いくつかのこれらの機能ユニットを備えることができる。これらの機能ユニットは、１つまたは複数のマイクロプロセッサまたはマイクロコントローラを含むことができる処理回路、および、デジタル信号プロセッサ（ＤＳＰ）、専用デジタルロジックなどを含むことができる他のデジタルハードウェア、を介して実行することができる。処理回路は、メモリに格納されたプログラムコードを実行するように設定することができ、メモリは、リードオンリメモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、キャッシュメモリ、フラッシュメモリデバイス、光ストレージデバイス等など、１つまたはいくつかのタイプのメモリを含むことができる。メモリに格納されたプログラムコードは、本明細書で説明される技法の１つまたは複数を実行するための命令だけでなく、１つまたは複数のテレコミュニケーションおよび／またはデータ通信プロトコルを実行するためのプログラム命令も含む。いくつかの実装形態では、処理回路は、本開示の１つまたは複数の実施形態による対応する機能を、それぞれの機能ユニットに実施させるために使用されてもよい。
ホストコンピュータを備えるネットワークへの本開示の技法の応用
上記で提供された詳細な議論および例では、例えば、無線デバイス、無線アクセスネットワーク、または無線テレコミュニケーションコアネットワークノードで実行される動作について、いくつかの技法が説明されてきた。それでも、これらの無線ネットワーク構成要素を包含するがこれに限定されない通信システムのより広い背景でこれらの技法が実行されるものと理解されてもよいことが認識されよう。したがって、この通信システムは、固定（有線）ネットワーク、アプリケーションサーバ、サーバファーム、無線ネットワークに関するサービスにアクセスするユーザコンピュータ等をさらに含むことができる。同様に、本明細書で説明される技法は、無線ネットワーク自体を超えるサービスおよび／またはアプリケーションを含むか、サービスおよび／またはアプリケーションで利用することができる。必然的に、改善されたレイテンシ、信頼性、セキュリティ等などの、開示の技法の多くについて本明細書で説明される長所は、これらのサービスおよび／またはアプリケーションに生ずることがある。
図２２３は、いくつかの実施形態によれば、無線アクセスネットワークなどのアクセスネットワーク６１１、およびコアネットワーク６１４、を含む３ＧＰＰタイプのセルラネットワークなどの、通信ネットワーク６１０を含む通信システムを示す。アクセスネットワーク６１１は、対応するカバレッジエリア６１３ａ、６１３ｂ、６１３ｃをそれぞれが規定する、ＮＢ、ｅＮＢ、ｇＮＢ、または他のタイプの無線アクセスポイントなどの複数の基地局８６ａ、６１２ｂ、６１２ｃを備える。各基地局６１２ａ、６１２ｂ、６１２ｃは、有線または無線接続６１５でコアネットワーク６１４に接続することができる。カバレッジエリア６１３ｃ内に位置する第１のユーザ機器（ＵＥ）６９１は、対応する基地局６６ｃに無線接続するように、または、対応する基地局６６ｃによってページされるように設定される。カバレッジエリア６１３ａ内の第２のＵＥ６９２は、対応する基地局６１２ａに無線接続することができる。この例では、複数のＵＥ６９１、６９２が示されているが、本開示の実施形態は、カバレッジエリア内に唯一のＵＥがあるか、対応する基地局６１２に唯一のＵＥが接続している状況に等しく適用可能である。
通信ネットワーク６１０は、それ自体がホストコンピュータ６３０に接続され、ホストコンピュータ６３０は、スタンドアロンサーバ、クラウド実行型サーバ、分散型サーバの、または、サーバファーム内の処理リソースとして、ハードウェアおよび／またはソフトウェアで具体化することができる。ホストコンピュータ６３０は、サービスプロバイダの所有権もしくは制御権の下にあってもよく、または、サービスプロバイダによって、もしくはサービスプロバイダのために動作させることができる。通信ネットワーク６１０とホストコンピュータ６３０の間の接続６２１、６２２は、コアネットワーク６１４からホストコンピュータ６３０に直接延ばすことができ、または、任意選択の中間ネットワーク６２０を介して行うことができる。中間ネットワーク６２０は、パブリック、プライベート、またはホストされるネットワークの１つ、または２つ以上の組合せであってもよく、中間ネットワーク６２０は、もしあれば、バックボーンネットワークまたはインターネットであってもよく、具体的には、中間ネットワーク６２０は、２つ以上のサブネットワークを備えることができる（図示せず）。
図２２３の通信システムは、全体として、接続されたＵＥ６９１、６９２の１つと、ホストコンピュータ６３０との間の接続を可能にする。接続は、オーバザトップ（ＯＴＴ：ｏｖｅｒ－ｔｈｅ－ｔｏｐ）接続６５０として説明することができる。ホストコンピュータ６３０および接続されたＵＥ６９１、６９２は、アクセスネットワーク６１１、コアネットワーク６１４、任意の中間ネットワーク６２０、および可能なさらなるインフラストラクチャ（図示せず）を中間体として使用して、ＯＴＴ接続６５０を介してデータおよび／またはシグナリングを通信するように設定される。ＯＴＴ接続６５０は、ＯＴＴ接続６５０が通る、関与する通信デバイスが、アップリンクおよびダウンリンク通信のルーティングを意識しないという意味では透過的であってもよい。例えば、基地局６１２は、接続されたＵＥ６９１に転送される（例えば、ハンドオーバされる）ことになるホストコンピュータ６３０から生じるデータとの、入ってくるダウンリンク通信の過去のルーティングについて知らされなくてもよいか、知らされる必要がない。同様に、基地局６１２は、ホストコンピュータ６３０の方へＵＥ６９１から生じる、出て行くアップリンク通信の将来のルーティングについて認識している必要はない。
前の段落で論じられた、ＵＥ、基地局、およびホストコンピュータの、１つの実施形態による実例の実装形態を、図２２４を参照しながらここで説明する。通信システム７００では、ホストコンピュータ７１０は、通信システム７００の異なる通信デバイスのインターフェースとの有線または無線接続をセットアップし、維持するように設定された通信インターフェース７１６を含むハードウェア７１５を備える。ホストコンピュータ７１０は、処理回路７１８をさらに備え、処理回路７１８は、ストレージおよび／または処理能力を保持することができる。具体的には、処理回路７１８は、命令を実行するように適合された、１つもしくは複数のプログラム可能プロセッサ、特定用途向け集積回路、フィールドプログラマブルゲートアレイ、またはこれらの組合せ（図示せず）を備えることができる。ホストコンピュータ７１０は、ソフトウェア７１１をさらに備え、ソフトウェア７１１は、ホストコンピュータ７１０に格納されるか、ホストコンピュータ７１０によってアクセス可能であり、処理回路７１８によって実行可能である。ソフトウェア７１１は、ホストアプリケーション７１２を含む。ホストアプリケーション７１２は、ＵＥ７３０およびホストコンピュータ７１０で終端となるＯＴＴ接続７５０を介して接続するＵＥ７３０などの、リモートユーザへのサービスを提供するように動作可能であってもよい。リモートユーザにサービスを提供する際、ホストアプリケーション７１２は、ＯＴＴ接続７５０を使用して伝送されるユーザデータを提供することができる。
通信システム７００は、通信システム内に提供され、ホストコンピュータ７１０と、およびＵＥ７３０との通信を可能にするハードウェア７２５を備える基地局７２０をさらに含む。ハードウェア７２５は、通信システム７００の異なる通信デバイスのインターフェースとの有線または無線接続をセットアップし、維持するための通信インターフェース７２６、および、基地局７２０によってサーブされるカバレッジエリア（図２２４に図示せず）内に位置するＵＥ７３０との少なくとも無線接続７７０をセットアップし、維持するための無線インターフェース７２７を含むことができる。通信インターフェース７２６は、ホストコンピュータ７１０への接続７６０を容易にするように設定することができる。接続７６０は、直接であってもよく、または、通信システムのコアネットワーク（図２２４に図示せず）を、および／もしくは、通信システムの外部の１つまたは複数の中間ネットワークを通過してもよい。図示の実施形態では、基地局７２０のハードウェア７２５は、処理回路７２８をさらに含み、処理回路７２８は、命令を実行するように適合された、１つもしくは複数のプログラム可能プロセッサ、特定用途向け集積回路、フィールドプログラマブルゲートアレイ、またはこれらの組合せ（図示せず）を備えることができる。基地局７２０は、内部に格納された、または外部接続を介してアクセス可能な、ソフトウェア７２１をさらに備えることができる。
通信システム７００は、既に言及したＵＥ７３０をさらに含む。ＵＥ７３０のハードウェア７３５は、ＵＥ７３０が現在位置するカバレッジエリアをサーブする基地局との無線接続７７０をセットアップし、維持するように設定された無線インターフェース７３７を含むことができる。ＵＥ７３０のハードウェア７３５は、処理回路７３８をさらに含み、処理回路７３８は、命令を実行するように適合された、１つもしくは複数のプログラム可能プロセッサ、特定用途向け集積回路、フィールドプログラマブルゲートアレイ、またはこれらの組合せ（図示せず）を備えることができる。ＵＥ７３０は、ソフトウェア７３１をさらに備え、ソフトウェア７３１は、ＵＥ７３０に格納されるか、ＵＥ７３０によってアクセス可能であり、処理回路７３８によって実行可能である。ソフトウェア７３１は、クライアントアプリケーション７３２を含む。クライアントアプリケーション７３２は、ホストコンピュータ７１０のサポートにより、ＵＥ７３０を介して人間または非人間ユーザにサービスを提供するように動作可能であってもよい。ホストコンピュータ７１０では、実行するホストアプリケーション７１２は、ＵＥ７３０およびホストコンピュータ７１０で終端となるＯＴＴ接続７５０を介して、実行するクライアントアプリケーション７３２と通信することができる。ユーザにサービスを提供する際、クライアントアプリケーション７３２は、ホストアプリケーション７１２からリクエストデータを受信し、リクエストデータに応答して、ユーザデータを提供することができる。ＯＴＴ接続７５０は、リクエストデータとユーザデータの両方を転送することができる。クライアントアプリケーション７３２は、ユーザと対話して、ユーザが提供するユーザデータを生成することができる。
図２２４に示されているホストコンピュータ７１０、基地局７２０、およびＵＥ７３０は、図２２３のホストコンピュータ６３０、基地局６１２ａ、６１２ｂ、６１２ｃの１つ、および、ＵＥ６９１、６９２の１つとそれぞれ同一であってもよいことに留意されたい。つまり、これらのエンティティの内部の動きは、図２２４に示されているようなものであってもよく、独立して、周囲のネットワークトポロジは、図２２３のものであってもよい。
図２２４では、ＯＴＴ接続７５０は、基地局７２０を介したホストコンピュータ７１０と使用機器７３０との間の通信を示すように抽象的に描かれてきており、何らかの中間デバイス、およびこれらのデバイスを介したメッセージの正確なルーティングに明示的に言及していない。ネットワークインフラストラクチャは、ルーティングを判定することができ、ＵＥ７３０から、または、ホストコンピュータ７１０を動作させるサービスプロバイダから、または両方から隠すように設定することができる。ＯＴＴ接続７５０はアクティブであるが、ネットワークインフラストラクチャは、判定をさらに行うことができ、これにより、（例えば、負荷分散の考慮、またはネットワークの再設定に基づいて）ルーティングを動的に変化させる。
ＵＥ７３０と基地局７２０との間の無線接続７７０は、本開示の全体にわたって説明される実施形態の教示によるものである。様々な技法には、説明される技法のそれぞれに関して上記で説明したように、ＯＴＴ接続７５０を使用するネットワークおよびＵＥ７３０についての、データレート、容量、レイテンシ、信頼性、セキュリティ、および／または電力消費量を改善する可能性があり、これにより、ユーザ待ち時間の低減、より多くの容量、より良い応答性、およびより良いデバイスバッテリ時間などの利益をもたらす。
１つまたは複数の実施形態が改善するデータレート、レイテンシ、および他の要因を監視するための測定手順を提供することができる。さらに、測定結果の変動に応じて、ホストコンピュータ７１０とＵＥ７３０との間のＯＴＴ接続７５０を再設定するための任意選択のネットワーク機能があってもよい。ＯＴＴ接続７５０を再設定するための測定手順および／またはネットワーク機能は、ホストコンピュータ７１０のソフトウェア７１１で、または、ＵＥ７３０のソフトウェア７３１で、または両方で実行することができる。実施形態では、ＯＴＴ接続７５０が通る通信デバイス内に、または通信デバイスに関連して、センサ（図示せず）を展開することができ、センサは、上記で例示した監視した量の値を供給すること、または、ソフトウェア７１１、７３１が監視した量を計算するか、推定することができる他の物理量の値を供給することによって、測定手順に関与することができる。ＯＴＴ接続７５０の再設定は、メッセージフォーマット、再伝送設定、好ましいルーティング等を含むことができ、再設定は、基地局７２０に影響を及ぼす必要はなく、基地局７２０に知られていないか、または気づかれていなくてもよい。このような手順および機能は、当技術分野において知られ、実践されてもよい。一定の実施形態では、測定は、スループット、伝搬時間、レイテンシなどのホストコンピュータ７１０の測定を容易にする独自のＵＥシグナリングを含めることができる。測定は、これが伝搬時間、エラー等を監視しつつ、ＯＴＴ接続７５０を使用して、ソフトウェア７１１、７３１によって、具体的には空のまたは「ダミーの」メッセージといったメッセージが伝送されるという点で実行することができる。
図２２６は、１つの実施形態による、通信システムで実行される方法を示す流れ図である。通信システムは、図２２９および図２３０を参照しながら説明されたものであってもよいホストコンピュータ、基地局、およびＵＥを含む。本開示の簡略化のために、図２２６への図面参照だけを本セクションに含める。方法の第１のステップ８１０において、ホストコンピュータは、ユーザデータを提供する。第１のステップ８１０の任意選択のサブステップ８１１において、ホストコンピュータは、ホストアプリケーションを実行することによってユーザデータを提供する。第２のステップ８２０において、ホストコンピュータは、ユーザデータをＵＥに搬送する伝送を始める。任意選択の第３のステップ８３０において、基地局は、本開示の全体にわたって説明される実施形態の教示に従って、ホストコンピュータが始めた伝送で搬送されたユーザデータをＵＥに伝送する。任意選択の第４のステップ８４０において、ＵＥは、ホストコンピュータによって実行されたホストアプリケーションに関連付けられたクライアントアプリケーションを実行する。
図２２６は、１つの実施形態による、通信システムで実行される方法を示す流れ図である。通信システムは、図２２３および図２２４を参照しながら説明されたものであってもよいホストコンピュータ、基地局、およびＵＥを含む。本開示の簡略化のために、図２２６への図面参照だけを本セクションに含める。方法の第１のステップ９１０において、ホストコンピュータは、ユーザデータを提供する。任意選択のサブステップ（図示せず）において、ホストコンピュータは、ホストアプリケーションを実行することによってユーザデータを提供する。第２のステップ９２０において、ホストコンピュータは、ユーザデータをＵＥに搬送する伝送を始める。伝送は、本開示の全体にわたって説明される実施形態の教示に従って、基地局を介して伝えることができる。任意選択の第３のステップ８３０において、ＵＥは、伝送で搬送されたユーザデータを受信する。
図２２７は、１つの実施形態による、通信システムで実行される方法を示す流れ図である。通信システムは、図２２３および図２２４を参照しながら説明されたものであってもよいホストコンピュータ、基地局、およびＵＥを含む。本開示の簡略化のために、図２２７への図面参照だけを本セクションに含める。方法の任意選択の第１のステップ１０１０において、ＵＥは、ホストコンピュータによって提供された入力データを受信する。追加として、または代替として、任意選択の第２のステップ１０２０において、ＵＥは、ユーザデータを提供する。第２のステップ１０２０の任意選択のサブステップ１０２１において、ＵＥは、クライアントアプリケーションを実行することによってユーザデータを提供する。第１のステップ１０１０のさらなる任意選択のサブステップ１０１１において、ＵＥは、受信した入力データがホストコンピュータによって提供されたのに応答して、ユーザデータを提供するクライアントアプリケーションを実行する。ユーザデータを提供する際、実行したクライアントアプリケーションは、ユーザから受信したユーザ入力をさらに考慮してもよい。ユーザデータを提供した特定の手法に関わらず、ＵＥは、任意選択の第３のサブステップ１０３０において、ホストコンピュータへのユーザデータの伝送を始める。方法の第４のステップ１０４０において、ホストコンピュータは、本開示の全体にわたって説明される実施形態の教示に従って、ＵＥから伝送されたユーザデータを受信する。
図２２８は、１つの実施形態による、通信システムで実行される方法を示す流れ図である。通信システムは、図２２３および図２２４を参照しながら説明されたものであってもよいホストコンピュータ、基地局、およびＵＥを含む。本開示の簡略化のために、図２２８への図面参照だけを本セクションに含める。方法の任意選択の第１のステップ１１１０において、本開示の全体にわたって説明される実施形態の教示に従って、基地局は、ＵＥからユーザデータを受信する。任意選択の第２のステップ１１２０において、基地局は、ホストコンピュータへの受信したユーザデータの伝送を始める。第３のステップ１１３０において、ホストコンピュータは、基地局によって始められた伝送で搬送されたユーザデータを受信する。
図２３１および図２３４に示されている方法は、本明細書で説明され、同じまたは重複するデバイスまたはノードを伴う他の様々な方法のいずれかと組み合わせることができることが理解されよう。
本発明の概念の原理から実質的に逸脱することなく、実施形態に対して多くの変更および修正を行うことができる。全てのこのような変更および修正は、本発明の概念の範囲内の本明細書に含まれることを意図するものである。したがって、上記で開示した主題は、制限的でなく例証的であるとみなされるべきであり、実施形態の例は、本発明の概念の精神および範囲に含まれる、全てのこのような修正、拡張、および他の実施形態をカバーすることを意図するものである。したがって、法律によって許容される最大限度まで、本発明の概念の範囲は、実施形態の例、およびその同等物を含む、本開示の最も広く許容可能な解釈によって決定されるべきであり、前述の詳細な説明によって制限または限定されるべきではない。

Claims (13)

  1. 無線通信ネットワークと関連付けられた無線デバイスによって実施される方法であって、
    前記無線通信ネットワークの無線基地局（ＲＢＳ）から、システム情報（ＳＩ）または無線リソース制御（ＲＲＣ）メッセージを受信することであって、前記ＳＩまたはＲＲＣメッセージが、前記ＲＢＳを通じた少なくとも１つのタイムセンシティブネットワーキング（ＴＳＮ）特徴のサポートを示している、システム情報（ＳＩ）または無線リソース制御（ＲＲＣ）メッセージを受信することと、
    前記無線通信ネットワークから第１のタイミング信号を受信することであって、前記第１のタイミング信号が、前記無線通信ネットワークの内部のシステムクロックのための時間基準を含む、第１のタイミング信号を受信することと、
    前記無線デバイスが接続される外部ＴＳＮデータネットワークから第２のタイミング信号を受信することであって、前記第２のタイミング信号が、作動時計時間基準を含む、第２のタイミング信号を受信することと、
    前記ＲＢＳを通じて、受信した前記ＳＩまたはＲＲＣメッセージに基づいて、前記外部ＴＳＮデータネットワーク対応のネットワークエンティティによって共有される共通時間基準を有する、少なくとも１つのＴＳＮストリームを確立することと
    を含み、
    前記共通時間基準は、前記第１のタイミング信号と第２のタイミング信号とに基づく、
    方法。
  2. 前記ＳＩを受信することが、前記ＲＢＳを通じたＴＳＮのための少なくとも１つの特徴のサポートを示すＳＩを受信することを含む、
    請求項１に記載の方法。
  3. 前記ＳＩは、１つまたは複数のシステム情報ブロック（ＳＩＢ）に含まれる、
    請求項２に記載の方法。
  4. 前記第１のタイミング信号は、前記ＲＢＳから受信されるＳＩ内で受信される、
    請求項１から３のいずれか一項に記載の方法。
  5. 前記ＲＲＣメッセージを受信することが、前記ＲＢＳを通じたＴＳＮのための少なくとも１つの特徴のサポートを示すＲＲＣメッセージを受信することを含む、
    請求項１に記載の方法。
  6. 前記第１のタイミング信号は、前記ＲＲＣメッセージ内で受信される、
    請求項５に記載の方法。
  7. 前記無線通信ネットワークは、新無線（Ｎｅｗ Ｒａｄｉｏ）無線通信ネットワークなどのセルラ通信ネットワークである、
    請求項１から６のいずれか一項に記載の方法。
  8. 無線通信ネットワーク内での使用のための無線デバイスであって、前記無線デバイスは、
    前記無線通信ネットワークの無線基地局（ＲＢＳ）から、システム情報（ＳＩ）または無線リソース制御（ＲＲＣ）メッセージを受信することであって、前記ＳＩまたはＲＲＣメッセージが、前記ＲＢＳを通じた少なくとも１つのタイムセンシティブネットワーキング（ＴＳＮ）特徴のサポートを示している、システム情報（ＳＩ）または無線リソース制御（ＲＲＣ）メッセージを受信することと、
    前記無線通信ネットワークから第１のタイミング信号を受信することであって、前記第１のタイミング信号が、前記無線通信ネットワークの内部のシステムクロックのための時間基準を含む、第１のタイミング信号を受信することと、
    前記無線デバイスが接続される外部ＴＳＮデータネットワークから第２のタイミング信号を受信することであって、前記第２のタイミング信号が、作動時計時間基準を含む、第２のタイミング信号を受信することと、
    前記ＲＢＳを通じて、受信した前記ＳＩまたはＲＲＣメッセージに基づいて、前記外部ＴＳＮデータネットワーク対応のネットワークエンティティによって共有される共通時間基準を有する、少なくとも１つのＴＳＮデータストリームを確立することと、
    を行うように適合され、
    前記共通時間基準は、前記第１のタイミング信号と第２のタイミング信号とに基づく、
    無線デバイス。
  9. 前記無線デバイスは、前記ＲＢＳを通じたＴＳＮのための少なくとも１つの特徴のサポートを示すＳＩを受信するように適合される、
    請求項８に記載の無線デバイス。
  10. 前記無線デバイスは、前記ＲＢＳから受信されるＳＩ内で前記第１のタイミング信号を受信するように適合される、
    請求項８または９に記載の無線デバイス。
  11. 前記無線デバイスは、前記ＲＢＳを通じたＴＳＮのための少なくとも１つの特徴のサポートを示すＲＲＣメッセージを受信するように適合される、
    請求項８に記載の無線デバイス。
  12. 無線デバイスによる実行のためのプログラム命令を含むコンピュータプログラム製品であって、前記プログラム命令が、請求項１から７のいずれか一項に記載の方法を前記無線デバイスに実行させるように設定される、
    コンピュータプログラム。
  13. 非一時的なコンピュータ可読媒体であって、そこに格納された請求項１２に記載のコンピュータプログラムを備える、
    非一時的なコンピュータ可読媒体。
JP2021547171A 2019-02-13 2020-02-11 ５ｇ以降を用いた産業自動化 Active JP7241899B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US16/274,800 US20200259896A1 (en) 2019-02-13 2019-02-13 Industrial Automation with 5G and Beyond
US16/274,800 2019-02-13
PCT/SE2020/050139 WO2020167222A2 (en) 2019-02-13 2020-02-11 Industrial automation with 5g and beyond

Publications (2)

Publication Number Publication Date
JP2022522630A JP2022522630A (ja) 2022-04-20
JP7241899B2 true JP7241899B2 (ja) 2023-03-17

Family

ID=69726678

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2021547171A Active JP7241899B2 (ja) 2019-02-13 2020-02-11 ５ｇ以降を用いた産業自動化

Country Status (15)

Country Link
US (1) US20200259896A1 (ja)
EP (2) EP3925239B1 (ja)
JP (1) JP7241899B2 (ja)
KR (1) KR102547760B1 (ja)
CN (1) CN113615239A (ja)
BR (1) BR112021015413A2 (ja)
CO (1) CO2021008919A2 (ja)
DK (1) DK3925239T3 (ja)
ES (1) ES2928297T3 (ja)
MX (1) MX2021009432A (ja)
PL (1) PL3925239T3 (ja)
SG (1) SG11202106332XA (ja)
TW (2) TWI770803B (ja)
WO (1) WO2020167222A2 (ja)
ZA (1) ZA202106710B (ja)

Families Citing this family (241)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016163032A1 (ja) 2015-04-10 2016-10-13 富士通株式会社 無線通信システム、基地局、移動局および処理方法
JP6606355B2 (ja) * 2015-05-29 2019-11-13 キヤノン株式会社 情報処理装置、情報処理方法、及びプログラム
US11350449B2 (en) * 2016-09-29 2022-05-31 Apple Inc. Frequency hopping for unlicensed internet of things
US11256641B2 (en) * 2017-01-27 2022-02-22 National Instruments Corporation Asynchronous start for timed functions
EP3665810B1 (en) * 2017-08-09 2022-10-19 Telefonaktiebolaget LM Ericsson (Publ) Transient protection interval
US10536859B2 (en) 2017-08-15 2020-01-14 Charter Communications Operating, Llc Methods and apparatus for dynamic control and utilization of quasi-licensed wireless spectrum
US10951359B2 (en) * 2018-01-18 2021-03-16 Asustek Computer Inc. Method and apparatus for providing control resource set configuration in a wireless communication system
KR102616557B1 (ko) 2018-02-13 2023-12-26 삼성전자 주식회사 무선 통신 시스템에서 데이터 및 제어 정보 송수신 방법 및 장치
US11690068B2 (en) * 2018-06-21 2023-06-27 Nokia Technologies Oy Optimal BSR for limited traffic mix
US11281200B2 (en) * 2018-10-01 2022-03-22 Fisher-Rosemount Systems, Inc. Drone-enabled operator rounds
JP6885909B2 (ja) * 2018-10-12 2021-06-16 ファナック株式会社 ロボット制御装置
KR102651436B1 (ko) 2018-11-02 2024-03-25 아싸 아브로이 에이비 액세스 제어를 위한 시스템들, 방법들, 및 디바이스들
CN111200848B (zh) * 2018-11-19 2022-03-25 华为技术有限公司 一种通信方法及装置
US11424868B2 (en) * 2019-01-24 2022-08-23 Mediatek Singapore Pte. Ltd. Method and apparatus for user equipment processing timeline enhancement in mobile communications
CN111510419B (zh) * 2019-01-31 2021-03-30 华为技术有限公司 一种数据压缩的方法及基站
CN112740630B (zh) * 2019-02-01 2024-02-13 Oppo广东移动通信有限公司 业务处理方法、设备、芯片及计算机程序
US11349764B2 (en) * 2019-02-15 2022-05-31 Qualcomm Incorporated Methods and apparatus for signaling offset in a wireless communication system
WO2020169170A1 (en) * 2019-02-18 2020-08-27 Lenovo (Singapore) Pte. Ltd. Calculating round trip time in a mobile communication network
EP3928473B1 (en) * 2019-02-20 2024-05-15 Level 3 Communications, LLC Systems and methods for communications node upgrade and selection
KR20200104217A (ko) * 2019-02-26 2020-09-03 한국전자통신연구원 이동통신망에서 패킷 처리 방법 및 이를 수행하는 네트워크 엘리먼트
US11239939B2 (en) 2019-03-22 2022-02-01 Samsung Electronics Co., Ltd. Scheduling in communication systems with multiple service types
EP3928114A1 (en) * 2019-03-25 2021-12-29 Assa Abloy Ab Physical access control systems with localization-based intent detection
KR102592842B1 (ko) 2019-03-25 2023-10-20 아싸 아브로이 에이비 액세스 제어 판독기 시스템을 위한 초광대역 디바이스
WO2020192748A1 (en) * 2019-03-27 2020-10-01 FG Innovation Company Limited Method and apparatus for handling overlapping pusch durations
EP3949311B1 (en) * 2019-03-28 2024-02-07 British Telecommunications public limited company Competitor selection
JP6704548B1 (ja) * 2019-03-28 2020-06-03 三菱電機株式会社 通信システム、通信装置及びプログラム
EP3715983B1 (de) * 2019-03-28 2022-06-29 Siemens Aktiengesellschaft Verfahren zur bereitstellung von steuerungsanwendungen über ein kommunikationsnetz zur übermittlung zeitkritischer daten und koordinierungseinrichtung
EP3935795A1 (en) * 2019-03-29 2022-01-12 Huawei Technologies Co., Ltd. Switch device, control device and corresponding methods for enhanced schedulability and throughput on a tsn network
US11184872B2 (en) * 2019-04-04 2021-11-23 Qualcomm Incorporated Reference timing delivery to user equipment with propagation delay compensation
EP3962187A4 (en) * 2019-04-26 2022-12-07 Ntt Docomo, Inc. WIRELESS BASE STATION
EP3963829A1 (en) * 2019-05-02 2022-03-09 Nokia Technologies Oy Integration of communication network in time sensitive networking system
US20200351814A1 (en) * 2019-05-02 2020-11-05 Qualcomm Incorporated Group delay timing accuracy for positioning in new radio
US11395244B2 (en) * 2019-05-03 2022-07-19 Samsung Electronics Co., Ltd. Apparatus and method for supporting burst arrival time reference clock based on time-sensitive communication assistance information in wireless communication network
KR20220006090A (ko) * 2019-05-07 2022-01-14 지티이 코포레이션 무선 통신에서 시간 매핑을 위한 방법, 장치 및 시스템
US11520322B2 (en) * 2019-05-24 2022-12-06 Markforged, Inc. Manufacturing optimization using a multi-tenant machine learning platform
EP3984183A1 (en) * 2019-06-14 2022-04-20 Nokia Technologies Oy Supporting bridge managed objects
CN110267312B (zh) * 2019-06-17 2023-09-19 腾讯科技（深圳）有限公司 数据传输的方法、管理服务质量流的方法、设备及介质
CN112118073B (zh) * 2019-06-19 2022-04-22 华为技术有限公司 一种数据处理方法、光传输设备及数字处理芯片
EP3758249A1 (en) * 2019-06-27 2020-12-30 Nokia Technologies Oy Adaptive antenna arrangements for cellular communication system
RU2739862C2 (ru) * 2019-06-28 2020-12-29 Акционерное общество "Лаборатория Касперского" Способ адаптивного выбора путей передачи данных пользователя
US11374779B2 (en) * 2019-06-30 2022-06-28 Charter Communications Operating, Llc Wireless enabled distributed data apparatus and methods
CN117412346A (zh) 2019-07-09 2024-01-16 荣耀终端有限公司 灾害期间的网络重选的方法、装置和系统
CN114051715A (zh) * 2019-07-22 2022-02-15 华为技术有限公司 控制设备、交换设备和方法
DE102019211843A1 (de) * 2019-08-07 2021-02-11 Kuka Deutschland Gmbh Kommunikation mit automatisierbaren industriellen Vorrichtungen oder Anlagen oder mit deren Steuerung
US11176149B2 (en) * 2019-08-13 2021-11-16 International Business Machines Corporation Predicted data provisioning for analytic workflows
US11184097B2 (en) * 2019-08-16 2021-11-23 Arista Networks, Inc. VLAN-aware clock hierarchy
US10951745B1 (en) * 2019-08-23 2021-03-16 Asustek Computer Inc. Method and apparatus for header compression configuration for sidelink radio bearer in a wireless communication system
US11736933B2 (en) * 2019-08-26 2023-08-22 Qualcomm Incorporated Capability signaling for physical uplink shared channel repetition
US11172501B2 (en) * 2019-09-05 2021-11-09 Qualcomm Incorporated Methods and apparatus for signaling offset in a wireless communication system
US11528748B2 (en) 2019-09-11 2022-12-13 Charter Communications Operating, Llc Apparatus and methods for multicarrier unlicensed heterogeneous channel access
CN114391235B (zh) * 2019-09-13 2024-04-09 鸿颖创新有限公司 执行用于非优先的上行链路授权的混合自动重复请求进程的方法及相关设备
CN114651489A (zh) * 2019-09-30 2022-06-21 三星电子株式会社 支持tsc的设备和方法
US11785632B2 (en) * 2019-10-02 2023-10-10 Ofinno, Llc On demand system information for sidelink communications
US11632774B2 (en) * 2019-10-04 2023-04-18 Qualcomm Incorporated Systems and methods for determining cancellation timeline for user equipment with mixed processing capabilities
US11716626B2 (en) * 2019-10-22 2023-08-01 General Electric Company Network access control system
CN115699050A (zh) * 2019-11-05 2023-02-03 强力价值链网络投资组合2019有限公司 价值链网络控制塔和企业管理平台
WO2021092260A1 (en) * 2019-11-05 2021-05-14 Strong Force Vcn Portfolio 2019, Llc Control tower and enterprise management platform for value chain networks
EP4055786A1 (en) * 2019-11-08 2022-09-14 Telefonaktiebolaget LM Ericsson (publ) Qos mapping
US11563529B2 (en) * 2019-11-08 2023-01-24 Mediatek Singapore Pte. Ltd. Method and apparatus for out-of-order hybrid automatic repeat request feedback in mobile communications
CN110989605B (zh) * 2019-12-13 2020-09-18 哈尔滨工业大学 一种三体智能系统架构及探测机器人
US11411925B2 (en) * 2019-12-31 2022-08-09 Oracle International Corporation Methods, systems, and computer readable media for implementing indirect general packet radio service (GPRS) tunneling protocol (GTP) firewall filtering using diameter agent and signal transfer point (STP)
US20210211886A1 (en) * 2020-01-08 2021-07-08 Qualcomm Incorporated Interference coordination in licensed shared radio frequency spectrum
US11356234B1 (en) * 2020-01-28 2022-06-07 T-Mobile Innovations Llc Scheduling full-duplex transmissions in 5G networks
FI130347B (en) * 2020-01-31 2023-06-30 Cumucore Oy System and method for transmission of isochronous data in industrial network
CN113498585A (zh) * 2020-02-07 2021-10-12 Oppo广东移动通信有限公司 信息接收的方法、发送的方法、装置和设备
CN113260039B (zh) * 2020-02-13 2023-04-07 维沃移动通信有限公司 信息控制方法及通信设备
EP3866442B1 (en) * 2020-02-17 2023-06-07 ABB Schweiz AG Interface apparatus between tsn-devices and non-tsn-devices
US11553376B2 (en) * 2020-03-09 2023-01-10 Qualcomm Incorporated Communication link selection for non-RSRP based association in wireless industrial internet-of-things
EP3882662A1 (en) * 2020-03-16 2021-09-22 Nxp B.V. Localization device and method of operating a localization device
US11228942B2 (en) * 2020-03-27 2022-01-18 Mitsubishi Electric Research Laboratories, Inc. Scheduling data traffic in wireless time sensitive networks
EP3893450A1 (en) * 2020-04-08 2021-10-13 NTT DoCoMo, Inc. Method for forwarding an ethernet frame by a time-sensitive networking ethernet bridge provided by means of a mobile radio communication system and mobile radio communication system arrangement
US11012857B1 (en) * 2020-04-13 2021-05-18 Sprint Communications Company L.P. Fifth generation core (5GC) authentication for long term evolution (LTE) data service
US20210329574A1 (en) * 2020-04-15 2021-10-21 Qualcomm Incorporated Selection of initial acquisition parameters for reduced-capability devices
US11407109B2 (en) * 2020-04-16 2022-08-09 Boston Dynamics, Inc. Global arm path planning with roadmaps and precomputed domains
US11678284B2 (en) * 2020-04-17 2023-06-13 Electronics And Telecommunications Research Institute Radio communication method for time-sensitive network, and apparatus therefor
US20210337622A1 (en) 2020-04-28 2021-10-28 Apple Inc. Framework for Supporting Custom Signaling Between a Wireless Device and a Cellular Network
GB2594512B (en) * 2020-04-30 2022-08-24 Spatialbuzz Ltd Network fault diagnosis
WO2021226634A1 (en) * 2020-05-05 2021-11-11 Apple Inc. System and method for survival time delivery in 5gc
CN113677005A (zh) * 2020-05-14 2021-11-19 华为技术有限公司 一种通信方法及装置
JP2021180412A (ja) * 2020-05-14 2021-11-18 キヤノン株式会社 通信装置、通信装置の制御方法およびプログラム
JP2023527384A (ja) 2020-05-27 2023-06-28 ピヴォタル コムウェア インコーポレイテッド ５ｇワイヤレスネットワーク用ｒｆ信号リピータデバイスの管理方法
US11133959B1 (en) * 2020-06-15 2021-09-28 Moxa Inc. Apparatuses and methods for routing packets for a time-sensitive networking (TSN) network by virtual local area network (VLAN) tag replacement
US11121889B1 (en) * 2020-06-15 2021-09-14 Moxa Inc. Apparatuses and methods for routing packets between a time-sensitive networking (TSN) network and a non-TSN network by virtual local area network (VLAN) tag manipulation
US11653400B2 (en) * 2020-06-16 2023-05-16 Blu Wireless Technology Limited Wireless communication for vehicle based node
US11503557B2 (en) * 2020-06-18 2022-11-15 Kabushiki Kaisha Toshiba Time synchronization in integrated 5G wireless and time-sensitive networking systems
US11438770B2 (en) 2020-07-01 2022-09-06 Celona, Inc. Method and apparatus for monitoring and predicting channel availability and preemptively reconfiguring the network in a spectrum controlled network
US11399290B2 (en) * 2020-07-01 2022-07-26 Celona, Inc. Method and apparatus for monitoring and predicting capacity utilization and preemptively reconfiguring the network in a spectrum controlled network
US11553342B2 (en) 2020-07-14 2023-01-10 Oracle International Corporation Methods, systems, and computer readable media for mitigating 5G roaming security attacks using security edge protection proxy (SEPP)
US11233715B1 (en) * 2020-07-14 2022-01-25 Juniper Networks, Inc. Dynamic prediction and management of application service level agreements
US11616588B2 (en) * 2020-07-24 2023-03-28 Dish Wireless L.L.C. Method and system for timing synchronization in a cellular network
US11363103B2 (en) * 2020-07-27 2022-06-14 T-Mobile Usa, Inc. Dynamic user plane function (UPF) selection based on supported protocol type
US11849341B2 (en) * 2020-07-27 2023-12-19 Verizon Patent And Licensing Inc. Systems and methods for simulating wireless user equipment and radio access network messaging over packet-based networks
US11533217B2 (en) * 2020-07-31 2022-12-20 Hewlett Packard Enterprise Development Lp Systems and methods for predictive assurance
US11026055B1 (en) 2020-08-03 2021-06-01 Pivotal Commware, Inc. Wireless communication network management for user devices based on real time mapping
WO2022042833A1 (en) * 2020-08-26 2022-03-03 Telefonaktiebolaget Lm Ericsson (Publ) Methods and systems for improving controlling of a robot
EP4205340A1 (en) * 2020-08-28 2023-07-05 Telefonaktiebolaget LM Ericsson (publ) Radio network node, user equipment and methods performed in a wireless communication network
US11751056B2 (en) 2020-08-31 2023-09-05 Oracle International Corporation Methods, systems, and computer readable media for 5G user equipment (UE) historical mobility tracking and security screening using mobility patterns
US20220067509A1 (en) * 2020-09-02 2022-03-03 Alibaba Group Holding Limited System and method for learning from partial compressed representation
WO2022047684A1 (en) * 2020-09-03 2022-03-10 Qualcomm Incorporated Voice over new radio reliability enhancement by duplicate transmission of internet protocol multimedia subsystem signaling
US11297606B2 (en) 2020-09-08 2022-04-05 Pivotal Commware, Inc. Installation and activation of RF communication devices for wireless networks
US11832172B2 (en) 2020-09-25 2023-11-28 Oracle International Corporation Methods, systems, and computer readable media for mitigating spoofing attacks on security edge protection proxy (SEPP) inter-public land mobile network (inter-PLMN) forwarding interface
US11825310B2 (en) 2020-09-25 2023-11-21 Oracle International Corporation Methods, systems, and computer readable media for mitigating 5G roaming spoofing attacks
US11924696B2 (en) * 2020-10-01 2024-03-05 Nokia Technologies Oy Reducing traffic interruption during handover
US20230379081A1 (en) * 2020-10-02 2023-11-23 Nokia Solutions And Networks Oy Frer support of wireless communication system operable as tsn bridge
US11622255B2 (en) 2020-10-21 2023-04-04 Oracle International Corporation Methods, systems, and computer readable media for validating a session management function (SMF) registration request
EP4236120A4 (en) * 2020-10-30 2023-12-13 Huawei Technologies Co., Ltd. METHOD AND APPARATUS FOR TRANSMITTING MESSAGES
US11528251B2 (en) 2020-11-06 2022-12-13 Oracle International Corporation Methods, systems, and computer readable media for ingress message rate limiting
KR102656209B1 (ko) * 2020-11-09 2024-04-09 한국전자통신연구원 시동기 서비스를 제공하기 위한 5g 시스템의 포트 구성 방법 및 이를 수행하는 네트워크 엔티티
CN112511376B (zh) * 2020-11-12 2022-04-15 鹏城实验室 一种tsn网络转发时间特性的测量方法及终端
US11770694B2 (en) 2020-11-16 2023-09-26 Oracle International Corporation Methods, systems, and computer readable media for validating location update messages
US20240008091A1 (en) * 2020-11-18 2024-01-04 Beijing Xiaomi Mobile Software Co., Ltd. Modulation and coding scheme (mcs) configuration method and apparatus, and communication device
US11627511B2 (en) 2020-11-19 2023-04-11 Cisco Technology, Inc. Techniques to facilitate data stream routing and entitlement
US11736359B2 (en) * 2020-11-20 2023-08-22 Ge Aviation Systems Llc Method and system for generating a time-sensitive network configuration
CN112436929B (zh) * 2020-11-24 2023-09-15 北京中航通用科技有限公司 一种混合双通道热冗余近场通信的方法及装置
US11895603B2 (en) * 2020-11-25 2024-02-06 Electronics And Telecommunications Research Institute Frame structure and terminal synchronization method and apparatus in wireless communication system
US11564117B2 (en) * 2020-11-30 2023-01-24 Verizon Patent And Licensing Inc. User equipment based network capability scoring for wireless wide area network management
US11570806B2 (en) * 2020-12-04 2023-01-31 Qualcomm Incorporated Conditional configured grant (CG) occasions for uplink transmission
US20220191303A1 (en) * 2020-12-10 2022-06-16 Amazon Technologies, Inc. Intersection of on-demand network slicing and content delivery
CN112637290B (zh) * 2020-12-14 2024-03-19 厦门宏泰科技研究院有限公司 一种基于微基站及边缘计算的全球通信网络系统
US11575751B2 (en) * 2020-12-14 2023-02-07 International Business Machines Corporation Dynamic creation of sensor area networks based on geofenced IoT devices
WO2022126399A1 (zh) * 2020-12-15 2022-06-23 华为技术有限公司 一种通信方法及通信装置
US11818570B2 (en) 2020-12-15 2023-11-14 Oracle International Corporation Methods, systems, and computer readable media for message validation in fifth generation (5G) communications networks
US11658911B2 (en) 2020-12-16 2023-05-23 Microchip Technology Inc. System and method for low latency network switching
DE112021005053T5 (de) * 2020-12-16 2023-07-13 Microchip Technology Inc. System und Verfahren für Netzwerkumschaltung mit niedriger Latenz
US11537227B2 (en) 2020-12-17 2022-12-27 CEO Vision, Inc Systems and methods for control of a virtual world
US11812271B2 (en) 2020-12-17 2023-11-07 Oracle International Corporation Methods, systems, and computer readable media for mitigating 5G roaming attacks for internet of things (IoT) devices based on expected user equipment (UE) behavior patterns
US11375526B1 (en) 2020-12-28 2022-06-28 Charter Communications Operating, Llc Uplink resource allocation in fixed wireless access systems using WiFi controller
EP4272517A1 (en) * 2020-12-30 2023-11-08 Telefonaktiebolaget LM Ericsson (publ) Wireline communication technique
EP4278645A1 (en) 2021-01-15 2023-11-22 Pivotal Commware, Inc. Installation of repeaters for a millimeter wave communications network
EP4280768A4 (en) * 2021-01-28 2024-02-28 Huawei Tech Co Ltd SERVICE DATA FLOW TRANSMISSION METHOD, COMMUNICATION DEVICE AND COMMUNICATION SYSTEM
EP4238489A1 (en) * 2021-01-29 2023-09-06 Samsung Electronics Co., Ltd. Electronic device and method for synchronizing times of different data records
WO2022160346A1 (zh) * 2021-02-01 2022-08-04 华为技术有限公司 一种通信方法及装置
TWI742999B (zh) * 2021-02-09 2021-10-11 中華電信股份有限公司 聯網設備資料缺漏分析與補值裝置、系統、方法及電腦可讀媒介
CN114915988A (zh) * 2021-02-10 2022-08-16 维沃移动通信有限公司 信息传输方法、通信设备及存储介质
US11700510B2 (en) 2021-02-12 2023-07-11 Oracle International Corporation Methods, systems, and computer readable media for short message delivery status report validation
US11876871B2 (en) * 2021-02-18 2024-01-16 Verizon Patent And Licensing Inc. Systems and methods for providing firmware over-the-air updates
US11516671B2 (en) 2021-02-25 2022-11-29 Oracle International Corporation Methods, systems, and computer readable media for mitigating location tracking and denial of service (DoS) attacks that utilize access and mobility management function (AMF) location service
US11533688B2 (en) * 2021-03-17 2022-12-20 T-Mobile Usa, Inc. Dynamic switching of user equipment power class
CN113055303B (zh) * 2021-03-24 2022-06-03 重庆邮电大学 一种适用于时间敏感网络中多周期应用的门控调度方法
CN112702282B (zh) * 2021-03-25 2021-07-09 浙江大学 时间敏感网络的柔性化配置方法和系统
KR20220133716A (ko) * 2021-03-25 2022-10-05 삼성전자주식회사 가상 기업망을 구성하기 위한 장치 및 방법
CN113068263B (zh) * 2021-03-26 2022-07-05 鹏城实验室 一种时间敏感网络时隙调度方法、终端及存储介质
WO2022198648A1 (en) * 2021-03-26 2022-09-29 Zte Corporation Methods for information configuration in wireless communication
CN112734945B (zh) * 2021-03-30 2021-08-17 上海交大智邦科技有限公司 一种基于增强现实的装配引导方法、系统及应用
CN115150841B (zh) * 2021-03-30 2024-02-23 南宁富联富桂精密工业有限公司 上下行覆盖增强方法、电子设备及计算机存储介质
EP4072042A1 (en) * 2021-04-08 2022-10-12 Deutsche Telekom AG Synchronizing a distributed application via a communication network
CN112804043B (zh) * 2021-04-12 2021-07-09 广州迈聆信息科技有限公司 时钟不同步的检测方法、装置及设备
CN117044134A (zh) * 2021-04-15 2023-11-10 华为技术有限公司 在移动网络上跨tsn域进行时间敏感通信的移动网络实体
US20220335431A1 (en) * 2021-04-16 2022-10-20 Somos, Inc. Systems and methods for fraudulent activity detection
US11824788B2 (en) * 2021-04-22 2023-11-21 Moxa Inc. Apparatuses and methods for supporting class-based scheduling in a time-sensitive networking (TSN) network
CN113194424B (zh) * 2021-04-27 2023-09-12 大连理工大学 工业物联网中基于中断概率的raw分组接入方法
TWI765677B (zh) * 2021-04-27 2022-05-21 啟碁科技股份有限公司 用於次世代無線電存取網路的超可靠低延遲通信的本地分流方法及系統
EP4087369A1 (en) * 2021-05-03 2022-11-09 Mavenir Systems, Inc. Method and apparatus for survival time handling for time sensitive connections
US11689912B2 (en) 2021-05-12 2023-06-27 Oracle International Corporation Methods, systems, and computer readable media for conducting a velocity check for outbound subscribers roaming to neighboring countries
US11601363B2 (en) * 2021-05-14 2023-03-07 Comcast Cable Communications, Llc Intelligent internet traffic routing
CN113271575B (zh) * 2021-05-14 2022-04-29 重庆邮电大学 基于信息和用户意识耦合的d2d信息传播建模方法
US11936740B2 (en) * 2021-05-18 2024-03-19 Schneider Electric USA, Inc. Modeling and management of industrial network using OPCUA
US11641630B2 (en) * 2021-05-18 2023-05-02 Qualcomm Incorporated Time-sensitive networking support over sidelink
US11582672B2 (en) * 2021-05-18 2023-02-14 Thales Avionics, Inc. Dynamic roaming for aircraft data traffic connectivity between communication networks based on performance measurements
US11653218B2 (en) * 2021-05-20 2023-05-16 Charter Communications Operating, Llc. 5G bandwidth part configuration method in CBRS fixed wireless access network
CN113038590B (zh) 2021-05-25 2021-08-10 深圳艾灵网络有限公司 时间同步方法、电子设备及存储介质
CN115412507A (zh) * 2021-05-28 2022-11-29 中国移动通信有限公司研究院 数据处理、信息确定方法及设备、存储介质
US11892955B2 (en) 2021-06-01 2024-02-06 Microchip Technology Inc. System and method for bypass memory read request detection
EP4360265A1 (en) * 2021-06-23 2024-05-01 Telefonaktiebolaget LM Ericsson (publ) Transmitting node, receiving node and methods performed therein
US11317371B1 (en) * 2021-06-30 2022-04-26 Hubstar International Limited Scheduling allocation of resources to a number of devices based on time and location
CN113259081B (zh) * 2021-07-05 2021-09-28 中国人民解放军国防科技大学 一种跨时间域的数据同步系统及方法
US11570066B1 (en) * 2021-07-07 2023-01-31 Cisco Technology, Inc. Slice intent efficiency assurance and enhancement in enterprise private 5G network
EP4367919A1 (en) 2021-07-07 2024-05-15 Pivotal Commware, Inc. Multipath repeater systems
CN115701043A (zh) * 2021-07-14 2023-02-07 南宁富联富桂精密工业有限公司 网络切片管理方法、装置及计算机可读存储介质
US11671861B2 (en) * 2021-07-14 2023-06-06 At&T Intellectual Property I, L.P. Intelligent customer oriented mobility network engineering at edges
WO2023288098A1 (en) * 2021-07-15 2023-01-19 General Electric Company System and method for configuring network slices for time-sensitive networks
CN117917058A (zh) * 2021-07-15 2024-04-19 通用电气公司 用于网络切片的时间敏感性网络(tsn)实现的系统和方法
CN115696366A (zh) * 2021-07-23 2023-02-03 维沃移动通信有限公司 数字孪生子系统及服务提供装置
US11336732B1 (en) * 2021-07-26 2022-05-17 Schneider Electric USA, Inc. IoT licensing platform and architecture
US11757707B2 (en) * 2021-07-28 2023-09-12 Cisco Technology, Inc. Network assurance for 5G enterprise networks
CN113783842B (zh) * 2021-08-09 2022-05-24 中国科学院计算技术研究所 一种5g专网upf的计算存储资源分配方法
WO2023017296A1 (en) * 2021-08-11 2023-02-16 Nokia Technologies Oy Method and apparatus for communication system involving synchronisaton of local clocks
US20230052998A1 (en) * 2021-08-12 2023-02-16 Abb Schweiz Ag Systems and methods for configuring industrial devices through a secured wireless side channel
US20230051166A1 (en) * 2021-08-12 2023-02-16 Wisys Technology Foundation, Inc. Delay Sensitive Network Estimation System
US20230058614A1 (en) * 2021-08-13 2023-02-23 Qualcomm Incorporated Conditional use of allocated periodic resources
US11765087B1 (en) * 2021-08-19 2023-09-19 T-Mobile Innovations Llc Rapid packet processing at user plane function
CN113746605B (zh) * 2021-08-26 2023-01-24 深圳市盛博科技嵌入式计算机有限公司 可靠的工业数据流的传输方法
CN113904991B (zh) * 2021-08-26 2023-08-22 北京邮电大学 一种流量整形方法、装置及系统
US20230075864A1 (en) * 2021-09-03 2023-03-09 Qualcomm Incorporated Resource bundle for time sensitive networking bridge
EP4149074A1 (en) * 2021-09-13 2023-03-15 Nokia Solutions and Networks Oy Slice configuration across operations technology and network domains
CN113848779B (zh) * 2021-09-15 2023-11-10 北京和利时系统工程有限公司 一种控制器、工业控制系统和数据传输方法
WO2023061566A1 (en) * 2021-10-13 2023-04-20 Nokia Technologies Oy Utc traceability support for terminal devices
CN113992671B (zh) * 2021-10-25 2024-01-30 中国电信股份有限公司 数据处理方法、电子设备和计算机可读存储介质
TWI784773B (zh) * 2021-10-27 2022-11-21 財團法人工業技術研究院 取得豐富資訊的方法及控制器
EP4181478A1 (en) 2021-11-11 2023-05-17 Abb Schweiz Ag Improving communication in an industrial automation system
US11818646B2 (en) * 2021-11-15 2023-11-14 Kabushiki Kaisha Toshiba System-level schedule generation for integrated TSN and 5G deployments
CN113810918A (zh) * 2021-11-16 2021-12-17 矿冶科技集团有限公司 地下巷道数据的传输方法、装置和电子设备
US11627063B1 (en) * 2021-12-02 2023-04-11 Verizon Patent And Licensing Inc. Systems and methods for measuring unidirectional latency of applications over asymmetric links
CN116249192A (zh) * 2021-12-07 2023-06-09 瑞昱半导体股份有限公司 网络及节点同步方法
US11902788B2 (en) * 2021-12-08 2024-02-13 T-Mobile Innovations Llc 5G hyperledger slice security framework
WO2023110052A1 (en) * 2021-12-13 2023-06-22 Nokia Solutions And Networks Gmbh & Co. Kg Frer support using 5g system bridges
CN114326566A (zh) * 2021-12-13 2022-04-12 中国航发北京航科发动机控制系统科技有限公司 一种航发液压产品试验设备的远程集中系统及控制方法
TWI792784B (zh) * 2021-12-20 2023-02-11 國立清華大學 基於聯邦強化學習的邊緣計算卸載優化方法及通信系統
WO2023122576A1 (en) * 2021-12-20 2023-06-29 General Electric Company Network configuration using coupled oscillators
WO2023122654A1 (en) * 2021-12-21 2023-06-29 General Electric Company Disaggregated time-sensitive network (tsn)-based 5g system
US20220311710A1 (en) * 2021-12-22 2022-09-29 Kishore Kasichainula Multi-stream scheduling for time sensitive networking
CN114302402B (zh) * 2021-12-24 2023-05-12 国网福建省电力有限公司 一种基于5g的电力调控业务安全通信方法
WO2023136757A1 (en) * 2022-01-17 2023-07-20 Telefonaktiebolaget Lm Ericsson (Publ) Distribution of data packets for controlling of industrial devices
WO2023141907A1 (zh) * 2022-01-27 2023-08-03 Oppo广东移动通信有限公司 无线通信的方法、终端设备和网络设备
WO2023163924A1 (en) * 2022-02-23 2023-08-31 Qorvo Us, Inc. Fine ranging slot scheduler
CN114527425B (zh) * 2022-02-24 2023-01-10 中国科学院空天信息创新研究院 一种基于数字孪生的矿井人员定位方法
CN114389944B (zh) * 2022-03-01 2023-11-17 重庆邮电大学 一种面向工业应用的时间敏感网络完全分布式配置方法
US11930541B2 (en) * 2022-03-01 2024-03-12 Cisco Technology, Inc. Coordinating best effort traffic to an associationless, overhead mesh of access points
WO2023173321A1 (en) * 2022-03-16 2023-09-21 Qualcomm Incorporated Network assisted application layer federated learning member selection
CN114626868A (zh) * 2022-03-22 2022-06-14 歌尔股份有限公司 智能门铃防盗版方法、系统、智能门铃及可读存储介质
CN116867067A (zh) * 2022-03-23 2023-10-10 华为技术有限公司 通信方法及装置
US20230309136A1 (en) * 2022-03-24 2023-09-28 Microsoft Technology Licensing, Llc Scheduling time-critical data on a radio interface
CN114884557B (zh) * 2022-03-25 2023-07-25 重庆邮电大学 一种基于网络演算的卫星时间敏感网络路径选择方法
US20230319125A1 (en) * 2022-03-29 2023-10-05 Nokia Technologies Oy Two-way delay budget for interactive services
US20230328720A1 (en) * 2022-04-08 2023-10-12 EdgeQ, Inc. Downlink and uplink disaggregation in a radio access network
CN115065646B (zh) * 2022-04-29 2024-04-02 中国电子技术标准化研究院 一种基于软硬件协同的报文定时发送方法及装置
CN114697159B (zh) * 2022-04-29 2024-02-02 中国航空无线电电子研究所 一种在线集中资源规划控制模式下确定性乒乓传输方法
WO2023213418A1 (en) * 2022-05-04 2023-11-09 Lenovo (Singapore) Pte. Ltd Method for supporting deterministic networks in a wireless communications network
WO2023214383A1 (en) * 2022-05-06 2023-11-09 Telefonaktiebolaget Lm Ericsson (Publ) Timing services over cellular communication system mobility
CN114979942B (zh) * 2022-05-12 2023-03-24 煤炭科学技术研究院有限公司 矿用移动通信系统及方法
TWI823408B (zh) * 2022-05-27 2023-11-21 國立成功大學 機械設備雲端控制系統
WO2023228426A1 (ja) * 2022-05-27 2023-11-30 三菱電機株式会社 フレーム伝送システム、５ｇコア装置、５ｇ端末、トランスレータ、フレーム伝送方法、およびフレーム伝送プログラム
CN115002093B (zh) * 2022-05-30 2023-08-29 中国船舶重工集团公司第七二二研究所 一种复杂移动场景下内外远程通信的方法
CN115051938B (zh) * 2022-05-31 2024-02-13 中国电子技术标准化研究院 Opc ua-tsn传输时延测试系统及方法
US11843699B1 (en) * 2022-06-09 2023-12-12 The Government of the United States of America, as represented by the Secretary of Homeland Security Biometric identification using homomorphic primary matching with failover non-encrypted exception handling
WO2023238410A1 (ja) * 2022-06-10 2023-12-14 日本電信電話株式会社 制御装置、制御方法、及びプログラム
EP4297338A1 (en) * 2022-06-20 2023-12-27 Nokia Technologies Oy Automatic certificate management in 5gc network
CN115243359B (zh) * 2022-07-26 2023-05-26 深圳市汇顶科技股份有限公司 一种nb-iot端的时间确定方法、nb-iot芯片、设备及通信系统
TWI811050B (zh) * 2022-08-03 2023-08-01 優式機器人股份有限公司 多台移動機器人協作的控制方法
TWI825896B (zh) * 2022-08-03 2023-12-11 優式機器人股份有限公司 環境整理控制方法
WO2024035005A1 (en) * 2022-08-06 2024-02-15 Samsung Electronics Co., Ltd. Method and apparatus of secure multi-path transmission for proximity services in wireless communication system
CN115243362B (zh) * 2022-09-26 2023-03-28 南方电网数字电网研究院有限公司 一种应用于行波定位装置的时间同步系统及方法
CN116319534A (zh) * 2023-02-20 2023-06-23 重庆邮电大学 一种基于改进frer的无缝冗余传输方法
CN116582855B (zh) * 2023-04-26 2023-10-20 北京科技大学 一种基于深度强化学习的5g-tsn融合网络切片管理方法及系统
CN116760486B (zh) * 2023-08-23 2023-10-13 深圳市飞瑞航空服务有限公司 一种对讲机用自动对频系统和方法
CN117098142B (zh) * 2023-10-18 2023-12-26 济南华科电气设备有限公司 一种基于uwb技术的煤矿井下人员定位方法及系统
CN117674961A (zh) * 2023-11-20 2024-03-08 航天恒星科技有限公司 基于时空特征学习的低轨卫星网络时延预测方法
CN117411792B (zh) * 2023-12-15 2024-02-13 深圳中科德能科技有限公司 智能箱连接发现方法、装置、设备及存储介质
CN117491960B (zh) * 2024-01-02 2024-03-26 精华隆智慧感知科技（深圳）股份有限公司 雷达产品检测方法、装置、设备及介质
CN117556221B (zh) * 2024-01-09 2024-03-26 四川大学 基于智能电气控制交互会话的数据分析方法及系统
CN117808123A (zh) * 2024-02-28 2024-04-02 东北大学 一种基于多中心分层联邦学习的边缘服务器再分配方法

Family Cites Families (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2841247B2 (ja) * 1994-01-21 1998-12-24 コニンクリジケ ピーティーティー ネーダーランド エヌ ブィー 一連のデータパケットをデータ圧縮により変換する方法および装置
US8780885B2 (en) * 2007-07-09 2014-07-15 Qualcomm Incorporated Synchronization of a peer-to-peer communication network
CN102356588A (zh) * 2009-03-16 2012-02-15 瑞典爱立信有限公司 无线通信系统中的方法和配置
US8634313B2 (en) * 2009-06-19 2014-01-21 Qualcomm Incorporated Method and apparatus that facilitates a timing alignment in a multicarrier system
EP3319395B1 (en) * 2010-12-03 2023-05-03 InterDigital Patent Holdings, Inc. Method and apparatus for performing multi-radio access technology carrier aggregation
US9578649B2 (en) * 2011-01-20 2017-02-21 Qualcomm Incorporated Method and apparatus to facilitate support for multi-radio coexistence
CN103002513A (zh) * 2011-09-14 2013-03-27 中兴通讯股份有限公司 一种tsn长度配置方法及系统
US9179397B2 (en) * 2012-08-22 2015-11-03 Qualcomm Incorporated Wireless local area network discovery using non-WLAN timing reference
KR102058563B1 (ko) * 2013-08-07 2019-12-24 인터디지탈 패튼 홀딩스, 인크 디바이스 대 디바이스 통신을 위한 분산형 스케줄링
CN104811997B (zh) * 2014-01-26 2019-07-05 中兴通讯股份有限公司 用户设备的配置状态管理方法、无线网络控制器及基站
US20160295426A1 (en) * 2015-03-30 2016-10-06 Nokia Solutions And Networks Oy Method and system for communication networks
EP3289805A1 (en) * 2015-04-27 2018-03-07 Nokia Solutions and Networks Oy Providing service
US10536914B2 (en) * 2016-09-22 2020-01-14 Qualcomm Incorporated Synchronizing a 5G communication channel using a 4G timing synchronization parameter
US20180132234A1 (en) * 2016-11-09 2018-05-10 Dave Cavalcanti Enhanced wireless networks for time sensitive applications
EP3944642A1 (en) * 2016-12-21 2022-01-26 Telefonaktiebolaget LM Ericsson (publ) Support of circuit switched service in a 5g core network
US10425321B2 (en) * 2017-04-25 2019-09-24 Keysight Technologies Singapore (Sales) Pte. Ltd. Methods, systems, and computer readable media for testing time sensitive network (TSN) elements
CN108810979B (zh) * 2017-04-28 2023-05-16 华为技术有限公司 系统信息的传输方法及终端设备、网络设备
US10979368B2 (en) * 2017-08-02 2021-04-13 Nebbiolo Technologies, Inc. Architecture for converged industrial control and real time applications
US11233594B2 (en) * 2017-12-19 2022-01-25 Qualcomm Incorporated Time synchronization for wireless communications
US11368972B2 (en) * 2018-02-14 2022-06-21 Qualcomm Incorporated Receiver-side buffering for time-aware scheduling across cellular link
EP3815418A1 (en) * 2018-06-26 2021-05-05 Nokia Technologies OY Methods and apparatuses for enhanced data packet flow handling in communications systems
US11297541B2 (en) * 2018-08-17 2022-04-05 Qualcomm Incorporated Signaling timing information for a time sensitive network in a wireless communications system
DE102018214144A1 (de) * 2018-08-22 2020-02-27 Robert Bosch Gmbh Verfahren zum Verbinden einer Maschine mit einem drahtlosen Netzwerk
US11304092B2 (en) * 2018-09-12 2022-04-12 Ofinno, Llc Session packet duplication control
US10785082B2 (en) * 2018-09-19 2020-09-22 Solid, Inc. Distributed antenna system-based on time sensitive network
ES2910997T3 (es) * 2018-09-21 2022-05-17 Ericsson Telefon Ab L M Métodos y aparato para planificar recursos en redes de acceso por radio
US11172397B2 (en) * 2018-10-15 2021-11-09 Qualcomm Incorporated Timing information for multiple periodic traffic streams sharing a same quality of service
WO2020081060A1 (en) * 2018-10-16 2020-04-23 Nokia Technologies Oy. Synchronization in wireless networks for supporting ieee tsn-based industrial automation
US20200229055A1 (en) * 2019-01-11 2020-07-16 Institute For Information Industry Base station and user equipment for mobile communication system

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
Ericsson，Analysis of Time Synchronization Accuracy over Uu Interface[online]，3GPP TSG RAN WG1 adhoc_NR_AH_1901，3GPP，2019年01月25日，R1-1901353，検索日[2022.08.30],Internet<URL:http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_AH/NR_AH_1901/Docs/R1-1901353.zip>
Nokia, Nokia Shanghai Bell，TSN Time Synchronization[online]，3GPP TSG RAN WG3 #102，3GPP，2018年11月16日，R3-186705，検索日[2022.08.30],Internet<URL:https://www.3gpp.org/ftp/tsg_ran/WG3_Iu/TSGR3_102/Docs/R3-186705.zip>

Also Published As

Publication number Publication date
BR112021015413A2 (pt) 2021-10-05
TWI791950B (zh) 2023-02-11
ZA202106710B (en) 2022-08-31
TW202135580A (zh) 2021-09-16
EP3925239A2 (en) 2021-12-22
WO2020167222A3 (en) 2020-10-15
EP3925239B1 (en) 2022-07-06
DK3925239T3 (da) 2022-08-01
JP2022522630A (ja) 2022-04-20
CO2021008919A2 (es) 2021-10-29
KR20210122289A (ko) 2021-10-08
TWI770803B (zh) 2022-07-11
ES2928297T3 (es) 2022-11-16
CN113615239A (zh) 2021-11-05
PL3925239T3 (pl) 2022-11-07
EP4109937A1 (en) 2022-12-28
EP4109937C0 (en) 2024-01-31
SG11202106332XA (en) 2021-07-29
US20200259896A1 (en) 2020-08-13
MX2021009432A (es) 2021-09-10
TW202037208A (zh) 2020-10-01
KR102547760B1 (ko) 2023-06-23
EP4109937B1 (en) 2024-01-31
WO2020167222A2 (en) 2020-08-20

Similar Documents

Publication Publication Date Title
JP7241899B2 (ja) ５ｇ以降を用いた産業自動化
US11736942B2 (en) Multi-domain trust establishment in edge cloud architectures
Ahmadi 5G NR: Architecture, technology, implementation, and operation of 3GPP new radio standards
US20220014963A1 (en) Reinforcement learning for multi-access traffic management
US11244242B2 (en) Technologies for distributing gradient descent computation in a heterogeneous multi-access edge computing (MEC) networks
US11423254B2 (en) Technologies for distributing iterative computations in heterogeneous computing environments
US20220038902A1 (en) Technologies for radio equipment cybersecurity and multiradio interface testing
US20220232423A1 (en) Edge computing over disaggregated radio access network functions
KR20220092366A (ko) 하이브리드 에지 컴퓨팅 플랫폼에서의 보안 듀얼 모드 에지 애플리케이션 프로그래밍 인터페이스 소비를 위한 상호운용가능한 프레임워크
5G PPP Architecture Working Group View on 5G Architecture: Version 2.0
US11019157B2 (en) Connectionless service and other services for devices using microservices in 5G or other next generation communication systems
US20220345417A1 (en) Technologies for configuring and reducing resource consumption in time-aware networks and time-sensitive applications
US20230006889A1 (en) Flow-specific network slicing
CN116112110A (zh) 用于补偿时钟漂移引起的时间同步中的错误的技术
CN117897980A (zh) 无线接入网智能应用管理器
WO2023215720A1 (en) Authorization and authentication of machine learning model transfer
Muzaffar et al. 5g deployment models and configuration choices for industrial cyber-physical systems–a state of art overview
US20220369067A1 (en) Automated cell azimuth estimation and validation
US11297594B2 (en) Automated cell location estimation and validation
OA20434A (en) Wireless time-sensitive networking
US20230388871A1 (en) Mobility features for next generation cellular networks
WO2023215771A1 (en) Authentication and authorization for localized services
WO2023227955A1 (en) Enabling cellular based zero trust network access

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20211025

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20210817

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20211025

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20220906

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20221205

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20230104

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20230221

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20230307

R150 Certificate of patent or registration of utility model

Ref document number: 7241899

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150