特表 2024-517912 ユーザ装置、及びユーザ装置の方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2024-04-23

(54)【発明の名称】ユーザ装置、及びユーザ装置の方法

(51)【国際特許分類】

   H04W 76/19 20180101AFI20240416BHJP

   H04W 48/10 20090101ALI20240416BHJP

   H04W 76/18 20180101ALI20240416BHJP

   H04W 28/04 20090101ALI20240416BHJP

   H04W 80/02 20090101ALI20240416BHJP

【ＦＩ】

H04W76/19

H04W48/10

H04W76/18

H04W28/04 110

H04W80/02

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2023569604

(86)(22)【出願日】2021-05-10

(85)【翻訳文提出日】2024-01-09

(86)【国際出願番号】 CN2021092838

(87)【国際公開番号】W WO2022236600

(87)【国際公開日】2022-11-17

(81)【指定国・地域】

(71)【出願人】

【識別番号】000004237

【氏名又は名称】日本電気株式会社

(74)【代理人】

【識別番号】100103894

【弁理士】

【氏名又は名称】家入 健

(72)【発明者】

【氏名】ワン ダー

(72)【発明者】

【氏名】ワン ガン

【テーマコード（参考）】

5K067

【Ｆターム（参考）】

5K067AA21

5K067CC14

5K067EE02

5K067EE10

5K067HH21

5K067HH28

(57)【要約】

本開示の実施形態は、通信の方法、装置、及びコンピュータ可読媒体に関する。端末装置は、非アクティブ状態におけるデータ送信を有するように設定された無線ベアラについての無線リンク制御（ＲＬＣ）エンティティ再確立が実行されるか否かを決定する。ＲＬＣエンティティ再確立が実行されると決定した場合、端末装置は、ＲＬＣエンティティを再確立する。その後、端末装置は、無線ベアラにて非アクティブ状態においてアップリンクデータを送信する。こうして、ＳＤＴを有するように設定された無線ベアラのためにＲＬＣエンティティ再確立を処理することは、該ＳＤＴのために該ＲＬＣエンティティ再確立を実行する必要があると端末装置が決定した場合に可能であるため、ＳＤＴプロシージャのパフォーマンスが向上する。
【選択図】図３

【特許請求の範囲】

【請求項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】

少なくとも一つのプロセッサ上で実行された場合、請求項４に記載の方法を前記少なくとも一つのプロセッサに実行させる命令を記憶している、
コンピュータ可読媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本開示の実施形態は、全体として、電気通信の分野に関し、特に、端末装置の非アクティブ状態におけるデータ送信中の通信の方法、装置、及びコンピュータ記憶媒体に関する。

【背景技術】

【0002】

通常、非アクティブ状態にある端末装置は、依然として、送信すべき少量で頻繁ではないデータトラフィックを有する場合がある。第３世代パートナシッププロジェクト（３ＧＰＰ（登録商標））リリース１６までは、非アクティブ状態は、データ送信をサポートしておらず、端末装置は、ダウンリンクデータとアップリンクデータのいずれについても接続を再開しなければならない（すなわち、接続状態に入らなければならない）。これは、不必要な電力消費とシグナリングオーバーヘッドを引き起こす。

【0003】

この場合、３ＧＰＰリリース１７では、非アクティブ状態におけるスモールデータ送信（ＳＤＴ）が承認されている。したがって、シグナリングオーバーヘッドを低減することができる。しかしながら、これまでのところ、ＳＤＴ関連技術は未だ未整備であり、さらなる発展が待たれる。

【発明の概要】

【発明が解決しようとする課題】

【0004】

全体として、本開示の実施形態は、通信の方法、装置、及びコンピュータ記憶媒体を提供する。

【課題を解決するための手段】

【0005】

第１の態様において、通信の方法が提供される。前記方法は、端末装置において、非アクティブ状態におけるデータ送信を有するように設定された無線ベアラについての無線リンク制御（ＲＬＣ）エンティティ再確立が実行されるか否かを決定することと、前記ＲＬＣエンティティ再確立が実行されるとの決定に従って、ＲＬＣエンティティを再確立することと、前記無線ベアラにて前記非アクティブ状態においてネットワーク装置にアップリンクデータを送信することと、を含む。

【0006】

第２の態様において、通信の方法が提供される。前記方法は、非アクティブ状態における端末装置からアップリンクデータと無線リソース制御（ＲＲＣ）再開要求メッセージとを受信したことに応じて、前記端末装置に、非アクティブ状態におけるデータ送信を有するように設定されていない無線ベアラについての無線リンク制御（ＲＬＣ）エンティティ再確立のための指示を含むＲＲＣ再開メッセージを送信することを含む。

【0007】

第３の態様において、通信の方法が提供される。前記方法は、非アクティブ状態におけるアップリンクデータの送信を実行する端末装置において、オンデマンド情報が利用可能か否かを決定することと、前記オンデマンド情報が利用不可能であるとの決定に従って、前記オンデマンド情報についての要求のネットワーク装置への送信をトリガすること、又は、前記オンデマンド情報についての前記要求の前記ネットワーク装置への送信を回避すること、のうちの少なくとも１つを実行することと、を含む。

【0008】

第４の態様において、通信の方法が提供される。前記方法は、端末装置において、非アクティブ状態におけるアップリンクデータの送信を、前記ネットワーク装置から前記端末装置宛てのページングメッセージを受信したことと、前記端末装置の無線リソース制御（ＲＲＣ）層において非アクセスストラタム層から接続確立の中断を受信したことと、前記非アクティブ状態における前記アップリンクデータの送信に関連する第１のタイマの満了と、すでに無線リンク制御（ＲＬＣ）再送信の最大回数に達したことと、最初のアップリンクデータ送信が所定の回数で失敗したことと、前記非アクティブ状態における前記アップリンクデータの送信をキャンセルする指示が前記端末装置のメディアアクセス制御（ＭＡＣ）層から前記ＲＲＣ層に提供されたことと、のうちの少なくとも１つに応じて、中断することを含む。

【0009】

第５の態様において、通信の方法が提供される。前記方法は、端末装置において、ＲＲＣ再開プロシージャに関連する第１の値に基づいて、前記ＲＲＣ再開プロシージャのためのメッセージ認証コード整合性（ＭＡＣ－Ｉ）のパラメータを決定することと、前記ＲＲＣ再開プロシージャを開始するために、前記パラメータを含むＲＲＣ再開要求メッセージを送信することと、を含み、前記第１の値は、別のＲＲＣ再開プロシージャのＭＡＣ－Ｉを決定するための第２の値とは異なる。

【0010】

第６の態様において、通信の方法が提供される。前記方法は、端末装置において、パワーヘッドルーム報告（ＰＨＲ）をトリガすることと、前記アップリンクデータが非アクティブ状態において送信されるとの決定に従って、アップリンク許可が前記アップリンクデータを受け入れ、前記ＰＨＲを追加として受け入れないか否かを決定することと、前記アップリンク許可が前記アップリンクデータを受け入れ、前記ＰＨＲを追加として受け入れないとの決定に従って、前記アップリンクデータにリソースを割り当てることと、前記割り当てられたリソースを使用して、ネットワーク装置に前記アップリンクデータを送信することと、を含む。

【0011】

第７の態様において、端末装置が提供される。前記端末装置は、プロセッサと、前記プロセッサに結合されたメモリとを備える。前記メモリは、前記プロセッサにより実行された場合、本開示の第１、第３、第４、第５、第６の態様に記載の方法を前記端末装置に実行させる命令を記憶している。

【0012】

第８の態様において、ネットワーク装置が提供される。前記ネットワーク装置は、プロセッサと、前記プロセッサに結合されたメモリとを備える。前記メモリは、前記プロセッサにより実行された場合、本開示の第２の態様に記載の方法を前記ネットワーク装置に実行させる命令を記憶する。

【0013】

第９の態様において、命令を記憶したコンピュータ可読媒体が提供される。前記命令は、少なくとも１つのプロセッサ上で実行された場合、本開示の前記第１、第３、第４、第５、第６の態様に記載の方法を前記少なくとも一つのプロセッサに実行させる。

【0014】

第１０の態様において、命令を記憶したコンピュータ可読媒体が提供される。前記命令は、少なくとも１つのプロセッサ上で実行された場合、本開示の第２の態様に記載の方法を前記少なくとも１つのプロセッサに実行させる。

【0015】

本開示のその他の特徴は、以下の説明により容易に理解することができるはずである。

【図面の簡単な説明】

【0016】

添付図面において本開示のいくつかの実施形態をさらに詳細に説明することで、本開示の上述の及びその他の目的、特徴及び利点をさらに明らかにする。

【0017】

【図1A】本開示のいくつかの実施形態を実施可能な例示的な通信ネットワークを示す図である。

【図1B】本開示のいくつかの実施形態を実施可能なユーザプレーン（ＵＰ：ｕｓｅｒ ｐｌａｎｅ）プロトコルスタックを示す模式図である。

【図1C】本開示のいくつかの実施形態を実施可能な制御プレーン（ＣＰ：ｃｏｎｔｒｏｌ ｐｌａｎｅ）プロトコルスタックを示す模式図である。

【図2A】本開示のいくつかの実施形態を実施可能なＳＤＴプロシージャを示す模式図である。

【図2B】本開示のいくつかの実施形態を実施可能な、最初のデータ送信フェーズと後続のデータ送信フェーズとを含むＳＤＴプロシージャを示す模式図である。

【図3】本開示のいくつかの実施形態にかかる、ＳＤＴプロシージャのためのシグナリングフローを示す図である。

【図4】本開示のいくつかの実施形態にかかる、ＳＤＴプロシージャのためのシグナリングフローを示す図である。

【図5】本開示のいくつかの実施形態にかかる、ＳＤＴプロシージャのためのシグナリングフローを示す図である。

【図6】本開示のいくつかの実施形態にかかる、ＳＤＴプロシージャのためのシグナリングフローを示す図である。

【図7】本開示のいくつかの実施形態にかかる、ＳＤＴプロシージャのためのシグナリングフローを示す図である。

【図8】本開示のいくつかの実施形態にかかる、端末装置において実現される例示的な通信方法を示す図である。

【図9】本開示のいくつかの実施形態にかかる、ネットワーク装置において実現される別の例示的な通信方法を示す図である。

【図10】本開示のいくつかの実施形態にかかる、端末装置において実現される別の例示的な通信方法を示す図である。

【図11】本開示のいくつかの実施形態にかかる、端末装置において実現される別の例示的な通信方法を示す図である。

【図12】本開示のいくつかの実施形態にかかる、端末装置において実現される別の例示的な通信方法を示す図である。

【図13】本開示のいくつかの実施形態にかかる、端末装置において実現される別の例示的な通信方法を示す図である。

【図14】本開示の実施形態を実装するのに適した装置の概略ブロック図である。

【0018】

図中、同一又は類似の参照番号は、同一又は類似の要素を表す。

【発明を実施するための形態】

【0019】

ここで、いくつかの実施形態を参照して、本開示の原理を説明する。これらの実施形態は、説明のためにのみ記載され、当業者が本開示を理解し、実施するのを助けるものであり、本開示の範囲に関するいかなる限定も示唆しないことを理解すべきである。本明細書で説明される開示内容は、以下で説明される方法とは異なる様々な方法で実施することができる。

【0020】

以下の説明及び特許請求の範囲において、別途定義されていない限り、本文で使用されるすべての技術的及び科学的用語は、本開示の当業者が一般に理解するものと同一の意味を有する。

【0021】

本文で使用されるように、用語「端末装置」は、無線又は有線の通信能力を有する任意の装置を意味する。端末装置の例としては、ユーザ装置（ＵＥ）、パーソナルコンピュータ、デスクトップコンピュータ、携帯電話、セルラーホン、スマートフォン、パーソナルデジタルアシスタント（ＰＤＡ）、ポータブルコンピュータ、タブレット、ウェアラブル装置、モノのインターネット（ＩｏＴ）装置、あらゆるモノのインターネット（ＩｏＥ）装置、マシンタイプ通信（ＭＴＣ）装置、Ｖ２Ｘ通信のための車載装置などを含むが、これらに限定されず、Ｖ２Ｘの「Ｘ」は、歩行者、車両又はインフラストラクチャ／ネットワーク、あるいはデジタルカメラなどの画像取得装置、ゲーム装置、音楽保存及び再生装置、あるいは無線又は有線のインターネットアクセス及び閲覧を可能とするインターネット家電などを表す。「端末装置」という用語は、ＵＥ、移動局、加入者局、移動端末、ユーザ端末、又は無線装置と互換的に使用することができる。また、「ネットワーク装置」という用語は、端末装置が通信可能なセル又はカバレッジを提供又はホストすることのできる装置を意味する。ネットワーク装置の例としては、ノードＢ（ＮｏｄｅＢ又はＮＢ）、進化型ノードＢ（ｅＮｏｄｅＢ又はｅＮＢ）、次世代ノードＢ（ｇＮＢ）、送受信ポイント（ＴＲＰ）、リモートラジオユニット（ＲＲＵ）、ラジオヘッド（ＲＨ）、リモートラジオヘッド（ＲＲＨ）、フェムトノード、ピコノードなどの低電力ノードを含むが、これらに限定されない。

【0022】

一実施形態において、端末装置は、第１のネットワーク装置及び第２のネットワーク装置に接続することができる。第１のネットワーク装置と第２のネットワーク装置の一方をマスターノードとして、他方をセカンダリ―ノードとしてもよい。第１のネットワーク装置と第２のネットワーク装置は、異なる無線アクセス技術（ＲＡＴ）を使用してもよい。一実施形態において、第１のネットワーク装置は、第１のＲＡＴ装置であってもよく、第２のネットワーク装置は、第２のＲＡＴ装置であってもよい。一実施形態において、第１のＲＡＴ装置は、ｅＮＢであり、第２のＲＡＴ装置は、ｇＮＢである。異なるＲＡＴに関する情報は、第１のネットワーク装置又は第２のネットワーク装置の少なくとも一方から端末装置に送信されてもよい。一実施形態において、第１の情報は、第１のネットワーク装置から端末装置に送信されてもよく、そして、第２の情報は、第２のネットワーク装置から直接又は第１のネットワーク装置を介して端末装置に送信されてもよい。一実施形態において、第２のネットワーク装置により設定された端末装置の設定に関する情報は、第２のネットワーク装置から第１のネットワーク装置を介して送信されてもよい。第２のネットワーク装置により設定された端末装置の再設定に関する情報は、第２のネットワーク装置から直接、又は第１のネットワーク装置を介して端末装置に送信されてもよい。

【0023】

