3GPP TS 25.303 V3.9 - 株式会社QT RAT 間ハンドオーバ：UTRAN → GSM/BSS、 CS...

3GPP TS 25.303 V3.9.0 (2001-09)技術仕様書

3rd Generation Partnership Project;Technical Specification Group Radio Access Network;

Interlayer Procedures in Connected Mode(Release 1999)

The present document has been developed within the 3rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP. The present document has not been subject to any approval process by the 3GPP Organisational Partners and shall not be implemented. This Specification is provided for future development work within 3GPP only. The Organisational Partners accept no liability for any use of this Specification.Specifications and reports for implementation of the 3GPP TM system should be obtained via the 3GPP Organisational Partners' Publications Offices.

3GPP

3GPP TS 25.303 V3.9.0 (2001-09)2Release 1999

Keywords UMTS, radio

3GPP

Postal address

3GPP support office address 650 Route des Lucioles - Sophia Antipolis

Valbonne - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16

Internet http://www.3gpp.org

Copyright Notification

No part may be reproduced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in all media.

© 2001, 3GPP Organizational Partners (ARIB, CWTS, ETSI, T1, TTA,TTC).

All rights reserved.

3GPP

3GPP TS 25.303 V3.9.0 (2001-09)3Release 1999

Contents はじめに（Foreword）.....................................................................................................................................6 1 Scope ........................................................................................................................................................7 2 リファレンス（References） ................................................................................................................7

3 空き（Void）..........................................................................................................................................7

4 コネクトモード概説（General Description of Connected Mode） ....................................................8

5 無線ベアラの制御―処理手順の概要（Radio Bearer Control – Overview of Procedures） ............9 5.1 調整可能なパラメータ（Configurable parameters） .......................................................................................... 9 5.2 典型的なコンフィグレーションのケース（Typical configuration cases）..................................................... 9 5.3 RRC エレメンタリ処理手順（RRC Elementary Procedures）........................................................................ 10 5.3.1 カテゴリ 1：無線ベアラのコンフィグレーション（Category 1: Radio Bearer Configuration） .......... 10 5.3.2 カテゴリ 2：トランスポートチャネルのコンフィグレーション（Category 2: Transport Channel

Configuration） ......................................................................................................................................... 11 5.3.3 カテゴリ 3：物理チャネルのコンフィグレーション（Category 3: Physical Channel

Configuration） ......................................................................................................................................... 11 5.3.4 カテゴリ 4：TFC (Transport Format Combination)の規制（Category 4: Transport Format

Combination Restriction） ........................................................................................................................ 12 5.3.5 カテゴリ 5：CRNC における上りリンク個別チャネル制御（Category 5: Uplink Dedicated

Channel Control in CRNC） ..................................................................................................................... 12

6 処理の例（Examples of procedures） .................................................................................................12 6.1 RRC コネクションの確立と解放の処理手順（RRC Connection Establishment and Release

Procedures）.................................................................................................................................................... 12 6.1.1 RRC コネクションの確立（RRC connection establishment）.................................................................... 12 6.1.2 UE 側開始シグナリングコネクションの確立（ UE Initiated Signalling Connection

Establishment） ......................................................................................................................................... 15 6.1.3 正常な RRC コネクション解放（Normal RRC Connection Release） ..................................................... 16 6.1.3.1 個別物理チャネルからの RRC コネクションの解放（RRC Connection Release from Dedicated

Physical Channel） .............................................................................................................................. 17 6.1.3.2 個別物理チャネルなしの RRC コネクションの解放（RRC Connection Release without Dedicated

Physical Channel） .............................................................................................................................. 18 6.2 無線ベアラ制御手順（Radio Bearer Control Procedures） .............................................................................. 21 6.2.1 無線ベアラのコンフィグレーション（Radio Bearer Configuration） .................................................... 21 6.2.1.1 無線ベアラの確立（Radio Bearer Establishment） ..................................................................................... 21 6.2.1.1.1 個別物理チャネルの起動を伴う無線ベアラ確立（Radio Bearer Establishment with Dedicated

Physical Channel Activation） ....................................................................................................... 21 6.2.1.1.2 個別物理チャネルの非同期修正を伴う無線ベアラ確立（Radio Bearer Establishment with

Unsynchronised Dedicated Physical Channel Modification） ....................................................... 23 6.2.1.1.3 個別物理チャネルの同期修正を伴う無線ベアラ確立（Radio Bearer Establishment with

Synchronised Dedicated Physical Channel Modification） ........................................................... 24 6.2.1.1.4 個別物理チャネルなしの無線ベアラ確立（Radio Bearer Establishment without Dedicated

Physical Channel）......................................................................................................................... 26 6.2.1.1.5 CPCH チャネル割当てと同時の無線ベアラ確立（Radio Bearer Establishment with CPCH

Channel Allocation） ..................................................................................................................... 27 6.2.1.2 無線ベアラの解放（Radio Bearer Release） ............................................................................................... 29 6.2.1.2.1 非同期の個別物理チャネル修正を伴う無線ベアラの解放（Radio Bearer Release with

Unsynchronised Dedicated Physical Channel Modification） ....................................................... 29 6.2.1.3 無線ベアラの再コンフィグレーション（Radio Bearer Reconfiguration） .............................................. 31

3GPP

3GPP TS 25.303 V3.9.0 (2001-09)4Release 1999

6.2.1.3.1 非同期の無線ベアラの再コンフィグレーション（Unsynchronised Radio Bearer Reconfiguration）........................................................................................................................... 31

6.2.2 トランスポートチャネルの再コンフィグレーション（Transport Channel Reconfiguration）............. 33 6.2.2.1 非同期型 TFS の再コンフィグレーション（Unsynchronised Transport Format Set

Reconfiguration） ................................................................................................................................ 33 6.2.3 物理チャネルの再コンフィグレーション（Physical Channel Reconfiguration） .................................. 35 6.2.3.1 UE 発の DCH 活性化（UE-Originated DCH Activation） .......................................................................... 35 6.2.3.2 UE 着の同期型 DCH の修正（UE-terminated synchronised DCH Modify） ............................................. 37 6.2.3.3 UE 着の DCH 解放（UE-terminated DCH Release） ................................................................................... 38 6.2.4 TFC の制御（Transport Format Combination Control）.............................................................................. 40 6.2.4.1 TFC の規制（Transport Format Combination Limitation） ......................................................................... 40 6.2.5 上りリンク DCH の動的リソース割当て（Dynamic Resource Allocation Control of Uplink

DCHs）...................................................................................................................................................... 41 6.2.6 上りリンク DCH の可変レート送信（Variable Rate Transmission of Uplink DCHs） ........................... 43 6.3 データ送信（Data transmission） ...................................................................................................................... 45 6.3.1 DSCH 上のアクノリッジモードのデータ送信、TFCI ワードの物理分割（Acknowledged-mode

data transmission on DSCH using hard split of TFCI-word）................................................................... 45 6.3.2 DSCH 上でのアクノリッジモードのデータ送信、TFCI ワードの論理分割（Acknowledged-

mode data transmission on DSCH using logical split of TFCI-word） ..................................................... 46 6.3.3 CPCH 上のデータ送信（Data transmission on CPCH） ............................................................................. 48 6.3.4 USCH 上のデータ送信（TDD のみ）（Data transfer on USCH (TDD only)） ....................................... 51 6.3.5 DSCH 上のデータ送信（TDD のみ）（Data transfer on DSCH (TDD only)） ....................................... 52 6.4 RRC コネクションのモビリティ処理手順（RRC Connection mobility procedures）.................................. 53 6.4.1 ハンドオーバ測定レポート（Handover Measurement Reporting） .......................................................... 54 6.4.2 セルの更新（Cell Update） .......................................................................................................................... 54 6.4.3 URA の更新（URA Update） ....................................................................................................................... 56 6.4.4 無線リンクの追加（FDD）（Radio Link Addition）................................................................................. 59 6.4.5 無線リンクの削除(FDD)（Radio Link Removal）...................................................................................... 59 6.4.6 無線リンクの追加と削除の組合せ（Combined radio link addition and removal） ................................. 61 6.4.7 ハードハンドオーバ（FDD と TDD）(Hard Handover ) ........................................................................... 62 6.4.8 SRNS 再配置 (SRNS Relocation)................................................................................................................... 63 6.4.8.1 Cell/URA 更新と SRNS 再配置の組合せ（ロス無し無線ベアラ）(Combined Cell/URA Update

and SRNS relocation (lossless radio bearers))...................................................................................... 63 6.4.8.2 ハードハンドオーバと SRNS 再配置の組合せ（ロス無し無線ベアラ）(Combined Hard

Handover and SRNS relocation (lossless radio bearers)) ..................................................................... 66 6.4.8.3 Cell/URA 更新と SRNS 再配置の組合せ（シームレス無線ベアラ）(Combined Cell/URA Update

and SRNS relocation (seamless radio bearers)).................................................................................... 68 6.4.8.4 Combined Hard Handover and SRNS relocation (seamless radio bearers) ..................................................... 70 6.4.9 RRC コネクションの再確立（RRC Connection re-establishment） .......................................................... 72 6.4.10 システム間ハンドオーバ：GSM/BSS → UTRAN （Inter-system Handover: GSM/BSS to

UTRAN） .................................................................................................................................................. 73 6.4.11 RAT 間ハンドオーバ：UTRAN → GSM/BSS、 CS ドメインのサービス Inter-RAT Handover:

UTRAN to GSM/BSS, CS domain services............................................................................................... 75 6.5 コネクトモードにおける、CN 発のページング要求（CN originated paging request in connected

mode） ............................................................................................................................................................ 77 6.5.1 DCCH を使用した UTRAN 調和型ページング（UTRAN coordinated paging using DCCH）............... 77 6.6 UTRAN 発のページング要求とページング応答（UTRAN originated paging request and paging

response） ....................................................................................................................................................... 79 6.7 その他の処理（Other procedures）.................................................................................................................... 80 6.7.1 UE のケーパビリティ情報（UE Capability Information）......................................................................... 80 6.7.2 ランダムアクセス送信シーケンス（FDD）（Random access transmission sequence (FDD)） ............ 81 6.7.3 ランダムアクセス送信シーケンス（TDD）（Random access transmission sequence (TDD)）............ 82 6.7.4 CPCH の緊急停止シーケンス（CPCH Emergency Stop sequence） ......................................................... 83

3GPP

3GPP TS 25.303 V3.9.0 (2001-09)5Release 1999

7 トラフィック量のモニタ（Traffic volume monitoring） ................................................................84

付録 A(informative): 改版履歴（Change history） ...................................................................................85

3GPP

3GPP TS 25.303 V3.9.0 (2001-09)6Release 1999

はじめに（Foreword）本書の内容は現在進行している TSG 作業に従って次の TSG 承認により変更される事がある。TSG が本書の

内容を変更する場合には、リリース日とバージョン番号が以下の規則に従って変更され TSG から再リリー

スされる。

バージョン x.y.z

x [主バージョン番号] を示す。

1 TSG への初期提出向けに作成された。

2 TSG への承認向けに作成された。

3 以上指定個所の変更を条件に TSG に承認された。

y 本質的な部分 (機能拡張、修正、または更新など) を変更した場合に更新される。

z 誤字・脱字など編集上の変更が仕様書に反映されたときに更新される。

3GPP

3GPP TS 25.303 V3.9.0 (2001-09)7Release 1999

1 Scope 本書は、無線リソースの割当て、再構成、および解放に関する全ての処理手順（procedure）について説明し

たものである。本書の内容には、例えば異なるステートまたはサブステート間の移行処理、ハンドオーバと

測定レポートなどが含まれる。本書で重点を置いた点としては、peer-to-peer メッセージとレイヤ間プリミィ

ティブの両方を組合せて使用した場合の、レイヤ間の機能的分離をイラスト化する事にある。これには、い

くつかの例をとりエレメンタリ手順の組合せとして表している。peer-to-peer の基本手順の詳細は、関連する

プロトコル解説仕様書[1, 2, 3]に譲り、本書の範囲ではない。

本書内のレイヤ間処理手順は informative である。

2 リファレンス（References）以下の文書は、本書の参照にもなっていて、本書の条項を構成する条項を含む。

• リファレンスには、特定 (作成日、改訂番号、およびバージョン番号で識別できる) と非特定がある。

• 特定のリファレンスの場合、表記されたバージョン以降は使用できない。

• 非特定のリファレンスの場合、最新のバージョンを使用する。GSM ドキュメントを含む 3GPP ドキュ

メントへの参照の場合、バージョンの指定がない参照は、本ドキュメントと同じリリースにおける最

新バージョンを参照する事とする。

[1] 3GPP TS 25.321: "MAC Protocol Specification".

[2] 3GPP TS 25.322: "RLC Protocol Specification".

[3] 3GPP TS 25.331: "RRC Protocol Specification".

[4] 3GPP TS 25.304: "UE Procedures in Idle Mode and Procedures for Cell Reselection in Connected Mode".

[5] 3GPP TS 25.301: "Radio Interface Protocol Architecture".

[6] 3GPP TS 23.060: "General Packet Radio Service (GPRS) Service description, Stage 2".

[7] 3GPP TS 25.323: "PDCP Protocol Specification".

3 空き（Void）

3GPP

3GPP TS 25.303 V3.9.0 (2001-09)8Release 1999

4 コネクトモード概説（General Description of Connected Mode）

RRC コネクションが確立されるとコネクトモードに入る。UE に対して RNTI（radio network temporary identity）が割当てられ、これが共通トランスポートチャネル上で UE を識別するために使用される。RNTIは 2 種類存在する。１つは、SRNC(サービング RNC)が自分と RRC コネクションを持つ全ての UE に対して

割当てる s-RNTI で、s-RNTI と RNC-ID の組合せは PLMN 内で一意である。もう１つは各 CRNC(Controlling RNC)が UE に対して割当てる c-RNTI である。UE は c-RNTI を経由して、DCCH 上で CRNC と通信すること

ができる。新規の UE コンテキストが発生するたびに、UTRAN は UE に対して c-RNTI を割当てるが、UEが c-RNTI を必要とするのは共通トランスポートチャネル上で通信を行う場合だけである。

RRC コネクションが解放された場合、もしくは RRC コネクションが失敗した場合には、UE はコネクトモー

ドからアイドルモードに戻る。

コネクトモードにおいて、UE の UTRAN に対するコネクションのレベルは、アクティブな無線ベアラ

（Radio Bearer）の QoS(Quality of Service)要求条件と、それらのベアラ上のトラフィックの特性によって決

まる。

UE と UTRAN 間のインタフェースは、パケットデータを使用する多数の UE をサポートできるように、フ

レキシブルな手段を提供して統計的多重を利用するように設計されているが、エアインタフェースの容量、

UE の消費電力、ネットワークのハードウエア能力などの制限により、個別リソースを全パケットサービス

ユーザに常に割当てることはできない。

可変レート送信は、可変レートサービスに対して、最大許容送信出力に従ってデータレートを調整する手段

を提供する。

コネクトモードにおける UE のステートは、UE に関連するアクティビティのレベルを定義する。各ステー

トのキーパラメータは、ステート内で要求されるアクティビティとリソース、およびデータ送信に先立って

必要なシグナリングである。UE のステートは少なくとも、アプリケーションの要求条件とインアクティビ

ティの期間に依存するべきである。

UE は、CPCH（Common Packet Channel）の上りリンクのリソースを、RACH に似たアクセスプロトコルに

より使用することができる。CPCH のリソースは、セルに割当られている競合ベースの共有 CPCH のチャネ

ルの１セットを用いた、多数の UE の上りリンクのパケット通信をサポートする。

UTRAN に対する UE のコネクションのレベルを、以下にリストアップする。

- シグナリングコネクションが存在しない場合 UE がアイドルモードにあり、UTRAN とは関係を持たず、CN とのみ関係する場合。データ伝送を行

うためにはシグナリングコネクションを確立する必要がある。

- シグナリングコネクションが存在する場合少なくとも 1 つのシグナリングコネクションが存在する場合には、UE はコネクトモードにあり、通

常は UE と UTRAN の間にコネクションが存在する。UE の位置はいくつかの異なるレベルで把握され

ている。

- URA（UTRAN Registration Area）レベル UE の位置は URA 単位で把握されている。URA とはセルのセットを指す。

- セルレベル（Cell level） UE の位置はセル単位で把握されている。データ伝送用に、異なるタイプのトランスポートチャネ

ルを使用できる。

- 共通トランスポートチャネル（RACH / FACH, DSCH, CPCH）レベル

- 個別トランスポートチャネル（Dedicated transport channels）レベル

3GPP

3GPP TS 25.303 V3.9.0 (2001-09)9Release 1999

RRC コネクションが存在すると仮定すると、2 種類の基本的な RRC コネクションのモビリティ手順が存在

する。すなわち、URA の更新とハンドオーバである。UE のコネクションのレベルが異なる（セルレベルと

URA レベル）場合には、異なる種類の RRC コネクションのモビリティ手順が使用される。

- URA の更新は、RRC コネクションが存在し、かつ UE の位置が UTRAN 内で URA レベルで把握され

ている場合に、UE の URA を更新する一連の手順である。

- ハンドオーバは、RRC コネクションが存在し、かつ UE の位置が UTRAN 内でセルレベルで把握され

ている場合に、UE と UTRAN 間で、1 つもしくは複数の無線リンクを追加・削除する一連の手順であ

る。

5 無線ベアラの制御―処理手順の概要（Radio Bearer Control – Overview of Procedures）

5.1 調整可能なパラメータ（Configurable parameters）以下の L1、MAC、および RLC パラメータは、RRC が調整できること。本リストは完全ではない。

- 無線ベアラパラメータ。例えば、

- RLC リンク（無線ベアラ）ごとの RLC パラメータ。例えば PDU のサイズやタイムアウトの値な

どが含まれる。RLC が使用。

- DCCH/DTCH 単位の多重優先度。MAC が論理チャネルを多重化する場合に MAC が使用。

- トランスポートチャネルパラメータ。例えば、

- トランスポートチャネル単位のスケジューリング優先度。L1 でトランスポートチャネルを多重化

する場合に、MAC が使用。

- トランスポートチャネル単位の TFS（Transport format set）。MAC および L1 が使用。

- UE 単位の TFCS（Transport format combination set）。MAC および L1 が使用。

- UE 単位で許容された TFCS のサブセット。MAC が使用。

- CPCH 単位の CPCH アクセスパラメータ。 MAC および L1 が使用。

- 物理チャネルパラメータ。例えばキャリア周波数やコードなどが含まれる。L1 が使用。

5.2 典型的なコンフィグレーションのケース（Typical configuration cases）

下表は、どのパラメータが（1 回の処理で）同時にコンフィグレーションできるかという観点から作成した、

サポートすべきパラメータコンフィグレーションの主な組合せのプロポーザルである。その意味では「トラ

ンスポートチャネルタイプの切替」（"Transport channel type switching"）はパラメータではないが、該当す

るコンビネーションのケースではトランスポートチャネルタイプの切替が起こりうることを示したものであ

ることに注意。

3GPP

3GPP TS 25.303 V3.9.0 (2001-09)10Release 1999

表 1: 典型的なコンフィグレーションのケース "X" は、そのパラメータが（たとえ必要がなくても）コンフィグレーション可能であることを示す。

Parameter Layer A B C D E F Radio bearer parameters

RLC parameters RLC X

