(57)【要約】  任意の現場において、任意の規模で、SNP/ACPカバレージまたはビームモビリティとは無関係に、全部の需要および供給を含む衛星ベースのアクセス設備のより広い視野を提供する、衛星ベースのインターネットアクセスおよびトランスポートのための改良されたシステムおよび方法および技法が開示される。したがって、本開示の態様による方法およびシステムは、有利には、予測可能かつ地理空間的に計算可能な供給モデルに対してIPサービス(需要)を寸法決定し、配備し、したがって、(すなわちARは)いずれもその任意のCA(供給)エリアにおいて所望のしきい値を超えてオーバーサブスクライブされない。
2019518345.tif 000002
【特許請求の範囲】
【請求項１】
地球低軌道(LEO)衛星コンステレーションを介して地上グラウンドネットワーク(GN)に接続された複数のユーザ端末(UT)を含む、衛星ベースのインターネットアクセスおよびトランスポートネットワークのための承認制御システムであって、前記GNが、コアネットワーク(CN)にさらに接続され、前記CNが、インターネットに接続され、前記承認制御システムが、
前記UT、前記GN、前記LEO、および前記CNに関するステータス情報を提供するように構成されたグローバル連合データベースと、
サービス加入者がサービスの存続期間の間に衛星ベースのネットワークにアクセスすることを常に承認するように構成された静的承認制御コンポーネントと、
サービス加入者がセッションベースのサービス品質(QoS)承認のために衛星ベースのネットワーク処理システムにアクセスすることを選択的に承認するように構成された動的承認制御コンポーネントと
を備え、
前記承認制御システムが、UTによって要求される任意のサービスレベル(SL)に違反しないように、独立したスケジュールを各々が有するビームの移動するセットを含む前記インターネットおよびトランスポートネットワークへのアクセスを提供するように構成されている、システム。
【請求項２】
前記静的承認制御コンポーネントが、別段特別なキャリッジのために分類されていない限り、IPトラフィックフローのセットを処理する基本データサービス(BDS)を提供するようにさらに構成され、所与の時点でUTごとにアクティブなBDSが1つだけ存在する、請求項1に記載のシステム。
【請求項３】
前記UTが位置に固定され、そのサービス領域(SR)が、当該SR内の衛星スポットビームの幅および高さの実質的に2倍を測定する承認制御ゾーン(ACZ)であり、前記SRが、サービスクラス(SC)を可能にするUTが動作し、容量を消費するエリアである、請求項2に記載のシステム。
【請求項４】
複数のサービスプロバイダエンタープライズポータルと通信するように構成されたエンタープライズポータルインターフェースをさらに備える、請求項3に記載のシステム。
【請求項５】
前記サービスプロバイダエンタープライズポータルとアクセスコントローラとの間に介在するオペレーションサポートシステムをさらに備える、請求項4に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、2016年3月24日に出願された米国仮特許出願第62/312,969号の利益を主張するものであり、その内容全体は、本明細書に詳細に記載されているかのように参照により組み込まれる。
【０００２】
本開示は、一般に電気通信に関する。より詳細には、本開示は、衛星ベースのインターネットアクセスおよびトランスポートのための承認制御に関する。
【背景技術】
【０００３】
インターネットの普及が増加し、今日の生活に日々影響を与え続けるにつれて、インターネットへのアクセスがますます重要なものになっている。容易に認識されるように、地上であろうと空中であろうと、特定の位置はしばしば、即座のアクセスを難しくしている。これらの困難なアクセス位置の1つのアプローチは、衛星ベースのインターネットアクセスを含み、その魅力は、インターネットの普及とともに増加している。したがって、そのような衛星ベースのインターネットアクセス設備の配備およびその後の管理を容易にするシステム、方法、および技法は、当技術分野への望ましい追加である。
【発明の概要】
【課題を解決するための手段】
【０００４】
有利には、任意の現場において、任意の規模で、衛星ネットワークポータル(SNP)/アンカー共通ポイント(ACP)カバレージまたはビームモビリティとは無関係に、全部の需要および供給を含む衛星ベースのアクセス設備のより広い視野を提供する、衛星ベースのインターネットアクセスおよびトランスポートのための承認制御システムを対象とする本開示の態様によれば、当該分野において進歩がもたらされる。したがって、本開示の態様による方法およびシステムは、有利には、予測可能かつ地理空間的に計算可能な供給モデルに対してIPサービス(需要)を寸法決定し、配備し、したがって、(すなわちARは)いずれもその任意のCA(供給)エリアにおいて所望のしきい値を超えてオーバーサブスクライブされない。
【０００５】
より具体的には、本開示は、地球低軌道(LEO)衛星コンステレーションを介して地上グラウンドネットワーク(GN)に接続された複数のユーザ端末(UT)を含む、衛星ベースのインターネットアクセスおよびトランスポートネットワークのための承認制御システムについて記載し、GNは、コアネットワーク(CN)にさらに接続され、CNは、インターネットに接続され、承認制御システムは、UT、GN、LEO、およびCNに関するステータス情報を提供するように構成されたグローバル連合データベース(globally federated database)と、サービス加入者がサービスの存続期間の間に衛星ベースのネットワークにアクセスすることを常に承認するように構成された静的承認制御コンポーネントと、サービス加入者がセッションベースのサービス品質(QoS)承認のために衛星ベースのネットワーク処理システムにアクセスすることを選択的に承認するように構成された動的承認制御コンポーネントとを含み、承認制御システムは、UTによって要求される任意のサービスレベル(SL)に違反しないように、独立したスケジュールを各々が有するビームの移動するセット(moving set of beams)を含むインターネットおよびトランスポートネットワークへのアクセスを提供するように構成されている。
【０００６】
本概要は、本明細書において以下にさらに記載される本開示のいくつかの態様を簡単に識別するために提供される。本概要は、本開示の鍵となるまたは本質的な特徴を識別するものではなく、いかなる請求項の範囲をも限定しないものとする。
【０００７】
「態様」という用語は、「少なくとも1つの態様」と解釈されるものとする。上述した態様および本開示の他の態様は、例として示されており、添付の図面に限定されるものではない。
【０００８】
本開示のより完全な理解は、添付の図面を参照することによって実現され得る。
【図面の簡単な説明】
【０００９】
【図１】本開示の態様による例示的なネットワークアーキテクチャを示す概略図である。
【図２】本開示の態様による単一の衛星スポットビームカバレージを示す概略図である。
【図３】本開示の態様によるUTトラフィック需要を示すプロットである。
【図４】本開示の態様による承認制御ゾーンを示すプロットである。
【図５】本開示の態様によるVBR需要面を示すプロットである。
【図６】本開示の態様による25Mbpsの需要を示すプロットである。
【図７Ａ】本開示の態様によるVBR需要面を示すプロットである。
【図７Ｂ】本開示の態様によるVBR需要面を示すプロットである。
【図８】本開示の態様による容量面を示すプロットである。
【図９Ａ】本開示の態様によるVBR容量-需要面を示すプロットである。
【図９Ｂ】本開示の態様によるVBR容量-需要面を示すプロットである。
【図１０】本開示の態様による市場容量分割(Market Capacity Splits)、SNPカバレージおよびビームを示す概略ブロック図である。
【図１１】本開示の態様による承認制御システムを示す概略ブロック図である。
【図１２】本開示の態様によるサービス領域を示すプロットである。
【図１３Ａ】本開示の態様によるGBR容量面を示すプロットである。
【図１３Ｂ】本開示の態様によるGBR容量面を示すプロットである。
【図１４Ａ】本開示の態様によるVBR需要面を示すプロットである。
【図１４Ｂ】本開示の態様によるGBR需要面を示すプロットである。
【図１５Ａ】本開示の態様によるオーバーサブスクライブされるVBR需要面を示すプロットである。
【図１５Ｂ】本開示の態様によるオーバーサブスクライブされないGBR需要面を示すプロットである。
【図１６】本開示の態様によるACZ重複およびGBR空間需要を示す概略ブロック図である。
【図１７Ａ】本開示の態様によるトリプルACZ重複を示す概略図である。
【図１７Ｂ】本開示の態様によるトリプルACZ重複を示すプロットである。
【図１８】本開示の態様によるGBR需要プラトーを示すプロットである。
【図１９Ａ】本開示の態様による利用可能なGBR容量面を示すプロットである。
【図１９Ｂ】本開示の態様による利用可能なGBR容量面を示すプロットである。
【図２０Ａ】本開示の態様による理想的なVBR容量面を示すプロットである。
【図２０Ｂ】本開示の態様による理想的なVBR容量面を示すプロットである。
【図２１Ａ】本開示の態様による利用可能なGBR容量VBR面を示すプロットである。
【図２１Ｂ】本開示の態様による利用可能なGBR容量VBR面を示すプロットである。
【図２２】本開示の態様による理想的なVBR-GBR容量デルタ面を示すプロットである。
【図２３】本開示の態様によるネットワーク寸法決定を示す概略ブロック図である。
【図２４】本開示の態様によるUT/SC承認およびプロビジョニングを示す概略ブロック図である。
【図２５】本開示の態様によるUT接続/SCアクティブ化を示す概略ブロック図である。
【図２６】本開示の態様による、方法を実行するために使用され得る、またはシステムの一部として統合され得るコンピュータシステムを示す概略ブロック図である。
【発明を実施するための形態】
【００１０】
以下は単に本開示の原理を示すものである。したがって、当業者は、本明細書に明示的に記載または図示されていないが、本開示の原理を具体化し、その意図および範囲内に含まれる様々な構成を考案することができることを諒解されよう。より具体的には、数多くの具体的な詳細が記載されているが、本開示の実施形態は、これらの具体的な詳細なしに実施されてもよく、他の例では、よく知られている回路、構造、および技法は、本開示の理解を不明瞭にしないために示されていないことを理解されよう。
【００１１】
さらに、本明細書に詳述されるすべての例および条件付き言語は、主に、明確に、読者が本開示の原理および本技術を促進するために発明者によって貢献される概念の理解を援助するための教育のためのものにすぎず、そのような特に詳述された例および条件に限定されないものと解釈されるものとする。
【００１２】
さらに、本開示の原理、態様、および実施形態、ならびにその具体的な例を詳述する本明細書におけるすべての記述は、その構造的均等物と機能的均等物の両方を包含するものとする。さらに、そのような均等物は、現在知られている均等物と将来開発される均等物の両方、すなわち、構造にかかわらず、同じ機能を果たす任意の開発された要素を含むものとする。
【００１３】
したがって、たとえば、本明細書の図が本開示の原理を具体化する例示的な構造の概念図を表すことは、当業者には諒解されよう。
【００１４】
さらに、任意のフローチャート、フロー図、状態遷移図、疑似コードなどは、コンピュータ可読媒体において実質的に表され得、コンピュータまたはプロセッサが明確に示されるかどうかにかかわらず、そのようなコンピュータまたはプロセッサによってそのように実行され得る、様々なプロセスを表すことは、当業者には諒解されよう。
【００１５】
本明細書の特許請求の範囲において、指定された機能を実行するための手段として表される任意の要素は、たとえば、a)その機能を実行する回路要素の組合せ、またはb)したがって、機能を実行するためにそのソフトウェアを実行するための適切な回路と結合された、ファームウェア、マイクロコードなどを含む任意の形態のソフトウェアを含む、その機能を実行する任意の方法を包含するものとする。そのような請求項によって定義される本発明は、様々な列挙された手段によって提供される機能が、請求項が要求する方法で組み合わされ、まとめられているという事実にある。したがって、出願人は、それらの機能を提供することができる任意の手段を、本明細書に示されるものと均等とみなす。最後に、本明細書に特に明記しない限り、図面は一定の縮尺で描かれていない。
【００１６】
何らかの追加の背景として、OneWebが、より広いインターネットへのアクセスをインターネットプロトコル(IP)デバイスに提供するインターネットアクセスおよびトランスポートネットワークに与えた名前であることに言及することから始める。この意味で、OneWebは、光ファイバ、ケーブル、セルラー通信を含む他の既知のインターネットアクセス通信技術と同様なものと見なされ得る。しかしながら、当業者には容易に明らかになるように、そのアクセスネットワークトポロジは特にユニークである。
【００１７】
より具体的には、従来のネットワークインフラストラクチャシステムおよびアーキテクチャは、固定ユーザとモバイルユーザの両方にサービスを提供する固定のインフラストラクチャを有することに言及する。OneWebトポロジでは、ネットワークインフラストラクチャ自体の本質的な部分である衛星はモバイルである。示すように、この差は、エアインターフェースリソース管理のいくつかの側面をかなり変える。
【００１８】
次に図1を参照すると、本開示の態様によるネットワークアーキテクチャを示す概略図が示されている。より具体的には、その図1から観測され得るように、いくつかのユーザ端末(UT)は、低地球軌道(LEO)衛星コンステレーションを介して地上グラウンドネットワーク(GN)に接続する。本明細書で使用されるUTは、しばしば、顧客構内機器(CPE)アクセスデバイスであり、なじみのあるケーブルモデムまたは他のモデムにいくらか類似した方法でネットワークへのアクセスを提供する。IPホストデバイス(ユーザデバイス(UD)として示される)は、Ethernet、Wi-Fi、LTEなどを含むいくつかの既知の通信技術のうちのいずれかの効果を介してUTに接続され、そのUTは、次いで、OneWebシステムを介してホストをインターネットに接続する。
【００１９】
ある高レベルの抽象化において、図1に示されるOneWebシステムアーキテクチャは、ロングタームエボリューション(LTE)セルラーパケット無線アクセスを支える3GPPエボリューションパケットシステム(EPS)に関連付けられるアーキテクチャといくつかの類似点を有する。特に、当業者には容易に理解されるように、LTEは、発展型ノードB(eNB-セルラー基地局)に接続するユーザ機器(UE)デバイス(結合ホスト/モデムデバイス)を使用し、発展型ノードBは、次いで、図1に示すように、EPC(発展型パケットコア)に接続し、次いでインターネットに接続する。類似点は明らかに見え得るが、上述したように、エアインターフェース管理に関する詳細は著しく異なる。
【００２０】
周知の従来のセルラーアーキテクチャであるLTEでは、各eNBは、しばしば「セル」と呼ばれるあらかじめ定義された静的なカバレージエリアにわたってエアインターフェース機能を提供する。動作中、セルは、サイズ、形状、および容量においてしばしば異なる。セル内のUEは、eNBの制御下でエアリソース容量を消費する。UEが所与のサービス需要(すなわち、電話呼)を満たすためのリソースを要求すると、UEは、その要求が「承認可能」であるかどうかを決定するために動的なセッションベースの承認制御(AC)手順に着手する。呼を提供するのに十分な容量がセル内にある場合、進めることが許可される。そうでない場合、要求は拒否される。LTEでは、所与のeNBは、常にそのエリア内のすべてのUEについて、所与のカバレージにわたって容量を制御する。これは、十分な容量供給(容量)および需要(トラフィック負荷)情報を有し、したがって、AC決定を行うのに良好な位置にある。そのようなことは、衛星ベースのOneWebシステムではしばしば当てはまらない。理由を理解するためには、GNの構成および機能を調べなければならない。
【００２１】
今や当業者には理解されるように、GNは、OneWeb Service WAN(ワイドエリアネットワーク)またはSWANによって分離された2つの構成要素、衛星ネットワークポータル(SNP)とアンカー共通ポイント(ACP)とを含む。各SNPは、衛星ビームスケジューリングを処理する多くの要素、最も顕著には、LxP/BxPの組合せを含む。際立って対照的に、ACOは、CNへの固定eNBとして、GN全体を表す唯一のエンティティである。
【００２２】
衛星の移動、UTをカバーするサービスビームの移動、SNPに接続されたフィーダリンクの移動、およびCNからビーム、リンク、衛星の動きを隠す対応する必要性のために、SNP-ACPの分離は必要である。
【００２３】
次に図2を参照すると、本開示の一態様による衛星スポットビームカバレージを示す概略図が示されている。理解できるように、衛星は極軌道にある。SNPは、回転している地球上にあり、それらがサービスするUTの多くがそうである(一部は飛行しているかもしれない)。すべてが衛星と比較して非常にゆっくり動いている。したがって、UTの位置に依存して、そのカバーする衛星は、主に北または南に移動している。
【００２４】
インドのUTをカバーする北に行く衛星の近似経路が図2に示されていることに言及する。各衛星は、16個の長方形のスポットビームをそれに関連付けている。新しいスポットビームは、所与のUTをおよそ11秒ごとに通過する。地球が回転しており、UTも西東方向に歳差運動しているので、スポットビームも地球の表面を横切って東西方向にゆっくり移動する。さらに、スポットビームの東西幅を移動するには約40分かかることに留意されたい。図2に示した点線は、西にわずかに移動するにつれて、北に行く衛星の近似経路を示す。
【００２５】
諒解されるように、各UTは、任意の時点に一意の位置を占有する。各UTは、その位置からトラフィックを送受信し、逆方向リンクと順方向リンクの両方でエアインターフェース容量についての「需要」を生成する。複数のUTは、図3に概略的に示すように、所与のエリアにわたって広がり、ここでは、10、30、および50Mbps可変ビットレート(VBR)トラフィック需要の評価が示されている。
【００２６】
本開示による衛星システムのための1つの主なシステム要件は、所与のエリアにおけるトラフィック需要が許容範囲内に維持されることである。この要件に対する1つの簡単なアプローチは、図3に示すように、点別(point-wise)(位置別)の需要を単純に合計し、次いで、それを容量と照合調整することを含む。しかしながら、残念なことに、エアインターフェース容量は、ビーム内で共有され、したがって、同じビーム内に存在する可能性がある2つのUTは、時間の経過とともに互いの利用可能な容量に影響を及ぼす。結果として、時間の経過に伴うスポットビームの動きのダイナミクスのために、1対のUTの相対的位置がビームを共有する時間の割合を決定し、したがって、ビームの能力について競合する時間の相対的割合を決定する。これは、ここで説明するゾーン全体にわたるUT需要の地理空間分布と呼ぶことになる。
【００２７】
各UTを囲むことは、衛星スポットビームの幅および高さの実質的に2倍を測定する、その承認制御ゾーン(ACZ)と呼ばれるほぼ矩形のゾーンであることに留意されたい。さらに、これは低い緯度では一般に当てはまるが、より高い緯度では、ACZの形状は、ビームの重なりに起因して変わるが、同じ概念が適用されることに留意されたい。
【００２８】
UT「X」の周りのACZのトップダウン図が図4に図式的に示されている。示されるこのACZは、VBR容量とGBR容量の両方に適用される。ビームが名目上1000×70kmの矩形である場合、ACZは、約2200×140kmである。aCZは、UT Xの容量需要がそのACZ内の他のUTに利用可能な容量供給に影響を及ぼし得る(すなわち、そこから減じる)地理的エリアを表す。したがって、これは、反射関係である。
【００２９】
この点で、VBR需要について、UTのトラフィック需要の確率密度関数(PDF)がACZにわたって3D需要面を形成し、これは、図5に3Dグラフとして、ならびにその正面図と側面図の2Dグラフである図4の上半分に示されていることに言及する。UTがそのACZから消費する(または必要とする)容量は、ビームの形状および動きによって決定される統計的関数である。より具体的には、ACZの内部にある所与の位置Yがその定義するUT X(ACZの中央)に近いほど、Yの位置におけるUT Xからの容量についての統計的需要が高くなる。
【００３０】
観測され得るように、VBR面の形状は、「鮫ひれ」形状を有する細長いピラミッドに似ている(正確には幾何学的に言うピラミッドではないが)。表面にはその側面に沿って三角形が持ち上がっており、中心に向かって移動するにつれて壁の斜面の急勾配/屈曲がある。
【００３１】
当然ながら、需要の強い東西の空間相関がある。南北の相関は、形状は同じであるが、ここでも、密度関数を作り出すビームの狭さに起因して、大きさは減少する。図5に示す表面の「高さ」は、オーバーサブスクライブされない25Mbpsの点源のVBR需要(OneWebシステムについての比較的大きい需要)に対応する。しかしながら、すべてのVBR需要はある程度オーバーサブスクライブされることが予想され、これによって、後で示すように、寸法決定のために実効レートが低下する。
【００３２】
ここでの議論では、澄んだ空の400Mbpsのビーム容量を仮定する。400Mbpsのビーム容量の文脈における25MbpsのACZ需要面の相対的サイズが、図6に示されており、一見すると、小さい需要であるように見えるが、オーバーサブスクリプション率>1でさらに小さくなる。
【００３３】
図3の図:UTトラフィック需要のポイント需要を対応するACZ需要面に変換することによって、VBR需要面を示すプロットである、図7(A)および図7(B)に示されるように、エリアにわたる総VBR需要面が生成される。最大(「最高」の)IPサービスレートが図7(A)に示されており、オーバーサブスクリプション率100を反映する、「縮小された」実効速度ベースのプロビジョニングレートが図7(B)に示されている。いくつかの個々の形状は、標準的なACZ需要面形状とは異なることがわかり、これは、複数の部分的に重なるACZ面がVBR需要面を作り出すからである。
【００３４】
需要面に対する「裏側」が、地理空間的に利用可能な容量を示す、容量面のグラフである図8に示されていることに留意されたい。図8のこの単純化した(すなわち一様な)グラフは、400Mbpsの点別の「澄んだ空」ビーム容量を示す。澄んだ空の容量は雨がないことを前提としており、VBR需要が寸法決定される容量である。表面に沿った点別容量は、この領域で利用されている任意のトラフィック需要が空になる前のビームのものを反映している。すでにわかったように、ここでの表面は個々のACZよりも大きい。
【００３５】
次に図9(A)および図9(B)を参照すると、需要を減じた供給(supply less demand)の2つの図(左右)が示されている。これらの図9(A)および図9(B)を参照すると、ランダムに配置された10、30、および50MbpsのVBR需要のセットが示されていることが観測され得る。これらは、容量を減じた面からの、部分的に重なる点別需要面のセットを作成する。前に提示したように、図9(A)は顧客が実際に感じる最大IPサービスレートを示し、図9(B)はオーバープロビジョニング率100で消費される実効レートを示す。図9(B)のみが、速度ベースの承認制御プロビジョニング計算において考慮される。最大(総)需要が63Mbpsを超えることはなく、これは、複数の需要面の最大点別総計(100のオーバーサブスクリプション率では0.63Mbps)であり、したがって、エリア内の任意の位置の利用可能な容量は、>=399.37Mbpsであるので、ここでは十分な容量が残存している(図9(B))。そのため、これは、非常に軽負荷なエリアの一例である。
【００３６】
この点で、承認制御システムの主な目的は、述べるように、点別の空き容量がどこでもゼロを下回らないことを確実にすることであることに言及し、強調する。
【００３７】
当業者によって容易に諒解されるように、承認制御問題は、管理領域(AR)とSNPカバレージエリアとビームエリアとの相対的なサイズのために、より困難になり、その一例が、市場容量分割、SNPカバレージ、およびビームを示す図10に示される。
【００３８】
管理領域(単に図10に四角で示されている)は、1つまたは複数のサービスプロバイダ(SP)(すなわち、OneWeb)がAR全体にわたって容量割振り(CA)を取得した可能性のある四角内の連続した重ならない地理的エリア(たとえば国)を表す。一般に、サービスプロバイダディストリビュータキャップは、OneWebディストリビュータパートナーがサービスを提供するARの容量の%である。
【００３９】
SNPカバレージエリア(図中)は、1つまたは複数のARをカバーする重なる地理的エリアを表す。SNPカバレージエリアは大きい楕円であり、不均一であり、しばしばAR全体よりも大きいが、(たとえば、シベリアを想像する)いくつかの大きいARの一部のみを含むこともある。
【００４０】
図10に関してさらに、ビーム(細長い矩形)も多くのARに比べて大きく、しばしば所与の時間に複数をカバーすることに留意されたい。最も重要なことに、ビームはまた、期せずして、最小の(すなわち最も制限された)スケジューリング可能なエアリンクリソースであり、そのため、様々なARにおけるCAに分割され、次いで、様々なSPのUTのIPサービス間でさらに分割されなければならないビーム容量である。また、ビームが移動(南北)しており、歳差運動(東西)しているので、理論的容量(供給)は(多かれ少なかれ)固定のままであるが、瞬間的な負荷(需要)は、UTが各ビームに入ったりそこから離れたりすると変わる。複数のARがカバーされる場合、それらの相対的なわずかな供給容量(SP間で分割された)も変わり得る。
【００４１】
今や当業者であれば容易に理解されるように、「セル内セッションベース」のACプロセスの従来のワイヤレスアプローチは、当面のタスクに適さない。より具体的には、以下の点に関する。
【００４２】
LxP/BxP:LxP/BxPによって制御される各ビームは事実上「セル」であるが、各ビームは、現在のIPトラフィック需要情報を迅速に無関係にするほど速く動いている(新しいUTがビームに連続的に出入りするので)。「セル内」ビューは、有用な決定を下すには、あまりに近視眼的で動的すぎる。
【００４３】
SNP:SNPは、しばしば、相互のカバレージエリアの重なり、およびビームカバレージのダイナミクスに起因して、AC決定を行うための十分な需要および供給情報を有していないことが多い。多くのUTは、実際には、衛星の動きに応じてSNP間で「ピンポン」(すなわち、ハンドオフ)しており、どのSNPが実際にUTを所有しているかに関する質問を提起する(その答えはどちらでもない)。
【００４４】
ACP:EPCの観点から「基地局」として機能するACPは、おそらくAC決定を行うのに最適なインフラストラクチャ要素である。モビリティを無視し、それらがサービスするUTのセットは一定である。それでも、視野があまりにも限られており、絶え間なく変化するビーム需要を有するBxPの絶え間なく変化する負荷を絶えずやりくりしている。さらに、各ビームの容量は同じである。したがって、実質的に同じリソース(後続のビーム)に対する同じトラフィックについての同じ承認制御決定を繰り返し行う(および再び行う)ことは冗長である。
【００４５】
エアインターフェースリソース管理のこの問題を解決するには、すべてのAR、ビーム、SNP、およびACPにわたって見ることができ、任意の現場において、任意の規模で、SNP/ACPカバレージまたはビームモビリティとは無関係に、全部の需要および供給を認識することができる「より広い」視野が必要である。したがって、本開示の態様による方法およびシステムは、有利には、いずれも(すなわちAR)がそのCA(供給)エリアのいずれかにおいて所望のしきい値を超えてオーバーサブスクライブされないように、予測可能かつ地理空間的に計算可能な供給モデルに対してIPサービス(需要)を寸法決定し、配備する。
【００４６】
承認制御システム
今や当業者であれば容易に理解されるように、グローバル承認制御機能が必要であり、示すように、図11に概略的に示されるような(ACS)によって、本開示に従って実現される。理解されるように、ACSは、グローバルリソース管理システム(GRNS)内で機能し、グローバルネットワーク運営センター(GNOC)に、配備されたUTのグローバルビューと、それらの一致したプロビジョニングされたアクティブなサービスクラス(SC)トラフィック需要とを提供する。ACSの物理的実現は、グローバル連合データベースを含み得るが、その管理面は、ローカルでのみ効力を発する。連合データベースのローカル部分は、他のPOP要素と並んで、選択されたポイントオブプレゼンス(POP)位置に存在することがあり、または、GNOCにホストされることもある。
【００４７】
OneWeb POPは一般に、GNの「上側」部分(すなわちACP)、およびローカルなCN構成要素(すなわち、モビリティ管理エンティティ(MME)、およびサービング/パケットGW(S/P-GW))を含むと理解されることに留意されたい。GRMS-ACSデータベースの物理的な構成および位置にかかわらず、GNOCは、データベースシステムに「グローバルなビューポータル」を有し、任意の範囲および解像度で、統合された閲覧可能なものとしてそれを知覚する。
【００４８】
さらに、ACSは、リソース管理動作の2つの主なモード、すなわち「静的」および「動的」承認制御モードを有することに留意されたい。
【００４９】
静的承認制御
【００５０】
インターネットアクセスサービスは、典型的には、「ビットパイプ」をサービス加入者に販売することを伴う。各パイプは、サービス(一般にその帯域幅およびレイテンシの特性を含む)に関連付けられた(QoS)サービス品質パラメータ、および使用量ベース(たとえばトン数)または性能ベース(すなわち速度)とすることができる、その料金設定のモデル(tariffing model)に応じて異なり得る。技術的観点から、各データサービスは、OneWebエアインターフェース上でその速度(すなわちデータレート)、レイテンシ、および他の性能パラメータを指定するQoS定義であるIPサービスクラス(SC)によって実現される。各SCには、IPレベルでの優先QoS処理を示す対応するPHB(Differentiated Services Per-Hop Behavior)パラメータが関連付けられている。
【００５１】
OneWebは、トランスポートクラスIP QoSフレームワークアーキテクチャ仕様内で説明されているように、IPサービスクラスが定義され得るいくつかの基本的なIPトランスポートクラスを提供する。これらは、サービスの3つの基本形態を作成するのに適している。
【００５２】
完全優先転送サービス:音声またはビデオ会議などの用途に適する。
【００５３】
基本データサービス:従来の様々なIPアクセスサービスに適する。
【００５４】
レイテンシ耐性サービス(Latency-tolerant Service):断続的な接続を利用するマシンツーマシンの用途に適する。
【００５５】
基本データサービス(BDS)は、別段特別な(非基本的な)キャリッジのために分類されていない限り、IPトラフィックフローのセットを処理するものである。所与の時点でUTごとにアクティブなBDSが1つだけ存在する。各OneWeb BDSは、最大ビット(MBR)パラメータと、随意に、次の関係、0≦GBR≦MBRを一緒に満たす(GBR)パラメータを有するハイブリッドSCを含む。これによって、OneWebは、純粋に「ベストエフォート型」のデータサービス(たとえば、この場合、0=GBR<MBR)、従来の電話会社の「専用回線」サービス(この場合、0<GBR=MBR)、および最大ビットレートの調整可能な部分が常に利用可能であることが保証されるフレキシブルに融和される混合(すなわち、0<GBR<MBR)を提供することができる。これらは、それぞれVBR(可変ビットレート)、GBR(保証ビットレート)、およびハイブリッドVBR/GBRサービスと呼ばれる。
【００５６】
BDSは、ひとたび配備されると、「静的」(すなわち、ひとたびプロビジョニングされると変わらない)および「常時オン」である。そのようなサービスを提供することは、限られた容量のシステムに影響を与える。本質的に、常時オンのサービスを「オフ」にすることはできない。承認制御の観点から考えると、ひとたび常時オンのSCが配備されると、そのようなSCのアドミタンスの質問に対する回答は、サービスの存続期間を通じて、およびSCのサービス領域(SR)を通じて、常に「はい」でなければならない。この記載は、サービスされたエンティティが固定である場合(たとえば、家庭)またはモバイル(たとえば、旅客機)である場合に成り立つ。サービス領域は、SCを有効にするUTが動作し、そこから容量を消費するエリアである。固定のUTは1つのARから容量を消費する。モバイルUTは、1つまたは複数のARから容量を消費し得る。UTは、各AR内の一部のCAから容量を消費する。
【００５７】
このすべては、配備の前に(および場合によっては販売時点においても)、SPによってACチェックが実行されなければならないということを必要とする(図11でわかるように、エンタープライズ先行ポータル(EP)をOSS経由でACSに使用して、SCの存続期間中に予想されるSRに十分な容量が存在することを確実にする)。そうでない場合、UTは、配備時にACSによるサービスが拒否される危険性がある。
【００５８】
固定のUTの場合、そのSRは、単に、UTが配備される位置を取り囲むACZである(図12の左側を参照)。必要な容量は、常にその点に存在しなければならず、その周囲のACZにおける需要の関数である。このようなチェックは、新しいSCをこの領域に追加することを検討し、既存のSCに害を与えずに新しいSCがプロビジョニングされ配備されるかどうかを判断する。SCが承認可能である場合、その配備は許可され、そうでなければ、許可されない。先験的SC承認可能性がUTの配備より前に要求されない唯一のケースは、商用モデル-1(CM-1)であることに留意されたい。CM-1によって、いわゆる「On Net」UT動作を排除する標準的な3GPPローミングベースの合意手順を使用してOneWebディストリビュータパートナーの迅速なオンボーディングを可能にし、そのようなチェックとの結果的統合は、すべてのSCにとって望ましく、保証ビットレート(GBR)または完全優先転送(EF)サービスには必須である。局所領域にあまりにも多くのサービスを追加すると、所与の容量割振りに負荷をかけすぎ、以前に配備されたサービスに関連付けられた「サービス契約」に違反する可能性がある。ここでの承認制御手順は、たまたまサービス配備の「前に」行われるので、ネットワーク寸法決定プロセスとしても容易に理解される。
【００５９】
さらに、モバイルサービスには同じACプロセスが必要とされることに留意されたい。モバイルUTの場合、そのSRはその移動経路(たとえば、北大西洋の飛行経路の移動経路内にある可能性のある航空機の場合)によって定義され、移動中、そのACZによって掃引される連続的な包絡線における点別需要が考慮されなければならない(図12の右側参照)。ここでは、そのような経路に沿って需要および供給を推定し、可能性のあるワーストケースの需要要件を評価し、新しいモバイルサービスが承認可能かどうかを判断するために、より複雑なリソース管理アルゴリズムが必要とされる。モバイルサービスが販売される時点で、需要を把握するために、そのSCおよび関連するサービス領域がACSに入れられる。
【００６０】
ネットワーク寸法決定/サービスクラス「What If」配備計画
【００６１】
OneWebディストリビュータパートナーは、エンタープライズポータル(EP)を使用して、各AR/CAにおけるそのリソース容量(供給)、その供給に対するその配備されたリソースIPサービス(需要)、および得られたIPサービスQoSに対する影響の様々な「ビュー」を見る。ネットワーク寸法決定のプロセスを検討し始めると、Table 1(表1)のサービスクラス配備ファクタに示すように、最終的にいくつかのファクタを考慮しなければならない。
【００６２】
【表１】
2019518345.tif 000003
【００６３】
ここでは、EPがレンダリングするビューの種類の大まかな「感じ」を提供するために、主に、GBR寸法決定、およびデータレート、衛星デューティサイクルおよびレインフェードの関連ファクタ、ならびに割振り可能なVBR容量へのGBR負荷の影響(現在はUTのモビリティを無視する)を考慮する。「表面」に関する前の議論を想起すると、図8に最初に見られる「理想的な」容量面は、図13(A)において繰り返される。その表面は、ビーム当たり公称400Mbps、ビーム容量の完全に均一な(すなわち滑らかな)分布を想定する。
【００６４】
図13(B)は、2つの別々の効果、すなわち、レインフェードマージンと衛星デューティサイクルを捕捉する。
【００６５】
レインフェードマージン:GBRサービスは、99.xx%のサービスレベル利用可能性(SLA)が提供されると予測される。そのようなSLAを提供するには、データレートをその保証されたレベル未満に低下させることなく、レインフェードマージンの可能性のあるワーストケースの影響についての動的エアリンクリソースの補償を可能にするように、容量マージンを含める必要がある。ここでは、30%のマージンを想定し、これによって、図示のように、GBRサービスプロビジョニングで利用可能な最大点別容量が280Mbpsに低減する。
【００６６】
衛星デューティサイクル:理想的なGBR容量(左側)は、衛星スポットビームが100%のデューティサイクルで動作していると想定する。デューティサイクルは、衛星における電力を節約するために、0%から100%の間で1/8刻みで調整することができるので、そうである必要はない。図13(B)は、エリアの1/4が100%で動作しており(グレー)、1/4が25%のみで動作しており(青)、残りが50%のデューティサイクルで動作している(オレンジ)シナリオを示している。点別の配備可能なGBR容量への影響がわかる。様々なプラトー間の「傾斜路」は、ビームの形状のために南北方向よりも西東方向に伸長しているが、それ以外の点では類似している。
【００６７】
GBR需要の空間的性質は、VBR需要とは異なる。VBR需要は早期に見られる「鮫ひれ」形状を示すのに対し、GBR需要は、平らな「プラトー」と同等のものを作る。これら2つの「需要面」が図14(A)および図14(B)に示されており、これらは、両方の需要が1のオーバーサブスクリプション率(オーバーサブスクライブされていることを意味する)を想定している、空間需要とも呼ばれる、エリアの関数としての統計的IPサービス需要を表す。GBRプラトーより下の量を25Mbpsの需要基準の100%とみなす場合、25MbpsのVBRの鮫ひれより下の量はわずかに27.4%(このグリッドサイズの場合)であり、すなわち、プラトーより下の量の約1/4である。したがって、Mbps相当のVBRサービスは、対応するGBRサービスの空間需要のわずか〜25%しか誘発しない。
【００６８】
しかしながら、VBRサービスは典型的にはオーバーサブスクライブされる(すなわち、率>1)ので、所与のVBR負荷は、ここに示す空間需要のさらなる一部分を誘発するにすぎないことにすでに言及した。
【００６９】
これを理解するために、次に、図15(A)および図15(B)に図式的に示すように、より典型的なVBR例(オーバーサブスクリプション率=100)を示す。ここでは、VBR、および「オーバーサブスクライブされないGBR」需要面のGBRの2つの25Mbpsサービスからの相対的空間需要(Mbps単位)を示す。GBR空間需要は、25Mbps/単位面積でフラットであるのに対し、VBR空間需要は前述の鮫ひれ分布を示すが、今は100分の1に縮小されている。正確な需要計算では、レインフェードマージン(GBRの場合)および最繁時負荷(VBRの場合)など他のファクタを考慮しなければならないので、これも実際の需要の正確な記述ではない。また、そのような計算は、Mbpsではなくクォークでも行われ、後者はここでは単によく知られているために示している。ここでは、説明のために差の大きさを大まかに近似している。
【００７０】
前に、VBR需要では、2つの重なる需要面(すなわち、重なるACZ)が一緒に「合計」されることがわかった。ここで、GBR需要に注目すると、2つの重なるプラトーが、不連続な方法で互いに空間需要を誘発し、重なりの程度に応じて、時として「合計」し、時として合計しないことがあることを観測している。図16の上部は、周囲のビームエリアおよびACZを含むGBR空間需要負荷を示す。下の2つの部分は、それぞれの需要が両方ともACZの交点に含まれるかどうかによって区別される、2つのGBR需要についてのACZの重なりの2つの異なる程度を示す。交点に含まれる場合、交差需要を「合計」することができ、そうでない場合、2つの需要の「最大」が交点の空間需要を決定する。
【００７１】
当然、これは一般化しており、3つの重なるACZのセットが、図17(A)および図17(B)に見られるように現れ、ここで、3D図は、剪断垂直壁のみを有する、階段状のプラトーを有するアステカピラミッドに似始める。
【００７２】
さらに一般化して、各々GBR需要に対応する、図18に示されるいくつかのGBRプラトーを認識する。
【００７３】
図19(A)に示される利用可能なGBR容量を取得するために、これらの需要は、次いで、図19(B)から減じられる。この図は、追加のGBR需要がプロビジョニングされる可能性のある利用可能な(残りの)容量を示す。
【００７４】
この点で、VBR(すなわち、非GBR)サービスは、関連するSLAを与えられると予想されないことに留意されたい。結果として、これは、図20(A)に示されるものの別の名称である、いわゆる「澄んだ空」の容量に対して寸法決定することができる。図20(B)は全GBR容量を示す。当面は、2つの面の形状の違いを無視して、少しその特性に戻り、説明する。
【００７５】
述べたように、観測され得るように、図20(B)は、全GBR容量を依然として示している。当面は、2つの面の形状の違いを無視して、少しそれに戻る。
【００７６】
有利には、OneWebスケジューラは、VBRサービスよりもGBRサービスのスケジューリングに優先順位を付ける。結果として、VBRサービスをプロビジョニングするために利用可能な容量は、任意の関連するGBR要求を考慮する(すなわち、減じる)必要がある。次に図21(A)および図21(B)を参照すると、これは、GBR需要とVBR需要の両方が取り除かれた後に利用可能なVBR容量を示す図21(A)に図式的に示されていることが観測され得る。
【００７７】
ここで、図21(A)および図21(B)を想起すると、スケジュール可能なVBR面とGBR面の形状が異なることが明らかになる。2つの面の違いは、GBRスケジューリングは、利用可能な容量を計算するときに「ワーストケース」のレインフェードを考慮しなければならず、VBRスケジューリングは、「平均の」または「予想された」容量に対して喜んで寸法決定するという事実に由来する。これらの考察の結果、異なる表面形状が示される。それらの違いは、結果の容量デルタを示す図22でわかる。
【００７８】
前述のように、前述の表面は、寸法決定されるべきIPサービスと比較して理解を容易にするために、bps(レート)で示されている。しかし、基礎となる供給および需要の計算は、「エアリソース」または「クォーク」の観点で行われる必要がある。名目上、クォークは「エアインターフェーストラフィックリソースのスケジューリング可能な最小単位」である。具体的には、クォークは、それぞれフォワードリンク(FL)またはリバースリンク(RL)に1つのクォークFLリソースブロック(RB)または2つのRL RBを備える。ビームデューティサイクルの関数としての特定の数値計算(Quarks/sec、またはQps単位)。
【００７９】
SCでのネットワーク寸法決定の機能図を図23に示す。IPサービスプランニングは、OneWebによってSC承認制御アルゴリズムが設計されたフレームワークである、承認制御フレームワーク(ACF)に従って実行される。各パートナーは、管理しているAR/CAごとにそれ自体の承認制御ポリシー(ACP)を定義するためにACFを自由に使用するが、ACFがそのパートナーに対して許可するものに従って、ACPは常に「実行可能」でなければならない。
【００８０】
簡単に言えば、容量(供給)とトラフィック(需要)の観点から、OneWebが供給を制御し、OneWebパートナーが需要を制御する。
【００８１】
パートナーは、図23に示すように、供給または需要の変化の影響を見るために、またはそのACPを変化させ、その影響を評価するために、いわゆる「What if」計画を実行することができる。
【００８２】
パートナーは、ACFの実行可能範囲内にとどまる限り、OneWebとの対話なしに、希望するSC需要の任意の実際の変更を開始することができる。このアクティビティは、OneWeb OSSシステムを通じて開始され、GRMS ACSに伝播する。供給の任意の実際の変化は、OneWebとのオフライン(ヒューマンインザループ)対話を必要とする。
【００８３】
Table 2(表2)に示すように、パートナーが要求し得るビューのタイプは様々である。
【００８４】
【表２】
2019518345.tif 000004
【００８５】
図:ビューのタイプにおいて、供給と実際の需要の両方の実際の(ほぼリアルタイムの)ビューは、ARにわたって可視であり、履歴のビューは、過去の任意の時点で可視であるものとする。また、計画の(すなわち計算された)ビューは、プロビジョニングされたもの、アクティブのもの、見通しのものに利用可能な履歴的に計画されるものとする。計画プロビジョニングのビューは、計画プロビジョニングのサービスクラス需要が(事前のサービス寸法決定を介して)承認されており、しかし、まだアクティブ化されていないUTにのみ適用される。計画アクティブのビューは、UT SC需要およびその先験的な計画されたアクティブの一致した供給の両方に適用される。同様に、計画見通しのビューは、需要と供給の両方をカバーし、「what if」計画を構成する。計画見通しは、履歴プロビジョニングのビューがアーカイブのために保持されることも要求する。
【００８６】
有利には、供給および需要(GBR、VBR、合計など)の様々な局面から見ることができ、洗練された「what if」計画を可能にするために、(表:サービスクラスを想起して)寸法決定に影響を及ぼすファクタの実現可能な変動を可能にする、比較可能なビュー(すなわち、計画対実際、アクティブ対見通しなど)を対比することが可能である。
【００８７】
UT/SCの承認およびプロビジョニング:機能的に、新しいSCが配備される前に、EPは、ACSにSCの承認を要求するものとする。SCは、パートナーのACPに従ってACSによって「承認可能」とみなされる。そのように承認が与えられたSCは、プロビジョニングされたものとみなされるが、まだアクティブではない。
【００８８】
しかしながら、この手順を説明する前に、OneWebはいくつかの商用モデル(CM)を提供することを目的としており、事前承認制御を省略(すなわち、図24のステップ2および3をスキップ)したCM-1と呼ばれる1つのモデルがあることに留意されたい。この省略は、時間のかかる、およびいくぶんコストのかかるOSS/BSSの統合を必要とせず、OneWebプロビジョニングサービスを配備する非常に簡単で迅速な手段をディストリビュータパートナーに提供したいという願望に由来する。VBRサービスのみを提供するための配備なしにCM-1を制限しているので、この省略は可能である。CM-1ではGBRサービスは許可されていない。
【００８９】
SC承認およびUTプロビジョニングの高レベルのアーキテクチャ図が図24に示され、以下のステップを含み、
【００９０】
図:UT/SC承認およびプロビジョニングにおいて以下のステップからなる。
【００９１】
1)EPは、1つまたは複数のAR/CAをカバーする所与のSR内の所与のUT上のSCのOSS配備を要求する。
【００９２】
2)この要求は、必要に応じてOSSによって増強され、AC要求はACSに転送される。AC要求は、UT情報(識別情報(IMSI)、アンテナタイプ、固定の場合、位置(GPS))およびQoS情報(ベアラ構成、サービス領域、AR/CA)を含む。
【００９３】
3)SCがパートナーのACPに従って承認可能である場合、承認が与えられ、それ以外の場合は拒否される。ここでは、CM-1の意味合いは、承認は常に許可されることである(ステップ2と3はスキップされる)。したがって、ステップ1はステップ4に直接つながる。
【００９４】
4)成功を仮定すると、UTは、OneWeb(またはそのCM-1パートナー)のHSSにおいてプロビジョニングすることができる。
【００９５】
5)成功指示がACSからOSSに戻される。
【００９６】
6)成功指示がOSSからEPに転送される。
【００９７】
UT接続/SCアクティブ化:最終的に、プロビジョニングされたUTがネットワークに接続し、その承認されたSCがアクティブ化され、その後アクティブとみなされる。このプロセスアクティブが図25に示され、以下のステップを含む。
【００９８】
1)UTが配備され、ネットワークに接続すると、そのP-GWは、適切なHSSからSC情報を取り出し、対応するベアラを構成する。これによって、UTにIP接続が提供される。
【００９９】
2)その後、UTは、OSSにその接続を通知し、その事前構成されたUTおよびQoS情報(前のセクションのステップ2で説明したように)をOSSに伝える。
【０１００】
3)OSSは、この情報を記録し、GRMS ACSに送る。次いで、ACSは、a)SCのアクティブ化を記録する(非CM-1)、またはb)承認されないSCのアクティブ化を記録する(CM-1)、またはc)何らかの管理上の理由でアクティブ化を拒否する。
【０１０１】
4)ACSは、このUTを以前見たかどうかに留意して、許可または拒否をシグナリングする。
【０１０２】
5)ACSが承認を拒否した場合、すぐに効力を発し得る(ネットワークを開始する)、またはUTが次に接続しようとするときに効力を発し得る(管理上禁止)。この選択はパートナーによって決定される。
【０１０３】
UT接続通知(ステップ3)は、次のことに役立つことに留意されたい。1)CM-1 UT/SC(存在する場合)をACSに通知し、2)配備された/アクティブなUTおよびSCに関してACSを最新の状態に保つ。
【０１０４】
これは、固定のサービスとモバイルサービスの両方に当てはまることに留意されたい。この情報は、UTごとにUTの以前にプロビジョニングされたSR情報と組み合わされると、ACSが、グローバルに配備されたアクティブなQoS SC(およびそのSR)の正確なピクチャを有することができ、その配備前に任意の新しいSCのAC決定を常に行うことが可能である。この情報は、プロビジョニング/承認されたサービス契約から逸脱していないことを確実にするために、各UTの位置/SRを監視するための手段を提供する。
【０１０５】
この点で、管理上禁止はいくつかの形を取り得ることに言及する。
【０１０６】
1)CM-1では、新たに承認されたUTが(ACPごとに)利用可能なリソースを超える場合、CS OSSは、このUTをCN EIRブラックリストに追加し、OneWebネットワークに接続されないようにする。CS OSSは、卸売業者アカウントにそれを追加し、その状態を「ネットワークリソースが不十分のために禁止」に設定する。CS BSS/CRMは、UTがネットワークから管理上禁止されていることを識別する電子メールを卸売業者に送る。これは、リソースの問題に対処するための管理プロセスが発生するまで、ブラックリストに残る。
【０１０７】
2)他のすべてのCMについては、承認制御は、CNにおけるSIMのプロビジョニングの前に行われるものとする。リソースが不足している場合、SIMはCNにおいてプロビジョニングされず、これによって、OneWebネットワークに接続できなくなる。しかしながら、事前プロビジョニング承認チェックが何らかの理由(間違い/事業者のオーバーライドなど)で行われず、接続のリソースが不十分になると、CS OSSは、それを卸売業者アカウントに追加し、その状態を「リソースの不足のために禁止」に設定する。
【０１０８】
UTプロビジョニングオーダーがどのように入れられたかに応じて、CS BSS/CRMは次のうちのいずれかを行う。a)エンタープライズポータルを介したオーダーエントリ、「ネットワークリソースが不十分」のためにUTプロビジョニングまたは承認が失敗したことを示すエラーウェブページを表示する、b)B2BウェブサービスAPIを介したオーダーエントリ、「ネットワークリソースが不十分」のためにUTプロビジョニングまたは承認が失敗したことを示すメッセージ(XMLまたはJSON)を戻す、c)バッチファイルを介したオーダーエントリ、「ネットワークリソースが不十分」のプロビジョニング/承認失敗コードを含む特定のSIMカード(IMEI、IMSI、およびMSDIN)を含むバッチファイルを戻す。
【０１０９】
さらに、CN EIRは、他の利用規約違反(たとえば、UTが未認証、UTが紛失/盗難の報告を受けたなど)のSIMカードをグレーリストまたはブラックリストにも使用されることに留意されたい。
【０１１０】
有利には、ACチェックおよびリソース計画(配備の前[またはCM-1配備の直後])の使用を通じて、または最終的には接続時に、承認されたSCのセットは、ビームパターンカバレージ、SNPの重なりなどに関係なく、実行可能なままである。したがって、ビームが通過する際にACチェックは必要ない。しかしながら、事業者が所与のAR内のそのCAに(誤りもしくは過失、または場合によっては意図的に)負荷をかけすぎた場合、各AR内の容量を割り振る階層スケジューラは、市場を共有する他の事業者のCAを、負荷をかけすぎた事業者による過度の借入から保護するように設計されているので、その加入者のみが損害を被ることになる。したがって、事業者は、CAに負荷をかけないことが奨励される。
【０１１１】
完全優先転送:いくつかのUTは、前述のBDS PHBに加えて、完全優先転送(EF)PHBをサポートするように構成され得る。EF PHB完全優先転送は、BDS SCよりも低いレイテンシ目標(たとえば、100ms対300ms)を有する対応する(追加の)EF SCを必要とするので、容量に対する比較的低い高い優先アクセスを有する。EF SCは、GBRパラメータが指定された状態で配備される。したがって、承認制御の観点から、EFトラフィックは、「GBR」トラフィックともみなされ、そのように扱われるものとする。
【０１１２】
動的承認制御:セッションベースのQoSは、時として(他のネットワークにおいて)ビデオ呼など、帯域幅を大量に消費する対話型アプリケーションをサポートして使用されることがある。そのようなセッションベースのQoSサポートは、動的ACと呼ばれるものを必要とする。動的ACは、そのようなセッションのためのモバイル動的ACシステムにおけるハンドオフ時にも発生する。そのため、これが必要であることが判明した場合、ここでも当てはまる。
【０１１３】
セッションベースのQoSサポートが必要とされる方法は、アプリケーション、およびその基礎となるネットワークとの関係によって異なる。時として、アプリケーションがホストデバイスに常駐し、ホストOSにQoS要求を行い、ホストOSが、サポートが必要とされる対応するネットワークインターフェースにQoSサポートを要求することがある。これによって、インターフェースモデムは、適切なSCがアクセスネットワークに入ることを要求し、このモードのQoSシグナリングは、しばしばホストまたはモバイル主導型と呼ばれる。より一般的には、3GPPシステムでは、ホストアプリケーションがネットワーク側のアプリケーションの相手と対話し、ネットワーク接続された相手がQoSシグナリングにアクセスネットワークのSC要求を行わせる。これはしばしばネットワーク主導型シグナリングと呼ばれる。いずれの場合でも、QoS要求は、最終的に、AC決定を行わなければならないアクセスインターフェースリソース(すなわち、セルラーネットワークにおける基地局)をネットワーク要素が管理する道を見つける。
【０１１４】
ここでは、すでに述べたように、基地局均等物(SNP)は、AC決定を行うための装備が整っていない。しかしながら、そのような質問をすると、SNPがSC ACクエリをACSに中継することが可能であり、これは、図:承認制御システムにおいて、すでにすべてのアクティブなSCを認識している。以前のように、セッションは、進行することが許可される場合もあり、許可されない場合もある。また、以前のように、SCが、モバイルが承認したオープンな質問である場合、SNPは、ACS内のその状態を維持し(アクティブなSCとして)、セッションが完了したときにそれを削除する責任がある。したがって、すべてのアプリケーション固有のセッションによる要求もACSにとって既知であり、そのAC決定に考慮される。
【０１１５】
専用対共有の容量割振り:容量の割振りは、「専用」または「共有」のいずれかと想定される。共有のCAは単一のSPによって占有され、管理され、専用のCAは複数のSPによって占有される。共有のCAは、より広いエリア/グローバルサービスの容量を提供するために使用され得、この場合、サービスが共有のCAの大部分であり、モバイルの権威のある監視がOneWebまたはモビリティサービスパートナーによって提供される状態で、ARの共有のCA内の複数のモビリティ「フリート」が協働するSPによって共同管理される必要がある。
【０１１６】
需要および供給:容量(すなわち、CA)の最大の「供給」は、ビジネスレベルで契約上決定され、典型的には、所与のARについて固定される。この最大供給に対して承認制御の決定が行われる。しかしながら、しばしば、容量の「需要」は、この最大値よりも小さくなる(たとえば、より少ない日中の使用パターン)。GRMSは、時間および空間にわたるローカル供給利用可能度を管理すると同時に、グローバル電力バジェット内にとどまるように衛星電力支出を管理する責任がある。これは、各衛星のデューティサイクルを軌道ごとに0%から100%の間で調整することによって行われる。ACSは、配備されたすべてのUTとそのアクティブなSCの状態とを認識しているので、GRMSは、この知識を、(たとえば日中の使用パターンなど)時間の経過とともにIPトラフィックの「需要」に関して学習される「データ分析」と結合して、衛星電力消費を最小限に抑えながら供給および需要に最もマッチするようにすることができる。
【０１１７】
ACSとBxP/AxP(スケジューラ)の関係:ACSは、BxP/AxPスケジューラの構築方法、および承認されたSCのスケジュール方法についての部分的な知識により動作する。対照的に、BxP/AxPは、AC決定が動的セッションQoSをサポートするようACSに要求しなければならないことを知っていること以外、概念の承認制御を認識しない。BxP/AxPは、(UTおよびSCが出入りするにつれて)すべてのアクティブなSCを受け入れ、それに従ってスケジューリングを適応させる必要がある。
【０１１８】
前述のように、ACS実装は、グローバル連合DBに対して動作するローカライズされたサーバインスタンスをローカライズした。重要な実装決定は、使用するDBのタイプ(SQLまたはNoSQL)次第である。カサンドラは、システムが生成することができるあらゆるレベルのACダイナミクス(読取り/書込み)を容易に処理できるので、考慮するのに良いNoSQL DBの候補である。しかし、ACのダイナミクスのレベルはそれほど高くない(多くの初期SCエントリは静的である)であり、リレーショナルクエリ処理は強力であるので、SQLアプローチ(リレーショナルDB)は先験的に除外すべきではない。
【０１１９】
それでもなお、OneWebが慎重すぎて失敗し、必要な程度にスケールアップすることが知られているDBから始めるのが最善の方法であり得る。大規模なデータ分析は、細工されたマルチテーブルのカサンドラスキーマの上に容易に実装される。時間とともに「SQL状の」特徴がカサンドラに追加されている。奇妙なことに、カサンドラでは「書込み」は比較的「フリー」であるので、多くのテーブルにわたって一貫したデータを書き込むことが方法である。データモデルは、高速AC決定のために必要な「ビュー」(読取り時に必要)が自然に従うように細工されている。
【０１２０】
概要:ACSは、すべてプロビジョニングされ、アクティブなSCの状態を世界中で維持する。このことは、この状態および計算をクラウドベースのリソースにオフロードすることによって、SNPが静的ACチェックと動的ACチェックの両方を実行するという要件を削除する。ACSは、さらに、市場、事業者、サービスなどによって区分可能な衛星エアインターフェースの需要および使用量のグローバルなピクチャをGNOCに提供する。したがって、これは、SPサービスプランナーによって、販売時点で有用な容量管理機能を提供する。
【０１２１】
最後に、図26は、本開示の態様による方法およびシステムを実施するのに適した例示的なコンピュータシステム2600を示す。すぐに諒解されるように、そのようなコンピュータシステムは、別のシステムに統合されてもよく、個別の要素または1つもしくは複数の統合された構成要素を介して実装されてもよい。コンピュータシステムは、たとえば、いくつかのオペレーティングシステムのうちのいずれかを実行するコンピュータを備え得る。本開示の上述の方法は、記憶されたプログラム制御命令としてコンピュータシステム2600上で実施されてもよい。
【０１２２】
コンピュータシステム2600は、プロセッサ2610、メモリ2620、記憶デバイス2630、および入出力構造2640を含む。1つまたは複数の入出力デバイスは、ディスプレイ2645を含み得る。1つまたは複数のバス2650は、典型的には、構成要素2610、2620、2630、および2640を相互接続する。プロセッサ2610は、シングルまたはマルチコアであってもよい。さらに、システムは、チップ上のシステムをさらに含む加速器などを含み得る。
【０１２３】
プロセッサ2610は、本開示の実施形態が図面の1つまたは複数に記載されたステップを含み得る命令を実行する。そのような命令は、メモリ2620または記憶デバイス2630に記憶され得る。データおよび/または情報は、1つまたは複数の入出力デバイスを使用して受信および出力されてもよい。
【０１２４】
メモリ2620は、データを記憶してもよく、揮発性または不揮発性メモリなどのコンピュータ可読媒体であってもよい。記憶デバイス2630は、たとえば、前述の方法を含むシステム2600の記憶デバイスを提供し得る。様々な態様において、記憶デバイス2630は、磁気、光、または他の記録技術を使用するフラッシュメモリデバイス、ディスクドライブ、光ディスクデバイス、またはテープデバイスであってもよい。
【０１２５】
入出力構造2640は、システム2600の入出力動作を提供し得る。
【０１２６】
この点で、本開示による方法、技法、および構造を特定の実装および/または実施形態に関して説明してきたが、当業者であれば、本開示はそれに限定されないことを認識することを、当業者は、容易に諒解されよう。したがって、本開示の範囲は、本明細書に添付された特許請求の範囲によってのみ限定されるものとする。
【符号の説明】
【０１２７】
2600  コンピュータシステム
2610  プロセッサ
2620  メモリ
2630  記憶デバイス
2640  入出力構造
2645  ディスプレイ
2650  バス
【図１】
2019518345.tif 000005
【図２】
2019518345.tif 000006
【図３】
2019518345.tif 000007
【図４】
2019518345.tif 000008
【図５】
2019518345.tif 000009
【図６】
2019518345.tif 000010
【図７Ａ】
2019518345.tif 000011
【図７Ｂ】
2019518345.tif 000012
【図８】
2019518345.tif 000013
【図９Ａ】
2019518345.tif 000014
【図９Ｂ】
2019518345.tif 000015
【図１０】
2019518345.tif 000016
【図１１】
2019518345.tif 000017
【図１２】
2019518345.tif 000018
【図１３Ａ】
2019518345.tif 000019
【図１３Ｂ】
2019518345.tif 000020
【図１４Ａ】
2019518345.tif 000021
【図１４Ｂ】
2019518345.tif 000022
【図１５Ａ】
2019518345.tif 000023
【図１５Ｂ】
2019518345.tif 000024
【図１６】
2019518345.tif 000025
【図１７Ａ】
2019518345.tif 000026
【図１７Ｂ】
2019518345.tif 000027
【図１８】
2019518345.tif 000028
【図１９Ａ】
2019518345.tif 000029
【図１９Ｂ】
2019518345.tif 000030
【図２０Ａ】
2019518345.tif 000031
【図２０Ｂ】
2019518345.tif 000032
【図２１Ａ】
2019518345.tif 000033
【図２１Ｂ】
2019518345.tif 000034
【図２２】
2019518345.tif 000035
【図２３】
2019518345.tif 000036
【図２４】
2019518345.tif 000037
【図２５】
2019518345.tif 000038
【図２６】
2019518345.tif 000039
【国際調査報告】
2019518345.tif 000040
2019518345.tif 000041
2019518345.tif 000042