本明細書で使用される単数形「１つ」、及び「前記」は、文脈に明示的に示されていない限り、複数形も含まれる。用語「含む」及びその変型は、「含むが、これらに限定されるものではない」を意味するオープンエンド用語として理解されるべきである。用語「に基づく」は、「に少なくとも部分的に基づく」と理解されるべきである。用語「一実施形態」及び「実施形態」は、「少なくとも１つの実施形態」と理解されるべきである。用語「別の実施形態」は、「少なくとも１つの他の実施形態」と理解されるべきである。「第１」、「第２」などの用語は、異なる又は同一の対象を指してもよい。以下では、その他の明示的及び暗黙的な定義を含む場合がある。

【0024】

いくつかの例において、値、プロシージャ、又は機器は、「最良」、「最低」、「最高」、「最小」、「最大」などと称される。このような説明は、多くの使用される機能的代替案の中から選択することができることを示すことを意図されており、そして、このような選択は、他の選択より良く、より小さく、より高い必要がなく、又はそのほかの点でより好ましい必要はないことを理解することができるはずである。

【0025】

通信環境の例
図１Ａは、本開示のいくつかの実施形態を実施可能な例示的な通信システム１００Ａを示す図である。通信ネットワークの一部である通信システム１００Ａは、まとめて「端末装置１１０」と称することができる端末装置１１０－１と、端末装置１１０－２と、…、端末装置１１０－Ｎとを備える。数Ｎは、任意の適切な整数であってもよい。

【0026】

通信システム１００Ａは、ネットワーク装置１２０をさらに含む。いくつかの実施形態において、ネットワーク装置１２０は、ｇＮＢであってもよい。代替として、ネットワーク装置１２０はＩＡＢであってもよい。図示しないが、通信システム１００Ａ内には、２つ以上のネットワーク装置１２０が存在してもよい。

【0027】

通信システム１００Ａにおいて、ネットワーク装置１２０と端末装置１１０とが互いにデータと制御情報とを通信してもよい。図１に示される端末装置１１０及びネットワーク装置１２０の数は、説明のためのみに示されており、いかなる限定も示唆していない。

【0028】

図１Ａに示すように、端末装置１１０は、無線通信チャネル等のチャネルを介してネットワーク装置１２０と通信してもよい。通信ネットワーク１００Ａにおける通信は、モバイル通信のためのグローバルシステム（ＧＳＭ）、ロングタームエボリューション（ＬＴＥ）、ＬＴＥ－Ｅｖｏｌｕｔｉｏｎ、ＬＴＥ－Ａｄｖａｎｃｅｄ（ＬＴＥ－Ａ）、広帯域符号分割多元接続（ＷＣＤＭＡ（登録商標））、符号分割多元接続（ＣＤＭＡ）、ＧＳＭ ＥＤＧＥ無線アクセスネットワーク（ＧＥＲＡＮ）、マシンタイプ通信（ＭＴＣ）などを含むが、これらに限定されない任意の適切な規格に準拠してもよい。さらに、通信は、現在知られている、又は将来開発される任意の世代の通信プロトコルに従って実行されてもよい。通信プロトコルの例は、第１世代（１Ｇ）、第２世代（２Ｇ）、２．５Ｇ、２．７５Ｇ、第３世代（３Ｇ）、第４世代（４Ｇ）、４．５Ｇ、第５世代（５Ｇ）通信プロトコルを含むが、これらに限定されない。

【0029】

端末装置１１０からネットワーク装置１２０に向かう方向の通信は、ＵＬ通信と称され、ネットワーク装置１２０から端末装置１１０に向かう方向の通信は、ＤＬ通信と称される。端末装置１１０は、ネットワーク装置１２０、そして場合によっては、他のネットワーク装置のセルの間を移動することができる。ＵＬ通信において、端末装置１１０は、ＵＬチャネルを介してＵＬデータ（例えば、データ無線ベアラ（ＤＲＢ：ｄａｔａ ｒａｄｉｏ ｂｅａｒｅｒ）を使用して送信されるデータ及び／又はシグナリング無線ベアラ（ＳＲＢ：ｓｉｇｎａｌｉｎｇ ｒａｄｉｏ ｂｅａｒｅｒ）を使用して送信されたデータ）をネットワーク装置１２０に送信してもよい。ＤＬ通信において、ネットワーク装置１２０は、ＤＬチャネルを介して、ＤＬデータを端末装置１１０に送信してもよい。

【0030】

通信ネットワーク１００Ａにおける通信は、ＵＰ及びＣＰプロトコルスタックに従って行われてもよい。一般に言うと、通信装置（例えば、端末装置１１０又はネットワーク装置）の場合、プロトコルスタック内の複数のネットワークプロトコル層の複数のエンティティが存在し、これらのエンティティは、通信装置から送信され、通信装置により受信されるデータ又はシグナリングに、対応するプロセスを実施するように設定されてもよい。図１Ｂは、本開示のいくつかの実施形態にかかる装置においてＵＰプロトコルスタックのために確立されてもよいネットワークプロトコル層エンティティを示す模式図１００Ｂである。

【0031】

図１Ｂに示すように、ＵＰにおいて、端末装置１１０及びネットワーク装置１２０のそれぞれは、Ｌ１層のエンティティ、つまり、物理（ＰＨＹ）層のエンティティ（ＰＨＹエンティティとも称される）と、媒体アクセス制御（ＭＡＣ）層のエンティティ（ＭＡＣエンティティとも称される）、無線リンク制御（ＲＬＣ）層のエンティティ（ＲＬＣエンティティとも称される）、パケットデータコンバージェンスプロトコル（ＰＤＣＰ）層のエンティティ（ＰＤＣＰエンティティとも称される）、及びサービスデータアプリケーションプロトコル（ＳＤＡＰ）層のエンティティ（ＳＤＡＰエンティティとも称され、５Ｇ及びその後の世代のネットワークで確立される）を含む、上位層（Ｌ２層及びＬ３層、つまり上位層）の１つ又は複数のエンティティとを含んでもよい。場合によっては、ＰＨＹ、ＭＡＣ、ＲＬＣ、ＰＤＣＰ、及びＳＤＡＰエンティティは、スタック構造になっている。

【0032】

図１Ｃは、本開示のいくつかの実施形態にかかる装置においてＣＰプロトコルスタックのために確立されてもよいネットワークプロトコル層エンティティを示す模式図１００Ｃである。図１Ｃに示すように、ＣＰにおいて、端末装置１１０及びネットワーク装置１２０のそれぞれは、Ｌ１層のエンティティ、つまり、ＰＨＹ層のエンティティ（ＰＨＹエンティティとも称される）と、ＭＡＣ層のエンティティ（ＭＡＣエンティティとも称される）、ＲＬＣ層のエンティティ（ＲＬＣエンティティとも称される）、ＰＤＣＰ層のエンティティ（ＰＤＣＰエンティティとも称される）、及び無線リソース制御（ＲＲＣ）層のエンティティ（ＲＲＣエンティティとも称される）を含む、上位層（Ｌ２層及びＬ３層）の１つ又は複数のエンティティを含んでもよい。ＲＲＣ層は、さらにアクセスストラタム（ＡＳ：ａｃｃｅｓｓ ｓｔｒａｔｕｍ）層と称されてもよく、そのために、ＲＲＣエンティティは、さらにＡＳエンティティと称されてもよい。図１Ｃに示すように、端末装置１１０は、さらに、非アクセスストラタム（ＮＡＳ）層のエンティティ（ＮＡＳエンティティとも称される）を含んでもよい。ネットワーク側のＮＡＳ層は、ネットワーク装置内ではなく、コアネットワーク（ＣＮ：ｃｏｒｅ ｎｅｔｗｏｒｋ、図示せず）内に配置される。いくつかのケースにおいては、これらのエンティティは、スタック構造になる。

【0033】

一般的には、通信チャネルは、論理チャネルと、送信チャネルと、物理チャネルとに分けられる。物理チャネルは、ＰＨＹ層が実際に情報を送信するチャネルである。例えば、物理チャネルは、物理アップリンク制御チャネル（ＰＵＣＣＨ：ｐｈｙｓｉｃａｌ ｕｐｌｉｎｋ ｃｏｎｔｒｏｌ ｃｈａｎｎｅｌ）と、物理アップリンク共有チャネル（ＰＵＳＣＨ：ｐｈｙｓｉｃａｌ ｕｐｌｉｎｋ ｓｈａｒｅｄ ｃｈａｎｎｅｌ）と、物理ランダムアクセスチャネル（ＰＲＡＣＨ：ｐｈｙｓｉｃａｌ ｒａｎｄｏｍ－ａｃｃｅｓｓ ｃｈａｎｎｅｌ）と、物理ダウンリンク制御チャネル（ＰＤＣＣＨ：ｐｈｙｓｉｃａｌ ｄｏｗｎｌｉｎｋ ｃｏｎｔｒｏｌ ｃｈａｎｎｅｌ）と、物理ダウンリンク共有チャネル（ＰＤＳＣＨ：ｐｈｙｓｉｃａｌ ｄｏｗｎｌｉｎｋ ｓｈａｒｅｄ ｃｈａｎｎｅｌ）と、物理ブロードキャストチャネル（ＰＢＣＨ：ｐｈｙｓｉｃａｌ ｂｒｏａｄｃａｓｔ ｃｈａｎｎｅｌ）とを含んでもよい。

【0034】

送信チャネルは、ＰＨＹ層とＭＡＣ層との間のチャネルである。例えば、送信チャネルは、ブロードキャストチャネル（ＢＣＨ：ｂｒｏａｄｃａｓｔ ｃｈａｎｎｅｌ）と、ダウンリンク共有チャネル（ＤＬ－ＳＣＨ：ｄｏｗｎｌｉｎｋ ｓｈａｒｅｄ ｃｈａｎｎｅｌ）と、ページングチャネル（ＰＣＨ：ｐａｇｉｎｇ ｃｈａｎｎｅｌ）と、アップリンク共有チャネル（ＵＬ－ＳＣＨ：ｕｐｌｉｎｋ ｓｈａｒｅｄ ｃｈａｎｎｅｌ）と、ランダムアクセスチャネル（ＲＡＣＨ）とを含んでもよい。

【0035】

論理チャネルは、ＭＡＣ層とＲＬＣ層との間のチャネルである。例えば、論理チャネルは、専用制御チャネル（ＤＣＣＨ：ｄｅｄｉｃａｔｅｄ ｃｏｎｔｒｏｌ ｃｈａｎｎｅｌ）と、共通制御チャネル（ＣＣＣＨ：ｃｏｍｍｏｎ ｃｏｎｔｒｏｌ ｃｈａｎｎｅｌ）と、ページング制御チャネル（ＰＣＣＨ：ｐａｇｉｎｇ ｃｏｎｔｒｏｌ ｃｈａｎｎｅｌ）と、ブロードキャスト制御チャネル（ＢＣＣＨ：ｂｒｏａｄｃａｓｔ ｃｏｎｔｒｏｌ ｃｈａｎｎｅｌ）と、専用トラフィックチャネル（ＤＴＣＨ：ｄｅｄｉｃａｔｅｄ ｔｒａｆｆｉｃ ｃｈａｎｎｅｌ）とを含んでもよい。

【0036】

一般的には、ＲＲＣ層とＰＤＣＰ層との間、又はＳＤＡＰ層とＰＤＣＰ層との間のチャネルは、無線ベアラと称される。端末装置１１０は、データプレーンデータを運ぶための少なくとも１つのＤＲＢと、制御プレーンデータを運搬するための少なくとも１つのＳＲＢとを有するように設定されてもよい。本開示の背景では、ＤＲＢは、非アクティブ状態における送信をサポートする（すなわち、ＳＤＴをサポートする）ように設定されてもよい。もちろん、ＤＲＢは、非アクティブ状態における送信をサポートしないように設定されてもよい。ＳＲＢは、非アクティブ状態における送信をサポートするように設定されてもよい。もちろん、ＳＲＢは、非アクティブ状態における送信をサポートしないように設定されてもよい。

【0037】

ＲＲＣ層においては、ＳＲＢ０、ＳＲＢ１及びＳＲＢ２の３種類のＳＲＢが定義されている。ＳＲＢ０は、ＲＲＣ接続の確立又は再確立にＣＣＣＨを使用する。ＳＲＢ１は、ＤＣＣＨを使用し、ＲＲＣ接続が確立されたときに確立される。ＳＲＢ２は、ＤＣＣＨを使用し、ＲＲＣ再設定中及び最初のセキュリティアクティブ化の後に確立される。

【0038】

上述したように、３ＧＰＰリリース１７では、非アクティブ状態におけるスモールデータ送信（ＳＤＴ）が承認されている。少量且つ頻繁でないデータ交換を行うさまざまなアプリケーションが存在する。例えば、モバイル装置のいくつかのアプリケーションでは、ＳＤＴは、インスタントメッセージ（ＩＭ）サービスからのトラフィック、例えば、ＩＭ又は電子メールクライアント及び他のサービスからのハートビート又はキープアライブトラフィック、様々なアプリケーションにおけるプッシュ通知、ウェアラブル装置からのトラフィック（例えば、周期的な位置情報を含む）などを含んでもよい。非モバイル装置のいくつかのアプリケーションでは、ＳＤＴは、センサデータ（例えば、ＩｏＴネットワーク内で定期的に又はイベントトリガ方式で伝送される温度、圧力測定値）、スマートメーターから送信される計測及び警報情報などを含んでもよい。

【0039】

本開示の背景において、非アクティブ状態にある端末装置１１０は、ネットワーク装置１２０と通信してもよい。いくつかの実施形態において、例えば、端末装置１１０は、ｓｕｓｐｅｎｄＣｏｎｆｉｇを有するＲＲＣ解放を受信すると、非アクティブ状態に入ってもよい。

【0040】

いくつかのシナリオにおいて、送信すべき非アクティブ状態における送信をサポートする無線ベアラからの小量で頻繁ではないデータトラフィックを端末装置１１０が有するときに、端末装置１１０は、ＳＤＴプロシージャを開始してもよい。１つの無線ベアラが非アクティブ状態における送信をサポートするか否かは、ネットワーク装置１２０又は他のネットワーク装置により設定される。

【0041】

図２Ａは、本開示のいくつかの実施形態を実施可能な１回限りのＳＤＴプロシージャを示す模式図である。図２Ａに示すプロシージャは、最初のデータ送信フェーズのみを含む。図２Ａに示すように、非アクティブ状態にある端末装置１１０は、ＲＲＣ再開要求メッセージをデータトラフィックに関連付けられるＵＬデータ（すなわち、アップリンクデータ、例えば、ＳＤＴを有するように設定されたＳＲＢ又はＤＲＢを使用して送信されるデータ）とともにネットワーク装置１２０に送信してもよい（２０１）。例えば、端末装置１１０は、２ステップＲＡＣＨプロシージャのＭｓｇ Ａ又は４ステップＲＡＣＨプロシージャのＭｓｇ３内で、ＲＲＣ再開要求メッセージをＵＬデータとともに送信してもよい。もちろん、端末装置１１０は、さらに、設定された許可（ＣＧ）リソースにおいてＲＲＣ再開要求メッセージをＵＬデータとともに送信してもよい。ＲＲＣ再開要求メッセージは、回復ＭＡＣ－Ｉを含んでもよい。

