知財求人 - 知財ポータルサイト「IP Force」
▶ パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカの特許一覧
特表2023-543501スモールデータの送信に関与するユーザ機器および基地局
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2023-10-16
(54)【発明の名称】スモールデータの送信に関与するユーザ機器および基地局
(51)【国際特許分類】
H04W 74/08 20090101AFI20231006BHJP
H04W 72/1268 20230101ALI20231006BHJP
H04W 72/21 20230101ALI20231006BHJP
H04W 4/20 20180101ALI20231006BHJP
H04W 76/11 20180101ALI20231006BHJP
【ＦＩ】
H04W74/08
H04W72/1268
H04W72/21
H04W4/20 110
H04W76/11
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2023519893
(86)(22)【出願日】2021-09-15
(85)【翻訳文提出日】2023-03-30
(86)【国際出願番号】 EP2021075355
(87)【国際公開番号】W WO2022069231
(87)【国際公開日】2022-04-07
(31)【優先権主張番号】20199693.1
(32)【優先日】2020-10-01
(33)【優先権主張国・地域又は機関】EP
(81)【指定国・地域】
(71)【出願人】
【識別番号】514136668
【氏名又は名称】パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ
【氏名又は名称原語表記】Ｐａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ
(74)【代理人】
【識別番号】110002952
【氏名又は名称】弁理士法人鷲田国際特許事務所
(72)【発明者】
【氏名】タオ ミン－フン
(72)【発明者】
【氏名】鈴木 秀俊
(72)【発明者】
【氏名】シャー リキン
【テーマコード（参考）】
5K067
【Ｆターム（参考）】
5K067AA21
5K067DD34
5K067EE02
5K067EE10
5K067HH21
5K067JJ21
(57)【要約】
本開示は、以下を有するユーザ機器（ＵＥ）に関する。受信機は、サービング基地局（ＢＳ）からＵＥ識別情報を受信する。ＵＥは、非アクティブ状態にある。ＵＥ識別情報は、少なくとも上りリンクリソース割当てを含むリソース割当ての受信のための監視機能を実行するためにＵＥによって使用可能である。受信機は、ＵＥ識別情報に基づいて、サービングＢＳから送信された上りリンクリソース割当てを受信し、当該上りリンクリソース割当てによってスモールデータの送信のための無線リソースが割り当てられる。送信機は、受信された上りリンクリソース割当てに基づいて、スモールデータのサービングＢＳへの送信を実行する。プロセッサは、ＵＥ識別情報に基づく少なくとももう１つの他の上りリンクリソース割当ての受信のために監視機能を延長するか否かを決定し、当該決定は、サービングＢＳから受信されたメッセージに基づくか、またはＵＥが送信可能なさらなるスモールデータを有するか否かに基づく。
【特許請求の範囲】
【請求項1】
ユーザ機器（ＵＥ：User Equipment）であって、動作中、前記ＵＥに現在サービスを提供（サービング）している基地局からＵＥ識別情報の割当てを受信する受信機であって、前記ＵＥは、接続状態、アイドル状態、および非アクティブ状態のうちの非アクティブ状態にあり、前記ＵＥ識別情報は、前記サービング基地局から送信される、少なくとも上りリンクリソース割当てを含む、リソース割当ての受信のための監視機能を実行するために前記非アクティブＵＥによって使用可能である、受信機と、
前記受信機は、動作中、前記ＵＥ識別情報に基づいて、前記サービング基地局から送信された上りリンクリソース割当てを受信し、当該受信された上りリンクリソース割当てによって、スモールデータの送信のために前記非アクティブＵＥによって使用可能な無線リソースが割り当てられる、
動作中、前記受信された上りリンクリソース割当てに基づいて、前記スモールデータの前記サービング基地局への送信を実行する送信機と、
動作中、前記ＵＥ識別情報に基づく少なくとももう１つの他の上りリンクリソース割当ての受信のために前記監視機能を延長するか否かを決定するプロセッサであって、前記決定は、前記サービング基地局から受信されたメッセージに基づくか、または前記ＵＥが送信可能なさらなるスモールデータを有するか否かに基づく、プロセッサと、
を有する、ユーザ機器。
【請求項2】
前記メッセージは、前記受信された上りリンクリソース割当てであり、前記プロセッサは、動作時、前記上りリンクリソース割当ての受信時に、または前記受信された上りリンクリソース割当てに基づく前記スモールデータの送信の実行時に、または前記さらなるスモールデータが前記ＵＥにより送信可能であることを示すバッファ状態報告の送信時に前記監視機能を延長すると決定する、請求項１に記載のユーザ機器。
【請求項3】
前記ＵＥ識別情報の破棄は、１つまたは２つのタイマに基づいて制御され、当該制御は、前記ＵＥ識別情報の有効性を制御するために１つのタイマを動作させることを含み、前記タイマは、前記監視機能の実行開始時に始動され、前記タイマは、前記上りリンクリソース割当ての受信時に、もしくは前記スモールデータの前記送信の実行時に、もしくは前記さらなるスモールデータが前記ＵＥにより送信可能であることを示す前記バッファ状態報告の送信時に再始動され、前記プロセッサは、前記タイマの満了時に前記ＵＥ識別情報を破棄すると決定する、または
前記ＵＥ識別情報の有効性を制御するために第１のタイマおよび第２のタイマをそれぞれ動作させることを含み、前記第１のタイマは、前記監視機能の実行開始時に始動され、前記第２のタイマは、前記上りリンクリソース割当ての受信のたびに、もしくは前記スモールデータの前記送信の実行のたびに、もしくは前記さらなるスモールデータが前記ＵＥにより送信可能であることを示す前記バッファ状態報告の送信のたびに始動されもしくは再始動され、前記プロセッサは、前記第１のタイマおよび前記第２のタイマがいずれも動作していない場合、前記ＵＥ識別情報を破棄すると決定する、
請求項２に記載のユーザ機器。
【請求項4】
前記受信機は、前記非アクティブＵＥに前記非アクティブ状態に留まるよう指示するＵＥ状態指示メッセージを前記サービング基地局から受信し、前記ＵＥ識別情報は、前記ＵＥ状態指示メッセージの受信時に、破棄され、
オプションで、前記プロセッサは、動作時、前記ＵＥ状態指示メッセージの受信時に他の上りリンクリソース割当てを受信するための前記監視機能の実行を停止し、
オプションで、前記ＵＥ状態指示メッセージは、前記非アクティブＵＥによって前記サービング基地局に以前に送信された接続再開要求メッセージに対する応答である、
請求項２または３に記載のユーザ機器。
【請求項5】
前記プロセッサは、動作時、前記メッセージが、前記非アクティブＵＥに前記監視機能を延長するよう指示する監視指示を含む場合、前記監視機能を延長すると決定し、前記メッセージは、前記非アクティブＵＥに前記非アクティブ状態に留まるよう指示し、かつ、前記監視機能を延長するか否かを指示する前記監視指示を含む、ＵＥ状態指示メッセージであり、
オプションで、前記ＵＥ状態指示メッセージは、前記非アクティブＵＥによって前記サービング基地局に以前に送信された接続再開要求メッセージに対する応答である、
請求項１に記載のユーザ機器。
【請求項6】
前記プロセッサは、動作時、ある量の監視時間に到達した時に、他の上りリンクリソース割当ての受信のための前記監視機能の実行を停止し、前記監視時間の量は、前記メッセージに含まれる情報に基づいて、または前記非アクティブＵＥによって利用可能な事前設定済み情報に基づいて決定され、オプションで、前記事前設定済み情報は、前記サービング基地局からブロードキャストされるシステム情報によって、または基地局からの以前の上位レイヤ構成メッセージによって、または前記非アクティブＵＥのユニバーサル加入者識別モジュール（Universal Subscriber Identity module）から、または技術規格の要件から、前記ＵＥに提供され、
オプションで、前記監視時間の量は、前記上りリンクリソース割当ての受信時に、または前記受信された上りリンクリソース割当てに基づく前記スモールデータの前記送信の実行時に、または前記さらなるスモールデータが前記ＵＥにより送信可能であることを示すバッファ状態報告の送信時に、延長される、
請求項５に記載のユーザ機器。
【請求項7】
前記メッセージは、上りリンクリソース割当ての数に関する情報をさらに提供し、前記プロセッサは、動作時、前記数の上りリンクリソース割当てを受信した時に、他の上りリンクリソース割当ての受信のための前記監視機能の実行を停止する、請求項５または６に記載のユーザ機器。
【請求項8】
前記監視指示は、● 前記ＵＥ状態指示メッセージに含まれ、または
● 前記ＵＥ状態指示メッセージと共に送信され、または
● 前記ＵＥ状態指示メッセージを受信するために前記非アクティブＵＥによって使用可能な下りリンク無線リソースを割り当てる下りリンクリソース割当てに含まれる、
請求項５～７のいずれかに記載のユーザ機器。
【請求項9】
前記ＵＥ識別情報の破棄は、前記監視機能に基づいて制御され、オプションで、前記プロセッサは、動作時、前記監視機能の実行を停止すると決定した時に前記ＵＥ識別情報を破棄すると決定し、オプションで、前記プロセッサは、動作時、前記監視指示が、前記非アクティブＵＥに前記監視時間を延長しないよう指示する場合、前記ＵＥ識別情報を破棄すると決定する、
請求項５～８のいずれか一項に記載のユーザ機器。
【請求項10】
前記プロセッサは、動作時、前記メッセージが、前記非アクティブＵＥに前記監視機能を延長するよう指示する監視指示を含む場合、前記監視機能を延長すると決定し、前記メッセージは、データの送受信のために前記非アクティブＵＥによって使用可能な無線リソースを割り当て、かつ、前記監視機能を延長するか否かを指示する監視指示を含む、リソース割当てであり、
オプションで、前記プロセッサは、動作時、前記リソース割当ての前記監視指示が前記監視機能を延長しないよう指示する場合、前記監視機能を停止する、
請求項１に記載のユーザ機器。
【請求項11】
前記ＵＥ識別情報の破棄は、前記監視指示に基づいて制御され、前記プロセッサは、動作時、前記監視指示が前記監視機能を延長しないよう指示する場合、前記ＵＥ識別情報を破棄すると決定し、または、前記ＵＥ識別情報の破棄は、２つのタイマに基づいて制御され、前記制御は、
前記ＵＥ識別情報の有効性を制御するために第１のタイマおよび第２のタイマをそれぞれ動作させることを含み、前記第１のタイマは、前記監視機能の実行開始時に始動され、前記第２のタイマは、前記監視指示が前記監視機能を延長するよう指示する場合に始動されまたは再始動され、前記プロセッサは、前記第１のタイマおよび前記第２のタイマがいずれも動作していない場合、前記ＵＥ識別情報を破棄すると決定する、
請求項１０に記載のユーザ機器。
【請求項12】
前記プロセッサは、動作時、前記ＵＥが送信可能なさらなるスモールデータを有する場合、前記監視機能を拡張すると決定し、オプションで、前記送信機は、動作時、前記非アクティブＵＥが送信可能なさらなるスモールデータを有する場合、バッファ状態報告を前記サービング基地局に送信し、
オプションで、前記バッファ状態報告は、前記スモールデータと共に送信される、
請求項１に記載のユーザ機器。
【請求項13】
前記ＵＥ識別情報は、前記非アクティブＵＥと前記サービング基地局の間で実行されるランダムアクセス手順中に前記非アクティブＵＥに割り当てられ、オプションで、前記ランダムアクセス手順は、２つのステップを含み、第１のスモールデータの送信は、前記２ステップランダムアクセス手順の第１のメッセージによって実行され、
オプションで、前記ランダムアクセス手順は、４つのステップを含み、前記第１のスモールデータの前記送信は、前記４ステップランダムアクセス手順の第３のメッセージによって実行され、
オプションで、スモールデータの第１の送信は、前記ＵＥと前記基地局の間で実行される前記ランダムアクセス手順の一部として実行される、
請求項１～１２のいずれか一項に記載のユーザ機器。
【請求項14】
前記非アクティブＵＥによって前記サービング基地局にバッファ状態報告が送信され、前記バッファ状態報告は、前記非アクティブＵＥのバッファの送信可能なデータに関する情報を提供する、請求項１～１３のいずれか一項に記載のユーザ機器。
【請求項15】
前記非アクティブ状態、前記接続状態、および前記アイドル状態は、無線リソース制御（ＲＲＣ：Radio Resource Control）プロトコルに関連している、請求項１～１４のいずれか一項に記載のユーザ機器。
【請求項16】
前記受信機は、動作時、前記非アクティブＵＥに前記接続状態に遷移するようまたは前記非アクティブ状態に留まるよう指示するＵＥ状態指示を前記サービング基地局から受信し、前記プロセッサは、動作時、前記受信されたＵＥ状態指示に従うように前記ＵＥの状態を制御し、
オプションで、前記ＵＥ状態指示は、前記非アクティブＵＥによって送信された接続要求メッセージに応答して前記基地局によって送信される、
請求項１～１５のいずれか一項に記載のユーザ機器。
【請求項17】
ユーザ機器（ＵＥ：User Equipment）によって実行される以下のステップを有する方法であって、前記ＵＥに現在サービスを提供（サービング）している基地局からＵＥ識別情報の割当てを受信するステップであって、前記ＵＥは、接続状態、アイドル状態、および非アクティブ状態のうちの非アクティブ状態にあり、前記ＵＥ識別情報は、前記サービング基地局から送信される、少なくとも上りリンクリソース割当てを含む、リソース割当ての受信のための監視機能を実行するために非アクティブＵＥによって使用可能である、ステップと、
前記ＵＥ識別情報に基づいて、前記サービング基地局から送信された上りリンクリソース割当てを受信するステップであって、当該受信した上りリンクリソース割当てによって、スモールデータの送信のために前記非アクティブＵＥによって使用可能な無線リソースが割り当てられる、ステップと、
前記受信した上りリンクリソース割当てに基づいて、前記スモールデータの前記サービング基地局への送信を実行するステップと、
前記ＵＥ識別情報に基づく少なくとももう１つの他の上りリンクリソース割当ての受信のために前記監視機能を延長するか否かを決定するステップであって、前記決定は、前記サービング基地局から受信したメッセージに基づくか、または前記ＵＥが送信可能なさらなるスモールデータを有するか否かに基づく、ステップと、
を有する方法。
【請求項18】
基地局であって、動作中、前記基地局によって現在サービスが提供されているユーザ機器（ＵＥ：User Equipment）にＵＥ識別情報の割当てを送信する送信機であって、前記ＵＥは、接続状態、アイドル状態、および非アクティブ状態のうちの非アクティブ状態にあり、前記ＵＥ識別情報は、少なくとも上りリンクリソース割当てを含むリソース割当てを前記ＵＥに送信するために前記基地局によって使用可能である、送信機と、
前記送信機は、動作中、前記ＵＥ識別情報に基づいて、前記非アクティブＵＥに上りリンクリソース割当てを送信し、当該送信された上りリンクリソース割当てによって、スモールデータの送信のために前記非アクティブＵＥによって使用可能な無線リソースが割り当てられ、また、当該送信された上りリンクリソース割当ては、前記非アクティブＵＥが前記割り当てられたＵＥ識別情報に基づくリソース割当ての受信のための監視機能を実行することに基づいて前記非アクティブＵＥによって受信可能である、
動作中、前記送信された上りリンクリソース割当てに基づいて、前記非アクティブＵＥからの前記スモールデータの受信を実行する受信機と、を有し、
前記送信機は、動作中、前記非アクティブＵＥが前記ＵＥ識別情報に基づく少なくとももう１つの他の上りリンクリソース割当ての受信のために前記監視機能を延長するか否かを決定する基礎となるメッセージを前記非アクティブＵＥに送信する、
基地局。
【請求項19】
基地局によって実行される以下のステップを有する方法であって、前記基地局によって現在サービスが提供されているユーザ機器（ＵＥ：User Equipment）にＵＥ識別情報の割当てを送信するステップであって、前記ＵＥは、接続状態、アイドル状態、および非アクティブ状態のうちの非アクティブ状態にあり、前記ＵＥ識別情報は、少なくとも上りリンクリソース割当てを含むリソース割当てを前記ＵＥに送信するために前記基地局によって使用可能である、ステップと、
前記ＵＥ識別情報に基づいて、前記非アクティブＵＥに前記上りリンクリソース割当てを送信するステップであって、当該送信した上りリンクリソース割当てによって、スモールデータの送信のために前記非アクティブＵＥによって使用可能な無線リソースが割り当てられ、また、当該送信した上りリンクリソース割当ては、前記非アクティブＵＥが前記割り当てられたＵＥ識別情報に基づくリソース割当ての受信のための監視機能を実行することに基づいて前記非アクティブＵＥによって受信可能である、ステップと、
前記送信した上りリンクリソース割当てに基づいて、前記非アクティブＵＥからの前記スモールデータの受信を実行するステップと、
前記非アクティブＵＥが前記ＵＥ識別情報に基づく少なくとももう１つの他の上りリンクリソース割当ての受信のために前記監視機能を延長するか否かを決定する基礎となるメッセージを前記非アクティブＵＥに送信するステップと、
を有する方法。
【請求項20】
動作中、ユーザ機器（ＵＥ：User Equipment）の処理を制御する集積回路であって、前記処理が、前記ＵＥによって実行される以下のステップ、前記ＵＥに現在サービスを提供（サービング）している基地局からＵＥ識別情報の割当てを受信するステップであって、前記ＵＥは、接続状態、アイドル状態、および非アクティブ状態のうちの非アクティブ状態にあり、前記ＵＥ識別情報は、前記サービング基地局から送信される、少なくとも上りリンクリソース割当てを含む、リソース割当ての受信のための監視機能を実行するために非アクティブＵＥによって使用可能である、ステップと、
前記ＵＥ識別情報に基づいて、前記サービング基地局から送信された上りリンクリソース割当てを受信するステップであって、当該受信した上りリンクリソース割当てによって、スモールデータの送信のために前記非アクティブＵＥによって使用可能な無線リソースが割り当てられる、ステップと、
前記受信した上りリンクリソース割当てに基づいて、前記スモールデータの前記サービング基地局への送信を実行するステップと、
前記ＵＥ識別情報に基づく少なくとももう１つの他の上りリンクリソース割当ての受信のために監視機能を延長するか否かを決定するステップであって、前記決定は、前記サービング基地局から受信したメッセージに基づくか、または前記ＵＥが送信可能なさらなるスモールデータを有するか否かに基づく、ステップと、を含む、
集積回路。
【請求項21】
動作中、基地局の処理を制御する集積回路であって、前記処理が、前記基地局によって実行される以下のステップ、前記基地局によって現在サービスが提供されているユーザ機器（ＵＥ：User Equipment）にＵＥ識別情報の割当てを送信するステップであって、前記ＵＥは、接続状態、アイドル状態、および非アクティブ状態のうちの非アクティブ状態にあり、前記ＵＥ識別情報は、少なくとも上りリンクリソース割当てを含むリソース割当てを前記ＵＥに送信するために前記基地局によって使用可能である、ステップと、
前記ＵＥ識別情報に基づいて、前記非アクティブＵＥに上りリンクリソース割当てを送信するステップであって、当該送信した上りリンクリソース割当てによって、スモールデータの送信のために前記非アクティブＵＥによって使用可能な無線リソースが割り当てられ、また、当該送信した上りリンクリソース割当ては、前記非アクティブＵＥが前記割り当てられたＵＥ識別情報に基づくリソース割当ての受信のための監視機能を実行することに基づいて前記非アクティブＵＥによって受信可能である、ステップと、
前記送信した上りリンクリソース割当てに基づいて、前記非アクティブＵＥからの前記スモールデータの受信を実行するステップと、
前記非アクティブＵＥが前記ＵＥ識別情報に基づく少なくとももう１つの他の上りリンクリソース割当ての受信のために前記監視機能を延長するか否かを決定する基礎となるメッセージを前記非アクティブＵＥに送信するステップと、を含む、
集積回路。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、３ＧＰＰ通信システムなどの通信システムにおける方法、装置、および物品を対象とする。
【背景技術】
【0002】
現在、第３世代パートナーシッププロジェクト（３ＧＰＰ（登録商標）：3rd Generation Partnership Project）は、第５世代（５Ｇ：5th Generation）とも呼ばれる次世代セルラー技術の技術仕様に取り組んでいる。
【0003】
一つの目的は、少なくとも拡張モバイルブロードバンド（ｅＭＢＢ：enhanced mobile broadband）、超高信頼・低遅延通信（ＵＲＬＬＣ：ultra-reliable low-latency communications）、および大規模マシンタイプ通信（ｍＭＴＣ：massive machine type communications）を含む、あらゆる使用シナリオ、要件、および配置シナリオ（例えば、非特許文献１の第６節を参照）に対処する、単一の技術的枠組みを提供することである。例えば、ｅＭＢＢの配置シナリオには、屋内のホットスポット、密集都市部、郊外、都市部マクロ・高速環境が含まれ得る。ＵＲＬＬＣの配置シナリオには、産業制御システム、モバイル健康管理（遠隔モニタリング、遠隔診断、および遠隔治療）、車両のリアルタイム制御、スマートグリッドの広域監視・制御システムが含まれ得る。ｍＭＴＣの配置シナリオには、スマートウェアラブルやセンサーネットワークなど、データ伝送の遅延の影響が小さい多数の装置を使用するシナリオが含まれ得る。ｅＭＢＢのサービスとＵＲＬＬＣのサービスは、いずれも極めて広い帯域幅が要求される点において似ているが、ＵＲＬＬＣサービスは、好ましくは極めて小さいレイテンシ（待ち時間）（latency）が要求され得る点において異なる。
【0004】
第２の目的は、前方互換性を達成することである。ロングタームエボリューション（Long Term Evolution）（ＬＴＥ、ＬＴＥ－Ａ）セルラーシステムへの後方互換性は要求されず、これにより、全く新しいシステムの設計および／または新規の特徴の導入が容易になる。
【先行技術文献】
【非特許文献】
【0005】
【非特許文献1】ＴＲ ３８．９１３ ｖｅｒｓｉｏｎ １５．０．０
【非特許文献2】３ＧＰＰ ＴＳ ３８．３００ ｖ１６．２．０
【非特許文献3】３ＧＰＰ ＴＳ ３８．２１１ ｖ１６．２．０
【非特許文献4】ＩＴＵ－Ｒ Ｍ．２０１８３
【非特許文献5】ＴＳ ２３．５０１ ｖ１６．５．１
【非特許文献6】３ＧＰＰ ＴＳ ３８．３２１， ｖ１６．１．０
【非特許文献7】ＴＳ ３８．３３１ ｖ１６．１．０
【非特許文献8】ＴＲ ２５．７０５ ｖ１３．０．０
【発明の概要】
【0006】
一つの非限定的かつ例示的な実施形態は、ＵＥが改良されたスモールデータ送信手順を実行することを容易にするための手順の提供を容易にする。
【0007】
一実施の形態において、本明細書に開示されている技術は、以下を有するユーザ機器（ＵＥ：User Equipment）を特徴とする。
【0008】
前記ＵＥの受信機は、前記ＵＥに現在サービスを提供（サービング）している基地局からＵＥ識別情報の割当てを受信する。前記ＵＥは、接続状態、アイドル状態、および非アクティブ状態のうちの非アクティブ状態にある。前記ＵＥ識別情報は、前記サービング基地局から送信される、少なくとも上りリンクリソース割当てを含む、リソース割当ての受信のための監視機能を実行するために前記非アクティブＵＥによって使用可能である。前記受信機は、前記ＵＥ識別情報に基づいて、前記サービング基地局から送信された上りリンクリソース割当てを受信する。当該受信された上りリンクリソース割当てによって、スモールデータの送信のために前記非アクティブＵＥによって使用可能な無線リソースが割り当てられる。前記ＵＥの送信機は、前記受信された上りリンクリソース割当てに基づいて、前記スモールデータの前記サービング基地局への送信を実行する。プロセッサは、前記ＵＥ識別情報に基づく少なくとももう１つの他の上りリンクリソース割当ての受信のために前記監視機能を延長するか否かを決定し、当該決定は、前記サービング基地局から受信されたメッセージに基づくか、または前記ＵＥが送信可能なさらなるスモールデータを有するか否かに基づく。
【0009】
なお、一般的または特定の実施形態は、システム、方法、集積回路、コンピュータプログラム、記憶媒体、またはこれらの任意の選択的な組み合わせとして実施できることに留意されたい。例えば、集積回路は、ＵＥまたは基地局の処理を制御することができる。
【0010】
開示されている実施形態および様々な実装形態のさらなる恩恵および利点は、本明細書および図面から明らかになるであろう。これらの恩恵および／または利点は、本明細書および図面の様々な実施形態および特徴によって個別に得ることができ、このような恩恵および／または利点の１つまたは複数を得るために、それらをすべて設ける必要はない。
【図面の簡単な説明】
【0011】
以下、例示的な実施形態について添付の図面を参照しながらより詳細に説明する。
【0012】
【図1】３ＧＰＰ ＮＲシステムの例示的なアーキテクチャを示す図
【図2】ＮＧ－ＲＡＮと５ＧＣとの間の機能分割を示す概略図
【図3】ＲＲＣ接続確立／再設定手順のシーケンス図
【図4】拡張モバイルブロードバンド（ｅＭＢＢ）、大規模マシンタイプ通信（ｍＭＴＣ）、および超高信頼・低遅延通信（ＵＲＬＬＣ）の使用シナリオを示す概略図
【図5】非ローミングシナリオ向けの例示的な５Ｇシステムアーキテクチャを示すブロック図
【図6】コンテンションベースのＲＡＣＨ手順を示す図
【図7】コンテンションフリーのＲＡＣＨ手順を示す図
【図8】起こり得るＲＲＣ状態変化を示す図
【図9】ＲＲＣ再開（RRC Resume）手順のメッセージ交換を示す図
【図10】ＲＲＣ解放（RRC Release：RRCリリース）手順のメッセージ交換を示す図
【図11】ＲＲＣ解放（RRC Release：RRCリリース）手順のメッセージ交換を示す図
【図12】Ｉｎａｃｔｉｖｅ状態からＣｏｎｎｅｃｔｅｄ状態へのＵＥの状態変化を含む、上りリンクデータ送信のための先行技術のメッセージ交換を示す図
【図13】ＲＲＣ＿ＩＮＡＣＴＩＶＥ ＵＥがスモールデータを上りリンクで送信するために使用可能な例示的な４ステップＲＡＣＨを示す図
【図14】ＲＲＣ＿ＩＮＡＣＴＩＶＥ ＵＥがスモールデータを上りリンクで送信するために使用可能な例示的な２ステップＲＡＣＨを示す図
【図15】例示的なシングルＳＤＴ送信手順を示す図
【図16】マルチＳＤＴ送信手順に対する可能な解決策を示す図
【図17】ＵＥおよびｇＮＢの例示的かつ簡略化された構造を示す図
【図18】改良されたスモールデータ上りリンク送信手順の例示的な一実装形態に係るＵＥの構造を示す図
【図19】改良されたスモールデータ上りリンク送信手順の例示的な一実装形態に係る、ＵＥの動作を示すフロー図
【図20】改良されたスモールデータ上りリンク送信手順の例示的な一実装形態に係る基地局の構造を示す図
【図21】改良されたスモールデータ上りリンク送信手順の例示的な一実装形態に係る、基地局の動作を示すフロー図
【図22】改良されたスモールデータ上りリンク送信手順の第１の解決策の一変形例に係る、ＵＥから基地局への複数のスモールデータ送信を示すシグナリング図
【図23】改良されたスモールデータ上りリンク送信手順の第１の解決策の他の変形例に係る、ＵＥから基地局への複数のスモールデータ送信を示すシグナリング図
【図24】改良されたスモールデータ上りリンク送信手順の第１の解決策の他の変形例に係る、ＵＥから基地局への複数のスモールデータ送信を示すシグナリング図
【図25】改良されたスモールデータ上りリンク送信手順の第１の解決策の例示的な一実装形態に係るＵＥ動作を示すフロー図
【図26】改良されたスモールデータ上りリンク送信手順の第１の解決策の例示的な一実装形態に係る基地局動作を示すフロー図
【図27】改良されたスモールデータ上りリンク送信手順の第２の解決策の一変形例に係る、ＵＥから基地局への複数のスモールデータ送信を示すシグナリング図
【図28】改良されたスモールデータ上りリンク送信手順の第２の解決策の他の変形例に係る、ＵＥから基地局への複数のスモールデータ送信を示すシグナリング図
【図29】改良されたスモールデータ上りリンク送信手順の第３の解決策の一変形例に係る、ＵＥから基地局への複数のスモールデータ送信を示すシグナリング図
【図30】改良されたスモールデータ上りリンク送信手順の第３の解決策の他の変形例による、ＵＥから基地局への複数のスモールデータ送信を示すシグナリング図
【図31】改良されたスモールデータ上りリンク送信手順の第４の解決策の一変形例に係る、ＵＥから基地局への複数のスモールデータ送信を示すシグナリング図
【発明を実施するための形態】
【0013】
＜５Ｇ ＮＲのシステムアーキテクチャおよびプロトコルスタック＞
【0014】
３ＧＰＰは、最大１００ＧＨｚの周波数で動作する新しい無線アクセス技術（ＮＲ）の開発を含む第５世代セルラー技術（単に「５Ｇ」と呼ばれる）の次のリリースに取り組んでいる。５Ｇ規格の最初のバージョンは、２０１７年の終わりに完了し、これにより、５Ｇ ＮＲ規格に準拠したスマートフォンの試験および商用展開に進むことができる。
【0015】
とりわけ、全体的なシステムアーキテクチャは、ｇＮＢを有するＮＧ－ＲＡＮ（次世代無線アクセスネットワーク：Next Generation - Radio Access Network）を想定しており、これらのｇＮＢは、ＮＧ無線アクセスユーザプレーン（ＳＤＡＰ／ＰＤＣＰ／ＲＬＣ／ＭＡＣ／ＰＨＹ）プロトコルおよび制御プレーン（ＲＲＣ）プロトコルを終端させる。ｇＮＢは、Ｘｎインターフェースによって互いに相互接続されている。また、ｇＮＢは、次世代（ＮＧ：Next Generation）インターフェースによってＮＧＣ(次世代コア：Next Generation Core）に、より具体的には、ＮＧ－ＣインターフェースによってＡＭＦ(アクセスおよびモビリティ管理機能：Access and Mobility Management Function）（例えば、ＡＭＦを実行する特定のコアエンティティ）に、また、ＮＧ－ＵインターフェースによってＵＰＦ(ユーザプレーン機能：User Plane Function）（例えば、ＵＰＦを実行する特定のコアエンティティ）にも接続されている。ＮＧ－ＲＡＮアーキテクチャを図１に示す（例えば、非特許文献２の第４節を参照）。
【0016】
ＮＲにおけるユーザプレーンプロトコルスタック（例えば、非特許文献２の第４．４．１節を参照）は、ＰＤＣＰ（パケットデータコンバージェンスプロトコル：Packet Data Convergence Protocol、非特許文献２の第６．４節を参照）サブレイヤ、ＲＬＣ（無線リンク制御：Radio Link Control、非特許文献２の第６．３節を参照）サブレイヤ、ＭＡＣ（媒体アクセス制御：Medium Access Control、非特許文献２の第６．２節を参照）サブレイヤを含み、これらのサブレイヤは、ネットワーク側ではｇＮＢにおいて終端する。これに加えて、ＰＤＣＰの上に、アクセス層（ＡＳ：access stratum）の新しいサブレイヤ（ＳＤＡＰ、サービスデータアダプテーションプロトコル：Service Data Adaptation Protocol）が導入される（例えば、非特許文献２の第６．５節を参照）。ＮＲにおいても制御プレーンプロトコルスタックが定義されている（例えば、非特許文献２の第４．４．２節を参照）。レイヤ２の機能の概要は、非特許文献２の第６節に記載されている。ＲＲＣレイヤの機能は、非特許文献２の第７節に記載されている。
【0017】
例えば、媒体アクセス制御（ＭＡＣ：Medium-Access-Control）レイヤは、論理チャネルの多重化、ならびに、様々なヌメロロジーの処理を含む、スケジューリングおよびスケジューリング関連機能を扱う。
【0018】
物理レイヤ（ＰＨＹ）は、例えば、符号化、ＰＨＹ ＨＡＲＱ処理、変調、マルチアンテナ処理、および適切な物理時間－周波数リソースへの信号のマッピングを担当する。また、物理レイヤは、物理チャネルへのトランスポートチャネルのマッピングも処理する。物理レイヤは、トランスポートチャネルの形でＭＡＣレイヤにサービスを提供する。物理チャネルは、特定のトランスポートチャネルの送信に使用される時間周波数リソースのセットに対応し、各トランスポートチャネルは、対応する物理チャネルにマッピングされる。例えば、物理チャネルは、アップリンクに対するＰＲＡＣＨ（物理ランダムアクセスチャネル：Physical Random Access Channel）、ＰＵＳＣＨ（物理アップリンク共有チャネル：Physical Uplink Shared Channel）、およびＰＵＣＣＨ（物理アップリンク制御チャネル：Physical Uplink Control Channel）、ならびに、ダウンリンクに対するＰＤＳＣＨ（物理ダウンリンク共有チャネル：Physical Downlink Shared Channel）、ＰＤＣＣＨ（物理ダウンリンク制御チャネル：Physical Downlink Control Channel）、およびＰＢＣＨ（物理ブロードキャストチャネル：Physical Broadcast Channel）である。
【0019】
ＮＲのユースケース／配置シナリオには、拡張モバイルブロードバンド（ｅＭＢＢ）、超高信頼・低遅延通信（ＵＲＬＬＣ）、大規模マシンタイプ通信（ｍＭＴＣ）が含まれ、これらのサービスは、データレート、レイテンシ、およびカバレッジに関して多様な要件を有する。例えば、ｅＭＢＢは、ＩＭＴ－Ａｄｖａｎｃｅｄによって提供される３倍のオーダーのピークデータレート（ダウンリンクが２０Ｇｂｐｓ、アップリンクが１０Ｇｂｐｓ）およびユーザ体感データレートをサポートすることが期待される。これに対して、ＵＲＬＬＣの場合、より厳しい要件として、極めて低いレイテンシ（ユーザプレーンのレイテンシはＵＬおよびＤＬそれぞれで０．５ｍｓ）と、高い信頼性（１ｍｓ内で１～１０－５）とが課せられる。さらに、ｍＭＴＣでは、高い接続密度（都市環境では１ｋｍ２あたり１，０００，０００個のデバイス）、過酷な環境における広いカバレッジ、およびデバイスコストを下げるための極めて長寿命のバッテリ（１５年）が、好ましくは要求され得る。
【0020】
したがって、あるユースケースに適したＯＦＤＭヌメロロジー（例えば、サブキャリア間隔（subcarrier spacing）、ＯＦＤＭシンボル持続時間、サイクリックプレフィックス（ＣＰ：cyclic prefix）持続時間、スケジューリング間隔あたりのシンボル数）が、別のユースケースではうまく機能しないことがある。例えば、低レイテンシのサービスでは、ｍＭＴＣサービスよりも、短いシンボル持続時間（したがって、より大きいサブキャリア間隔）、および／または、スケジューリング間隔（ＴＴＩとも称される）あたりの少ないシンボルが、好ましくは要求され得る。さらには、チャネルの遅延スプレッドが大きい配置シナリオでは、遅延スプレッドが短いシナリオよりも長いＣＰ持続時間が、好ましくは要求され得る。同程度のＣＰオーバーヘッドを維持するため、遅延スプレッドに応じてサブキャリア間隔を最適化するべきである。ＮＲでは、サブキャリア間隔の２つ以上の値がサポートされ得る。したがって、現在のところ、１５ｋＨｚ、３０ｋＨｚ、６０ｋＨｚ、…のサブキャリア間隔が検討されている。シンボル持続時間Ｔuとサブキャリア間隔Δｆは、式（Δｆ＝１／Ｔｕ）により、直接関係している。ＬＴＥシステムの場合と同様に、１個のＯＦＤＭ／ＳＣ－ＦＤＭＡシンボルの長さに対する１つのサブキャリアから構成される最小リソース単位を表すのに、「リソースエレメント」という用語を使用することができる。
【0021】
新無線システム５Ｇ－ＮＲでは、各ヌメロロジーおよびキャリアごとに、アップリンクおよびダウンリンクそれぞれにおいて、サブキャリアとＯＦＤＭシンボルのリソースグリッドが定義される。リソースグリッド内の各要素は、リソースエレメントと呼ばれ、周波数領域における周波数インデックスと時間領域におけるシンボル位置とに基づいて識別される（非特許文献３、例えば、第４節を参照）。例えば、ダウンリンク送信およびアップリンク送信は、持続時間が１０ｍｓのフレームに編成され、各フレームは、持続時間がそれぞれ１ｍｓである１０個のサブフレームから構成される。５Ｇ ＮＲの実装形態では、１サブフレームあたりの連続するＯＦＤＭシンボルの数は、サブキャリア間隔の設定に依存する。例えば、１５ｋＨｚのサブキャリア間隔の場合、１サブフレームは、１４個のＯＦＤＭシンボルを有する（通常のサイクリックプレフィックスを想定したＬＴＥ準拠の実装形態に類似する）。一方、３０ｋＨｚのサブキャリア間隔の場合、１サブフレームは、２つのスロットを有し、各スロットは、１４個のＯＦＤＭシンボルを含む。
【0022】
＜ＮＧ－ＲＡＮと５ＧＣとの間の５Ｇ ＮＲ機能の分割＞
【0023】
図２は、ＮＧ－ＲＡＮと５ＧＣとの間での機能の分割を示している。ＮＧ－ＲＡＮの論理ノードは、ｇＮＢまたはｎｇ－ｅＮＢである。５ＧＣの論理ノードは、ＡＭＦ、ＵＰＦ、およびＳＭＦである。
【0024】
特に、ｇＮＢおよびｎｇ－ｅＮＢは、以下の主要機能を処理する。
－ 無線ベアラ制御（Radio Bearer Control）や、無線アドミッション制御（Radio Admission Control）、接続モビリティ制御（Connection Mobility Control）、アップリンクおよびダウンリンクの両方向におけるＵＥへの動的なリソース割当て（スケジューリング）など、無線リソース管理（Radio Resource Management）の機能
－ データのＩＰヘッダ圧縮、暗号化、および完全性保護
－ ＵＥによって提供される情報からＡＭＦへのルーティングを決定できないときのＵＥのアタッチ時のＡＭＦの選択
－ ＵＰＦへのユーザプレーンのデータのルーティング
－ ＡＭＦへの制御プレーン情報のルーティング
－ 接続の確立および解放
－ ページングメッセージのスケジューリングおよび送信
－ （ＡＭＦまたはＯＡＭから送られる）システムブロードキャスト情報（のスケジューリングおよび送信
－ モビリティおよびスケジューリングのための測定および測定報告の設定
－ アップリンクにおけるトランスポートレベルのパケットマーキング
－ セッション管理
－ ネットワークスライシングのサポート
－ ＱｏＳフロー管理およびデータ無線ベアラへのマッピング
－ ＲＲＣ＿ＩＮＡＣＴＩＶＥ状態にあるＵＥのサポート
－ ＮＡＳメッセージの配信機能
－ 無線アクセスネットワークシェアリング
－ デュアルコネクティビティ
－ ＮＲとＥ－ＵＴＲＡ間の緊密なインターワーキング
－ 無線ベアラ制御（Radio Bearer Control）や、無線アドミッション制御（Radio Admission Control）、接続モビリティ制御（Connection Mobility Control）、アップリンクおよびダウンリンクの両方向におけるＵＥへの動的なリソース割当て（スケジューリング）など、無線リソース管理（Radio Resource Management）の機能
－ データのＩＰヘッダ圧縮、暗号化、および完全性保護
－ ＵＥによって提供される情報からＡＭＦへのルーティングを決定できないときのＵＥのアタッチ時のＡＭＦの選択
－ ＵＰＦへのユーザプレーンのデータのルーティング
－ ＡＭＦへの制御プレーン情報のルーティング
－ 接続の確立および解放
－ ページングメッセージのスケジューリングおよび送信
－ （ＡＭＦまたはＯＡＭから送られる）システムブロードキャスト情報（のスケジューリングおよび送信
－ モビリティおよびスケジューリングのための測定および測定報告の設定
－ アップリンクにおけるトランスポートレベルのパケットマーキング
－ セッション管理
－ ネットワークスライシングのサポート
－ ＱｏＳフロー管理およびデータ無線ベアラへのマッピング
－ ＲＲＣ＿ＩＮＡＣＴＩＶＥ状態にあるＵＥのサポート
－ ＮＡＳメッセージの配信機能
－ 無線アクセスネットワークシェアリング
－ デュアルコネクティビティ
－ ＮＲとＥ－ＵＴＲＡ間の緊密なインターワーキング
【0025】
アクセスおよびモビリティ管理機能（ＡＭＦ）は、以下の主要機能を処理する。
－ 非アクセス層（ＮＡＳ：Non-Access Stratum）シグナリングの終端
－ ＮＡＳシグナリングのセキュリティ
－ アクセス層（ＡＳ：Access Stratum）のセキュリティ制御
－ ３ＧＰＰアクセスネットワーク間のモビリティのためのコアネットワーク（ＣＮ：Core Network）ノード間シグナリング
－ アイドルモードＵＥの到達可能性（Reachability）（ページング再送の制御および実行を含む）
－ レジストレーションエリア（Registration Area）管理
－ システム内モビリティおよびシステム間モビリティのサポート
－ アクセス認証（Access Authentication）
－ ローミング権のチェックを含むアクセス認証
－ モビリティ管理制御（サブスクリプションおよびポリシー）
－ ネットワークスライシングのサポート
－ セッション管理機能（ＳＭＦ：Session Management Function）の選択
－ 非アクセス層（ＮＡＳ：Non-Access Stratum）シグナリングの終端
－ ＮＡＳシグナリングのセキュリティ
－ アクセス層（ＡＳ：Access Stratum）のセキュリティ制御
－ ３ＧＰＰアクセスネットワーク間のモビリティのためのコアネットワーク（ＣＮ：Core Network）ノード間シグナリング
－ アイドルモードＵＥの到達可能性（Reachability）（ページング再送の制御および実行を含む）
－ レジストレーションエリア（Registration Area）管理
－ システム内モビリティおよびシステム間モビリティのサポート
－ アクセス認証（Access Authentication）
－ ローミング権のチェックを含むアクセス認証
－ モビリティ管理制御（サブスクリプションおよびポリシー）
－ ネットワークスライシングのサポート
－ セッション管理機能（ＳＭＦ：Session Management Function）の選択
【0026】
さらに、ユーザプレーン機能（ＵＰＦ：User Plane Function）は、以下の主要機能を処理する。
－ ＲＡＴ内／ＲＡＴ間モビリティのためのアンカーポイント（適用可能時）
－ データネットワークとの相互接続の外部ＰＤＵセッションポイント
－ パケットのルーティングおよび転送
－ パケット検査およびポリシールール施行のユーザプレーン部分
－ トラフィック使用報告
－ データネットワークへのトラフィックフローのルーティングをサポートするためのアップリンク分類器（uplink classifier）
－ マルチホームＰＤＵセッションをサポートするためのブランチングポイント
－ ユーザプレーンのＱｏＳ処理（例えば、パケットフィルタリング、ゲーティング、ＵＬ／ＤＬレート強制）
－ アップリンクトラフィックの検証（ＳＤＦからＱｏＳフローへのマッピング）
－ ダウンリンクパケットのバッファリングおよびダウンリンクデータ通知のトリガリング
－ ＲＡＴ内／ＲＡＴ間モビリティのためのアンカーポイント（適用可能時）
－ データネットワークとの相互接続の外部ＰＤＵセッションポイント
－ パケットのルーティングおよび転送
－ パケット検査およびポリシールール施行のユーザプレーン部分
－ トラフィック使用報告
－ データネットワークへのトラフィックフローのルーティングをサポートするためのアップリンク分類器（uplink classifier）
－ マルチホームＰＤＵセッションをサポートするためのブランチングポイント
－ ユーザプレーンのＱｏＳ処理（例えば、パケットフィルタリング、ゲーティング、ＵＬ／ＤＬレート強制）
－ アップリンクトラフィックの検証（ＳＤＦからＱｏＳフローへのマッピング）
－ ダウンリンクパケットのバッファリングおよびダウンリンクデータ通知のトリガリング
【0027】
最後に、セッション管理機能（ＳＭＦ）は、以下の主要機能を処理する。
－ セッション管理
－ ＵＥ ＩＰアドレスの割当ておよび管理
－ ＵＰ機能の選択および制御
－ トラフィックを正しい宛先にルーティングするためのユーザプレーン機能（ＵＰＦ）におけるトラフィックステアリングの設定
－ ポリシー施行およびＱｏＳの制御部分
－ ダウンリンクデータ通知
－ セッション管理
－ ＵＥ ＩＰアドレスの割当ておよび管理
－ ＵＰ機能の選択および制御
－ トラフィックを正しい宛先にルーティングするためのユーザプレーン機能（ＵＰＦ）におけるトラフィックステアリングの設定
－ ポリシー施行およびＱｏＳの制御部分
－ ダウンリンクデータ通知
【0028】
＜ＲＲＣ接続の確立および再設定の手順＞
【0029】
図３は、ＵＥがＲＲＣ＿ＩＤＬＥからＲＲＣ＿ＣＯＮＮＥＣＴＥＤに遷移するときの、ＮＡＳ部分における、ＵＥ、ｇＮＢ、ＡＭＦ(５ＧＣエンティティ）の間のインタラクションを示している（非特許文献２を参照）。
【0030】
ＲＲＣは、ＵＥおよびｇＮＢの設定に使用される上位レイヤシグナリング（プロトコル）である。特に、この遷移では、ＡＭＦがＵＥコンテキストデータ（例えば、ＰＤＵセッションコンテキストや、セキュリティキー、ＵＥ無線能力、ＵＥセキュリティ能力などを含む）を作成し、それをＩＮＩＴＩＡＬ ＣＯＮＴＥＸＴ ＳＥＴＵＰ ＲＥＱＵＥＳＴ（初期コンテキストセットアップ要求）によってｇＮＢに送る。次に、ｇＮＢが、ＵＥとのＡＳセキュリティをアクティブにし、これは、ｇＮＢがＳｅｃｕｒｉｔｙＭｏｄｅＣｏｍｍａｎｄメッセージをＵＥに送信し、ＵＥがＳｅｃｕｒｉｔｙＭｏｄｅＣｏｍｐｌｅｔｅメッセージでｇＮＢに応答することによって実行される。その後、ｇＮＢは、再設定を実行してシグナリング無線ベアラ２（ＳＲＢ２）およびデータ無線ベアラ（ＤＲＢ：Data Radio Bearer）を確立し、これは、ｇＮＢがＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージをＵＥに送信し、これに応答してＵＥからＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎＣｏｍｐｌｅｔｅをｇＮＢが受信することによる。シグナリングのみの接続の場合、ＳＲＢ２およびＤＲＢが確立されないため、ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎに関連するこれらのステップはスキップされる。最後に、ｇＮＢは、確立手順が完了したことを、ＩＮＩＴＩＡＬ ＣＯＮＴＥＸＴ ＳＥＴＵＰ ＲＥＳＰＯＮＳＥ（初期コンテキストセットアップ応答）によってＡＭＦに通知する。
【0031】
したがって、本開示では、ｇＮｏｄｅＢとユーザ機器（ＵＥ）との間にシグナリング無線ベアラが確立されるように、動作中、ｇＮｏｄｅＢとの次世代（ＮＧ）接続を確立する制御回路と、動作中、そのＮＧ接続を介して初期コンテキストセットアップメッセージをｇＮｏｄｅＢに送信する送信機とを有する、第５世代コア（５ＧＣ）のエンティティ（例えば、ＡＭＦやＳＭＦなど）が提供される。特に、ｇＮｏｄｅＢは、リソース割当て設定情報要素を含む無線リソース制御（ＲＲＣ）シグナリングを、シグナリング無線ベアラを介してＵＥに送信する。次いで、ＵＥが、このリソース割当て設定に基づいてアップリンク送信またはダウンリンク受信を実行する。
【0032】
＜２０２０年以降のＩＭＴの使用シナリオ＞
【0033】
図４は、５Ｇ ＮＲのユースケースのいくつかを示している。第３世代パートナーシッププロジェクトのＮＲ（３ＧＰＰ ＮＲ：3rd generation partnership project new radio）では、ＩＭＴ－２０２０によって多種多様なサービスおよびアプリケーションをサポートするために想定される３つのユースケースが考慮されている。拡張モバイルブロードバンド（ｅＭＢＢ）のフェーズ１の仕様は決定された。現在および今後の作業としては、ｅＭＢＢサポートをさらに拡張することに加えて、超高信頼・低遅延通信（ＵＲＬＬＣ）および大規模マシンタイプ通信（ｍＭＴＣ）のための標準化が含まれる。図４は、２０２０年以降に想定されるＩＭＴの使用シナリオのいくつかの例を示している（例えば、非特許文献４の図２を参照）。
【0034】
ＵＲＬＬＣユースケースは、スループットやレイテンシ、可用性などの能力に関する厳しい要件を有し、工業的製造または生産プロセスの無線制御、遠隔医療手術、スマートグリッドにおける配電自動化、輸送の安全性など、将来の垂直アプリケーションを実現する手段の１つとして想定されている。ＵＲＬＬＣの超高信頼性は、非特許文献１によって設定される要件を満たすための技術を特定することによってサポートされる。リリース１５におけるＮＲ ＵＲＬＬＣの場合、重要な要件は、ユーザプレーンの目標レイテンシが、ＵＬ（アップリンク）に対して０．５ｍｓ、ＤＬ（ダウンリンク）に対して０．５ｍｓであることを含む。パケットの１回の送信における一般的なＵＲＬＬＣの要件は、１ｍｓのユーザプレーンレイテンシでパケットサイズ３２バイトの場合にＢＬＥＲ（ブロック誤り率）１Ｅ－５である。
【0035】
物理レイヤの観点から、信頼性を向上させる方法はいくつか考えられる。信頼性を向上させるための現在の範囲には、ＵＲＬＬＣのための個別のＣＱＩテーブルや、よりコンパクトなＤＣＩフォーマット、ＰＤＣＣＨの繰り返しなどを定義することが含まれる。しかし、（ＮＲ ＵＲＬＣの重要な要件について）ＮＲがさらに安定し、開発が進むにつれて、超高信頼性を実現するための範囲が広がり得る。リリース１５におけるＮＲ ＵＲＬＣＣの具体的なユースケースとしては、拡張現実／仮想現実（ＡＲ／ＶＲ）、ｅ－ヘルス、ｅ－セーフティ、およびミッションクリティカルなアプリケーションが挙げられる。
【0036】
さらに、ＮＲ ＵＲＬＣＣが対象とする技術強化は、レイテンシの改善および信頼性の向上を目標としている。レイテンシを改善するための技術強化としては、設定可能なヌメロロジー、柔軟なマッピングを使用する非スロットベースのスケジューリング、グラントフリー（設定済みグラント（configured grant））のアップリンク、データチャネルのスロットレベルの繰り返し、およびダウンリンクのプリエンプションが挙げられる。プリエンプションとは、リソースがすでに割り当てられている送信が中止され、すでに割り当てられているリソースが、後から要求された、より小さいレイテンシ／より高い優先度要件を有する別の送信に使用されることを意味する。したがって、すでに許可された送信が、より後の送信によってプリエンプトされる。プリエンプションは、特定のサービスタイプに関係なく適用される。例えば、サービスタイプＡ（ＵＲＬＣＣ）の送信を、サービスタイプＢ（ｅＭＢＢなど）の送信によってプリエンプトすることができる。信頼性向上に関する技術強化としては、１Ｅ－５の目標ＢＬＥＲのための専用ＣＱＩ／ＭＣＳテーブルが挙げられる。
【0037】
ｍＭＴＣ（大規模マシンタイプ通信）のユースケースは、非常に多数の接続されたデバイスが、一般には遅延の影響が小さい比較的少量のデータを送信することを特徴とする。デバイスは、低コストでありかつ極めて長いバッテリ寿命を有する必要がある。ＮＲの観点からは、非常に狭い帯域幅部分を利用することは、ＵＥの観点からの節電を達成して長いバッテリ寿命を可能にするための１つの可能な解決策である。
【0038】
上記のように、ＮＲにおける信頼性の範囲が広がることが予測される。あらゆるケース、特にＵＲＬＬＣおよびｍＭＴＣの場合に必要な１つの重要な要件は、高信頼性または超高信頼性である。無線の観点およびネットワークの観点から、信頼性を向上させるためのいくつかのメカニズムを考えることができる。一般には、信頼性の向上に役立つ可能性のある重要な領域がいくつか存在する。これらの領域としては、コンパクトな制御チャネル情報、データチャネル／制御チャネルの繰り返し、ならびに周波数領域、時間領域、および／または空間領域に関連するダイバーシチが挙げられる。これらの領域は、特定の通信シナリオには関係なく、一般的に信頼性に適用可能である。
【0039】
ＮＲ ＵＲＬＬＣの場合、例えば、工場自動化や輸送産業、電力供給など、より厳しい要件を有するさらなるユースケースが特定されている。より厳しい要件とは、ユースケースに応じて、より高い信頼性（最大１０６レベル）、より高い可用性、最大２５６バイトのパケットサイズ、数μｓオーダーの時刻同期（値は周波数範囲に応じて１～数μｓ）、０．５～１ｍｓオーダーの短いレイテンシ（特にユーザプレーンの目標レイテンシは０．５ｍｓ）である。
【0040】
さらに、ＮＲ ＵＲＬＬＣの場合、物理レイヤの観点からいくつかの技術強化が認識されている。特に、ＰＤＣＣＨ（物理ダウンリンク制御チャネル：Physical Downlink Control Channel）に関連する強化として、コンパクトなＤＣＩ、ＰＤＣＣＨの繰り返し、ＰＤＣＣＨ監視の増大などが挙げられる。また、ＵＣＩ（アップリンク制御情報：Uplink Control Information）に関連する強化として、ＨＡＲＱ（ハイブリッド自動再送要求：Hybrid Automatic Repeat Request）の強化およびＣＳＩフィードバックの強化が挙げられる。また、ミニスロットレベルのホッピングおよび再送信／繰り返しに関連するＰＵＳＣＨの強化も認識されている。「ミニスロット」という用語は、スロットよりも少ない数のシンボルを含む送信時間間隔（ＴＴＩ：Transmission Time Interval）を意味する（スロットは、１４個のシンボルを含む）。
【0041】
＜ＱｏＳ制御＞
【0042】
５Ｇ ＱｏＳ（サービス品質：Quality of Service）モデルは、ＱｏＳフローに基づいており、保証フロービットレートを必要とするＱｏＳフロー（ＧＢＲ ＱｏＳフロー）と、保証フロービットレートを必要としないＱｏＳフロー（非ＧＢＲ ＱｏＳフロー）の両方をサポートする。したがって、ＮＡＳレベルでは、ＱｏＳフローはＰＤＵセッションにおけるＱｏＳ差別化の最も細かい粒度である。ＱｏＳフローは、ＰＤＵセッション内では、ＮＧ－Ｕインターフェースを通じてカプセル化ヘッダ内で伝えられるＱｏＳフローＩＤ（ＱＦＩ）によって識別される。
【0043】
５ＧＣは、ＵＥごとに、１つまたは複数のＰＤＵセッションを確立する。ＮＧ－ＲＡＮは、ＵＥごとに、ＰＤＵセッションと一緒に少なくとも１つのデータ無線ベアラ（ＤＲＢ：Data Radio Bearer）を確立し、次に、そのＰＤＵセッションのＱｏＳフローのための追加のＤＲＢを、例えば、図３を参照しながら上記したように、設定することができる（いつ設定するかはＮＧ－ＲＡＮが決定する）。ＮＧ－ＲＡＮは、異なるＰＤＵセッションに属するパケットを異なるＤＲＢにマッピングする。ＵＥおよび５ＧＣにおけるＮＡＳレベルのパケットフィルタによって、ＵＬおよびＤＬのパケットがＱｏＳフローに関連付けられ、ＵＥおよびＮＧ－ＲＡＮにおけるＡＳレベルのマッピング規則によって、ＵＬおよびＤＬのＱｏＳフローがＤＲＢに関連付けられる。
【0044】
図５は、５Ｇ ＮＲの非ローミング基準アーキテクチャ（非特許文献５の第４．２．３節を参照）を示している。アプリケーション機能（ＡＦ：Application Function）（例えば、図４に例示的に記載されている５Ｇサービスを処理する外部アプリケーションサーバ）は、サービスを提供する目的で、３ＧＰＰコアネットワーク（Core Network）と対話する。例えば、トラフィックのルーティングに対するアプリケーションの影響をサポートしたり、ネットワーク公開機能（ＮＥＦ：Network Exposure Function）にアクセスしたり、またはポリシー制御（例えば、ＱｏＳ制御）のためのポリシーフレームワーク（ポリシー制御機能（ＰＣＦ）を参照）と対話する。事業者の配備に基づいて、事業者によって信頼されるものとみなされるアプリケーション機能（ＡＦ）を、関連するネットワーク機能（Network Function）と直接対話できるようにすることができる。ネットワーク機能に直接アクセスすることが事業者によって許可されていないアプリケーション機能（ＡＦ）は、ＮＥＦを介して外部の公開フレームワークを使用して、関連するネットワーク機能と対話する。
【0045】
図５は、５Ｇアーキテクチャのさらなる機能ユニット、すなわち、ネットワークスライス選択機能（ＮＳＳＦ：Network Slice Selection Function）、ネットワークリポジトリ機能（ＮＲＦ：Network Repository Function）、統一データ管理（ＵＤＭ：Unified Data Management）、認証サーバ機能（ＡＵＳＦ：Authentication Server Function）、アクセスおよびモビリティ管理機能（ＡＭＦ：Access and Mobility Management Function）、セッション管理機能（ＳＭＦ：Session Management Function）、およびデータネットワーク（ＤＮ：Data Network）（例えば、事業者のサービス、インターネットアクセスまたはサードパーティのサービス）を示している。コアネットワーク機能およびアプリケーションサービスのすべてまたは一部を、クラウドコンピューティング環境に配置して実行してもよい。
【0046】
したがって、本開示では、動作中、ＵＲＬＬＣサービス、ｅＭＢＢサービス、およびｍＭＴＣサービスの少なくとも１つに対するＱｏＳ要件を含む要求を５ＧＣの機能（例えば、ＮＥＦやＡＭＦ、ＳＭＦ、ＰＣＦ、ＵＰＦなど）の少なくとも１つに送信して、そのＱｏＳ要件に従ってｇＮｏｄｅＢとＵＥとの間の無線ベアラを含むＰＤＵセッションを確立する送信機と、動作中、確立されたＰＤＵセッションを使用して前記サービスを実行する制御回路と、を有するアプリケーションサーバ（例えば、５ＧアーキテクチャのＡＦ）が提供される。
【0047】
＜ランダムアクセス手順＞
【0048】
ＬＴＥと同様に、５Ｇ ＮＲでは、ＲＡＣＨ（ランダムアクセスチャネル：Random Access Channel）手順（または単にランダムアクセス手順）が提供される。例えば、ＲＡＣＨ手順は、ＵＥが、発見したセルにアクセスするために使用することができる。また、ＲＡＣＨ手順は、例えば、
● ハンドオーバーにおいて、新しいセルへの同期を確立するとき、
● デバイスからのアップリンク送信がない期間が長すぎるために同期が失われた場合に、現在のセルへのアップリンク同期を再確立するため、
● 専用のスケジューリング要求リソースがデバイスに設定されていない場合、アップリンクのスケジューリングを要求するため、
ＮＲ内の他のコンテキストでも使用することができる。
● ハンドオーバーにおいて、新しいセルへの同期を確立するとき、
● デバイスからのアップリンク送信がない期間が長すぎるために同期が失われた場合に、現在のセルへのアップリンク同期を再確立するため、
● 専用のスケジューリング要求リソースがデバイスに設定されていない場合、アップリンクのスケジューリングを要求するため、
ＮＲ内の他のコンテキストでも使用することができる。
【0049】
ランダムアクセス手順（非特許文献２の第９．２．６節を参照）を実行するようにＵＥをトリガーしうるイベントは、以下を含む多数がある。ランダムアクセス手順は、多くのイベント、
－ ＲＲＣ＿ＩＤＬＥからの初期アクセス
－ ＲＲＣ接続再確立手順
－ ＵＬ同期状態が「非同期」であるときＲＲＣ＿ＣＯＮＮＥＣＴＥＤ時にＤＬデータまたはＵＬデータが到着すること
－ ＳＲ（スケジューリング要求：scheduling request）用のＰＵＣＣＨリソースが利用可能ではないときＲＲＣ＿ＣＯＮＮＥＣＴＥＤ時にＵＬデータが到着すること
－ ＳＲの失敗
－ 同期的な再構成（例：ハンドオーバー）時にＲＲＣによって要求されること
－ ＲＲＣ＿ＩＮＡＣＴＩＶＥから遷移すること
－ セカンダリＴＡＧのタイムアライメントを確立すること
－ その他のＳＩの要求（７．３節を参照）
－ ビームの障害回復
－ ＳｐＣｅｌｌでＵＬ ＬＢＴが連続的に失敗すること
によってトリガーされる。
－ ＲＲＣ＿ＩＤＬＥからの初期アクセス
－ ＲＲＣ接続再確立手順
－ ＵＬ同期状態が「非同期」であるときＲＲＣ＿ＣＯＮＮＥＣＴＥＤ時にＤＬデータまたはＵＬデータが到着すること
－ ＳＲ（スケジューリング要求：scheduling request）用のＰＵＣＣＨリソースが利用可能ではないときＲＲＣ＿ＣＯＮＮＥＣＴＥＤ時にＵＬデータが到着すること
－ ＳＲの失敗
－ 同期的な再構成（例：ハンドオーバー）時にＲＲＣによって要求されること
－ ＲＲＣ＿ＩＮＡＣＴＩＶＥから遷移すること
－ セカンダリＴＡＧのタイムアライメントを確立すること
－ その他のＳＩの要求（７．３節を参照）
－ ビームの障害回復
－ ＳｐＣｅｌｌでＵＬ ＬＢＴが連続的に失敗すること
によってトリガーされる。
【0050】
移動端末のアップリンク送信が時刻同期している場合には、アップリンク送信のために移動端末をスケジューリングすることができる。したがって、ランダムアクセスチャネル（ＲＡＣＨ）手順は、同期していない移動端末（ＵＥ）とアップリンク無線アクセスの直交伝送の間のインターフェースとしての役割を果たす。ランダムアクセスは、例えば、アップリンクの同期をまだ取得していない、あるいは失ったユーザ機器のアップリンク時刻同期（uplink time synchronization）を達成するために使用される。ユーザ機器がアップリンク同期を取得すると、基地局は、そのユーザ機器のためにアップリンク送信リソースをスケジューリングすることができる。ランダムアクセスに関連する１つのシナリオは、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態にあるユーザ機器が、現在のサービングセルから新しいターゲットセルにハンドオーバーし、ターゲットセルにおいてアップリンク時刻同期を達成するためにランダムアクセス手順を実行する場合である。
【0051】
ランダムアクセス手順には、コンテンションベースで（すなわち、本質的に衝突のリスクを伴う）アクセスを可能にする手順と、コンテンションフリーで（競合なしで）アクセスを可能にする手順の２種類がある。ランダムアクセス手順の例示的な定義は、非特許文献６の第５．１節に記載されている。
【0052】
次に、図６および図７を参照しながら、ＲＡＣＨ手順についてより詳細に説明する。以下では、図６を参照しながら、コンテンションベースのランダムアクセス手順についてより詳細に説明する。この手順は、４つの「ステップ」から構成され、したがって、例えば、４ステップＲＡＣＨ手順と称することができる。最初に、ユーザ機器は、物理ランダムアクセスチャネル（ＰＲＡＣＨ）上でランダムアクセスプリアンブルを基地局に送信する（すなわち、ＲＡＣＨ手順のメッセージ１）。基地局は、ＲＡＣＨプリアンブルを検出した後、プリアンブルが検出された時間周波数およびスロットを特定する（ランダムアクセス）ＲＡ－ＲＮＴＩを使用してＰＤＣＣＨ上でアドレッシングされるＰＤＳＣＨ（物理ダウンリンクリンク共有チャネル：Physical Downlink Shared Channel）上でランダムアクセス応答（ＲＡＲ：Random Access Response）メッセージ（ＲＡＣＨ手順のメッセージ２）を送信する。複数のユーザ機器が同じＰＲＡＣＨリソースで同じＲＡＣＨプリアンブルを送信した場合（これは衝突とも呼ばれる）、それらのユーザ機器は、同じランダムアクセス応答メッセージを受信する。ＲＡＲメッセージは、検出されたＲＡＣＨプリアンブルと、受信したプリアンブルのタイミングに基づくその後のアップリンク送信の同期のためのタイミングアライメントコマンド（ＴＡコマンド）と、最初のスケジューリングされる送信を送るための最初のアップリンクリソース割当て（グラント）と、Ｔ－ＣＲＮＴＩ（一時セル無線ネットワーク一時識別子：Temporary Cell Radio Network Temporary Identifier）の割当て、を伝えることができる。このＴ－ＣＲＮＴＩは、ＲＡＣＨ手順が終了するまで、ＲＡＣＨプリアンブルが検出された移動体のアドレスとして基地局によって使用される、なぜなら、この時点で、基地局は、移動体の「本当の」ＩＤを認識していないためである。
【0053】
ユーザ機器は、基地局によって設定され得る所定の時間ウィンドウ（例えば、ＲＡＲ受信ウィンドウと呼ばれる）内で、ランダムアクセス応答メッセージを受信するためにＰＤＣＣＨを監視する。基地局から受信したＲＡＲメッセージに応答して、ユーザ機器は、最初のスケジューリングされたアップリンク送信を、ランダムアクセス応答内のグラントによって割り当てられた無線リソース上で送信する。このスケジューリングされたアップリンク送信は、ＲＲＣ接続要求、ＲＲＣ再開要求、またはバッファ状態報告などの特定の機能を有する実際のメッセージを伝える。
【0054】
ＲＡＣＨ手順の最初のメッセージにおいてプリアンブルの衝突が発生した場合、すなわち、複数のユーザ機器が同じＰＲＡＣＨリソース上で同じプリアンブルを送信した場合、衝突したユーザ機器は、ランダムアクセス応答内で同じＴ－ＣＲＮＴＩを受信し、ＲＡＣＨ手順の第３のステップにおいてスケジューリングされた送信を送信するときにも同じアップリンクリソースにおいて衝突する。１基のユーザ機器からのスケジューリングされた送信が基地局によって正常に復号された場合、他のユーザ機器についてはコンテンションが未解決のままである。このタイプのコンテンションを解決するために、基地局は、Ｃ－ＲＮＴＩまたは一時Ｃ－ＲＮＴＩ宛にアドレッシングされたコンテンション解決メッセージ（第４のメッセージ）を送信する。これで手順は終了する。
【0055】
図７は、コンテンションフリーのランダムアクセス手順を示しており、この手順は、コンテンションベースのランダムアクセス手順と比較して簡略化されている。基地局は、衝突（すなわち、複数のユーザ機器が同じプリアンブルを送信する）の危険性がないように、最初のステップで、ランダムアクセスに使用する専用のプリアンブルをユーザ機器に提供する。したがって、ユーザ機器は、基地局によってシグナリングされたプリアンブルを、その後、ＰＲＡＣＨリソース上でアップリンクにおいて送信する。コンテンションフリーのランダムアクセスでは、複数のＵＥが同じプリアンブルを送信するケースが回避されるため、コンテンションフリーのランダムアクセス手順は、本質的には、ランダムアクセス応答がＵＥによって正常に受信された後に終了する。
【0056】
３ＧＰＰは、５Ｇ ＮＲ用の２ステップ（コンテンションベース）ＲＡＣＨ手順も定義しており、この手順では、４ステップのＬＴＥ／ＮＲ ＲＡＣＨ手順におけるメッセージ１およびメッセージ３に対応するメッセージ１（ＭｓｇＡと呼ばれる）が、最初に送信される。２ステップＲＡＣＨタイプのＭｓｇＡは、物理ランダムアクセスチャネル（ＰＲＡＣＨ）上のプリアンブルと、物理アップリンク共有チャネル（ＰＵＳＣＨ）上のペイロードを含む。ＭｓｇＡを送信した後、ＵＥは、設定された時間ウィンドウ内で、ｇＮＢからの応答がないか監視する。ｇＮＢは、４ステップＬＴＥ／ＮＲ ＲＡＣＨ手順のメッセージ２およびメッセージ４に対応するメッセージ２（ＭｓｇＢと呼ばれる）で応答する。このＭｓｇＢは、例えば、成功ランダムアクセス応答（ＲＡＲ）、フォールバックＲＡＲ、およびオプションとしてバックオフ指示情報を含むことができる。成功ＲＡＲを受信してコンテンションの解決に成功した場合、ＵＥは、ランダムアクセス手順を終了する。一方、ＭｓｇＢにおいてフォールバックＲＡＲを受信した場合、ＵＥは、（４ステップＲＡＣＨ手順と同様に）メッセージ３の送信を実行し、コンテンション解決を監視する。２ステップＲＡＣＨ手順ではさらにいくつかの例示的な想定がなされ、例えば、ＵＥは、ＲＡＣＨタイプ（例えば、２ステップＲＡＣＨ）を決定した後、失敗するまで同じＲＡＣＨタイプを再試行し続ける。しかしながら、ＵＥがＭｓｇＡの送信を特定の回数だけ再試行した後に４ステップＲＡＣＨ手順に切り替えることも可能である。
【0057】
さらに、２ステップＲＡＣＨ手順および４ステップＲＡＣＨ手順を実行するために使用される、互いに排他的である無線リソースを、ネットワークが半静的に決定してもよい。ＲＡＣＨ手順における最初のメッセージの送信に使用される無線リソースは、少なくともＲＡＣＨ機会（RACH occasion）およびプリアンブルを含む。例えば、２ステップＲＡＣＨ手順では、最初のメッセージＭｓｇＡは、ＰＲＡＣＨリソース（例えば、ＲＡＣＨ機会およびプリアンブル）のみならず、関連するＰＵＳＣＨリソースも使用する。
【0058】
一般に、ＲＡＣＨプリアンブルについては、例えば、非特許文献３の「表６．３．３．２－２：ＦＲ１およびペアスペクトラム／補足アップリンクのランダムアクセス設定（Random access configurations for FR1 and paired spectrum/supplementary uplink）」および第６．３．３．２節「物理リソースへのマッピング（Mapping to physical resources）」を参照されたい。
【0059】
＜ＲＲＣ状態（ＲＲＣ＿Ｃｏｎｎｅｃｔｅｄ、ＲＲＣ＿Ｉｎａｃｔｉｖｅ）＞
【0060】
ＬＴＥでは、ＲＲＣ状態マシン（RRC state machine）は、ＲＲＣアイドル状態（RRC idle state）（主として、高い電力節約、ＵＥ自律モビリティ、コアネットワークとのＵＥ接続が確立されていない、ことを特徴とする）と、ＲＲＣ接続状態（RRC connected state）の２つのみから構成されており、ＲＲＣ接続状態では、ロスレスサービス継続をサポートするためにモビリティがネットワークによって制御されている間、ＵＥは、ユーザプレーンデータを送信することができる。５Ｇ ＮＲでは、ＬＴＥに関連するＲＲＣ状態マシンを、以下で説明するように、非アクティブ状態（例えば、非特許文献７の図４．２．１－１および図４．２．１－２を参照）によって拡張することができる。
【0061】
ＮＲ ５ＧのＲＲＣ（非特許文献７の第４節を参照）では、次の３つの状態、すなわち、ＲＲＣ Ｉｄｌｅ、ＲＲＣ Ｉｎａｃｔｉｖｅ、およびＲＲＣ Ｃｏｎｎｅｃｔｅｄがサポートされる。ＵＥは、ＲＲＣ接続が確立されているときには、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態またはＲＲＣ＿ＩＮＡＣＴＩＶＥ状態のいずれかである。そうでない場合、すなわち、ＲＲＣ接続が確立されていない場合、ＵＥは、ＲＲＣ＿ＩＤＬＥ状態である。図８に示したように、以下の状態遷移が可能である。
● 例えば「接続確立」手順に従って、ＲＲＣ＿ＩＤＬＥからＲＲＣ＿ＣＯＮＮＥＣＴＥＤ
● 例えば「接続解放」手順に従って、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤからＲＲＣ＿ＩＤＬＥ
● 例えば「中断による接続解放」手順に従って、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤからＲＲＣ＿ＩＮＡＣＴＩＶＥ
● 例えば「接続再開」手順に従って、ＲＲＣ＿ＩＮＡＣＴＩＶＥからＲＲＣ＿ＣＯＮＮＥＣＴＥＤ
● 例えば「接続解放」手順に従って、ＲＲＣ＿ＩＮＡＣＴＩＶＥからＲＲＣ＿ＩＤＬＥ（単方向）
● 例えば「接続確立」手順に従って、ＲＲＣ＿ＩＤＬＥからＲＲＣ＿ＣＯＮＮＥＣＴＥＤ
● 例えば「接続解放」手順に従って、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤからＲＲＣ＿ＩＤＬＥ
● 例えば「中断による接続解放」手順に従って、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤからＲＲＣ＿ＩＮＡＣＴＩＶＥ
● 例えば「接続再開」手順に従って、ＲＲＣ＿ＩＮＡＣＴＩＶＥからＲＲＣ＿ＣＯＮＮＥＣＴＥＤ
● 例えば「接続解放」手順に従って、ＲＲＣ＿ＩＮＡＣＴＩＶＥからＲＲＣ＿ＩＤＬＥ（単方向）
【0062】
新しいＲＲＣ状態であるＲＲＣ Ｉｎａｃｔｉｖｅは、ｅＭＢＢ（enhanced Mobile Broadband：拡張モバイルブロードバンド）、ｍＭＴＣ（massive Machine Type Communications：大規模マシンタイプ通信）、ＵＲＬＬＣ（Ultra-Reliable and Low-Latency Communications：超高信頼・低遅延通信）など、シグナリング、省電力、遅延などに関して極めて異なる要件を有する幅広いサービスをサポートするときに恩恵が提供されるように、５Ｇ ３ＧＰＰの新しい無線技術用に定義されたものである。したがって、新しいＲＲＣ Ｉｎａｃｔｉｖｅ状態は、無線アクセスネットワークおよびコアネットワークにおけるシグナリング、消費電力、リソースコストを最小限に抑えることができる一方で、例えば、低遅延でデータ転送を開始できるように設計される。
【0063】
例示的な５Ｇ ＮＲの実装形態によれば、これらの異なる状態は、以下のように特徴付けられる（非特許文献７の第４．２．１節を参照）。
【0064】
「ＲＲＣ＿ＩＤＬＥ：
－ ＵＥ固有のＤＲＸを上位レイヤによって設定することができる
－ ネットワーク設定に基づいてＵＥが制御するモビリティ
－ ＵＥは、
－ ＤＣＩを通じてＰ－ＲＮＴＩを使用して送信されるショートメッセージ（Short Message）を監視する（第６．５節を参照）
－ ５Ｇ－Ｓ－ＴＭＳＩを使用するＣＮページングにおいてページングチャネル（Paging channel）を監視する、
－ 隣接するセルの測定およびセルの（再）選択を実行する
－ システム情報を取得し、ＳＩ要求を送信することができる（設定されている場合）
－ ロギングされる測定が設定されたＵＥに対して位置および時間と共に利用可能な測定のロギングを実行する。
－ ＲＲＣ＿ＩＮＡＣＴＩＶＥ：
－ ＵＥ固有のＤＲＸを、上位レイヤまたはＲＲＣレイヤによって設定することができる
－ ネットワーク設定に基づいてＵＥが制御するモビリティ
－ ＵＥは、ＵＥ Ｉｎａｃｔｉｖｅ ＡＳコンテキストを格納する
－ ＲＡＮベースの通知領域（RAN-based notification area）がＲＲＣレイヤによって設定される
－ ＵＥは、
－ ＤＣＩを通じてＰ－ＲＮＴＩを使用して送信されるショートメッセージ（Short Message）を監視する（第６．５節を参照）
－ ５Ｇ－Ｓ－ＴＭＳＩを使用するＣＮページングおよび完全なＩ－ＲＮＴＩ（full-RNTI）を使用するＲＡＮページングにおいてページングチャネル（Paging channel）を監視する
－ 隣接するセルの測定およびセルの（再）選択を実行する
－ ＲＡＮベースの通知領域の更新を定期的に実行し、設定されたＲＡＮベースの通知領域外に移動したときにも実行する
－ システム情報を取得し、ＳＩ要求を送信することができる（設定されている場合）
－ ロギングされる測定が設定されたＵＥに対して位置および時間と共に利用可能な測定のロギングを実行する。
－ ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ：
－ ＵＥは、ＡＳコンテキストを格納する
－ ＵＥとの間でのユニキャストデータの転送
－ 下位レイヤにおいて、ＵＥにＵＥ固有のＤＲＸを設定することができる
－ ＣＡをサポートするＵＥの場合、帯域幅を広げるためにＳｐＣｅｌｌとアグリゲートされた１つ以上のＳｃｅｌｌを使用する
－ ＤＣをサポートするＵＥの場合、帯域幅を広げるためにＭＣＧとアグリゲートされた１つのＳＣＧを使用する
－ ＮＲ内およびＥ－ＵＴＲＡとの間でのネットワーク制御されるモビリティ
－ ＵＥは、
－ 設定されている場合、ＤＣＩを通じてＰ－ＲＮＴＩを使用して送信されるショートメッセージ（Short Message）を監視する（第６．５節を参照）
－ 共有データチャネルに関連付けられる制御チャネルを監視し、データがスケジューリングされているかどうかを判定する
－ チャネル品質およびフィードバック情報を提供する
－ 隣接セルの測定および測定報告を実行する
－ システム情報を取得する
－ 利用可能な位置の報告と共にＭＤＴ測定を即時実行する。」
－ ＵＥ固有のＤＲＸを上位レイヤによって設定することができる
－ ネットワーク設定に基づいてＵＥが制御するモビリティ
－ ＵＥは、
－ ＤＣＩを通じてＰ－ＲＮＴＩを使用して送信されるショートメッセージ（Short Message）を監視する（第６．５節を参照）
－ ５Ｇ－Ｓ－ＴＭＳＩを使用するＣＮページングにおいてページングチャネル（Paging channel）を監視する、
－ 隣接するセルの測定およびセルの（再）選択を実行する
－ システム情報を取得し、ＳＩ要求を送信することができる（設定されている場合）
－ ロギングされる測定が設定されたＵＥに対して位置および時間と共に利用可能な測定のロギングを実行する。
－ ＲＲＣ＿ＩＮＡＣＴＩＶＥ：
－ ＵＥ固有のＤＲＸを、上位レイヤまたはＲＲＣレイヤによって設定することができる
－ ネットワーク設定に基づいてＵＥが制御するモビリティ
－ ＵＥは、ＵＥ Ｉｎａｃｔｉｖｅ ＡＳコンテキストを格納する
－ ＲＡＮベースの通知領域（RAN-based notification area）がＲＲＣレイヤによって設定される
－ ＵＥは、
－ ＤＣＩを通じてＰ－ＲＮＴＩを使用して送信されるショートメッセージ（Short Message）を監視する（第６．５節を参照）
－ ５Ｇ－Ｓ－ＴＭＳＩを使用するＣＮページングおよび完全なＩ－ＲＮＴＩ（full-RNTI）を使用するＲＡＮページングにおいてページングチャネル（Paging channel）を監視する
－ 隣接するセルの測定およびセルの（再）選択を実行する
－ ＲＡＮベースの通知領域の更新を定期的に実行し、設定されたＲＡＮベースの通知領域外に移動したときにも実行する
－ システム情報を取得し、ＳＩ要求を送信することができる（設定されている場合）
－ ロギングされる測定が設定されたＵＥに対して位置および時間と共に利用可能な測定のロギングを実行する。
－ ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ：
－ ＵＥは、ＡＳコンテキストを格納する
－ ＵＥとの間でのユニキャストデータの転送
－ 下位レイヤにおいて、ＵＥにＵＥ固有のＤＲＸを設定することができる
－ ＣＡをサポートするＵＥの場合、帯域幅を広げるためにＳｐＣｅｌｌとアグリゲートされた１つ以上のＳｃｅｌｌを使用する
－ ＤＣをサポートするＵＥの場合、帯域幅を広げるためにＭＣＧとアグリゲートされた１つのＳＣＧを使用する
－ ＮＲ内およびＥ－ＵＴＲＡとの間でのネットワーク制御されるモビリティ
－ ＵＥは、
－ 設定されている場合、ＤＣＩを通じてＰ－ＲＮＴＩを使用して送信されるショートメッセージ（Short Message）を監視する（第６．５節を参照）
－ 共有データチャネルに関連付けられる制御チャネルを監視し、データがスケジューリングされているかどうかを判定する
－ チャネル品質およびフィードバック情報を提供する
－ 隣接セルの測定および測定報告を実行する
－ システム情報を取得する
－ 利用可能な位置の報告と共にＭＤＴ測定を即時実行する。」
【0065】
ＲＲＣ Ｉｎａｃｔｉｖｅ状態の特徴によれば、非アクティブＵＥに対して、ＲＡＮおよびコアネットワークとの接続（ユーザプレーンと制御プレーンの両方）が維持される。より具体的には、ＲＲＣ Ｉｎａｃｔｉｖｅでは、接続は依然として存在するが中断されている、言い換えれば、接続はもはや有効ではない。これに対して、ＲＲＣ Ｃｏｎｎｅｃｔｅｄ状態では、接続は存在し、例えば、データ送信に使用されるという意味でアクティブである。ＲＲＣ Ｉｄｌｅ状態では、ＵＥは、ＲＡＮおよびコアネットワークとのＲＲＣ接続を有さず、このことは、例えば、無線基地局が、ＵＥのコンテキストを有さず、例えば、ＵＥの識別情報を認識しておらず、ＵＥによって送信されたデータを正しく復号できるためのＵＥに関するセキュリティパラメータを有さない（セキュリティは、例えば、送信データの完全性を保証する）ことも意味する。ＵＥのコンテキストは、コアネットワークにおいて利用可能であり得るが、最初に無線基地局によって取得されなければならない。
【0066】
さらに、無線セル内のユーザ機器のためのページングメカニズム（例えば、通知メカニズムとも呼ばれる）は、いわゆる無線アクセスネットワーク（ＲＡＮ）ベースの通知領域（略してＲＮＡ）に基づく。無線アクセスネットワークは、ユーザ機器が位置している現在のＲＮＡを認識しているべきであり、ユーザ機器は、様々なＲＮＡ間を移動するＵＥを追跡するようにｇＮＢを支援することができる。ＲＮＡは、ＵＥ固有とすることができる。
【0067】
以下では、ＵＥがＲＲＣ＿Ｉｎａｃｔｉｖｅ状態からＲＲＣ＿Ｃｏｎｎｅｃｔｅｄ状態に遷移するためのＲＲＣ再開手順の一例（非特許文献７の第５．３．１３節を参照）について、図９を参照しながら説明する。この手順の目的は、中断されたＲＲＣ接続を再開すること（シグナリング無線ベアラおよびデータ無線ベアラの再開を含みうる）である。
【0068】
この手順では、ＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔメッセージまたはＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔ１メッセージのいずれかを送信することができる。ＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔメッセージを送信するときには、ＵＥの識別情報（例示的に「ｒｅｓｕｍｅＩｄｅｎｔｉｔｙ」と呼ばれる）としてショートＩ－ＲＮＴＩ（例えば、短縮された（Truncated）Ｉ－ＲＮＴＩ）が使用される。ＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔ１メッセージを送信するときには、ＵＥの識別情報（例示的に「ｒｅｓｕｍｅＩｄｅｎｔｉｔｙ」と呼ばれる）として完全なＩ－ＲＮＴＩが使用される。ＵＥは、ＳＩＢ１における指示情報「ｕｓｅＦｕｌｌＲｅｓｕｍｅＩＤ」を確認し、ＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔメッセージまたはＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔ１メッセージのいずれかを送信するように決定する。「ｕｓｅＦｕｌｌＲｅｓｕｍｅＩＤ」が「ｔｒｕｅ」を示している場合、ＵＥは、完全なＩ－ＲＮＴＩを使用してＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔ１を送信し、そうでない場合、ＵＥは、ショートＩ－ＲＮＴＩを使用してＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔを送信する。ＵＥがＲＲＣ再開手順において実行するアクションには（非特許文献７の第５．３．１３．４節を参照）、ＳＲＢ２およびすべてのＤＲＢ（これらはＲＲＣ Ｉｎａｃｔｉｖｅ状態に遷移したときに中断された（以下の解放手順を参照））を再開することが含まれる。
【0069】
また、ＲＲＣ再開手順は、設定されているＲＮＡの外にＵＥが移動したときにＲＮＡの更新を実行するために使用することもできる。この場合、ネットワークは、図１０に示すように、ＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔ／ＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔ１メッセージに対する応答として、ＲＲＣＲｅｓｕｍｅの代わりにＲＲＣＲｅｌｅａｓｅを送信する。ＵＥは、ＲＲＣＲｅｌｅａｓｅメッセージを受信した後、ＲＲＣ＿ＩＮＡＣＴＩＶＥに留まる。
【0070】
以下では、ＵＥがＲＲＣ＿Ｃｏｎｎｅｃｔｅｄ状態からＲＲＣ Ｉｎａｃｔｉｖｅ状態に遷移するためのその後のＲＲＣ接続解放手順の一例について（非特許文献７の第５．３．８節を参照）、図１１を参照しながら説明する。この手順の目的は、ＲＲＣ接続を解放すること、またはＲＲＣ接続を中断することである。例えば、ネットワークは、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤにあるＵＥをＲＲＣ＿ＩＤＬＥまたはＲＲＣ＿ＩＮＡＣＴＩＶＥに遷移させるためにＲＲＣ接続解放手順を開始する。ＲＲＣ接続解放手順においてＵＥが実行するアクションには（非特許文献７の第５．３．８．３節を参照）、中断によって解放が行われる場合（例：ＲＲＣＲｅｌｅａｓｅがｓｕｓｐｅｎｄＣｏｎｆｉｇを含む）、ＳＲＢ０を除くすべてのＳＲＢ（シグナリング無線ベアラ：Signaling Radio Bearer）およびＤＲＢ（データ無線ベアラ：Data Radio Bearer）を中断することが含まれる。したがって、ＲＲＣ Ｉｎａｃｔｉｖｅ状態にあるＵＥは、中断されていないＤＲＢまたはアクティブなＤＲＢを有さない（ＵＥは中断されたＤＲＢのみを有する）。ＳＲＢ０は、ＲＲＣ Ｉｎａｃｔｉｖｅ状態であってもアクティブに維持され、例えば、ＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔ、ＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔ１、ＲＲＣＳｅｔｕｐＲｅｑｕｅｓｔなどのＲＲＣメッセージを伝えるときに、ＲＡＣＨ手順を実行するためにＵＥによって使用することができる。
【0071】
＜スモールデータ送信＞
【0072】
本開示で対象とするスモールデータ送信の特徴は、ＵＬ／ＤＬにおけるデータバーストが小さく、オプションとして相当に頻度が低く、遅延に関する厳密な要件がない、という特徴を有するあらゆるサービスを指す。例えば、ＵＥが（例えば、ＲＡＣＨにおいて、下記参照）１回の送信で送信できるほど小さい１回のデータ送信は、スモールデータ送信とみなすことができる。次の表は、トラフィック特性の典型的な非限定的な例をまとめたものである（非特許文献８の第５節を参照）。
【0073】
【表1】
【0074】
別の可能な例示的な定義は、ｇＮＢの設定に依存することができる。例えば、ｇＮＢは、特定のしきい値（例えば、１０００Ｋバイト）未満のデータをスモールデータとみなすことができ、一方、そのしきい値を超えるデータはスモールデータとみなされないと定義することができる。このしきい値は、例えば、バッファの状態に関連して定義することができる。
【0075】
これに代えて、スモールデータとは何かという定義を、適切な規格によって固定することもでき、例えば、上述と同様のデータ量のしきい値を規定する。
【0076】
＜ＲＲＣ ＩＮＡＣＴＩＶＥ状態にあるＵＥによるスモールデータ送信＞
【0077】
より詳細には、５Ｇ ＮＲでは、ＲＲＣ＿ＩＮＡＣＴＩＶＥ状態がサポートされ、（周期的および／または非周期的な）低頻度のデータ送信を有するＵＥは、一般にネットワークによってＲＲＣ＿ＩＮＡＣＴＩＶＥ状態に維持される。リリース１６までは、ＲＲＣ＿ＩＮＡＣＴＩＶＥ状態ではデータ送信がサポートされない。したがって、ＵＥは、ＤＬ（ＭｏｂｉｌｅＴｅｒｍｉｎａｔｅｄ）およびＵＬ（ＭｏｂｉｌｅＯｒｉｇｉｎａｔｅｄ）データに対して、接続を再開する（例えば、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態に遷移する）必要がある。データパケットがどんなに小さくても頻度が低い場合でも、接続の確立（または再開）およびその後のＲＲＣ＿ＩＮＡＣＴＩＶＥ状態への解放が、データ送信のたびに発生する。結果として不要な消費電力およびシグナリングオーバーヘッドが生じる。
【0078】
小さくかつ頻度が低いデータトラフィックの具体的な例としては、以下のユースケースが挙げられる。
－ スマートフォンのアプリケーション：
〇 インスタントメッセージングサービス（ｗｈａｔｓａｐｐ、ＱＱ、ｗｅｃｈａｔなど）からのトラフィック
〇 ＩＭ／メールクライアントおよび他のアプリからのハートビート／キープアライブトラフィック
〇 様々なアプリケーションからのプッシュ通知
－ スマートフォン以外のアプリケーション：
〇 ウェアラブル端末からのトラフィック（定期的な位置情報など）
〇 センサー（温度、圧力の測定値を定期的またはイベントトリガー方式で送信する産業用無線センサーネットワークなど）。
〇 メーターの測定値を定期的に送信するスマートメーターおよびスマートメーターネットワーク
－ スマートフォンのアプリケーション：
〇 インスタントメッセージングサービス（ｗｈａｔｓａｐｐ、ＱＱ、ｗｅｃｈａｔなど）からのトラフィック
〇 ＩＭ／メールクライアントおよび他のアプリからのハートビート／キープアライブトラフィック
〇 様々なアプリケーションからのプッシュ通知
－ スマートフォン以外のアプリケーション：
〇 ウェアラブル端末からのトラフィック（定期的な位置情報など）
〇 センサー（温度、圧力の測定値を定期的またはイベントトリガー方式で送信する産業用無線センサーネットワークなど）。
〇 メーターの測定値を定期的に送信するスマートメーターおよびスマートメーターネットワーク
【0079】
以下では、ＲＲＣ Ｃｏｎｎｅｃｔｅｄ状態への遷移後に、ＲＲＣ Ｉｎａｃｔｉｖｅ状態にあるＵＥが（スモール）データを送信できるようにするための先行技術の例示的な手順（この場合には５Ｇ ＮＲに準拠する先行技術の解決策）について、図１２を参照しながら簡単に説明する。同図から明らかであるように、ＵＥは、ＲＲＣ＿Ｉｎａｃｔｉｖｅ状態にあるものと想定されており、ＲＲＣ＿Ｉｎａｃｔｉｖｅ状態では、例えば、ＵＥ（およびｇＮＢ）は、すべてのデータ無線ベアラを中断しており、ｇＮＢにデータを送信することができない。ＵＥがデータを送信できるようにするには、最初にＵＥがＲＲＣ Ｃｏｎｎｅｃｔｅｄ状態に遷移する必要があり、この遷移は、ＵＥがＲＡＣＨ手順（図１２では、例えば、４ステップＲＡＣＨ手順を使用する）の一部として、ＲＲＣ接続の再開を要求する（ここではＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔを送信する）ことによって行うことができる。
【0080】
詳細には、ＵＥは、プリアンブルを現在のｇＮＢに送信し、無線リソースの小さなＵＬグラントを含む、対応するランダムアクセス応答を受信し、このリソースを使用して、ＵＥは、ＲＡＣＨ手順のｍｓｇ３としてＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔメッセージを送信することができる。
【0081】
最後に、新しいｇＮＢが、ＲＲＣＲｅｓｕｍｅメッセージをＵＥに提供し、ＵＥは、すべてのデータ無線ベアラの再開を含めて、ＲＲＣ Ｃｏｎｎｅｃｔｅｄ状態に遷移する。ＲＲＣ＿Ｃｏｎｎｅｃｔｅｄ状態では、ＵＥは、ＵＬデータを送信することができる。
【0082】
このようなＵＬスモールデータ送信後に、ＵＥをＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態に遷移させるべきであることをｇＮＢがいつ、どのように決定するかは、まだ定義されていない。ＵＥがＲＲＣ接続の再開を要求することもあり得るが、この点に関する制御は、依然としてｇＮＢに委ねられる可能性が高い。１つの例示的な可能性として、ｇＮＢは、ＵＥが、例えば、Ｍｓｇ３またはＭｓｇＡにおいて送信することができるバッファ状態報告を考慮して、ＵＥがＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態に遷移するべきであるか否かを決定する。バッファ状態報告は、ＵＥのバッファ内の実際のデータ量を示す。例えば、バッファ状態報告が、ＵＥのバッファに大量のデータがあることを示している場合、ｇＮＢは、（例えば、ｇＮＢがＲＲＣＲｅｓｕｍｅメッセージを送信することによって）ＵＥをＲＲＣ＿ＩＮＡＣＴＩＶＥ状態からＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態に遷移させると決定することができる。一方、バッファ状態報告が、ＵＥのバッファにわずかなデータしかないことを示している場合、ｇＮＢは、（例えば、ｇＮＢがＲＲＣＲｅｌｅａｓｅメッセージを送信することによって）ＵＥをＲＲＣ＿ＩＮＡＣＴＩＶＥ状態に維持すると決定することができる。さらに、Ｍｓｇ３／ＭｓｇＡにバッファ状態報告が無いことによっても、例えば、ＵＥバッファにおいてさらなるデータが利用可能でなく、ＵＥがＲＲＣ＿ＩＮＡＣＴＩＶＥに留まることができるという指示をｇＮＢに提供することができる。
【0083】
図１２の説明から理解できるように、上記プロセスによれば、ＵＥは、上りリンクでユーザデータを送信できるように、最初に非アクティブ状態から接続状態に遷移する必要があり、したがって、レイテンシが発生し、ユーザデータの送信のたびにかなりのＵＥ電力が消費される。さらに、小さなデータパケットを送信するときにＩＮＡＣＴＩＶＥ状態のＵＥにおいて生じるシグナリングオーバーヘッドは、一般的な問題であり、５Ｇ ＮＲにおいてＵＥの数が増えればさらに悪化する。
【0084】
したがって、３ＧＰＰは、ＲＲＣ＿Ｉｎａｃｔｉｖｅ ＵＥが自身の状態をＲＲＣ Ｃｏｎｎｅｃｔｅｄに変更せずに、上りリンクでスモールデータを送信できるようにすることを企図している。一般的には、ＩＮＡＣＴＩＶＥ状態のときに小さなデータパケットが断続的に発生するデバイスは、ＩＮＡＣＴＩＶＥ状態でのスモールデータの送信を可能にすることの恩恵を受ける。
【0085】
４ステップＲＡＣＨ、２ステップＲＡＣＨ、または設定済みグラント（ＣＧ：Configured Grant）手順を使用することによって、スモールデータ送信（ＳＤＴ：small data transmission）を可能にすることが合意された。本出願は、４ステップＲＡＣＨまたは２ステップＲＡＣＨに基づくＲＡＣＨベースのＳＤＴ手順に焦点を絞ったものである。
【0086】
３ＧＰＰでは、ＲＲＣ Ｉｎａｃｔｉｖｅ状態に留まるＵＥに対して、どのようにして（スモール）データの送信を可能にするかに関する標準化された方法については、最終的な合意に達していない。
【0087】
ＵＥが依然としてＲＲＣ＿ＩＮＡＣＴＩＶＥ状態にあるときに上りリンクでスモールデータを送信するための１つの可能な方法は、上述したように、ＲＡＣＨ手順を使用することである。図１３および図１４を対象として、また、本発明の概念、解決策、および変形例の後からの説明を対象としてなされた以下の想定は、単なる例示であって、本発明によるＲＡＣＨベースのスモールデータの上りリンク送信を制限するようにはみなされないものとする。
【0088】
さらには、例としてＲＡＣＨに基づくスモールデータの上りリンク送信を想定した場合、ＵＥは、２ステップＲＡＣＨまたは４ステップＲＡＣＨのいずれかを使用して上りリンクでスモールデータを送信することができる（ＭｓｇＡまたはＭｓｇ３を参照）。簡略化された例示的なＲＡＣＨベースのスモールデータアップリンク送信手順を、図１３および図１４に示す。図１３および図１４の両方において、例示的に、ＵＥは、既にＲＲＣ＿ＩＮＡＣＴＩＶＥ状態にあり、送信可能なスモールデータを有すると想定する。図１３は、４ステップのＲＡＣＨ手順を想定しており、ＵＥがＭｓｇ３と共にスモールデータを送信する方法を示している。図１４は、２ステップのＲＡＣＨ手順を想定しており、ＵＥがＭｓｇＡによってスモールデータを送信する方法を示している。
【0089】
一例によれば、制御メッセージおよびスモールデータは、一緒に、例えば、同じトランスポートブロックの中で一緒に、基地局に送信される。この場合、ＵＥは、リソースを使用してトランスポートブロックを構築し、ＭＡＣレイヤの同じトランスポートブロックにおいてデータおよびシグナリングを一緒に多重化する。４ステップＲＡＣＨの場合、スモールデータは、例えば、Ｍｓｇ２においてｇＮＢから受信された上りリンクグラントを通じて許可（granted）された無線リソースに基づいて、Ｍｓｇ３において送信される。２ステップＲＡＣＨの場合、スモールデータは、例えば、選択されたＲＡＣＨプリアンブルに関連して、以前に設定された無線リソースの中からＵＥによって選択された無線リソースを使用して、ＭｓｇＡにおいて送信される。
【0090】
さらに、図１３および図１４は、バッファ状態報告をそれぞれＭｓｇ３およびＭｓｇＡに含めることができることを示しているが、ＢＳＲは、ＢＳＲを含めることが単なる例示的な可能性であることを示すために、括弧内にのみ示されている。例えば、図１３では、例示的に、例えばＢＳＲが存在しないかまたはＵＥバッファ内にわずかな上りリンクスモールデータしか示さないために、ｇＮＢがＵＥをＲＲＣ＿Ｉｎａｃｔｉｖｅ状態に保つと決定することが想定されている。したがって、Ｍｓｇ４ではＲＲＣＲｅｌｅａｓｅメッセージが送信される。一方、図１４では、例示的に、例えば、ＢＳＲが、ＵＥによって送信されなければならないＵＥバッファ内の大量の上りリンクデータを示すために、ｇＮＢが、ＵＥをＲＲＣ＿Ｃｏｎｎｅｃｔｅｄ状態に遷移させると決定することが想定されている。したがって、ＭｓｇＡではＲＲＣＲｅｓｕｍｅメッセージが送信される。
【0091】
さらに、図１３では、上りリンクグラントが、Ｍｓｇ２のランダムアクセス応答（Random Access Response）とは別個に示されているが、図１３および以下の同様の実装形態では、上りリンクグラントは、ランダムアクセス応答に属しかつその一部であると等しく考えてもよい。
【0092】
要約すると、ＲＲＣ＿ＩＮＡＣＴＩＶＥ状態のＵＥによるスモールデータ上りリンク送信の例示的な実装が可能であり、例えば、ＲＡＣＨ手順（２ステップまたは４ステップのＲＡＣＨ手順）に基づくことができる（図１３および図１４を参照）。
【0093】
上記では、（例えば、ＲＡＣＨのＭｓｇ３／ＭｓｇＡを使用する）シングルスモールデータ上りリンク送信について述べた。また、３ＧＰＰは、ＲＲＣ＿ＩＮＡＣＴＩＶＥ状態にあるＵＥが、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態に遷移することなく、同一の手順を使用して複数のＵＬ（および場合によってはＤＬ）伝送を送信する（および受信する）ことが可能であるべきことに合意した。
【0094】
しかし、そのようなマルチＳＤＴ送信手順を実装し定義する方法については、３ＧＰＰでは合意が得られていない。
【0095】
＜さらなる改良＞
【0096】
したがって、本発明者らは、以下からより明らかになるように、そのような複数のスモールデータ送信をサポートし、それによって、複数のスモールデータ送信に関連する潜在的な問題および課題を回避するために、改良されたスモールデータ送信手順を定義する必要性を確認した。
【0097】
マルチＳＤＴ送信手順に含まれる潜在的な問題についての議論を容易にするために、図１５は、図１３の簡略化された例示的な図よりも詳細なシングルＳＤＴ送信手順の例示的な実装形態を示している。図示およびその後の議論を容易にするために、例示的に、マルチＳＤＴ送信手順が４ステップＲＡＣＨに基づくと想定する。
【0098】
さらに、例示的に、ＵＥは、ＲＲＣ＿ＩＮＡＣＴＩＶＥ状態にある間に、以前のｇＮＢ（アンカーｇＮＢ）から現在のｇＮＢ（したがって、現在のサービングｇＮＢである）に移動したと想定する。これにより、例えば、サービングｇＮＢがＵＥ（サービングｇＮＢにとって未知のＵＥ）を認証できるように、サービングｇＮＢが、ＲＡＣＨ手順の一部として、アンカーｇＮＢからＵＥコンテキストを取得することが必要になる場合がある。
【0099】
これに関連して、例示的に、競合解消アイデンティティＭＡＣ制御エレメント（ＣＲ ＭＡＣ ＣＥ：Contention Resolution Identity MAC Control Element）が、ＵＥのＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔメッセージ（図１５の例では、ＲＲＣＲｅｌｅａｓｅメッセージ）に対する応答とは別に送信されることも想定する。前記Ｍｓｇ４および対応するＣＲ ＭＡＣ ＣＥの主な目的は、サービングｇＮＢによるＵＥコンテキストの取得を待たなくてよいように、コンテンションベースのＲＡＣＨの起こり得る競合を解消することである。したがって、サービングｇＮＢは、可能な限り早く（例えば、競合解消の結果がサービングｇＮＢにおいて決定されるときに）ＣＲ ＭＡＣ ＣＥを送信できる一方で、サービングｇＮＢは、ＵＥからのＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔメッセージへの応答メッセージの送信を、ＵＥコンテキストを受信し処理した後に実行することができる。一方、他のシナリオでは、競合解消アイデンティティＭＡＣ制御エレメントを、ＲＲＣ応答メッセージ（例えば、ＲＲＣＲｅｌｅａｓｅまたはＲＲＣＲｅｓｕｍｅ）と共に送信することができる。
【0100】
図１５に示すシングルＳＤＴ手順のステップのシーケンスは、以下の通りである。
【0101】
１．送信可能なスモールデータを有するＵＥは、スモールデータ送信を実行するためにＲＡＣＨを開始する。したがって、ＵＥは、プリアンブルをサービングｇＮＢに送信する。
【0102】
２．次に、ＵＥは、サービングｇＮＢから、一時ＵＥ識別子（例えば、一時Ｃ－ＲＮＴＩ）と、ＲＡＲとしての上りリンクリソースグラントとを受信する。
【0103】
３．その後、ＵＥは、以前に受信したＵＬグラントに基づいて、ＵＬスモールデータと共にＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔメッセージを送信する。実質的にこの時点で、ＵＥは、Ｔ３１９と呼ばれる、ＲＲＣ再開要求（RRC resume request）手順の制御に関与するタイマも始動する。タイマＴ３１９の詳細情報については後述する。
【0104】
より詳細には、例示的な５Ｇ準拠の実装形態によれば、Ｔ３１９タイマは、ＲＲＣ再開要求手順の最大持続時間を規制する。タイマＴ３１９は、ＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔメッセージの送信時に始動され、それに対する、ＲＲＣＲｅｌｅａｓｅメッセージまたはＲＲＣＲｅｓｕｍｅメッセージなどの対応する応答を受信すると停止される。Ｔ３１９が停止される前に満了した場合、ＵＥは、ＲＲＣ再開要求手順が失敗したとみなし、ＲＲＣ＿ＩＤＬＥ状態に遷移する。
【0105】
例示的には、Ｔ３１９に適用される値は、他のアンカーｇＮＢからＵＥコンテキストを取得するために必要な時間を考慮して、ｇＮＢによって決定される。Ｔ３１９が長くなるほど、サービングｇＮＢが応答メッセージ（例えば、ＲＲＣＲｅｌｅａｓｅまたはＲＲＣＲｅｓｕｍｅ）をＵＥに送信可能になるのが遅くなる。Ｔ３１９の値は、例えば、Ｔ３１９タイマがセル固有であり、ＵＥ固有ではないように、ｇＮＢによって当該ｇＮＢのセル内においてシステム情報（ＳＩＢ）を使用してブロードキャストすることができる。
【0106】
４．サービングｇＮＢは、ＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔメッセージの情報コンテンツに基づいて、アンカーｇＮＢからＵＥのコンテキストの取得を試みる。ＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔメッセージには、例えば、コンテキスト取得のための対応するＵＥ ＩＤ（非アクティブＲＮＴＩ、Ｉ－ＲＮＴＩなど）が含まれる。
【0107】
５．サービングｇＮＢは、ＵＥコンテキスト取得の完了を待たずに、競合解消アイデンティティ（Contention Resolution identity）ＭＡＣ ＣＥをＵＥに送信し、これにより、ＲＡＣＨ手順を完了する。ＵＥは、このＣＲ ＭＡＣ ＣＥを受信し、その中の競合解消アイデンティティを、ＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔメッセージにおいてサービングｇＮＢに以前に送信されたＵＥ ＩＤ（例えば、Ｉ－ＲＮＴＩ）と比較する。２つのアイデンティティが一致する場合、競合は肯定的に解消される。
【0108】
６．肯定的なＲＡＣＨ競合解消の結果として、以前に受信された一時Ｃ－ＲＮＴＩは、Ｃ－ＲＮＴＩとしてＵＥによって使用される。
【0109】
７．次に、サービングｇＮＢがアンカーｇＮＢからＵＥのコンテキストの取得に成功するものと想定する。
【0110】
８．次いで、サービングｇＮＢは、ＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔメッセージに応答する方法を決定し、図１５のこの例示的なケースでは、ＲＲＣＲｅｌｅａｓｅメッセージをＵＥに送信して、ＵＥをＲＲＣ＿Ｉｎａｃｔｉｖｅに維持する。ＵＥ側では、ＵＥは、ＲＲＣＲｅｌｅａｓｅメッセージを受信すると、Ｔ３１９タイマを停止する。
【0111】
９．さらに、ＲＲＣＲｅｌｅａｓｅメッセージの結果として、ＵＥは、ＲＲＣ＿ＩＮＡＣＴＩＶＥに留まり、したがって、Ｃ－ＲＮＴＩを解除する（破棄と呼ぶこともできる）。一方、ＵＥは、例えば、上記ステップ３の前のＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔメッセージに対する応答としてＲＲＣＲｅｓｕｍｅメッセージを受信する場合、Ｃ－ＲＮＴＩを保持する。
【0112】
マルチＳＤＴ送信をサポートするためには、ステップ３におけるシングルスモールデータ送信のみを含む上記一連のステップを延長しなければならない。例えば、ＵＥは、追加の適切なＵＬ無線リソースを取得しなければならず、次いで、それに応じて、１つ以上のＵＬスモールデータ送信を実行しなければならない。
【0113】
しかし、ＵＥがサービングｇＮＢから上りリンクリソースグラントを受信できるようにするためには、ＵＥが、上りリンクリソースグラント（例えば、フォーマット０＿０、０＿１、または０＿２のＤＣＩ）がアドレス指定される有効なＣ－ＲＮＴＩ（すなわち、一時Ｃ－ＲＮＴＩがＣ－ＲＮＴＩに変換された後のＣ－ＲＮＴＩ）を有することが有利であろう。言い換えれば、Ｃ－ＲＮＴＩの有効性は、マルチＳＤＴ手順の実装にとって重要である。しかし、Ｃ－ＲＮＴＩがＵＥによって保持されるか否かは、上記から明らかなように、開始されたＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔに関連するＵＥによって受信された応答、およびタイマＴ３１９の動作に依存する。
【0114】
より具体的には、ＵＥのＣ－ＲＮＴＩは、ＵＥがＲＲＣＲｅｌｅａｓｅメッセージを受信する場合（上記のステップ８を参照）、またはＴ３１９が満了する場合（例えば、ＲＲＣＲｅｌｅａｓｅメッセージの受信前）に解除される。例えば、現在の非特許文献７の規格は、第５．３．８．３節においてＲＲＣＲｅｌｅａｓｅメッセージを受信する場合のＵＥ動作を定義しており、ここで、ＵＥ動作は、（例えば、ＭＡＣリセットの一部として）Ｃ－ＲＮＴＩの解除を伴っている。さらに、現在の非特許文献７の規格は、例えば、Ｔ３１９タイマが満了する場合のＵＥ動作も定義している。すなわち、第５．３．１３．５節において、ＵＥ動作はＲＲＣ＿ＩＤＬＥへの遷移を伴い、この遷移が今度は（非特許文献７の第５．３．１１節を参照）、Ｃ－ＲＮＴＩの解除を再び伴っている（例えば、ＲＬＣエンティティやＭＡＣ構成などのリソースすべてを解除することの一部として）。
【0115】
要約すると、ＵＥのＣ－ＲＮＴＩは、Ｔ３１９タイマが動作している間、ＲＲＣＲｅｌｅａｓｅメッセージが受信されるまでＵＥにおいて有効に保たれる。
【0116】
その結果、Ｃ－ＲＮＴＩは、特定の時間量の間のみ利用可能である。この時間量は、ＵＥがマルチＳＤＴ手順を実行するのに不十分な場合がある。
【0117】
１つの採り得る解決策は、例えば、ＵＥがＭｓｇ４の競合解消を受信した後（図１５およびステップ５の説明を参照）で、かつ、ＲＲＣＲｅｌｅａｓｅメッセージを受信する前に、合理的に可能な最も早い時間に追加の１つ以上のスモールデータ送信を実施することであり得る。このような解決策を図１６に示すが、これは図１５と同様であり、対応する想定をする。
【0118】
このような解決策では、サービングｇＮＢは、Ｃ－ＲＮＴＩ宛の上りリンクグラントをＵＥに送信することができ、ＵＥは、ＲＲＣＲｅｌｅａｓｅメッセージがサービングｇＮＢによって送信される前に、割り当てられた上りリンク無線リソースを使用して、対応するスモールデータ上りリンク送信を実行することができる。
【0119】
スモールデータ送信は、オプションで、バッファ状態報告と共に送信することができる。これにより、サービングｇＮＢは、ＵＥバッファ内にどれだけのさらなるデータがあるかを認識し、次いで、他のスモールデータ送信が必要であるか否かを決定し、必要である場合には、それに応じて、次のＵＬグラントを作成することができる。
【0120】
したがって、図１６の解決策によれば、スモールデータ送信を効果的かつ迅速に実装することができる。
【0121】
しかし、このような解決策は、ｇＮＢがまだアンカーｇＮＢからＵＥコンテキストを受信していないために、ＵＥがサービングｇＮＢによってまだ認証されていないという欠点を伴うことがある。一般的には、ＵＬ無線リソースが実際に確保され、新たなＵＥに割り当てられる前に、そのようなＵＥが（ＵＥコンテキストに基づいて）サービングｇＮＢによって最初に認証されることが好ましい。例えば、ＵＥコンテキスの取得が失敗する、またはＵＥコンテキスの取得によりＵＥが不正もしくは偽であることが明らかになる可能性があり、この場合、ＵＬ ＳＤＴ向けに割り当てられた無線リソースが無駄になってしまう可能性がある。
【0122】
さらに、図１６の例示的なシナリオでは、ＵＥコンテキストが取得され、ｇＮＢがＲＲＣＲｅｌｅａｓｅメッセージをＵＥに送信する前に、２つの追加のスモールデータ送信（合計で３つのＳＤＴ）が可能であると想定する。次いで、ＵＥは、Ｔ３１９タイマを停止し、Ｃ－ＲＮＴＩを解除する。その後、さらなるＵＬスモールデータ送信は、もはや可能ではない。しかし、利用可能な時間の量は、ＵＥコンテキスト取得に必要な時間に依存し、この時間は、大きく変化し、実際には非常に短くなり得る。
【0123】
上記解決策の可能な変形例は、ＵＥがＣ－ＲＮＴＩを破棄することを回避するために、ｇＮＢがＲＲＣＲｅｌｅａｓｅメッセージの送信を待機することを含み得る。例えば、ＵＥがＴ３１９タイマを停止する時間ちょうどにＲＲＣＲｅｌｅａｓｅメッセージを受信するようにｇＮＢは待機することができ、したがって、ＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔ手順の失敗、ひいては可能性としてＲＲＣ＿ＩＤＬＥ状態への遷移を回避することができる。これにより、スモールデータ送信に利用可能な時間が最大化される。このスモールデータ送信は、ＵＥコンテキストがサービングｇＮＢによって実際に受信される時とはいくぶん独立している。しかし、サービングｇＮＢによる待機時間は、Ｔ３１９タイマの値によって制限される、なぜなら、ＲＲＣＲｅｌｅａｓｅは、サービングｇＮＢによって時間内に送信され、Ｔ３１９タイマの満了前にＵＥによって受信されるべきだからである。したがって、必要な数のスモールデータ送信を実行するのに十分な時間がないことがある。現在の３ＧＰＰ ５Ｇ準拠の実装形態では、Ｔ３１９タイマは、最大２０００ｍｓに設定することができる（非特許文献７の第６．３．２節の情報要素（Information Element）「ＵＥ－ＴｉｍｅｒｓＡｎｄＣｏｎｓｔａｎｔｓ」：「ＥＮＵＭＥＲＡＴＥＤ｛ｍｓ１００，ｍｓ２００，ｍｓ３００，ｍｓ４００，ｍｓ６００，ｍｓ６００，ｍｓ１０００，ｍｓ１５００，ｍｓ２０００｝」を参照）。この最大２０００ｍｓは、非アクティブＵＥのためにＵＥコンテキストを保持するアンカーｇＮＢとサービングｇＮＢとの間のバックホールリンクに起因して生じ得る遅延を含めて、他のｇＮＢからのＵＥコンテキスト取得に対処することができるように定義されている。Ｔ３１９タイマの最大値は、マルチＳＤＴ手順に適合するように設計されておらず、したがって、小さすぎる可能性が高い。
【0124】
上記解決策（図１６に基づく）のさらなるオプションの変形例として、Ｔ３１９タイマの長さを延長する、すなわち、長くすることができる。上記の点に関して、Ｔ３１９タイマが定義され得る最大値は、はるかに高く設定され得る（例えば、８０００ｍｓ）。これにより、改良されたマルチＳＤＴ手順において、ＵＥがＣ－ＲＮＴＩをより長く有効に保つことができ、したがって、ＲＲＣＲｅｌｅａｓｅメッセージを受信する前に、複数のスモールデータ送信のためのより多くの時間を許容し得るという利点がある。
【0125】
しかし、Ｔ３１９タイマをより高い値に設定することには、欠点もある、なぜなら、複数のスモールデータ送信を実行せず、場合によっては複数のスモールデータ送信をサポートさえしない他のＵＥが悪影響を受けることになるからである。Ｔ３１９タイマの値は、システム情報の一部としてサービングｇＮＢによってそのセル内でブロードキャストされ、すべてのＵＥによって採用される。このすべてのＵＥには、マルチスモールデータ送信を実行しないまたはサポートしないＵＥが含まれ、また、単にＲＮＡ（ＲＡＮベースの通知エリア更新）を実行したりまたはＲＲＣ接続を再開したりする予定のＵＥも含まれる。したがって、延長されたＴ３１９タイマ値は、このようなＵＥのＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔ手順に悪影響を及ぼす、なぜなら、このようなＵＥは、Ｔ３１９タイマが満了する後の時点で、上記手順の失敗を検出する可能性があるからである。
【0126】
マルチＳＤＴ手順を実装するための他の課題は、手順全体がシングルＳＤＴ送信手順よりもはるかに長くなることがあるという結果に関する。特に、マルチＳＤＴ送信手順は、最初のＵＬ ＳＤＴ送信の後に、いくつかの後続のＵＬグラントの送信を含み得る（図１３および図１４も参照）。これが、例えば、上記のシングルＳＤＴ送信手順と比較した場合、マルチＳＤＴ手順を実質的に延長する可能性が高い。これに関連して起こりうる１つの問題は、ＵＥがこのマルチＳＤＴ手順の最中に他のセルに移動する可能性があることである（これは、シングルＳＤＴ手順においても起こり得るが、可能性ははるかに低い）。このような例示的なシナリオでは、いくつかの問題が生じ得る。例えば、古いサービングｇＮＢによって許可された無線リソースは、ＵＥが新たなサービングｇＮＢにキャンプする場合、ＵＥによってもはや使用することができない。さらに、ＵＥは、以前に送信されたＵＬデータが古いサービングｇＮＢによって正しく受信されたか否かを確認することができないことがある。この場合、いくつかのＵＬデータは、依然としてＨＡＲＱバッファに残ることがある。
【0127】
本発明者らは、上述の潜在的な欠点および課題を見出した。これらの１つ以上は、マルチＳＤＴ手順を実装する場合に最もよく解決可能である。
【0128】
したがって、本発明者らは、上記問題点の１つ以上を回避または軽減することができる改良されたスモールデータ送信手順を提供する可能性を見出した。本発明は、このような改良されたスモールデータ送信手順の様々な解決策および変形例に関する。
【0129】
＜実施形態＞
【0130】
以下では、５Ｇ移動通信システムにおいて想定される新しい無線アクセス技術（ただし、ＬＴＥ移動通信システムでも使用可能）のための、これらのニーズを満たすＵＥ、基地局、および手順について説明する。複数の異なる実装形態および変形例も説明する。以下の開示は、上述した議論および発見事項によって促進され、例えば、その少なくとも一部に基づくことができる。
【0131】
一般に、本開示の基礎となる原理を明確かつ理解しやすい方法で説明できるように、本明細書では多くの想定がなされていることに留意されたい。しかし、これらの想定は、本明細書において説明を目的としてなされた単なる例であり、本開示の範囲を限定するものではないことを理解されたい。当業者には、以下の開示および特許請求の範囲に記載されている原理が、異なるシナリオに、および本明細書に明示的に記載されていない方法で適用できることが理解されるであろう。
【0132】
さらに、次の３ＧＰＰ ５Ｇ通信システムのための新しい無線アクセス技術のコンテキストで使用される特定の用語は、まだ完全に決定されていない、または最終的に変更される可能性があるが、以下で使用されている手順、エンティティ、レイヤなどの用語のいくつかは、ＬＴＥ／ＬＴＥ－Ａシステムに、または現在の３ＧＰＰ ５Ｇ標準化において使用されている用語に、密接に関連している。したがって、用語は将来的に変更されうるが、実施形態の機能に影響を与えることはない。したがって、当業者には、実施形態およびその保護範囲が、より新しいまたは最終的に合意された用語が存在しないために本明細書で例示的に使用されている特定の用語に制限されるものではなく、本開示の機能および原理の基礎をなす機能およびコンセプトの観点においてより広義に理解されるべきであることが認識されるであろう。
【0133】
例えば、「移動局」または「移動ノード」または「ユーザ端末」または「ユーザ機器（ＵＥ）」は、通信ネットワーク内の物理エンティティ（物理ノード）である。１つのノードがいくつかの機能エンティティを有することができる。機能エンティティとは、同じノードもしくは別のノードまたはネットワークの別の機能エンティティに対して、所定の一連の機能を実施および／または提供する、ソフトウェアモジュールまたはハードウェアモジュールを意味する。ノードは、それを通じて通信することのできる通信機器または通信媒体に自身をアタッチする１つ以上のインターフェースを有することができる。同様に、ネットワークエンティティは、それを通じて別の機能エンティティまたは通信相手ノードと通信することのできる通信機器または通信媒体に機能エンティティをアタッチする論理インターフェースを有することができる。
【0134】
用語「基地局」または「無線基地局」は、本明細書においては、通信ネットワーク内の物理エンティティを意味する。基地局は、移動局と同様に、いくつかの機能エンティティを有することができる。機能エンティティとは、同じノードもしくは別のノードまたはネットワークの別の機能エンティティに対して、所定の一連の機能を実施および／または提供する、ソフトウェアモジュールまたはハードウェアモジュールを意味する。物理エンティティは、通信装置に関連するいくつかの制御タスク（スケジューリングおよび設定の１つまたは複数を含む）を実行する。なお、基地局の機能および通信装置の機能を、１つの装置内に統合してもよいことに留意されたい。例えば、移動端末が、別の端末に対して基地局の機能をさらに実施してもよい。ＬＴＥにおいて使用されている専門用語は、ｅＮＢ（またはｅＮｏｄｅＢ）であるが、５Ｇ ＮＲにおいて現時点で使用されている専門用語は、ｇＮＢである。
【0135】
ＵＥと基地局との間の通信は、一般的に標準化されており、ＰＨＹやＭＡＣ、ＲＲＣなどの異なるレイヤによって定義され得る（上記の背景技術の説明を参照）。
【0136】
本出願で使用される「スモールデータ」という用語は、ＵＥおよび基地局が、小さいことを合意するデータ（例えば、「小さくない」の反意語（versus non-small））であるものと広義に理解されるものとする。例えば、データがスモールデータとみなされるか否かは、データ量のしきい値を設定することにより基地局によって定義することができる。あるいは、どのようなデータがスモールデータであるかを、例えば、データ量のしきい値を設定することにより、通信規格によって定義することができる。
【0137】
本出願で使用される「非アクティブ状態」という用語は、ＵＥと基地局との間の通常の広範なデータ交換が不可能であるかまたは一般的ではない状態として広義に理解されるものとする。例えば、ＵＥは、非アクティブ状態にあるとき（例えば、「非アクティブＵＥ」と呼ばれる）、アクティブに使用される（actively-used）データ接続を有していなくてよいが、最初にデータ接続を再開する必要なしに（スモール）データの送信を可能にする１つ以上の非アクティブなデータ接続（例えば、存在するが現在使用されていないと言うこともできる）を依然として有する。なお、補足すると、「アイドル状態」にあるＵＥは、ＵＥが基地局にデータを送信することのできるデータ接続を有しておらず、一方で、「接続状態」にあるＵＥは、基地局にデータを伝えるためにただちに使用することのできる１つ以上のアクティブなデータ接続を有する。
【0138】
「監視する（monitoring）」という用語は、例えば特定のフォーマットに基づいて、ＤＣＩメッセージを受信する可能な候補を復号しようとすること、すなわち、より単純には、ＤＣＩメッセージを復号しようとすることとして広く理解することができる。このような復号の試みは、ブラインド復号と呼ばれることもある。ＤＣＩメッセージは、例えば、上りリンクまたは下りリンクの無線リソースのためのリソース割当てメッセージとして広く理解することができる。したがって、「監視機能（monitoring function）」という用語は、ＤＣＩメッセージを復号しようと試みるためにＵＥによって実行される対応する機能に関連するものとして、この文脈において広く理解することができる。
【0139】
さらに、「監視機能」は、様々な理由で、例えば、Ｍｓｇ２またはＭｓｇ４またはＭｓｇＢを予期する場合のＲＡＣＨ手順中など、基地局からの応答を予期する場合に、ＵＥによって実行することができる。次いで、監視機能は、基地局からさらなるメッセージまたはリソース割当てを受信することができるように、ＵＥによって継続または延長することができる。
【0140】
図１７は、ユーザ機器（通信装置とも呼ばれる）およびスケジューリング装置（ここでは、例示的に、基地局、例えば、ｅＬＴＥ ｅＮＢ（代替的にｎｇ－ｅＮＢとも呼ばれる）または５Ｇ ＮＲにおけるｇＮＢに配置されていると想定する）の簡略化された一般的かつ例示的なブロック図を示している。ＵＥおよびｅＮＢ／ｇＮＢは、それぞれ送受信機を使用して、（無線）物理チャネルを通じて互いに通信している。
【0141】
通信装置は、送受信機および処理回路を備えていることができる。送受信機は、受信機および送信機を備えている、および／または、受信機および送信機として機能することができる。処理回路は、１つ以上のプロセッサまたは任意のＬＳＩなどの１つ以上のハードウェアとすることができる。送受信機と処理回路との間には入力／出力点（またはノード）が存在し、処理回路は、動作時に、この入力／出力点（またはノード）を通じて送受信機を制御する、すなわち、受信機および／または送信機を制御し、受信データ／送信データを交換することができる。送信機および受信機としての送受信機は、１つ以上のアンテナ、増幅器、ＲＦ変調器／復調器などを含むＲＦ（無線周波数：radio frequency）フロントを含むことができる。処理回路は、処理回路によって提供されるユーザデータおよび制御データを送信する、および／または、処理回路によってさらに処理されるユーザデータおよび制御データを受信する、ように送受信機を制御するなどの制御タスクを実施することができる。また、処理回路は、判定や決定、計算、測定などの他の処理を実行する役割を担うこともできる。送信機は、送信のプロセス、および送信に関連する他のプロセスを実行する役割を担うことができる。受信機は、受信のプロセス、および受信に関連する他のプロセス（チャネルを監視するなど）を実行する役割を担うことができる。
【0142】
以下では、改良されたスモールデータ送信手順について説明する。これに関連して、改良されたスモールデータ送信手順に参加する、改良されたＵＥおよび改良された基地局が提示される。ＵＥの動作および基地局の動作のための対応する方法も提供される。
【0143】
図１８は、改善されたスモールデータ送信手順の１つの例示的な解決策に係る簡略化された例示的なＵＥの構造を示し、図１７に関連して説明された一般的なＵＥの構造に基づいて実現することができる。図１８に示されるＵＥの様々な構造要素は、例えば、制御データおよびユーザデータならびに他の信号を交換するために、例えば、対応する入力／出力ノード（不図示）を用いて互いに相互接続され得る。説明のために示されていないが、ＵＥは、さらなる構造要素を含み得る。
【0144】
図１８から明らかなように、ＵＥは、ＵＥ識別情報割当受信機と、リソース割当受信機と、監視機能処理回路と、スモールデータ送信機と、監視機能を延長するかを決定する処理回路と、オプションでメッセージ受信機とを含み得る。
【0145】
以下の開示から明らかになる本ケースでは、したがって、ＵＥの受信機は、例示的に、ＵＥ識別情報の割当てを受信すること、リソース割当てを受信すること、下りリンク送信を受信すること、ＲＡＣＨ手順のメッセージを受信することなどの１つ以上を少なくとも部分的に実行するように構成することができる。
【0146】
さらに、以下の開示から明らかになる本ケースでは、したがって、ＵＥの処理回路（プロセッサとも呼ばれる）は、例示的に、監視機能を実行すること、監視機能を延長するか否かを決定すること、タイマおよびカウンタを動作させることなどの１つ以上を少なくとも部分的に実行するように構成することができる。
【0147】
さらに、以下の開示から明らかになる本ケースでは、したがって、ＵＥの送信機は、スモールデータを送信すること、サービング基地局によって実行されるＲＡＣＨ手順のメッセージを送信すること、バッファ状態報告（例えば、ＢＳＲ ＭＡＣ ＣＥ）を送信することなどの１つ以上を少なくとも部分的に実行するように構成することができる。
【0148】
以下でさらに詳細に開示される１つの例示的な解決策は、以下を含むＵＥによって実施される。前記ＵＥの受信機は、前記ＵＥに現在サービスを提供（サービング）している基地局からＵＥ識別情報の割当てを受信する。前記ＵＥは、接続状態、アイドル状態、および非アクティブ状態のうちの非アクティブ状態にある。前記ＵＥ識別情報は、前記サービング基地局から送信される、少なくとも上りリンクリソース割当てを含む、リソース割当ての受信のための監視機能を実行するために前記非アクティブＵＥによって使用可能である。前記受信機は、前記ＵＥ識別情報に基づいて、前記サービング基地局から送信された上りリンクリソース割当てを受信する。当該受信された上りリンクリソース割当てによって、スモールデータの送信のために前記非アクティブＵＥによって使用可能な無線リソースが割り当てられる。前記ＵＥの送信機は、前記受信された上りリンクリソース割当てに基づいて、前記スモールデータの前記サービング基地局への送信を実行する。プロセッサは、前記ＵＥ識別情報に基づく少なくとももう１つの他の上りリンクリソース割当ての受信のために前記監視機能を延長するか否かを決定し、当該決定は、前記サービング基地局から受信されたメッセージに基づくか、または前記ＵＥが送信可能なさらなるスモールデータを有するか否かに基づく。
【0149】
上述したＵＥに沿った、例示的なＵＥ動作の対応するシーケンス図を、以下に定義し、図１９に示す。本方法は、ユーザ機器（ＵＥ）によって実行される以下のステップ、
● 前記ＵＥに現在サービスを提供（サービング）している基地局からＵＥ識別情報の割当てを受信するステップであって、前記ＵＥは、接続状態、アイドル状態、および非アクティブ状態のうちの非アクティブ状態にあり、前記ＵＥ識別情報は、前記サービング基地局から送信される、少なくとも上りリンクリソース割当てを含む、リソース割当ての受信のための監視機能を実行するために非アクティブＵＥによって使用可能である、ステップと、
● 前記ＵＥ識別情報に基づいて、前記サービング基地局から送信された上りリンクリソース割当てを受信するステップであって、当該受信した上りリンクリソース割当てによって、スモールデータの送信のために前記非アクティブＵＥによって使用可能な無線リソースが割り当てられる、ステップと、
● 前記受信した上りリンクリソース割当てに基づいて、前記スモールデータの前記サービング基地局への送信を実行するステップと、
● 前記ＵＥ識別情報に基づく少なくとももう１つの他の上りリンクリソース割当ての受信のために前記監視機能を延長するか否かを決定するステップであって、前記決定は、前記サービング基地局から受信したメッセージに基づくか、または前記ＵＥが送信可能なさらなるスモールデータを有するか否かに基づく、ステップと、
を有する。
● 前記ＵＥに現在サービスを提供（サービング）している基地局からＵＥ識別情報の割当てを受信するステップであって、前記ＵＥは、接続状態、アイドル状態、および非アクティブ状態のうちの非アクティブ状態にあり、前記ＵＥ識別情報は、前記サービング基地局から送信される、少なくとも上りリンクリソース割当てを含む、リソース割当ての受信のための監視機能を実行するために非アクティブＵＥによって使用可能である、ステップと、
● 前記ＵＥ識別情報に基づいて、前記サービング基地局から送信された上りリンクリソース割当てを受信するステップであって、当該受信した上りリンクリソース割当てによって、スモールデータの送信のために前記非アクティブＵＥによって使用可能な無線リソースが割り当てられる、ステップと、
● 前記受信した上りリンクリソース割当てに基づいて、前記スモールデータの前記サービング基地局への送信を実行するステップと、
● 前記ＵＥ識別情報に基づく少なくとももう１つの他の上りリンクリソース割当ての受信のために前記監視機能を延長するか否かを決定するステップであって、前記決定は、前記サービング基地局から受信したメッセージに基づくか、または前記ＵＥが送信可能なさらなるスモールデータを有するか否かに基づく、ステップと、
を有する。
【0150】
この改良されたスモールデータ送信手順によれば、ＵＥによる監視を延長することにより、さらなる上りリンクリソース割当てを受信することができ、したがってさらなる上りリンク（スモール）データ送信を可能にすることができる。ＵＥは、監視機能を実行するために、以前に割り当てられたＵＥ識別情報をさらに使用し、ＵＥ識別情報は、ＵＥへの上りリンクリソース割当てをＵＥにアドレス指定するためにサービング基地局によって使用される。さらに、監視機能がＵＥによって延長されるか否かは、上記目的のためにＵＥに送信されるメッセージを使用することによって、サービング基地局によって制御可能でもある。
【0151】
また、上記から既に明らかなように、改良されたスモールデータ送信手順は、改良された無線基地局も提供する。図２０は、改良されたスモールデータ送信手順の１つの例示的な解決策に係る簡略化された例示的な基地局の構造を示し、図１７に関連して説明された一般的な基地局の構造に基づいて実現することができる。図２０に示される無線基地局の様々な構造要素は、例えば、制御データおよびユーザデータならびに他の信号を交換するために、例えば、対応する入力／出力ノード（不図示）を用いて互いに相互接続され得る。説明のために示されていないが、基地局は、さらなる構造要素を含み得る。
【0152】
図２０から明らかなように、基地局は、リソース割当送信機と、ＵＥ識別情報割当送信機と、スモールデータ送信受信機と、メッセージ送信機とを含み得る。
【0153】
以下の開示から明らかになる本ケースでは、したがって、基地局の受信機は、例示的に、ＵＥからのスモールデータを受信すること、ＵＥで実行されるＲＡＣＨ手順のメッセージを受信すること、ＵＥからのＲＲＣメッセージを受信すること、ＵＥからのバッファ状態報告（例えば、ＢＳＲ ＭＡＣ ＣＥ）を受信することなどの１つ以上を少なくとも部分的に実行するように構成することができる。
【0154】
以下の開示から明らかになる本ケースでは、したがって、基地局の処理回路は、例示的に、タイマおよびカウンタを動作させること、ＵＥに上りリンクリソース割当てを送信するか否かを決定することなどの１つ以上を少なくとも部分的に実行するように構成することができる。
【0155】
以下の開示から明らかになる本ケースでは、したがって、基地局の送信機は、例示的に、ＵＥにＵＥ識別情報割当メッセージを送信すること、ＵＥにメッセージを送信すること、ＵＥによって実行されるＲＡＣＨ手順のメッセージを送信すること、ＵＥに上りリンクリソース割当てを送信することなどの１つ以上を少なくとも部分的に実行するように構成することができる。
【0156】
以下でさらに詳細に開示される１つの例示的な解決策は、以下を含む無線基地局によって実施される。前記基地局の送信機は、前記基地局によって現在サービスが提供されているユーザ機器（ＵＥ：User Equipment）にＵＥ識別情報の割当てを送信する。前記ＵＥは、接続状態、アイドル状態、および非アクティブ状態のうちの非アクティブ状態にあり、前記ＵＥ識別情報は、少なくとも上りリンクリソース割当てを含むリソース割当てを前記ＵＥに送信するために前記基地局によって使用可能である。前記送信機は、前記ＵＥ識別情報に基づいて、前記非アクティブＵＥに上りリンクリソース割当てを送信する。当該送信された上りリンクリソース割当てによって、スモールデータの送信のために前記非アクティブＵＥによって使用可能な無線リソースが割り当てられる。また、当該送信された上りリンクリソース割当ては、前記非アクティブＵＥが前記割り当てられたＵＥ識別情報に基づくリソース割当ての受信のための監視機能を実行することに基づいて前記非アクティブＵＥによって受信可能である。受信機は、前記送信された上りリンクリソース割当てに基づいて、前記非アクティブＵＥからの前記スモールデータの受信を実行する。前記送信機は、前記非アクティブＵＥが前記ＵＥ識別情報に基づく少なくとももう１つの他の上りリンクリソース割当ての受信のために前記監視機能を延長するか否かを決定する基礎となるメッセージを前記非アクティブＵＥに送信する。
【0157】
上述した基地局に沿った、例示的な基地局動作の対応するシーケンス図を、図２１に示す。対応する方法は、基地局によって実行される以下のステップ、
● 前記基地局によって現在サービスが提供されているユーザ機器（ＵＥ：User Equipment）にＵＥ識別情報の割当てを送信するステップであって、前記ＵＥは、接続状態、アイドル状態、および非アクティブ状態のうちの非アクティブ状態にあり、前記ＵＥ識別情報は、少なくとも上りリンクリソース割当てを含むリソース割当てを前記ＵＥに送信するために前記基地局によって使用可能である、ステップと、
● 前記ＵＥ識別情報に基づいて、前記非アクティブＵＥに前記上りリンクリソース割当てを送信するステップであって、当該送信した上りリンクリソース割当てによって、スモールデータの送信のために前記非アクティブＵＥによって使用可能な無線リソースが割り当てられ、また、当該送信した上りリンクリソース割当ては、前記非アクティブＵＥが前記割り当てられたＵＥ識別情報に基づくリソース割当ての受信のための監視機能を実行することに基づいて前記非アクティブＵＥによって受信可能である、ステップと、
● 前記送信した上りリンクリソース割当てに基づいて、前記非アクティブＵＥからの前記スモールデータの受信を実行するステップと、
● 前記非アクティブＵＥが前記ＵＥ識別情報に基づく少なくとももう１つの他の上りリンクリソース割当ての受信のために前記監視機能を延長するか否かを決定する基礎となるメッセージを前記非アクティブＵＥに送信するステップと、
を有する。
● 前記基地局によって現在サービスが提供されているユーザ機器（ＵＥ：User Equipment）にＵＥ識別情報の割当てを送信するステップであって、前記ＵＥは、接続状態、アイドル状態、および非アクティブ状態のうちの非アクティブ状態にあり、前記ＵＥ識別情報は、少なくとも上りリンクリソース割当てを含むリソース割当てを前記ＵＥに送信するために前記基地局によって使用可能である、ステップと、
● 前記ＵＥ識別情報に基づいて、前記非アクティブＵＥに前記上りリンクリソース割当てを送信するステップであって、当該送信した上りリンクリソース割当てによって、スモールデータの送信のために前記非アクティブＵＥによって使用可能な無線リソースが割り当てられ、また、当該送信した上りリンクリソース割当ては、前記非アクティブＵＥが前記割り当てられたＵＥ識別情報に基づくリソース割当ての受信のための監視機能を実行することに基づいて前記非アクティブＵＥによって受信可能である、ステップと、
● 前記送信した上りリンクリソース割当てに基づいて、前記非アクティブＵＥからの前記スモールデータの受信を実行するステップと、
● 前記非アクティブＵＥが前記ＵＥ識別情報に基づく少なくとももう１つの他の上りリンクリソース割当ての受信のために前記監視機能を延長するか否かを決定する基礎となるメッセージを前記非アクティブＵＥに送信するステップと、
を有する。
【0158】
したがって、改良された基地局は、改良されたスモールデータ送信手順に参加し、それにより、ＵＥは、容易に監視時間を延長していくつかの上りリンクリソース割当てを受信することができ、これらの上りリンクリソース割当てに基づいて対応する上りリンクスモールデータ送信を実行することができる。
【0159】
以下、上記の改良されたスモールデータ送信手順の実装方法について、様々な例示的な実装形態を開示する。
【0160】
以下の解決策では、改良されたスモールデータ送信手順は、ＲＡＣＨ手順を基礎として、第１のスモールデータ送信を提供し、次いで、さらなるスモールデータ送信を可能にするＵＥ動作を定義するものとする。
【0161】
さらに、サービング基地局がＵＥにＵＥ識別情報を割り当てることを含むのも、このＲＡＣＨ手順である。ＵＥ識別情報は、その後、スモールデータ送信を可能にするために使用可能である。例えば、ＵＥは、上りリンクスモールデータ送信を実行するためにＵＥによって使用可能な無線リソースを割り当てる上りリンクリソース割当てを受信する。解決策の５Ｇ－ＮＲ規格に準拠した変形例では、ＵＥ識別情報は、Ｍｓｇ２またはＭｓｇＢに基づいて（最初は一時的に）ＵＥに割り当てられるＣ－ＲＮＴＩであり得る。例えば、５Ｇ－ＮＲ準拠の変形例は、上記の対応するセクション「ランダムアクセス手順（Random Access procedure）」で説明したＲＡＣＨ手順の一部として、スモールデータおよびＢＳＲ ＭＡＣ ＣＥを送信することができる。様々な解決策（および可能な変形例）は、４ステップＲＡＣＨ手順および２ステップＲＡＣＨ手順の両方に適用可能であり得る。
【0162】
＜第１の解決策＞
【0163】
改良されたスモールデータ送信手順（ならびにその変形例および実装形態）の第１の解決策によれば、サービング基地局は、リソース割当てを使用して、ＵＥがいくつかの上りリンクスモールデータ送信を実行することを可能にすることができる。したがって、上記のメッセージ（これに基づいて、ＵＥは、少なくとももう１つの他の上りリンクリソース割当ての受信のために監視機能を延長する（継続すると呼ぶこともある）か否かを決定する）は、サービング基地局から非アクティブＵＥに送信される上りリンクリソース割当てである。
【0164】
そして、上りリンクリソース割当ての受信時に、ＵＥは、さらなる上りリンクリソース割当てを予期すべきであると決定する。したがって、当該上りリンクリソース割当ての受信時に、非アクティブＵＥは、次の上りリンクリソース割当てを受信できるように、監視機能を延長すると決定する。
【0165】
上記のように、ＵＥは、上りリンクリソース割当ての受信に基づいて、監視機能を延長するか否かの決定を行う。あるいは、上りリンクリソース割当ての受信を利用する代わりに、後に実行されるスモールデータ送信を使用することができる。したがって、例えば、以前に受信した上りリンクリソース割当てに基づく上りリンクスモールデータ送信の実行時に、ＵＥは、次の上りリンクリソース割当てを受信できるように監視機能を延長すべきであると決定する。
【0166】
さらなる例示的な変形例によれば、ＵＥが監視機能を延長すべきか否かの決定は、追加的にまたは代替的に、ＵＥのバッファに残っている上りリンクデータがあるか否かを考慮することができる。例えば、ＵＥは、ＵＥのバッファに残っている上りリンクスモールデータがある場合（例えば、バッファ状態報告が、以前に受信した上りリンクリソース割当てによって指示された無線リソースを使用して、スモールデータ送信と一緒に送信されるかまたは一緒には送信されない場合）、監視機能を延長すると決定する。一方、ＵＥは、ＵＥのバッファにさらなる上りリンクスモールデータが残っていない場合（例えば、バッファ状態報告が送信されない場合、または送信されたバッファ状態報告がさらなるデータを示さない場合）、監視機能を延長しないと決定する。
【0167】
非アクティブＵＥによって実行される監視機能は、（上りリンクまたは下りリンク）リソース割当てがサービング基地局によってアドレス指定可能なＵＥ識別情報（例えば、Ｃ－ＲＮＴＩ）に基づく。ＵＥ識別情報は、典型的には、サービング基地局によって、例えば、ＲＡＣＨ手順のＭｓｇ４を受信するためなど、特定の目的のために、一時的に、すなわち、永続的ではなく、非アクティブＵＥに割り当てられる。ＵＥ識別情報は、必要とされる限り、アライブ状態（alive）に保つことができ、必要なくなれば、ＵＥによって破棄される（および、場合によっては、サービング基地局によって他のＵＥに再び割り当てられる）。
【0168】
改良されたスモールデータ送信手順によれば、ＵＥ識別情報は、ＵＥ識別情報が複数の上りリンクリソース割当てを受信するために使用可能に保たれるように（したがって、非アクティブＵＥによる複数のスモールデータ送信を可能にするように）、ＵＥによって制御される。これをどのように実現することができるかについての２つの変形例を、以下に提示する。２つの変形例は、この点に関して１つまたは２つのタイマを使用する点で互いに異なる。
【0169】
第１の変形例によれば、場合によって破棄する前に、ＵＥ識別情報がどれだけ長く有効に（「アライブ状態」ともいう）保たれるかを制御するために、主にＵＥによって１つのタイマが使用される。例えば、ＵＥ識別情報は、ＲＡＣＨ手順のＲＡＲによってＵＥに割り当てられる。例えば、タイマは、ＵＥがＲＡＣＨ手順中に接続再開要求を送信する場合に始動される。タイマは、接続再開要求手順のために使用され、タイマのおかげで、接続再開要求メッセージに対しての対応する応答（例えば、ＲＲＣＲｅｌｅａｓｅ）がサービング基地局から受信されなかったという理由から、タイマの満了時に接続再開要求手順が成功しなかったと決定することができる。したがって、破棄されたＵＥ識別情報は、さらなる上りリンクまたは下りリンクリソース割当ての受信にはもはや使用することができない。サービング基地局からのＲＲＣＲｅｌｅａｓｅメッセージを受信すると、タイマが停止され、ＵＥが非アクティブ状態に留まる結果となる。これにより、次いで、ＵＥ識別情報が破棄される。同様に、タイマが満了した場合（すなわち、接続再開要求に対する応答も、上りリンクリソース割当てもサービング基地局から受信されなかった場合）、ＵＥは、接続再開要求が成功しなかったと決定し、次いで、アイドル状態に入ることに進む。また、アイドル状態に入ることは、ＵＥがＵＥ識別情報を破棄することを伴う。したがって、破棄されたＵＥ識別情報は、さらなる上りリンクまたは下りリンクリソース割当てを受信するためにもはや使用することができない。
【0170】
現在の５Ｇ－ＮＲ規格に従った例示的な一実装形態によれば、タイマは、非アクティブＵＥがＲＡＣＨ手順のＭｓｇ３またはＭｓｇ４を送信する時に始動されるＴ３１９タイマである。しかし、５Ｇ－ＮＲ ＵＥは、Ｔ３１９タイマが動作している間、下りリンクＲＲＣメッセージ（すなわち、ＲＲＣ解放／再開／拒否メッセージ）を監視するだけでよいため、この例示的な実装形態におけるＵＥの動作は、Ｔ３１９タイマが動作している間、上りリンクリソース割当ても監視するように変更される必要がある。
【0171】
改良されたスモールデータ送信手順のこの第１の変形例によれば、タイマは、上りリンクリソース割当ての受信時に再始動され、それによって、ＵＥ識別情報の寿命（または有効性）を延長し、このＵＥ識別情報にアドレス指定された、サービング基地局によって送信されるさらなるリソース割当てのために下りリンク制御チャネルを監視する関連においてＵＥ識別情報の有用性を延長する。さらに、ＵＥ識別情報の破棄は、タイマの満了時に発生する。
【0172】
改良されたスモールデータ送信手順の第２の変形例によれば、第１のタイマは、接続再開要求手順に必要な時間を制御するために使用される。加えて、第２のタイマがＵＥによって作動し、ＵＥ識別情報の寿命（有効性）を延長することに用いられる。この第２のタイマは、サービング基地局から最初の上りリンクリソース割当てを受信した時に初めて始動され、その後、サービング基地局からさらなる上りリンクリソース割当てを受信するたびに再始動される。次いで、ＵＥ識別情報は、第１および第２のタイマのいずれか１つが動作している限りアライブ状態のままであるが、第１のタイマおよび第２のタイマがいずれももはや動作していない（例えば、満了しているか、または停止された）ときに破棄される。
【0173】
現在の５Ｇ－ＮＲ規格に合致する例示的な一実装形態によれば、第１の変形例のタイマおよび第２の変形例の第１のタイマは、Ｔ３１９タイマであり、これは、非アクティブＵＥが、ＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔメッセージを含むＲＡＣＨ手順のＭｓｇ３またはＭｓｇＡを送信する時に始動される。
【0174】
第１の解決策の第１および第２の変形例について上述したように、ＵＥによる監視機能を実行するために必要に応じてＵＥ識別情報をアライブ状態のまま保つことにより、いくつかのスモールデータ送信を実行することができるようにすることが可能である。
【0175】
第１の解決策の一変形例によれば、改良されたスモールデータ送信手順は、その後、接続再開要求手順の応答メッセージで完了される。例えば、ＵＥは、接続再開要求（例えば、ＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔメッセージ）を送信することによって、ＲＡＣＨ手順中に接続再開要求手順を開始した。これに応答して、接続再開要求手順は、対応する応答メッセージ（ＲＲＣＲｅｌｅａｓｅメッセージ等）を受信することによって完了する。また、この応答メッセージは、ＵＥがどのＵＥ状態にあるべきかをも指示してよく、例えば、ＵＥに非アクティブ状態に留まるように指示してよい。既に上述したように、接続再開要求メッセージの完了は、ＵＥ識別情報が破棄されることをもたらす。したがって、（ＵＥ状態を指示する）応答メッセージの受信時に、ＵＥ識別情報は、ＵＥによって破棄される。
【0176】
また、同様に、ＵＥは、例えば、サービング基地局によってさらなるリソース割当てが送信されないことを想定して、（ＵＥ状態を指示する）応答メッセージの受信時に監視機能を停止してもよい。
【0177】
上記２つの変形例によれば、ＵＥは、上りリンクリソース割当ての受信に基づいて、タイマ（例えば、第１の変形例の１つのタイマ、および第２の変形例の第２のタイマ）を再始動するか否かの決定を行う。あるいは、上りリンクリソース割当ての受信を用いる代わりに、後に実行されるスモールデータ送信をトリガーとして用いることができる。したがって、例えば、以前に受信した上りリンクリソース割当てに基づく上りリンクスモールデータ送信の実行時に、ＵＥは、上記の第１の変形例および第２の変形例について説明したそれぞれのタイマを再始動して、ＵＥ識別情報をより長く有効に保ち、したがって、その早期破棄を回避する。
【0178】
さらなる例示的な変形例によれば、ＵＥがそれぞれのタイマを再始動すべきか否かの決定には、追加的にまたは代替的に、ＵＥのバッファに残っている上りリンクデータがあるか否かを考慮に入れることもできる。例えば、ＵＥは、ＵＥのバッファ内に残っている上りリンクスモールデータがある場合（例えば、バッファ状態報告がスモールデータ送信と一緒に送信されるかまたは一緒には送信されない場合）、それぞれのタイマを再始動すると決定する。一方、ＵＥは、ＵＥのバッファにさらなる上りリンクスモールデータが残っていない場合（例えば、バッファ状態報告が送信されない場合、または、送信されるバッファ状態報告がさらなるデータを示さない場合）、それぞれのタイマを再始動しないと決定する。
【0179】
【0180】
図２２は、第１の解決策の第１の変形例（１つのタイマが使用される）による、ＵＥとサービングｇＮＢとのメッセージ交換を例示的にかつ簡略化して示している。図２２による例示的な実装形態は、図１６の実装形態について説明したものと同様の例示的な想定を行う。例えば、例示的に、スモールデータ送信のために４ステップのランダムアクセス手順がＵＥによって開始されると想定されている。ＵＥのＵＥコンテキストはアンカーｇＮＢに存在し、ＵＥは現在そのサービングｇＮＢにキャンプしているとさらに例示的に想定されており、その結果、サービングｇＮＢは、ＵＥの認証を行うために、アンカーｇＮＢからＵＥコンテキストを取得する必要がある。
【0181】
図２２から明らかなように、Ｔ３１９タイマは、Ｃ－ＲＮＴＩにアドレス指定された上りリンクグラントがＵＥによって受信されるたびに再始動される。
【0182】
さらに、例えば、ＵＥは、送信可能なさらなるデータについてサービングｇＮＢに知らせるために、（例えば、スモールデータと一緒に）バッファ状態報告を送信する。したがって、受信したバッファ状態報告に基づいて、サービングｇＮＢは、ＵＥバッファ内に残っているスモールデータのためのさらなる上りリンクグラントをＵＥに提供すると決定することができる。この手順は、さらなるスモールデータがＵＥバッファに残っていない状態まで繰り返すことができる。例えば、その場合、ＵＥは、スモールデータと一緒にはバッファ状態報告を送信しないか、またはバッファ状態報告を送信する場合、バッファ状態報告は、さらなるスモールデータが送信可能でないことを適切に示す。
【0183】
そうすると、ｇＮＢは、ＲＲＣＲｅｌｅａｓｅメッセージをＵＥに送信すると決定し、それによって、ＵＥに非アクティブ状態に留まるよう指示することができる。ＵＥにおけるＴ３１９タイマは、Ｃ－ＲＮＴＩの破棄につながるＲＲＣ解放メッセージの受信時に停止される。
【0184】
図２２に示すように、サービングｇＮＢは、非アクティブＵＥからＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔメッセージを受信すると、アンカーｇＮＢからのＵＥコンテキストの取得を開始し、最終的に当該ＵＥコンテキストを取得する。それにもかかわらず、ＲＲＣＲｅｌｅａｓｅメッセージは、サービングｇＮＢによって直ちに送信される必要はなく、ｇＮＢは、複数のスモールデータ送信を可能にするためにＵＥにさらなる上りリンクグラントを送信することができる。これにより、ＵＥにおける（およびサービングｇＮＢに示されるように）送信可能なスモールデータを送信する必要に応じて、ＵＥが上りリンクスモールデータ送信を実行することができるという利点がある。
【0185】
図２３は、第１の解決策の第１の変形例（１つのタイマが使用される）によるＵＥとサービングｇＮＢとのメッセージ交換を例示的にかつ簡略化して示している。ただし、４ステップＲＡＣＨ手順ではなく２ステップＲＡＣＨ手順を想定する。いずれにせよ、図２３の手順は、図２２の手順とほとんど同一であり、２ステップＲＡＣＨ手順を使用する、すなわち、Ｍｓｇ１～Ｍｓｇ４の代わりに、ＭｓｇＡおよびＭｓｇＢが送信されることによる差異がある。しかし、重要なことに、図２２について上記で詳細に説明したように、タイマＴ３１９は、ＵＥ識別情報（Ｃ－ＲＮＴＩ）にアドレス指定された上りリンクグラントを受信するたびに、非アクティブＵＥによって再始動される。
【0186】
図２４は、第１の解決策の第２の変形例（２つのタイマが使用される）による、ＵＥとサービングｇＮＢとのメッセージ交換を例示的にかつ簡略化して示している。図２２と同様の想定がなされている。第１のタイマは、Ｔ３１９タイマとして実装され、第２のタイマは、ＵＥ識別情報（例えば、Ｃ－ＲＮＴＩ）の有効性を制御する目的で動作する新しいタイマ（例示的にＴ３１９’と呼ばれる）である。さらに、第２の変形例について一般的に上述したように、ＵＥ識別情報は、２つのタイマの１つがまだ動作している間は破棄されず、ＵＥ識別情報の破棄は、上記タイマ（Ｔ３１９およびＴ３１９’）がいずれも動作していない（例えば、満了または停止している）ときにＵＥによって実行される。
【0187】
この第２の変形例によれば、第１のタイマＴ３１９は、接続再開要求メッセージ（例えば、ＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔメッセージ）の送信時にＵＥによって始動される。一方、新しいタイマＴ３１９’は、ＵＥのＣ－ＲＮＴＩ宛てのサービングｇＮＢからの第１の上りリンクグラントメッセージの受信時に始動される。さらに、新しいタイマＴ３１９’は、その後、さらなる上りリンクグラントがＵＥによって受信されるたびに再始動される。
【0188】
第１のタイマＴ３１９の満了時、ＵＥ識別情報は、新しいタイマＴ３１９’が以前に既に始動されている（第１のタイマＴ３１９が満了する前に適時にサービング基地局によって送信された上りリンクグラントの受信により）と想定して、まだ破棄されない。
【0189】
新しいタイマＴ３１９’は、ＵＥによって以前に送信された接続再開要求メッセージに対する応答メッセージ（例えば、ＲＲＣＲｅｌｅａｓｅ）の受信時に、ＵＥによって停止される。
【0190】
図２５は、第１の解決策の第１の変形例による改良されたスモールデータ送信手順のためのＵＥ動作の例示的かつ簡略化された実装形態を示すフロー図である。したがって、ＵＥ識別情報の有効性を制御する１つのタイマＴ３１９がＵＥによって使用されることが想定されている。
【0191】
一般に、一例によれば、ＵＥの動作は、サービングｇＮＢにバッファ状態報告を送信すべきか否かの決定を含む。バッファ状態報告が送信されるのは、スモールデータ送信の後、さらなるスモールデータが送信可能である場合であり、バッファ状態報告が当該残りのスモールデータを示している。バッファ状態報告は、全てのスモールデータの送信が可能である場合には、送信されない。
【0192】
これは、例示的に、図２５のＵＥ動作に反映されており、同図によれば、ＵＥは、（ランダムアクセス応答メッセージによって提供される）グラントサイズがすべての利用可能なスモールデータを送信するのに十分であるか否かに基づいて、スモールデータおよび接続再開要求メッセージをバッファ状態報告なしで送信するかまたはバッファ状態報告と共に送信するかを決定する。グラントサイズが十分である場合（例えば、送信可能なさらなるスモールデータがない場合）、ＵＥは、バッファ状態報告を送信せずに、ＲＡＣＨ手順のＭｓｇ３またはＭｓｇＡ中でＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔメッセージと共にスモールデータを送信する。逆に、グラントサイズが十分でない場合（例えば、さらなるスモールデータが送信可能な状態で残る場合）、ＵＥは、ＲＡＣＨ手順のＭｓｇ３またはＭｓｇＡにおいて、スモールデータおよびＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔメッセージと共にバッファ状態報告を送信する。
【0193】
その後、ＵＥは、Ｔ３１９タイマを始動し、ｇＮＢからの応答を受信することができるように、監視機能の実行を開始する。ＵＬグラントを受信すると、ＵＥは、Ｔ３１９タイマを再始動し、ＵＥのＣ－ＲＮＴＩにアドレス指定された他の上りリンクグラント（例えば、ＤＣＩ）の監視を続ける。
【0194】
さらに、ＵＥ識別情報（Ｃ－ＲＮＴＩ）の破棄は、ＵＬグラントが受信されなかった後、タイマＴ３１９が満了した時に発生し、ＲＲＣＲｅｌｅａｓｅメッセージが受信された時にも発生する。
【0195】
また、ＵＥは、Ｔ３１９タイマが満了しない限り、監視機能を実行し続けてもよい。
【0196】
さらに、以下では、この改良されたスモールデータ送信手順の第１の解決策のためのｇＮＢの動作の例示的かつ簡略化された実装形態について説明する。
【0197】
例えば、ｇＮＢは、スモールデータ送信のためにＵＥによって開始されるＲＡＣＨ手順に参加する。さらに、ｇＮＢは、ＲＡＣＨ手順（例えば、Ｍｓｇ３またはＭｓｇＡを参照）中の一回のスモールデータ送信が、すべての利用可能なスモールデータを送信するのに十分であるか否かを決定する役割を担う。したがって、（例えば、適切なバッファ状態報告によって示される）さらなるスモールデータ送信が必要な場合、サービングｇＮＢは、（例えば、それぞれのタイマの満了前に）適時にＵＥに１つ以上のＵＬグラントを送信する役割を担う。
【0198】
図２６は、第１の解決策の第１の変形例による（すなわち、１つのタイマのみを使用する）改良されたスモールデータ送信手順のためのサービング基地局の動作の例示的かつ簡略化された実装形態を示すフロー図である。同図から明らかなように、ｇＮＢは、非アクティブＵＥから接続再開要求メッセージを受信し、それに応答して、アンカーｇＮＢから当該ＵＥのＵＥコンテキストを取得しようと試みる。図示されていないが、ｇＮＢは、ＲＡＣＨ手順の一部として、スモールデータの最初の送信を受信し、場合によっては、さらなるスモールデータが送信可能であるか否かを示すバッファ状態報告を受信する。ＵＥがさらなるスモールデータ送信を実行することができる場合、ｇＮＢは、Ｔ３１９タイマが満了する前に適切なＵＬグラントをＵＥに送信すること（Ｔ３１９タイマが既に満了した場合、ＵＥはＣ－ＲＮＴＩを破棄してしまい、ＵＬグラントを監視しないため遅すぎることになる）、Ｔ３１９タイマを再始動すること、そして（以前のグラントに従って）ＵＥからＵＬデータを受信することを含むステップを実行する。
【0199】
そして、ｇＮＢは、ＵＥが、さらなるスモールデータが送信可能であることを示すか否かを再びチェックすることができる。このループは、例えば、全てのスモールデータがＵＥによって送信されるまで実行することができる。
【0200】
送信可能なさらなるスモールデータがない場合、ｇＮＢは、例えば、アンカーｇＮＢからのＵＥコンテキストの受信に成功した後に、ＲＲＣＲｅｌｅａｓｅメッセージのＵＥへの送信に進むことができる。
【0201】
上記したように、ＵＥは、さらなる上りリンクリソース割当てを受信し、次いで、１つ以上の追加の上りリンクスモールデータ送信を実行することができるように、監視機能を継続する（すなわち、延長する）。一方、第１の解決策のさらなる変形例によれば、監視は、下りリンクリソース割当ての受信を含んでよく、その後、（それぞれ、以前に受信された下りリンクリソース割当てに基づいて）サービングｇＮＢによる後続の下りリンク（スモール）データ送信が受信され得る。例えば、そのような下りリンクリソース割当ての受信（または代替的に、ＤＬスモールデータ送信の後続の受信）は、監視期間を延長するようにＵＥをトリガーし、また、ＵＥ識別情報をより長くアライブ状態のままにする（例えば、それぞれ上記した第１の変形例の１つのタイマを再始動するか、または第２の変形例の第２のタイマを再始動する）ようにＵＥをトリガーしてよい。
【0202】
上述のように、改良されたスモールデータ送信手順は、スモールデータ送信の少なくともいくつかを非常に早期に実行することを可能にする。例えば、アンカーｇＮＢからのＵＥコンテキストの取得を待つ必要なしに、サービングｇＮＢは、さらなるスモールデータ送信のために少なくともいくつかの上りリンクリソース割当てをＵＥに既に発行することができる。特に、競合が解消され、対応する競合解消がＵＥに通信されるとすぐに、サービング基地局は、非アクティブＵＥがＵＬスモールデータを送信できるように、ＵＥに次の上りリンクグラントを提供し始めることができる。
【0203】
１つの生じ得る欠点は、サービングｇＮＢが非アクティブＵＥを認証する前に（例えば、要求されたＵＥコンテキストに基づいて）、いくつかの初期ＵＬグラントが送信され得ることである。したがって、認証の前に許可された無線リソースは、ＵＥがサービングｇＮＢによって最終的に肯定的に認証されない場合に無駄になる可能性がある。さらに、ＵＥが認証前にＵＬスモールデータをサービングｇＮＢに送信することを可能にすることによって、サービングｇＮＢは、自身を可能性のある悪意のあるＵＥの攻撃にさらすことになる。
【0204】
＜第２の解決策＞
【0205】
改良されたスモールデータ送信手順（ならびにその変形例および実装形態）の第２の解決策によれば、サービング基地局は、監視機能を延長し、スモールデータの送信を継続することをＵＥに通知するために接続再開要求メッセージに対する応答メッセージを使用する。したがって、少なくとももう１つの他の上りリンクリソース割当ての受信のために監視機能を延長するか否かをＵＥが決定する基礎となる上記したメッセージが、この応答メッセージ（例えば、ＲＲＣＲｅｌｅａｓｅメッセージ）である。また、この接続再開要求応答メッセージは、ＵＥがあるべき状態に関する指示をＵＥに提供する、例えば、非アクティブＵＥに非アクティブ状態に留まるよう指示する。したがって、当該メッセージは、ＵＥ状態指示メッセージとして理解することができる。
【0206】
したがって、この接続再開要求応答メッセージは、監視機能を延長するか否かに関する非アクティブＵＥのための指示を含み得る。この監視指示は、例えば、例示的にｆｌａｇ＿ｓｕｂｓｅｑｕｅｎｔと呼ばれるフラグの形態であり得る。監視指示の１つの値は、ＵＥに、そのＵＥ識別情報にアドレス指定された後続の上りリンクグラントを監視するよう指示し、一方、監視指示の他の値は、ＵＥに、そのＵＥ識別情報にアドレス指定された後続の上りリンクグラントを監視しないよう指示する。
【0207】
次いで、非アクティブＵＥは、指示されたように監視機能を延長または停止することによって、監視指示に従う。
【0208】
ＵＥが、受信した監視指示に従って、監視機能をどのくらい長く実行し続けるべきかをどのように制御するかについては、いくつかの可能性がある。
【0209】
この第２の解決策の第１の変形例によれば、ＵＥは、特定の監視時間だけ（例えば、監視指示の受信時に開始することによって）監視機能を延長する。延長された監視時間の量は、様々な方法で、例えば、サービング基地局からＵＥによって、例えば、監視通知と一緒に（例えば、ＲＲＣＲｅｌｅａｓｅメッセージにおいて）、受信される情報に基づいて、定義することができる。追加的にまたは代替的に、監視時間の量は、例えば、サービング基地局からブロードキャストされるシステム情報によって、もしくは現在もしくは以前の基地局からの以前に受信された上位レイヤ（例えば、ＲＲＣ）構成メッセージによって、もしくはＵＥのユニバーサル加入者識別モジュール（Universal Subscriber Identify Module）に記憶された設定によって、事前に定義することができ、または、監視時間の量は、単に、３ＧＰＰ技術規格の要求の中で定義されている。例えば、上記は、例示的に、特定の時間量（例示的にｔｉｍｅｒ＿ｓｕｂｓｅｑｕｅｎｔと呼ばれる）を有するタイマを使用することによって実装することができ、このタイマの満了時に、ＵＥは、監視機能の実行を停止し得る。
【0210】
この第２の解決策の第２の変形例によれば、ＵＥは、監視指示を受信した後、特定の数のＵＬグラント受信（または、同様に、特定の数のスモールデータ送信）に達するまで継続する。ＵＥが指示された数のＵＬグラントを受信した場合、ＵＥは、監視機能の実行を停止する。ＵＬグラントの特定の数は、様々な方法で、例えば、監視時間について既に説明したのと同一の方法で定義することができる。より具体的には、上りリンクグラントの数は、サービング基地局からＵＥによって、例えば、監視通知と共に（例えば、ＲＲＣＲｅｌｅａｓｅメッセージにおいて）、受信される情報に基づいて定義することができる。追加的にまたは代替的に、上りリンクグラントの数は、例えば、サービング基地局からブロードキャストされるシステム情報によって、もしくは現在もしくは以前の基地局からの以前に受信された上位レイヤ（例えば、ＲＲＣ）構成メッセージによって、もしくはＵＥのユニバーサル加入者識別モジュールに記憶された設定によって、事前に定義することができ、または、単に３ＧＰＰ技術規格の要求の中で定義することができる。
【0211】
この第２の解決策のさらなる第３の変形例は、上述の第１および第２の変形例の組み合わせに基づく。特に、ＵＥは、特定の時間量の間、監視機能を実行し続け、例えば、監視指示を受信すると開始し（第１の変形例を参照）、また、受信したＵＬグラントをカウントする（例えば、監視指示を受信した後）（第２の変形例を参照）。ＵＥは、監視時間の量が満了した時に監視機能の実行を停止してもよく、ＵＥは、もっと早くに、ＵＥが受信した上りリンクグラントの数が到達した時に監視機能を停止してもよい。
【0212】
この第２の解決策のさらなる第４の変形例は、上述の第１の変形例に基づく。具体的には、ＵＥは、特定の量の監視時間の間、監視機能を実行し続ける。次いで、対応するＵＬグラントが受信されるたびに（あるいは、以前に受信されたＵＬグラントに基づくスモールデータ送信時に、または、さらなるスモールデータがＵＥにおける送信可能であることを示すバッファ状態報告の送信時に）、ＵＥは、監視時間を再開する（例えば、対応するタイマを再始動する）。これにより、非アクティブＵＥに上りリンクスモールデータ送信を実行するよう指示し得る頻度（または、長さ）について柔軟性を持たせることができ、同時に、最小の必要な監視時間を短く保つことができる。
【0213】
非アクティブＵＥによって実行される監視機能は、（上りリンクまたは下りリンク）リソース割当てがサービング基地局によってアドレス指定可能な、以前に割り当てられたＵＥ識別情報（例えば、Ｃ－ＲＮＴＩ）に基づく（例えば、第１の解決策についての説明を参照）。したがって、ＵＥ識別情報は、必要とされる限りアライブ状態のまま保たれることができ、必要がなくなれば、ＵＥによって破棄される（および、場合によっては、サービング基地局によって他のＵＥに再び割り当てられる）。
【0214】
例示的な一実装形態によれば、受信された接続再開要求応答メッセージにおけるこの指示は、ＵＥに後続のリソース割当てを提供するために次いで使用されるＵＥ識別情報の有効性を制御する方法にも直接的な影響を及ぼす。一般に、ＵＥ識別情報の有効性および破棄は、監視機能に基づいて制御することができるため、ＵＥは、監視機能を実行し続ける場合、ＵＥ識別情報を維持すると決定し、ＵＥは、監視機能の実行を停止すると決定する場合、ＵＥ識別情報を破棄すると決定する。
【0215】
例えば、ＵＥは、接続再開要求応答メッセージにおいて以前に受信された監視指示が、監視機能を延長しないよう指示する場合、ＵＥ識別情報を破棄すると決定する。先行技術および第１の解決策と比較して、ＵＥ識別情報は、接続再開要求応答メッセージ（例えば、ＲＲＣＲｅｌｅａｓｅメッセージ）の受信時に必ずしもＵＥによって破棄されない。むしろ、ＵＥ識別情報は、当該指示が、ＵＥが監視機能を延長すべきであることを示す場合、ＵＥによってアライブ状態のままにされ、一方、ＵＥ識別情報は、当該指示が、ＵＥが監視機能を延長する必要がないことを示す場合、ＵＥによって破棄される。
【0216】
また、ＵＥは、（例えば、上記した様々な変形例の１つに基づいて）監視機能を停止する場合、もはや必要でないＵＥ識別情報の破棄に進んでもよい。
【0217】
第２の解決策の上記の説明では、第２の解決策のための追加情報（例えば、指示、ならびにいくつかの変形例では、タイマ値およびカウンタ値も）が、接続再開要求応答メッセージを使用してＵＥに提供されることを概説した。以下では、接続再開要求応答メッセージによってこの追加情報がどのように正確に搬送され得るかに関するより具体的な実装形態について説明する。
【0218】
１つの可能な実装形態によれば、追加情報のすべてまたは一部は、実際の接続再開要求応答メッセージ（例えば、ＲＲＣＲｅｌｅａｓｅメッセージ）で搬送される。
【0219】
他の第２の可能な実装形態によれば、追加情報のすべてまたは一部は、接続再開要求応答メッセージと一緒に搬送されるが、当該メッセージ内には含まれない。例えば、追加情報の全部または一部は、接続再開要求応答メッセージに付されるＭＡＣ制御エレメント（MAC Control Element）に含まれ得る。
【0220】
他の第３の可能な実装形態によれば、追加情報のすべてまたは一部は、実際の接続再開要求応答メッセージを受信するための無線リソースを指示する下りリンクリソース割当てで搬送される。
【0221】
さらなる実装形態によれば、追加情報は、上記した３つの実装形態のうちの２つ以上の組み合わせに基づいてＵＥに提供される。
【0222】
図２７は、第２の解決策の例示的な実装形態による、ＵＥとサービングｇＮＢとのメッセージ交換を例示的にかつ簡略化して示している。図２７による例示的な実装形態は、図１６（または図２２）の実装形態について説明したのと同様の例示的な想定をしている。例えば、スモールデータ送信のために４ステップのランダムアクセス手順がＵＥによって開始されることが例示的に想定されている。さらに、ＵＥのＵＥコンテキストがアンカーｇＮＢに存在し、ＵＥが現在サービス提供を受けているサービングｇＮＢにキャンプしていると例示的に想定されている。したがって、サービングｇＮＢは、ＵＥの認証を実行するために、アンカーｇＮＢからＵＥコンテキストを取得する必要がある。
【0223】
図２７から明らかなように、ＲＲＣＲｅｌｅａｓｅメッセージ（すなわち、接続再開要求応答メッセージ）は、上述の監視指示を含み、監視指示の受信時に、ＵＥは、Ｔ３１９タイマを停止し、監視機能を延長する（例えば、監視期間を延長する）。これにより、ＵＥには、さらなる上りリンクグラントを受信し、次いで、上りリンクにおいて対応するスモールデータ送信を実行する機会が与えられる。図２７に反映される本実装形態では、ＲＲＣＲｅｌｅａｓｅメッセージは、延長されるべき監視期間に関する情報を、ｔｉｍｅｒ＿ｓｕｂｓｅｑｕｅｎｔ値（上記の第１の変形例を参照）としてさらに含むことが例示的に想定されている。したがって、ＵＥは、ＲＲＣＲｅｌｅａｓｅメッセージから、指示された時間の間、自身の監視機能を延長すべきであると決定する。
【0224】
当該指示された延長監視期間中、サービングｇＮＢは、必要に応じて、さらなる上りリンクスモールデータ送信をスケジューリングすることができる。延長監視期間が満了すると、ＵＥは、監視機能の実行を停止し、Ｃ－ＲＮＴＩを破棄する。さらに、ＵＥは、非アクティブ状態に留まる。
【0225】
図２８は、第２の解決策の例示的な実装形態による、ＵＥとサービングｇＮＢとのメッセージ交換を例示的にかつ簡略化して図示しており、この例示的な実装形態は、２ステップＲＡＣＨ手順を採用する点、および、バッファ状態報告と共にスモールデータ送信を実行するたびに監視期間を延長する（上記の第４の変形例を参照）点で、図２７の実装形態とは異なる。図２８から明らかなように、図２７と同様に、ＲＲＣＲｅｌｅａｓｅメッセージ（接続再開要求応答メッセージ）は、監視指示と、延長される監視時間の情報とを含む。一方、延長監視期間は、非アクティブＵＥによって、すなわち、非アクティブＵＥがバッファ状態報告と共にスモールデータを送信するたびに、繰返し延長される。ＵＥは、バッファ状態報告なしでスモールデータを送信する場合、監視期間を延長しない、すなわち、監視期間を延長する必要がない、なぜなら、サービング基地局は、バッファ状態報告がＵＥから受信されなかったことを考慮して、他の上りリンクグラントを発行しないからである。
【0226】
第２の解決策のさらなる変形例によれば、上りリンクグラントは、接続再開要求応答メッセージ（例えば、ＲＲＣＲｅｌｅａｓｅメッセージ）内でＵＥに直接提供することができる。これにより、ＵＥは、接続再開要求応答メッセージに続いて、第１の後続の上りリンクスモールデータ送信を早期に送信することができる。
【0227】
上記したように、ＵＥは、さらなる上りリンクリソース割当てを受信し、次いで上りリンクスモールデータ送信を実行できるようにするために、監視機能を継続する（すなわち、延長する）。一方、第２の解決策のさらなる変形例によれば、監視は、下りリンクリソース割当ての受信をも含んで、そして、（以前に受信された下りリンクリソース割当てに基づいて）サービングｇＮＢによる後続の下りリンク（スモール）データ送信を受信し得る。また、例えば、そのような下りリンクリソース割当ての受信（または代替的に、ＤＬスモールデータ送信の後続の受信）は、ＵＥが監視期間を繰り返し延長することをトリガーし得る。
【0228】
上記した第２の解決策によれば、サービングｇＮＢは、接続再開要求応答メッセージ（例えば、ＲＲＣＲｅｌｅａｓｅメッセージ）を使用して、ＵＥに必要な情報を提供することにより監視機能を延長してマルチスモールデータ送信手順を実施する。したがって、接続再開要求応答メッセージは、（例えば、アンカーｇＮＢから取得されたＵＥコンテキストに基づいて）ＵＥを認証した後にサービングｇＮＢによって送信される。監視通知の後に送信されるＵＬグラントは、ＵＥが認証された場合にのみ提供される。したがって、例えば、第１の解決策と比較して、リソースが浪費されるリスクは減少する。
【0229】
したがって、他方において、第２の解決策は、ＵＥが最初に認証されることを必要とし、それによって、ＵＥによって実行されるＵＬスモールデータ送信に対して遅延を導入する。
【0230】
＜第３の解決策＞
【0231】
改良されたスモールデータ送信手順（ならびにその変形例および実装形態）の第３の解決策によれば、サービング基地局は、ＵＥが監視機能を延長すべきか否かを指示する監視指示を含めるためにリソース割当てメッセージを使用する。
【0232】
したがって、少なくとももう１つの他の上りリンクリソース割当ての受信のために監視機能を延長するか否かをＵＥが決定する基礎となる上記したメッセージは、（例えば、ＤＣＩメッセージなど、下りリンクまたは上りリンクのための）リソース割当てメッセージである。
【0233】
したがって、このリソース割当てメッセージは、非アクティブＵＥが監視機能を延長するか否かを決定するための監視指示を含み得る。この監視指示は、例えば、第２の解決策の場合と同様に実装することができ、例えば、例示的にｆｌａｇ＿ｓｕｂｓｅｑｕｅｎｔと呼ばれるフラグの形態であり得る。監視指示の１つの値は、ＵＥに、そのＵＥ識別情報にアドレス指定された後続の上りリンクグラントを監視するよう指示し（例示的に、肯定的監視指示（positive monitoring indication）と呼ばれる）、一方、監視指示の他の値は、ＵＥに、そのＵＥ識別情報にアドレス指定された後続の上りリンクグラントを監視しないよう指示する（例示的に、否定的監視指示（negative monitoring indication）と呼ばれる）。
【0234】
次いで、非アクティブＵＥは、特定の延長監視期間の間監視機能を延長することによって、または、指示された通りに監視機能を停止することによって、監視指示に従う。
【0235】
リソース割当てメッセージは、ＵＥに監視機能を継続するよう指示するためにサービングｇＮＢによって繰り返し使用され得る。これにより、第３の解決策は、ＵＥが、監視指示を繰り返し受信することに従って監視機能の延長をどのくらい継続するかに関して柔軟である。
【0236】
１つの例示的な第１の変形例によれば、ＵＥは、少なくとも、リソース割当ての監視指示が、ＵＥが監視機能を延長するべきであることを指示する限り、監視機能を継続する。ＵＥが否定的監視指示（すなわち、監視機能を延長しない指示）を受信すると、ＵＥは、監視機能を停止する。ただし、例えば、ＵＥが依然として接続再開要求応答メッセージ（例えば、ＲＲＣＲｅｌｅａｓｅメッセージ）を監視し、場合によっては受信しなければならないために、タイマＴ３１９が依然として動作中であるなど、他の理由によって、監視機能を継続しなければならない場合を除く。
【0237】
上記の第１の変形例に加えて、または上記の第１の変形例に代えて、ＵＥは、他の例示的な第２の変形例によれば、監視指示によって特定の監視期間だけ監視機能を延長するよう指示されている場合、そのように監視機能を延長する。この延長監視期間の量は、例えば、ＵＥにおいて既に利用可能な情報に基づいて定義することができる。例えば、延長監視時間の量は、例えば、サービング基地局からブロードキャストされるシステム情報によって、もしくは現在もしくは以前の基地局からの以前に受信された上位レイヤ（例えば、ＲＲＣ）構成メッセージによって、もしくはＵＥのユニバーサル加入者識別モジュール（Universal Subscriber Identify Module）に記憶された設定によって、事前に定義することができ、または、３ＧＰＰ技術規格の要求の中で定義することができる。
【0238】
この延長監視期間は、サービングｇＮＢからリソース割当てにおいて肯定的監視指示を受信するたびに再開される。
【0239】
例えば、上記は、特定の時間量を有する新しいタイマ（例示的にＴ３１９’と呼ばれる）を使用することによって例示的に実装することができる。この新しいタイマＴ３１９’は、リソース割当てにおいて肯定的監視指示を受信したときに始動または再始動される。この新たなタイマＴ３１９’は、ＵＥに監視機能を停止するよう指示する否定的監視指示を受信したときに停止される。最後に、このＴ３１９’タイマが満了した時も、ＵＥは、監視機能の実行を停止する。
【0240】
この第２の変形例のメカニズムは、上述の第１の変形例のメカニズムに加えて使用することができ、したがって、例えば、否定的監視指示を有するリソース割当てが欠落している場合に、ＵＥが監視機能を無期限に継続することを回避する。
【0241】
非アクティブＵＥによって実行される監視機能は、（上りリンクまたは下りリンク）リソース割当てがサービング基地局によってアドレス指定可能な、以前に割り当てられたＵＥ識別情報（例えば、Ｃ－ＲＮＴＩ）に基づく（例えば、第１の解決策についての説明を参照）。したがって、ＵＥ識別情報は、必要とされる限りアライブ状態のまま保たれることができ、必要がなくなれば、ＵＥによって破棄される（および、場合によっては、サービング基地局によって他のＵＥに再び割り当てられる）。
【0242】
例示的な一実装形態によれば、リソース割当てメッセージにおける監視指示は、ＵＥに後続のリソース割当てを提供するために次いで使用されるＵＥ識別情報の有効性を制御する方法にも直接的な影響を及ぼす。一般に、ＵＥ識別情報の有効性および破棄は、監視機能に基づいて制御することができるため、ＵＥは、監視機能を実行し続ける場合、ＵＥ識別情報を維持すると決定し、ＵＥは、監視機能の実行を停止すると決定する場合、ＵＥ識別情報を破棄すると決定する。
【0243】
例えば、ＵＥは、監視機能を拡張しないよう指示する否定的監視指示を受信した場合、ＵＥ識別情報を破棄すると決定する。先行技術および第１の解決策と比較して、ＵＥ識別情報は、接続再開要求応答メッセージ（例えば、ＲＲＣＲｅｌｅａｓｅメッセージ）の受信時に必ずしもＵＥによって破棄されない。むしろ、ＵＥ識別情報は、監視指示および監視機能に従って、ＵＥによってアライブ状態のままに保たれる。
【0244】
また、ＵＥは、（例えば、上記した様々な変形例の１つに基づいて）監視機能を停止する場合、もはや必要でないＵＥ識別情報の破棄に進んでもよい。
【0245】
例示的な実施態様によれば、ＵＥ識別情報の有効性は、２つのタイマを使用することによって制御される。第１のタイマは、接続再開要求手順に要する時間を制御するために使用される。加えて、第２のタイマがＵＥによって作動し、ＵＥ識別情報の寿命（有効性）を延長することに用いられる。この第２のタイマは、サービング基地局から肯定的監視指示を有する最初のリソース割当てを受信した時に初めて始動され、その後、サービング基地局からリソース割当てにおける肯定的監視指示を受信するたびに毎回再始動される。次いで、ＵＥ識別情報は、第１および第２のタイマのいずれか１つが動作している限りアライブ状態のままであるが、第１のタイマおよび第２のタイマがいずれももはや動作していない（例えば、満了しているか、または停止された）ときに破棄される。
【0246】
５Ｇ－ＮＲ規格に準拠する実装形態によれば、監視指示を搬送するリソース割当ては、上りリンクリソース割当てまたは下りリンクリソース割当てのいずれかを参照することができ、上りリンクに対するＤＣＩフォーマット０＿１または０＿２および下りリンクに対するＤＣＩフォーマット１＿１または１＿２を使用して実装することができる。
【0247】
上記の第２の解決策で使用される接続再開要求応答メッセージの代わりに、監視指示を搬送するメッセージとしてリソース割当てを使用することによって、サービングｇＮＢは、アンカーｇＮＢからのＵＥコンテキストの取得から独立して監視指示をＵＥに提供することができる。言い換えれば、監視指示を搬送する第１のリソース割当ては、ＵＥコンテキストの取得の前または後に、例えば、非アクティブＵＥを認証する前または後に、サービングｇＮＢによってＵＥに送信することができる。したがって、サービングｇＮＢは、ＵＥを実際に認証する前に、監視指示と共にリソース割当てを送ることによって、あり得る上りリンクスモールデータ送信の遅延の低減を決定することができ、または、サービングｇＮＢは、ＵＥを肯定的に認証した後に、監視指示と共にリソース割当てを送ることによって、不正なＵＥで無線リソースを浪費するリスクの低減を決定し得る。
【0248】
図２９および図３０は、第３の解決策の２つの異なる例示的な実装形態を反映している。図２９は、第３の解決策の例示的な実装形態による、ＵＥとサービングｇＮＢとのメッセージ交換を例示的にかつ簡略化して示している。図２９は、図１６（または図２２、図２７）の実装形態について説明したのと同様の例示的な想定をしている。例えば、スモールデータ送信のために４ステップのランダムアクセス手順がＵＥによって開始されることが例示的に想定されている。さらに、ＵＥのＵＥコンテキストがアンカーｇＮＢに存在し、ＵＥが現在サービス提供を受けているサービングｇＮＢにキャンプしていると例示的に想定されている。したがって、サービングｇＮＢは、ＵＥの認証を実行するために、アンカーｇＮＢからＵＥコンテキストを取得する必要がある。
【0249】
図２９から明らかなように、上りリンクグラントは、監視指示（ｆｌａｇ＿ｓｕｂｓｅｑｕｅｎｔ）を有し、この監視指示は、ＵＥに監視機能を延長するよう指示する（例示的には、値がｆｌａｇ＿ｓｕｂｓｅｑｕｅｎｔ＝１の場合）かまたは監視機能を延長しないよう指示する（例示的には、値がｆｌａｇ＿ｓｕｂｓｅｑｕｅｎｔ＝０の場合）かのいずれかである。図２９の例示的な実装形態は、ＵＥ識別情報（例えば、Ｃ－ＲＮＴＩ）の有効性を制御するための新しいタイマＴ３１９’の上記した使用に基づいている。
【0250】
したがって、図２９に示すように、ＵＥが上りリンクグラントにおいて肯定的監視指示を受信する場合、新たなタイマＴ３１９’が始動または再始動され、その後、ＵＥは、監視機能を延長し、これにより、後続の上りリンクグラントを受信することができ、したがって、対応するスモールデータ送信を実行することができる。肯定的監視指示を有する上りリンクグラントのこのような交換および後続のスモールデータ上りリンク送信は、サービングｇＮＢとＵＥとの間で繰り返し実行され得る。
【0251】
上記の解決策に関して説明したように、ＵＥは、例えば、スモールデータと一緒に送信される（または一緒には送信されない）バッファ状態報告における対応する情報を提供することによって、さらなる上りリンクスモールデータ送信が必要とされていることを基地局に示し得る。したがって、サービングｇＮＢは、さらなる上りリンク無線リソースを非アクティブＵＥに割り当てるべきか否かを決定することができる。
【0252】
図２９の実装形態では、例示的に、サービングｇＮＢは、上りリンクスモールデータ送信が終了するまで、ＲＲＣＲｅｌｅａｓｅメッセージを送信するのを待機すると想定されている。ＲＲＣＲｅｌｅａｓｅメッセージを受信した時に、非アクティブＵＥは、第１のタイマＴ３１９を停止し、さらにＣ－ＲＮＴＩを破棄する。ＲＲＣＲｅｌｅａｓｅメッセージの指示されたＵＥ状態に従って、ＵＥは、非アクティブ状態に留まる。あるいは（また、図３０による例示的な実装形態にも示されるように）、サービングｇＮＢは、より早く（例えば、ＵＥコンテキストを取得しＵＥを肯定的に認証した直後に）ＲＲＣ解放メッセージを送信し得る。
【0253】
図３０は、第３の解決策の他の例示的な実装形態による、ＵＥとサービングｇＮＢとのメッセージ交換を例示的にかつ簡略化して示している。この例示的な実装形態は、例えば、上記の図２９による実装形態と、２ステップＲＡＣＨ手順を使用すること、サービング基地局からＲＲＣＲｅｌｅａｓｅメッセージをより早くに送信すること、および、新しいタイマを使用（始動および再始動）せず、むしろ、対応する上りリンクリソース割当てにおいて受信した監視指示に従うことで、異なっている（上記の第１の変形例を参照）。
【0254】
したがって、延長監視期間は、肯定的監視指示（ｆｌａｇ＿ｓｕｂｓｅｑｕｅｎｔ＝１を含む上りリンクグラントとして示される）を受信した時にＵＥによって開始され、否定的監視指示（ｆｌａｇ＿ｓｕｂｓｅｑｕｅｎｔ＝０を含む上りリンクグラントとして示される）を受信した時に停止される。
【0255】
さらに、サービングｇＮＢは、アンカーｇＮＢからＵＥコンテキストを取得しかつＵＥを肯定的に認証した直後に、ＲＲＣＲｅｌｅａｓｅメッセージをＵＥに送信すると決定する。サービングｇＮＢから上記ＲＲＣＲｅｌｅａｓｅメッセージを受信した時に、ＵＥは、Ｔ３１９タイマを停止するが、以前に受信した肯定的監視指示のために、サービング基地局からのさらなる上りリンクグラントについて監視を継続する。
【0256】
スモールデータ送信手順は、サービングｇＮＢが最後の上りリンクグラントを有する否定的監視指示を送信することによって終了し、ＵＥは、その時点で監視機能を停止し、Ｃ－ＲＮＴＩを破棄する。以前に受信したＲＲＣ解放メッセージおよびメッセージ内において指示されたＵＥ状態に従って、ＵＥは非アクティブ状態に留まる。
【0257】
上記したように、ＵＥは、さらなる上りリンクリソース割当てを受信し、次いで上りリンクスモールデータ送信を実行できるようにするために、監視機能を継続する（すなわち、延長する）。一方、第３の解決手段のさらなる変形例によれば、監視は、（場合によっては監視指示を有する）下りリンクリソース割当ての受信を含んで、そして、（以前に受信された下りリンクリソース割当てに基づいて）サービングｇＮＢによる後続の下りリンク（スモール）データ送信を受信し得る。また、例えば、監視指示を有するそのような下りリンクリソース割当ての受信は、ＵＥが監視期間を延長または停止することをトリガーする。
【0258】
＜第４の解決策＞
【0259】
改良されたスモールデータ送信手順（ならびにその変形例および実装形態）の第４の解決策によれば、ＵＥは、特に、ＵＥが、さらなるスモールデータが送信可能なままであると決定するか否かに基づいて、可能なさらなる上りリンクリソース割当てを受信することができるように、いつ監視機能を延長するかを独立して制御する。
【0260】
より具体的には、ＵＥは、送信可能なさらなるスモールデータはないと決定した場合（例えば、すべてのスモールデータが、Ｍｓｇ３もしくはＭｓｇＡにおいて、または後続の上りリンクスモールデータ送信によって、送信され得る場合）、さらなるＵＬグラントを受信するために監視機能を延長する必要はない。ただし、ＵＥは、以前に送信された接続再開要求メッセージ（例えば、ＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔメッセージ）への応答として予期される接続再開要求応答メッセージ（例えば、ＲＲＣＲｅｌｅａｓｅメッセージ）を受信することができるように監視機能を継続し得る。
【0261】
一方、ＵＥは、さらなるスモールデータが送信可能であると決定した場合、例えば、すべてのスモールデータが以前のスモールデータ送信において送信され得なかった場合、監視機能を延長する。
【0262】
第４の解決策のさらなる例示的な実装形態によれば、ＵＥは、監視機能を延長するか否かを決定すること対応付けてサービング基地局にバッファ状態報告を送信すると決定する。特に、バッファ状態報告は、送信可能なスモールデータがまだあるときに送信される。一方、送信可能なスモールデータがない場合、バッファ状態報告は、ＵＥによって送信される必要はない。
【0263】
したがって、サービング基地局は、バッファ状態報告の受信または非受信に基づいて、ＵＥがその監視機能を延長したか否かを認識する。次いで、サービング基地局は、対応する上りリンクグラントを非アクティブＵＥに送信するか否かを依然として決定することができる。
【0264】
例えば、サービング基地局は、ＵＥのバッファに送信可能なさらなるスモールデータがあることを示すバッファ状態報告をＵＥから受信するが、ＵＥに上りリンクグラントを送信しないと決定してよい。この場合、ＵＥは、監視機能を継続するが、基地局からいかなる上りリンクグラントも受信しない。
【0265】
図３１は、第４の解決策の例示的な実装形態による、ＵＥとサービングｇＮＢとのメッセージ交換を例示的にかつ簡略化して示している。図３１による例示的な実装形態は、図１６（または図２２）の実装形態について説明したのと同様の例示的な想定をしている。例えば、スモールデータ送信のために４ステップのランダムアクセス手順がＵＥによって開始されることが例示的に想定されている。さらに、ＵＥのＵＥコンテキストがアンカーｇＮＢに存在し、ＵＥが現在サービス提供を受けているサービングｇＮＢにキャンプしていると例示的に想定されている。したがって、サービングｇＮＢは、ＵＥの認証を実行するために、アンカーｇＮＢからＵＥコンテキストを取得する必要がある。
【0266】
図３１から明らかなように、監視機能の延長は、スモールデータが送信可能であるか否かに応じて、ＵＥによって制御される。例示的に、ＵＥは、Ｍｓｇ３を使用する最初のスモールデータ送信（バッファ状態報告と一緒）の後に、スモールデータが依然として送信可能であると決定し、したがって、監視機能を継続すると想定する（監視機能は、いずれにせよ、ＲＲＣＲｅｌｅａｓｅメッセージを受信できるようにするためにその時にはＵＥによって実行される）。しかし、ＲＲＣ解放メッセージを受信し、対応するＴ３１９タイマを停止した後も、ＵＥは、スモールデータが依然として送信可能であることを考慮して監視機能を継続する。したがって、ＵＥは、後続の上りリンクグラントを受信し、対応する上りリンクスモールデータ送信を実行することができる。あるいは、監視機能の延長は、ＵＥがバッファ状態報告を送信した時にＴ３１９が再始動されるように実装される。
【0267】
また、例示的に、スモールデータ送信後にもさらなるスモールデータが送信可能なままであり、ＵＥは、監視機能を再び延長すると決定し、また、スモールデータと共にバッファ状態報告をサービング基地局に送信すると決定することが想定される。
【0268】
したがって、ＵＥは、サービング基地局からさらなる上りリンクグラントを受信することができ、残りのスモールデータをサービング基地局に送信する。ここで、例示的に、ＵＥに送信可能なさらなるスモールデータが残っておらず、したがって、ＵＥは、監視機能を停止し、また、サービング基地局にバッファ状態報告を送信しないことが想定される。
【0269】
＜さらなる変形例＞
【0270】
以上、改良されたスモールデータ送信手順の多数の解決策、変形例、および実装形態について説明した。例えば、マルチスモールデータ送信手順をどのように実装することができるかに関して、４つの異なる解決策（およびそれぞれの変形例）をした。
【0271】
改良されたスモールデータ送信手順の説明された解決策および実装形態では、ＵＥは、非アクティブ状態（アイドル状態および接続状態にも言及した）にあると説明されている。特定の５Ｇ－ＮＲ準拠の変形例によれば、ＵＥは、ＲＲＣ＿ＩＮＡＣＴＩＶＥ状態（上記した非アクティブ状態に対応する）、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態（上記した接続状態に対応する）、またはＲＲＣ＿ＩＤＬＥ状態（上記されていない）にあってもよい。
【0272】
上記４つの解決策の変形例のさらなるセットは、非常に長いマルチＳＤＴ手順を有するという上記の課題に対処する。それに関連して考えられる１つの問題は、ＵＥが、このマルチＳＤＴ手順中に他のセルに移動する可能性があることである（この問題は、シングルＳＤＴ手順でも起こり得るが、その可能性はずっと低い）。その結果、例えば、古いサービングｇＮＢによって許可された無線リソースは、新たなサービングｇＮＢにキャンプする場合、ＵＥによってもはや使用することができない。
【0273】
この問題を解決する１つの変形例によれば、ＵＥは、サービングセルのリンク品質が一定のしきい値を下回ると、自身のサービング基地局に通知することができる。この場合、ＵＥは、次の上りリンクグラントを使用して、空のバッファを示すバッファ状態報告と、スモールデータとを多重化することができる。サービング基地局は、バッファ状態報告から、この非アクティブＵＥのためにさらなる上りリンクスモールデータ送信をスケジューリングする必要はないと決定する。したがって、ＵＥのモビリティに起因する、後続の上りリンクデータ送信のために割り当てられたＵＬグラントを利用することができないという問題を防止することができる。
【0274】
この問題を解決するための他の変形例によれば、ＵＥは、（上記変形例のように）ＵＥが他のセルに移動することをサービングｇＮＢに通知せず、代わりに、ｇＮＢは、上記４つの解決策の各々に対応するタイマ／カウンタにもっと小さい値を設定する。これは、マルチＳＤＴ手順の継続時間全体を短縮するためであり、したがって、上述の問題を軽減することができる。
【0275】
これに関連して議論される他の問題は、ＵＥが、以前に送信したＵＬデータが古いサービングｇＮＢによって正しく受信されたか否かを確認することができないことである。この場合、いくつかのＵＬデータは、依然としてＨＡＲＱバッファに残ったままである可能性がある。
【0276】
この問題を解決するための１つの変形例によれば、ＵＥは、論理チャネルの対応するバッファが空であっても、ＨＡＲＱバッファに残っている上りリンクデータに基づいて、スモールデータ送信手順を依然として開始してもよい。典型的には、いくつかの先行技術の解決策では、論理チャネルバッファにおいて待ち行列に入れられている上りリンクデータのみが、スモールデータ送信手順をトリガーする。
【0277】
この問題を解決するための他の変形例によれば、ＵＥは、ＨＡＲＱバッファ状態または論理チャネルバッファ状態にかかわらずセルを再選択し、必要に応じて、ＲＬＣ／ＴＣＰリカバリーメカニズムなど、システムの上位レイヤによって提供されるリカバリーメカニズムが使用される。
【0278】
＜さらなる態様＞
【0279】
第１の態様によれば、以下を有するユーザ機器（ＵＥ：User Equipment）が提供される。前記ＵＥの受信機は、前記ＵＥに現在サービスを提供（サービング）している基地局からＵＥ識別情報の割当てを受信する。前記ＵＥは、接続状態、アイドル状態、および非アクティブ状態のうちの非アクティブ状態にある。前記ＵＥ識別情報は、前記サービング基地局から送信される、少なくとも上りリンクリソース割当てを含む、リソース割当ての受信のための監視機能を実行するために前記非アクティブＵＥによって使用可能である。前記受信機は、前記ＵＥ識別情報に基づいて、前記サービング基地局から送信された上りリンクリソース割当てを受信する。当該受信された上りリンクリソース割当てによって、スモールデータの送信のために前記非アクティブＵＥによって使用可能な無線リソースが割り当てられる。前記ＵＥの送信機は、前記受信された上りリンクリソース割当てに基づいて、前記スモールデータの前記サービング基地局への送信を実行する。プロセッサは、前記ＵＥ識別情報に基づく少なくとももう１つの他の上りリンクリソース割当ての受信のために前記監視機能を延長するか否かを決定し、当該決定は、前記サービング基地局から受信されたメッセージに基づくか、または前記ＵＥが送信可能なさらなるスモールデータを有するか否かに基づく。
【0280】
前記第１の態様に加えて提供される第２の態様によれば、前記メッセージは、前記受信された上りリンクリソース割当てであり、前記プロセッサは、前記上りリンクリソース割当ての受信時に、または前記受信された上りリンクリソース割当てに基づく前記スモールデータの送信の実行時に、または前記さらなるスモールデータが前記ＵＥにより送信可能であることを示すバッファ状態報告の送信時に前記監視機能を延長すると決定する。
【0281】
前記第２の態様に加えて提供される第３の態様によれば、前記ＵＥ識別情報の破棄は、１つまたは２つのタイマに基づいて制御され、当該制御は、
前記ＵＥ識別情報の有効性を制御するために１つのタイマを動作させることを含み、前記タイマは、前記監視機能の実行開始時に始動され、前記タイマは、前記上りリンクリソース割当ての受信時に、もしくは前記スモールデータの前記送信の実行時に、もしくは前記さらなるスモールデータが前記ＵＥにより送信可能であることを示す前記バッファ状態報告の送信時に再始動され、前記プロセッサは、前記タイマの満了時に前記ＵＥ識別情報を破棄すると決定する、または
前記ＵＥ識別情報の有効性を制御するために第１のタイマおよび第２のタイマをそれぞれ動作させることを含み、前記第１のタイマは、前記監視機能の実行開始時に始動され、前記第２のタイマは、前記上りリンクリソース割当ての受信のたびに、もしくは前記スモールデータの前記送信の実行のたびに、もしくは前記さらなるスモールデータが前記ＵＥにより送信可能であることを示す前記バッファ状態報告の送信のたびに始動されもしくは再始動され、前記プロセッサは、前記第１のタイマおよび前記第２のタイマがいずれも動作していない場合、前記ＵＥ識別情報を破棄すると決定する。
前記ＵＥ識別情報の有効性を制御するために１つのタイマを動作させることを含み、前記タイマは、前記監視機能の実行開始時に始動され、前記タイマは、前記上りリンクリソース割当ての受信時に、もしくは前記スモールデータの前記送信の実行時に、もしくは前記さらなるスモールデータが前記ＵＥにより送信可能であることを示す前記バッファ状態報告の送信時に再始動され、前記プロセッサは、前記タイマの満了時に前記ＵＥ識別情報を破棄すると決定する、または
前記ＵＥ識別情報の有効性を制御するために第１のタイマおよび第２のタイマをそれぞれ動作させることを含み、前記第１のタイマは、前記監視機能の実行開始時に始動され、前記第２のタイマは、前記上りリンクリソース割当ての受信のたびに、もしくは前記スモールデータの前記送信の実行のたびに、もしくは前記さらなるスモールデータが前記ＵＥにより送信可能であることを示す前記バッファ状態報告の送信のたびに始動されもしくは再始動され、前記プロセッサは、前記第１のタイマおよび前記第２のタイマがいずれも動作していない場合、前記ＵＥ識別情報を破棄すると決定する。
【0282】
前記第２または第３の態様に加えて提供される第４の態様によれば、前記受信機は、前記非アクティブＵＥに前記非アクティブ状態に留まるよう指示するＵＥ状態指示メッセージを前記サービング基地局から受信する。前記ＵＥ識別情報は、前記ＵＥ状態指示メッセージの受信時に、破棄される。１つのオプション実装において、前記プロセッサは、前記ＵＥ状態指示メッセージの受信時に他の上りリンクリソース割当てを受信するための前記監視機能の実行を停止する。他のオプション実装において、前記ＵＥ状態指示メッセージは、前記非アクティブＵＥによって前記サービング基地局に以前に送信された接続再開要求メッセージに対する応答である。
【0283】
前記第１の態様に加えて提供される第５の態様によれば、前記プロセッサは、前記メッセージが、前記非アクティブＵＥに前記監視機能を延長するよう指示する監視指示を含む場合、前記監視機能を延長すると決定する。前記メッセージは、前記非アクティブＵＥに前記非アクティブ状態に留まるよう指示し、かつ、前記監視機能を延長するか否かを指示する前記監視指示を含む、ＵＥ状態指示メッセージである。１つのオプション実装において、前記ＵＥ状態指示メッセージは、前記非アクティブＵＥによって前記サービング基地局に以前に送信された接続再開要求メッセージに対する応答である。
【0284】
前記第５の態様に加えて提供される第６の態様によれば、前記プロセッサは、ある量の監視時間に到達した時に、他の上りリンクリソース割当ての受信のための前記監視機能の実行を停止する。前記監視時間の量は、前記メッセージに含まれる情報に基づいて、または前記非アクティブＵＥによって利用可能な事前設定済み情報に基づいて決定され、オプションで、前記事前設定済み情報は、前記サービング基地局からブロードキャストされるシステム情報によって、または基地局からの以前の上位レイヤ構成メッセージによって、または前記非アクティブＵＥのユニバーサル加入者識別モジュール（Universal Subscriber Identity module）から、または技術規格の要件から、前記ＵＥに提供される。１つのオプション実装において、前記監視時間の量は、前記上りリンクリソース割当ての受信時に、または前記受信された上りリンクリソース割当てに基づく前記スモールデータの前記送信の実行時に、または前記さらなるスモールデータが前記ＵＥにより送信可能であることを示すバッファ状態報告の送信時に、延長される。
【0285】
前記第５または第６の態様に加えて提供される第７の態様によれば、前記メッセージは、上りリンクリソース割当ての数に関する情報をさらに提供する。前記プロセッサは、前記数の上りリンクリソース割当てを受信した時に、他の上りリンクリソース割当ての受信のための前記監視機能の実行を停止する。
【0286】
前記第５から第７の態様の１つに加えて提供される第８の態様によれば、前記監視指示は、
● 前記ＵＥ状態指示メッセージに含まれ、または
● 前記ＵＥ状態指示メッセージと共に送信され、または
● 前記ＵＥ状態指示メッセージを受信するために前記非アクティブＵＥによって使用可能な下りリンク無線リソースを割り当てる下りリンクリソース割当てに含まれる。
● 前記ＵＥ状態指示メッセージに含まれ、または
● 前記ＵＥ状態指示メッセージと共に送信され、または
● 前記ＵＥ状態指示メッセージを受信するために前記非アクティブＵＥによって使用可能な下りリンク無線リソースを割り当てる下りリンクリソース割当てに含まれる。
【0287】
前記第５から第８の態様の１つに加えて提供される第９の態様によれば、前記ＵＥ識別情報の破棄は、前記監視機能に基づいて制御される。１つのオプション実装において、前記プロセッサは、前記監視機能の実行を停止すると決定した時に前記ＵＥ識別情報を破棄すると決定する。１つのオプション実装において、前記プロセッサは、前記監視指示が、前記非アクティブＵＥに前記監視時間を延長しないよう指示する場合、前記ＵＥ識別情報を破棄すると決定する。
【0288】
前記第１の態様に加えて提供される第１０の態様によれば、前記プロセッサは、前記メッセージが、前記非アクティブＵＥに前記監視機能を延長するよう指示する監視指示を含む場合、前記監視機能を延長すると決定する。前記メッセージは、データの送受信のために前記非アクティブＵＥによって使用可能な無線リソースを割り当て、かつ、前記監視機能を延長するか否かを指示する監視指示を含む、リソース割当てである。１つのオプション実装において、前記プロセッサは、前記リソース割当ての前記監視指示が前記監視機能を延長しないよう指示する場合、前記監視機能を停止する。
【0289】
前記第１０の態様に加えて提供される第１１の態様によれば、前記ＵＥ識別情報の破棄は、前記監視指示に基づいて制御される。前記プロセッサは、前記監視指示が前記監視機能を延長しないよう指示する場合、前記ＵＥ識別情報を破棄すると決定する。または、前記ＵＥ識別情報の破棄は、２つのタイマに基づいて制御され、前記制御は、
前記ＵＥ識別情報の有効性を制御するために第１のタイマおよび第２のタイマをそれぞれ動作させることを含み、前記第１のタイマは、前記監視機能の実行開始時に始動され、前記第２のタイマは、前記監視指示が前記監視機能を延長するよう指示する場合に始動されまたは再始動され、前記プロセッサは、前記第１のタイマおよび前記第２のタイマがいずれも動作していない場合、前記ＵＥ識別情報を破棄すると決定する。
前記ＵＥ識別情報の有効性を制御するために第１のタイマおよび第２のタイマをそれぞれ動作させることを含み、前記第１のタイマは、前記監視機能の実行開始時に始動され、前記第２のタイマは、前記監視指示が前記監視機能を延長するよう指示する場合に始動されまたは再始動され、前記プロセッサは、前記第１のタイマおよび前記第２のタイマがいずれも動作していない場合、前記ＵＥ識別情報を破棄すると決定する。
【0290】
前記第１の態様に加えて提供される第１２の態様によれば、前記プロセッサは、前記ＵＥが送信可能なさらなるスモールデータを有する場合、前記監視機能を拡張すると決定する。１つのオプション実装において、前記送信機は、前記非アクティブＵＥが送信可能なさらなるスモールデータを有する場合、バッファ状態報告を前記サービング基地局に送信する。１つのオプション実装において、前記バッファ状態報告は、前記スモールデータと共に送信される。
【0291】
前記第１から第１２の態様の１つに加えて提供される第１３の態様によれば、前記ＵＥ識別情報は、前記非アクティブＵＥと前記サービング基地局の間で実行されるランダムアクセス手順中に前記非アクティブＵＥに割り当てられる。１つのオプション実装において、前記ランダムアクセス手順は、２つのステップを含み、第１のスモールデータの送信は、前記２ステップランダムアクセス手順の第１のメッセージによって実行される。１つのオプション実装において、前記ランダムアクセス手順は、４つのステップを含み、前記第１のスモールデータの前記送信は、前記４ステップランダムアクセス手順の第３のメッセージによって実行される。１つのオプション実装において、スモールデータの第１の送信は、前記ＵＥと前記基地局の間で実行される前記ランダムアクセス手順の一部として実行される。
【0292】
前記第１から第１３の態様の１つに加えて提供される第１４の態様によれば、前記非アクティブＵＥによって前記サービング基地局にバッファ状態報告が送信され、前記バッファ状態報告は、前記非アクティブＵＥのバッファの送信可能なデータに関する情報を提供する。
【0293】
前記第１から第１４の態様の１つに加えて提供される第１５の態様によれば、前記非アクティブ状態、前記接続状態、および前記アイドル状態は、無線リソース制御（ＲＲＣ：Radio Resource Control）プロトコルに関連している。
【0294】
前記第１から第１５の態様の１つに加えて提供される第１６の態様によれば、前記受信機は、前記非アクティブＵＥに前記接続状態に遷移するようまたは前記非アクティブ状態に留まるよう指示するＵＥ状態指示を前記サービング基地局から受信する。前記プロセッサは、前記受信されたＵＥ状態指示に従うように前記ＵＥの状態を制御する。１つのオプション実装において、前記ＵＥ状態指示は、前記非アクティブＵＥによって送信された接続要求メッセージに応答して前記基地局によって送信される。
【0295】
第１７の態様によれば、ユーザ機器（ＵＥ：User Equipment）によって実行される以下のステップ、
前記ＵＥに現在サービスを提供（サービング）している基地局からＵＥ識別情報の割当てを受信するステップであって、前記ＵＥは、接続状態、アイドル状態、および非アクティブ状態のうちの非アクティブ状態にあり、前記ＵＥ識別情報は、前記サービング基地局から送信される、少なくとも上りリンクリソース割当てを含む、リソース割当ての受信のための監視機能を実行するために非アクティブＵＥによって使用可能である、ステップと、
前記ＵＥ識別情報に基づいて、前記サービング基地局から送信された上りリンクリソース割当てを受信するステップであって、当該受信した上りリンクリソース割当てによって、スモールデータの送信のために前記非アクティブＵＥによって使用可能な無線リソースが割り当てられる、ステップと、
前記受信した上りリンクリソース割当てに基づいて、前記スモールデータの前記サービング基地局への送信を実行するステップと、
前記ＵＥ識別情報に基づく少なくとももう１つの他の上りリンクリソース割当ての受信のために前記監視機能を延長するか否かを決定するステップであって、前記決定は、前記サービング基地局から受信したメッセージに基づくか、または前記ＵＥが送信可能なさらなるスモールデータを有するか否かに基づく、ステップと、
を有する方法が提供される。
前記ＵＥに現在サービスを提供（サービング）している基地局からＵＥ識別情報の割当てを受信するステップであって、前記ＵＥは、接続状態、アイドル状態、および非アクティブ状態のうちの非アクティブ状態にあり、前記ＵＥ識別情報は、前記サービング基地局から送信される、少なくとも上りリンクリソース割当てを含む、リソース割当ての受信のための監視機能を実行するために非アクティブＵＥによって使用可能である、ステップと、
前記ＵＥ識別情報に基づいて、前記サービング基地局から送信された上りリンクリソース割当てを受信するステップであって、当該受信した上りリンクリソース割当てによって、スモールデータの送信のために前記非アクティブＵＥによって使用可能な無線リソースが割り当てられる、ステップと、
前記受信した上りリンクリソース割当てに基づいて、前記スモールデータの前記サービング基地局への送信を実行するステップと、
前記ＵＥ識別情報に基づく少なくとももう１つの他の上りリンクリソース割当ての受信のために前記監視機能を延長するか否かを決定するステップであって、前記決定は、前記サービング基地局から受信したメッセージに基づくか、または前記ＵＥが送信可能なさらなるスモールデータを有するか否かに基づく、ステップと、
を有する方法が提供される。
【0296】
第１８の態様によれば、以下を有する基地局が提供される。前記基地局の送信機は、前記基地局によって現在サービスが提供されているユーザ機器（ＵＥ：User Equipment）にＵＥ識別情報の割当てを送信し、前記ＵＥは、接続状態、アイドル状態、および非アクティブ状態のうちの非アクティブ状態にあり、前記ＵＥ識別情報は、少なくとも上りリンクリソース割当てを含むリソース割当てを前記ＵＥに送信するために前記基地局によって使用可能である。前記送信機は、前記ＵＥ識別情報に基づいて、前記非アクティブＵＥに上りリンクリソース割当てを送信し、当該送信された上りリンクリソース割当てによって、スモールデータの送信のために前記非アクティブＵＥによって使用可能な無線リソースが割り当てられ、また、当該送信された上りリンクリソース割当ては、前記非アクティブＵＥが前記割り当てられたＵＥ識別情報に基づくリソース割当ての受信のための監視機能を実行することに基づいて前記非アクティブＵＥによって受信可能である。前記基地局の受信機は、前記送信された上りリンクリソース割当てに基づいて、前記非アクティブＵＥからの前記スモールデータの受信を実行する。前記送信機は、前記非アクティブＵＥが前記ＵＥ識別情報に基づく少なくとももう１つの他の上りリンクリソース割当ての受信のために前記監視機能を延長するか否かを決定する基礎となるメッセージを前記非アクティブＵＥに送信する。
【0297】
第１９の態様によれば、基地局によって実行される以下のステップ、
前記基地局によって現在サービスが提供されているユーザ機器（ＵＥ：User Equipment）にＵＥ識別情報の割当てを送信するステップであって、前記ＵＥは、接続状態、アイドル状態、および非アクティブ状態のうちの非アクティブ状態にあり、前記ＵＥ識別情報は、少なくとも上りリンクリソース割当てを含むリソース割当てを前記ＵＥに送信するために前記基地局によって使用可能である、ステップと、
前記ＵＥ識別情報に基づいて、前記非アクティブＵＥに前記上りリンクリソース割当てを送信するステップであって、当該送信した上りリンクリソース割当てによって、スモールデータの送信のために前記非アクティブＵＥによって使用可能な無線リソースが割り当てられ、また、当該送信した上りリンクリソース割当ては、前記非アクティブＵＥが前記割り当てられたＵＥ識別情報に基づくリソース割当ての受信のための監視機能を実行することに基づいて前記非アクティブＵＥによって受信可能である、ステップと、
前記送信した上りリンクリソース割当てに基づいて、前記非アクティブＵＥからの前記スモールデータの受信を実行するステップと、
前記非アクティブＵＥが前記ＵＥ識別情報に基づく少なくとももう１つの他の上りリンクリソース割当ての受信のために前記監視機能を延長するか否かを決定する基礎となるメッセージを前記非アクティブＵＥに送信するステップと、
を有する方法が提供される。
前記基地局によって現在サービスが提供されているユーザ機器（ＵＥ：User Equipment）にＵＥ識別情報の割当てを送信するステップであって、前記ＵＥは、接続状態、アイドル状態、および非アクティブ状態のうちの非アクティブ状態にあり、前記ＵＥ識別情報は、少なくとも上りリンクリソース割当てを含むリソース割当てを前記ＵＥに送信するために前記基地局によって使用可能である、ステップと、
前記ＵＥ識別情報に基づいて、前記非アクティブＵＥに前記上りリンクリソース割当てを送信するステップであって、当該送信した上りリンクリソース割当てによって、スモールデータの送信のために前記非アクティブＵＥによって使用可能な無線リソースが割り当てられ、また、当該送信した上りリンクリソース割当ては、前記非アクティブＵＥが前記割り当てられたＵＥ識別情報に基づくリソース割当ての受信のための監視機能を実行することに基づいて前記非アクティブＵＥによって受信可能である、ステップと、
前記送信した上りリンクリソース割当てに基づいて、前記非アクティブＵＥからの前記スモールデータの受信を実行するステップと、
前記非アクティブＵＥが前記ＵＥ識別情報に基づく少なくとももう１つの他の上りリンクリソース割当ての受信のために前記監視機能を延長するか否かを決定する基礎となるメッセージを前記非アクティブＵＥに送信するステップと、
を有する方法が提供される。
【0298】
第２０の態様によれば、ユーザ機器（ＵＥ：User Equipment）の処理を制御する集積回路であって、前記処理が、前記ＵＥによって実行される以下のステップ、
前記ＵＥに現在サービスを提供（サービング）している基地局からＵＥ識別情報の割当てを受信するステップであって、前記ＵＥは、接続状態、アイドル状態、および非アクティブ状態のうちの非アクティブ状態にあり、前記ＵＥ識別情報は、前記サービング基地局から送信される、少なくとも上りリンクリソース割当てを含む、リソース割当ての受信のための監視機能を実行するために非アクティブＵＥによって使用可能である、ステップと、
前記ＵＥ識別情報に基づいて、前記サービング基地局から送信された上りリンクリソース割当てを受信するステップであって、当該受信した上りリンクリソース割当てによって、スモールデータの送信のために前記非アクティブＵＥによって使用可能な無線リソースが割り当てられる、ステップと、
前記受信した上りリンクリソース割当てに基づいて、前記スモールデータの前記サービング基地局への送信を実行するステップと、
前記ＵＥ識別情報に基づく少なくとももう１つの他の上りリンクリソース割当ての受信のために監視機能を延長するか否かを決定するステップであって、前記決定は、前記サービング基地局から受信したメッセージに基づくか、または前記ＵＥが送信可能なさらなるスモールデータを有するか否かに基づく、ステップと、を含む、
集積回路が提供される。
前記ＵＥに現在サービスを提供（サービング）している基地局からＵＥ識別情報の割当てを受信するステップであって、前記ＵＥは、接続状態、アイドル状態、および非アクティブ状態のうちの非アクティブ状態にあり、前記ＵＥ識別情報は、前記サービング基地局から送信される、少なくとも上りリンクリソース割当てを含む、リソース割当ての受信のための監視機能を実行するために非アクティブＵＥによって使用可能である、ステップと、
前記ＵＥ識別情報に基づいて、前記サービング基地局から送信された上りリンクリソース割当てを受信するステップであって、当該受信した上りリンクリソース割当てによって、スモールデータの送信のために前記非アクティブＵＥによって使用可能な無線リソースが割り当てられる、ステップと、
前記受信した上りリンクリソース割当てに基づいて、前記スモールデータの前記サービング基地局への送信を実行するステップと、
前記ＵＥ識別情報に基づく少なくとももう１つの他の上りリンクリソース割当ての受信のために監視機能を延長するか否かを決定するステップであって、前記決定は、前記サービング基地局から受信したメッセージに基づくか、または前記ＵＥが送信可能なさらなるスモールデータを有するか否かに基づく、ステップと、を含む、
集積回路が提供される。
【0299】
第２１の態様によれば、基地局の処理を制御する集積回路であって、前記処理が、前記基地局によって実行される以下のステップ、
前記基地局によって現在サービスが提供されているユーザ機器（ＵＥ：User Equipment）にＵＥ識別情報の割当てを送信するステップであって、前記ＵＥは、接続状態、アイドル状態、および非アクティブ状態のうちの非アクティブ状態にあり、前記ＵＥ識別情報は、少なくとも上りリンクリソース割当てを含むリソース割当てを前記ＵＥに送信するために前記基地局によって使用可能である、ステップと、
前記ＵＥ識別情報に基づいて、前記非アクティブＵＥに上りリンクリソース割当てを送信するステップであって、当該送信した上りリンクリソース割当てによって、スモールデータの送信のために前記非アクティブＵＥによって使用可能な無線リソースが割り当てられ、また、当該送信した上りリンクリソース割当ては、前記非アクティブＵＥが前記割り当てられたＵＥ識別情報に基づくリソース割当ての受信のための監視機能を実行することに基づいて前記非アクティブＵＥによって受信可能である、ステップと、
前記送信した上りリンクリソース割当てに基づいて、前記非アクティブＵＥからの前記スモールデータの受信を実行するステップと、
前記非アクティブＵＥが前記ＵＥ識別情報に基づく少なくとももう１つの他の上りリンクリソース割当ての受信のために前記監視機能を延長するか否かを決定する基礎となるメッセージを前記非アクティブＵＥに送信するステップと、を含む、
集積回路が提供される。
前記基地局によって現在サービスが提供されているユーザ機器（ＵＥ：User Equipment）にＵＥ識別情報の割当てを送信するステップであって、前記ＵＥは、接続状態、アイドル状態、および非アクティブ状態のうちの非アクティブ状態にあり、前記ＵＥ識別情報は、少なくとも上りリンクリソース割当てを含むリソース割当てを前記ＵＥに送信するために前記基地局によって使用可能である、ステップと、
前記ＵＥ識別情報に基づいて、前記非アクティブＵＥに上りリンクリソース割当てを送信するステップであって、当該送信した上りリンクリソース割当てによって、スモールデータの送信のために前記非アクティブＵＥによって使用可能な無線リソースが割り当てられ、また、当該送信した上りリンクリソース割当ては、前記非アクティブＵＥが前記割り当てられたＵＥ識別情報に基づくリソース割当ての受信のための監視機能を実行することに基づいて前記非アクティブＵＥによって受信可能である、ステップと、
前記送信した上りリンクリソース割当てに基づいて、前記非アクティブＵＥからの前記スモールデータの受信を実行するステップと、
前記非アクティブＵＥが前記ＵＥ識別情報に基づく少なくとももう１つの他の上りリンクリソース割当ての受信のために前記監視機能を延長するか否かを決定する基礎となるメッセージを前記非アクティブＵＥに送信するステップと、を含む、
集積回路が提供される。
【0300】
＜ハードウェアおよびソフトウェアによる本開示の実施＞
【0301】
本開示は、ソフトウェアによって、ハードウェアによって、またはハードウェアと協働するソフトウェアによって、実施することができる。上述した各実施形態の説明において使用される各機能ブロックは、その一部または全体を、集積回路などのＬＳＩによって実施することができ、各実施形態において説明した各プロセスは、その一部または全体を、同じＬＳＩまたはＬＳＩの組合せによって制御することができる。ＬＳＩは、チップとして個別に形成する、または、機能ブロックの一部またはすべてが含まれるように１個のチップを形成することができる。ＬＳＩは、自身に結合されたデータ入出力部を含むことができる。ＬＳＩは、集積度の違いに応じて、ＩＣ（集積回路）、システムＬＳＩ、スーパーＬＳＩ、またはウルトラＬＳＩとも称される。しかしながら、集積回路を実施する技術は、ＬＳＩに限定されず、専用回路、汎用プロセッサ、または専用プロセッサを使用することによって実施することができる。さらには、ＬＳＩの製造後にプログラムすることのできるＦＰＧＡ（フィールドプログラマブルゲートアレイ）や、ＬＳＩ内部に配置されている回路セルの接続および設定を再設定できるリコンフィギャラブル・プロセッサを使用することもできる。本開示は、デジタル処理またはアナログ処理として実施することができる。半導体技術または別の派生技術が進歩する結果として、ＬＳＩが将来の集積回路技術に置き換わる場合、その将来の集積回路技術を使用して機能ブロックを集積化することができる。バイオテクノロジを適用することもできる。
【0302】
本開示は、通信の機能を有する任意の種類の装置、デバイス、またはシステム（通信装置と呼ばれる）によって実施することができる。
【0303】
通信装置は、送受信機および処理／制御回路を備えていることができる。送受信機は、受信機および送信機を備えている、および／または、受信機および送信機として機能することができる。送信機および受信機としての送受信機は、増幅器、ＲＦ変調器／復調器などを含むＲＦ（無線周波数）モジュールと、１つ以上のアンテナを含むことができる。
【0304】
このような通信装置の非限定的ないくつかの例としては、電話（例：携帯電話、スマートフォン）、タブレット、パーソナルコンピュータ（ＰＣ）（例：ラップトップ、デスクトップ、ノートブック）、カメラ（例：デジタルスチル／ビデオカメラ）、デジタルプレイヤー（デジタルオーディオ／ビデオプレイヤー）、ウェアラブルデバイス（例：ウェアラブルカメラ、スマートウォッチ、トラッキングデバイス）、ゲームコンソール、電子書籍リーダー、遠隔医療／テレメディシン（リモート医療・医薬）装置、通信機能を提供する車両（例：自動車、飛行機、船舶）、およびこれらの様々な組合せ、が挙げられる。
【0305】
通信装置は、携帯型または可搬型に限定されず、非携帯型または据付け型である任意の種類の装置、デバイス、またはシステム、例えば、スマートホームデバイス（例：電化製品、照明、スマートメーター、制御盤）、自動販売機、および「モノのインターネット（ＩｏＴ：Internet of Things）」のネットワーク内の任意の他の「モノ」なども含むことができる。
【0306】
通信は、例えば、セルラーシステム、無線ＬＡＮシステム、衛星システム、その他、およびこれらの様々な組合せを通じてデータを交換するステップ、を含むことができる。
【0307】
通信装置は、本開示の中で説明した通信の機能を実行する通信デバイスに結合されたコントローラやセンサーなどのデバイスを備えることができる。例えば、通信装置は、通信装置の通信機能を実行する通信デバイスによって使用される制御信号またはデータ信号を生成するコントローラまたはセンサー、を備えていることができる。
【0308】
通信装置は、インフラストラクチャ設備、例えば、上の非限定的な例における装置等の装置と通信する、またはそのような装置を制御する基地局、アクセスポイント、および任意の他の装置、デバイス、またはシステムなどを、さらに含むことができる。
【0309】
さらに、様々な実施形態は、ソフトウェアモジュールによって実施してもよく、これらのソフトウェアモジュールは、プロセッサによって実行される、または、ハードウェアにおいて直接実行される。また、ソフトウェアモジュールとハードウェア実装の組合せも可能である。ソフトウェアモジュールは、任意の種類のコンピュータ可読記憶媒体、例えばＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、レジスタ、ハードディスク、ＣＤ－ＲＯＭ、ＤＶＤなどに格納することができる。さらには、複数の異なる実施形態の個々の特徴は、個別に、または任意の組合せにおいて、別の実施形態の主題とすることができることに留意されたい。
【0310】
特定の実施形態に示した本開示には、多数の変更および／または修正を行い得ることが、当業者には理解されるであろう。したがって、本明細書における実施形態は、あらゆる点において説明を目的としており、本発明を制限するものではないとみなされたい。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【図27】
【図28】
【図29】
【図30】
【図31】
【国際調査報告】