Logical channel multiplexing priority

MAC X

Transport channel parameters

Transport channel scheduling priority

MAC X

TFS L1+MAC X X TFCS L1+MAC X X Subset of TFCS MAC X X Transport channel

type switching MAC X X X

Physical channel parameters L1 X X X X

ケース A は通常無線ベアラが確立または解放された場合、または既存無線ベアラの QoS を変更する必要が

生じた場合。

ケース B は、無線ベアラのトラフィック量が変動した結果、DCH 上で使用される TFS を変更する必要が生

じて、物理チャネルの割当てセットのいずれかに影響を与える場合。他の例としては、UE に新しいトラン

スポートチャネルを使用させて、同時に該当チャネル用の TFS を提供する場合。

ケース C は、無線ベアラのトラフィック量が変動した結果、使用するトランスポートチャネルのタイプが変

更される場合。例えば、CELL_FACH から CELL_DCH へ、または UE に割当てられた CPCH のセットが切

替えられた場合など。このケースは、物理チャネルのセットの割当てまたは解放を含む。

ケース D は、例えば DCH を使用中に、使用中の下りリンクチャネライゼーションコードが変更された場合

など。トランスポートチャネルのタイプの切替は実行されない。

ケース E は、UE が使用する TFCS（合計上りリンクレート）の使用の一時的な規制および／または解

放。

ケース F は、送信確率や最大ビットレートなどのブロードキャストキャスト情報を使用して、CRNC 内で上

りリンク DCH のリソースの動的割当てを行う際に使用される。

5.3 RRC エレメンタリ処理手順（RRC Elementary Procedures）

5.3.1 カテゴリ 1：無線ベアラのコンフィグレーション（Category 1: Radio Bearer Configuration）

処理の最初のカテゴリにはケース A が含まれ、以下のような特徴を持つ。

- 上位レイヤの要求に基づいてコンフィグレーションが実行され、パラメータのコンフィグレーション

は QoS に基づく。

- L1, MAC 、および RLC に対して影響を及ぼす。

本カテゴリには、以下の 3 つの RRC 処理が含まれる。

- 無線ベアラの確立（Radio Bearer Establishment）：新しい無線ベアラを確立する処理。確立は QoS に

基づいて行われ、RLC パラメータの割当て、DTCH の多重優先度、CPCH セットの割当て、DCH のス

ケジュール優先度、DCH 用の TFS および TFCS の更新が含まれる。物理チャネルの割当て、使用中の

トランスポートチャネルのタイプ／RRC ステートの変更を含むこともある。

3GPP

3GPP TS 25.303 V3.9.0 (2001-09)11Release 1999

- 無線ベアラの解放（Radio Bearer Release）：無線ベアラを解放する処理。無線ベアラ用の RLC エン

ティティは解放される。本処理で DCH を解放することもできる。この場合は TFCS に影響を与える。

物理チャネルの解放と、使用中のトランスポートチャネルのタイプ／RRC ステートの変更を含むこと

もある。

- 無線ベアラの再コンフィグレーション（Radio Bearer Reconfiguration）：本処理は、無線ベアラ

（例：シグナルリンク）のパラメータを再コンフィグレーションし、QoS の変更に反映する。RLC パ

ラメータの変更、DTCH/DCCH の多重優先度の変更、CPCH セットの割当て、DCH スケジューリング

優先度の変更、DCH 用の TFS の変更、TFCS の変更、物理チャネルの割当てまたは解放、および使用

中のトランスポートチャネルのタイプの変更を含むこともある。

5.3.2 カテゴリ 2：トランスポートチャネルのコンフィグレーション（Category 2: Transport Channel Configuration）

処理の第 2 のカテゴリにはケース B が含まれ、以下のような特徴を持つ。

- トランスポートチャネル用の TFS のコンフィグレーションと、TFCS の再コンフィグレーションが実

行されるが、物理チャネルのパラメータが含まれることもある。

- L1 および MAC に影響を与える。

- 使用中のトランスポートチャネルの切替を実行することもできる。

本カテゴリには、1 種類の RRC 処理が含まれる。

- トランスポートチャネルの再コンフィグレーション（Transport Channel Reconfiguration）: 本処理は、

TFS などのトランスポートチャネルに関連するパラメータの再コンフィグレーションを行う。本処理

は、TFCS を割当てて、物理チャネルのパラメータを変更することもできる。その場合には、使用す

る物理チャネルの再コンフィグレーションに反映される。

注: TFS/TFCS のコンフィグレーションは、物理チャネルの割当てよりも必要性が低いと想定され

る。本処理は、未使用のトランスポートチャネル用 TFS/TFCS の「プレコンフィグレーショ

ン」（"pre-configuration"）を実行しない。「プレコンフィグレーション」は、物理チャネルが

割当てられたとき、トランスポートチャネルタイプが切替えられた後に使用される。

5.3.3 カテゴリ 3：物理チャネルのコンフィグレーション（Category 3: Physical Channel Configuration）

処理の第 3 のカテゴリにはケース C およびケース D が含まれ、以下のような特徴を持つ。

- UE 用の物理チャネルの割当てと解放を行うことができる（トランスポートチャネルタイプの切替を

伴うこともある）。

- 使用中の物理チャネルの組合せの解放と割当て（置換）を行うことができる（その結果、トランスポ

ートチャネルの切替／RRC ステートの変更が起こることはない）

- 主として L1 と、MAC のトランスポートチャネルタイプの切替部分にだけ影響を与える。

- このタイプの処理では、TFS（TFS と TFCS）は割当てられない。しかし、既に UE に対して TFS が割

当てられているトランスポートチャネルは、UE に指示を与えることができる。

本カテゴリには、1 種類の RRC 処理が含まれる。

- 物理チャネルの再コンフィグレーション（Physical Channel Reconfiguration）: 本処理は、UE が使用

する物理チャネルのセットの割当て、置換、および解放を行うことができる。本処理の結果、使用さ

れるトランスポートチャネルタイプ（RRC ステート）が変更されることもある。例えば、UE に最初

の物理チャネルが割当てられると、UE は DCH/DCH ステートに入る。また、UE に割当てられた最後

3GPP

3GPP TS 25.303 V3.9.0 (2001-09)12Release 1999

の物理チャネルが解放されると、UE は CELL_DCH ステートを離れて、ネットワークが指示したステ

ート（およびトランスポートチャネルのタイプ）に入る。本処理が使用される特別なケースとしては、

個別物理チャネルの下りリンクのチャネライゼーションコードを変更する場合がある。

注: 本処理によってアクティブセットが変更されることはない。下りリンクでは、各無線リンクに

対して、同一数の物理チャネルが追加または置換される。

5.3.4 カテゴリ 4：TFC (Transport Format Combination)の規制（Category 4: Transport Format Combination Restriction）

処理の第 4 のカテゴリにはケース E が含まれ、以下のような特徴をもつ。

- セット内で使用することができる TFC を使用することによって、L1 に影響を与えずに MAC レイヤだ

けを制御する。

本カテゴリには 1 種類の RRC 処理が含まれる。

- TFC の制御（Transport format combination control）: ネットワークは本処理を UE に対して適用し、

上りリンクで使用される TFC が TFCS の範囲内になるように制御する。

5.3.5 カテゴリ 5：CRNC における上りリンク個別チャネル制御（Category 5: Uplink Dedicated Channel Control in CRNC）

処理の第 5 のカテゴリにはケース F が含まれ、以下のような特徴をもつ。

- 送信確率と上りリンクの DCH で使用すべき最大総ビットレートをブロードキャストすることによっ

て、UE MAC を制御する。上りリンクの DCH は、本処理の管理下にある。

本カテゴリには 1 種類の RRC 処理が含まれる。

- 上りリンク DCH の動的リソース割当て制御（Dynamic Resource Allocation Control of Uplink DCHs）: ネットワークは UE に対して本処理を適用し、伝送確率と上りリンクの DCH で使用すべき

最大総ビットレートを制御する。上りリンクの DCH は、本処理の管理下にある。

6 処理の例（Examples of procedures）これらのシーケンスは例であり、全ての異なるシナリオの包括的な組合せを網羅したものではない。

与えられたメッセージ用の論理チャネルおよび／またはトランスポートチャネルが既知の場合には、メ

ッセージ名称の前にそれを記載（Logical_Ch: Transport_Ch: Message）する。例えば、DCCH:RACH など。ア

クノリッジデータ（Acknowledged Data）は、RACH 上にマッピングされる DCCH 上のデータメッセージを

示す。メッセージに対する論理チャネルおよび／またはトランスポートチャネルが明示されない場合に

は、それらは省略できる。

6.1 RRC コネクションの確立と解放の処理手順（RRC Connection Establishment and Release Procedures）

6.1.1 RRC コネクションの確立（RRC connection establishment）図 1 に、RRC コネクション確立 ([5]参照)の処理手順を示す（共通チャネル用のプロトコル終端は、前述のケース A に従って示され、比較のためにケース C を付録 A 中で示す）。UE の RRC レイヤは、アイドルモ

3GPP

3GPP TS 25.303 V3.9.0 (2001-09)13Release 1999

ードを離れて、RRC コネクションが確立されたことを MAC SAP を使用して RRC Connection Request メッセ

ージを送信して CCCH 論理チャネルに通知する。MAC は RACH トランスポートチャネル上で L3 のメッセ

ージを送信する。

ネットワーク側では、RRC Connection Request を受信すると、RRC レイヤがアドミッション制御を実行し、

RRC コネクション用に s-RNTI を割当てて無線リソースパラメータ（トランスポートチャネルタイプ、TFSなど）を選択する。DCH を確立する必要がある場合には、チャネルの確立に関連する全ての Node B に対し

て、CPHY-RL-Setup および CPHY-TrCH-Config 要求(request)プリミィティブ（1 つの RADIO LINK SETUP PDU として送信される）が送信される。物理レイヤのオペレーションが開始され、各 Node B から確認プリ

ミィティブ（confirmation primitive）が返される。RRC は、L2 上でパラメータをコンフィグレーションして、

DCCH 論理チャネルをローカルに確立する。RNTI を含む選択されたパラメータは、CCCH 論理チャネル用

の MAC SAP を使用して、RRC Connection Setup メッセージに入れられて UE に送信される。

UE の RRC レイヤは RRC Connection Setup メッセージを受信すると、これらのパラメータを使用して、L1 と

L2 をコンフィグレーションして DCCH 論理チャネルをローカルに確立する。DCH の場合、L1 の同期が確立

された時に、RRC に対して通知する。

RLC シグナルリンクは、ネットワークと UE の双方でローカルに確立される。（リンクの）確立は、MACによって、RACH / FACH または DCH のいずれかの上でマッピングすることができる。UE が RLC シグナル

リンクを確立した場合には、DCCH 上でアクノリッジモードを使用して、RRC Connection Setup Complete メッセージをネットワークに送信する。

3GPP

3GPP TS 25.303 V3.9.0 (2001-09)14Release 1999

CPHY-RL-Setup-REQ (only if DCH)


CCCH: MAC-Unit-Data-IND

[RRC Connection Request]

UE-RRC UE-RLC UE-MAC UE-L1 Node B-L1 RNC-L1 SRNC-MAC SRNC-RLC SRNC-RRC

Uu Iub

CCCH: MAC-Unit-Data-REQ


RACH: CCCH Data


Admission control &radio resource

allocation

Start tx/rx

CPHY-RL-Setup-CNF (only if DCH)

CCCH: MAC-Unit-Data-REQ

[RRC Connection Setup]

FACH: CCCH Data


CCCH: MAC-Unit-Data-IND


CMAC-C / SH / D-Config-REQ

CRLC-Config-REQ

Start tx/rx

L1 synchronisation (DCH)

CPHY-Sync-IND (only if DCH)CPHY-Sync-IND (only if DCH)

CRNC-MAC


CMAC-C/SH-Config-REQ

CMAC-D-Config-REQ

CPHY-TrCH-Config-REQ (only if DCH)


CRLC-Config-REQ

L2 link establishment

L2 link establishment

RLC-Data-REQ

[RRC Connection Setup Complete] DCCH: Acknowledged Data

[RRC Connection Setup Complete]

RLC-Data-CNF

RLC-Data-IND

[RRC Connection SetupComplete]

DCCH: Data ack

CPHY-TrCH-Config-CNF (only if DCH)


図 1: 共通チャネルの終端と RRC コネクションの確立（ケース A）

3GPP

3GPP TS 25.303 V3.9.0 (2001-09)15Release 1999

6.1.2 UE 側開始シグナリングコネクションの確立（ UE Initiated Signalling Connection Establishment）

注 1: RRC Connection Establishment 時に、追加の UE capability information が必要な場合、それは RRC Connection Setup Complete メッセージ中で送信される。

図 2 に、UE 側から開始された UE 用の最初の Signalling Connection の確立シーケンスを示す。

UE 内の非アクセス層は、DC(Dedicated Contorol) SAP 上のプリミィティブを使用して、RRC Signalling Connection Establishment を要求する。プリミィティブには初期メッセージが含まれ、それらは RRC によって

ネットワーク側の非アクセス層エンティティに透過的に伝送される。

注 2: 初期 NAS メッセージは、GSM ベースのコアネットワーク用のメッセージであってもよい。例

えば、CM Service Request, Location Update Request 等。

RRC コネクションが存在しない場合、RRC レイヤは RRC コネクションを確立する。これには UE の capability information の送信も含まれる。RRC コネクションの確立が完了すれば、シグナリングコネクショ

ンの確立も再開できる。

NAS からの初期メッセージは、DCCH 上でアクノリッジモードを使用して、RRC メッセージ "Initial Direct Transfer" 内でネットワークに送信される。RRC メッセージは、ネットワークでは DC-SAP 上で RRC Signalling Connection Establish IND メッセージといっしょに渡される。

UE-RRC が UE-RLC に INITIAL DIRECT TRANSFER メッセージ送信の要求が済んだ時、Signalling Connection Establishment が UE-RRC によって確認される。

UE-RRC UE-RLC SRNC-RLC SRNC-RRC

Uu Iub

RRC SignallingConnection

EstablishmentRequested

RRC Connection Establishment

RLC-Data-REQ

DCCH: Acknowledged Data

INITIAL DIRECT TRANSFER RLC-Data-INDConfirm RRC

SignallingConnection

EstablishmentIndicate RRC

SignallingConnection

EstablishmentDCCH: Data ack

INITIAL DIRECT TRANSFER

INITIAL DIRECT TRANSFER

図 2: UE 側開始のシグナリングコネクションの確立

3GPP

3GPP TS 25.303 V3.9.0 (2001-09)16Release 1999

6.1.3 正常な RRC コネクション解放（Normal RRC Connection Release）

正常な RRC Connection Release 処理は、UE の最後の Signalling Connection 用の RRC Signalling Connection Release request によって、ネットワーク側で開始される。UE に割当てられている個別物理チャネルによって、

処理手順は多少異なる。

3GPP

3GPP TS 25.303 V3.9.0 (2001-09) 17Release 1999

6.1.3.1 個別物理チャネルからの RRC コネクションの解放（RRC Connection Release from Dedicated Physical Channel）

DCCH: DCH: RRC CONNECTION RELEASE (unacknowledged)

UE-RRC UE-RLC UE-MAC UE-L1 Node B-L1 RNC-L1 CRNC-MAC SRNC-RLC SRNC-RRC

Uu Iub

RRC SignallingConnection Release

Requested


Indicated

CMAC-C / SH / D-Config-REQ CMAC-D-Config-REQ

CPHY-TrCH-Release-REQ

Last SignallingConnection &DCH released

CPHY-Out-Of-Sync-IND

CPHY-RL-Release-REQ

SRNC-MAC

CMAC-C / SH -Config-REQ

L2 link released

DCCH: DCH: RRC CONNECTION RELEASE COMPLETE (unacknowledged, Quick Repeat)

CRLC-Config-REQ CRLC-Config-REQ



CPHY-RL-Release-REQ CPHY-TrCH-Release-REQ

CPHY-RL-Release-REQ


L2 link released

図 3: 個別物理チャネルからの RRC コネクションの解放

3GPP

3GPP TS 25.303 V3.9.0 (2001-09)18Release 1999

ネットワーク内の RRC レイヤのエンティティは、DCCH 上で非アクノリッジモードを使用して、RRC CONNECTION RELEASE メッセージを発行する。UE-RRC は本メッセージを受信すると、NAS に対して

RRC Signalling Connection Release Indication プリミィティブを送信する。UE は個別チャネル上で非アクノリ

ッジモードを使用して RRC CONNECTION RELEASE COMPLETE メッセージを返す。メッセージの信頼度

を上げるために、RRC-level 上のクイックリピートを使用することもできる。続いて UE は、RLC、MAC、および無線リンクを解放し、そして UE はアイドルモードに入る。

ネットワーク内のシグナルリンクの解放を検出する第一の方法は、UE からの RRC CONNECTION RELEASE COMPLETE-message である。クイックリピートを使用したにもかかわらずメッセージが消失した場合でも、

Node-B L1 もしくは RNC-L1 のどちらかから RNC RRC に対する out-of-sync プリミィティブによって、シグ

ナルリンクの解放が検出できること。本プリミィティブ受信後、RNC-RRC レイヤはネットワーク側の L2および L1 リソースを解放して、アイドルモードに入る。

6.1.3.2 個別物理チャネルなしの RRC コネクションの解放（RRC Connection Release without Dedicated Physical Channel）

ネットワーク内の RRC レイヤのエンティティは、DCCH 上で非アクノリッジモードまたはアクノリッジモ

ードを使用して RRC CONNECTION RELEASE メッセージを発行する。UE-RRC は本メッセージを受信する

と、NAS に対して、RRC Signalling Connection Release Indication プリミィティブを送信し、DCCH 上でアク

ノリッジモードを使用して UTRAN に対して RRC CONNECTION RELEASE COMPLETE を送信する。

ネットワークの RRC レイヤは RRC CONNECTION RELEASE COMPLETE メッセージすると、 L2 リソース

を解放し、RRC Signalling Connection Release confirmation を DC-SAP に対して送信し、そしてアイドルモー

ドに入る（より厳密にいえば、その UE 個別の RRC エンティティだけがアイドルモードに入る）。

3GPP

3GPP TS 25.303 V3.9.0 (2001-09) 19Release 1999

[RRC Connection Release Complete]

DCCH: FACH: RRC CONNECTION RELEASE (acknowledged)


Uu Iub


Requested


Indicated


CMAC-D-Config-REQ

Last SignallingConnection &

no DCH

CRLC-Config-REQ

SRNC-MAC


RLC-Data-REQ[RRC Connection Release Complete]

DCCH: RACH: Acknowledged DataRLC-Data-IND

RLC-Data-CNF

DCCH: FACH: Data ack


Confirmed

CRLC-Config-REQ

図 4: 個別物理チャネルなしの RRC コネクションの解放

3GPP

3GPP TS 25.303 V3.9.0 (2001-09)21Release 1999

6.2 無線ベアラ制御手順（Radio Bearer Control Procedures）

6.2.1 無線ベアラのコンフィグレーション（Radio Bearer Configuration）

6.2.1.1 無線ベアラの確立（Radio Bearer Establishment）

無線ベアラ確立のための処理は、無線ベアラと個別トランスポートチャネルの関係によって大きく異なるこ

とがある。無線ベアラに関係する個別チャネルが固定的に割当てられるか否かは、QoS パラメータに依存す