【0042】

ＲＲＣ再開要求メッセージ及びＵＬデータを受信すると、ネットワーク装置１２０は、ＲＲＣ解放メッセージをＵＬデータに対応するＤＬデータとともに端末装置１１０に送信してもよい（２０２）。例えば、ネットワーク装置１２０は、２ステップＲＡＣＨプロシージャのＭｓｇ Ｂ又は４ステップＲＡＣＨプロシージャのＭｓｇ４内で、ＤＬデータとともにＲＲＣ解放メッセージを送信してもよい。また、ネットワーク装置１２０は、ＣＧリソースでの送信の応答として、ＤＬデータとともにＲＲＣ解放メッセージを送信してもよい。そして、ＳＤＴプロシージャ２００Ａが終了する。

【0043】

図２Ｂは、本開示のいくつかの実施形態を実施可能な、最初のデータ送信フェーズとデータ後続のデータ送信フェーズとを含むＳＤＴプロシージャ２００Ｂを示す模式図である。図２に示すように、非アクティブ状態にある端末装置１１０は、ＲＲＣ再開要求メッセージをＵＬデータ及びバッファ状態報告（ＢＳＲ：ｂｕｆｆｅｒ ｓｔａｔｕｓ ｒｅｐｏｒｔ）とともにネットワーク装置１２０に送信してもよい（２１１）。例えば、端末装置１１０は、２ステップＲＡＣＨプロシージャのＭｓｇ Ａ又は４ステップＲＡＣＨプロシージャのＭｓｇ３内で、ＵＬデータ及びＢＳＲとともにＲＲＣ再開要求メッセージを送信してもよい。もちろん、端末装置１１０は、さらに、設定された許可（ＣＧ）リソースにおいて、ＵＬデータとともにＲＲＣ再開要求メッセージを送信してもよい。ＲＲＣ再開要求メッセージは、回復ＭＡＣ－Ｉを含んでもよい。

【0044】

ＲＲＣ再開要求メッセージをＵＬデータ及びＢＳＲとともに受信すると、ネットワーク装置１２０は、端末装置１１０に後続のデータ送信の指示を送信してもよい（２１２）。例えば、ネットワーク装置１２０は、後続のデータ送信を示す明示的なＲＲＣメッセージを送信してもよい。別の例として、ネットワーク装置１２０は、別の送信についてのアップリンク許可（ＵＬ許可）を送信して、後続のデータ送信を暗黙的に示してもよい。いくつかの実施形態において、ネットワーク装置１２０は、また、指示とともにＤＬデータを端末装置１１０に送信してもよい。この時点で、最初のデータ送信が完了する。

【0045】

この指示に基づいて、端末装置１１０は、例えば、動的な許可又は設定された許可に基づいて、別のＵＬデータ及びＢＳＲをネットワーク装置１２０に送信してもよい（２１３）。そして、ネットワーク装置１２０は、動的な許可についてのＵＬ許可を端末装置１１０に送信してもよい（２１４）。いくつかの実施形態において、ネットワーク装置１２０は、ＵＬ許可とともにＤＬデータを端末装置１１０に送信してもよい。

【0046】

ネットワーク装置１２０からのＵＬ許可に基づいて、端末装置１１０は、残りのＵＬデータをネットワーク装置１２０に送信してもよい（２１５）。したがって、ネットワーク装置１２０は、ＲＲＣ解放メッセージを端末装置１１０に送信してもよい（２１６）。この時点で、後続のデータ送信が完了する。すなわち、ＳＤＴプロシージャ２００Ｂが終了する。ＳＤＴプロシージャ２００Ｂは、後続のデータ送信におけるより多くの又はより少ないステップを含んでもよく、本開示の保護範囲はこの点において限定されないことを理解すべきである。

【0047】

以上の部分では、図２Ａと図２Ｂとを参照して可能なＳＤＴプロシージャを例示した。以下の部分では、ＳＤＴに関連するいくつかの具体的なシナリオを紹介する。

【0048】

本開示全体を通して、用語「ＳＤＴ中」は、「ＳＤＴのためのタイマが実行している」と互換的に使用されてもよいことを理解すべきである。例えば、タイマは、ＳＤＴの開始時に起動されてもよい。

【0049】

しかしながら、本開示の発明者らは、ＳＤＴのためのより堅牢で安全な解決策を提供するために、解決すべきいくつかの問題（例えば、ＳＤＴのためのＲＬＣ再確立の処理、ＳＤＴ中のオンデマンドＳＩ／ＰＩ、ＳＤＴ中断、ｒｅｓｕｍｅＭＡＣ－Ｉ計算に関連するセキュリティ問題、パワーヘッドルーム報告（ＰＨＲ：ｐｏｗｅｒ ｈｅａｄｒｏｏｍ ｒｅｐｏｒｔ）など）が、特定のシナリオにおいて依然として存在することに気づいた。これらの問題又は他の潜在的なシナリオにおける問題を解決するために、本開示の実施形態は、ＳＤＴプロシージャ中の問題を処理するための通信解決策を提供する。

【0050】

なお、各シナリオについて発見された上記の問題の詳細と、それらに対応する解決策とについては、それぞれ以下の部分で紹介する。以下、添付図面を参照して、本開示の原理及び実施態様について詳細に説明する。

【0051】

ＳＤＴのためのＲＬＣ再確立処理の実現例
上位層（例えば、ＲＲＣ）がＲＬＣエンティティ再確立を要求する場合、端末装置１１０は、すべてのＲＬＣサービスデータユニット（ＳＤＵ：ｓｅｒｖｉｃｅ ｄａｔａ ｕｎｉｔ）と、ＲＬＣ ＳＤＵセグメントと、ＲＬＣプロトコルデータユニット（ＰＤＵ：ｐｒｏｔｏｃｏｌ ｄａｔａ ｕｎｉｔ）と（もしあれば）を廃棄してもよい。また、ＲＬＣエンティティの再確立中、すべてのタイマが停止し、リセットされる。また、このプロセスでは、すべての状態変数がそれらの初期値にリセットされる。

【0052】

一例において、ＲＬＣエンティティ再確立の目的の１つは、バッファされたデータ（例えば、端末装置１１０が前のセルに位置していたときに送信されると想定されるデータ）が古い鍵を使用して暗号化されているため、バッファされたデータが後続のデータ送信において送信されることを回避するために使用されることである。端末装置１１０が新しいセルに移動するときに、バッファされたデータが端末装置１１０により送信される場合、エラーが発生することになる。したがって、バッファされたデータは、破棄されるべきであり、送信されることはない。

【0053】

ｒｅｅｓｔａｂｌｉｓｈＲＬＣは、ＲＬＣは再確立される必要があることを示すために使用される。ネットワーク装置１２０は、少なくとも該ＲＬＣエンティティに関連付けられる無線ベアラに使用されるセキュリティ鍵が変わるたびに、これをｔｒｕｅにセットする。ＳＲＢ２及びＤＲＢについても、ＲＲＣ接続の再開中又は再確立後の最初の再設定時にｔｒｕｅにセットされる。

【0054】

しかしながら、本開示の発明者らは、ネットワーク装置１２０が端末装置１１０にＲＬＣ再確立（すなわち、ｒｅｅｓｔａｂｌｉｓｈＲＬＣ）を設定する場合にのみＲＬＣエンティティ再確立が実行されることに気づいた。しかしながら、ＳＤＴの場合、端末装置１１０は、ＲＲＣ再開要求メッセージを図２Ａ及び図２Ｂを参照して上述したように直接送信されるアップリンクデータ（例えば、ＳＤＴを有するように設定されたＳＲＢ又はＤＲＢを使用して送信されるデータ）とともに送信することになり、この時点では、端末装置１１０は、ネットワーク装置１２０から設定（例えば、ｒｅｅｓｔａｂｌｉｓｈＲＬＣ）をまだ受信していない。言い換えれば、ネットワーク装置１２０は、ＳＤＴの初期化時に設定（例えば、ｒｅｅｓｔａｂｌｉｓｈＲＬＣ）することが不可能である。したがって、ＳＤＴのためにＲＬＣ再確立が実行されない場合、上述したような問題が発生する（例えば、バッファされた古いデータが送信されることになるが、これは望ましくないことである）。そのため、ＲＬＣエンティティ再確立は、ＳＤＴの開始前又は開始時に実行される必要がある。

【0055】

これに鑑みて、本願の実施形態は、ＳＤＴのためのＲＬＣエンティティ再確立を処理する解決策を提供する。この解決策において、端末装置１１０は、まず、非アクティブ状態におけるデータ送信を有するように設定された無線ベアラについてのＲＬＣエンティティ再確立が実行されるか否かを決定する。そして、ＲＬＣエンティティ再確立が実行されると決定した場合、端末装置１１０は、ＲＬＣエンティティを再確立する。その後、端末装置１１０は、ネットワーク装置１２０に、無線ベアラにて非アクティブ状態においてアップリンクデータを送信する。こうして、ＳＤＴを有するように設定された無線ベアラのためにＲＬＣエンティティ再確立を処理することは、該ＳＤＴのために該ＲＬＣエンティティ再確立を実行する必要があると端末装置１１０が決定した場合に可能であるため、ＳＤＴプロシージャのパフォーマンスが向上する。

【0056】

ここで、図３を参照すると、図３は、本開示のいくつかの実施形態にかかるＳＤＴプロシージャのためのシグナリングフロー３００を示す。説明のために、図１Ａを参照しつつシグナリングフロー３００を説明する。シグナリングフロー３００には、図１Ａに示されるような端末装置１１０と、ネットワーク装置１２０とが関与する。

【0057】

図３に示すように、端末装置１１０は、無線ベアラのためのＲＬＣエンティティ再確立が実行されるか否かを決定する（３１０）。無線ベアラは、非アクティブ状態におけるアップリンクデータの送信を有するように設定される（すなわち、ＳＤＴを有するように設定された無線ベアラ）。

【0058】

いくつかの実施形態において、端末装置１１０は、アップリンクデータの送信が非アクティブ状態において実行されるか否かを決定してもよい。アップリンクデータの送信が非アクティブ状態において実行される場合、端末装置１１０は、ＲＬＣエンティティ再確立が実行されるか否かを決定してもよい。こうして、ＳＤＴを有するように設定された無線ベアラについて、ＲＬＣ再確立は、端末装置１１０において暗黙的に、すなわち、ネットワークへのＲＬＣ再確立の明示的な指示なしに実行されることができる。

【0059】

いくつかの他の実施形態において、ＲＲＣ解放メッセージがネットワーク装置１２０から受信され、該ＲＲＣ解放メッセージが、非アクティブ状態におけるアップリンクデータ送信を有するように設定された無線ベアラについてのＲＬＣエンティティ再確立に関する指示を含む場合、端末装置１１０は、ＲＬＣエンティティ再確立が実行されると決定してもよい。こうして、ネットワーク装置１２０は、ｓｕｓｐｅｎｄＣｏｎｆｉｇを使用してＲＲＣＲｅｌｅａｓｅ内でＳＤＴ無線ベアラについてｒｅｅｓｔａｂｌｉｓｈＲＬＣを設定してもよく、これにより、ＳＤＴを有するように設定された無線ベアラについてＲＬＣエンティティ再確立を処理することができる。

【0060】

端末装置１１０は、また、ＲＬＣエンティティ再確立が別の方法で実行されることを決定してもよく、本開示の範囲がこの点において限定されないことを理解すべきである。

【0061】

ＲＬＣエンティティ再確立が実行されると決定した後に、端末装置１１０は、ＲＬＣエンティティを再確立してもよい（３２０）。いくつかの実施形態において、端末装置１１０の上位層（例えば、ＰＤＣＰ、ＲＲＣ又はＮＡＳ）がＲＬＣエンティティ再確立を要求するとき、端末装置１１０のＲＬＣ層は、すべてのＲＬＣ ＳＤＵ、ＲＬＣ ＳＤＵセグメント及びＲＬＣプロトコルデータユニット（ＰＤＵ）（もしあれば）を破棄してもよい。いくつかの他の実施形態において、ＲＬＣエンティティ再確立中に、端末装置１１０は、すべてのタイマを停止し、リセットしてもよい。代替として、端末装置１１０は、すべての状態変数をそれらの初期値にリセットしてもよい。端末装置１１０のＲＬＣレイヤは、ＲＬＣエンティティを再確立するために他の動作を実行してもよく、本開示の範囲は、この点において限定されない。

【0062】

ＲＬＣエンティティが再確立されると、端末装置１１０は、ネットワーク装置１２０に、無線ベアラにて非アクティブ状態においてアップリンクデータを送信する（３３０）。いくつかの実施形態において、端末装置１１０は、図１及び図２を参照して紹介したＲＡに基づく又はＣＧに基づくＳＤＴを使用して、非アクティブ状態においてアップリンクデータを送信してもよい。

【0063】

いくつかの例において、ＣＧに基づくＳＤＴ基準が満たされている場合、端末装置１１０は、ＣＧに基づくＳＤＴを選択してもよい。そうでなければ、ＲＡに基づくＳＤＴ基準が満たされている場合、端末装置１１０は、ＲＡーＳＤＴを選択してもよい。

【0064】

このような例において、以下の条件のうちの１つ又は複数が満たされている場合、ＣＧ－ＳＤＴ基準が満たされているとみなしてもよい。１）利用可能なデータ量≦データ量閾値、２）参照信号受信電力（ＲＳＲＰ：ｒｅｆｅｒｅｎｃｅ ｓｉｇｎａｌ ｒｅｃｅｉｖｅｄ ｐｏｗｅｒ）が設定閾値以上、又は３）ＣＧに基づくＳＤＴリソースが選択されたＵＬキャリアにおいて設定され、且つ、有効である。一方、以下の条件のうちの１つ又は複数が満たされている場合、ＲＡに基づくＳＤＴ基準が満たされているとみなしてもよい。１）利用可能データ量≦データ量閾値、２）ＲＳＲＰが設定閾値以上、３）選択されたＵＬキャリア上に４ステップＲＡに基づくＳＤＴリソースが設定され、且つ、４ステップＲＡに基づくＳＤＴを選択する基準が満たされている、又は選択されたＵＬキャリア上に２ステップＲＡに基づくＳＤＴリソースが設定され、且つ、２ステップＲＡに基づくＳＤＴを選択する基準が満たされている。

【0065】

例えば、上述の解決策により、好ましくない、バッファされた古いデータは、ＳＤＴ中に送信されることはない。より堅牢なＳＤＴ解決策を提供することができる。

【0066】

