【誤訳訂正書】
【提出日】平成31年3月11日(2019.3.11)
【誤訳訂正１】
【訂正対象書類名】明細書
【訂正対象項目名】００４１
【訂正方法】変更
【訂正の内容】
【００４１】
ＬＴＥにおけるＤＲＸは、３ＧＰＰ  ＴＳ  ３６．３２１において次のように説明される。
５．７  間欠受信（ＤＲＸ）
ＭＡＣエンティティは、ＭＡＣエンティティのＣ−ＲＮＴＩ、ＴＰＣ−ＰＵＣＣＨ−ＲＮＴＩ、ＴＰＣ−ＰＵＳＣＨ−ＲＮＴＩ、セミパーシステントスケジューリングＣ−ＲＮＴＩ（設定される場合）ｅＩＭＴＡ−ＲＮＴＩ（設定される場合）及びＳＬ−ＲＮＴＩ（設定される場合）のためのＵＥのＰＤＣＣＨ監視アクティビティを制御するＤＲＸ機能を有するＲＲＣによって設定されてよい。ＲＲＣ＿ＣＯＮＮＥＣＴＥＤにあるとき、ＤＲＸが設定される場合、ＭＡＣエンティティはこの節で指定されるＤＲＸ動作を使用してＰＤＣＣＨを不連続に監視することが許可される。そうでなければ、ＭＡＣエンティティはＰＤＣＣＨを継続的に監視する。ＤＲＸ動作を使用するとき、ＭＡＣエンティティはまた、本仕様書の他の節の要件に従ってＰＤＣＣＨを監視するものとする。ＲＲＣは、onDurationTimer（オン持続時間タイマ）、drx-InactivityTimer（ＤＲＸ非アクティブタイマ）、drx-RetransmissionTimer（ＤＲＸ再送タイマ）（ブロードキャストプロセスを除くＤＬ  ＨＡＲＱプロセスごとに１つ）、drx-ULRetransmissionTimer（ＤＲＸ  ＵＬ再送タイマ）（非同期ＵＬ  ＨＡＲＱプロセスごとに１つ）、longDRX-Cycle（ロングＤＲＸサイクル）、drxStartOffsetの値、及びオプションで、drxShortCycleTimerとshortDRX-Cycle（ショートＤＲＸサイクル）のタイマを設定することによってＤＲＸ動作を制御する。（ブロードキャストプロセスを除く）ＤＬ  ＨＡＲＱプロセスごとのＨＡＲＱ  ＲＴＴタイマ及び（ブロードキャストプロセスを除く）非同期ＵＬ  ＨＡＲＱプロセス当たりのＵＬ  ＨＡＲＱ  ＲＴＴタイマも定義される（７．７節参照）。
ＤＲＸサイクルが設定されるとき、アクティブ時間は次の時間を含む：
−  onDurationTimer、drx-InactivityTimer、drx-RetransmissionTimer、drx-ULRetransmissionTimer、又はmac-ContentionResolutionTimer（５．１．５項に記載）が実行中
−  スケジューリング要求がＰＵＣＣＨで送信され、保留中（５．４．４項に記載）
−  保留中のＨＡＲＱ再送信に対する上りリンクグラントが発生する可能性があり、同期ＨＡＲＱプロセスに対する対応するＨＡＲＱバッファにデータが存在、又は
−  ＭＡＣエンティティによって選択されていないプリアンブルに対するランダムアクセス応答を首尾よく受信した後で、ＭＡＣエンティティのＣ−ＲＮＴＩ宛ての新しい送信を示すＰＤＣＣＨが受信されていない（５．１．４項に記載）
ＤＲＸが設定されるとき、ＭＡＣエンティティは各サブフレームに対して次のことを行うものとする：
−  このサブフレームでＨＡＲＱ  ＲＴＴタイマが期限切れになった場合：
−  対応するＨＡＲＱプロセスのデータが首尾よく復号されなかった場合：
−  対応するＨＡＲＱプロセスに対するdrx-RetransmissionTimerを開始する。
−  ＮＢ−ＩｏＴの場合、drx-InactivityTimerを開始、又は再開(restart)する。
−  このサブフレームでＵＬ  ＨＡＲＱ  ＲＴＴタイマが期限切れになった場合：
−  対応するＨＡＲＱプロセスに対してdrx-ULRetransmissionTimerを開始する。
−  ＮＢ−ＩｏＴの場合、drx-InactivityTimerを開始、又は再開する。
−  ＤＲＸコマンドＭＡＣ制御要素又はロングＤＲＸコマンドＭＡＣ制御要素が受信された場合：
−  onDurationTimerを停止する。
−  drx-InactivityTimerを停止する。
−  このサブフレームでdrx-InactivityTimerが期限切れになった、又はＤＲＸコマンドＭＡＣ制御要素が受信された場合：
−  short  DRX  cycleが設定される場合：
−  drxShortCycleTimerを開始、又は再開する。
−  short  DRX  cycleを使用する。
−  それ以外：
−  Long  DRX  cycleを使用する。
−  このサブフレームでdrxShortCycleTimerが期限切れになった場合：
−  Long  DRX  cycleを使用する。
−  ロングＤＲＸコマンドＭＡＣ制御要素が受信された場合：
−  drxShortCycleTimerを停止し、
Long  DRX  cycleを使用する。
−  Short  DRX  Cycleが使用され、[(SFN  *  10)+サブフレーム番号]modulo(shortDRX-Cycle)
= （drxStartOffset）modulo（shortDRX-Cycle）の場合、又は
−  long  DRX  Cycleが使用され、[(SFN  *  10)+サブフレーム番号]modulo(longDRX-Cycle)
= drxStartOffsetの場合：
−  onDurationTimerを開始する。
−  アクティブ時間中、ＰＤＣＣＨサブフレームに対して、サブフレームが半二重ＦＤＤ  ＵＥ動作のための上りリンク送信に必要ではない場合、サブフレームが半二重ガードサブフレーム［７］ではない場合、サブフレームが設定された測定ギャップの一部ではない場合、サブフレームが受信のための設定されたサイドリンクディスカバリギャップの一部ではない場合、及びＮＢ−ＩｏＴに対して、サブフレームがＰＤＣＣＨ以外で上りリンク送信又は下りリンク受信に必要ではない場合、
−  アクティブ時間中、ＰＤＣＣＨサブフレーム以外のサブフレームに対して、及び集約セル内で同時に受信及び送信が可能なＵＥに対して、サブフレームがschedulingCellId[8]で設定されていない少なくとも１つのサービングセルに対する有効なｅＩＭＴＡ  Ｌ１シグナリングによって示される下りリンクサブフレームである場合、サブフレームが設定された測定ギャップの一部ではない場合、及びサブフレームが受信のための設定されたサイドリンクディスカバリギャップの一部でもない場合、又は
−  アクティブ時間中、ＰＤＣＣＨサブフレーム以外のサブフレームに対して、及び集約セル内で同時に受信及び送信することができないＵＥに対して、サブフレームがＳｐＣｅｌｌに対する有効なｅＩＭＴＡ  Ｌ１シグナリングによって示される下りリンクサブフレームである場合、サブフレームが設定された測定ギャップの一部ではない場合、サブフレームが受信のための設定されたサイドリンクディスカバリギャップの一部ではない場合：
−  ＰＤＣＣＨを監視する。
−  ＰＤＣＣＨがＤＬ送信を示す場合、又はこのサブフレームに対してＤＬ割り当てが設定された場合：
−  ＵＥがＮＢ−ＩｏＴ  ＵＥ、ＢＬ  ＵＥ、又は拡張カバレッジのＵＥの場合
−  対応するＰＤＳＣＨ受信の最後の繰り返しを含むサブフレーム内の対応するＨＡＲＱプロセスのためのＨＡＲＱ  ＲＴＴタイマを開始する。
−  それ以外：
−  対応するＨＡＲＱプロセスのためのＨＡＲＱ  ＲＴＴタイマを開始する。
−  対応するＨＡＲＱプロセスのためのdrx-RetransmissionTimerを停止する。
−  ＰＤＣＣＨが非同期ＨＡＲＱプロセスのためのＵＬ送信を示す場合：
−  対応するＰＵＳＣＨ送信の最後の繰り返しを含むサブフレーム内の対応するＨＡＲＱプロセスのためのＵＬ  ＨＡＲＱ  ＲＴＴタイマを開始する。
−  対応するＨＡＲＱプロセスのためのdrx-ULRetransmissionTimerを停止する。
−  ＰＤＣＣＨが新しい送信（ＤＬ、ＵＬ、又はＳＬ）を示す場合：
−  ＮＢ−ＩｏＴの場合を除き、drx-InactivityTimerを開始又は再開する。
−  ＰＤＣＣＨがＮＢ−ＩｏＴ  ＵＥのための送信（ＤＬ、ＵＬ）を示す場合：
−  drx-InactivityTimer、drx-ULRetransmissionTimer、及びonDurationTimerを停止する。
−  現在のサブフレームｎにおいて、この節で指定されるすべてのＤＲＸアクティブ時間条件を評価するとき、サブフレームｎ−５を含み、それまでに受信されたグラント／割り当て／ＤＲＸコマンドＭＡＣ制御要素／ロングＤＲＸコマンドＭＡＣ制御要素、及び送信されたスケジューリング要求を考慮してＭＡＣエンティティがアクティブ時間にない場合、タイプ０トリガのＳＲＳ［２］は報告されないものとする。
−  ＣＱＩマスキング（cqi-Mask）が上位レイヤによって設定される場合：
−  現在のサブフレームｎにおいて、この節で指定されるすべてのＤＲＸアクティブ時間条件を評価するとき、サブフレームｎ−５を含み、それまでに受信されたグラント／割り当て／ＤＲＸコマンドＭＡＣ制御要素／ロングＤＲＸコマンドＭＡＣ制御要素を考慮してonDurationTimerが実行中とならない場合、ＰＵＣＣＨでのＣＱＩ／ＰＭＩ／ＲＩ／ＰＴＩ／ＣＲＩは報告されないものとする。
−  それ以外：
−  現在のサブフレームｎにおいて、この節で指定されるすべてのＤＲＸアクティブ時間条件を評価するとき、サブフレームｎ−５を含み、それまでに受信されたグラント／割り当て／ＤＲＸコマンドＭＡＣ制御要素／ロングＤＲＸコマンドＭＡＣ制御要素及び送信されたスケジューリング要求を考慮してＭＡＣエンティティがアクティブ時間にない場合、ＰＵＣＣＨでのＣＱＩ／ＰＭＩ／ＲＩ／ＰＴＩ／ＣＲＩは報告されないものとする。
ＭＡＣエンティティがＰＤＣＣＨを監視しているかどうかにかかわらず、ＭＡＣエンティティはＨＡＲＱフィードバックを送信及び受信し、そのようなことが期待されるときはタイプ１トリガＳＲＳ［２］を送信する。
注：同じアクティブ時間が、アクティブにされているすべてのサービングセルに適用される。
注：下りリンク空間多重化の場合、ＨＡＲＱ  ＲＴＴタイマの実行中にＴＢが受信され、同じＴＢの以前の送信が現在のサブフレームの少なくともＮサブフレーム前に受信された場合（ＮはＨＡＲＱ  ＲＴＴタイマに対応する）、ＭＡＣエンティティはそれを処理し、ＨＡＲＱ  ＲＴＴタイマを再開すべきである。
注：ＢＬ  ＵＥと拡張カバレッジのＵＥは、設定されたＭＰＤＣＣＨサーチスペースの最後のサブフレームまで待機してから、次に指定されたアクションを実行する。
【誤訳訂正２】
【訂正対象書類名】明細書
【訂正対象項目名】００４３
【訂正方法】変更
【訂正の内容】
【００４３】
ＫＴ  ５Ｇ  ＭＡＣ仕様でのビーム管理及びＤＲＸは、ＴＳ  ５Ｇ．３２１において次のように説明される。
５．５  ビーム管理
５．５．１  ビームフィードバック手順
ビームフィードバック手順は、ビーム測定結果をサービングセルに報告するために使用される。
２つのビームフィードバック手順が定義され、１つは、以下のビーム参照信号（ＢＲＳ）の測定に基づく、以下のビーム状態情報報告であり、１つは、ビームリファインメント参照信号（ＢＲＲＳ）の測定に基づく、以下のビームリファインメント情報報告である。
５．５．１．１．１  ビーム状態情報報告
ｘＰＤＣＣＨ命令によって開始されるＢＲＳベースのビーム状態情報（ＢＳＩ）報告は、対応するＤＣＩ［１］によってスケジュールされるように、ｘＰＵＣＣＨ／ｘＰＵＳＣＨでのＵＣＩを通じて送信される。イベントトリガＢＳＩ報告は、通常のＳＲ又は競合ベースのＲＡＣＨ手順を使用して、６．１．３．１１項で定義されるＢＳＩフィードバックＭＡＣ制御要素を通じて送信され、ＢＳＩはビームインデックス（ＢＩ）及びビーム参照信号受信電力（ＢＲＳＲＰ）からなる。ＢＳＩ報告は、サービングセルによって送信されるＢＲＳに基づく。
５．５．１．１．１  ｘＰＤＣＣＨ命令により開始されるＢＳＩ報告
ｘＰＤＣＣＨ命令によって開始されるＢＳＩ報告は、５Ｇの物理レイヤから得られる最新の測定結果に基づく。
−  サービングセルによってｘＰＵＣＣＨを介してＵＣＩを通じてＢＳＩ報告を要求するｘＰＤＣＣＨ命令がこのＴＴＩにおいて受信された場合：
−  サービングビームが最良のビームではなく、最良のビームのＢＲＳＲＰがサービングビームのＢＲＳＲＰよりも高い場合：
−    ［１］で定義されているように、ｘＰＵＣＣＨを介してスケジュールされたＵＣＩリソースで最良のビームをシグナリングするように５Ｇ物理レイヤに指示する。
−  それ以外：
−    ［１］で定義されているように、ｘＰＵＣＣＨを介してスケジュールされたＵＣＩリソースでサービングビームをシグナリングするように５Ｇ物理レイヤに指示する。
−  サービングセルによってｘＰＵＳＣＨを介してＵＣＩを通じてＢＳＩ報告を要求するｘＰＤＣＣＨ命令がこのＴＴＩにおいて受信された場合：
−  要求された報告に対するＢＳＩの数が１に等しい場合：
−  サービングビームが最良のビームではなく、最良のビームのＢＲＳＲＰがサービングビームのＢＲＳＲＰよりも高い場合：
−  ［１］で定義されているように、ｘＰＵＳＣＨを介してスケジュールされたＵＣＩリソースで最良のビームをシグナリングするように５Ｇ物理レイヤに指示する。
−  それ以外：
−  ［１］で定義されているように、ｘＰＵＳＣＨを介してスケジュールされたＵＣＩリソースでサービングビームをシグナリングするように５Ｇ物理レイヤに指示する。
−  要求されたＢＳＩ報告の数が１より大きい場合、及び
−  サービングビームが最良のビームではなく、最良のビームのＢＲＳＲＰがサービングビームのＢＲＳＲＰよりも高い場合：
−  ｘＰＵＳＣＨを介してスケジュールされたＵＣＩリソースでの最初のＢＳＩ及び次のＮ−１番目に高いＢＲＳＲＰビーム値として最良のビームを用いてＮ個のＢＳＩ報告をシグナリングするように５Ｇ物理レイヤに指示する。
−  それ以外：
−  ｘＰＵＳＣＨを介してスケジュールされたＵＣＩリソースでの最初のＢＳＩ及び次のＮ−１番目に高いＢＲＳＲＰビーム値としてサービングビームを用いてＮ個のＢＳＩ報告をシグナリングするように５Ｇ物理レイヤに指示する。
５．５．１．１．２  ５Ｇ−ＭＡＣによって開始されるＢＳＩ報告
５Ｇ−ＭＡＣによって開始されるＢＳＩ報告は、イベントトリガに基づく。
−  最良のビームのＢＲＳＲＰが、beamTriggeringRSRPoffset  ｄＢ＋サービングビームのＢＲＳＲＰより大きい場合、及び
−  ＵＥが上りリンク同期されている（すなわち、timeAlignmentTimerが期限切れになっていない）場合
−  ＵＥは、通常のＳＲ手順を通じてグラントされたＵＬリソースでＢＳＩフィードバックＭＡＣ制御要素を送信する。
−  それ以外：
−  ＵＥは、競合ベースのランダムアクセス手順を通じてグラントされたＭｓｇ３のためのＵＬリソースでＢＳＩフィードバックＭＡＣ制御要素を送信する。
５．５．１．２  ビームリファインメント情報報告
ビームリファインメント情報（ＢＲＩ）報告は、ｘＰＤＣＣＨ命令によって開始され、対応するＤＣＩ［１］によってスケジューリングされるｘＰＵＣＣＨ／ｘＰＵＳＣＨでのＵＣＩを通じて報告される。ＢＲＩは、サービングセルによって送信されるＢＲＲＳに基づいたリファインビームインデックス（ＲＢＩ）及びＢＲＳＲＰからなる。
−  サービングセルによってｘＰＵＣＣＨを介してＵＣＩを通じてＢＲＩ報告を要求するｘＰＤＣＣＨ命令が受信された場合：
−  ［１］で定義されているように、ｘＰＵＣＣＨを介してスケジュールされたＵＣＩリソースに関するＢＲＩ報告をシグナリングするように５Ｇ物理レイヤに指示する。
−  サービングセルによってｘＰＵＳＣＨを介してＵＣＩを通してＢＲＩ報告を要求するｘＰＤＣＣＨ命令が受信された場合：
−  ［１］で定義されているように、ｘＰＵＳＣＨを介してスケジュールされたＵＣＩリソースに関するＢＲＩ報告をシグナリングするように５Ｇ物理レイヤに指示する。
注：イベントトリガＢＲＩのフィードバックはサポートされない。
注：ｘＰＤＣＣＨ命令によって要求されるＢＳＩ／ＢＲＩフィードバックは、５Ｇ−ＭＡＣレイヤの報告手順には影響しない。
2018098783.tif 000001
2018098783.tif 000002
2018098783.tif 000003
2018098783.tif 000004
2018098783.tif 000005