る。CS（Circuit-switched）ベアラ、あるいはリアルタイムサービスとして分類されるベアラは通常、要求遅

延特性を満足するために DCH を固定的に割当てる必要がある。それに対して PS(Packet-switched)ベアラ、ま

たは非リアルタイムサービスとして分類されるベアラは、多くの場合、ベストエフォートのサービスが提供

され、DCH に関連するキャパシティ要求は需要に基づく。

DCH と同時に無線ベアラを確立する場合には、DCH を新規に起動物理チャネルに割当ててもいいし、既存

の物理チャネルを修正してそれに割当ててもよい。修正はさらに 2 種類の異なるオプションに分ける事がで

きる。すなわち、同期と非同期である。新旧物理チャネルの設定（TFCI など）に互換性があり、かつネッ

トワークと UE とで別々なタイミングでパラメータ修正を実行しても送信エラーが生じない場合には、非同

期処理を適用できる。それに対して、例えば新しい物理レイヤのコンフィグレーションセットに同一の

TFCI 値が割当てられた場合など、新旧の設定に互換性がない場合には、同期処理を使用する必要がある。

6.2.1.1.1 個別物理チャネルの起動を伴う無線ベアラ確立（Radio Bearer Establishment with Dedicated Physical Channel Activation）

図 5 に示した処理は、無線ベアラ用に新しい物理チャネルを生成する必要がある場合に適用される。RRC レ

イヤのネットワーク側が、DC-SAP から RB Establish Request プリミィティブを受信した場合、無線ベアラの

確立（Radio Bearer Establishment）が開始される。本プリミィティブには、ベアラリファレンスと QoS パラ

メータが含まれる。これらの QoS パラメータの値に基づき、ネットワーク側で RRC エンティティが L1 お

よび L2 パラメータを選択する。

ネットワーク側における物理レイヤの処理は、対象となる全ての Node B に対して CPHY-RL-Setup request プリミィティブを発行することによって開始される。もし全ての期待した受信者（Node B）がサービスを提供

できない場合には、そのことが confirmation プリミィティブ中で通知される。Node B において、送受信

（Tx/Rx）の開始を含む L1 のセットアップが完了した後、NW-RRC はそのピアエンティティに対して

RADIO BEARER SETUP メッセージを送信する（アクノリッジ送信を行うか非アクノリッジ送信を行うかは

ネットワークのオプション）。本メッセージ中には、L1、 MAC、および RLC パラメータが含まれる。メ

ッセージ受信後、UE-RRC は L1 と MAC をコンフィグレーションする。

L1 同期が通知されると、UE はネットワークに対してアクノリッジモードで RADIO BEARER SETUP COMPLETE メッセージを返す。それを受けて NW RRC は、ネットワーク側の MAC と RLC をコンフィグレ

ーションする。

UE-RRC は RADIO BEARER SETUP COMPLETE に対する確認を受信した後、新しい無線ベアラに付随する

新しい RLC エンティティを生成する。RLC 確立に適用可能な方法は、RLC の送信モードに依存する。RLCコネクションは、非明示的確立または明示的シグナリングのどちらでも適用できる。

最終的に、UE-RRC が RB Establish Indication プリミィティブを送信し、RNC-RRC が RB Establish Confirmation プリミィティブを発行する。

3GPP

3GPP TS 25.303 V3.9.0 (2001-09) 22Release 1999


[Radio Bearer Setup Complete]

DCCH: Data ack

DCCH: RADIO BEARER SETUP (acknowledged or unacknowledged optional)


Uu Iub

CPHY-RL-Setup-REQ

Request for RBEstablishment

New DCH needed

Start tx/rx

CPHY-RL-Setup-CNF

CMAC-D-Config-REQ

CRLC-Config-REQ

CMAC-D / C / SH-Config-REQ

CRLC-Config-REQ

CPHY-RL-Setup-REQ

Start tx/rx

L1 Connection Establishment

CPHY-Sync-IND

DTCH: RLC Link Established

RLC-Data-REQ


RLC-Data-CNF

RB EstablishIndication

RLC-Data-IND


RB EstablishConfirmation

CPHY-Sync-IND

SRNC-MAC

CPHY-RL-Setup-REQ

CMAC-C / SH-Config-REQ

CPHY-TrCH-Config-REQ




図 5: 個別物理チャネルの活性化を伴う無線ベアラ確立

3GPP

3GPP TS 25.303 V3.9.0 (2001-09) 23Release 1999

6.2.1.1.2 個別物理チャネルの非同期修正を伴う無線ベアラ確立（Radio Bearer Establishment with Unsynchronised Dedicated Physical Channel Modification）



DCCH: Data ack



Uu Iub

CPHY-RL-Modify-REQ


Compatible DCHModification required

CPHY-RL-Modify-CNF


CRLC-Config-REQ


CRLC-Config-REQ

CPHY-RL-Modify-REQ


RLC-Data-REQ


RLC-Data-CNF


RLC-Data-IND



SRNC-MAC

CPHY-RL-Modify-REQ

CMAC-D-Config-REQ





図 6: 個別物理チャネルの非同期修正を伴う無線ベアラの確立

3GPP

3GPP TS 25.303 V3.9.0 (2001-09)24Release 1999

図 6 に、物理チャネルの非同期修正が適用される場合の無線ベアラの確立手順を示す。新旧物理レイヤが、

ピアエンティティ内で共存できるという意味で互換性がある場合には、非同期の無線ベアラ確立処理が適用

できる。この場合、固定的な起動時間は要求されない。

ネットワーク内の物理レイヤ上の修正は、CPHY_ modify request に対する応答として実行される。応答の失

敗は、確認プリミィティブ内で通知される。エラーフリーの場合、L3 上で RADIO BEARER SETUP メッセ

ージが送信される。アクノリッジ送信を行うか非アクノリッジ送信を行うかはネットワークのオプション。

UE 側では本メッセージ受信後、コンフィグレーションが変更される。RADIO BEARER SETUP COMPLETEメッセージの受信は、ネットワーク内の MAC および RLC のコンフィグレーション変更のトリガとなる。

6.2.1.1.3 個別物理チャネルの同期修正を伴う無線ベアラ確立（Radio Bearer Establishment with Synchronised Dedicated Physical Channel Modification）

このケースでは、CPHY-RL-Modify request は、直ちに物理レイヤのコンフィグレーション変更の原因とはな

らない。単に要求されたコンフィグレーションが適用可能であるかをチェックし、「予約」

（"reservation"）を行うだけである。対象となる全ての Node B から確認を受信後、RRC は適切な「起動時

間」（"activation time"）を選択し、新しいコンフィグレーションを起動する時間を指定する。本情報は、

MAC、RLC そして物理レイヤ（CPHY_Commit request プリミィティブ）に対してシグナリングされる。

UE 側では、RADIO BEARER SETUP メッセージ (L2 上でアクノリッジ型送信が必要)を受信した後、ピア L3エンティティ間でセットアップ処理手順が進行する。そして初めて、新しいコンフィグレーションが UE、ネットワーク双方で利用可能になり、スケジューリングされた起動時間に全ての対象となるピアエンティテ

ィが新しいコンフィグレーションを引き継ぐ。

新旧物理チャネルのコンフィグレーションに互換性がない（DPCCH フォーマットや TFCI パターンが異なる

場合など）場合には、L1 および L2 上のコンフィグレーションの修正は、UE とネットワーク間の正確な同

期を必要とする。その様子を図 7 に示す。

3GPP

3GPP TS 25.303 V3.9.0 (2001-09) 25Release 1999



DCCH: Data ack


[Radio Bearer Setup]


Uu Iub

CPHY-RL-Modify-REQ


Incompatible DCHModification required

CPHY-RL-Modify-CNF


CRLC-Config-REQ

RLC-Data-REQ


DCCH: Data ack

RLC-Data-CNF

RLC-Data-IND



CRLC-Config-REQ

CPHY-RL-Modify-REQ

L1, MAC and RLC Modified

RLC-Data-REQ


RLC-Data-CNF


RLC-Data-IND



ChooseActivationTime

CPHY-commit-REQ


CRNC-MAC

CPHY-RL-Modify-REQ

CMAC-D-Config-REQ





図 7: 個別物理チャネルの同期修正を伴う無線ベアラの確立

3GPP

3GPP TS 25.303 V3.9.0 (2001-09) 26Release 1999

6.2.1.1.4 個別物理チャネルなしの無線ベアラ確立（Radio Bearer Establishment without Dedicated Physical Channel）




DCCH: Data ack

UE-RRC UE-RLC UE-MAC SRNC-MAC SRNC-RLC SRNC-RRC

Uu Iub


No DCH Required

CRLC-Config-REQ


CRLC-Config-REQ

RLC-Data-REQ


RLC-Data-CNF


RLC-Data-IND



CRNC-MAC


CMAC-D-Config-REQ



図 8: 個別物理チャネルなしの無線ベアラの確立

3GPP

3GPP TS 25.303 V3.9.0 (2001-09)27Release 1999

幾つかの無線ベアラにおいては、無線ベアラに対して個別無線リソースが恒久的に関連付けられていない。

それ故に、物理的リソースのセットアップは、実質的な無線ベアラのセットアップ（RLC と MAC だけが含

まれる）とは分離される。

MAC のコンフィグレーションは、既存の個別トランスポートチャネルと物理チャネル上、または共通チャ

ネル上で開始される。

6.2.1.1.5 CPCH チャネル割当てと同時の無線ベアラ確立（Radio Bearer Establishment with CPCH Channel Allocation）

RNC が CPCH 上りリンクリソースを UE に対して割当てる必要があると決定した場合には、RNC は RB Setup メッセージを UE に対して送信する。CPCH の物理的パラメータは BCCH 上でブロードキャストされ