従来、ネットワーク装置１２０は、ＳＤＴ中にＲＲＣ再開メッセージを端末装置１１０に送信して、端末装置１１０に非ＳＤＴモードへ移行するように示してもよい。従来の解決策によれば、ネットワーク装置１２０は、ＲＲＣ接続を再開するとき、ＲＬＣ再確立を示してもよい。しかしながら、ＳＤＴ無線ベアラについて、ネットワーク装置１２０がＲＬＣ再確立を示す場合、バッファされたＲＬＣパケットはクリーンアップされ、これによりパケット損失が引き起こされる。

【0067】

上記の問題を解決するために、いくつかの実施形態において、アップリンクデータと無線リソース制御（ＲＲＣ）再開要求メッセージを非アクティブ状態にある端末装置１１０から受信したとき、ネットワーク装置１２０は、端末装置１１０に、ＲＲＣ再開メッセージを送信してもよい。ＲＲＣ再開メッセージは、非アクティブ状態におけるデータ送信を有するように設定されていない無線ベアラについてのＲＬＣエンティティ再確立のための指示を含んでもよい。

【0068】

ネットワーク装置１２０からＲＲＣ再開メッセージを受信すると、端末装置１１０は、接続状態においてデータを送信するためにＲＬＣエンティティを再確立してもよい。言い換えれば、ネットワーク装置１２０は、ＳＤＴ中のＲＲＣ再開メッセージ内の非ＳＤＴ無線ベアラについてのみｒｅｅｓｔａｂｌｉｓｈＲＬＣを設定する。結果として、ＳＤＴ無線ベアラについて、バッファされたＲＬＣパケットはクリーンアップされない。

【0069】

したがって、例えば、変更された３ＧＰＰ仕様の関連内容は「ｒｅｅｓｔａｂｌｉｓｈＲＬＣは、ＲＬＣが再確立されるべきであることを示す」になる。そして、ネットワーク装置１２０は、少なくとも該ＲＬＣエンティティに関連付けられる無線ベアラに使用されるセキュリティ鍵が変わるたびに、これをｔｒｕｅにセットしてもよい。ＳＲＢ２及びＤＲＢについても、ＲＲＣ接続の再開中又は再確立後の最初の再設定時にｔｒｕｅにセットされる。これは、ＳＤＴ中にＲＲＣ接続を再開する場合、ＳＤＴをサポートしない無線ベアラにのみ示される。

【0070】

この解決策（すなわち、ネットワーク装置１２０が、端末装置１１０に、非アクティブ状態におけるデータ送信を有するように設定されていない無線ベアラについてのＲＬＣエンティティ再確立のための指示を含むＲＲＣ再開メッセージを送信する）は、上述したＳＤＴのためのＲＬＣエンティティ再確立を処理する解決策と独立して機能してもよく、共に機能してもよく、本開示の範囲がこの点において限定されないことを理解すべきである。

【0071】

オンデマンドシステム／位置情報要求の実現例
システム情報（ＳＩ）は、最小ＳＩと他のＳＩとを含む。最小ＳＩは、最初のアクセスに必要な基本情報と、任意の他のＳＩを取得するための情報とを含む。最小ＳＩは、マスタ情報ブロック（ＭＩＢ：ｍａｓｔｅｒ ｉｎｆｏｒｍａｔｉｏｎ ｂｌｏｃｋ）とシステム情報ブロック１（ＳＩＢ１：ｓｙｓｔｅｍ ｉｎｆｏｒｍａｔｉｏｎ ｂｌｏｃｋ １）とを含む。

【0072】

いくつかの例において、他のＳＩは、最小ＳＩ内でブロードキャストされないすべてのＳＩＢをカバーする。このような例において、例えば、これらのＳＩＢは、ＤＬ－ＳＣＨにおいて周期的にブロードキャストされてもよい。別の例において、ＳＩＢは、また、ＤＬ－ＳＣＨにおいて必要に応じて（すなわち、ＲＲＣ＿ＩＤＬＥ、ＲＲＣ＿ＩＮＡＣＴＩＶＥ、又はＲＲＣ＿ＣＯＮＮＥＣＴＥＤにおいて端末装置１１０からの要求に応じて）ブロードキャストされてもよい。代替として、これらのＳＩＢは、ＤＬ－ＳＣＨにおいて専用の方法でＲＲＣ＿ＣＯＮＮＥＣＴＥＤにあるＵＥへ送信されてもよい（すなわち、要求されると、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤにあるＵＥからネットワークにより設定されている場合、又は設定された共通探索空間を有しないアクティブなＢＷＰをＵＥが有する場合）。

【0073】

さらに、ＳＩのほかにも、いくつかの例において、端末装置１１０は、位置情報（ＰＩ）を取得する必要もあるかもしれない。このような例において、ＰＩは、端末装置１１０により要求されたときにネットワーク装置１２０によりブロードキャストされてもよい（すなわち、必要に応じてブロードキャストされてもよい）。したがって、端末装置１１０の位置は、ネットワーク装置１２０からブロードキャストされるＰＩに含まれるパラメータを介して取得されてもよい。

【0074】

しかしながら、本開示の発明者らは、ＳＤＴ（すなわち、非アクティブ状態にある端末装置１１０によるアップリンク送信）中に、端末装置１１０がオンデマンドＳＩ／ＰＩを要求する必要があるかもしれないことに気づいた。したがって、一態様において、オンデマンドＳＩ／ＰＩについての要求は、最初のアップリンクＳＤＴ送信において、非アクティブ状態においてアップリンクデータ送信とともに送信されてもよい。すなわち、２つのＣＣＣＨメッセージ（ＲＲＣ再開要求メッセージとＲＲＣ＿Ｓｙｓｔｅｍ＿Ｉｎｆｏ＿Ｒｅｑｕｅｓｔメッセージは、両方ともＣＣＣＨメッセージを介して送信されるため）は、同時に送信される必要がある。しかしながら、従来の解決策では、ＵＬ許可のサイズは、少なくとも１つのＣＣＣＨメッセージのために設計され、ＣＣＣＨメッセージのためのＲＬＣのモードは、トランスペアレントモード（ＴＭ：ｔｒａｎｓｐａｒｅｎｔ ｍｏｄｅ）であり、これは、ＣＣＣＨメッセージを送信時にセグメント化すべきではないことを意味する。すなわち、ＵＬ許可のサイズが２つのＣＣＣＨメッセージを送信するのに不十分である場合、第２のＣＣＣＨメッセージを分離方式で送信することはできない（すなわち、ＣＣＣＨメッセージの一部は、該ＵＬ許可内で送信され、ＣＣＣＨメッセージの他の部分は、次のＵＬ許可内で送信される）。したがって、２つのＣＣＣＨメッセージがＵＬ許可内で送信され、該ＵＬ許可のサイズが２つのＣＣＣＨメッセージを保持するのに小さすぎる場合、２つのＣＣＣＨメッセージのうちの２番目のメッセージの送信の失敗を引き起こすかもしれない。

【0075】

別の態様において、本発明者らは、さらに、最初のアップリンクＳＤＴ送信の後に、非アクティブ状態における後続のアップリンクデータ送信が存在する場合、端末装置１１０が非アクティブ状態において送信を継続して実行してもよいことに気づいた。このとき、端末装置１１０がオンデマンドＳＩ／ＰＩを要求する必要がある場合、後続のデータ送信フェーズにおいて、該後続のＳＤＴ送信とともにオンデマンドＳＩ／ＰＩについての要求をどのように送信するかについての解決策はない。言い換えれば、非アクティブ状態にある端末装置１１０について、後続のアップリンクデータ送信フェーズ中にＣＣＣＨメッセージをどのように送信するかについての解決策はない。したがって、例えば、上述のようにＣＣＣＨメッセージをセグメント化することができないことを考慮すると、これは、後続のアップリンクデータ送信についてのＵＬ許可のサイズがＣＣＣＨメッセージについて不十分である場合に問題となり得る。

【0076】

いくつかの他の態様において、オンデマンドＳＩ／ＰＩは、また、ＲＡＣＨプロシージャを介して取得されてもよく、非アクティブ状態におけるアップリンク送信（すなわち、ＳＤＴ）についての最初のデータ送信フェーズは、上述したように、ＲＡに基づくＳＤＴを介して実行されることができる。結果として、２つの並行のＲＡＣＨプロシージャ（すなわち、一方は、オンデマンドＳＩ／ＰＩ用であり、他方は、非アクティブ状態におけるアップリンク送信についての最初のデータ送信フェーズ用である）がトリガされる可能性があるが、これは許可されないことである。しかしながら、端末装置１１０のＭＡＣエンティティは、１つのＲＡＣＨプロシージャの実行しか許可しないため、結果として、２つの並行のＲＡＣＨプロシージャをトリガすることも問題となる。

【0077】

要するに、上記のような問題のあるシナリオにどのように対処するかについての解決策はない。言い換えれば、ＳＤＴ中にオンデマンドＳＩ／ＰＩ情報要求がトリガされるシナリオについての解決策が必要とされる。

【0078】

上記問題のうちの少なくとも１つを解決するために、ＳＤＴの解決策が提供される。この解決策では、非アクティブ状態においてアップリンクデータ送信を行う端末装置１１０（すなわち、ＳＤＴを行う端末装置１１０）は、まず、オンデマンド情報が利用可能か否かを決定する。オンデマンド情報が利用不可能であると決定した場合、端末装置１１０は、以下の動作のうちの少なくとも１つの動作を実行する。まず、端末装置１１０は、オンデマンド情報についての要求のネットワーク装置１２０への送信をトリガする。代替として、端末装置１１０は、ネットワーク装置１２０へのオンデマンド情報についての要求の送信を回避する。言い換えれば、端末装置１１０は、オンデマンド情報についての要求をネットワーク装置１２０に送信しない。

【0079】

したがって、端末装置１１０は、ＳＤＴ中にオンデマンド情報（例えば、オンデマンドＳＩ／ＰＩ）についての要求を許可するか、又はＳＤＴ中にオンデマンド情報要求が送信されるのを回避することができる。こうして、ＳＤＴ中にトリガされたオンデマンド情報要求を適切に処理することができるため（例えば、既存のＳＤＴを中断することなく）、ＳＤＴ解決策の堅牢性が向上する。

【0080】

ここで、図４を参照し、図４は本開示のいくつかの実施形態にかかるＳＤＴプロシージャのためのシグナリングフロー４００を示す。説明のために、図１Ａを参照しつつシグナリングフロー４００を説明する。シグナリングフロー３００には、図１Ａに示されるような端末装置１１０と、ネットワーク装置１２０とが関与する。

【0081】

図４に示すように、非アクティブ状態においてアップリンクデータの送信を実行する端末装置１１０は、オンデマンド情報が利用可能か否かを決定する（４１０）。一例において、オンデマンド情報はオンデマンドＳＩを含んでもよい。別の例において、オンデマンド情報は、また、オンデマンドＰＩを含んでもよい。オンデマンド情報は、他のタイプのオンデマンド情報を含んでもよく、本開示の範囲がこの点において限定されないことを理解すべきである。

【0082】

いくつかの実施形態において、端末装置１１０は、オンデマンド情報が利用可能か否かを決定してもよい。ＮＯの場合、端末装置１１０は、非アクティブ状態におけるアップリンクデータ送信（すなわち、ＳＤＴ）を実行しているか否かを決定してもよい。ＹＥＳの場合、端末装置１１０は、オンデマンド情報についての要求のネットワーク装置１２０への送信をトリガするか、又はネットワーク装置１２０へのオンデマンド情報についての要求の送信を回避してもよい（すなわち送信しない）。

【0083】

いくつかの実施形態において、オンデマンド情報の有効なバージョンが存在せず、オンデマンド情報がネットワーク装置１２０によりブロードキャストされていないと決定された場合、端末装置１１０は、オンデマンド情報が利用不可能であると決定してもよい。このような実施形態において、例えば、オンデマンド情報の有効なバージョンが存在しないことは、端末装置１１０が有効なバージョンを記憶していないことであるかもしれない。別の例において、端末装置がオンデマンド情報のどんなバージョンも一切記憶していないことであるかもしれない。

【0084】

いくつかの他の実施形態において、オンデマンド情報についての要求がＲＲＣ層において端末装置１１０の上位層から受信され、該オンデマンド情報はネットワーク装置１２０によりブロードキャストされていないと決定された場合、端末装置１１０は、該オンデマンド情報が利用不可能であると決定してもよい。端末装置１１０は、オンデマンド情報が利用可能か否かを決定してもよく、本開示の範囲は、この点で限定されない。

【0085】

そして、オンデマンド情報が利用不可能であると決定した場合、端末装置１１０は、オンデマンド情報についての要求のネットワーク装置１２０への送信をトリガすることを決定する（４２０）。代替として、端末装置１１０は、ネットワーク装置１２０へのオンデマンド情報についての要求の送信を回避する。言い換えれば、端末装置１１０は、ＳＤＴ中にオンデマンドＳＩ又はオンデマンドＰＩを要求しない。このような場合、端末装置１１０は、要求をＳＤＴプロシージャの後に延期させてもよい。いくつかの他の実施形態において、オンデマンド情報が利用不可能であると決定され、且つ、端末装置１１０がＳＤＴを実行していない（すなわち、ＳＤＴのためのタイマが実行していない）場合、端末装置１１０はオンデマンドＳＩ／ＰＩを要求してもよい。

【0086】

端末装置１１０は、様々な方法でネットワーク装置１２０へのオンデマンド情報についての要求の送信をトリガしてもよい。以下の部分では、要求の送信をトリガする方法について詳しく紹介する。しかしながら、要求の送信をトリガする他の方法もあり、本開示の範囲がこの点において限定されないことを理解すべきである。

【0087】

いくつかの実施形態において、端末装置１１０は、非アクティブ状態からアイドル状態に入り、その後、オンデマンド情報についての要求をネットワーク装置１２０に送信してもよい。このような実施形態において、一例において、端末装置１１０の下位層（例えば、ＭＡＣ層）は、ＴＳ ３８．３２１に従って、端末装置１１０がセル内で動作するのに必要とするＳＩメッセージに対応するｓｉ－ＲｅｑｕｅｓｔＣｏｎｆｉｇ内のＰＲＡＣＨプリアンブル及びＰＲＡＣＨリソースを使用して、通常のアップリンクにおいてランダムアクセス（ＲＡ）プロシージャを開始するようにトリガされ、また、この場合、ｓｉ－ＢｒｏａｄｃａｓｔＳｔａｔｕｓは、ｎｏｔＢｒｏａｄｃａｓｔｉｎｇにセットされる。したがって、オンデマンド情報は、必要に応じてネットワーク装置１２０から取得されてもよい。

【0088】

別の例において、端末装置１１０は、既存の３ＧＰＰ規格に従ってＲＲＣＳｙｓｔｅｍＩｎｆｏＲｅｑｕｅｓｔメッセージ（すなわち、ＣＣＣＨを使用するＳＲＢ０メッセージ）の送信を開始して、ＩＮＡＣＴＩＶＥ状態又はＩＤＬＥ状態にある端末装置１１０のためのオンデマンドＳＩ／ＰＩを要求してもよい。

【0089】

いくつかの他の実施形態において、端末装置１１０は、非アクティブ状態におけるアップリンクデータの送信を中断し、その後、オンデマンド情報についての要求をネットワーク装置１２０に送信してもよい。例えば、端末装置１１０は、本開示の以下の部分で説明される同じ中断プロシージャを使用することにより、非アクティブ状態におけるアップリンクデータの送信を中断してもよい。端末装置１１０は、また、他の中断プロシージャを利用して、非アクティブ状態におけるアップリンクデータの送信を中断してもよく、本開示の範囲は、この点において限定されない。

【0090】

このような実施形態において、一例において、端末装置１１０の下位層（例えば、ＰＨＹ層）は、ＴＳ ３８．３２１に従って、端末装置１１０がセル内で動作するのに必要とするＳＩメッセージに対応するｓｉ－ＲｅｑｕｅｓｔＣｏｎｆｉｇ又はｓｉ－ＲｅｑｕｅｓｔＣｏｎｆｉｇＳＵＬ内のＰＲＡＣＨプリアンブル及びＰＲＡＣＨリソースを使用して、通常のアップリンク又は補助的なアップリンクにおいてＲＡプロシージャを開始するようにトリガされ、また、この場合、ｓｉ－ＢｒｏａｄｃａｓｔＳｔａｔｕｓは、ｎｏｔＢｒｏａｄｃａｓｔｉｎｇにセットされる。したがって、オンデマンド情報は、必要に応じてネットワーク装置１２０から取得されてもよい。

【0091】

別の例において、端末装置１１０は、既存の３ＧＰＰ規格に従ってＲＲＣＳｙｓｔｅｍＩｎｆｏＲｅｑｕｅｓｔメッセージ（すなわち、ＣＣＣＨを使用するＳＲＢ０メッセージ）の送信を開始して、ＩＮＡＣＴＩＶＥ状態又はＩＤＬＥ状態にある端末装置１１０のためのオンデマンドＳＩ／ＰＩを要求してもよい。

【0092】

代替として、端末装置１１０は、ＳＲＢ１メッセージ又はＳＲＢ２メッセージを送信することにより、オンデマンドＳＩ／ＰＩについての要求の送信をトリガしてもよい。したがって、ＳＲＢ１及びＳＲＢ２メッセージがＲＬＣ確認応答モード（ＡＭ）において送信されるので、このようなモードについて、セグメント化が許可される。結果として、ＤＣＣＨを使用してオンデマンドＳＩ／ＰＩについての要求が送信されるので、ＵＬ許可がＣＣＣＨメッセージを収容するのに十分に大きいか否かの問題はない。

【0093】

このような実施形態において、例えば、既存のＳＲＢ１又はＳＲＢ２メッセージが使用されてもよい。この例において、オンデマンドＳＩ／ＰＩを送信するために、既存のＤｅｄｉｃａｔｅｄＳＩＢＲｅｑｕｅｓｔメッセージを使用してもよい。より多くのタイプのＳＩＢのために、メッセージの内容は、ＤｅｄｉｃａｔｅｄＳＩＢＲｅｑｕｅｓｔメッセージにより現在サポートされているＳＩＢ１２、ＳＩＢ１３、ＳＩＢ１４以外にも他のＳＩＢ（例えば、ＳＩＢ２～ＳＩＢ１１）を要求するように拡張されてもよい。

【0094】

このような実施形態において、別の例において、新しく設計されたメッセージは、ＳＲＢ１又はＳＲＢ２を使用してオンデマンド情報を送信するために使用されてもよい。具体的には、新しいメッセージの内容は、ＲＲＣＳｙｓｔｅｍＩｎｆｏＲｑｕｅｓｔと同一であってもよく、又は似ていてもよい。

【0095】

１つの例において、新しく設計されたメッセージは、以下の通りであってもよい：
NewMessage ::= SEQUENCE {
criticalExtensions CHOICE {
newMessage RRCSystemInfoRequest-IEs,
criticalExtensionsFuture-r16 CHOICE {
rrcPosSystemInfoRequest-r16
RRC-PosSystemInfoRequest-r16-IEs,
criticalExtensionsFuture SEQUENCE {}
}
}
}
RRCSystemInfoRequest-IEs ::= SEQUENCE {
requested-SI-List BIT STRING (SIZE (maxSI-Message)), --32bits
spare BIT STRING (SIZE (12))
}
RRC-PosSystemInfoRequest-r16-IEs ::= SEQUENCE {
requestedPosSI-List BIT STRING (SIZE (maxSI-Message)), --32bits
spare BIT STRING (SIZE (11))
}

【0096】

ＳＲＢ１及びＳＲＢ２メッセージは、他のフォーマットで設計されてもよく、本開示の範囲がこの点において限定されないことを理解すべきである。

【0097】

いくつかの実施形態において、ＲＡに基づくＳＤＴが使用され、ＲＡプロシージャに基づく要求がトリガされる場合、ＲＡに基づくＳＤＴの最初のＳＤＴフェーズ中にＲＡに基づく要求を実行できないことを考慮して、端末装置１１０は、ＲＡに基づく要求を延期させて、最初のＳＤＴ送信（すなわち、最初のデータ送信フェーズ）が完了した後に実行さいてもよい。代替として、このような場合、端末装置１１０は、また、ＲＡに基づく要求を延期させる代わりに、最初のデータ送信フェーズ中にＳＲＢ０メッセージ（例えば、ＲＲＣＳｙｓｔｅｍＩｎｆｏＲｅｑｕｅｓｔメッセージ）に基づく要求を送信してもよい。

【0098】

上記の解決策により、ＳＤＴ中にオンデマンド情報が必要とされ、且つ、ＲＡプロシージャに基づく要求がトリガされる場合、２つの並行のＲＡＣＨプロシージャがトリガされるシナリオを回避することができる。

【0099】

いくつかの例において、オンデマンドＳＩ／オンデマンドＰＩについてのＲＡプロシージャに基づく要求は、ＳＤＴの後続のデータ送信フェーズ中に実行されてもよい。いくつかの他の例において、ＲＡプロシージャに基づく要求は、ＣＧに基づくＳＤＴ中にオンデマンドＳＩ／オンデマンドＰＩについて実行されてもよい。

【0100】

いくつかの実施形態において、図２Ａ及び図２Ｂを参照して上述したように、非アクティブ状態におけるアップリンクデータの送信のためのフェーズは、場合によっては、最初のデータ送信フェーズと、追加の後続のデータ送信フェーズとを含んでもよい。したがって、このような実施形態において、例えば、端末装置１１０は、オンデマンドＳＩ／ＰＩについての要求がＳＲＢ０メッセージ（例えば、ＲＲＣＳｙｓｔｅｍＩｎｆｏＲｅｑｕｅｓｔメッセージ）とともに送信されてもよく、最初のデータ送信フェーズ中に、ＳＲＢ０メッセージが、媒体アクセス制御プロトコルデータユニット（ＭＡＣ ＰＤＵ：ｍｅｄｉｕｍ ａｃｃｅｓｓ ｃｏｎｔｒｏｌ ｐｒｏｔｏｃｏｌ ｄａｔａ ｕｎｉｔ）内で、ＲＲＣ再開要求メッセージ及び非アクティブ状態におけるアップリンクデータの送信とともに送信されてもよいことを決定してもよい。

【0101】

従来の解決策では、最初のデータ送信フェーズ内のＲＡプロシージャ中に、一時的セル無線ネットワーク一時識別子（ＴＣ－ＲＮＴＩ：ｔｅｍｐｏｒａｒｙ ｃｅｌｌ－ｒａｄｉｏ ｎｅｔｗｏｒｋ ｔｅｍｐｏｒａｒｙ ｉｄｅｎｔｉｆｉｅｒ）が使用される。しかしながら、後続のデータ送信フェーズにおいて、動的許可又は設定された許可についてのアップリンク許可が使用される場合、セル無線ネットワーク一時識別子（Ｃ－ＲＮＴＩ：ｃｅｌｌ－ｒａｄｉｏ ｎｅｔｗｏｒｋ ｔｅｍｐｏｒａｒｙ ｉｄｅｎｔｉｆｉｅｒ）と、設定されたスケジューリング無線ネットワーク一時識別子（ＣＳ－ＲＮＴＩ：ｃｏｎｆｉｇｕｒｅｄ ｓｃｈｅｄｕｌｉｎｇ－ｒａｄｉｏ ｎｅｔｗｏｒｋ ｔｅｍｐｏｒａｒｙ ｉｄｅｎｔｉｆｉｅｒ）とがそれぞれ使用される。しかしながら、従来の解決策では、Ｃ－ＲＮＴＩとＣＳ－ＲＮＴＩとの両方が、ＵＬ ＣＣＣＨメッセージを送信することが許可されない。結果として、ＣＣＣＨをセグメント化することができるとしても、ＣＣＣＨメッセージを後続のデータ送信フェーズにおいて送信する場合、依然として問題となる。すなわち、Ｃ－ＲＮＴＩとＣＳ－ＲＮＴＩとを使用して、ＳＤＴの後続のデータ送信フェーズ中に、オンデマンドＳＩ／ＰＩのためのＵＬ ＣＣＣＨメッセージを送信することが必要である。

【0102】

上述した問題を解決するために、別の例において、端末装置１１０は、Ｃ－ＲＮＴＩ又はＣＳ－ＲＮＴＩを使用してＣＣＣＨにおいて後続のデータ送信フェーズ中にＳＲＢ０メッセージを送信してもよい。例えば、修正された３ＧＰＰ仕様の関連内容は、次の表１のようになる：

【0103】

表１ ＲＮＴＩの用途

【表1】

【0104】

したがって、Ｃ－ＲＮＴＩとＣＳ－ＲＮＴＩとを使用してＵＬ ＣＣＣＨメッセージを送信することにより、ＳＤＴ中にオンデマンドシステム情報要求を開始することができるようにすることが可能である。

【0105】

いくつかの他の実施形態において、端末装置１１０は、オンデマンド情報についての要求がＳＲＢ０メッセージを使用して送信されることを決定してもよい。したがって、アップリンク許可がアップリンクデータを受け入れ、ＳＲＢ０メッセージを追加として受け入れないと決定すると、端末装置１１０は、アイドル状態に入った後に要求を送信してもよい。代替として、端末装置１１０は、非アクティブ状態におけるアップリンクデータの送信を中断した後に要求を送信してもよい。一例において、端末装置１１０は、本開示の以下の部分で説明される同じ中断プロシージャを使用することにより、非アクティブ状態におけるアップリンクデータの送信を中断してもよい。端末装置１１０は、また、他の中断プロシージャを利用して、非アクティブ状態におけるアップリンクデータの送信を中断してもよく、本開示の範囲は、この点において限定されない。

【0106】

すなわち、ＵＬ許可がＣＣＣＨメッセージのデータを受け入れられない場合、ＭＡＣ層は、ＲＲＣ層に示すべきである。したがって、端末装置１１０のＲＲＣ層は、ＳＤＴ中断プロシージャを実行するか、又はアイドルモードに入って、その後、オンデマンド情報についての要求を開始してもよい。このように、オンデマンド情報（例えば、ＳＩ／ＰＩ）は、ＳＤＴプロシージャ中にトリガされても、端末装置１１０により取得されることができる。

【0107】

ＳＤＴプロシージャの終了の実現例
本開示の発明者は、ＳＤＴプロシージャ中に、ＳＤＴプロシージャを継続して実行することができないいくつかのケースが存在する可能性があることに気づいた。そのように、ＳＤＴプロシージャを終了した方がいい。しかしながら、この場合、ＳＤＴプロシージャを終了するために端末装置１１０が何を実行すべきか否かは、依然として不明である。

【0108】

さらに、本開示の発明者は、いずれも発生した後に端末装置１１０が何をすべきかが不明である多数のシナリオを発見している。具体的には、１つのシナリオにおいて、例えば、端末装置１１０がＲＲＣ再開要求メッセージとアップリンクデータとを送信することにより最初のＳＤＴを送信するだけであって、ネットワーク装置１２０がネットワークにおける遅延や障害によりこの最初のデータ送信を受信していない場合、このとき、端末装置１１０がページング要求を受信すれば（例えば着信呼がある場合）、ＳＤＴを継続して実行するよりもページング要求についての応答を提供する方がよい。これは、ＳＤＴが、例えば着信呼により引き起こされるページング要求よりも低い優先度を有するからである。このようなシナリオにおいて、端末装置１１０は、ＳＤＴプロシージャをどのように処理すればよいのであろうか。

【0109】

さらに、別のシナリオにおいて、端末装置１１０の上位層（例えば、ＮＡＳ層）は、ＲＲＣ再開プロシージャをＲＲＣ層へトリガしてもよく、ＳＤＴプロシージャは、例えば、ＲＲＣ層により開始される。しかしながら、その後、上位層は、ＲＲＣ再開プロシージャを放棄するように、すなわちＲＲＣ接続確立を中断するように、ＲＲＣ層に示してもよい。このようなケースにおいて、端末装置１１０は、ＳＤＴプロシージャをどのように処理すればよいのであろうか。

【0110】

別のシナリオにおいて、タイマは、導入され、アップリンクデータの送信が失敗したか否かを決定するために使用される。例えば、該タイマは、ＳＤＴプロシージャがＲＲＣ層により開始されると、すぐに開始されるタイマであってもよい。代替として、該タイマは、後続のデータ送信フェーズ中に端末装置１１においてアップリンクデータの送信が実行されたときに開始又はリセットされるタイマであってもよい。

【0111】

通常のシナリオにおいて、最大値でセットされたタイマは、ＳＤＴプロシージャ中に満了すべきではなく、該タイマが満了する前にネットワーク装置１２０から応答があるべきである。しかしながら、タイマが満了し、且つ、（例えば、ネットワーク遅延、ネットワーク障害等により）ネットワーク装置１２０からの応答がない場合、端末装置１１０は、アップリンクデータの送信が失敗したと決定してもよい。このようなシナリオにおいて、端末装置１１０は、ＳＤＴプロシージャをどのように処理すればよいのであろうか。

【0112】

別のシナリオにおいて、ＲＬＣ送信が失敗したとき、ＲＬＣ再送信が発生する。該ＲＬＣ再送信が失敗した場合、別のＲＬＣ再送信があってもよい。このようなシナリオにおいて、ＲＬＣ再送信の最大回数（例えば、２回又は４回のＲＬＣ再送信）が定義されてもよい。ＳＤＴ中に、ＲＬＣ再送信の最大回数に達した場合、これは、その時点でのチャネル状態が悪いことを意味するかもしれない。このようなシナリオにおいて、端末装置１１０は、ＳＤＴプロシージャをどのように処理すればよいのであろうか。

【0113】