るので、RB Setup メッセージには DPCH の部分が含まれない。Transport Channel information には、CPCH set (CPCH Set ID#) が含まれ、それに対して UE が割当てられる。 MAC エンティティはコンフィグレーション

される。MAC エンティティとは、UE 中の MAC-D と MAC-C/SH、CRNC 中の MAC-C/SH 、および SRNC中の MAC-D を指す。Node B の MAC は、CPCH セット中の個々の CPCH へのアクセスを制御するが、Node B の MAC はコンフィグレーションを必要としない、なぜなら、該当セルに対して最初に CPCH セットが割

当てられたとき、CPCH セットを制御するために MAC がコンフィグレーションされるからである。Node Bの MAC は、CPCH セットに対して割当てられた UE の数とは独立して機能する。一旦 RB Setup が完了した

後は、上りリンク方向に送信する次データがこの無線ベアラの論理チャネルに存在する時は、UE は CPCHにアクセスできる。

CPCH 用の無線ベアラ確立のメッセージフローダイヤグラムは、個別物理チャネルがない場合の無線ベアラ

確立のそれと類似している ( 6.2.1.1.4 節参照)。

3GPP

3GPP TS 25.303 V3.9.0 (2001-09) 28Release 1999


DCCH: RACH: Acknowledged Data

DCCH: FACH: RADIO BEARER SETUP (acknowledged or unacknowledged optional)

DCCH: FACH: Data ack

UE-RRC UE-RLC UE-MAC SRNC-MAC SRNC-RLC SRNC-RRC

Uu Iub


Assign CPCH Set

CRLC-Config-REQ

CMAC-D / C/SH-Config-REQ

CRLC-Config-REQ

RLC-Data-REQ


RLC-Data-CNF


RLC-Data-IND



CRNC-MAC


CMAC-D-Config-REQ

CPCH Allocated

図 9: CPCH チャネル割当てを伴う無線ベアラの確立

3GPP

3GPP TS 25.303 V3.9.0 (2001-09)29Release 1999

6.2.1.2 無線ベアラの解放（Radio Bearer Release）

無線ベアラ確立の処理手順同様、無線ベアラの解放処理手順には、物理チャネルの修正または停止を含むこ

ともできる。どちらになるかは、新旧 QoS パラメータ間の差異に依存する。これらの処理は、同期でも非

同期でもよい。

ネットワーク側の RRC レイヤから解放の要求があると、無線ベアラの開放処理が開始される。本要求には、

ベアラリファレンスが含まれ、回復された無線ベアラ上で Release Confirm プリミィティブが直ちに非アク

セス層に戻される。

無線ベアラが残っている場合には、新しい L1 と L2 パラメータを選択することもできる。RADIO BEARER RELEASE メッセージが、ネットワーク内の RRC レイヤから UE 内のピアエンティティに対して送信される。

本メッセージには、残っている無線ベアラ用に適用可能な L1、 MAC 、および RLC パラメータと、解放す

べき無線ベアラに関する識別が含まれる（注）。UE-RRC は、RB Release Indication を送信する。

注: 同期処理の場合には、データの消失を防ぐために、L1 と L2 のコンフィグレーション用に特定

の起動時間（specific activation time）が必要

UE 側の RRC は、L1 と MAC をコンフィグレーションし、解放された無線ベアラに関連する RLC エンティ

ティを解放する。NW RRC は UE から RADIO BEARER RELEASE COMPLETE メッセージを受信した後、同

様の再コンフィグレーション処理をネットワーク側でも行う。

6.2.1.2.1 非同期の個別物理チャネル修正を伴う無線ベアラの解放（Radio Bearer Release with Unsynchronised Dedicated Physical Channel Modification）

図 10 中の例は、（無線ベアラの）解放が、非同期の物理チャネル修正として、すなわち物理チャネルの停

止なしで実行できる場合を示したものである。

上位レイヤに対してこの解放を通知した後、RADIO BEARER RELEASE メッセージが UE に対して送信（ア

クノリッジ送信を使用するか非アクノリッジ送信を使用するかはネットワークのオプション）され、UE 内

で再コンフィグレーションがトリガされる。再コンフィグレーション処理が完了すると、UE はネットワー

クに対して RADIO BEARER RELEASE COMPLETE メッセージを送信し、その後ネットワーク内で再コンフ

ィグレーション処理が実行される。

3GPP

3GPP TS 25.303 V3.9.0 (2001-09) 30Release 1999

DCCH: RADIO BEARER RELEASE COMPLETE (acknowledged)

DCCH: RADIO BEARER RELEASE (acknowledged or unacknowledged optional)


Uu Iub

CPHY-RL-Release-REQ

Request for RBRelease

Compatible DCHModification required

CPHY-RL-Modify-CNF

CMAC-D-Config-REQ

CRLC-Config-REQ (DTCH)


CRLC-Config-REQ (DTCH)

CPHY-RL-Release-REQ

RB ReleaseIndication

RB ReleaseConfirmation

CRNC-MAC

CPHY-RL-Release-REQ

L2 link released (DTCH)





L2 link released (DTCH)

図 10: 非同期の個別物理チャネル修正を伴う無線ベアラの解放

3GPP

3GPP TS 25.303 V3.9.0 (2001-09)31Release 1999

6.2.1.3 無線ベアラの再コンフィグレーション（Radio Bearer Reconfiguration）

無線ベアラの再コンフィグレーションには、同期型および非同期型処理の双方が適用可能である。非同期処

理の例を図中で示した。

6.2.1.3.1 非同期の無線ベアラの再コンフィグレーション（Unsynchronised Radio Bearer Reconfiguration）

図 11 に示すように、非同期という特性ゆえに、起動時間も Node B の物理レイヤ用への別のコミット要求

（commit request）も必要ない。要求された修正の実行の可否は、物理レイヤからの確認プリミィティブ

（confirmation primitive）内でリポートされる。修正に旧コンフィグレーションの解放が含まれる場合には、

解放は処理が完了するまで延期することができる。UE は RNC-RRC から RADIO BEARER RECONFIGURATION を受信した後（アクノリッジ送信を使用するか非アクノリッジ送信を使用するかはネ

ットワークのオプション）、L1 と L2 上でコンフィグレーションの修正を実行する。

NW-RRC は UE-RRC から RADIO BEARER RECONFIGURATION COMPLETE メッセージを受信した後、 L1と L2 上でコンフィグレーションの修正を実行する。そして最後に、旧コンフィグレーションが存在する場

合には、Node B-L1 から解放される。

3GPP

3GPP TS 25.303 V3.9.0 (2001-09) 32Release 1999

[Radio Bearer Reconfiguration Complete]


DCCH: Data ack

DCCH: RADIO BEARER RECONFIGURATION (acknowledged or unacknowledged optional)


Uu Iub

CPHY-RL-Modify-REQ

CPHY-RL-Modify-CNF


CRLC-Config-REQ


CRLC-Config-REQ

CPHY-RL-Modify-REQ

RLC-Data-REQ

[Radio Bearer Reconfiguration Complete]

RLC-Data-CNF

RLC-Data-IND

[Radio BearerReconfiguration Complete]

CPHY-RL-Modify-REQ (release old)

CPHY-RL-Modify-CNF

CRNC-MAC

CPHY-RL-Modify-REQ

CMAC-D-Config-REQ



CPHY-TrCH-Config-REQ (release old)


図 11: 非同期無線ベアラ再コンフィグレーション

3GPP

3GPP TS 25.303 V3.9.0 (2001-09)33Release 1999

6.2.2 トランスポートチャネルの再コンフィグレーション（Transport Channel Reconfiguration）

トランスポートチャネルの再コンフィグレーションに関しては、同期処理と非同期処理の双方が適用可能で

ある。

6.2.2.1 非同期型 TFS の再コンフィグレーション（Unsynchronised Transport Format Set Reconfiguration）

図 12 に、1 つのトランスポートチャネル用の TFS を変更する場合の処理の例を示す。本処理はトランスポ

ートチャネルの再コンフィグレーション処理を伴う。

トランスポートチャネル用の TFS の変更は、ネットワーク内の RRC レイヤでトリガされる。ネットワーク

内の RRC レイヤからそのピアエンティティに対して、TRANSPORT CHANNEL RECONFIGURATION メッ

セージが送信される（アクノリッジ送信を使用するか非アクノリッジ送信を使用するかはネットワークの

オプション）。メッセージには、新しい TFS、または新しい TFCS が含まれる。つまり、L1 と MAC 用の新

しいパラメータが含まれる（注）。UE 内で本メッセージが受信されると、L1 と MAC の再コンフィグレー

ションが実行される。ネットワーク側でも TRANSPORT CHANNEL RECONFIGURATION COMPLETE メッ

セージを受信後、同様の再コンフィグレーションが実行される。

注: 同期処理の場合には、データの消失を防ぐために、L1 と L2 のコンフィグレーション用に特定

の起動時間が必要

トランスポートチャネル用の TFS の再コンフィグレーション中には、該当チャネル上での無線トラフィック

は一時的に停止してもよい。なぜならば、UE とネットワークがこれらのコンフィグレーションを行う際に

連携する必要はないからである。停止されたトラフィックは、COMPLETE メッセージの後で再開できる。

3GPP

3GPP TS 25.303 V3.9.0 (2001-09) 34Release 1999

DCCH: DCH:TRANSPORT CHANNEL RECONFIGURATION (acknowledged or unacknowledged optional)


Uu Iub



CPHY-RL-Modify-REQ

[Change TFS]

CPHY-RL-Modify-REQ

[Change TFS]

TRANSPORT CHANNEL RECONFIGURATION COMPLETE (acknowledged)

CPHY-RL-Modify-CNF

CRNC-MAC

CMAC-D-Config-REQ

[Change TFS]

図 12: 非同期型 TFS の再コンフィグレーション

3GPP

3GPP TS 25.303 V3.9.0 (2001-09)35Release 1999

6.2.3 物理チャネルの再コンフィグレーション（Physical Channel Reconfiguration）

物理チャネルの再コンフィグレーションは、同期処理も非同期処理の双方が適用可能である。

6.2.3.1 UE 発の DCH 活性化（UE-Originated DCH Activation）

図 13 は、共通チャネル(CELL_FACH) から個別チャネル（CELL_DCH）への切替処理の例を示したものであ

る。

UE 内では、トラフィック量の測定機能が、MEASUREMENT REPORT メッセージをネットワークに送信す

るか否かを決定する。ネットワーク側では、本測定レポートが様々な異なるアクションのトリガとなりうる。

例えばシステムトラフィックが高い場合に、ネットワークは TFS を変更したり、またはチャネルのタイプを

切替えたり、あるいは何もアクションを起こさない、など。このケースでは CELL_FACH から CELL_DCHへの切替が開始される。

レポート送信に、アクノリッジ送信を使用するか、非アクノリッジ送信を使用するかはネットワークがコン

フィグレーション可能。

最初に、L1 上の修正が要求されて、ネットワーク側では CPHY-RL-Setup プリミィティブといっしょに確認

される。

ネットワーク側の RRC レイヤは、UE 内のピアエンティティに対して PHYSICAL CHANNEL RECONFIGURATION メッセージを送信する（アクノリッジ送信を使用するか、非アクノリッジ送信を使用

するかはネットワークのオプション）。このメッセージは、DCCH 上で FACH にマッピングされて送信され

る。メッセージには、新しい物理チャネルに関する情報、例えばコードや DCH を活性化すべき時間周期な

どが含まれる（注）。

注: 本メッセージには新しいトランスポートフォーマットは含まれない。トランスポートチャネル

の変更によって、トランスポートフォーマットの変更が要求された場合には、別の Transport Channel Reconfiguration 処理として実行される。本処理はトランスポートチャネルの変更のみを

取り扱う。

UE が新しい個別チャネル上で同期を検出したならば、UE 側で L2 のコンフィグレーションが実行され、

PHYSICAL CHANNEL RECONFIGURATION COMPLETE メッセージがネットワーク中の RRC に対して

DCCH 上で DCH にマッピングされて送信される。ネットワーク CPHY_sync_ind もしくは L3 complete メッ

セージによってトリガされて、ネットワーク内で RNC-L1 と L2 のコンフィグレーション変更が実行される。

3GPP

3GPP TS 25.303 V3.9.0 (2001-09) 36Release 1999

DCCH: RACH: MEASUREMENT REPORT (acknowledged or unacknowledged RLC transmission configurable by UTRAN)

CMAC-measurement-IND


Uu Iub

CPHY-RL-Setup-REQ

CPHY-RL-Setup-CNF


CRLC-Config-REQ


CRLC-Config-REQ

CPHY-RL-Setup-REQ

Switchdecision

Start tx/rx

DCCH: FACH: PHYSICAL CHANNEL RECONFIGURATION (acknowledged or unacknowledged RLC transmission optional)

Start tx/rx

CPHY-Sync-IND

Establish L1 connection

CPHY-Sync-IND (FFS)

DCCH: DCH: PHYSICAL CHANNEL RECONFIGURATION COMPLETE

CRNC-MAC

CPHY-RL-Setup-REQ

CMAC-D-Config-REQ

図 13: UE 発の DCH 活性化

3GPP

3GPP TS 25.303 V3.9.0 (2001-09) 37Release 1999

6.2.3.2 UE 着の同期型 DCH の修正（UE-terminated synchronised DCH Modify）

[Physical ChannelReconfiguration Complete]

[Physical Channel Reconfiguration]

DCCH: DCH: Acknowledged Data


Uu Iub


CRLC-Config-REQ

RLC-Data-REQ


CRLC-Config-REQ

CPHY-RL-Modify-REQ

[Physical Channel Reconfiguration]

DCCH: DCH: Data ack

RLC-Data-IND

[Physical ChannelReconfiguration] RLC-Data-CNF

CPHY-RL-Modify-REQ

CPHY-RL-Modify-CNF

ChooseActivationTime

CPHY-commit-REQ

CRNC-MAC

CMAC-D-Config-REQ

Modify L1, MAC, RLC

[Physical Channel Reconfiguration Complete]


RLC-Data-REQ

[Physical Channel Reconfiguration Complete]

DCCH: DCH: Data ack

RLC-Data-IND

RLC-Data-CNF

図 14: UE 着の同期型 DCH 修正

3GPP

3GPP TS 25.303 V3.9.0 (2001-09)38Release 1999

図 14 は、同期型 DCH 修正処理の例を示したものである。本処理のトリガは、例えば停止タイマなどである。

本処理は例えば、他のベアラが DCH を使用している場合に、その DCH を解放せずに無線ベアラの全トラン

スポートフォーマットを解放する。新旧のコンフィグレーション間に互換性がない場合（チャネライゼーシ

ョンコードが変更された場合など）に、同期型処理が適用される。

NW-RRC は CPHY-RL-Modify 要求を確認した後、起動時間を選択する。その後、NW-RRC は UE に対して、

データ送信のアクノリッジとして、 PHYSICAL CHANNEL RECONFIGURATION メッセージを送信する。上

りリンク下りリンク双方とも、本メッセージは DCCH 上で DCH にマッピングして送信される。

メッセージ受信後 UE は、L1 と L2 を DCH リソースに対して再コンフィグレーションする。完了メッセー

ジを使用する場合には、DCCH 上で DCH にマッピングして送信する。非同期型の場合には、本メッセージ

は、個別チャネルと関連するネットワーク内の L1 と L2 のリソース修正をトリガする。

6.2.3.3 UE 着の DCH 解放（UE-terminated DCH Release）

図 15 は、個別チャネル(CELL_DCH) から共通チャネル（CELL_FACH）への切替処理の例を示したものであ

る。UE が使用する全ての DCH は解放され、全ての個別論理チャネルは CELL_FACH に移行される。本処

理のトリガは、例えば停止タイマなどである。

DCH から共通チャネルへの切替が決定されると、ネットワーク内の RRC レイヤが UE に対して PHYSICAL CHANNEL RECONFIGURATION メッセージを送信する（アクノリッジ送信を使用するか、非アクノリッジ

送信を使用するかはネットワークのオプション）。本メッセージは、DCCH 上で DCH にマッピングされて

送信される。

注 1: 本メッセージには、新しいトランスポートフォーマットは含まれない。トランスポートチャネ

ルの変更によって、トランスポートフォーマットの変更が必要な場合には、別の Transport Channel Reconfiguration 処理として実行される。本処理はトランスポートチャネルの変更のみ取

り扱う。

L1 の同期外れを使用して、ネットワーク内で UE が DCH を解放したことを検出する場合には、図に 1 つの

可能性を示したように、Node B-L1 をコンフィグレーションして、同期外れ検出用のタイムアウト時間を短

くする必要があるかもしれない。これは図中では CPHY-Out-of-Sync-Configure プリミィティブとして示され

る。

UE は（メッセージ）受信後、 L1 および L2 を再コンフィグレーションし、旧 DCH 用のリソースを解放す

る。ここでネットワークに対して、PHYSICAL CHANNEL RECONFIGURATION COMPLETE メッセージが DCCH 上で RACH にマッピングされて送信される（メッセージアクノリッジは FACH 上で行う）。本メッ

セージは、個別チャネルに関連するネットワーク内の L1 と L2 リソースの正常な解放をトリガする。

注 2: CELL_FACH への切替が実行された場合には、旧コードをできるだけ早く解放し、再利用可能

とすることが重要である。それゆえ、アクノリッジデータが到着しており、UE が Physical Channel Reconfiguration メッセージを受信したことが確実である場合には、Physical Channel Rreconfiguration Complete メッセージの受信を待つ代わりに、アクノリッジデータの到着を以っ

てネットワークが L1 と L2 を再コンフィグレーションすることも可能。UE が旧 DCH 用リソー

スを解放したことが確実である場合には、ネットワークは Out of sync Indication が L1 から上が

ってくるまで待つこともできる。 Physical Channel Reconfiguration が送信時にスタートするタイマを含むこれらのステップには、

DCH 用のリソースが本当に解放されて再利用可能であることをネットワークに通知するための

4 つの異なる通知が含まれる。

3GPP

3GPP TS 25.303 V3.9.0 (2001-09) 39Release 1999

DCCH: DCH: PHYSICAL CHANNEL RECONFIGURATION (acknowledged or unacknowledged optional)


Uu Iub

CPHY-Out-Of-Sync-IND


CRLC-Config-REQ


CRLC-Config-REQ

CPHY-RL-Release-REQ

DCCH: RACH: PHYSICAL CHANNEL RECONFIGURATION COMPLETE

CPHY-RL-Release-REQ

CRNC-MAC

CPHY-RL-Release-REQ

CMAC-D-Config-REQ

CPHY-Out-Of-Sync-Config-REQ

CPHY-Out-Of-Sync-Config-CNF

図 15: UE 着の DCH の解放

3GPP

3GPP TS 25.303 V3.9.0 (2001-09)40Release 1999

6.2.4 TFC の制御（Transport Format Combination Control）

6.2.4.1 TFC の規制（Transport Format Combination Limitation）

DCCH: TRANSPORT FORMAT COMBINATION CONTROL (acknowledged, unacknowledged or transparent optional)

UE-RRC UE-RLC UE-MAC SRNC-RLC SRNC-RRC

Uu Iub

CMAC-D-Config-REQ

[New smaller TFCS]

TFC limitationtriggered

DCCH: TRANSPORT FORMAT COMBINATION CONTROL (acknowledged, unacknowledged or transparent optional)

CMAC-D-Config-REQ

[Original TFCS]

TFC limitationreleased

図 16: TFC の規制

図 16 は、TFC 制御の例を示したものである。輻輳状態が発生すると、許容されていた TFC が一時的に規制

される。輻輳状態が解消すると、規制は解除される。

本処理は、ネットワークから UE に対して Transport Format Combination Control メッセージが送信されたとき

に開始される（アクノリッジ送信を使用するか、非アクノリッジ送信を使用するかはネットワークのオプシ

ョン）。本メッセージには、通常の TFCS のサブセットが含まれる。UE は MAC の再コンフィグレーション

を継続する。MAC は TFC のサブセットを、完全に新しいセットとして見なす。

さらに、しばらくして輻輳が解決した後に、ネットワーク内の RRC レイヤから UE に対して、新しい

Transport Format Combination Control メッセージが送信される。本メッセージにはサブセットが含まれ、それ

は完全にオリジナルなセットである。再び、UE は MAC を再コンフィグレーションする。

3GPP

3GPP TS 25.303 V3.9.0 (2001-09) 41Release 1999

6.2.5 上りリンク DCH の動的リソース割当て（Dynamic Resource Allocation Control of Uplink DCHs）

UE-RRC UE-MAC CRNC-RRC

Uu

CMAC-D_conf_req

[subset of TFCS]

Update UL resourcesallocation control

parameters(Max Rate, ptr)

UL DCH : Transmission during Tvalidity

DYNAMIC UPLINK RESOURCE ALLOCATION CONTROL (Broadcast)

Iub

Check permission for DCHsIf granted select TFCS subset

for DCHs,Else w ait for Tretry

図 17: 上りリンク DCH の動的リソース割当て制御

3GPP

3GPP TS 25.303 V3.9.0 (2001-09)42Release 1999

図 17 は、上りリンク DCH の動的リソース割当て制御(DRAC)の例を示したものである。CRNC は定期的に

以下のパラメータをブロードキャストする。

- 送信確率（transmission probability） ptr：UE が自身の DCH 上で送信を許可される確率を示す。次の周

期 Tvalidityの間、この値は本処理の管理下に置かれる。

- UE が自身の DCH 上で使用を許可された最大総ビットレート（maximum total bit rate）。次の周期

Tvalidityの間、この値は本処理の管理下に置かれる。

以上のパラメータの他にも、RNC は以下のパラメータを UE に送信することができる。

- 送信時間正当性（transmission time validity） Tvalidity：送信のためのアクセスが許容された期間を示す

- 再アクセスタイム（reaccess time） Tretry：送信が許容されなかった場合に、リソースへのアクセスを

リトライするまでの待ち時間を示す。

本処理は、CRNC が上記 DRAC パラメータを含む SYSTEM INFORMATION メッセージを定期的に FACH 上

にブロードキャストすることによって開始される。これは S-CCPCH と DPCH の同時受信が可能で DCH を

動的に制御できる全 UE に対して適用される。UE は自身の DCH 上で送信を開始する前に、本メッセージを

聞かなくてはならない。UE の RRC は、送信が許容されているかをチェックし、そして maximum total bit rate パラメータから算出される新しい TFCS サブセットを使用して、MAC を再コンフィグレーションする。

本 TFCS のサブセットは、本処理の制御下にある DCH だけを制御すること。

上りリンク DCH 上でソフトハンドオーバが実行される場合、UE はそのクラスに応じて、自身のプライマリ

セル（最もパス損失が小さいセル）からのブロードキャスト情報を聞くか、あるいは自身のアクティブセッ

ト中にある全セルからのブロードキャスト情報を聞くか、どちらかが要求される。後者の場合には、UE は

より厳密な制御情報に従って動作することが予想される。

3GPP

3GPP TS 25.303 V3.9.0 (2001-09) 43Release 1999

6.2.6 上りリンク DCH の可変レート送信（Variable Rate Transmission of Uplink DCHs）

.

.

.continue packet transmission


UE-RRC UE-RLC UE-MAC UE-L1 Node B-L1 RNC-L1 SRNC-RLC SRNC-RRC

Uu Iub

RB Establishmentprocedure


set Maximum allowable Tx power(Uplink Radio Resources IE) if needed

CPHY-Measurement-REQ (set power thresholds for measurement)

PHY-Status-IND (e.g. event Allowabletransmit power has been reached)

Decrease data rate within TFCS

PHY-Status-IND (e.g. event Allowabletransmit power is below allowable transmit

Increase data rate within TFCS

DCH: Acknowledged Data

DCH: Acknowledged Data

図 18: 上りリンク DCH の可変レート送信

3GPP

3GPP TS 25.303 V3.9.0 (2001-09)44Release 1999

図 18 に、上りリンク DCH の可変レート送信処理の例を示す。本処理で TFCS の範囲内で一時的にデータレ

ートを引き下げることによって、可変レートサービスのユーザの QoS を維持し、不要な干渉を避けること

ができる。

可変レートサービス用のコネクション確立時、RRC は MAC に対して TFCS を割当てる。無線ベアラセット

アップ処理の際に、UE の最大許容送信出力（maximum allowable Tx power）が UE の能力クラスごとに異な

る場合には、その値をユーザ毎に設定することができる。

CPHY-Measurement-REQ を使用して、UE に対して電力スレッショルド（power thresholds）が設定される。

送信中に許容送信出力が設定スレッショルドを上回ったならば、イベントが MAC にシグナリングされて、

次の送信インターバルの間、TFCS の範囲内でデータレートを引き下げる。

UE 側で１TTI 内で送信不可能な PDU（すなわち利用可能な PDU のいくつかが送信できないと MAC が認識

した場合）は RRC の discard configuration set に従いバッファされる。

チャネル環境が改善されて、平均送信出力が許容送信出力を下回ったならば、物理レイヤは本イベントを

MAC に通知する。もし送信すべきデータが十分にある場合には、それに対する応答として、MAC は L1 に

配送する送信ブロックの数を増加させてデータレートを引き上げて、物理レイヤは UE の総送信出力を規定

値まで増加させる。そうすることによって、チャネル環境が悪いときにバッファリングされたデータを、

UTRAN に送信することができる。

3GPP

3GPP TS 25.303 V3.9.0 (2001-09) 45Release 1999

6.3 データ送信（Data transmission）

6.3.1 DSCH 上のアクノリッジモードのデータ送信、TFCI ワードの物理分割（Acknowledged-mode data transmission on DSCH using hard split of TFCI-word）

MAC-C/SH-Data-REQ

CRNC-MAC-C/SH SRNC-MAC-D

Uu Iur

Schedule DSCHtransmission

UE-MAC-C/SHUE-MAC-D

MAC-C/SH-Data-IND

SRNC-RLC

DTCH (/ DCCH): MAC-D-Data-REQ

Iub

UE-RLC

MAC-D-Data-IND

DTCH (/ DCCH): DCH: Data ACK

Node B-L1UE-L1

DSCH: MPHY-Data-REQ

[Data]

[Data]

[Data, TFI2]

DCH: MPHY-Data-REQ

[Data2, TFI1]

(PDSCH)

(DPCH)

[Data]

[Data2, TFCI(field1), TFCI(field2)]

DSCH: MPHY-Data-IND

[Data, TFI2]

[Data]

[Data]

図 19: DSCH 上のアクノリッジモードのデータ送信例

3GPP

3GPP TS 25.303 V3.9.0 (2001-09)46Release 1999

図 19 に、DCH に付随する DSCH 上のアクノリッジモードのデータ送信例を示す。まず最初に、SRNC 内の

RLC が、MAC-d からデータ送信をローカルに要求する。MAC-d はその要求を、ローカルまたは Iur を経由

して CRNC 内の MAC-c/sh にルーチングする。CRNC 内で DSCH 送信スケジュール処理が実行される。

MAC-c/sh は、データ用の TFI(‘TFI2’)を決定し、Node B 内の物理レイヤに対して Iub 経由のデータ送信を要

求する。これと同時に、付随する個別チャネルのデータが Node B 内に到達できる。

DCH ほすべての TFI（例えば “TFI1”）は TFCI(field1)内に送信される。TFCI(field2)は関連する DSCH の情報

を運ぶ。DSCH 用の TFCI(field1)と DCH 用の TFCI(field2)が TFCI-word に物理的に分割(’hard’ split)されて物

理レイヤで組み合わされ、付随した DPCH (dedicated physical channel)の DPCCH (dedicated physical control channel) 上で送信される。DSCH のデータは、PDSCH (physical downlink shared channel)上で別に送信される。

TFCI(field2)は DSCH データをデコードするのに使用され、続いて MAC-c/sh および MAC-d を経由して受信

側 RLC に転送される。アクノリッジを送信する前に DCH が解放される場合を除き、最終的に UE-RLC がア

クノリッジ（acknowledgement）を DCH 上にマッピングして送信する。

6.3.2 DSCH 上でのアクノリッジモードのデータ送信、TFCI ワードの論

理分割（Acknowledged-mode data transmission on DSCH using logical split of TFCI-word）

注: 本リリースでは、本例は SRNC = CRNC である場合のみ有効。

図 20 に、DSCH 上でのアクノリッジモードのデータ送信の例を示す。まず最初に、SRNC 内の RLC が、

MAC-d からのデータ送信を要求する。MAC-d はデータを MAC-c/sh にパスする。MAC-c/sh は DSCH の送信

をスケジューリングし、データ用の TFI を決定する。送信に必要な TFI と CFN (connection frame number)がMAC-d に返される。

MAC-c/sh は TFI を選択し、DSCH 用のデータを送信する。一方、MAC-d は、任意の DCH データと同期し

て TFI を送信し、DCH データと同一フレーム内で TFI が送信されるようにする。DSCH 用の TFCI(field2)とDCH 用の TFCI(field1)は TFCI-word に論理的に分割(‘logical’ split)されて物理レイヤ上で組み合わされ、付随

した DPCH (dedicated physical channel)の DPCCH (dedicated physical control channel) 上で送信される。DSCH の

データは PDSCH (physical downlink shared channel)上で別に送信される。TFCI(field2)は DSCH のデータをデ

コードするのに使用され、続いて MAC-c/sh および MAC-d を経由して受信側 RLC に転送される。アクノリ

ッジを送信する前に DCH が解放された場合を除き、最終的に UE-RLC がアクノリッジ（acknowledgement）を DCH 上にマッピングして送信する。

3GPP

3GPP TS 25.303 V3.9.0 (2001-09) 47Release 1999

RNC-MAC-C/SH RNC-MAC-D

Uu

Schedule DSCHtransmission,

TFI defines TF forDSCH

UE-MAC-C/SHUE-MAC-D

MAC-C/SH-Data-IND

RNC-RLC

DTCH (/ DCCH): MAC-D-Data-REQ

Iub

UE-RLC

MAC-D-Data-IND

DTCH (/ DCCH): DCH: Data ACK

Node B-L1UE-L1

DSCH: MPHY-Data-REQ

[Data]

[Data]

DCH: MPHY-Data-REQ

[Data2, TFI2]

(PDSCH)

(DPCH)

[Data]

[Data2, TFCI]

DSCH: MPHY-Data-IND

[Data, TFI]

[Data]

[Data]

DCH: MPHY-Data-REQ

[TFI]

DTCH (/ DCCH): MAC-C/SH-Data-REQ

[Data]

[TFI]

図 20: DSCH 上のアクノリッジモードのデータ送信の例

3GPP

3GPP TS 25.303 V3.9.0 (2001-09) 48Release 1999

6.3.3 CPCH 上のデータ送信（Data transmission on CPCH）

CSICH RRC information relevant for CSICH

CSICH RRC information relevant for CSICHA

UE-MAC CRNC-MAC-C/SH SRNC-MAC-D

[Note 1]

[Note 1][Note 1][Note 1][Note 1][Note 2]

[Note 1] If AP-AICH NAK received, resume from A

[Note 2] If CD-ICH does not match CD signature resume from A

[Chart is continued on next page]

SRNC-RLC

Uu IurIubUE-RLC UE-L1 Node B-L1

PHY-CPCH_Status-REQ

DTCH: MAC-D-Data-REQ

PHY-CPCH_Status-CNF

Select desired TransportFormat for access requestPersistency CheckExecute initial delay

PHY-Access-REQAccess Preamble (AP) @P1

Access Preamble (AP) @P2

Node B-RRC

AP received

response with selected signatureAP-AICH with matching signature

Collision Detection

CD received

response with selected CD orCD/CA signature

Select Transport FormatBuild CPCH Transport Block Set

Preamble for CLPC (0 or 8 Slots)

TPC for CLPC (continuous)

CD/CA-ICH with specificChannel assignment

PHY-Access-CNF

PHY-DATA-REQ

図 21: CPCH 上のデータ送信の例 (1/2)

3GPP

3GPP TS 25.303 V3.9.0 (2001-09) 49Release 1999

UE-MAC CRNC-MAC-C/SH SRNC-MAC-D

[Chart continued from previous page]

Note: CPCH transmission and fast power control is continuous in Uu

SRNC-RLC

D

C

E

F

Uu IurIubUE-RLC UE-L1 Node B-L1

PHY-STATUS-IND

PHY : CPCH

Node B-RRC

PHY-DATA-IND (normal transmission) MAC-DATA-INDMAC-DATA-REQ

PHY-DATA-IND MAC-DATA-IND

PHY : CPCH

PHY-DATA-REQ

B

DPCH [Start of message indication]

PHY : CPCH

CPHY-CPCH-EOT-IND

PHY-DATA-REQ (with TB==0)

図 22: CPCH 上のデータ送信の例 (2/2)

3GPP

3GPP TS 25.303 V3.9.0 (2001-09)50Release 1999

図 21 に、CPCH 上のアクノリッジモードのデータ送信例を示す。RLC のアクノリッジ送信モード、または

アクノリッジ送信モードが、CPCH 上にマッピングされた全ての論理チャネルに対して適用されるものと仮

定する。

CPCH の送信は、UE に対して割当てられた CPCH のリソースと共に、コネクトモードの RRC ステートの

CELL_FACH に対して適用される。 UE はそれぞれの RRC 処理の過程で、CPCH 送信をコンフィグレーショ

ンすることが必要である（例：RADIO BEARER SETUP または TRANSPORT CHANNEL RECONFIGURATION メッセージといっしょに）。

データ送信要求を RLC から受信すると、MAC はまず始めに物理レイヤに対して CPCH チャネルのステー

タス情報を要求する。CPCH チャネルのステータス情報は、AP-AICH と同じ下りリンクチャネライゼーショ

ンコードを使用して、CSICH 物理チャネル上でブロードキャストされると仮定する。ステータス情報は、

CA（Channel Assignment）がアクティブである場合に、PCPCH リソース上で利用可能な許容最大データレー

トを通知する。CA がアクティブでない場合には、UE のチャネル選択（UE Channel Selection）が使用される。この場合、ステータス情報は、それぞれ定義された PCPCH が利用可能であるかを通知する。どちらの場合

でも、チャネルステータス情報はその時に使用可能なトランスポートフォーマットの組合せにコンバートさ

れる。チャネル割当てがアクティブであるか否かを、System Information メッセージを使って通知してはな

らない。現時点では、CPCH のステータス情報のトランスポートフォーマットへのコンバートは、L1 の内部

機能であると仮定されている。

許容されたトランスポートフォーマットと送信のために利用可能なデータに基づき、MAC は CPCH アクセ

ス要求のために希望するトランスポートフォーマットを選択する。MAC の CPCH 送信制御処理は、RRC か

ら受信して保持された値に基づいて、持続性（persistency）をチェックすることによって開始される。持続

性（persistency）チェックが通った場合には、PHY-Access-REQ プリミィティブを送信することによって物

理的な CPCH の送信処理が開始される。PCPCH 送信処理は、アクセスプリアンブル電力ランピングサイク

ル（access preamble power ramping cycle）で開始される。そして MAC は、L1 から PHY-Status-IND を通じて

ステータスが通知されるのを待つ。AP-AICH 上でアクセスプリアンブルの獲得（acquisition）が通知された

ならば、CD プリアンブルを PCPCH 上で送信する。Node B 内の CD プリアンブルの受信が、CD-ICH 上で

UE に通知される。CA がアクティブな場合には、チャネル割当情報が同時に CD/CA-ICH 上で送信される。

L1 は MAC に対してステータス情報を提供し、CD または CD/CA 情報を通知する。CA 情報は UE 内の L1上で PCPCH を定義して、プリアンブルとメッセージパートの電力制御に使用される。MAC は CPCH トラ

ンスポートブロックセットを組立てて、適切なトランスポートフォーマットといっしょに PHY-Data-REQ を

経由して送信する。トランスポートフォーマットは要求されたトランスポートフォーマットとは異なっても

よい。

電力制御プリアンブルの 0 または 8 スロットの周期の後、メッセージの最初の伝送ブロックセット (first TTI) が送信される。

最初の伝送ブロックセットが送信されている間、Node B の L1 はメッセージインジケータの開始を送信する。

UE がこのメッセージインジケータの開始を受信することによって、正しい CPCH チャネルを使用している

か否かを知ることができる。UE が一定期間内でメッセージインジケータを受信しなかった場合には、UE は

メッセージの送信を直ちに停止する。UE が一定期間内でメッセージインジケータを受信した場合には、UEは送信を継続する。

全てのデータが送信されるまで、あるいは送信データ量が最大フレーム長 [NF_max] に達するまで、CPCH上のデータ送信は継続される。もし UE が NF_max の以前にデータが無くなった場合には、UE は UTRAN に

End of Transmission indication を用いて CPCH 上に最大フレーム長[NF_max]以前にフレーム送信が終了する事

を知らせる事ができる。SRNC 内の RLC エンティティからのアクノリッジは、FACH 下りリンクトランスポ

ートチャネルを使用して、ネットワーク MAC によって UE RLC エンティティにルーチングされる。

図 21 中の A 点から B 点までのイベントが、first TTI 用の CPCH 送信処理を定義する。図 22 中の C 点から D点までのイベントが、その後に続く各 TTI 用の CPCH 送信処理を表す。

図 22 において E 点から F 点までのイベントが、UE が最大フレーム長[NF_max]以前に CPCH データ送信を

終了する CPCH 停止処理を表す。この場合 CPCH 送信の停止は NF_max 前の CPCH 送信の開放を起こす事が

できる。CPCH 送信の逓信は PHY-DATA-REQ プリミティブにより通知される。このプリミティブは TFI により通知されるトランスポートブロックをサイズゼロにする事で’end of transmittion”イベントを表す。

3GPP

3GPP TS 25.303 V3.9.0 (2001-09)51Release 1999

一時的に過負荷状況に達した場合のように、ネットワーク側の RRC から再試行（reacting）の要求があった

場合には、CPCH 送信の緊急停止を実行することができる。緊急停止は PHY-STATUS-IND プリミィティブ

によって通知される。

送信電力規制（これもまた PHY-STATUS-IND プリミィティブによって通知される）の場合にも、CPCH を

送信している間はいつでもトランスポートフォーマットの選択に関する規制が適用できることに注意するこ

と。

6.3.4 USCH 上のデータ送信（TDD のみ）（Data transfer on USCH (TDD only)）

図 23 に、USCH 上のデータ送信処理手順を示す。ここでは無線ベアラが、例えば 6.2.1.1.4 節で図示したよ

うな個別物理チャネルを使用しない無線ベアラ確立処理手順で確立され、かつその無線ベアラが USCH およ

び DSCH 上にマッピングされるものとする。関連する DCH の使用の有無にかかわらず、USCH の使用は可

能である。

UE 内の測定機能は、RACH もしくは USCH 上にマッピングされた SHCCH 論理チャネルを使用して、

Capacity Request をネットワークに送信するか否かを決定する。 C-RRC における、USCH/DSCH のスケジュ

ーリング機能は、物理リソースをこの論理チャネルに割当てるか否かを決定し、C-RNC 内の RRC は UE 内

のピアエンティティに PhyShChAllocation を送信する。このメッセージは、物理的リソースと、USCH トラ

ンスポートチャネル上で MAC-c/sh がデータを送信できる期間を規定する。

CRNC 内の RRC と UE の双方が、USCH 上でデータを送信するために L1 と MAC をそれぞれコンフィグレ

ーションし、規定の時間に UE 内の MAC-c/sh が規定された PUSCH リソースを使用してデータを運ぶ。

本オペレーションは、RLC バッファが空になるまで数回反復できる。

ダイヤグラム中では、PhyShChAllocation が PUSCH リソースに加えていくつかの PDSCH に対して割当てら

れると仮定する。その結果、割当てメッセージ中で規定された時間に、CRNC 内の RRC と UE の双方が、

DSCH 上でデータを送信するために L1 と MAC をそれぞれコンフィグレーションし、規定の時間に C-RNC 中の MAC-c/sh が UTRAN RLC のアクノリッジメッセージを規定の PDSCH リソースを使用してその UE ピ

アエンティティに送信する。

FACH を使用してアクノリッジメッセージを送信することも可能である。

3GPP

3GPP TS 25.303 V3.9.0 (2001-09)52Release 1999

SRNC-RRCSRNC-RLCCRNC-RRCSRNC-MACCRNC-MACNodeB-L1UE-L1UE-MACUE-RLCUE-RRC

Data transferin the user plane

RLC buffer scanning

Scheduling

MAC-Data-REQ

[PDU-Ack ]

USCH:Data

USCH:Data

USCH:DataMAC-Data-REQ

MAC-Data-REQ

MAC-Data-REQ

CMAC-C/SH/D-Config-REQ

MAC-Data-IND

MAC-Data-IND

MAC-Data-IND

MAC-Data-IND

[PDU-Ack ]

DPSCH DSCH/FACH :

[PDU-Ack ]

CMAC-C/SH-Config-REQCMAC-C/SH/D-Config-REQ


SHCCH: MAC-Unit-Data-IND

[PhyShChAllocation ]


[ Capacity Request ]

SHCCH:MAC-Unit-Data-REQ

[PhyShChAllocation ]FACH/USCH: SHCCH-Data

[PhyShChAllocation ]

RACH/USCH: SHCCH-Data


SHCCH:MAC-Unit-Data-REQ


IubUu

図 23: USCH 上のデータ送信

6.3.5 DSCH 上のデータ送信（TDD のみ）（Data transfer on DSCH (TDD only)）

図 24 中に、DSCH 上のデータ送信手順を示す。ここでは無線ベアラが、例えば 6.2.1.1.4 節で図示したよう

な個別物理チャネルを使用しない無線ベアラ確立処理手順で確立され、その無線ベアラが USCH および

DSCH トランスポートチャネル上にマッピングされるものと仮定する。

関連する DCH の使用の有無にかかわらず、DSCH の使用は可能である。

C-RRC における USCH/DSCH のスケジューリング機能は、下りリンクの物理リソース割当てを決定し、C-RNC 内の RRC は UE 内のピアエンティティに対して、FACH または DSCH 上にマッピングされた SHCCHを使用して PhyShChAllocation を送信する。このメッセージは、物理リソースと、DSCH トランスポートチ

ャネル上で MAC-c/sh がデータを送信できる期間を規定する。

CRNC 内の RRC と UE の双方が、DSCH 上でデータを送信するために L1 と MAC をそれぞれコンフィグレ

ーションし、規定の時間に C-RNC 内の MAC-c/sh が、規定された PDSCH リソースを使用してデータを運ぶ。

3GPP

3GPP TS 25.303 V3.9.0 (2001-09)53Release 1999

本オペレーションは、RLC バッファが空になるまで数回反復できる。

ダイヤグラム中では、PhyShChAllocation が PDSCH リソースに加えていくつかの PUSCH に対して割当てら

れると仮定する。その結果、割当てメッセージ中で規定された時間に、CRNC 内の RRC と UE の双方が

USCH 上でデータを送信するために L1 と MAC をそれぞれコンフィグレーションし、規定の時間に UE 中の

MAC-c/sh が UE のアクノリッジメッセージを、規定の PUSCH リソースを使用してその C-RNC ピアエンテ

ィティに送信する。

RACH を使用してアクノリッジメッセージを送信することも可能である。

SRNC-RRCSRNC-RLCCRNC-RRCSRNC-MACCRNC-MACNodeB-L1UE-L1UE-MACUE-RLCUE-RRC

RLC buffer scanningScheduling

MAC-Data-REQ

[PDU-Ack ]

DSCH:Data

DSCH:Data

DSCH:Data MAC-Data-REQ

MAC-Data-IND

CMAC-C/SH/D-Config-REQ

MAC-Data-REQ

MAC-Data-REQ

[PDU-Ack ]

USCH/RACH:

[PDU-Ack ]

CMAC-C/SH-Config-REQCMAC-C/SH/D-Config-REQ


IubUu

[ PhyShCh Allocation ]


FACH/DSCH: SHCCH Data

[ PhyShChAllocation ]

SHCCH:MAC-Unit -Data-REQ

[ PhyShCh Allocation ]

MAC-Data-IND

MAC-Data-IND

Data transferin the user plane

MAC-Data-IND

MAC-Data-IND

図 24: DSCH 上のデータ送信

6.4 RRC コネクションのモビリティ処理手順（RRC Connection mobility procedures）

RRC ハンドオーバプロトコルは、FDD と TDD とで必ず共通でなくてはならない。このことは、同一のプロ

トコルが、以下のハンドオーバ手順すべてを必ずサポートする必要があることを意味する。

3GPP

3GPP TS 25.303 V3.9.0 (2001-09)54Release 1999

6.4.1 ハンドオーバ測定レポート（Handover Measurement Reporting）図 25 に、ハンドオーバの測定に測定制御と測定レポートの処理手順を使用した場合の例を示す。NW RRCは UE に対して、MEASUREMENT CONTROL メッセージを送信して測定とレポートの開始を要求する。メ

ッセージには、測定タイプ（例：帯域内測定など）の通知、評価対象となる無線リンク、レポート基準、お

よび測定 ID 番号が含まれる。UE は L1 をコンフィグレーションして測定を開始する。測定レポート基準が

満たされた時、UE は MEASUREMENT REPORT メッセージを送信する。

UE-RRC UE-L1 SRNC-RRC

Uu Iub

MEASUREMENT CONTROL

Reportingcriteriafulfilled

CPHY-Measurement-REQ

CPHY-Measurement-IND

MEASUREMENT REPORT

CPHY-Measurement-IND

Measurement

Measurement

図 25: ハンドオーバ測定レポート

6.4.2 セルの更新（Cell Update）図 26 に、セル更新手順の例を示す。

セル更新手順は、UE のセル再選択機能によってトリガされる。セル再選択機能は、UE がどのセルに切替え

るべきか指示を与える。UE は新しいセルからのブロードキャスト情報を読み取る。それに続いて、 UE のRRC レイヤは、UTRAN の RRC に対して、CCCH 論理チャネルおよび RACH トランスポートチャネルを使

用して CELL UPDATE メッセージを送信する。RACH 送信には、現行の S-RNTI および SRNC の ID が含ま

れる。

UE から CELL UPDATE を受信した UTRAN は、セル変更を登録する。登録が成功した場合には、UTRANは UE に対して、CELL UPDATE CONFIRM メッセージを DCCH/FACH 上で送信して応答する。メッセージには、現行の S-RNTI および SRNC の ID が含まれ、また新しい S-RNTI および／または S-RNTI + SRNCの ID が含まれる。メッセージ確認用に DCCH を使用する場合、メッセージ内容を暗号化することができる。

3GPP

3GPP TS 25.303 V3.9.0 (2001-09) 55Release 1999

CPHY-RL-Release-REQ (Stop RX and TX)

[Cell Update]

CCCH: RACH: CCCH Message

[Cell Update Confirm]MAC-C/SH-Data-REQ

UE-RRC UE-MAC UE-L1 Node B-MAC RNC-L1 CRNC-MAC SRNC-RRC

Uu Iub

Cell reselectiontriggered

SRNC-MAC

CPHY-RL-Setup-REQ (Start RX)

CPHY-Sync-IND

BCCH: BCH: Message

[System info]

MAC-B-Data-IND

[New system info]

CPHY-RL-Setup-REQ (Start TX)

Registerchange of

cell

MAC-D-Data-REQ

[Cell Update Confirm]

DCCH: FACH: DCCH Message


RLC-Tr-Data-IND


MAC-C/SH-Data-REQ

[Cell Update]

IurUE-RLC SRNC-RLC

RLC-Tr-Data-REQ

[Cell Update]

RLC-Tr-Data-REQ


MAC-D-Data-IND


図 26: セルの更新処理手順

3GPP

3GPP TS 25.303 V3.9.0 (2001-09)56Release 1999

6.4.3 URA の更新（URA Update）図 27 に、URA の更新処理手順の例を示す。CCCH または DCCH の送信の、レイヤ間相互作用の詳細につい

ては、前節「セルの更新」（"Cell Update"）を参照。

セル再選択がトリガされると、UE は旧セル内の無線リンクを解放し、新しいセルと無線リンクを確立する。

UE が新しいセルからのブロードキャスト情報を読み出して、URA 更新の必要性を認識すると、URA 更新手

順がトリガされる。その後、UE の RRC レイヤは、UE の MAC レイヤに対して CCCH 上で URA UPDATE を送信する。UE の MAC レイヤは UTRAN に RACH 上でメッセージを送信する。RACH 送信には、現行の S-RNTI および SRNC の ID が含まれる。

UTRAN は URA UPDATE を受信すると、URA の更新を登録する。そして、CRNC-RRC は CRNC-MAC に対

して、FACH 上で URA UPDATE CONFIRM メッセージを UE に送信するよう要求する。メッセージには現

行の S-RNTI および SRNC の ID が含まれ、また新しい C-RNTI、S-RNTI、および SRNC の ID を含むことも

できる。

URA UPDATE CONFIRM メッセージの送信にどの論理チャネルを使用するかは、SRNC 再配置ポリシに依存

する。URA UPDATE CONFIRM が送信される前に常に SRNC が再配置されるならば、DCCH を使用すべき

である（メッセージ内容の暗号化が可能であるため）。SRNC が再配置されないならば、CCCH 論理チャネ

ルを使用すべきである。そうすれば、本処理のために Iur 上で u-plane をセットアップすることなしに、

RNSAP Iur 処理を利用することができる。

3GPP

3GPP TS 25.303 V3.9.0 (2001-09) 57Release 1999

UE-RRC UE-MAC UE-L1 Node B-MAC RNC-L1 CRNC-MAC SRNC-RRC

Uu Iub

URA reselectiontriggered

CPHY-RL-Release-REQ (Stop RX and TX)

CPHY-RL-Setup-REQ (Start RX)

CPHY-Sync-IND

BCCH: BCH: BCCH Message

[System info]

MAC-B-Data-IND

[New system info]

CPHY-RL-Setup-REQ (Start TX)

Registerchange of

URA

CCCH: RACH: URA UPDATE

Iur

Continue to Aor B

図 27: URA 更新処理の開始・・・ケース A またはケース B に続く

3GPP

3GPP TS 25.303 V3.9.0 (2001-09) 58Release 1999 ケース A: DCCH 上の URA UPDATE CONFIRM：

UE-RRC UE-MAC UE-L1 RNC-L1 CRNC-MAC SRNC-RRC

Uu Iub Iur

DCCH: FACH: URA UPDATE CONFIRM

図 28: ケース A、URA 更新手続きの続き、CONFIRM メッセージの暗号化が可能

ケース B: CCCH 上の URA UPDATE CONFIRM：

本ケースでは、SRNC と CRNC 間の送信は RNSAP Downlink Signalling Transfer 上で行われ、CCCH 論理チャネルが使用される。

UE-RRC UE-MAC UE-L1 RNC-L1 CRNC-MAC SRNC-RRC

Uu Iub Iur

CCCH: FACH: URA UPDATE CONFIRM

図 29: ケース B、URA 更新手順の続き、CONFIRM メッセージの暗号化は不可能

3GPP

3GPP TS 25.303 V3.9.0 (2001-09)59Release 1999

6.4.4 無線リンクの追加（FDD）（Radio Link Addition）

UE-RRC UE-L1 NodeB -L1 RNC-L1 SRNC-RRC

Uu Iub

Radio link addition triggered

CPHY-RL-Setup-REQ

CPHY-RL-Setup-CNF

Start RX andTX

ACTIVE SET UPDATE

CPHY-RL-Setup-REQ

Start RX

CPHY-RL-Setup-CNF

ACTIVE SET UPDATE COMPLETE

CPHY-RL-Setup-REQ

図 30: 無線リンクの追加

図 30 に無線リンクの追加処理手順を示す。UE から送信される測定レポートによって、ネットワークの

RRC レイヤ内で無線リンクの追加がトリガされる。NW RRC は、まず Node B 内の物理レイヤで新しい無線

リンクをコンフィグレーションする。直ちに送受信が開始される。次に NW RRC は、UE の RRC に対して

RRC ACTIVE SET UPDATE メッセージを送信する。UE RRC は物理レイヤをコンフィグレーションし、受

信を開始する。

UE は UE 物理レイヤからの同期確立通知を待たずに ACTIVE SET UPDATE COMPLETE メッセージを RNC-RRC に送信する。

6.4.5 無線リンクの削除(FDD)（Radio Link Removal）

3GPP

3GPP TS 25.303 V3.9.0 (2001-09)60Release 1999

Uu IubUE-RRC UE-L1 NodeB-L1 RNC-L1 SRNC-RRC

Radio linkremovaltriggered

CPHY-RL-Release-REQ

CPHY-RL-Release-CNF

Stop RX andTX

ACTIVE SET UPDATE

CPHY-RL-Release-REQ

Stop RX


CPHY-RL-Release-REQ

図 31: 無線リンクの削除

図 31 に無線リンクの削除手順を示す。UE から送信された測定レポートによって、ネットワークの RRC レ

イヤ内のアルゴリズムが無線リンクの削除をトリガする。ネットワーク内の負荷制御アルゴリズムによって

無線リンクの削除がトリガされることもある。無線リンクはまず始めに UE 側で停止され、続いてネットワ

ーク側で停止される。

NW RRC は UE RRC に対して ACTIVE SET UPDATE メッセージを送信する。UE RRC は UE L1 に対して削

除すべき無線リンク（1 つまたは複数）の受信を終了するよう、要求する。その後 UE RRC は、NW RRC に対して ACTIVE SET UPDATE COMPLETE メッセージ送信し、無線リンク削除の確認（acknowledges radio link removal）を行う。NW RRC は、Node B および RNC 双方のネットワーク L1 に対して、無線リンクの解

放の要求を進める。

3GPP

3GPP TS 25.303 V3.9.0 (2001-09)61Release 1999

6.4.6 無線リンクの追加と削除の組合せ（Combined radio link addition and removal）


Uu Iub

CPHY-RL-Release-REQ


Radio link additionand removal

triggered

CPHY-RL-Setup-REQ

CPHY-RL-Setup-CNF

Start rx / tx

ACTIVE SET UPDATE

CPHY-RL-Setup-REQ

Start rx

Stop rx

CPHY-RL-Release-REQ

Stop rx / tx

CPHY-RL-Release-CNF

CPHY-RL-Setup-REQ

CPHY-RL-Setup-REQ

図 32: 無線リンクの追加と削除の組合せ

図 32 に、無線リンクの追加と削除の組合せ処理を示す。NW RRC は、受信した測定レポートまたは負荷制

御アルゴリズムに基づき、無線リンク置換の必要性を決定する。

無線リンクを置換する必要がある場合、最初に NW RRC がネットワーク L1 をコンフィグレーションし、追

加すべき無線リンク（1 つまたは複数）を活性化する。次に NW RRC は、UE RRC に対して ACTIVE SET UPDATE メッセージを送信し、UE RRC は UE L1 をコンフィグレーションして、削除された無線リンクの受

信を終了して、追加された無線リンクの受信を開始する。

UE のアクティブセットが一杯になった場合には、無線リンクの置換処理を実行する必要がある。その手順

を図 32 に示す。UE が持つ無線リンクが 1 つだけの場合には、置換は逆の手順（最初に追加して次に削除）

で行うこと。

UE RRC は、ACTIVE SET UPDATE COMPLETE メッセージを使用して置換の確認（acknowledges the replacement）を行う。次に NW RRC はネットワーク L1 をコンフィグレーションし、除去された無線リンク

上での受信を終了する。

3GPP

3GPP TS 25.303 V3.9.0 (2001-09)62Release 1999

6.4.7 ハードハンドオーバ（FDD と TDD）(Hard Handover )


Uu Iub

CPHY-RL-Setup-REQ

PHYSICAL CHANNEL RECONFIGURATION COMPLETE (acknowledged on L2)

Inter-handover

CPHY-RL-Setup-REQ

CPHY-RL-Setup-CNF

Start new rx / tx

PHYSICAL CHANNEL RECONFIGURATION

CPHY-RL-Release-REQ

Stop rx / tx

Start rx / tx

CPHY-RL-Release-REQ

Stop old rx / tx

CPHY-RL-Release-CNF

Layer 1 synchronisation

CPHY-Sync-IND

CPHY-RL-Setup-REQ

Layer 2 link established

CPHY-RL-Release-REQ

図 33: ハードハンドオーバ

図 33 にハードハンドオーバの手順を示す。NW RRC は、受信した測定レポートまたは負荷制御アルゴリズ

ムに基づき、ハードハンドオーバの必要性を決定する。

周波数間ハードハンドオーバの場合には、測定はスロットモードで行われると仮定される。

最初に NW RRC はネットワーク L1 をコンフィグレーションし、新しい無線リンクを起動する。ネットワー

ク L1 は直ちに新しいリンク上で送受信を開始する。次に NW RRC は UE RRC に対して PHYSICAL CHANNEL RECINFIGURATION メッセージ（あるいは他のメッセージ群、例えば RADIO BEARER RECONFIGURATION と TRANSPORT CHANNEL RECONFIGURATION がハードハンドオーバを実行するの

に使用可能）を送信する。メッセージには、新しい無線リンク用に使用すべき無線リソースが示される。

UE RRC は UE L1 をコンフィグレーションし、旧い無線リンク上での受信を終了し、新しい無線リンク上で

の受信を開始する。

UE L1 が新しい周波数で下りリンクの同期を確立した後、L2 リンクが確立され、UE RRC は NW RRC に対

して PHYSICAL CHANNEL RECONFIGURATION COMPLETE メッセージを送信する。L3 上で確認

（acknowledgement）を受信後、NW RRC はネットワーク L1 をコンフィグレーションして旧無線リンク上の

送受信を終了する。

3GPP

3GPP TS 25.303 V3.9.0 (2001-09)63Release 1999

6.4.8 SRNS 再配置 (SRNS Relocation) SRNS 再配置処理は２つのフェーズに分割できる。最初のフェーズは再配置準備段階で、リソースが

予約される。２番目のフェーズは Serving RNS の転送がソースからターゲット RNC に起きる事で新し

い RAB が確立される。

ロス無しの無線ベアラは、ロス無しの SRNS 再配置をサポートするために構成された AM の RB であ

る。シームレスの無線ベアラは、UM 又はロス無しの SRNS 再配置をサポートするために構成されな

い AM の RB である。

SRNS 再配置が実行できる３つのケースを以下に記述する。

- Serving SRNS 再配置。これは UTRAN 側の UTRAN-CN の接続ポイントがソース SRNC からタ

ーゲット RNC に移動させる場合。

- ハードハンドオーバと SRNS 再配置の組合せ。これは UTRAN によるハードハンドオーバを実

行中に UTRAN 側の UTRAN-CN の接続ポイントがソース SRNC からターゲット RNC に移動さ

せる場合。

- Cell/URA 更新と SRNS 再配置の組合せ。これは UTRAN でセル再選択を実行中に UTRAN 側の

UTRAN-CN の接続ポイントがソース SRNC からターゲット RNC に移動させる場合。

これらはセクション 6.4.8.1,6.4.8.2(ロス無しの無線ベアラの場合),6.4.8.3,6.4.8.4(シームレスの無線ベア

ラの場合)及び[6]により詳しく記述されている。

6.4.8.1 Cell/URA 更新と SRNS 再配置の組合せ（ロス無し無線ベアラ）(Combined Cell/URA Update and SRNS relocation (lossless radio bearers))

SRNS 再配置の実行を決定したソース RNC により処理が開始される。ケース１を UE を伴わない時の

状況として図 34 に示し、ケース２として UE を伴い Cell/URA 更新と SRNS 再配置の組合せを実行す

る時の状況も併せて図 34 に示す。

CN からの RANAP 再配置コマンドをソース RNC が受信する。これには開放すべき RAB とデータ転

配すべき RAB が指示されている。データ転配すべき RAB を設定する場合には常に、かつこの場合に

限り、ロス無し SRNS 再配置が行われる。[7]に記述されているロス無し SRNS 再配置がサポートされ

る場合には PDCP レイヤは PDCP シーケンス番号付与をサポートしなくてはならない。

影響される無線ベアラに対して、RLC エンティティが停止し PDCP シーケンス番号が RRC により検

索される。PDCP 送信および受信シーケンス番号はソースからロス無し SRNC 再配置をサポートする

RAB のターゲット RNC に RNSAP 再配置コミット(RANAP Relocation Commit)メッセージにより伝送

される。ターゲット RNC は RANAP 再配置検出(RANAP Relocation Detect)メッセージを送信した時点

でサービング RNC となる。

ターゲット RNC はその後 UTRAN MOBILITY INFORMATION (ケース１)か CELL/URA UPDATE CONFIRM (ケース２)を送信する。これは、UE に新しい U-RNTI を設定し、ロス無し SRNS 再配置を

サポートするために設定した各無線ベアラに上りリンク受信 PDCP シーケンス番号が示される。UEは上りリンク受信 PDCP シーケンス番号と UE 上りリンク送信 PDCP シーケンス番号を比較する。も

しこの比較により PDCP SDU が再配置開始前に送信が成功したと確認された場合には、すなわちソー

ス RNC により既に受信されているという事で、これらは UE により廃棄される。UE はヘッダ圧縮プ

ロトコル([7]を参照)を使用するように設定された無線ベアラの PDCP ヘッダ圧縮エンティティを再初

期化する。

もし UE が自分自身の設定に成功している場合には、UTRAN MOBILITY INFORMATION CONFIRM(ケース 1 とケース 2 の両方)を送信する。これらのメッセージには START 値とロス無し

SRNS 再配置をサポートするために設定した各無線ベアラに下りリンク受信 PDCP シーケンス番号が

含まれている。UTRAN は下りリンク受信 PDCP シーケンス番号と下りリンク送信 PDCP シーケンス

3GPP

3GPP TS 25.303 V3.9.0 (2001-09)64Release 1999

番号を比較する。UTRAN はヘッダ圧縮プロトコル([7]を参照)を使用するように設定された無線ベア

ラの PDCP ヘッダ圧縮エンティティを再初期化する。影響を受ける無線ベアラに対しては RLC エンテ

ィティは現在の設定で再起動され（文献[2]）UE RLC のすべてのデータバッファが廃棄される。

失敗の場合には、UE は UTRAN MOBILIRY INFORMATION FAILURE(ケース 1)又は CELL/URA UPDATE FAILURE(ケース２)メッセージを送る必要がある。

UTRAN MOBILIRY INFORMATION FAILURE(ケース 1)又は CELL/URA UPDATE FAILURE(ケース２)メッセージを受信したら、UTRAN は PDCP エンティティをスタートさせ再配置処理を終了させる必

要がある。

3GPP

3GPP TS 25.303 V3.9.0 (2001-09) 65Release 1999

(Triggered by RANAP Relocation Commit)

CPDCP-RELOC-Req(Receive_SN)

target RNCUE-RRC UE-RLC

Uu IubIur / Iu

UE-PDCPtarget

RNC-RLCtarget

RNC-PDCPtarget

RNC-RRC

RANAP: Relocation Command (from old SGSN)

source RNC

source RNC-RLC

source RNC-PDCP

source RNC-RRC

Decision to perform SRNS relocation (could be initiated by CELL/URA UPDATE from UE)

Relocation Preparation

CPDCP-RELOC-Req

CPDCP-RELOC-Conf (Send_SN, Receive_SN)

RNSAP: Relocation Commit Forwarding of Data

RRC: UTRAN MOBILITY INFORMATION (Case I); CELL/URA UPDATE CONFIRM (Case II)

(New U-RNTI, Receive_SN)

CPDCP-RELOC-Conf (Receive_SN)

RRC: UTRAN MOBILITY INFORMATION CONFIRM ( Case I and Case II) (Receive_SN, START)

RRC: CELL/URA UPDATE (Case II)

RANAP: Relocation Detect (to new SGSN)

CRLC-CONFIG-Req(Stop)


CPDCP-SN-Req (PDCP_SN)

CRLC-CONFIG-Req (Re-establish/Reconfigure) CRLC-CONFIG-Req

(Establish)

RANAP: Relocation Complete(to new SGSN)

図 34: Cell/URA 更新と SRNA 再配置の組合せ(ロス無し無線ベアラ)

3GPP

3GPP TS 25.303 V3.9.0 (2001-09)66Release 1999

6.4.8.2 ハードハンドオーバと SRNS 再配置の組合せ（ロス無し無線ベアラ）(Combined Hard Handover and SRNS relocation (lossless radio bearers))

測定結果と UTRAN トポロジーの情報を基にして、ソース SRNC はハードハンドオーバと SRNC 再配

置の組合せを起動する事を決める。UE はこの時まだ SRNC の制御下にあるがターゲット RNC の制御

化の位置に動こうとしている。

CN からの RANAP 再配置コマンド(RANAP Relocation Command)をソース RNC が受信する。これには

開放すべき RAB とターゲット RNC からソース RNC の透過コンテナ(Transparent Container)とデータ配

送すべき RAB が指示されている。データ配送すべき RAB を設定する時は必ず、またこの場合のみ、

ロス無し SRNS 再配置が行われる。[7]に記述されているロス無し SRNS 再配置がサポートされる場合

には PDCP レイヤは PDCP シーケンス番号付与をサポートしなくてはならない。

ターゲット RNC からソース RNC への透過コンテナはハードハンドオーバのための RRC メッセージ

（たとえば、PHYSICAL CHANNEL RECONFIGURATION）を含む。

RANAP 再配置コマンドの受信によりソース RNC 上の RRC エンティティは影響する無線ベアラの

RLC エンティティを停止し、PDCP シーケンス番号を保存する。これはまたアクノリッジモードでの

個別シグナリング無線ベアラ（SRB#2）を用いて UE へ RRC メッセージを送り SRNS 再配置実行の開

始のトリガとなる。このメッセージには、新しい（ターゲット RNC からの）U-RNTI と（ソース

RNC からの）ロス無し SRNS 再配置をサポートするために設定された各無線ベアラに上りリンク受信

PDCP シーケンス番号が含まれる。UE はヘッダ圧縮プロトコル（文献[7]）を使用するために設定さ

れた無線ベアラの PDCP ヘッダ圧縮エンティティを再初期化する。

PDCP はシーケンス番号を送受信し、SRNS コンテキストをソース RNC からターゲット RNC へ転送

する間、現在の下りリンクと上りリンク HFN 値は CN を経由して転送される。ターゲット RNC は

RANAP Relocation Detect メッセージが送出された時サービング RNC になる。

UE がメッセージの受信と確認を行ったところで、アクノリッジモードでの個別シグナリング無線ベ

アラ（SRB#2）の RLC エンティティが UTRAN と UE の両方で再確立され、各 HFN 値は現在の下り

リンクと上りリンク HFN 値に１を足した値にセットされる。SRNS 再配置のタイミングは URAN に

よって注意深く実行される事で、この処理における SRB#2 の SN ロールオーバのリスクは存在しない。

UE は上りリンク受信 PDCP シーケンス番号と UE 上りリンク送信 PDCP シーケンス番号を比較する。

もしこの比較により PDCP SDU が再配置開始前に送信が成功したと確認された場合には、すなわちソ

ース RNC により既に受信されているという事で、これらは UE により廃棄される。

もし UE が自分自身の設定に成功している場合には応答メッセージを、この場合では PHYSICAL CHANNEL RECONFIGURATION COMPLETE メッセージをターゲット RNC にアクノリッジモードで

の個別シグナリング無線ベアラ（SRB#2）を用いて送信する。このメッセージには START 値とロス

無し SRNS 再配置をサポートするために設定した各無線ベアラに下りリンク受信 PDCP シーケンス番

号が含まれている。

メッセージの確認が行われたところで、影響する無線ベアラの RLC エンティティは UTRAN と UE の

両側で再確立される。各 RB の HFN 値は対応する CN ドメインのメッセージの START 値がセットさ

れる。

UTRAN は下りリンク受信 PDCP シーケンス番号と下りリンク送信 PDCP シーケンス番号を比較する。

UTRAN はヘッダ圧縮プロトコル（文献[7]）を使用するために設定された無線ベアラの PDCP ヘッダ

圧縮エンティティを再初期化する。

UTRAN と UE は、影響する RB の各 RLC と PDCP エンティティを継続させ、再配置処理を終了する。

3GPP

3GPP TS 25.303 V3.9.0 (2001-09) 67Release 1999

(Triggered by detectionof the UE as indicatedfrom the lower layers)

targetRNCUE-RRC UE-RLC

Uu IubIur / Iu

UE-PDCPtarget

RNC-RLCtarget

RNC-PDCPtarget

RNC-RRC

RANAP: Relocation Command(from old SGSN)

sourceRNC

sourceRNC-RLC

sourceRNC-PDCP

sourceRNC-RRC

UE involved


CPDCP-RELOC-Req

CPDCP-RELOC-Conf(Send_SN, Receive_SN)

RANAP: Relocation Detect(to new SGSN)

Forwarding of Data

RRC: PHYSICAL CHANNEL RECONFIGURATION(New U-RNTI, Receive_SN)

CPDCP-RELOC-Conf(Receive_SN)

RRC: PHYSICAL CHANNEL RECONFIGURATION COMPLETE(Receive_SN, START)

Forwarding of SRNS contexts via the CN

CPDCP-RELOC-Conf(Send_SN, Receive_SN)

Decision to perform SRNS relocation


CPDCP-RELOC-Req(Receive_SN)


CPDCP-SN-Req(PDCP_SN)

UE detected by target RNC


CRLC-CONFIG-Req(Re-establish/Reconfigure) CRLC-CONFIG-Req

(Establish)

図 35: ハードハンドオーバと SRNC 再配置の組合せ(ロス無し無線ベアラ)

3GPP

3GPP TS 25.303 V3.9.0 (2001-09)68Release 1999

6.4.8.3 Cell/URA 更新と SRNS 再配置の組合せ（シームレス無線ベアラ）(Combined Cell/URA Update and SRNS relocation (seamless radio bearers))

SRNS 再配置の実行を決定したソース RNC により処理が開始される。ケース１を UE を伴わない時の

状況として図 36 に示し、ケース２として UE を伴い Cell/URA 更新と SRNS 再配置の組合せを実行す

る時の状況も併せて図 36 に示す。

CN からの RANAP 再配置コマンドをソース RNC が受信する。これには開放すべき RAB が指示され

ている。ソース RNC はシームレス SRNS 再配置をサポートする無線ベアラでターゲット RNC がサー

ビング RNC になるまで下りリンクデータ送信を継続する。ターゲット RNC は RANAP 再配置検出メ

ッセージを送出した時点でサービング RNC となる。

ターゲット RNC はその後 UTRAN MOBILITY INFORMATION (ケース１)か CELL/URA UPDATE CONFIRM (ケース２)を送信する。これは、UE に新しい U-RNTI を設定する。

もし UE が自分自身の設定に成功している場合には、UTRAN MOBILITY INFORMATION CONFIRM(ケース 1 とケース 2 の両方)を送信する。これらのメッセージには START 値（これは UMや AM RLC で使用する無線ベアラ上のデータ完全性保護や暗号化に使用される）が含まれている。

UTRAN はヘッダ圧縮プロトコル（文献[7]）を使用するために設定された無線ベアラの PDCP ヘッダ

圧縮エンティティを再初期化する。影響を受ける無線ベアラに対しては RLC エンティティは現在の

設定で再起動される（文献[2]）。

UTRAN MOBILIRY INFORMATION FAILURE(ケース 1)又は CELL/URA UPDATE FAILURE(ケース２)メッセージを受信したら、UTRAN は再配置処理が終了する。

3GPP

3GPP TS 25.303 V3.9.0 (2001-09) 69Release 1999

(Triggered byRANAP RelocationCommit)

targetRNCUE-RRC UE-RLC

Uu IubIur / Iu

UE-PDCPtarget

RNC-RLCtarget

RNC-PDCPtarget

RNC-RRC

RANAP: Relocation Command(from old SGSN)

sourceRNC

sourceRNC-RLC

sourceRNC-PDCP

sourceRNC-RRC

Decision to performSRNS relocation (couldbe initiated byCELL/URA UPDATEfrom UE)


RNSAP: Relocation Commit

RRC: UTRAN MOBILITY INFORMATION (Case I); CELL/URA UPDATE CONFIRM(Case II)

(New U-RNTI)

RRC: UTRAN MOBILITY INFORMATION CONFIRM ( Case I and Case II) (START)

RRC: CELL/URA UPDATE (Case II)

RANAP: Relocation Detect(to new SGSN)

CRLC-CONFIG-Req(Establish)


CRLC-CONFIG-Req(Re-establish)

Figure 36: Combined Cell/URA Update and SRNS relocation (seamless radio bearers)

3GPP

3GPP TS 25.303 V3.9.0 (2001-09)70Release 1999

6.4.8.4 Combined Hard Handover and SRNS relocation (seamless radio bearers)

測定結果と UTRAN トポロジーの情報を基にして、ソース SRNC はハードハンドオーバと SRNC 再配

置の組合せを起動する事を決める。UE はこの時まだ SRNC の制御下にあるがターゲット RNC の制御

化の位置に動こうとしている。

ソース RNC は、ターゲット RNC がサービング RNC になるまで、シームレス SRNC 再配置をサポー

トする無線ベアラ上で下りリンクデータ送信を続ける。ターゲット RNC は RANAP 再配置検出

(RANAP Relocation Detect)メッセージを送信した時点でサービング RNC となる。

CN からの RANAP 再配置コマンド(RANAP Relocation Command)をソース RNC が受信する。これには

開放すべき RAB が指示されている。ターゲット RNC からソース RNC への透過コンテナはハードハ

ンドオーバのための RRC メッセージ（たとえば、PHYSICAL CHANNEL RECONFIGURATION）を含

む。このメッセージには、新しい U-RNTI が含まれる。

RANAP 再配置コマンドの受信によりソース RNC は個別シグナリング無線ベアラのアクノリッジモー

ドを用いて UE に RRC メッセージを送出する事による SRNS 再配置実行を開始する。”forwarding of SRNS contexts via the CN” フェーズの間、現在の下りリンクと上りリンク HFN 値はソース RNC からタ

ーゲット RNC へ転送される。

PHYSICAL CHANNEL RECONFIGURATION COMPLETE メッセージを UE が受信し確認すると、アク

ノリッジモードでの個別シグナリング無線ベアラ（SRB#2）用の RLC エンティティが UTRAN（ター

ゲット SRNC）と UE の両方で再確立される。そして各 HFN 値は現在の下りリンクと上りリンク HFN値に１を足した値にセットされる。SRNS 再配置のタイミングは URAN によって注意深く実行される

事で、この処理における SRB#2 の SN ロールオーバのリスクは存在しない。

もし UE が自分自身の設定に成功している場合にはレスポンスメッセージ、この場合には PHYSICAL CHANNEL RECONFIGURATION COMPLETE メッセージをアクノリッジモードでの個別シグナリング

無線ベアラ（SRB#2）を用いてターゲット RNC に送信する。このメッセージは新 RLC コンテキスト

をベースに送信され、これには START 値（これは UM や AM RLC で使用する無線ベアラ上のデータ

完全性保護や暗号化に使用される）が含まれている。UTRAN はヘッダ圧縮プロトコル（文献[7]）を

使用するために設定された無線ベアラの PDCP ヘッダ圧縮エンティティを再初期化する。

メッセージの確認の時点で影響する無線ベアラの残りの RLC エンティテイが UTRAN と UE の両方で

再確立される。各 RB の HFN 値は対応する CN ドメインのメッセージの START 値がセットされる。

シグナリング無線ベアラの（SRB#2 以外の）残りの各 HFN 値は最後に設定された CN ドメインのメ

ッセージの START 値がセットされる。

再配置処理はこれで終了する。

3GPP

3GPP TS 25.303 V3.9.0 (2001-09) 71Release 1999

(Triggered by detection of the UE as indicated from the lower layers)

target RNCUE-RRC UE-RLC

Uu Iub Iur / Iu

UE-PDCPtarget

RNC-RLCtarget

RNC-PDCPtarget

RNC-RRC

RANAP: Relocation Command (from old SGSN)

source RNC

source RNC-RLC

source RNC-PDCP

source RNC-RRC


RANAP: Relocation Detect (to new SGSN)

RRC: PHYSICAL CHANNEL RECONFIGURATION on AM RLC (New U-RNTI)

RRC: PHYSICAL CHANNEL RECONFIGURATION COMPLETE on AM RLC (with START value)

Decision to perform SRNS relocation

UE detected by target RNC

RANAP: Relocation Complete (to new SGSN)

CRLC-CONFIG-Req (Establish SRB 2 and increment HFN)

CRLC-CONFIG-Req (Re-establish SRB 2 and increment HFN)

Forwarding of SRNS contexts via the CN (Including the last START value for each CN domain)

UE involved

CRLC-CONFIG-Req (Re-establish with START)

CRLC-CONFIG-Req (Establish with START)

CPDCP-CONFIG-Req (Re-initialisation)

CPDCP-CONFIG-Req (Initialisation)

Figure 37: Combined Hard Handover and SRNS relocation (seamless radio bearers)

3GPP

3GPP TS 25.303 V3.9.0 (2001-09) 72Release 1999

6.4.9 RRC コネクションの再確立（RRC Connection re-establishment）

UE-RRC UE-RLC UE-MAC UE-L1 NodeB -L1 RNC-L1 CRNC-MAC SRNC-RLC SRNC-RRC

Uu Iub

CCCH: RRC CONNECTION RE-ESTABLISHMENT REQUEST

CPHY-RL-Setup-CNF

Start rx / tx

CCCH: RRC CONNECTION RE-ESTABLISHMENT

CPHY-RL-Setup-REQ

Start rx / tx


L1 synchronisation

CRLC-Config-REQ

CRLC-configure-REQ

CPHY-Sync-IND

CPHY-RL-Setup-REQ

CPHY-Sync-IND

CPHY-RL-Setup-REQ

SRNC-MAC


CMAC-D-Config-REQ

CCCH: RRC CONNECTION RE-ESTABLISHMENT COMPLETE

図 38: RRC コネクションの再確立

3GPP

3GPP TS 25.303 V3.9.0 (2001-09)73Release 1999

図 38 に例えば無線リンクの不具合などによって UE が無線コネクションを失った場合の処理の例を示す。

新しいセルを選択後、UE RRC は NW RRC に対して CELL UPDATE メッセージを送信する。CELL UPDATE メッセージは無線リンクの不具合によりこのメッセージが送られたという情報を含む。NW RRC はネットワ

ークをコンフィグレーションし、CELL UPDATE CONFIRM メッセージを送信して、コネクション再確立の

確認（acknowledges the connection re-establishment）とする。UE RRC は UE L1 をコンフィグレーションして

新しい無線リンクを起動する。UE が少なくとも 1 つの無線リンクに対して同期を確立した後、（必要な場

合には）MAC および RLC レイヤをコンフィグレーションできる。

処理が UE 側で完了した場合、PHYSICAL CHANNEL RECONFIGURATION COMPLETE メッセージが送信さ

れる。

6.4.10 システム間ハンドオーバ：GSM/BSS → UTRAN （Inter-system Handover: GSM/BSS to UTRAN）

図 39 に、デュアルモード端末（GSM MS / UMTS UE）用の、GSM/BSS から UTRAN へのハードハンドオー

バ処理手順を示す。ネットワーク側では、RANAP プロトコルを経由して HARD HANDOVER PROCEED 2 コマンドを受信すると、RRC レイヤがアドミッション制御を行い、RRC コネクション用に RNTI を割当てて

無線リソースを割当てて、無線リソース用のパラメータ（トランスポートチャネルのタイプや TFS など）を

選択する。RRC はこれらのパラメータを L1 と L2 上でコンフィグレーションし、ローカルに DCH 論理チャ

ネルを確立する。

選択されたパラメータには RNTI が含まれるが、これは RANAP のメッセージ HARD HANDOVER PROCEED 1、および GSM のアップグレードメッセージ HANDOVER COMMAND を使用して先行して UEに送信される。

HANDOVER COMMAND メッセージ受信後、GSM の RR レイヤは UMTS RRC レイヤに対して RR-Data-INDプリミィティブを使用して要求されたパラメータを送信する。UE RRC はこれらのパラメータを使用して L1 および L2 をコンフィグレーションし、ローカルに DCH 論理チャネルを確立する。L1 で同期が確立される

と、RRC に通知される。次に UE が RLC シグナルリンクの確立を開始する。最後に UE が HANDOVER COMPLETE メッセージを送信する。

3GPP

3GPP TS 25.303 V3.9.0 (2001-09) 74Release 1999


[Handover Complete]


Uu Iub

Admission control &Radio Resource

Allocation


CMAC-D-Config-REQ

CPHY-RL-Setup-REQ

RANAP: HARD HANDOVER PROCEED 2

CRLC-Config-REQ

CPHY-RL-Setup-REQ

SRNC-MAC


MS-RR BSC-RRCN / AS

Inter-network messageexchange described in 25.402

Start tx / rx

CPHY-RL-Setup-CNF

CPHY-RL-Setup-REQ

HANDOVER COMMAND

RR-Data-IND

[Handover Command]

Start tx / rx

L1 synchronisation

CPHY-Sync-INDCPHY-Sync-IND

CRLC-Config-REQ

L2 Link Establishment

RLC-Data-REQ

[Handover Complete]

RLC-Data-IND

[Handover Complete]DCCH: Data Ack

RLC-Data-CNF

RANAP: HARD HANDOVER COMPLETE

GSM Mode

Transition state

Cell connected state

図 39: GSM から UMTS へのシステム間ハンドオーバ

3GPP

3GPP TS 25.303 V3.9.0 (2001-09) 75Release 1999

6.4.11 RAT 間ハンドオーバ：UTRAN → GSM/BSS、 CS ドメインのサービス Inter-RAT Handover: UTRAN to GSM/BSS, CS domain services

HANDOVER ACCESS

PHYSICAL INFORMATION (unacknowledged)


Uu Iub


CMAC-D-Config-REQ

CPHY-RL-Release-REQ

RANAP: I-S HARD HANDOVER COMMAND

CRLC-Config-REQ

SRNC-MAC


MS-RR BSC-RRCN/AS

CPHY-RL-Release-REQ

CRLC-configureure-REQ

GSM Mode

Transition state

Cell connected state

INTER-SYSTEM HANDOVER COMMAND (acknowledged on L2)

RRC-Data-IND[I-S Handover Command]

RR-Data-IND[RRC Connection Release]

RANAP: BEARER RELEASE

CPHY-RL-Release-REQ

RANAP: HANDOVER REQUIRED

HANDOVER REQUEST

HANDOVER REQUEST ACK

HANDOVER DETECT

HANDOVER COMPLETE

HANDOVER COMPLETE

RANAP: BEARER RELEASE COMPLETE

図 40: UMTS から GSM への RAT 間ハンドオーバ

3GPP

3GPP TS 25.303 V3.9.0 (2001-09)76Release 1999

注: ここでは、UE が CS ドメインのサービスとだけコネクションを持っている場合に限定して説明

する。つまり、同時に PS シグナリングコネクションは持たないものとする。

CS ドメインのサービスについては、UTRAN から GSM への RAT 間ハンドオーバ処理手順は UE からの測定

レポートに基づいて行われるが、処理を開始するのは UTRAN 側である。DCCH 上でアクノリッジデータ送

信を使用して HANDOVER FROM UTRAN COMMAND が送信される。HANDOVER FROM UTRAN COMMAND 受信後に、UE の UTRAN コネクトモードからの移行が開始される。、UE から HANDOVER COMPLETE メッセージが送信された後に、GSM コネクトモードへの移行が完了する。

UTRAN は CN/AS に対して RELOCATION REQUIRED を送信する。本メッセージには、GSM システムがハ

ンドオーバを実行するために必要な情報（例えばサービスセルやターゲットセルなど）が含まれる。情報の

幾つか（例えば MS クラスマーク）は、RRC コネクションのセットアップ時に獲得されて CN 内に保存され

る。

CN/AS は BSC-RR に対して HANDOVER REQUEST メッセージを送信し、必要なリソースを割当てて、GSM MS を受信できるようにする。さらに CN/AS に HANDOVER REQUEST ACKNOWLEDGE を送信することに

よって、このアクノリッジを行う。HANDOVER REQUEST ACKNOWLEDGE には、UE がハンドオーバをす

るために必要な全ての無線関連の情報を持つ GSM-RR メッセージが含まれる。

CN/AS は UE に対して RELOCATION COMMAND (タイプ UTRAN-to-BSS HARD HANDOVER) を送信し、

UTRAN はハンドオーバの実行を開始する。本メッセージには、UE が GSM のセルに切替えて GSM にハン

ドオーバするために必要な全ての情報を持つ GSM-RR メッセージが含まれる。

UE が HANDOVER FROM UTRAN COMMAND メッセージを受信すると、UE RRC エンティティは GSM-RRメッセージを MS-RR エンティティに転送する。UTRA リソースを開放するには、MS-RR エンティティは

UE-RRC エンティティに RRC コネクションをローカルに開放するように要求する。UE-RRC エンティティは

ローカルに UE の RLC、MAC、および物理レイヤのリソースを解放することができる。

HANDOVER FROM UTRA COMMAND 中で受信した割当てられた GSM チャネルに切替えた後、GSM MS は

継続する L1 フレーム中で HANDOVER ACCESS を送信する。通常はコンベンショナル GSM ハンドオーバ

開始（conventional GSM handover initiation）として実行される。

BSC-RR が HANDOVER ACCESS を受信すると、このことを HANDOVER DETECT メッセージを使用して

CN/AS に通知する。BSC-RR は GSM MS に対して、PHYSICAL INFORMATION メッセージを非アクノリッ

ジモードで送信する。このメッセージ中には、MS が適切な送信をするために必要な、物理レイヤに関連す

る様々なフィールドが含まれる。

L1 と L2 のコネクション確立が成功した後、GSM MS は HANDOVER COMPLETE メッセージを返す。

次に、CN/AS は、UE が UTRAN コネクトモードで使用した UTRAN のリソースを解放することができる。 CN/AS は UTRAN に対して IU RELEASE COMMAND を送信する。その後 UTRAN は、RLC、MAC、および

物理レイヤから全てのネットワークリソースを解放することができる。リソース解放のオペレーション完

了後、CN / AS に対して IU RELEASE COMPLETE メッセージが送信される。

3GPP

3GPP TS 25.303 V3.9.0 (2001-09) 77Release 1999

6.5 コネクトモードにおける、CN 発のページング要求（CN originated paging request in connected mode）

6.5.1 DCCH を使用した UTRAN 調和型ページング（UTRAN coordinated paging using DCCH）

RLC-Data-REQ

[PAGING TYPE 2 (UE Paging id)]

UE-RRC UE-RLC UE-MAC UE-L1 Node B-L1 RNC-L1 RNC-MAC RNC-RLC RNC-RRC

Uu Iub


[PAGING TYPE 2]

RRC Paging request(UE Paging Id, Area,Paging Group Calc

Info)

RRC Notificationindication (UE

Paging Id)

RLC-Data-IND

[PAGING TYPE 2 (UEPaging id)]

図 41: DCCH を使用した CN 発のページング要求のシーケンス例

3GPP

3GPP TS 25.303 V3.9.0 (2001-09)78Release 1999

上記シーケンスは、UE がコネクトモードにあり、かつ DCCH で UE にアクセスできる場合の、CN 発のペー

ジング要求のシーケンスである。ページング要求と既存 RRC コネクションとの調整は UTRAN が行う。

ネットワーク側の上記 RRC エンティティは、Nt-SAP 上で UE に対してページングを要求する。ページング

要求には、UE のページング ID、ページング要求をブロードキャストすべきエリア、ページンググループの

算出に関する情報が含まれる。

DCCH を使用して UE にアクセスできるので、RRC レイヤは PAGING TYPE 2 メッセージを初期化(format)する。このメッセージには、UE のページング ID が含まれ、メッセージは非アクノリッジデータ送信を使用し

て、UE に直接送信される。

3GPP

3GPP TS 25.303 V3.9.0 (2001-09) 79Release 1999

6.6 UTRAN 発のページング要求とページング応答（UTRAN originated paging request and paging response）

UE-RRC UE-RLC UE-MAC UE-L1 Node B-L1 CRNC-MAC CRNC-RLC CRNC-RRC

Uu

PCH: Transparent mode Data

[PAGING TYPE 1 (UTRAN UE Id)]

PCCH: MAC-Data-REQ[PAGING TYPE 1 (UTRAN UE id, paging group)]

PCCH: MAC-Data-IND[PAGING TYPE 1 (UTRAN UE id)]

CELL UPDATE (Unacknowledged on L2)

SRNC-RRC

Iub Iur

Trigger UTRAN originatedpaging

CELL UPDATE CONFIRM (Unacknowledged on L2)

UTRAN MOBILITY INFORMATION CONFIRM (Acknowledged on L2)

図 42: ページング応答を伴う、UTRAN 発のページング要求のシーケンス例

3GPP

3GPP TS 25.303 V3.9.0 (2001-09)80Release 1999

PCH を使用しないと UE にアクセスできない場合（CELL_PCH ステートまたは URA_PCH ステート）、ネッ

トワーク内の RRC レイヤは、本シーケンスを使用して CELL_FACH ステートへの切替えをトリガする。図中の Paging Type 1 メッセージには、UTRAN UE の ID (s-RNTI + RNC-ID)が含まれる。 RRC は PCCH 上の

MAC を使用してページンググループを通知し、メッセージの送信を要求する。

UE 内では、RRC レイヤが PCH 上で継続的にページンググループをモニタし、受信したページング要求メッ

セージ内の UE の ID を自身の ID と比較する。両者が一致した場合、RRC レイヤはステートを CELL_FACHステートに変更する。

UE は Cell Update メッセージを準備し、それを CCCH 上で送信する。

ネットワークが Cell Update メッセージを受信すると、UE に対して c-RNTI が割当てられ、Cell Update Confirmメッセージを使用してシグナリングされる。Cell Update Confirmメッセージは非アクノリッジモー

ドを使用して DCCH 上で送信される。このメッセージは Cell Update メッセージの受信確認（acknowledges the reception）の役割も果たす。UE は MAC をコンフィグレーションし、新しい c-RNTI を使用して UTRAN MOBILITY INFORMATION CONFIRM メッセージを準備する。ネットワークが DCCH 上で UTRAN MOBILITY INFORMATION CONFIRM メッセージを受信した場合、ネットワークは任意の旧 c-RNTI を削除

することができる。これによって、新しい c-RNTI を使用して DCCH/DTCH 論理チャネルを下りリンクで使

用できるようになる。

6.7 その他の処理（Other procedures）

6.7.1 UE のケーパビリティ情報（UE Capability Information）

UE-RRC UE-RLC RNC-RLC RNC-RRC

Uu Iub

DCCH: UE CAPABILITY INFORMATION (acknowledged)

Sending ofUE

capabilitytriggered

RRC connected mode

DCCH: UE CAPABILITY INFORMATION CONFIRM (acknowledged)

図 43: UE のケーパビリティ情報

UE は、DCCH 上でアクノリッジモードを使用して RRC メッセージ UE Capability Information を送信すること

によって、自身のケーパビリティ情報をネットワークに伝える。UTRAN は UE ケーパビリティの受信を

DCCH 上でアクノリッジモードで UE CAPABILITY INFORMATION CONFIRM メッセージを送信する事で確

認する。もし UE ケーパビリティ情報が変わる場合（たとえば、UE パワークラスの変更による等）、この

処理は RRC コネクションの寿命が有効である間に実行することができる。UE のケーパビリティ情報は、

UTRAN が明示的に要求することも可能である。

3GPP

3GPP TS 25.303 V3.9.0 (2001-09)81Release 1999

6.7.2 ランダムアクセス送信シーケンス（FDD）（Random access transmission sequence (FDD)）

UE-MAC UE-PHY Node B-PHY RNC-MAC

Uu Iub

Preamble transmission withpower ramping

PHY-Access-REQ

RACH DataMAC-Data-IND

PHY-Access-CNF

Evaluation of theMAC header

Condition

UE-RLC


Preamble transmission withpower ramping

PHY-Access-REQ

AICH “ack”

AICH “Nack”

Increment preambleretransmissioncycle counter

UE-RRC

Initialbackoff time

MAC-Data-REQ

CMAC-Config-REQ

subsequentbackoff time

Nack may besent or not

[ Access ServiceClass,..]

[ Access ServiceClass,..]

PHY-Data-REQ

PHY-Access-CNF

図 44: ランダムアクセス送信シーケンス（FDD）

RACH と AICH は、 CPHY-TrCH-Config-REQ プリミィティブによって一度だけコンフィグレーションされる。

本プリミィティブは初期コンフィグレーションまたはパラメータ変更のためだけに発行されるものであり、

RACH で伝送されるたびに発行されるものではない。

CMAC-Config-REQ プリミィティブは、ランダムアクセス処理のために要求される MAC パラメータをコン

フィグレーションするために使用される (例えば持続的な値、プリアンブルランピングサイクルの最大数、

初期および継続バックオフ回数など)。

RACH 上で送信すべきデータが存在する場合、つまり MAC-Data-REQ プリミィティブを受信した場合には、

RACH 送信制御処理が開始される。RACH 送信制御処理には、ASC(Access Service Class)の選択も含まれる。

幾つかの初期バックオフの後、選択された ASC を含む PHY-Access-REQ プリミィティブが L1 に送信される。

これは PRACH プリアンブル送信をトリガする。すなわち物理レイヤは、L1 が持つバックオフ遅延を超える

ことなく、選択された ASC の範囲内で、PRACH アクセススロットを選択して署名する。

Ack（acknowledgement）または Nack（negative acknowledgement）を AICH 上で受信することなく、最大許容

送信出力に達した場合には、プリアンブルランピングサイクルが反復される。プリアンブルランピングサ

イクルの回数は MAC がカウントする。

3GPP

3GPP TS 25.303 V3.9.0 (2001-09)82Release 1999

プリアンブルの送信が成功した場合、獲得インジケータ（acquisition indicator）が受信された PHY-Access-CNF プリミィティブを経由して、MAC は Ack（acknowledgement）を受信する。そして PHY-Data-REQ プリ

ミィティブがメッセージの送信を要求する。

6.7.3 ランダムアクセス送信シーケンス（TDD）（Random access transmission sequence (TDD)）

UE-MAC UE-PHY Node B-PHY RNC-MAC

Uu Iub

PHY-Data-REQ

RACH DataMAC-Data-IND

Evaluation of theMAC header


UE-RRC

backoff time

MAC-Data-REQ

CMAC-Config-REQ

RACH Data

(collision)

RRC sets atimer andwaits for anACK fromthe UTRANon the FACH

Expiry oftimer

MAC-Data-REQ

backoff time

PHY-Data-REQ

RNC-RRC

RRC sets atimer andwaits for anACK fromthe UTRANon the FACH

MAC-Data-IND

ACK is sent on the FACH.


CMAC-Config-REQ

図 45: ランダムアクセス送信シーケンス（TDD）

CPHY-TrCH-Config-REQ プリミィティブによって、RACH は一度コンフィグレーションされる。本プリミィ

ティブは初期コンフィグレーション（例えば電力パラメータ）またはパラメータ変更のためだけに発行され

るものであり、RACH 送信の度に発行されるものではない。

CMAC-Config-REQ プリミィティブは、ランダムアクセス処理に必要な MAC パラメータをコンフィグレー

ションするために使用される。パラメータには、持続的な値や ASC（Access Service Class ）パラメータなど

のランダムアクセス制御用のパラメータを含むこともできる。

RACH 上で送信すべきデータが存在する場合、つまり MAC-Data-REQ プリミィティブを受信した場合、

RACH 送信処理が開始される。この中には、ASC(Access Service Class)の選択も含まれる。

3GPP

3GPP TS 25.303 V3.9.0 (2001-09)83Release 1999

幾つかの初期バックオフの後、PHY-Access-REQ プリミィティブが L1 に送信される。これは PRACH メッセ

ージ送信をトリガする。すなわち物理レイヤは、L1 が持つバックオフ遅延を超えることなく、選択された

ASC の範囲内で、PRACH の拡散コードを選択する。MAC 上のバックオフタイムは、特定の条件下（例え

ば上りリンクの負荷が低い場合）には 0 に設定できることに注意すること。

UTRAN 側の MAC で、受信した RACH メッセージをこれ以上処理するかは、MAC ヘッダに依存する。メッセージが正しく受信されたことの Ack（acknowledgement）は、RRC 処理手順で与えられる。透過型 RLCの場合には、メッセージの再送信は、再送タイマを使用して RRC 内で最後まで処理すること。非透過型

RLC の場合には、タイマは RLC によって制御される。PRACH 送信のパラメータは、メッセージの再送回数

が低く抑えられるように選択される。PRACH 上のメッセージの消失は、同一の拡散コード上のコリジョン

に起因すること。

6.7.4 CPCH の緊急停止シーケンス（CPCH Emergency Stop sequence）図 46 に CPCH の緊急停止処理手順を示す。本処理は、例えばセル内で一時的な過負荷が発生するなどの緊

急停止条件を Node B が検出した場合に、Node B RRC からの要求に基づいて発動する。CPCH の緊急停止は、

Node B RRC から Node B L1 に対して発行される CPHY-CPCH-Estop-REQ プリミィティブによって開始され

る。本プリミィティブを受信すると、Node B L1 は UE L1 に対して、CPCH 緊急停止コマンドを送信する。

UE L1 は緊急停止コマンドを受信すると、UE RRC に対して CPHY-CPCH-Estop-IND プリミィティブを送信

し、CPCH 緊急停止コマンドを受信したことを通知する。そして UE RRC は UE L1 に対して CPHY-CPCH-Estop-Resp プリミィティブを反復して、CPCH 緊急停止を実行する。UE L1 停止後、現在進行中の CPCH 送信は、UE MAC に対して PHY-Status-IND プリミィティブを送信し、CPCH 緊急停止が完了したことを通知

する。一方、Node B L1 が CPCH リンクの消失を検出した場合には、Node B L1 は Node B RRC に CPHY-CPCH-Estop-CNF プリミィティブを送信する。これによって CPCH の緊急停止処理手順は完了する。

UE-MAC UE-PHY Node B-PHY Node B-RRC

Uu

UE-RLCUE-RRC

(DPCH)

[CPCH-Estop-Command]

CPHY-CPCH-Estop-IND

CPHY-CPCH-Estop-Resp

CPHY-CPCH-Estop-REQ

CPHY-CPCH-Estop-CNF

PHY-Status-IND [CPCH-Estop]

図 46: CPCH の緊急停止シーケンス

3GPP

3GPP TS 25.303 V3.9.0 (2001-09)84Release 1999

7 トラフィック量のモニタ（Traffic volume monitoring）

送信機のバッファのステータスに基づいて、UE がネットワークにメッセージ送信をトリガするためのアル

ゴリズムが定義される。

図 47 に、トラフィック量のモニタ処理メッセージシーケンスの例を示す。UE 内の RRC は、UTRAN 内の

RRC が送信する測定制御メッセージもしくはシステム情報メッセージから、トラフィック量の測定に必要な

パラメータを獲得する。UE 内の RRC は、CMAC-Measurement-REQ といっしょにトラフィック量測定用の

パラメータを MAC にパスする。一方、RLC はバッファのステータスといっしょにデータを MAC にパスす

る。MAC が RRC に対してトラフィック量測定レポートを通知する方法は 2 つある。つまり、周期型報告と

イベンントトリガ型報告である。周期型報告の場合には、MAC は RRC に対して測定結果を周期的にレポー

トする。イベンントトリガ型報告の場合には、UE 内の MAC は、測定結果が特定のスレッショルド値を超

えた場合にのみ、RRC に測定結果をレポートする。その後、MAC から受信した測定レポートと、UTRANから受信したレポート基準に基づいて、RRC は測定レポートメッセージ（Measurement Report Message）を

UTRAN に対して送信するべきか否かを決定する。UTRAN 内の RRC が測定レポートメッセージを受信した

場合には、UE からの測定レポートに基づいて適切なアクションを取る。それはベアラの再コンフィグレー

ションであったり、トランスポートチャネルの再コンフィグレーションであったり、物理チャネルの再コン

フィグレーションであったり、あるいはトランスポートチャネルの組合せ制御処理であったりする。図 44に示すように、2 種類のレポートモード（周期型／イベントトリガ型）は、排他的に単独で使用することも

できるし、同時に併用することもできる。

Uu IubUE-RRC UE-MACUE-RLC UE-PHY NodeB-PHY RNC-MAC

CMAC-MEASUREMENT-REQ

DCCH: MEASUREMENT CONTROL Message[Traffic Volume Measurement]

MAC-DATA-REQ

MAC-DATA-REQ

CMAC-MEASUREMENT-IND

DCCH: MEASUREMENT REPORT Message[Traffic Volume Measurement]

Thresholdexceeds

Decide toreport

RNC-RLC RNC-RRC

Choose Actionaccordingly

Radio Access Bearer Control Procedures[Bearer Reconfiguration / Transport Channel Reconfiguration / Physical Channel Reconfiguration / Transport Format Combination Control

BCCH: System Information Message[Traffic Volume Measurement]

MAC-DATA-REQ

ReportInterval


ReportInterval


図 47: トラフィック量測定レポート処理手順

3GPP

3GPP TS 25.303 V3.9.0 (2001-09)85Release 1999

付録 A(informative): 改版履歴（Change history）

Change history Date TSG # TSG Doc. CR Rev Subject/Comment Old New 06/1999 RP-04 RP-99310 - Approved at TSG-RAN #4 placed under Change Control - 3.0.0 10/1999 RP-05 RP-99462 001 RRC connection establishment procedure 3.0.0 3.1.0 RP-05 RP-99462 002 1 RRC Connection release procedure 3.0.0 3.1.0 RP-05 RP-99462 003 Cell update and URA update procedures 3.0.0 3.1.0 RP-05 RP-99462 004 Removal of FFS in DSCH transmission example 3.0.0 3.1.0 RP-05 RP-99462 005 Incorporation of DSCH transmission with one TFCI 3.0.0 3.1.0 RP-05 RP-99462 006 RRC Traffic Volume Monitoring Procedure 3.0.0 3.1.0 RP-05 RP-99462 007 Transfer and update of system information 3.0.0 3.1.0 RP-05 RP-99462 008 UE controlled AMR mode adaptation 3.0.0 3.1.0 RP-05 RP-99462 009 Model of RACH procedures 3.0.0 3.1.0 RP-05 RP-99462 012 USCH/DSCH data transfer for TDD 3.0.0 3.1.0 RP-05 RP-99462 013 Removal of UE State Description 3.0.0 3.1.0 RP-05 RP-99462 014 Editorial renaming request 3.0.0 3.1.0 RP-05 RP-99462 015 Release version for Asymmetric transport channel reconfiguration

procedure 3.0.0 3.1.0

RP-05 RP-99462 016 Example message sequence for RACH transmissions in TDD mode

3.0.0 3.0.0

12/1999 RP-06 RP-99629 017 1 Support of shared channel operation in TDD and alignment to Mac-c/sh merge

3.1.0 3.2.0

RP-06 RP-99628 018 2 Corrections to RRC State Names 3.1.0 3.2.0 RP-06 RP-99628 021 Editorial issues 3.1.0 3.2.0 03/2000 RP-07 RP-000036 022 4 CPCH start of message indication 3.2.0 3.3.0 RP-07 RP-000036 023 Correction to Transport Format Combination Control procedure 3.2.0 3.3.0 RP-07 RP-000036 025 1 CPCH Emergency Stop sequence 3.2.0 3.3.0 RP-07 RP-000036 026 1 Variable Rate Packet Transmission for uplink DCH 3.2.0 3.3.0 RP-07 RP-000036 027 Random access transmission sequence 3.2.0 3.3.0 06/2000 RP-08 RP-000216 029 Corrections to L2 link management and radio link setup in interlayer

message sequence charts 3.3.0 3.4.0

RP-08 RP-000216 030 Alignment of FDD downlink shared channel descriptions with 25.331

3.3.0 3.4.0

RP-08 RP-000216 031 1 End of CPCH transmission 3.3.0 3.4.0 RP-08 RP-000216 033 Out-of-synch corrections 3.3.0 3.4.0 RP-08 RP-000216 034 Traffic Volume Monitoring 3.3.0 3.4.0 09/2000 RP-09 RP-000354 035 2 SRNS relocation 3.4.0 3.5.0 RP-09 RP-000354 037 Variable Rate Transmission 3.4.0 3.5.0 12/2000 RP-10 RP-000564 038 1 Corrections to SRNS Relocation 3.5.0 3.6.0 RP-10 RP-000564 040 Correction to Relocation text 3.5.0 3.6.0 03/2001 RP-11 RP-010021 041 1 Text corrections 3.6.0 3.7.0 RP-11 RP-010021 042 SRNS relocation 3.6.0 3.7.0 RP-11 RP-010021 044 Clean-up 3.6.0 3.7.0 06/2001 RP-12 RP-010304 045 1 Corrections to procedure examples 3.7.0 3.8.0 09/2001 RP-13 RP-010538 050 SRNS relocation and header compression protocol 3.8.0 3.9.0 RP-13 RP-010538 052 Alignment on active set update 3.8.0 3.9.0 RP-13 RP-010538 056 2 Proposed correction to SRNS relocation procedure 3.8.0 3.9.0

3GPP TS 25.303 V3.9 - 株式会社QT RAT 間ハンドオーバ：UTRAN → GSM/BSS、 CS...

Documents

Transcript of 3GPP TS 25.303 V3.9 - 株式会社QT RAT 間ハンドオーバ：UTRAN → GSM/BSS、 CS...