追加として、ＲＡに基づくＳＤＴのＭｓｇ Ａ又はＭｓｇ ３リソース内、又はＣＧに基づくＳＤＴのＣＧリソース内の、最初のアップリンクデータ送信が所定の回数で失敗した場合、端末装置１１０によりどのようにＳＤＴプロシージャをさらに実行すればよいのであろうか。

【0114】

別のシナリオにおいて、端末装置１１０のＲＲＣ層は、新しいデータを有するすべての無線ベアラがＳＤＴをサポートするように設定され、データ量が閾値を下回っていると決定してもよく、そして、ＲＲＣ層は、端末装置１１０のＭＡＣ層がＲＡに基づくＳＤＴ又はＣＧに基づくＳＤＴを実行するかを選択するように、ＭＡＣ層に示す。利用可能な、適切なＲＡに基づくＳＤＴリソースも適切なＣＧに基づくＳＤＴリソースもない場合、利用可能な、適切なＳＤＴリソースがないため、ＭＡＣ層は、ＳＤＴをキャンセルするよう端末装置１１０のＲＲＣ層に示すべきである。この時点で、端末装置１１０のＲＲＣ層は、上述したＲＬＣ再確立又は他のＳＤＴ関連処理をすでに完了しているかもしれない。しかしながら、端末装置１１０のＭＡＣ層が、ＳＤＴリソースが利用不可能であることをＲＲＣ層にすでに示しているので、端末装置１１０は、どのように実行すべきであろうか。

【0115】

上記問題のうちの少なくとも１つを解決するために、ＳＤＴを終了するための解決策が提供される。ここで、図５を参照すると、図５は、本開示のいくつかの実施形態にかかるＳＤＴプロシージャのためのシグナリングフロー５００を示す。説明のために、図１Ａを参照しつつシグナリングフロー５００を説明する。シグナリングフロー５００には、図１Ａに示されるような端末装置１１０と、ネットワーク装置１２０とが関与する。

【0116】

図５に示すように、例えば、端末装置１１０は、非アクティブ状態においてアップリンクデータをネットワーク装置１２０に送信しているかもしれない（５１０）。別の例において、端末装置１１０は、非アクティブ状態においてアップリンクデータをネットワーク装置１２０に送信しようとしているが、まだ送信していないかもしれない。次いで、端末装置１１０は、ネットワーク装置１２０から端末装置１１０宛てのページングメッセージを受信したことと、端末装置１１０のＲＲＣ層において非アクセスストラタム層から接続確立の中断を受信したことと、非アクティブ状態におけるアップリンクデータの送信に関連する第１のタイマの満了と、すでにＲＬＣ再送信の最大回数に達したことと、（ＭｓｇＡ／Ｍｓｇ３／ＣＧリソースにおける）最初のアップリンクデータ送信が所定の回数で失敗したことと、端末装置１１０のＭＡＣ層からＲＲＣ層に非アクティブ状態におけるアップリンクデータの送信をキャンセルする指示が提供されたことと、のうちの１つに応じて、非アクティブ状態におけるアップリンクデータの送信（すなわち、ＳＤＴプロシージャ）を中断する（５２０）。

【0117】

いくつかの実施形態において、端末装置１１０は、送信を拒否するメッセージ（例えば、ＲＲＣＲｅｊｅｃｔメッセージ）を受信したことに応じてＳＤＴプロシージャを中断してもよい。いくつかの例において、端末装置１１０は、非アクティブ状態における送信をサポートしていない（すなわち、ＳＤＴをサポートしていない）少なくとも１つの無線ベアラから到着する別のアップリンクデータに応じて、ＳＤＴプロシージャを中断してもよい。いくつかの例において、端末装置１１０は、ＮＡＳ層又はＡＳ層がＲＲＣ Ｃｏｎｎｅｃｔｅｄ状態への遷移を要求したことに応じて、ＳＤＴプロシージャを中断してもよい。いくつかの実施形態において、端末装置１１０は、端末装置１１０のサービングセルの受信信号電力（例えば、ＲＳＲＰ）が閾値電力より低いことに応じて、ＳＤＴプロシージャを中断してもよい。いくつかの実施形態において、端末装置１１０は、第１のセルから第２のセルへのセル再選択が実行されたことに応じて、ＳＤＴプロシージャを中断してもよい。これらは単なる例であり、ＳＤＴプロシージャを中止するための任意の他の適切な条件も可能である。

【0118】

いくつかの実施形態において、端末装置１１０は、非アクティブ状態におけるアップリンクデータの送信に関連するタイマを停止することにより、ＳＤＴプロシージャを中断してもよい。したがって、いったんタイマが停止されると、タイマの満了は、トリガされないため、他の予期しない動作がトリガされることはない。

【0119】

いくつかの他の実施形態において、端末装置１１０は、また、現在のＫｇＮＢ鍵、ＫＲＲＣｅｎｃ鍵、ＫＲＲＣｉｎｔ鍵、ＫＵＰｉｎｔ鍵及びＫＵＰｅｎｃ鍵を廃棄すること、ＭＡＣをリセットし、デフォルトＭＡＣセルグループ設定を解放すること、少なくとも、非アクティブ状態における送信をサポートする無線ベアラのＲＬＣエンティティ（すなわち、すべての無線ベアラ又はＳＤＴをサポートする無線ベアラのみ）を再確立すること、ＳＲＢ１及び少なくとも、非アクティブ状態における送信をサポートする無線ベアラ（すなわち、すべての無線ベアラ又はＳＤＴをサポートする無線ベアラのみ）を一時停止することのうちの少なくとも１つにより、ＳＤＴプロシージャを中断してもよい。ＳＤＴプロシージャを中断することに、より多くの動作又はより少ない動作が含まれてもよいことに注意すべきである。

【0120】

上記の解決策により、どのシナリオにおいて進行中のＳＤＴプロシージャを終了すべきかは、明らかである。そして、端末装置１１０は、リストされたシナリオが発生した場合にＳＤＴプロシージャを中断することにより、より堅牢なＳＤＴ解決策を提供することができる。

【0121】

いくつかの他の実施形態において、端末装置１１０は、また、ネットワーク装置１２０から端末装置１１０宛てのページングメッセージを受信したことと、端末装置１１０のＲＲＣ層において非アクセスストラタム層から接続確立の中断を受信したことと、非アクティブ状態におけるアップリンクデータの送信に関連する第１のタイマの満了と、すでにＲＬＣ再送信の最大回数に達したことと、（ＭｓｇＡ／Ｍｓｇ３／ＣＧリソースにおける）最初のアップリンクデータ送信が所定の回数で失敗したことと、又は、端末装置１１０のＭＡＣ層からＲＲＣ層に非アクティブ状態におけるアップリンクデータの送信をキャンセルする指示が提供されたことと、のうちの１つに応じて、アイドル状態に入ってもよい。

【0122】

上記の解決策により、端末装置１１０は、また、リストされたシナリオが発生した場合にアイドル状態に入ることにより、ＳＤＴのためのより堅牢且つ完全な解決策を提供することができる。

【0123】

アイドル状態（すなわち、ＲＲＣ＿ＩＤＬＥ）に入ると、端末装置１１０は、既存の３ＧＰＰ規格で定義されていることに従って実行してもよく、その詳細は、本明細書では規定されないことを理解すべきである。

【0124】

第２のＲＲＣ再開の実現例
いくつかの実施形態において、上述したように、ＳＤＴ中断は、様々な理由により、ＳＤＴプロシージャが開始された後に実行されてもよい。また、ＳＤＴ中断後、端末装置１１０は、非アクティブ状態に残ってもよい。非アクティブ状態にあるとき、端末装置１１０は、同じセル内で再びＲＲＣ再開プロシージャを開始してもよい。本開示の発明者は、このような場合に同じｒｅｓｕｍｅＭＡＣ－Ｉを使用する場合にいくつかのセキュリティ上の懸念があることに気づいた。

【0125】

具体的には、ＲｅｓｕｍｅＭＡＣ－Ｉは、端末装置１１０によりＲＲＣ再開要求メッセージ内でネットワーク装置１２０に送信されることにより、ネットワーク装置１２０がそれを用いて端末装置１１０が正当な端末装置１１０であるか否かを検証することができるようにする情報である。ＲＲＣ再開要求メッセージは、ＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔ又はＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔ１メッセージであってもよいことを理解すべきである。

【0126】

しかしながら、問題は、ＲｅｓｕｍｅＭＡＣ－Ｉが、ＳＤＴ中断プロシージャの前に発生するＳＤＴプロシージャ内ですでに計算されていることである。しかしながら、（例えば、ＳＤＴのため、又は非ＳＤＴのための）ＲＲＣ再開プロシージャは、同じセル内で再び同じＵＥコンテキストを使用して実行されるので、ＲｅｓｕｍｅＭＡＣ－Ｉが再計算される可能性があり、これにより、２回目で計算されるＲｅｓｕｍｅＭＡＣ－Ｉが、前のＳＤＴプロシージャで既に計算されたものと同じであるかもしれない。結果として、別の装置（例えば、別の端末装置１１０）を持つ者が、傍受により、中断プロシージャの前のＳＤＴプロシージャで計算されたｒｅｓｕｍｅＭＡＣ－Ｉを取得した場合、該装置を持つ者は、端末装置１１０になりすまして、第２のＲＲＣ再開要求メッセージをネットワーク装置１２０に送信する可能性がある。

【0127】

以上のケースの発生を防ぐためには、すでに一度使用されたｒｅｓｕｍｅＭＡＣ－Ｉを次のＳＤＴ／非ＳＤＴプロシージャにおいて次回から再利用しない方がいい。したがって、第２のＲＲＣ再開のための解決策が提供される。この解決策において、端末装置１１０は、ＲＲＣ再開プロシージャに関連する第１の値に基づいて、ＲＲＣ再開プロシージャのためのメッセージ認証コード整合性（ＭＡＣ－Ｉ：ｍｅｓｓａｇｅ ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｃｏｄｅ－ｉｎｔｅｇｒｉｔｙ）のパラメータを決定する。そして、端末装置１１０は、ＲＲＣ再開プロシージャを開始するために、当該パラメータを含むＲＲＣ再開要求メッセージを送信する。このような解決策において、第１の値は、別のＲＲＣ再開プロシージャ（例えば、ＳＤＴ中断プロシージャの前に発生するＲＲＣ再開プロシージャ）を決定するために使用されるＭＡＣ－Ｉの値とは異なる。

【0128】

上記の解決策により、該第２のＲＲＣ再開プロシージャ中に、それぞれのシーンについてＣＯＵＮＴ及び／又はＢＥＡＲＥＲ及び／又はＤＩＲＥＣＴＩＯＮの異なる入力値を使用してＭＡＣ－Ｉのパラメータ（例えば、ｒｅｓｕｍｅＭＡＣ－Ｉ）を計算することにより、ネットワークのセキュリティを向上させることができる。

【0129】

ここで、図６を参照すると、図６は、本開示のいくつかの実施形態にかかるＳＤＴプロシージャのためのシグナリングフロー６００を示す。説明のために、図１Ａを参照しつつシグナリングフロー６００を説明する。シグナリングフロー３００には、図１Ａに示されるような端末装置１１０と、ネットワーク装置１２０とが関与する。

【0130】

図６に示すように、端末装置１１０は、ＲＲＣ再開プロシージャに関連する値に基づいて、ＲＲＣ再開プロシージャのためのＭＡＣ－Ｉのパラメータを決定する（６１０）。ＲＲＣ再開プロシージャに関連する該値は、別のＲＲＣ再開プロシージャのＭＡＣ－Ｉを決定するための値とは異なる。いくつかの例において、ＭＡＣ－Ｉのパラメータは、ｒｅｓｕｍｅＭＡＣ－Ｉであってもよい。

【0131】

いくつかの例において、別のＲＲＣ再開プロシージャのＭＡＣ－Ｉを決定するための値は、２進数１のシーケンスである所定の値であってもよい。例えば、１６ビットのシーケンスである場合、該所定の値は、１１１１，１１１１，１１１１，１１１１であってもよい。いくつかの他の実施形態において、該所定の値は、１１又は１１１１であってもよく、本開示の実施形態は、この点において限定されない。

【0132】

いくつかの実施形態において、ＲＲＣ再開プロシージャに関連する値は、ｒｅｓｕｍｅＭＡＣ－Ｉを決定するためのカウントの入力ビットであってもよい。いくつかの他の実施形態において、この値は、ｒｅｓｕｍｅＭＡＣ－Ｉを決定するためのベアラの入力ビットであってもよい。代替として、この値は、ｒｅｓｕｍｅＭＡＣ－Ｉを決定するための方向の入力ビットであってもよい。他の実施形態において、この値は、カウント、ベアラ及び方向の入力ビット、又はそれらの任意の組み合わせであってもよい。

【0133】

いくつかの実施形態において、端末装置１１０は、非アクティブ状態における別のアップリンクデータの送信を中断した後にＲＲＣ再開プロシージャが開始されるとの決定に従って、該パラメータを決定してもよい。

【0134】

このような実施形態において、例えば、端末装置１１０が、後で、同じセル内で同じＵＥコンテキストを使用して（ＳＤＴ又はレガシーデータ送信のための）第２のＲＲＣ再開プロシージャを実行する場合、端末装置１１０は、
２＞ 節８（すなわち、８ビットの倍数の）ＶａｒＲｅｓｕｍｅＭＡＣ－Ｉｎｐｕｔに従ってエンコードされるＡＳＮ．１上で、
２＞ ＵＥ Ｉｎａｃｔｉｖｅ ＡＳ Ｃｏｎｔｅｘｔ内のＫＲＲＣｉｎｔ鍵と、以前に設定された整合性保護アルゴリズムを使用して、及び
２＞ 全２進値１ではない所定の値にセットされるカウント及び／又はベアラ及び／又は方向のための入力ビットで、
ＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔ又はＲＲＣＲｅｓｕｍｅＲｅｑｕｅｓｔ１内のｒｅｓｕｍｅＭＡＣ－Ｉを、全２進数１ではなく、カウント及び／又はベア及び／又は方向の予め定義された入力値（例えば、全２進数０、２進数１と０を含むシーケンスなど）で計算されるＭＡＣ－Ｉの最下位１６ビットにセットする。

【0135】

上記の解決策により、端末装置１１０が同一セル内でＲＲＣ再開プロシージャを再び開始する際に、ＳＤＴ中断後に異なるｒｅｓｕｍｅＭＡＣ－Ｉを使用することが可能となるため、システムの安全性が向上する。

【0136】

いくつかの他の実施形態において、端末装置１１０は、また、ＲＲＣ再開プロシージャが、非アクティブ状態におけるアップリンクデータの送信のためのものであるとの決定に従って、パラメータを決定してもよい。

【0137】

このような実施形態において、例えば、端末装置１１０がＳＤＴのためのＲＲＣ再開プロシージャを開始する場合、端末装置１１０は、カウント及び／又はベアラ及び／又は方向のための入力ビットを、全２進数１ではない（例えば、全２進数０など）所定の値にセットして、ｒｅｓｕｍｅＭＡＣ－Ｉを計算してもよい。そうでない場合、端末装置１１０は、従来の解決策と同様に、すなわち、全２進数１にセットして、ｒｅｓｕｍｅＭＡＣ－Ｉを計算する。

【0138】

図６に戻り、ＲＲＣ再開プロシージャのためのＭＡＣ－Ｉのパラメータを決定するとき、端末装置１１０は、ＲＲＣ再開プロシージャを開始するために、該パラメータを含むＲＲＣ再開要求メッセージを送信する（６２０）。

【0139】

いくつかの例において、ｒｅｓｕｍｅＭＡＣ－Ｉを含むＲＲＣ再開要求は、端末装置１１０によりネットワーク装置１２０に以下のように送信されてもよい：
RRCResumeRequest ::= SEQUENCE {
rrcResumeRequest RRCResumeRequest-IEs
}

RRCResumeRequest-IEs ::= SEQUENCE {
resumeIdentity ShortI-RNTI-Value,
resumeMAC-I BIT STRING (SIZE (16)),
resumeCause ResumeCause,
spare BIT STRING (SIZE (1))
}

【0140】

また、状態変数ＴＸ＿ＮＥＸＴは、送信される次のＰＤＣＰ ＳＤＵのカウント値を示す。いくつかの実施形態において、状態変数の初期値は、状態変数継続が設定されたＳＲＢを除いて０である。いくつかの実施形態において、状態変数継続が設定されたターゲットＳＲＢについて、初期値は、対応するソースＳＲＢのＰＤＣＰエンティティに記憶された値である。状態変数継続が設定されたソースＳＲＢについて、初期値は、対応するターゲットＳＲＢのＰＤＣＰエンティティに記憶された値である。

【0141】

ＰＤＣＰエンティティ一時停止プロシージャ中、ＴＸ＿ＮＥＸＴは、端末装置が非アクティブ状態に入ると現在実行されている初期値にセットされる。

【0142】

ＲＲＣ再開プロシージャ中、ＰＤＣＰ再確立が行われ、ここで、非肯定応答モード（ＵＭ：ｕｎａｃｋｎｏｗｌｅｄｇｅｄ ｍｏｄｅ）ＤＲＢ及びＳＲＢについての状態変数ＴＸ＿ＮＥＸＴは、初期値にセットされる。

【0143】

この場合、ＲＲＣ再開プロシージャが、現在のＵＥコンテキストを使用して、以前のＳＤＴプロシージャについてのセルと同じセルにおいてトリガされた場合、ＲＲＣ再開プロシージャの間又は後に、ＳＤＴ又はレガシーデータ送信により送信されるパケットは、以前に送信されたパケットと同じセキュリティ鍵とＣＯＵＮＴ値とを使用して暗号化される。しかしながら、ＲＲＣ再開プロシージャの間又は後に送信されるパケットは、以前のＳＤＴプロシージャにおいて以前に送信されたパケットとは異なってもよい。そのため、異なるパケットが同じセキュリティ鍵とＣＯＵＮＴ値とを使用して暗号化されることになり、安全の観点からは許されないことである。

【0144】

この点に鑑みて、本願の実施形態は、状態変数ＴＸ＿ＮＥＸＴをリセットしないようにセキュリティ問題に対処するための解決策を提供する。

【0145】

上述したように、いくつかのシナリオにおいて、ＳＤＴプロシージャが中断されてもよく、その後、端末装置は、ＳＤＴプロシージャが実行されたセルと同じセル内で別のＲＲＣ再開プロシージャをトリガしてもよい。この実施形態は、以下に詳細に説明される、これらのシナリオにおけるセキュリティを強化するための解決策を提供することを目的としている。

【0146】

このような実施形態において、端末装置１１０は、非アクティブ状態においてネアップリンクデータをットワーク装置１２０に送信する。すなわち、端末装置１１０は、ＳＤＴプロシージャを実行する。いくつかの実施形態において、端末装置１１０は、ＳＤＴプロシージャを中断してもよい。

【0147】

ＳＤＴプロシージャ中に、端末装置１１０は、ネットワーク装置１２０との接続の再開が、ＳＤＴプロシージャがすでに実行されたセルにおいて実行されるか否かを決定してもよい。接続の再開が該セルにおいて実行される場合、端末装置１１０は、以下に記載されるように、接続の再開を実行してもよい。

【0148】

例えば、端末装置１１０は、接続を回復するためのＰＤＣＰ再確立において、非肯定応答モード（ＵＭ）ＤＲＢ又はＳＲＢのＰＤＣＰエンティティの状態変数（すなわち、ＴＸ＿ＮＥＸＴ）を維持してもよい。すなわち、ＵＭ ＤＲＢ又はＳＲＢのＰＤＣＰエンティティのＴＸ＿ＮＥＸＴは、ＲＲＣ再開プロシージャにおいて初期値にセットされない。こうして、ＲＲＣ再開プロシージャ時に送信される最初のパケットは、ＳＤＴプロシージャにおける以前の送信されたパケットとは異なるＣＯＵＮＴ値で暗号化されることができる。

【0149】

ＮＡＳ層又はＡＳ層がＳＤＴ又はレガシーデータ送信のためにＲＲＣ接続を再開するように端末装置１１０に要求するとき、端末装置１１０が現在のＵＥコンテキストを使用してＳＤＴプロシージャを実行したセルである場合、端末装置１１０は、ＲＲＣ再開プロシージャにおいて以下の行動を実行してもよい。例えば、レガシーデータ送信の場合、ネットワーク装置１２０は、ＲＲＣ再開メッセージ内でＤＲＢ、ＳＲＢ１及びＳＲＢ２についてのＰＤＣＰ再確立を実行するように端末装置１１０を設定してもよい。ＳＤＴの場合、端末装置１１０のＲＲＣ層は、ＳＤＴを有するように設定されたＤＲＢ又はＳＲＢ（例えば、ＳＲＢ１又はＳＲＢ２）についてのＰＤＣＰ再確立を開始してもよい。ＲＲＣ層が、ＳＤＴを有するように設定された無線ベアラのＰＤＣＰエンティティに再確立を実行するように示す場合、ＲＲＣ層は、さらに、ＵＭ ＤＲＢ及びＳＲＢについての再確立中にＴＸ＿ＮＥＸＴが初期化されないことをＰＤＣＰに示すべきである。

【0150】

いくつかの実施形態において、他のＲＲＣ再開プロシージャ（すなわち、第２のＲＲＣプロセス）がレガシーデータ送信（すなわち、接続状態の間のデータ送信）のためのものである場合、非ＳＤＴベアラではなくＳＤＴベアラについてのみセキュリティ問題が存在することを考慮して、ネットワーク装置１２０は、以下の方法のうちのいずれか１つでＲＲＣ再開メッセージ内に設定してもよい。

【0151】

例えば、ＲＲＣ再開メッセージ内で、ネットワーク装置１２０は、ＳＤＴベアラ及び非ＳＤＴベアラのためにＰＤＣＰ再確立を設定してもよく、端末装置１１０のＲＲＣ層は、ＰＤＣＰ再確立を実行するときに、ＳＤＴをサポートする無線ベアラについてのＴＸ＿ＮＥＸＴ継続をＰＤＣＰ層に示してもよい。

【0152】

代替として、ＲＲＣ再開メッセージ内で、ネットワーク装置１２０は、ＳＤＴをサポートしない無線ベアラについてＰＤＣＰ再確立を設定してもよい。同時に、ネットワーク装置１２０は、ＳＤＴをサポートするＤＲＢについてＰＤＣＰリカバリを設定し、ＳＤＴをサポートするＳＲＢ１及び／又はＳＲＢについてＰＤＣＰ ＳＤＵ破棄を設定してもよい。ＰＤＣＰリカバリにより、ＳＤＴをサポートする無線ベアラについても、ＴＸ＿ＮＥＸＴがリセットされることはない。

【0153】

いくつかの実施形態において、ＳＤＴプロシージャが実行されたセルとは異なるセルにおいて接続の再開が実行される場合、端末装置１１０は、ＰＤＣＰ再確立において状態変数を初期化することにより接続の再開を実行してもよい。例えば、端末装置１１０は、ＰＤＣＰ再確立の前に、ＤＲＢの下位層にＰＤＣＰ一時停止を示し、ＴＸ＿ＮＥＸＴが初期化されていないことを示すことなく、ＰＤＣＰ再確立を実行してもよい。

【0154】

例えば、修正された３ＧＰＰ仕様の関連内容は、次のようになる： 上位層がＰＤＣＰエンティティ再確立を要求するとき、送信するＰＤＣＰエンティティは、次のようにすべきである。 － ＵＭ ＤＲＢ及びＡＭ ＤＲＢについて、ＴＳ ３８．３３１［３］にｄｒｂ－ＣｏｎｔｉｎｕｅＲＯＨＣが設定されていない場合、アップリンクについてＲＯＨＣプロトコルをリセットし、Ｕモード（ＲＦＣ ３０９５［８］及びＲＦＣ ４８１５［９］に定義されている）にてＩＲ状態で開始し、
－ ＵＭ ＤＲＢ及びＡＭ ＤＲＢについて、ＴＳ ３８．３３１［３］にｄｒｂ－ＣｏｎｔｉｎｕｅＥＨＣ－ＵＬが設定されていない場合、アップリンクについてのＥＨＣプロトコルをリセットし、
－ 上位層がＴＸ＿ＮＥＸＴ値を維持するように示さなかった場合、ＵＭ ＤＲＢ及びＳＲＢについて、ＴＸ＿ＮＥＸＴを初期値にセットし、
－ ＳＲＢについて、記憶されているＰＤＣＰ ＳＤＵ及びＰＤＣＰ ＰＤＵをすべて破棄する。

【0155】

パワーヘッドルーム報告の実現例
従来では、ＰＨＲはアップリンクパワーの使用状況をネットワーク装置１２０に報告するために端末装置１１０により使用される。従来の解決策では、ＰＨＲは、ＳＤＴ時に端末装置１１０のＭＡＣ層によりトリガされる。追加として、ＰＨＲは、データ（例えば、ＤＲＢ及びＳＲＢデータ）よりも高い優先度を有する。

【0156】

したがって、最初のデータ送信フェーズ中、ＲＲＣ再開要求（すなわちＣＣＣＨメッセージ）が非アクティブ状態におけるアップリンクデータとともに送信される場合、そしてその時点でＰＨＲを送信する必要もあれば、ＵＬ許可は、データ（ＵＬ ＣＣＣＨ、ＤＣＣＨ及びＤＴＣＨを含む）のみを受け入れられるが、ＰＨＲ ＭＡＣ ＣＥ及びそのヘッダ（３バイト）を受け入れられない可能性がある。結果として、アップリンクデータは、一度に送信されない可能性があり、端末装置１１０は、避けた方がよい後続のデータ送信を行わなければならないことになる。

【0157】

いくつかの例において、アップリンクデータを有するＲＲＣ再開要求メッセージのサイズが１００ビットであれば、ＰＨＲのサイズが１０ビット（すなわち、合計１１０ビット）になる。しかしながら、ネットワーク装置１２０が１００ビットのみを割り当てる場合について説明する。上述したように、ＰＨＲの優先度は、データよりも高い。結果として、このアップリンク許可内で送信できず、後続のデータ送信フェーズ内で送信される必要がある１０ビットのデータが存在する。しかしながら、ＰＨＲが、後続のデータ送信のために（例えば、後続のデータ送信のアップリンク送信パワーを調整するため）使用されるが、より高い優先度を有することを考慮すると、最初のデータ送信フェーズで一度に送信されることのできないデータが発生する。

【0158】

上記問題を解決するために、ＳＤＴのための解決策が提供される。ここで、図７を参照すると、図７は、本開示のいくつかの実施形態にかかるＳＤＴプロシージャのためのシグナリングフロー７００を示す。説明のために、図１Ａを参照しつつシグナリングフロー７００を説明する。シグナリングフロー７００には、図１Ａに示されるような端末装置１１０と、ネットワーク装置１２０とが関与する。

【0159】

図７に示すように、端末装置１１０は、ＰＨＲをトリガする（７１０）。そして、アップリンクデータが非アクティブ状態において送信されると決定された場合、端末装置１１０は、アップリンク許可がアップリンクデータを受け入れ、ＰＨＲを追加として受け入れないか否かを決定する（７２０）。アップリンク許可がアップリンクデータを受け入れ、ＰＨＲを追加として受け入れないと決定された場合、端末装置１１０は、アップリンクデータにリソースを割り当てる（７３０）。その後、端末装置１１０は、割り当てられたリソースを使用してアップリンクデータを送信する（７４０）。

【0160】

したがって、ＳＤＴ中にＰＨＲがトリガされた場合、ＵＬグラントが、送信のために利用可能なすべての保留中のデータを受け入れることができるが、ＰＨＲ ＭＡＣ ＣＥ及びそのヘッダを追加として受け入れるには不十分であれば、リソース割当を実行する際に、ＭＡＣ層は、リソースを選択してＰＨＲ ＭＡＣ ＣＥの論理チャネルに割り当てるべきではない。

【0161】

したがって、ＵＬ－ｇｒａｎｔがデータのみを受け入れられるが、ＰＨＲを受け入れられない場合、ＵＥは、データのみを送信してもよい。ＳＤＴプロシージャを１回の送信で完了させることができる。

【0162】

いくつかの実施形態において、アップリンク許可がＰＨＲを追加として受け入れないと決定された場合、端末装置１１０は、リソースをＰＨＲのＭＡＣ－ＣＥに割り当てることを回避してもよい。すなわち、端末装置１１０は、ＰＨＲのＭＡＣ－ＣＥにリソースを割り当てない。いくつかの実施形態において、ＵＬグラントがデータ及びＰＨＲの両方を受け入れられる場合、端末装置１１０は、その両方を同時に送信してもよい。

【0163】

方法の実現例
本開示の実施形態は、端末装置とネットワーク装置において実現される通信方法を提供する。図８～図１３を参照して、以下にこれらの方法を説明する。

【0164】

図８は、本開示のいくつかの実施形態にかかる、端末装置において実現される例示的な通信方法８００を示す図である。例えば、方法８００は、図１Ａに示すような端末装置１１０において実行されてもよい。以下、説明のために、図１Ａを参照しつつ方法８００を説明する。方法８００は、図示されていない追加のブロックを含んでもよく、且つ／又は図示されているいくつかのブロックを省略してもよく、本開示の範囲がこの点において限定されないことを理解すべきである。

【0165】

図８に示すように、ブロック８１０において、端末装置１１０は、無線ベアラのためのＲＬＣエンティティ再確立が実行されるか否かを決定する。無線ベアラは、非アクティブ状態におけるデータの送信を有するように設定される。いくつかの実施形態において、ＲＬＣエンティティ再確立が実行されるか否かを決定することは、アップリンクデータの送信が非アクティブ状態において実行される場合、ＲＬＣエンティティ再確立が実行されると決定すること、又は、無線ベアラについてのＲＬＣエンティティ再確立に関する指示を含む無線リソース制御（ＲＲＣ）解放メッセージがネットワーク装置から受信された場合、ＲＬＣエンティティ再確立が実行されると決定すること、を含む。

【0166】

ブロック８２０において、ＲＬＣエンティティ再確立が実行されると決定した場合、端末装置１１０は、ＲＬＣエンティティを再確立する。その後、端末装置１１０は、ネットワーク装置に、無線ベアラにて非アクティブ状態においてアップリンクデータを送信する。

【0167】

いくつかの実施形態において、非アクティブ状態におけるデータ送信を有するように設定されていない別の無線ベアラについての別のＲＬＣエンティティ再確立のための指示を含むＲＲＣ再開メッセージをネットワーク装置から受信したことに応じて、端末装置は、接続状態においてデータを送信するために該別のＲＬＣエンティティを再確立してもよい。

【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】

いくつかの実施形態において、端末装置（例えば、端末装置１１０）は、回路を備え、該回路は、非アクティブ状態においてアップリンクデータをネットワーク装置に送信し、ネットワーク装置から端末装置宛てのページングメッセージを受信したことと、端末装置の無線リソース制御（ＲＲＣ）層において非アクセスストラタム層から接続確立の中断を受信したことと、非アクティブ状態におけるアップリンクデータの送信に関連する第１のタイマの満了と、すでに無線リンク制御（ＲＬＣ）再送信の最大回数に達したことと、最初のアップリンクデータ送信が所定の回数で失敗したことと、端末装置のメディアアクセス制御（ＭＡＣ）層からＲＲＣ層に非アクティブ状態におけるアップリンクデータの送信をキャンセルする指示が提供されたことと、のうちの少なくとも１つに応じて、非アクティブ状態におけるアップリンクデータの送信を中断するように設定されている。

【0210】

いくつかの実施形態において、回路は、非アクティブ状態におけるアップリンクデータの送信に関連するタイマを停止することにより、送信を中断するように設定されている。

【0211】

いくつかの実施形態において、端末装置（例えば、端末装置１１０）は、回路を備え、該回路は、ＲＲＣ再開プロシージャに関連する第１の値に基づいて、ＲＲＣ再開プロシージャのためのＭＡＣ－Ｉのパラメータを決定し、ＲＲＣ再開プロシージャを開始するためにパラメータを含むＲＲＣ再開要求メッセージを送信するように設定され、第１の値は、別のＲＲＣ再開プロシージャのＭＡＣ－Ｉを決定するための第２の値とは異なる。

【0212】

いくつかの実施形態において、第１の値は、ｒｅｓｕｍｅＭＡＣ－Ｉを決定するためのカウントの入力ビットと、ｒｅｓｕｍｅＭＡＣ－Ｉを決定するためのベアラの入力ビットと、ｒｅｓｕｍｅＭＡＣ－Ｉを決定するための方向の入力ビットと、のうちの少なくとも１つを含む。

【0213】

いくつかの実施形態において、回路は、非アクティブ状態における別のアップリンクデータの別の送信を中断した後にＲＲＣ再開プロシージャが開始されること、又は、ＲＲＣ再開プロシージャが非アクティブ状態におけるアップリンクデータの送信のためのものであることのうちの少なくとも１つを決定したことに応じてパラメータを決定することにより、パラメータを決定するように設定されている。

【0214】

いくつかの実施形態において、所定の値は、２進数１のシーケンスを含んでもよい。

【0215】

いくつかの実施形態において、端末装置（例えば、端末装置１１０）は、回路を備え、該回路は、ＰＨＲをトリガし、アップリンクデータが非アクティブ状態において送信されるとの決定に従って、アップリンク許可がアップリンクデータを受け入れ、ＰＨＲを追加として受け入れないか否かを決定し、アップリンク許可がアップリンクデータを受け入れ、ＰＨＲを追加として受け入れないとの決定に従って、アップリンクデータにリソースを割り当て、ネットワーク装置に、割り当てられたリソースを使用してアップリンクデータを送信するように設定されている。

【0216】

回路は、さらに、アップリンク許可がＰＨＲを追加として受け入れないとの決定に従って、リソースをＰＨＲのＭＡＣ－ＣＥに割り当てることを回避するように設定されている。

【0217】

全体として、本開示の様々な実施形態は、ハードウェア又は専用回路、ソフトウェア、論理、又はそれらの任意の組み合わせで実現されてもよい。いくつかの態様は、ハードウェアで実現されてもよく、他の態様は、コントローラ、マイクロプロセッサ、又は他のコンピューティング装置により実行することができるファームウェア又はソフトウェアで実現されてもよい。本開示の実施形態の様々な態様は、ブロック図、フローチャート又は他の何らかの絵画的表現を用いて図示及び説明されているが、本明細書に記載されたブロック、機器、システム、技術、又は方法は、非限定的な例として、ハードウェア、ソフトウェア、ファームウェア、専用回路又は論理、汎用ハードウェア又はコントローラ又は他のコンピューティング装置、又はそれらの何らかの組み合わせで実装されてもよいことを理解すべきである。

【0218】

本開示は、また、非一時的なコンピュータ可読記憶媒体上に有形的に記憶された少なくとも一つのコンピュータプログラム製品を提供する。コンピュータプログラム製品は、図３から図１３を参照して上述したプロセス又は方法を実行するために、対象の実プロセッサ又は仮想プロセッサ上の装置内で実行される、プログラムモジュールに含まれる命令などのコンピュータ実行可能な命令を含む。一般に、プログラムモジュールには、特定のタスクを実行するか、又は特定の抽象データタイプを実装するルーチン、プログラム、ライブラリ、オブジェクト、クラス、コンポーネント、データ構造などが含まれる。様々な実施形態において、プログラムモジュールの機能は、必要に応じて、プログラムモジュール間で結合又は分割されてもよい。プログラムモジュールのマシンが実行可能な命令は、ローカル又は分散型装置内で実行されてもよい。分散型装置において、プログラムモジュールは、ローカル記憶媒体及びリモート記憶媒体内の両方に配置されていてもよい。

【0219】

本開示の方法を実行するためのプログラムコードは、一つ又は複数のプログラミング言語の任意の組み合わせで記述されてもよい。これらのプログラムコードは、汎用コンピュータ、専用コンピュータ、又は他のプログラマブルデータプロセッシング機器のプロセッサ又はコントローラに提供され、プロセッサ又はコントローラにより実行された場合、プログラムコードで、フローチャート及び／又はブロック図に指定された機能／動作を実現させる。プログラムコードは、完全にマシン上で、部分的にマシン上で、独立したソフトウェアパッケージとして、部分的にマシン上でかつ部分的にリモートマシン上で、又は完全にリモートマシン又はサーバ上で実行してもよい。

【0220】

上述のプログラムコードは、マシン可読媒体上で実装されてもよく、マシン可読媒体は、命令実行システム、機器、又は装置により利用されるか、又はそれらに関連するプログラムを含むか又は記憶することができる任意の有形媒体であってもよい。マシン可読媒体は、マシン可読信号媒体又はマシン可読記憶媒体であってもよい。マシン可読媒体は、電子、磁気、光学、電磁気、赤外線若しくは半導体のシステム、機器若しくは装置、又は前述の媒体の任意の適切な組み合せを含むことができるが、これらに限定されない。マシン可読記憶媒体のより具体的な例は、一つ又は複数のワイヤを有する電気接続、ポータブルコンピュータディスク、ハードディスク、ランダムアクセスメモリ（ＲＡＭ）、リードオンリーメモリ（ＲＯＭ）、消去可能プログラマブルリードオンリーメモリ（ＥＰＲＯＭ又はフラッシュメモリ）、光ファイバ、ポータブルコンパクトディスクリードオンリーメモリ（ＣＤ－ＲＯＭ）、光学的記憶装置、磁気記憶装置、又は上述の任意の適切な組合せを含んでもよい。

【0221】

なお、動作について特定の順序で説明を行ったが、所望の結果を得るために、こうした動作を、示された特定の順序で実行するか若しくは連続した順序で実行し、又は、説明されたすべての動作を実行することが求められる、と理解されるべきではない。場合によっては、マルチタスクや並列処理が有利になることもある。同様に、いくつかの特定の実装の詳細が上記の議論に含まれているが、これらは、本開示の範囲に対する限定として解釈されるべきではなく、特定の実施形態に固有となり得る特徴の説明として解釈されるべきである。個々の実施形態の文脈で説明されたいくつかの特徴は、単一の実施形態において組み合わされて実現されてもよい。逆に、単一の実施形態の文脈で説明された様々な特徴は、複数の実施形態において別々に、又は任意の適切なサブコンビネーションで実装されてもよい。

【0222】

本開示は、構造的特徴及び／又は方法論的動作に特有の言語で説明されてきたが、添付の特許請求の範囲において定義された本開示は、必ずしも上記の特定の特徴又は動作に限定されないことを理解すべきである。むしろ、上述した特定の特徴及び動作は、特許請求の範囲を実施する例示的な形態として開示されている。

【図1A】

【図1B】

【図1C】

【図2A】

【図2B】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【手続補正書】

【提出日】2024-01-09

【手続補正1】

【補正対象書類名】特許請求の範囲

【補正対象項目名】全文

【補正方法】変更

【補正の内容】

【特許請求の範囲】

【請求項1】

スモールデータ送信（ＳＤＴ）プロシージャをサポートする手段と、
ＵＥがシステム情報ブロック（ＳＩＢ）の有効なバージョンを記憶しておらず、システム情報（ＳＩ）メッセージがブロードキャストされておらず、且つ前記ＳＤＴプロシージャが進行中ではない場合に、前記ＳＩメッセージを取得するために、オンデマンドシステム情報についての要求をトリガする手段と、
を備える、ユーザ装置（ＵＥ）。

【請求項2】

前記ＳＤＴプロシージャが開始された場合に、前記ＳＤＴプロシージャに関連する第１のタイマを開始する手段と、
無線リソース制御（ＲＲＣ）拒否メッセージを受信する手段と、
前記ＲＲＣ拒否メッセージを受信すると、前記第１のタイマを停止する手段と、
をさらに備える、請求項１に記載のユーザ装置。

【請求項3】

すでに再送信の最大回数に達したことを無線リンク制御（ＲＬＣ）が示すか、又は、前記ＳＤＴプロシージャに関連する第２のタイマが満了した場合に、前記第１のタイマを停止する手段
をさらに備える、請求項２に記載のユーザ装置。

【請求項4】

前記ＳＤＴプロシージャが開始された場合に、前記ＳＤＴプロシージャに関連する第１のタイマを開始する手段と、
すでに再送信の最大回数に達したことを無線リンク制御（ＲＬＣ）が示すか、又は、前記ＳＤＴプロシージャに関連する第２のタイマが満了した場合に、前記第１のタイマを停止する手段と、
をさらに備える、請求項１に記載のユーザ装置。

【請求項5】

スモールデータ送信（ＳＤＴ）プロシージャが開始された場合に、前記ＳＤＴプロシージャに関連する第１のタイマを開始する手段と、
無線リソース制御（ＲＲＣ）拒否メッセージを受信する手段と、
前記ＲＲＣ拒否メッセージを受信すると、前記第１のタイマを停止する手段と、
を備える、ユーザ装置（ＵＥ）。

【請求項6】

すでに再送信の最大回数に達したことを無線リンク制御（ＲＬＣ）が示すか、又は、前記ＳＤＴプロシージャに関連する第２のタイマが満了した場合に、前記第１のタイマを停止する手段
をさらに備える、請求項５に記載のユーザ装置。

【請求項7】

スモールデータ送信（ＳＤＴ）プロシージャが開始された場合に、前記ＳＤＴプロシージャに関連する第１のタイマを開始する手段と、
すでに再送信の最大回数に達したことを無線リンク制御（ＲＬＣ）が示すか、又は、前記ＳＤＴプロシージャに関連する第２のタイマが満了した場合に、前記第１のタイマを停止する手段と、
を備える、ユーザ装置（ＵＥ）。

【請求項8】

ユーザ装置（ＵＥ）の方法であって、
スモールデータ送信（ＳＤＴ）プロシージャをサポートすることと、
前記ＵＥがシステム情報ブロック（ＳＩＢ）の有効なバージョンを記憶しておらず、システム情報（ＳＩ）メッセージがブロードキャストされておらず、且つ、前記ＳＤＴプロシージャが進行中ではない場合に、前記ＳＩメッセージを取得するために、オンデマンドシステム情報についての要求をトリガすることと、
を含む、方法。

【請求項9】

前記ＳＤＴプロシージャが開始された場合に、前記ＳＤＴプロシージャに関連する第１のタイマを開始することと、
無線リソース制御（ＲＲＣ）拒否メッセージを受信することと、
前記ＲＲＣ拒否メッセージを受信すると、前記第１のタイマを停止することと、
をさらに含む、請求項８に記載の方法。

【請求項10】

すでに再送信の最大回数に達したことを無線リンク制御（ＲＬＣ）が示すか、又は、前記ＳＤＴプロシージャに関連する第２のタイマが満了した場合に、前記第１のタイマを停止すること
をさらに含む、請求項９に記載の方法。

【請求項11】

前記ＳＤＴプロシージャが開始された場合に、前記ＳＤＴプロシージャに関連する第１のタイマを開始することと、
すでに再送信の最大回数に達したことを無線リンク制御（ＲＬＣ）が示すか、又は、前記ＳＤＴプロシージャに関連する第２のタイマが満了した場合に、前記第１のタイマを停止することと、
をさらに含む、請求項８に記載の方法。

【請求項12】

ユーザ装置（ＵＥ）の方法であって、
スモールデータ送信（ＳＤＴ）プロシージャが開始された場合に、前記ＳＤＴプロシージャに関連する第１のタイマを開始することと、
無線リソース制御（ＲＲＣ）拒否メッセージを受信することと、
前記ＲＲＣ拒否メッセージを受信すると、前記第１のタイマを停止することと、
を含む、方法。

【請求項13】

すでに再送信の最大回数に達したことを無線リンク制御（ＲＬＣ）が示すか、又は、前記ＳＤＴプロシージャに関連する第２のタイマが満了した場合に、前記第１のタイマを停止すること
をさらに含む、請求項１２に記載の方法。

【請求項14】

ユーザ装置（ＵＥ）の方法であって、
スモールデータ送信（ＳＤＴ）プロシージャが開始された場合に、前記ＳＤＴプロシージャに関連する第１のタイマを開始することと、
すでに再送信の最大回数に達したことを無線リンク制御（ＲＬＣ）が示すか、又は、前記ＳＤＴプロシージャに関連する第２のタイマが満了した場合に、前記第１のタイマを停止することと、
を含む、方法。

【国際調査報告】