TS 125 302 - V3.6.0 - Universal Mobile Telecommunications ... · 2 ETSI 3GPP TS 25.302 version...

ETSI TS 125 302 V3.6.0 (2000-09)Technical Specification

Universal Mobile Telecommunications System (UMTS);Services provided by the Physical Layer

(3GPP TS 25.302 version 3.6.0 Release 1999)

1

ETSI

ETSI TS 125 302 V3.6.0 (2000-09)3GPP TS 25.302 version 3.6.0 Release 1999

ReferenceRTS/TSGR-0225302UR3

KeywordsUMTS

ETSI

650 Route des LuciolesF-06921 Sophia Antipolis Cedex - FRANCE

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

Siret N° 348 623 562 00017 - NAF 742 CAssociation à but non lucratif enregistrée à laSous-Préfecture de Grasse (06) N° 7803/88

Important notice

Individual copies of the present document can be downloaded from:http://www.etsi.org

The present document may be made available in more than one electronic version or in print. In any case of existing orperceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).

In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drivewithin ETSI Secretariat.

Users of the present document should be aware that the document may be subject to revision or change of status.Information on the current status of this and other ETSI documents is available at http://www.etsi.org/tb/status/

If you find errors in the present document, send your comment to:[email protected]

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.

© European Telecommunications Standards Institute 2000.

All rights reserved.

http://www.etsi.org/

http://www.etsi.org/tb/status

[email protected]

2

ETSI


Intellectual Property RightsIPRs essential or potentially essential to the present document may have been declared to ETSI. The informationpertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be foundin ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI inrespect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Webserver (http://www.etsi.org/ipr).

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guaranteecan be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Webserver) which are, or may be, or may become, essential to the present document.

ForewordThis Technical Specification (TS) has been produced by the ETSI 3rd Generation Partnership Project (3GPP).

The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identities orGSM identities. These should be interpreted as being references to the corresponding ETSI deliverables.

The cross reference between GSM, UMTS, 3GPP and ETSI identities can be found under www.etsi.org/key .

http://www.etsi.org/ipr

http://www.etsi.org/key

ETSI


Contents

Foreword.............................................................................................................................................................6

1 Scope ........................................................................................................................................................7

2 References ................................................................................................................................................7

3 Definitions and abbreviations...................................................................................................................73.1 Definitions..........................................................................................................................................................73.2 Abbreviations .....................................................................................................................................................7

4 Interfaces to the physical layer.................................................................................................................94.1 Interface to MAC................................................................................................................................................94.2 Interface to RRC.................................................................................................................................................9

5 Services and functions of the physical layer ..........................................................................................105.1 General .............................................................................................................................................................105.2 Overview of L1 functions.................................................................................................................................105.3 L1 interactions with L2 retransmission functionality.......................................................................................11

6 Model of physical layer of the UE .........................................................................................................116.1 Uplink models ..................................................................................................................................................116.2 Downlink models .............................................................................................................................................136.3 Relay link Model ..............................................................................................................................................16

7 Formats and configurations for L1 data transfer ....................................................................................167.1 General concepts about Transport Channels ....................................................................................................167.1.1 Transport Block ..........................................................................................................................................167.1.2 Transport Block Set ....................................................................................................................................177.1.3 Transport Block Size ..................................................................................................................................177.1.4 Transport Block Set Size ............................................................................................................................177.1.5 Transmission Time Interval ........................................................................................................................177.1.6 Transport Format ........................................................................................................................................187.1.7 Transport Format Set ..................................................................................................................................187.1.8 Transport Format Combination...................................................................................................................197.1.9 Transport Format Combination Set ............................................................................................................197.1.10 Transport Format Indicator (TFI) ...............................................................................................................207.1.11 Transport Format Combination Indicator (TFCI) .......................................................................................207.1.12 Rate matching .............................................................................................................................................207.2 Types of Transport Channels............................................................................................................................217.3 Compressed Mode............................................................................................................................................23

8 UE Simultaneous Physical Channels combinations...............................................................................248.1 FDD Uplink......................................................................................................................................................248.2 FDD Downlink.................................................................................................................................................258.3 TDD Uplink......................................................................................................................................................268.4 TDD Downlink.................................................................................................................................................278.5 TDD UE Uplink and Downlink Combinations (within 10 ms air frames) .......................................................288.6 TDD UE Uplink Timeslot Combinations.........................................................................................................308.7 TDD UE Downlink Timeslot Combinations ....................................................................................................31

9 Measurements provided by the physical layer .......................................................................................329.1 Model of physical layer measurements ............................................................................................................329.2 UE Measurements ............................................................................................................................................339.2.1 SFN-CFN observed time difference ...........................................................................................................339.2.2 Observed time difference to GSM cell .......................................................................................................339.2.3 CPICH Ec/N0...............................................................................................................................................349.2.4 CPICH SIR .................................................................................................................................................349.2.5 CPICH RSCP..............................................................................................................................................349.2.6 P-CCPCH RSCP.........................................................................................................................................349.2.7 Timeslot ISCP.............................................................................................................................................34

ETSI


9.2.8 CPICH ISCP ...............................................................................................................................................359.2.9 SIR..............................................................................................................................................................359.2.10 UTRA carrier RSSI.....................................................................................................................................359.2.11 GSM carrier RSSI.......................................................................................................................................359.2.12 Transport channel BLER ............................................................................................................................359.2.13 UE transmitted power .................................................................................................................................369.2.14 UE Rx-Tx time difference ..........................................................................................................................369.2.15 SFN-SFN Observed time difference ...........................................................................................................369.2.16 UE GPS Timing of Cell Frames for LCS ...................................................................................................369.3 UTRAN Measurements....................................................................................................................................379.3.1 RSSI............................................................................................................................................................379.3.2 Transmitted carrier power...........................................................................................................................379.3.3 Transmitted code power..............................................................................................................................379.3.4 Transport channel BLER ............................................................................................................................379.3.5 Physical channel BER.................................................................................................................................379.3.6 Transport channel BER...............................................................................................................................389.3.7 RX timing deviation....................................................................................................................................389.3.8 Timeslot ISCP.............................................................................................................................................389.3.9 RSCP ..........................................................................................................................................................389.3.10 Round Trip Time ........................................................................................................................................389.3.11 Frequency Offset ........................................................................................................................................399.3.12 Acknowledged PRACH preambles.............................................................................................................399.3.13 Detected PCPCH access preambles ............................................................................................................399.3.14 Acknowledged PCPCH access preambles ..................................................................................................399.3.15 SIR..............................................................................................................................................................399.3.16 Propagation Delay.......................................................................................................................................409.3.17 UTRAN GPS Timing of Cell Frames for LCS ...........................................................................................409.3.18 SIR ERROR................................................................................................................................................40

10 Primitives of the physical layer ..............................................................................................................4010.1 Generic names of primitives between layers 1 and 2 .......................................................................................4110.1.1 PHY-Access-REQ ......................................................................................................................................4110.1.2 PHY-Access-CNF.......................................................................................................................................4110.1.3 PHY-Data-REQ ..........................................................................................................................................4210.1.4 PHY- Data-IND..........................................................................................................................................4210.1.5 PHY-CPCH_Status-REQ............................................................................................................................4210.1.6 PHY-CPCH_Status-CNF............................................................................................................................4210.1.7 PHY-Status-IND.........................................................................................................................................4210.2 Generic names of primitives between layers 1 and 3 .......................................................................................4310.2.1 STATUS PRIMITIVES..............................................................................................................................4310.2.1.1 CPHY-Sync-IND ..................................................................................................................................4310.2.1.2 CPHY-Out-of-Sync-IND ......................................................................................................................4310.2.1.3 CPHY-Measurement-REQ....................................................................................................................4310.2.1.4 CPHY-Measurement-IND.....................................................................................................................4410.2.1.5 CPHY-ERROR-IND.............................................................................................................................4410.2.1.6 CPHY-CPCH-EOT-IND.......................................................................................................................4410.2.2 CONTROL PRIMITIVES ..........................................................................................................................4510.2.2.1 CPHY-TrCH-Config-REQ....................................................................................................................4510.2.2.2 CPHY-TrCH-Config-CNF....................................................................................................................4510.2.2.3 CPHY-TrCH-Release-REQ ..................................................................................................................4610.2.2.4 CPHY-TrCH-Release-CNF...................................................................................................................4610.2.2.5 CPHY-RL-Setup-REQ..........................................................................................................................4610.2.2.6 CPHY-RL-Setup-CNF ..........................................................................................................................4610.2.2.7 CPHY-RL-Release-REQ.......................................................................................................................4610.2.2.8 CPHY-RL-Release-CNF.......................................................................................................................4610.2.2.9 CPHY-Modify-REQ .............................................................................................................................4710.2.2.10 CPHY-RL-Modify-CNF .......................................................................................................................4710.2.2.11 CPHY-Commit-REQ ............................................................................................................................4710.2.2.12 CPHY-CPCH-Estop-IND .....................................................................................................................4710.2.2.13 CPHY-CPCH-Estop-Resp.....................................................................................................................4710.2.2.14 CPHY-CPCH-Estop-REQ.....................................................................................................................4710.2.2.15 CPHY-CPCH-Estop-CNF.....................................................................................................................48

ETSI


10.2.2.16 CPHY-Out-of-Sync-Config-REQ .........................................................................................................4810.2.2.17 CPHY-Out-of-Sync-Config-CNF .........................................................................................................4810.3 Parameter definition .........................................................................................................................................4810.3.1 Error code ...................................................................................................................................................4810.3.2 Event value .................................................................................................................................................4810.3.3 Access Information.....................................................................................................................................4810.3.4 Transport Format Subset.............................................................................................................................4910.3.5 Physical channel description.......................................................................................................................4910.3.5.1 Primary SCH.........................................................................................................................................4910.3.5.2 Secondary SCH.....................................................................................................................................4910.3.5.3 Primary CCPCH....................................................................................................................................4910.3.5.4 Secondary CCPCH................................................................................................................................4910.3.5.5 PRACH .................................................................................................................................................5010.3.5.6 Uplink DPDCH+DPCCH......................................................................................................................5010.3.5.7 Uplink DPCH........................................................................................................................................5010.3.5.8 Downlink DPCH...................................................................................................................................5110.3.5.9 PCPCH (Physical Common Packet Channel) .......................................................................................5110.3.5.10 PICH .....................................................................................................................................................5110.3.5.11 AICH.....................................................................................................................................................5210.3.5.12 AP-AICH ..............................................................................................................................................5210.3.5.13 CD-ICH.................................................................................................................................................5210.3.5.14 CD/CA-ICH ..........................................................................................................................................5210.3.5.15 CSICH...................................................................................................................................................5210.3.5.16 PDSCH..................................................................................................................................................5310.3.5.17 PUSCH..................................................................................................................................................53

11 Transport block transmission .................................................................................................................53

Annex A (normative): Description of Transport Formats..........................................................................54

Annex B (informative): Example of Transport format attributes for AMR speech codec......................56

Annex C (informative): Change history .......................................................................................................57

ETSI


ForewordThis Technical Specification (TS) has been produced by the 3rd Generation Partnership Project (3GPP).

The contents of the present document are subject to continuing work within the TSG and may change following formalTSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with anidentifying change of release date and an increase in version number as follows:

Version x.y.z

where:

x the first digit:

1 presented to TSG for information;

2 presented to TSG for approval;

3 or greater indicates TSG approved document under change control.

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections,updates, etc.

z the third digit is incremented when editorial only changes have been incorporated in the document.

ETSI


1 ScopeThe present document is a technical specification of the services provided by the physical layer of UTRA to upperlayers.

The following items are considered for releases beyond Release 99:

- Fast Uplink Signalling Channel (FAUSCH);

- Opportunity Driven Multiple Access (ODMA).

2 ReferencesThe following documents contain provisions which, through reference in this text, constitute provisions of the presentdocument.

• References are either specific (identified by date of publication, edition number, version number, etc.) ornon-specific.

• For a specific reference, subsequent revisions do not apply.

• For a non-specific reference, the latest version applies.

[1] 3GPP TS 23.110: "UMTS Access Stratum; Services and Functions".

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

[3] 3GPP TS 25.212: "Multiplexing and channel coding (FDD)".

[4] 3GPP TS 25.222: "Multiplexing and channel coding (TDD)".

[5] 3GPP TS 25.224: "Physical Layer Procedures (TDD)".

[6] 3GPP TS 25.215: "Physical Layer – Measurements (FDD)".

[7] 3GPP TS 25.213: "Spreading and modulation (FDD)".

[8] 3GPP TS 25.214: "Physical layer procedures (FDD)".

[9] 3GPP TS 25.123: "Requirements for Support of Radio Resource Management (TDD)".

[10] 3GPP TS 25.133: "Requirements for Support of Radio Resource Management (FDD)".

3 Definitions and abbreviations

3.1 DefinitionsFor the purposes of the present document, the terms and definitions given in [3] apply.

3.2 AbbreviationsFor the purposes of the present document, the following abbreviations apply:

ARQ Automatic Repeat RequestBCCH Broadcast Control ChannelBCH Broadcast ChannelC- Control-

ETSI


CC Call ControlCCC CPCH Control CommandCCCH Common Control ChannelCCH Control ChannelCCTrCH Coded Composite Transport ChannelCN Core NetworkCRC Cyclic Redundancy CheckDC Dedicated Control (SAP)DCA Dynamic Channel AllocationDCCH Dedicated Control ChannelDCH Dedicated ChannelDL DownlinkDRNC Drift Radio Network ControllerDSCH Downlink Shared ChannelDTCH Dedicated Traffic ChannelFACH Forward Link Access ChannelFAUSCH Fast Uplink Signaling ChannelFCS Fame Check SequenceFDD Frequency Division DuplexGC General Control (SAP)HO HandoverITU International Telecommunication Unionkbps kilo-bits per secondL1 Layer 1 (physical layer)L2 Layer 2 (data link layer)L3 Layer 3 (network layer)LAC Link Access ControlLAI Location Area IdentityMAC Medium Access ControlMM Mobility ManagementNt Notification (SAP)OCCCH ODMA Common Control ChannelODCCH ODMA Dedicated Control ChannelODCH ODMA Dedicated ChannelODMA Opportunity Driven Multiple AccessODTCH ODMA Dedicated Traffic ChannelORACH ODMA Random Access ChannelPCCH Paging Control ChannelPCH Paging ChannelPDU Protocol Data UnitPHY Physical layerPhyCH Physical ChannelsRACH Random Access ChannelRLC Radio Link ControlRNC Radio Network ControllerRNS Radio Network SubsystemRNTI Radio Network Temporary IdentityRRC Radio Resource ControlSAP Service Access PointSDU Service Data UnitSRNC Serving Radio Network ControllerSRNS Serving Radio Network SubsystemTCH Traffic ChannelTDD Time Division DuplexTFCI Transport Format Combination IndicatorTFI Transport Format IndicatorTMSI Temporary Mobile Subscriber IdentityTPC Transmit Power ControlU- User-UE User EquipmentUER User Equipment with ODMA relay operation enabledUL Uplink

ETSI


UMTS Universal Mobile Telecommunications SystemURA UTRAN Registration AreaUTRA UMTS Terrestrial Radio AccessUTRAN UMTS Terrestrial Radio Access Network

4 Interfaces to the physical layerThe physical layer (layer 1) is the lowest layer in the OSI Reference Model and it supports all functions required for thetransmission of bit streams on the physical medium.

The physical layer interfaces the Medium Access Control (MAC) Layer and the Radio Resource Control (RRC) Layeras depicted in figure 1.

Physical Layer

Medium Access Control(MAC)

Radio Resource Control (RRC)

PHY primitivesLayer 1

Layer 2

Layer 3

CPHY primitives

Figure 1: Interfaces with the Physical Layer

4.1 Interface to MACThe physical layer interfaces the MAC entity of layer 2. Communication between the Physical Layer and MAC is in anabstract way performed by means of PHY-primitives defined which do not constrain implementations.

NOTE: The terms physical layer and layer 1, will be used synonymously in this description.

The PHY-primitives exchanged between the physical layer and the data link layer provide the following functions:

- transfer of transport blocks over the radio interface;

- indicate the status of the layer 1 to layer 2.

4.2 Interface to RRCThe physical layer interfaces the RRC entity of layer 3 in the UE and in the network.

Communication is performed in an abstract way by means of CPHY-primitives. They do not constrain implementations.

The CPHY-primitives exchanged between the physical layer and the Network layer provide the following function:

- control of the configuration of the physical layer.

The currently identified exchange of information across that interface has only a local significance to the UE orNetwork.

ETSI


5 Services and functions of the physical layer

5.1 GeneralThe physical layer offers data transport services to higher layers. The access to these services is through the use oftransport channels via the MAC sub-layer. The characteristics of a transport channel are defined by its transport format(or format set), specifying the physical layer processing to be applied to the transport channel in question, such asconvolutional channel coding and interleaving, and any service-specific rate matching as needed.

The physical layer operates exactly according to the L1 radio frame timing. A transport block is defined as the dataaccepted by the physical layer to be jointly encoded. The transmission block timing is then tied exactly to this L1 frametiming, e.g. every transmission block is generated precisely every 10ms, or a multiple of 10 ms.

A UE can set up multiple transport channels simultaneously, each having own transport characteristics (e.g. offeringdifferent error correction capability). Each transport channel can be used for information stream transfer of one radiobearer or for layer 2 and higher layer signalling messages.

The multiplexing of these transport channels onto the same or different physical channels is carried out by L1. Inaddition, the Transport Format Combination Indication field (TFCI) shall uniquely identify the transport format used byeach transport channel of the Coded Composite Transport Channel within the current radio frame.

5.2 Overview of L1 functionsThe physical layer performs the following main functions:

- FEC encoding/decoding of transport channels;

- measurements and indication to higher layers (e.g. FER, SIR, interference power, transmission power, etc…);

- macrodiversity distribution/combining and soft handover execution;

- error detection on transport channels;

- multiplexing of transport channels and demultiplexing of coded composite transport channels;

- rate matching;

- mapping of coded composite transport channels on physical channels;

- modulation and spreading/demodulation and despreading of physical channels;

- frequency and time (chip, bit, slot, frame) synchronisation;

- closed-loop power control;

- power weighting and combining of physical channels;

- RF processing;

- support of Uplink Synchronisation as defined in [5] (TDD only);

- timing advance on uplink channels (TDD only).

ETSI


5.3 L1 interactions with L2 retransmission functionalityProvided that the RLC PDUs are mapped one-to-one onto the Transport Blocks, Error indication may be provided byL1 to L2. For that purpose, the L1 CRC can be used for individual error indication of each RLC PDU. The L1 CRC willthen serve multiple purposes:

- error indication for uplink macro diversity selection combining (L1);

- error indication for each erroneous Transport Block in transparent and unacknowledged mode RLC;

- quality indication;

- error indication for each erroneous Transport Block in acknowledged mode RLC.

Regardless of the result of the CRC check, all Transport Blocks are delivered to L2 along with the associated errorindications.

6 Model of physical layer of the UE

6.1 Uplink modelsFigure 2 shows models of the UE's physical layer in the uplink for both FDD and TDD mode. It shows the models forDCH, RACH, FAUSCH, CPCH (the latter two used in FDD mode only) and USCH (TDD only). Some restriction existfor the use of different types of transport channel at the same time, these restrictions are described in the chapter "UESimultaneous Physical Channel combinations". More details can be found in [3] and [4].

ETSI


Coded Composite Transport Channel

( CCTrCH)

Physical Channel Data Streams

Demultiplexing/ splitting

Coding and multiplexing

Phy CH Phy CH

DCH DCH DCH

Transport Format Combination

Indicator (TFCI)

TPC → Phy CH

DCH model

Coding

Phy CH

RACH

RACH model

FAUSCH

Phy CH

FAUSCH model

(note 1) Physical Channel Data Streams

Coded Composite Transport Channel

( CCTrCH)


Coding and multiplexing

Phy CH Phy CH

USCH

USCH model

Physical Channel

Data Streams

USCH

→ TFCI

Coding


Phy CH Phy CH

CPCH

CPCH model

NOTE 1: Only the data part of the CPCH can be mapped on multiple physical channels (in case of multi-codePCPCH).

NOTE 2: FAUSCH and CPCH are for FDD only.NOTE 3: USCH is for TDD only.

Figure 2: Model of the UE's physical layer - uplink

The DCH model shows that one or several DCHs can be processed and multiplexed together by the same coding andmultiplexing unit. The detailed functions of the coding and multiplexing unit are not defined in the present documentbut in [3] and [4]. The single output data stream from the coding and multiplexing unit is denoted Coded CompositeTransport Channel (CCTrCH).

The bits on a CCTrCH Data Stream can be mapped on the same Physical Channel and should have the same C/Irequirement.

On the downlink, multiple CCTrCH can be used simultaneously with one UE. In the case of FDD, only one fast powercontrol loop is necessary for these different CCtrCH, but the different CCtrCH can have different C/I requirements toprovide different QoS on the mapped Transport Channels. In the case of TDD, different power control loops can beapplied for different CCTrCH. One physical channel can only have bits coming from the same CCTrCH.

On the uplink and in the case of FDD, only one CCTrCH can be used simultaneously. On the uplink and in the case ofTDD, multiple CCTrCH can be used simultaneously.

ETSI


When multiple CCTrCH are used by one UE, one or several TFCI can be used, but each CCTrCH has only zero or onecorresponding TFCI. In the case of FDD, these different words are mapped on the same DPCCH. In the case of TDD,these different TFCI can be mapped on different DPCH.

The data stream of the CCTrCH is fed to a data demultiplexing/splitting unit that demultiplexes/splits the CCTrCH'sdata stream onto one or several Physical Channel Data Streams.

The current configuration of the coding and multiplexing unit is either signalled to, or optionally blindly detected by,the network for each 10 ms frame. If the configuration is signalled, it is represented by the Transport FormatCombination Indicator (TFCI) bits. Note that the TFCI signalling only consists of pointing out the current transportformat combination within the already configured transport format combination set. In the uplink there is only oneTFCI representing the current transport formats on all DCHs of one CCTrCH simultaneously. In FDD mode, thephysical channel data stream carrying the TFCI is mapped onto the physical channel carrying the power control bits andthe pilot. In TDD mode the TFCI is time multiplexed onto the same physical channel(s) as the DCHs. The exactlocations and coding of the TFCI are signalled by higher layers.

The DCH and USCH have the possibility to perform Timing Advance in TDD mode.

For the FAUSCH, there is no coding, since the FAUSCH is only used for the transmission of a reservation request bysending an up-link signalling code (USC) at the time-offset allocated for the specific UE during the 10 ms frame. Due tothe fixed time-offset allotted to a specific UE, the FAUSCH is a dedicated control channel.

The model for the RACH case shows that RACH is a common type transport channel in the uplink. RACHs are alwaysmapped one-to-one onto physical channels, i.e. there is no physical layer multiplexing of RACH. Service multiplexingis handled by the MAC layer.

The CPCH, which is another common type transport channel, has a physical layer model as shown in figure2. There isalways a single CPCH transport channel mapped to a PCPCH physical channel which implies a one-to-onecorrespondence between a CPCH TFI and the TFCI conveyed on PCPCH. Demultiplexing/splitting applies to multicodePCPCH physical channels. A CPCH transport channel belongs to a CPCH set which is identified by the application of acommon, CPCH set-specific scrambling code for access preamble and collision detection, and multiple PCPCHphysical channels. Each PCPCH shall employ a subset of the Transport Format Combinations implied by the TransportFormat Set of the CPCH set. A UE can request access to CPCH transport channels of a CPCH set, which is assignedwhen the service is configured for CPCH transmission.

6.2 Downlink modelsFigure 3 and figure 4 show the model of the UE's physical layer for the downlink in FDD and TDD mode, respectively.Note that there is a different model for each transport channel type.

ETSI


→TPC stream 1, TFCI→TPC stream 2, TFCI→TPC stream 3, TFCI

Coded CompositeTransport Channel

(CCTrCH)

Physical ChannelData Streams

MUX

DCH

Decoding anddemultiplexing

Cell 1 Phy CH Phy CHCell 2 Phy CH Phy CHCell 3 Phy CH Phy CH

DCH DCH

Phy CH

Decoding

BCH

Phy CH

ACH

Phy CH

PCH

FACH & PCHmodel

BCHmodel

DCHmodel


←TFCI← PI


CCTrCH)

FACH

DSCH

DSCHmodel

DCH associated with DSCH

→→TPC stream 2, TFCI1→TPC stream 3, TFCI1


(CCTrCH)


MUX

DCH


Cell 1 Phy CH Phy CHCell 2 Phy CH Phy CHCell 3 Phy CH Phy CH

DCH DCH

DCHmodel

→ TPC stream 1, TFCI2

Note (1) – TFCI1 indicates the DCH specificTFC and TFCI2 indicates the DSCH specificTFC and also the PDSCH channelisationcode(s)


DSCH


(CCTrCH)


MUX

Phy CH Phy CHCell 1TPC stream 1, TFCI1

Figure 3: Model of the UE's physical layer - downlink FDD mode

ETSI



(CCTrCH)


MUX

DCH


Phy CH Phy CH

DCH DCH

Phy CH

Decoding

BCH

BCHmodel

DCHmodel


(CCTrCH)


MUX


Phy CH Phy CH

DSCHmodel

Phy CH Phy CH

FACH & PCHmodel


← PI


CCTrCH)

PCHFACH

DSCH DSCH

←TFCI

←TFCI ←TFCI

FACH

Figure 4: Model of the UE's physical layer – downlink TDD mode

For the DCH case, the mapping between DCHs and physical channel data streams works in the same way as for theuplink. Note however, that the number of DCHs, the coding and multiplexing etc. may be different in uplink anddownlink.

In the FDD mode, the differences are mainly due to the soft and softer handover. Further, the pilot, TPC bits and TFCIare time multiplexed onto the same physical channel(s) as the DCHs. Further, the definition of physical channel datastream is somewhat different from the uplink. In TDD mode the TFCI is time multiplexed onto the same physicalchannel(s) as the DCHs. The exact locations and coding of the TFCI are signalled by higher layers.

Note that it is logically one and the same physical data stream in the active set of cells, even though physically there isone stream for each cell. The same processing and multiplexing is done in each cell. The only difference between thecells is the actual codes, and these codes correspond to the same spreading factor.

The physical channels carrying the same physical channel data stream are combined in the UE receiver, excluding thepilot, and in some cases the TPC bits. TPC bits received on certain physical channels may be combined provided thatUTRAN has informed the UE that the TPC information on these channels is identical.

ETSI


A PCH and one or several FACH can be encoded and multiplexed together forming a CCTrCH. Similarly as in theDCH model there is one TFCI for each CCTrCH for indication of the transport formats used on each PCH and FACH.The PCH is associated with a separate physical channel carrying page indicators (PIs) which are used to trigger UEreception of the physical channel that carries PCH. A FACH or a PCH can also be individually mapped onto a separatephysical channel. The BCH is always mapped onto one physical channel without any multiplexing with other transportchannels.

6.3 Relay link ModelThe Relay link applies to the TDD mode only.

Figure 4 illustrates the model of the UE's physical layer for the TDD mode.

ODCH

Coding

Phy CH

Coding

Phy CH

ORACH

ODCH model ORACHmodel

Figure 5: Model of the UE's physical layer - relay link TDD mode

The ORACH is a channel used within UE's to transmit and receive probing messages, and also to transmit and receivesmall packets of information. The ODCH is used to transmit larger amounts of data over a number of hops betweenUE's.

7 Formats and configurations for L1 data transfer

7.1 General concepts about Transport ChannelsLayer 2 is responsible for the mapping of data onto L1 via the L1/L2 interface that is formed by the transport channels.In order to describe how the mapping is performed and how it is controlled, some definitions and terms are required.The required definitions are given in the following subclauses. Note that the definitions are generic for all transportchannel types, i.e. not only for DCHs.

All Transport Channels are defined as unidirectional (i.e. uplink, downlink, or relay-link). This means that a UE canhave simultaneously (depending on the services and the state of the UE) one or several transport channels in thedownlink, and one or more Transport Channel in the uplink.

7.1.1 Transport Block

This is the basic unit exchanged between L1 and MAC, for L1 processing.

Layer 1 adds a CRC for each Transport Block.

ETSI


7.1.2 Transport Block Set

This is defined as a set of Transport Blocks, which are exchanged between L1 and MAC at the same time instance usingthe same transport channel.

7.1.3 Transport Block Size

This is defined as the number of bits in a Transport Block. The Transport Block Size is always fixed within a givenTransport Block Set, i.e. all Transport Blocks within a Transport Block Set are equally sized.

7.1.4 Transport Block Set Size

This is defined as the number of bits in a Transport Block Set.

7.1.5 Transmission Time Interval

This is defined as the inter-arrival time of Transport Block Sets, and is equal to the periodicity at which a TransportBlock Set is transferred by the physical layer on the radio interface. It is always a multiple of the minimum interleavingperiod (e.g. 10ms, the length of one Radio Frame). The MAC delivers one Transport Block Set to the physical layerevery TTI.

Figure 6 shows an example where Transport Block Sets, at certain time instances, are exchanged between MAC and L1via three parallel transport channels. Each Transport Block Set consists of a number of Transport Blocks. TheTransmission Time Interval, i.e. the time between consecutive deliveries of data between MAC and L1, is alsoillustrated.

DCH3

TransmissionTime Interval

DCH2

Transmission Time Interval

DCH1

Transmission Time Interval

Transport Block

Transport Block

Transport Block

Transport BlockTransport

Transport Block

Transport Block

Transport Block

Transport

Transport

Transport Block

Transport Block

Transport Block

Transport Block

Transport Block Transport Block

Transport Block

Transport Block

Figure 6: Exchange of data between MAC and L1

ETSI


7.1.6 Transport Format

This is defined as a format offered by L1 to MAC (and vice versa) for the delivery of a Transport Block Set during aTransmission Time Interval on a Transport Channel. The Transport Format constitutes of two parts – one dynamic partand one semi-static part.

Attributes of the dynamic part are:

- Transport Block Size;

- Transport Block Set Size;

- Transmission Time Interval (optional dynamic attribute for TDD only);

Attributes of the semi-static part are:

- Transmission Time Interval (mandatory for FDD, optional for the dynamic part of TDD NRT bearers);

- error protection scheme to apply:

- type of error protection, turbo code, convolutional code or no channel coding;

- coding rate;

- static rate matching parameter;

- size of CRC.

In the following example, the Transmission Time Interval is seen as a semi-static part.

EXAMPLE: Dynamic part: {320 bits, 640 bits}, Semi-static part: {10ms, convolutional coding only, static ratematching parameter = 1}.

7.1.7 Transport Format Set

This is defined as the set of Transport Formats associated to a Transport Channel.

The semi-static parts of all Transport Formats are the same within a Transport Format Set.

Effectively the first two attributes of the dynamic part form the instantaneous bit rate on the Transport Channel.Variable bit rate on a Transport Channel may, depending on the type of service, which is mapped onto the transportchannel, be achieved by changing between each Transmission Time Interval one of the following:

1. the Transport Block Set Size only;

2. both the Transport Block Size and the Transport Block Set Size Example 1:

- dynamic part: {20 bits, 20 bits}; {40 bits, 40 bits}; {80 bits, 80 bits}; {160 bits, 160 bits}.

- Semi-static part: {10ms, Convolutional coding only, static rate matching parameter = 1} Example 2:

- dynamic part: {320 bits, 320 bits}; {320 bits, 640 bits}; {320 bits, 1 280 bits}.

- Semi-static part: {10ms, Convolutional coding only, static rate matching parameter = 2}.

The first example may correspond to a Transport Channel carrying a speech service, requiring blocks delivered on aconstant time basis. In the second example, which illustrates the situation where a non-real time service is carried by theTransport Channel, the number of blocks delivered per Transmission Time Interval varies between the differentTransport Formats within the Transport Format Set. Referring to figure 6, the Transport Block Size is varied on DCH1and DCH2. That is, a Transport Format Set where the dynamic part has a variable Transport Block Size has beenassigned for DCH1. On DCH3 it is instead only the Transport Block Set Size that is varied. That is, the dynamic partsof the corresponding Transport Format Sets only include variable Transport Block Set Sizes.

ETSI


7.1.8 Transport Format Combination

The layer 1 multiplexes one or several Transport Channels, and for each Transport Channel, there exists a list oftransport formats (Transport Format Set) which are applicable. Nevertheless, at a given point of time, not allcombinations may be submitted to layer 1 but only a subset, the Transport Format Combination. This is defined as anauthorised combination of the combination of currently valid Transport Formats that can be submitted simultaneously tothe layer 1 for transmission on a Coded Composite Transport Channel of a UE, i.e. containing one Transport Formatfrom each Transport Channel.

EXAMPLE:

DCH1: Dynamic part: {20 bits, 20 bits}, Semi-static part: {10ms, Convolutional coding only, static ratematching parameter = 2};

DCH2: Dynamic part: {320 bits, 1 280 bits}, Semi-static part: {10ms, Convolutional coding only, staticrate matching parameter = 3};

DCH3: Dynamic part: {320 bits, 320 bits}, Semi-static part: {40ms, Turbo coding, static rate matchingparameter = 2}.

7.1.9 Transport Format Combination Set

This is defined as a set of Transport Format Combinations on a Coded Composite Transport Channel.

EXAMPLE:

- dynamic part:

- combination 1: DCH1: {20 bits, 20 bits}, DCH2: {320 bits, 1280 bits}, DCH3: {320 bits, 320 bits};

- combination 2: DCH1: {40 bits, 40 bits}, DCH2: {320 bits, 1280 bits}, DCH3: {320 bits, 320 bits};

- combination 3: DCH1: {160 bits, 160 bits}, DCH2: {320 bits, 320 bits}, DCH3: {320 bits, 320 bits}

- semi-static part:

- DCH1: {10ms, Convolutional coding only, static rate matching parameter = 1};

- DCH2: {10ms, Convolutional coding only, static rate matching parameter = 1};

- DCH3: {40ms, Turbo coding, static rate matching parameter = 2}.

The Transport Format Combination Set is what is given to MAC for control. However, the assignment of the TransportFormat Combination Set is done by L3. When mapping data onto L1, MAC chooses between the different TransportFormat Combinations given in the Transport Format Combination Set. Since it is only the dynamic part that differbetween the Transport format Combinations, it is in fact only the dynamic part that MAC has any control over.

The semi-static part, together with the target value for the L1 closed loop power control, correspond to the serviceattributes:

- quality (e.g. BER);

- transfer delay.

These service attributes are then offered by L1. However, it is L3 that guarantees that the L1 services are fulfilled sinceit is in charge of controlling the L1 configuration, i.e. the setting of the semi-static part of the Transport Formats.Furthermore, L3 controls the target for the L1 closed loop power control through the outer loop power control (whichactually is a quality control rather than a power control).

Note that a Transport Format Combination Set need not contain all possible Transport Format Combinations that can beformed by Transport Format Sets of the corresponding Transport Channels. It is only the allowed combinations that areincluded. Thereby a maximum total bit rate of all transport channels of a Code Composite Transport Channel can be setappropriately. That can be achieved by only allowing Transport Format Combinations for which the included TransportFormats (one for each Transport Channel) do not correspond to high bit rates simultaneously.

ETSI


The selection of Transport Format Combinations can be seen as a fast part of the radio resource control. The dedicationof these fast parts of the radio resource control to MAC, close to L1, means that the flexible variable rate schemeprovided by L1 can be fully utilised. These parts of the radio resource control should be distinguished from the slowerparts, which are handled by L3. Thereby the bit rate can be changed very fast, without any need for L3 signalling.

7.1.10 Transport Format Indicator (TFI)

The TFI is a label for a specific transport format within a transport format set. It is used in the inter-layercommunication between MAC and L1 each time a transport block set is exchanged between the two layers on atransport channel.

When the DSCH is associated with a DCH, the TFI of the DSCH also indicates the physical channel (i.e. thechannelisation code) of the DSCH that has to be listened to by the UE.

7.1.11 Transport Format Combination Indicator (TFCI)

This is a representation of the current Transport Format Combination.

There is a one-to-one correspondence between a certain value of the TFCI and a certain Transport Format Combination.The TFCI is used in order to inform the receiving side of the currently valid Transport Format Combination, and hencehow to decode, de-multiplex and deliver the received data on the appropriate Transport Channels.

MAC indicates the TFI to Layer 1 at each delivery of Transport Block Sets on each Transport Channel. Layer 1 thenbuilds the TFCI from the TFIs of all parallel transport channels of the UE , processes the Transport Blocksappropriately and appends the TFCI to the physical control signalling . Through the detection of the TFCI the receivingside is able to identify the Transport Format Combination. For FDD, in case of limited Transport Format CombinationSets the TFCI signalling may be omitted, instead relying on blind detection. Nevertheless, from the assigned TransportFormat Combinations, the receiving side has all information it needs in order to decode the information and transfer itto MAC on the appropriate Transport Channels.

The multiplexing and exact rate matching patterns follow predefined rules and may therefore be derived (given theTransport Format Combinations) by transmitter and receiver without signalling over the radio interface.

When the meaning of the TFCI field needs to be reconfigured, two procedures can be used depending on the level ofreconfiguration:

- complete reconfiguration of TFCI: in this procedure all TFCI values are reinitialised and new values aredefined instead. The complete reconfiguration requires an explicit synchronisation between the UE and UTRANregarding when the reconfiguration becomes valid.

- incremental reconfiguration of TFCI: in this procedures, a part of the TFCI values before and after thereconfiguration remain identical (note that this must be true for at least a TFCI that carry the signallingconnection). This procedure supports addition, removal or redefinition of TFCI values. This procedure does notrequire an explicit execution time. This procedure may imply the loss of some user-plane data.

7.1.12 Rate matching

Two levels of rate matching are defined on the radio interface:

- a static rate matching per Transport Channel. The static rate matching is part of the semi-static attributes of theTransport Channel;

- a dynamic rate matching per CCTrCH. The dynamic rate matching adjusts the size of the physical layer datapayload to the physical channel as requested by RRC.

The static rate matching and the dynamic rate matching to be applied by the physical layer are indicated by RRC to thephysical layer.

In FDD, RRC is also responsible for configuring the physical layer on whether:

- Blind Rate Detection or TFCI is used;

- dynamic rate matching is applied or not on the downlink.

ETSI


7.2 Types of Transport ChannelsA general classification of transport channels is into two groups:

- common channels; and

- dedicated channels (where the UEs can be unambiguously identified by the physical channel, i.e. code andfrequency).

Common transport channel types are:

1. Random Access Channel(s) (RACH) characterised by:

- existence in uplink only;

- limited data field;

- collision risk;

- open loop power control.

2. ODMA Random Access Channel(s) (ORACH) characterised by:

- used in TDD mode only;

- existence in relay-link;

- collision risk;

- open loop power control;

- no timing advance control.

3. Forward Access Channel(s) (FACH) characterised by:

- existence in downlink only;

- possibility to use beam forming;

- possibility to use slow power control;

- possibility to change rate fast (each 10ms); and

- lack of fast power control.

4. Broadcast Channel (BCH) characterised by:


- low fixed bit rate; and

- requirement to be broadcast in the entire coverage area of the cell.

5. Paging Channel (PCH) characterised by:


- association with a physical layer signal, the Page Indicator, to support efficient sleep mode procedures; and

- requirement to be broadcast in the entire coverage area of the cell.

ETSI


6. Downlink Shared Channel(s) (DSCH) characterised by:


- possibility to use beamforming;

- possibility to use slow power control;

- possibility to use fast power control, when associated with dedicated channel(s);

- possibility to be broadcast in the entire cell;

- always associated with another channel (DCH or FACH (TDD)).

7. CPCH Channel characterised by:

- existence in FDD only;


- fast power control on the message part;


- possibility to change rate fast;

- collision detection;

- open loop power estimate for pre-amble power ramp-up.

8. Uplink Shared channel (USCH) characterised by:

- used in TDD only;



- possibility to use power control;

- possibility to change rate fast;

- possibility to use Uplink Synchronisation.

Possibility to use Timing advance Dedicated transport channel types are:

1. Dedicated Channel (DCH) characterised by:

- existing in uplink or downlink;


- possibility to change rate fast (each 10ms);

- fast power control;

- possibility to use timing advance in uplink (TDD only);

- possibility to use Uplink Synchronisation.

2. Fast Uplink Signalling Channel (FAUSCH) to allocate, in conjunction with FACH, dedicated channels; theFAUSCH is characterised by:

- existing in uplink only;

- inherent addressing of a UE by a unique time-offset (indicating to a UE when to send an uplink signallingcode, USC) related to the beginning of the 10 ms frame;

ETSI


- allowing for a UE to notify (by sending an USC) a request for a DCH, the allocation of which is messagedvia the FACH. No further information is conveyed via the FAUSCH.

NOTE: Applicability for TDD mode is FFS.

3. ODMA Dedicated Channel (ODCH) characterised by:

- used in TDD mode only;


- possibility to change rate fast (each 10ms);

- closed loop power control;

- closed loop timing advance control.

To each transport channel (except for the FAUSCH, since it only conveys a reservation request),, there is an associatedTransport Format (for transport channels with a fixed or slow changing rate) or an associated Transport Format Set (fortransport channels with fast changing rate).

7.3 Compressed ModeCompressed Mode is defined as the mechanism whereby certain idle periods are created in radio frames so that the UEcan perform measurements during these periods (more details can be found in [3]).

Compressed Mode is obtained by layer 2 using transport channels provided by the layer 1 as follows:

- compressed mode is controlled by the RRC layer, which configures the layer 2 and the physical layer;

- the number of occurrences of compressed frames is controlled by RRC, and can be modified by RRC signalling;

- it is under the responsibility of the layer 2 if necessary and if possible to either buffer some layer 2 PDUs(typically at the RLC layer for NRT services) or to rate adapt the data flow (similarly to GSM) so that there is noloss of data because of compressed mode. This will be service dependent and controlled by the RRC layer.

For measurements in compressed mode, a transmission gap pattern sequence is defined. A transmission gap patternsequence consists of alternating transmission gap patterns 1 and 2, and each of these patterns in turn consists of one ortwo transmission gaps. The transmission gap pattern structure, position and repetition are defined with physical channelparameters described in [3]. In addition, the UTRAN configures compressed mode pattern sequences with the thefollowing parameters:

- TGMP: Transmission Gap pattern sequence Measurement Purpose: This parameter defines the purpose thistransmission gap pattern sequence is intended for. The following values are used:

- 'TDD measurement', for which one compressed mode pattern sequence can be configured,

- 'FDD measurement', for which one compressed mode pattern sequence can be configured,

- 'GSM measurement', for which three simultaneous compressed mode pattern sequences can be configured,

- 'Other', for which one compressed mode pattern sequence can be configured;

- TGPSI: Transmission Gap Pattern Sequence Identifier selects the compressed mode pattern sequence for whichthe parameters are to be set. The range of TGPSI is [1 to <MaxTGPS>].

The UE shall support a total number of simultaneous compressed mode pattern sequences, which is determined by theUE's capability to support each of the measurement types categorised by the TGMP. For example, a UE supportingFDD and GSM shall support four simultaneous compressed mode pattern sequences and a UE supporting FDD andTDD shall support two simultaneous compressed mode pattern sequences.

When using simultaneous pattern sequences, it is the responsibility of the NW to ensure that the compressed mode gapsdo not overlap and are not scheduled to overlap the same frame. Gaps exceeding the maximum gap length shall not beprocessed by the UE and shall interpreted as a faulty message. If the UE detects overlapping gaps, it shall process thegap from the pattern sequence having the lowest TGPSI.

ETSI


8 UE Simultaneous Physical Channels combinationsThis clause describes the requirements from the UE to send and receive on multiple Transport Channels, which aremapped on different physical channels simultaneously depending on the service capabilities and requirements. Theclause will describe the impacts on the support for multiple services (e.g. speech call and SMS-CB) depending on theUE capabilities.

8.1 FDD UplinkThe table describes the possible combinations of FDD physical channels that can be supported in the uplink on the samefrequency by one UE at any one time.

Table 1: FDD Uplink

Physical ChannelCombination

TransportChannel

Combination

Mandatory ordependent on UE

radio accesscapabilities

Comment

1 PRACH RACH Mandatory The PRACH physical channel includes thepreambles and the message.

2 PRACH FAUSCH Depending on UEradio accesscapabilities

3 PCPCH consistingof one control andone data partduring themessage portion

CPCH Depending on UEradio accesscapabilities

The PCPCH physical channel includes thepreambles and the message.The maximum channel bit rate is dependant onUE radio access capabilities.

4 PCPCH consistingof one control andmore than onedata part duringthe messageportion

CPCH Depending on UEradio accesscapabilities

The PCPCH physical channel includes thepreambles and the message.The maximum channel bit rate is dependant onUE radio access capabilities.

5 DPCCH+DPDCH One or more DCHcoded into a singleCCTrCH

Mandatory The maximum number of DCHs and themaximum channel bit rate are dependant on UEradio access capabilities.

6 DPCCH+ morethan one DPDCH

One or more DCHcoded into a singleCCTrCH

Depending on UEradio accesscapabilities

The maximum number of DCHs and themaximum channel bit rate are dependant on UEradio access capabilities.

ETSI


8.2 FDD DownlinkThe table describes the possible combinations of FDD physical channels that can be supported in the downlink on thesame frequency by one UE at any one time.

Table 2: FDD Downlink

PhysicalChannel

Combination

TransportChannel

Combination

Mandatory dependenton UE radio access

capabilities

Comment

1 PCCPCH BCH Mandatory2 SCCPCH FACH + PCH Mandatory The maximum channel bit rate that can be

supported is dependent on the UE radioaccess capabilities.

3 PCCPCH +SCCPCH

BCH + FACH +PCH

Mandatory Simultaneous reception of PCCPCH andSCCPCH is only needed at occurrences whenthe UE needs to read system information onBCH while being in CELL_FACH state, i.e.continuous reception of both PCCPCH andSCCPCH at the same time is not required.The requirement holds for PCCPCH andSCCPCH sent in different cells or in the samecell.

4 SCCPCH +AICH

FACH + PCH +RACH in uplinkOrFACH + PCH +CPCH in uplink

Mandatory The maximum channel bit rate that can besupported is dependent on the UE radioaccess capabilities.This physical channel combination facilitatesthe preamble portion of the CPCH in theuplink

5 SCCPCH +DPCCH

FACH + PCH +CPCH in uplink

Depending on UE radioaccess capabilities

This physical channel combination facilitatesthe message portion of the CPCH in theuplink

6 More than oneSCCPCH

More than oneFACH + PCH


7 PICH N/A Mandatory8 DPCCH +

DPDCHOne or more DCHcoded into a singleCCTrCH

Mandatory The maximum number of DCHs and themaximum channel bit rate are dependent onUE radio access capabilities.

9 DPCCH + morethan oneDPDCH

One or more DCHcoded into a singleCCTrCH


The maximum number of DCHs and themaximum channel bit rate are dependent onUE radio access capabilities.

10 One or morePDSCH +DPCCH + oneor more DPDCH

One or more DSCHcoded into a singleCCTrCH + one ormore DCH codedinto a singleCCTrCH


The maximum number of DCHs and themaximum channel bit rate are dependent onUE radio access capabilities.

11 SCCPCH +DPCCH + oneor more DPDCH

FACH + one ormore DCH codedinto a singleCCTrCH


The maximum number of DCHs and themaximum channel bit rate are dependent onUE radio access capabilities.This combination of physical channels is usedfor DRAC control of an uplink DCH and forreceiving services such as cell broadcast ormulticast whilst in connected mode.

12 SCCPCH + oneor more PDSCH+ DPCCH + oneor more DPDCH

FACH + one ormore DSCH codedinto a singleCCTrCH + one ormore DCH codedinto a singleCCTrCH


The maximum number of DCHs and themaximum channel bit rate are dependent onUE radio access capabilities.This combination of physical channels is usedfor simultaneous DSCH and DRAC control ofan uplink DCH.

13 One DPCCH +more than oneDPDCH

More than oneDCH coded intoone or moreCCTrCH


ETSI


8.3 TDD UplinkThe table describes the possible combinations of TDD physical channels that can be supported in the uplink by one UEin any one 10ms frame, where a TDD physical channel corresponds to one code, one timeslot, one frequency and ismapped to one resource unit (RU). This table addresses combinations of uplink physical channels in the same 10msframe.

Table 3: TDD Uplink


TransportChannel

Combination



Comment

1 PRACH RACH Mandatory One RACH transport channel maps to onePRACH physical channel.

2 One or moreDPCH

One or more DCHcoded into one ormore CCTrCH


The maximum number of DCHs and themaximum channel bit rate are dependent on UEradio access capabilities.

3 PRACH + one ormore DPCH

RACH + one ormore DCH codedinto one or moreCCTrCH


One RACH transport channel maps to onePRACH physical channelThe maximum number of DCHs and themaximum channel bit rate are dependent on UEradio access capabilities.

4 One or morePUSCH

One or moreUSCH coded ontoone or moreCCTrCH


It is assumed here that a USCH transport channelmay map to one or more PUSCH physicalchannels based on system configuration.USCH requires a control channel (RACH orDCH); however, it is not required to be in thesame 10ms frame as the USCH.

5 PRACH + one ormore PUSCH

RACH + One ormore USCHcoded on to oneor more CCTrCH


One RACH transport channel maps to onePRACH physical channel.It is assumed here that a USCH transport channelmay map to one or more PUSCH physicalchannels based on system configuration.

6 One or morePUSCH + one ormore DPCH

One or moreUSCH coded ontoone or moreCCTrCH + one ormore DCH codedinto one or moreCCTrCH


The maximum number of DCHs and themaximum channel bit rate are dependent on UEradio access capabilities.It is assumed here that a USCH transport channelmay map to one or more PUSCH physicalchannels based on system configuration.

7 PRACH + one ormore PUSCH +one or moreDPCH

RACH + one ormore USCHcoded onto one ormore CCTrCH +one or more DCHcoded into one ormore CCTrCH


One RACH transport channel maps to onePRACH physical channel.The maximum number of DCHs and themaximum channel bit rate are dependent on UEradio access capabilities.It is assumed here that a USCH transport channelmay map to one or more PUSCH physicalchannels based on system configuration.

ETSI


8.4 TDD DownlinkThe table describes the possible combinations of TDD physical channels that can be supported in the downlink by oneUE in any one 10ms frame, where a TDD physical channel corresponds to one code, one timeslot, one frequency and ismapped to one resource unit (RU). This table addresses combinations of downlink physical channels in the same 10msframe.

Table 4: TDD Downlink

PhysicalChannel

Combination

TransportChannel

Combination



Comment

1 P-CCPCH and/orOne or moreS-CCPCH +PICH

BCH and/orPCH and/orone or more FACH

Mandatory BCH maps to the P-CCPCH in a frame.FACH can map to multiple S-CCPCH in a frame.PCH can map to multiple S-CCPCH in a frame.PICH substitutes one or more paging sub-channels that are mapped on an S-CCPCHassigned for the PCH transport channel.

2 One or moreDPCH



The maximum number of DCHs and themaximum channel bit rate are dependent on UEradio access capabilities.

3 P-CCPCH and/orOne or moreS-CCPCH +PICH + one ormore DPCH

BCH and/orPCH and/orone or more FACH+ one or moreDCH coded intoone or moreCCTrCH


The number of DCHs and the maximum channelbit rate are dependent on the UE radio accesscapabilities.BCH maps to the P-CCPCH in a frame.FACH can map to multiple S-CCPCH in a frame.PICH substitutes one or more paging sub-channels that are mapped on an S-CCPCHassigned for the PCH transport channel.

4 One or morePDSCH

One or moreDSCH coded ontoone or moreCCTrCH


It is assumed here that a DSCH transport channelmay map to one or more PDSCH physicalchannels based on system configuration.DSCH requires a control channel (FACH orDCH); however, it is not required to be in thesame 10ms frame as the DSCH.

5 One or morePDSCH + P-CCPCH and/orone or more S-CCPCH + PICH

BCH and/orPCH and/orone or more FACH+ one or moreDSCH coded ontoone or moreCCTrCH


BCH maps to the P-CCPCH in a frame.Each FACH can map to multiple S-CCPCH in aframe.PICH substitutes one or more paging sub-channels that are mapped on an S-CCPCHassigned for the PCH transport channel.It is assumed here that a DSCH transport channelmay map to one or more PDSCH physicalchannels based on system configuration.For the case of DSCH + BCH, DSCH requires acontrol channel (FACH or DCH); however, it is notrequired to be in the same 10ms frame as theDSCH.

6 One or morePDSCH + one ormore DPCH

One or moreDSCH coded ontoone or moreCCTrCH + one ormore DCH codedinto one or moreCCTrCH


The maximum number of DCHs and themaximum channel bit rate are dependent on UEradio access capabilities.It is assumed here that a DSCH transport channelmay map to one or more PDSCH physicalchannels based on system configuration.

ETSI


PhysicalChannel

Combination

TransportChannel

Combination



Comment

7 One or morePDSCH + P-CCPCH and/orone or more S-CCPCH + PICH+ one or moreDPCH

BCH and/orPCH and/orone or more FACH+ one or moreDSCH coded ontoone or moreCCTrCH + one ormore DCH codedinto one or moreCCTrCH


BCH maps to the P-CCPCH in a frame.Each FACH can map to multiple S-CCPCH in aframe.PICH substitutes one or more paging sub-channels that are mapped on an S-CCPCHassigned for the PCH transport channel.The maximum number of DCHs and themaximum channel bit rate are dependent on UEradio access capabilities.It is assumed here that a DSCH transport channelmay map to one or more PDSCH physicalchannels based on system configuration.

NOTE: Reference: TS 25.221: Physical Channels and Mapping of Transport Channels Onto Physical Channels(TDD).

8.5 TDD UE Uplink and Downlink Combinations (within 10 msair frames)

This table describes the possible uplink and downlink physical channel combinations that can be supported by a UE inTDD mode.

Table 5: TDD UE Uplink and Downlink Combinations (within 10 ms airframes)

DL PhysicalChannel

Combination

DL TransportChannel

Combination

UL PhysicalChannel

Combination

UL TransportChannel

Combination

Mandatoryor

dependenton UE radio

accesscapabilities

Comment

1 P-CCPCH PRACH RACH Mandatory One RACH transportchannel maps to onePRACH physicalchannel.P-CCPCH is used forreference power todetermine path loss forRACH transmit powercalculation.

2 P-CCPCHand/or one ormore S-CCPCH +PICH

BCH and/orPCH and/orone or moreFACH

Mandatory BCH maps to the P-CCPCH in a frame.FACH or PCH can mapto multiple S-CCPCH ina frame.



PRACH RACH Mandatory One RACH transportchannel maps to onePRACH physicalchannelBCH maps to the P-CCPCH in a frame.FACH or PCH can mapto multiple SCCPCH ina frame.P-CCPCH is used forreference power todetermine path loss forRACH transmit powercalculation.

ETSI


DL PhysicalChannel

Combination

DL TransportChannel

Combination

UL PhysicalChannel

Combination

UL TransportChannel

Combination

Mandatoryor


accesscapabilities

Comment



PRACH andone or moreDPCH

RACH and oneor more DCHcoded into oneor moreCCTrCH

Dependingon UE radioaccesscapabilities

The maximum numberof DCHs and themaximum channel bitrate are dependent onUE radio accesscapabilities.BCH maps to P-CCPCHin a frame. FACH orPCH can map tomultiple S-CCPCH in aframe.P-CCPCH is used forreference power todetermine path loss forRACH and UL- DPCHtransmit powercalculations.

5 P-CCPCHand/or one ormore

S-CCPCH +PICH and oneor more DPCH

BCH and/orPCH and/orone or moreFACH andone or moreDCH codedonto one ormore CCTrCH

PRACH andone or moreDPCH

RACH and oneor more DCHcoded into oneor moreCCTrCH


The maximum numberof DCHs and themaximum channel bitrate are dependent onUE radio accesscapabilities.See note.BCH maps to P-CCPCHin a frame. FACH orPCH can map tomultiple S-CCPCH in aframe.P-CCPCH is used forreference power todetermine path loss forRACH and UL- DPCHtransmit powercalculations.

6 P-CCPCH One or moreDPCH

One or moreDCH codedinto one ormore CCTrCH


The maximum numberof DCHs and themaximum channel bitrate are dependent onUE radio accesscapabilities.P-CCPCH is used forreference power todetermine path loss forUL- DPCH transmitpower calculations.

7 P-CCPCH andone or moreDPCH

One or moreDCH codedonto one ormore CCTrCH

One or moreDPCH

One or moreDCH codedinto one ormore CCTrCH


The maximum numberof DCHs and themaximum channel bitrate are dependent onUE radio accesscapabilities.P-CCPCH is used forreference power todetermine path loss forUL- DPCH transmitpower calculations.See note.

NOTE: The requirement for an UL DPCH to exist in every 10 ms frame for DL Power Control, Transmit Diversity,and Joint Pre-distortion is FFS.

ETSI


8.6 TDD UE Uplink Timeslot CombinationsThis table describes possible uplink physical channels that can be supported by a UE within a specific time slot.

Table 6: TDD UE Uplink Timeslot Combinations


TransportChannel

Combination

Mandatoryor


accesscapabilities

Comment

1 PRACH RACH Mandatory Time slots supporting RACH do not support otherchannel types.One RACH transport channel maps to one PRACHphysical channel.

2 One or moreDPCH


Depending onUE radioaccesscapabilities

The maximum number of DCHs and the maximumchannel bit rate are dependent on radio accesscapabilities.

3 One or morePUSCH

One or moreUSCH coded ontoone or moreCCTrCH


It is assumed here that a USCH transport channel maymap to one or more PUSCH physical channels basedon system configuration.USCH requires a control channel (RACH/FACH orDCH); however, it is not required to be in the same10 ms frame as the USCH.

4 One or morePUSCH + one ormore DPCH

One or moreUSCH coded ontoone or moreCCTrCH + one ormore DCH codedinto one or moreCCTrCH


The maximum number of DCHs and the maximumchannel bit rate are dependent on UE radio accesscapabilities.It is assumed here that a USCH transport channel maymap to one or more PUSCH physical channels basedon system configuration.

ETSI


8.7 TDD UE Downlink Timeslot CombinationsThis table describes possible downlink physical channels that can be supported by a UE within a specific time slot.

Table 7: TDD UE Downlink Timeslot Combinations

PhysicalChannel

Combination

TransportChannel

Combination

Mandatoryor


accesscapabilities

Comment

1 P-CCPCHand/or one ormore S-CCPCH+ PICH

BCH and/orPCH and/orone or more FACH

Mandatory BCH maps to the P-CCPCH in a frame.FACH can map to multiple S-CCPCH in a frame.PCH can map to multiple S-CCPCH in a frame.PICH substitutes one or more paging sub-channels thatare mapped on an S-CCPCH assigned for the PCHtransport channel.

2 One or moreDPCH



The maximum number of DCHs and the maximumchannel bit rate are dependent on radio accesscapabilities

3 P-CCPCH and/orone or more S-CCPCH+ PICH +one or moreDPCH

BCH and/orPCH and/orone or more FACHand one or moreDCH coded intoone or moreCCTrCH


The number of DCHs and the maximum channel bit rateare dependent on the UE radio access capabilities.BCH maps to the P-CCPCH in a frame.FACH can map to multiple S-CCPCH in a frame.PICH substitutes one or more paging sub-channels thatare mapped on an S-CCPCH assigned for the PCHtransport channel.

4 One or morePDSCH

One or moreDSCH coded ontoone or moreCCTrCH


It is assumed here that a DSCH transport channel maymap to one or more PDSCH physical channels basedon system configuration.DSCH requires a control channel (FACH or DCH);however, it is not required to be in the same 10msframe as the DSCH.

5 P-CCPCH and/orone or morePDSCH + one ormore S-CCPCH+PICH

BCH and/orPCH and/orone or more FACHand one or moreDSCH coded ontoone or moreCCTrCH


BCH maps to the P-CCPCH in a frame.Each FACH can map to multiple S-CCPCH in a frame.PICH substitutes one or more paging sub-channels thatare mapped on an S-CCPCH assigned for the PCHtransport channel.It is assumed here that a DSCH transport channel maymap to one or more PDSCH physical channels basedon system configuration.For the case of DSCH + BCH, DSCH requires a controlchannel (FACH or DCH); however, it is not required tobe in the same 10ms frame as the DSCH.

6 One or morePDSCH + one ormore DPCH

One or moreDSCH coded ontoone or moreCCTrCH + one ormore DCH codedinto one or moreCCTrCH


The maximum number of DCHs and the maximumchannel bit rate are dependent on UE radio accesscapabilities.It is assumed here that a DSCH transport channel maymap to one or more PDSCH physical channels basedon system configuration.

7 One or morePDSCH +

P-CCPCH and/orone or more S-CCPCH+ PICH+one or moreDPCH

BCH and/orPCH and/orone or more FACHand one or moreDSCH coded ontoone or moreCCTrCH and oneor more DCHcoded into one ormore CCTrCH


BCH maps to the P-CCPCH in a frame.Each FACH can map to multiple S-CCPCH in a frame.PICH substitutes one or more paging sub-channels thatare mapped on an S-CCPCH assigned for the PCHtransport channel.The maximum number of DCHs and the maximumchannel bit rate are dependent on UE radio accesscapabilities.It is assumed here that a DSCH transport channel maymap to one or more PDSCH physical channels basedon system configuration.

NOTE: Reference: TS25.221: Physical Channels and Mapping of Transport Channels Onto Physical Channels(TDD).

ETSI


9 Measurements provided by the physical layerOne of the key services provided by the physical layer is the measurement of various quantities, which are used totrigger or perform a multitude of functions. Both the UE and the UTRAN are required to perform a variety ofmeasurements. The standard will not specify the method to perform these measurements or stipulate that the list ofmeasurements provided in this clause must all be performed. While some of the measurements are critical to thefunctioning of the network and are mandatory for delivering the basic functionality (e.g., handover measurements,power control measurements), others may be used by the network operators in optimising the network (e.g., radioenvironment).

Measurements may be made periodically and reported to the upper layers or may be event-triggered (e.g., primaryCCPCH becomes better than the previous best primary CCPCH). Another reporting strategy may combine the eventtriggered and the periodical approach (e.g. falling of link quality below a certain threshold initiates periodicalreporting). The measurements are tightly coupled with the service primitives in that the primitives' parameters mayconstitute some of the measurements.

The list and frequency of measurements, which the physical layer reports to higher layers, is described in this clause.The precision requirements of the measurements are specified in TS 25.103. The detailed definition of themeasurements together with the range and mapping is contained in TS 25.215 and TS 25.225.

The measurement quantities measured by the physical layer shall be such that the following principles are applied:

- for handover measurements, the decoding of parameters on the BCCH logical channel of monitoredneighbouring cells, should not, in general, be needed for calculating the measurement result. If there is a need toadjust the measurement result with parameters broadcast on the PCCPCH, these parameters shall be provided bythe UTRAN in inband measurement control messages. There may be some exceptions to this rule;

EXAMPLE: It may be necessary to decode the SFN of the measured neighbouring cell for time differencemeasurements.

- in idle mode or in RRC connected mode using common Transport Channels, the UE shall be able to monitorcells for cell reselection, without being required to frequently decode parameters on the BCCH logical channel ofthe monitored neighbouring cells. The decoding frequency of these parameters, set by the cell reselectionalgorithm, should be such that UE standby times are not significantly decreased.

9.1 Model of physical layer measurementsThis subclause describes a model for how the physical layer measurements are performed. This model applies both tothe UE and Node B measurements.

The measurement model for physical layer measurements is represented in the figure 7.

Layer 1filtering

Layer 3filtering Evaluation

of reportingcriteria

A DB C

C'

parameters parameters

Figure 7: Measurement model

The model is described below:

- A: measurements (samples) internal to the physical layer in support to the measurements to be provided tohigher layers;

ETSI


- Layer 1 filtering: internal layer 1 filtering of the inputs measured at point A. Exact filtering is implementationdependant. How the measurements are actually executed in the physical layer by an implementation (inputs Aand Layer 1 filtering) in not constrained by the standard i.e. the model does not state a specific sampling rate oreven if the sampling is periodic or not. What the standard specifies is the performance objective and reportingrate at point B in the model. The performance objectives for the physical layer measurements are specified in [9]and [10];

- B: A measurement reported by layer 1 after layer 1 filtering. The reporting rate at point B is defined by thestandard and is measurement type specific. It is chosen to be equal to the measurement period over whichperformance objectives are defined in [9] and [10]. As a consequence, by setting the layer 3 filtering to "nofiltering", the performance of the layer 1 implementation can be tested. This means that the physical layer canorganise its internal measurements between these reporting at point B to meet the performance requirements;

- Layer 3 filtering: Filtering performed on the measurements provided at point B. The Layer 3 filters arestandardised and the configuration of the layer 3 filters is provided by RRC signalling (UE measurements) orNBAP signalling (Node B measurements);

- C: A measurement after processing in the layer 3 filter. The reporting rate is identical to the reporting rate atpoint B and is therefore also measurement type specific. Although this is not shown in the figure, onemeasurement can be used by a multiplicity of evaluation of reporting criteria;

- Evaluation of reporting criteria: This checks whether actual measurement reporting is necessary at point Di.e. whether a message need to be sent to higher layers on the radio interface or Iub interface. The evaluation canbe based on more than one flow of measurements at reference point C e.g. to compare between differentmeasurements. This is illustrated by input C, C', etc. The reporting criteria are standardised and the configurationis provided by RRC signalling (UE measurements) or NBAP signalling (Node B measurements). Examples areperiodic reporting and event based reporting. In case periodical reporting is in use and if the reporting interval isdifferent from the filtering period defined by the layer 3 filter, the last measurement result filtered by the L3filter is used as the value for reporting criteria evaluation and as the value of the reported result;

- D: a measurement report information (message) sent on the radio or Iub interface.

9.2 UE Measurements

9.2.1 SFN-CFN observed time difference

This measure is mandatory for the UE.

Measurement SFN-CFN observed time differenceSource L1 (UE)Destination RRC (RNC) for handoverReporting Trigger On-demand, Event-triggeredDefinition The 'SFN-CFN observed time difference' indicates the time difference (in chips for FDD

and in frames for TDD) which is measured by the UE between the SFN of the targetneighbouring cell and the CFN in the UE.

9.2.2 Observed time difference to GSM cell

This measure is mandatory for the UE if the handover to GSM service is to be supported.

Measurement Observed time difference to GSM cell

Source L1 (UE)Destination RRC (RNC) for maintenance and handover to GSMReporting Trigger On-demand, Event-triggeredDefinition Time difference between a specific UTRA and the timing of the GSM cell.

ETSI


9.2.3 CPICH Ec/N0


Measurement CPICH Ec/NoSource L1(UE)Destination RRC (UE, RNC)Reporting Trigger Periodic, on demand and event triggeredDefinition The received energy per chip of the CPICH divided by the power density in the frequency

band. The Ec/No is identical to RSCP /RSSI.

9.2.4 CPICH SIR

This measure is not included in release 99.

Measurement CPICH SIRSource L1 (UE)Destination RRC (UE, RNC)Reporting Trigger periodic or event triggeredDefinition This quantity is a ratio of the CPICH Received Signal Code Power (RSCP) to the

Interference Signal Code Power (ISCP).

9.2.5 CPICH RSCP


Measurement CPICH RSCPSource L1(UE)Destination RRC (UE, RNC)Reporting Trigger periodic or event triggeredDefinition Received Signal Code Power, is the received power on the CPICH after despreading.

9.2.6 P-CCPCH RSCP


Measurement P-CCPCH RSCPSource L1(UE)Destination RRC (UE, RNC)Reporting Trigger periodic or event triggeredDefinition Received Signal Code Power of the P-CCPCH is the received power after despreading.

This measurement is applicable for TDD cells only.

9.2.7 Timeslot ISCP


Measurement Timeslot ISCPSource L1(UE)Destination RRC (UE, RNC)Reporting Trigger periodic or event triggeredDefinition Interference Signal Code Power is the interference on the received signal in a specified

timeslot measured on the midamble. This measurement is applicable for TDD only.

ETSI


9.2.8 CPICH ISCP


Measurement CPICH ISCPSource L1(UE)Destination RRC (UE, RNC)Reporting Trigger periodic or event triggeredDefinition Interference on Signal Code Power, is the interference on the received signal after

despreading. Thereby only the non-orthogonal part of the interference is included.

9.2.9 SIR


Measurement SIRSource L1(UE)Destination RRC (UE,RNC)Reporting Trigger Periodic, once every power control cycle , event triggeredDefinition Signal to Interference Ratio is defined as (RSCP / ISCP) x (SF/2) for FDD and as (RSCP /

ISCP) x SF for TDD. For FDD this is measured on the DPCCH. For TDD this is measuredon the DPCH or PDSCH.

9.2.10 UTRA carrier RSSI


Measurement UTRA carrier RSSISource L1(UE)Destination RRC (RNC)Reporting Trigger Periodic, event triggered, on demandDefinition Received Signal Strength Indicator, the wideband received power within the channel

bandwidth. For TDD this is measured in specified timeslots.

9.2.11 GSM carrier RSSI

This measure is mandatory for the UE if the service handover to GSM is to be supported.

Measurement GSM carrier RSSISource L1(UE)Destination RRC (RNC)Reporting Trigger Periodic, event triggered, on demandDefinition Received Signal Strength Indicator, the wide-band received power within the relevant

channel bandwidth. Details are specified in the GSM specification 05.08

9.2.12 Transport channel BLER


Measurement Transport channel BLER (BLock Error Rate)Source L1(UE)Destination RRC (RNC,UE)Reporting Trigger Periodic, on demandDefinition Estimation of the transport channel block error rate (BLER).

ETSI


9.2.13 UE transmitted power


Measurement UE transmitted powerSource L1(UE)Destination RRC (UE,RNC)Reporting Trigger On-demand, periodic, Event-triggeredDefinition RRC (UE): the total transmitted power of the UE measured at the antenna connector.

RRC (RNC): indication of Tx power reaching threshold (for example, upper or lower powerlimits). For TDD this is measured in specified timeslots.

9.2.14 UE Rx-Tx time difference

Measurement UE Rx-Tx time differenceSource L1 (UE)Destination RRC (RNC)Reporting Trigger On-demand, periodic, event-triggeredDefinition Time difference between the UE uplink DPCCH/DPDCH frame transmission and the first

significant path of the downlink DPCH frame from the measured radio link. Measurementshall be made for each cell included in the active set. This measurement is applicable forFDD cells only. (Note: The use for TDD in case of LCS is ffs.)

9.2.15 SFN-SFN Observed time difference

The SFN-SFN observed time difference at the UE of a group of Node-B may be used for location calculation. Theapplicability of this measure is LCS method dependent. For TDD, this measure is mandatory for the UE.

Measurement SFN-SFN observed time differenceSource L1 (UE)Destination RRC (RNC)Reporting Trigger On-demand, Event-triggeredDefinition Time difference between a specific reference UTRA cell and a target UTRA cell. There

are two types of this measurement: Type 1 measures by means of the P-CCPCH and type2 by means of CPICH.

9.2.16 UE GPS Timing of Cell Frames for LCS

The UE GPS Timing of Cell Frames for LCS is an absolute reference time measurement for the arrival of a specificframe for an identified cell within the active set. This measure is applicable for UEs which support reception of GPSsignals for LCS.

Measurement UE GPS Timing of Cell Frames for LCS

Source L1 (UE)Destination RRC (RNC-LCS)Reporting Trigger On-demand, Event-triggered, PeriodicDefinition Time of arrival for the beginning of a frame, (identified by its SFN), measured when the

first significant multipath of the cell CPICH reaches the UE. This is the absolute timereference measurement in respect to GPS Time Of Week for the arrival of this frame.

ETSI


9.3 UTRAN Measurements

9.3.1 RSSI

Measurement RSSISource L1 (Node B)Destination RRC(RNC)Reporting Trigger On-demand, Event-triggered, PeriodicDefinition Received Signal Strength Indicator, the wide-band received power within the UTRAN UL

channel bandwidth at a UTRAN access point. For TDD this is measured in specifiedtimeslots.

9.3.2 Transmitted carrier power

Measurement Transmitted carrier powerSource L1(Node-B)Destination RRC (RNC)Reporting Trigger On-demand, periodic, Event-triggeredDefinition Transmitted carrier power is the ratio between the total transmitted power on one DL

carrier from one UTRAN access point, compared to the maximum power possible to useon that DL carrier at this moment of time. For TDD this is measured in specified timeslots.

9.3.3 Transmitted code power

Measurement Transmitted code powerSource L1(Node-B)Destination RRC (RNC)Reporting Trigger On-demand, periodic, Event-triggeredDefinition Transmitted Code Power is the transmitted power on one carrier, one scrambling and one

channelisation code. For TDD this is measured in specified timeslots.

9.3.4 Transport channel BLER

This measurement is not included in release 99.

Measurement Transport channel BLER (BLock Error Rate)Source L1(Node-B)Destination RRC (RNC)Reporting Trigger periodic, event triggered, on demandDefinition Estimation of the transport channel block error rate (BLER).

9.3.5 Physical channel BER

Measurement Physical channel BERSource L1(Node-B)Destination RRC (RNC)Reporting Trigger On-demand, Event-triggered, periodicDefinition The physical channel BER is measured on the control part after RL combining.

ETSI


9.3.6 Transport channel BER

Measurement Transport channel BERSource L1(Node-B)Destination RRC (RNC)Reporting Trigger On-demand, Event-triggered, periodicDefinition The transport channel BER is measured on the data part after RL combining.

9.3.7 RX timing deviation

Measurement RX timing deviationSource L1 (Node B)Destination RRC (RNC)Reporting Trigger Periodic, event triggeredDefinition The difference of the time of arrival of the UL transmissions in relation to the arrival time of

a signal with zero propagation delay. This measurement is applicable for TDD cells only.

9.3.8 Timeslot ISCP

Measurement Timeslot ISCPSource L1(Node B)Destination RRC (RNC)Reporting Trigger periodic or event triggeredDefinition Interference on Signal Code Power, is the interference on the received signal in a

specified timeslot measured on the midamble. This measurement is applicable for TDDcells only.

9.3.9 RSCP

Measurement RSCPSource L1(Node B)Destination RRC (RNC)Reporting Trigger periodic or event triggeredDefinition Received Signal Code Power is the received power on DPCH or PRACH or PUSCH after

despreading. This measurement is applicable for TDD cells only.

9.3.10 Round Trip Time

The Round Trip Time (RTT) measurement at a single Node-B may provide an estimate of the round trip time of signalsbetween the Node-B and the UE and this may be used to calculate a radial distance to the UE within the sector. A groupof simultaneous RTT measurements made from a number of Node-B or LMU may be used to estimate the location ofthe UE. The support for this measurement is LCS positioning method dependent.

Measurement Round Trip TimeSource L1(Node-B or LMU)Destination RRC (RNC-LCS)Reporting Trigger on demand, event triggeredDefinition The round trip time is measured from the time of transmission of the beginning of a

downlink frame to a UE to the time of reception of the beginning of the correspondinguplink frame from the UE.

ETSI


9.3.11 Frequency Offset

The Frequency Offset measures the rate of change (drift) of the Relative Time Difference and may be used to estimatethe RTD at the time the UE location measurements are made. The support for this measurement is LCS positioningmethod dependent.

Measurement Frequency OffsetSource L1( LMU)Destination RRC (RNC-LCS)Reporting Trigger On demand, event triggered, periodicDefinition The Frequency Offset (FO) measures the rate of change (drift) of the Relative Time

Difference of the transmissions of two Node-Bs.

9.3.12 Acknowledged PRACH preambles

Measurement Acknowledged PRACH preamblesSource L1(Node B)Destination RRC (RNC)Reporting Trigger Periodic, event triggered, On demandDefinition The acknowledged PRACH preambles measurement is defined as the total number of

acknowledged PRACH preambles per access frame for each PRACH, where an access frameconsists of fifteen access slots from access slot #0 to access slot #14. This is equivalent to thenumber of positive acquisition indicators transmitted per access frame on each AICH.

9.3.13 Detected PCPCH access preambles

Measurement Detected PCPCH Access preamblesSource L1(Node B)Destination RRC (RNC)Reporting Trigger Periodic, event triggered, On demandDefinition The detected PCPCH access preambles measurement is defined as the total number of

detected access preambles per access frame on the PCPCHs belonging to a CPCH set, wherean access frame consists of fifteen access slots from access slot #0 to access slot #14.

9.3.14 Acknowledged PCPCH access preambles

Measurement Acknowledged PCPCH access preamblesSource L1(Node B)Destination RRC (RNC)Reporting Trigger Periodic, event triggered, On demandDefinition The acknowledged PCPCH access preambles measurement is defined as the total number of

acknowledged PCPCH access preambles per access frame on the PCPCHs , where an accessframe consists of fifteen access slots from access slot #0 to access slot #14. This is equivalent tothe number of positive acquisition indicators transmitted on the AP-AICH per access frame.

9.3.15 SIR

Measurement SIRSource L1(Node B)Destination RRC (RNC)Reporting Trigger Periodic, event triggeredDefinition Signal to Interference Ratio is defined as (RSCP/ISCP) xSF. For FDD this is measured on

the DPCCH. For TDD this is measured on the DPCH.

ETSI


9.3.16 Propagation Delay

The Propagation delay measures the one-way propagation delay as measured during either PRACH or PCPCH access.The propagation delay measurement can be used for DPCH setup, as it allows to minimise the search window, whensetting up the uplink DPCH.

Measurement Propagation delaySource L1( Node B)Destination RRC (RNC)Reporting Trigger Event triggered, periodicDefinition The Propagation delay measures the one-way propagation delay as measured during

either PRACH or PCPCH access.

9.3.17 UTRAN GPS Timing of Cell Frames for LCS

The UTRAN GPS Timing of Cell Frames for LCS is an absolute reference time measurement for the arrival of aspecific frame for an identified cell within the active set. This measure is applicable for LMUs which support receptionof GPS signals for LCS.

Measurement UTRAN GPS Timing of Cell Frames for LCSSource L1 (LMU)Destination RRC (RNC-LCS)Reporting Trigger On-demand, Event-triggered, PeriodicDefinition Time of arrival for the beginning of a frame, (identified by its SFN), measured when the

first significant multipath of the cell CPICH reaches the LMU. This is the absolute timereference measurement in respect to GPS Time Of Week for the arrival of this frame.

9.3.18 SIR ERROR

Measurement SIR ERRORSource L1(Node B)Destination RRC (RNC)Reporting Trigger Periodic, event triggeredDefinition Signal to Interference Ratio Error is defined as SIR – SIRtarget_ave, where:

SIR = the SIR measured by UTRAN.

SIRtarget_ave = the SIRtarget averaged over the same time period as the SIR used in theSIR ERROR calculation.

10 Primitives of the physical layerThe Physical layer interacts with other entities as illustrated in figure 1. The interactions with the MAC layer and theRRC layer are shown in terms of primitives where the primitives represent the logical exchange of information andcontrol between the physical layer and higher layers. They do not specify or constrain implementations. The (adjacent)layers connect to each other through Service Access Points (SAPs). Primitives, therefore, are the conveyers of theinformation exchange and control through SAPs.

Three types of primitives are used for the present document, as follows.

- REQUEST:

- This type is used when a higher layer is requesting a service from a lower layer.

- INDICATION:

- This type is used by a lower layer providing a service to notify its higher layer of activities concerning thathigher layer.

ETSI


- CONFIRM:

- This type is used by a lower layer providing the requested service to confirm to the higher layer that theactivity has been completed.

The primitives defined below are for local communications between MAC and L1, as well as RRC and L1 in the sameprotocol stack.

For the physical layer two sets of primitives are defined:

- Primitives between layer 1 and 2:

- PHY - Generic name - Type: Parameters.

- Primitives between layer 1 and the RRC entity:

- CPHY - Generic name - Type: Parameters.

NOTE: This is a logical description of the primitives and does not cover addressing aspects (e.g. TransportChannel ID, Physical Channel ID, start frame number or disconnect frame number).

10.1 Generic names of primitives between layers 1 and 2The primitives between layer 1 and layer 2 are shown in table 8.

Table 8: Primitives between layer 1 and 2

Generic Name ParametersPHY-ACCESS-REQ transport format

subsetPHY-ACCESS-CNF Access InformationPHY-DATA-REQ TFI, TBSPHY-DATA-IND TFI, TBS, CRC

result, TD (NOTE)PHY-CPCH_STATUS-REQ transport format

subsetPHY-CPCH_STATUS-CNF transport format

subsetPHY-STATUS-IND Event value

NOTE: TDD only.

10.1.1 PHY-Access-REQ

The PHY-ACCESS-REQ primitive is used to request access to either a RACH or a CPCH transport channel from thephysical layer. A PHY-ACCESS primitive is submitted once before the actual data for peer-to-peer communication ispassed to the physical layer using the PHY-Data primitive.

Primitive Type: request.

Parameters:

- Transport Format subset.

10.1.2 PHY-Access-CNF

The PHY-ACCESS-CNF primitive is used to confirm that physical layer synchronisation has been established and thatthe physical layer is ready for data transmission using the PHY-Data primitive.

Primitive Type: confirm.

Parameters:

- access information.

ETSI


10.1.3 PHY-Data-REQ

The PHY-DATA primitives are used to request SDUs used for communications passed to and from the physical layer.One PHY-DATA primitive is submitted every Transmission Time Interval for each Transport Channel.


Parameters:

- TFI;

- Transport Block Set;

- FNCELL;

- Page indicators (PIs) (PCH only).

10.1.4 PHY- Data-IND

The PHY-DATA primitives are used to indicate SDUs used for Layer 2 passed to and from the physical layer. OnePHY-DATA primitive is submitted every Transmission Time Interval for each Transport Channel.

Primitive Type: indicate.

Parameters:

- TFI;

- Transport Block Set;

- CRC check result;

- TD (RX Timing Deviation measurement) (optional, TDD only).

10.1.5 PHY-CPCH_Status-REQ

The PHY-CPCH_STATUS-REQ primitive is used by MAC to request CPCH status information which is broadcast onCSICH. The parameter Transport Format subset allows to restrict the CPCH status information request to a limitednumber of CPCH channels of the given CPCH set.


Parameters:

- Transport Format subset.

10.1.6 PHY-CPCH_Status-CNF

The PHY-CPCH_STATUS-CNF primitive is used by L1 to indicate CPCH status information which is broadcast onCSICH. Status information is represented in terms of a Transport format subset which is permitted to be employed bythe UE.

Primitive Type: Confirm

Parameters:

- Transport Format subset

10.1.7 PHY-Status-IND

The PHY-Status-IND primitive can be used by the layer 1 to notify higher layers of an event that has occurred.

Primitive Type: indication

ETSI


Parameters:

- Event value:

- CPCH Emergency stop was completed;

- CPCH Start of Message Indicator was received;

- CPCH Start of Message Indicator was not received;

- L1 hardware failure has occurred.

- CPCH End of Transmission was received

10.2 Generic names of primitives between layers 1 and 3The status primitives between layer 1 and 3 are shown in table 9.

Table 9: Status primitives between layer 1 and 3

Generic Name ParametersCPHY-Sync-IND noneCPHY-Out-of-Sync-IND noneCPHY-Measurement-REQ Measurement

parametersCPHY-Measurement-IND Measurement

parametersCPHY-ERROR-IND Error CodeCPHY-CPCH-EOT-IND none

10.2.1 STATUS PRIMITIVES

10.2.1.1 CPHY-Sync-IND

This primitive is used for L1 to indicate to RRC that synchronisation of a certain physical channel has been done in thereceiver. In FDD synchronisation is based on reception of the DPCCH, and in TDD synchronisation is based onmidamble reception.

Primitive Type: indication.

Parameters:

- none.

10.2.1.2 CPHY-Out-of-Sync-IND

Primitive sent from L1 to RRC indicating that synchronisation of a previously configured connection has been lost inthe receiver. In FDD synchronisation is based on reception of the DPCCH, and in TDD synchronisation is based onmidamble reception.


Parameters:

- none.

10.2.1.3 CPHY-Measurement-REQ

The Request primitive is used for RRC to configure L1 measurements.


ETSI


Parameters:

- transmission power threshold;

- refer to clause 9 for measurement parameters.

10.2.1.4 CPHY-Measurement-IND

The Indication primitive is used to report the measurement results.


Parameters:

- refer to clause 9 for measurement parameters.

10.2.1.5 CPHY-ERROR-IND

The CPHY-ERROR primitive is used to indicate to the management entity that an error has occurred as a result of aphysical layer fault.


Parameters:

- error code.

10.2.1.6 CPHY-CPCH-EOT-IND

The CPHY-CPCH-EOT-IND primitive is used by L1 to indicate RRC of an end of CPCH transmission event hasoccurred.


Parameters:

- none.

ETSI


10.2.2 CONTROL PRIMITIVES

The control primitives between layer 1 and 3 are shown in table 10.

Table 10: Control primitives between layer 1 and 3

Generic Name ParametersCPHY-TrCH-Config-REQ Transport channel

description,CPHY-TrCH-Config-CNFCPHY-TrCH_Release-REQCPHY-TrCH_Release-CNFCPHY-RL-Setup-REQ Physical channel

descriptionCPHY-RL-Setup-CNF noneCPHY-RL-Release-REQ noneCPHY-RL-Release-CNF noneCPHY-RL-Modify-REQ Physical channel

descriptionCPHY-RL-Modify-CNF none

CPHY-Commit-REQ Activation Time

CPHY-CPCH-Estop-IND none

CPHY-CPCH-Estop-Resp none

CPHY-CPCH-Estop-REQ none

CPHY-CPCH-Estop-CNF none

CPHY-Out-of-Sync-Config-REQ

Out of syncdetectionparameters

CPHY-Out-of-Sync-Config-CNF

none

10.2.2.1 CPHY-TrCH-Config-REQ

This primitive is used for setting up and configuring a transport channel, and also to modify an existing transportchannel.


Parameters:

- transport channel description.

10.2.2.2 CPHY-TrCH-Config-CNF

This primitive is used for confirming the setting up and configuring a transport channel, and also modifying an existingtransport channel.


Parameters:

- none.

ETSI


10.2.2.3 CPHY-TrCH-Release-REQ

This primitive is used for releasing a transport channel.


Parameters:

- none.

10.2.2.4 CPHY-TrCH-Release-CNF

This primitive is used for confirming the releasing a transport channel.


Parameters:

- none.

10.2.2.5 CPHY-RL-Setup-REQ

The Request primitive is sent from RRC to L1 for establishment of a Radio link to a certain UE.


Parameters:

- physical channel description.

10.2.2.6 CPHY-RL-Setup-CNF

The Confirm primitive is returned from L1 to RRC when the Radio link is established. In case L1 is unable to executethe request, this is indicated in the confirm primitive.


Parameters:

- none.

10.2.2.7 CPHY-RL-Release-REQ

The Request primitive is sent from RRC to L1 for release of a Radio link to a certain UE.


Parameters:

- none.

10.2.2.8 CPHY-RL-Release-CNF

The Confirm primitive is returned from L1 to RRC when the radio link is released.


Parameters:

- none.

ETSI


10.2.2.9 CPHY-Modify-REQ

The Request primitive is sent from RRC to L1 for modification of a Radio link to a certain UE.


Parameters:

- physical channel description.

10.2.2.10 CPHY-RL-Modify-CNF

The Confirm primitive is returned from L1 to RRC when the radio link is modified. In case L1 is unable to execute therequest, this is indicated in the confirm primitive.


Parameters:

- none.

10.2.2.11 CPHY-Commit-REQ

This primitive is sent from RRC to L1 to synchronise UE and NW for the physical channel modification.


Parameters:

- activation time.

10.2.2.12 CPHY-CPCH-Estop-IND

The CPHY-CPCH-Estop-IND primitive is used by L1 to notify RRC of a CPCH emergency stop message has beenreceived.


Parameters:

- none.

10.2.2.13 CPHY-CPCH-Estop-Resp

This primitive is sent from UE RRC to L1 for emergency stop of the CPCH transmission. After receiving this primitive,UE L1 stopping its transmission on the related CPCH.

Primitive Type: response.

Parameters:

- none.

10.2.2.14 CPHY-CPCH-Estop-REQ

This primitive is sent from RRC to L1 for CPCH Emergency Stop. This primitive is sent for triggering of a CPCHemergency stop. After receiving this primitive, Node B L1 sends CPCH Estop Command to UE. This CPCH EstopCommand is all 1 bits pattern in the CCC field of DL DPCCH for CPCH.


Parameters:

- none.

ETSI


10.2.2.15 CPHY-CPCH-Estop-CNF

This primitive is sent from Node B L1 to RRC for confirming the emergency stop of the CPCH.


Parameters:

- none.

10.2.2.16 CPHY-Out-of-Sync-Config-REQ

This primitive is sent from RRC to Node B L1 to reconfigure the parameters to detect "in sync" and "out of sync"conditions of uplink physical channel transmission.


Parameters:

- Out of Sync detection parameters

10.2.2.17 CPHY-Out-of-Sync-Config-CNF

This primitive is sent from Node B L1 to RRC for confirming the Reconfiguration of the Out-of-Sync parameters onNode B L1.


Parameters:

- none.

10.3 Parameter definition

10.3.1 Error code

- Hardware failure.

10.3.2 Event value

- Maximum transmission power has been reached.

- Allowable transmission power has been reached.

- Average transmission power is below allowable transmission power.

- Loss of DL DPCCH.

- Completion of CPCH Emergency stop.

- CPCH Start of Message Indicator was received.

- CPCH Start of Message Indicator was not received.

- Maximum number of frames for CPCH transmission has been reached.

- End of Frame for CPCH transmission has been received.

10.3.3 Access Information

- Ready for RACH data transmission (in case of FDD mode: when Ack on AICH has been received).

ETSI


The following values of this parameter apply to FDD only:

- NACK on AICH or AP-AICH has been received;

- timeout, no response on AICH or AP-AICH has been received while maximum number of access preambletransmissions has been performed;

- ready for CPCH data transmission (CD or CD/CA information received on CD/CA-ICH);

- mismatch of CD/CA-ICH signatures;

- no response on CD/CA-ICH received;

- timeout, no CD/CA-ICH received.

10.3.4 Transport Format Subset

- A subset of the Transport Format set of a Transport Channel.

10.3.5 Physical channel description

10.3.5.1 Primary SCH

- Tx diversity mode.

10.3.5.2 Secondary SCH


10.3.5.3 Primary CCPCH

- Frequency info.

- DL scrambling code.


- Timeslot (TDD only).

- Burst type (TDD only).

- Offset (TDD only).

- Repetition period (TDD only).

- Repetition length (TDD only).

10.3.5.4 Secondary CCPCH

- DL scrambling code.

- Channelisation code.



- Burst type (TDD only).

- Midamble shift (TDD only).



ETSI



- TFCI presence (TDD only).

10.3.5.5 PRACH

NOTE: The PRACH can also be used to map the FAUSCH Transport Channel.

- Access Slot.

- Preamble spreading code (FDD only).

- Preamble signature (FDD only).

- Spreading factor for data part.

- Power control info:

- UL target SIR;

- primary CCPCH DL TX Power;

- UL interference;

- power offset (Power ramping) (FDD only).

- Access Service Class Selection:

- preamble signature classification information.

- AICH transmission timing parameter (FDD only).

- Timeslots (TDD only).

- Spreading codes (TDD only).

- Midamble codes (TDD only).

10.3.5.6 Uplink DPDCH+DPCCH

- UL scrambling code.

- DPCCH Gate rate.

- DPCCH slot structure (Npilot, NTPC, NTFCI, NFBI).

- Transmission Time offset value.

10.3.5.7 Uplink DPCH

- Timing Advance (TDD only).

- DPCH channelisation code (TDD only).

- Burst Type (TDD only).

- DPCH midamble shift (TDD only).



- Repetition Period (TDD only).



ETSI


10.3.5.8 Downlink DPCH

- Transmission Time offset value.

- DPCCH Gate rate (FDD only).

- DL scrambling code:

- DL Channelisation code.

- Tx diversity mode:

- FB mode (FDD only).

- Slot structure (Npilot, NTPC, NTFCI, NFBI, , Ndata1, Ndata2) (FDD only).

- Special slot structure only for CPCH (Npilot, NTPC, NTFCI, NCCC) (FDD only)


- DPCH midamble shift (TDD only).






10.3.5.9 PCPCH (Physical Common Packet Channel)

- CPCH Set ID to which this PCPCH belongs.

- Parameters related to the AP preamble:

- Access Preamble (AP) scrambling code;

- available AP signatures/subchannels for access request;

- Parameters related to the CD preamble:

- CD preamble scrambling code;

- available CD signatures/subchannels;

- Parameters related to PCPCH message part:

- PCPCH scrambling code;

- PCPCH Channelisation code;

- data rate (spreading factor);

- N_frames_max: Maximum length of CPCH message in radio frames.

10.3.5.10 PICH

- Scrambling code.




ETSI


- Midamble shift (TDD only).




10.3.5.11 AICH

- Scrambling code.



NOTE: The value for the parameters needs to be consistent with the corresponding PRACH.

10.3.5.12 AP-AICH

- CPCH Set ID.

- Scrambling code.



10.3.5.13 CD-ICH

- CPCH Set ID.

- Scrambling code.



NOTE: This physical channel is used in conjunction with PCPCH when UE Channel Selection is active.

10.3.5.14 CD/CA-ICH

- CPCH Set ID.

- Scrambling code.



NOTE: This physical channel is used in conjunction with PCPCH when Channel Assignment is active.

10.3.5.15 CSICH

- CPCH Set ID.

- Scrambling code.



NOTE: The values for the parameters need to be consistent with the AP-AICH which is time-multiplexed withthis CSICH.

ETSI


10.3.5.16 PDSCH

- Scrambling code.


- Tx diversity mode:

- FB mode (FDD only).

- DL channelisation code (TDD only).


- PDSCH Midamble shift (TDD only).






10.3.5.17 PUSCH

- PUSCH channelisation code.


- PUSCH midamble shift (TDD only).






- Timing Advance (TDD only).

11 Transport block transmissionData exchange between MAC and the physical layer, is defined in terms of Transport Block Sets (TBS). On a TransportChannel, one Transport Block Set can be transmitted for every Transmission Time Interval. A TBS consists of one orseveral Transport Blocks which shall be numbered 1,…, m,… ,M and is delivered in the order of the index m. ATransport Block is identical with a MAC PDU. A Transport Block (MAC PDU) is a bit string ordered from first to last,where the first and last bits are numbered 1 and A, respectively, where A is the number of bits of the Transport Block. Incase of Transport Block size=0 bit, only parity bits are sent and A=0.

The bits of the mth Transport Block in a TBS, are denoted as aim1, …, aimA for a Transport Channel identified by anindex i (cf. TS 25.212 and TS 25.222).

ETSI


Annex A (normative):Description of Transport FormatsThe following table describes the characterisation of a Transport Format.

Table A.1: Characterisation of Transport Format

Attribute values BCH PCH FACH RACHDynamicpart

TransportBlock Size

0 to 5 0001 bit granularity

246 1 to 50001 bitgranularity


0 to 5 0001 bitgranularity

TransportBlock Set Size


246 1 to 200 0001 bitgranularity



TransmissionTime Interval(option forTDD only)

10, 20 ms, 40 and80 ms

Semi-staticpart

TransmissionTime Interval(FDD, optionfor TDD NRTbearers)

10, 20 ms, 40 and80 ms

20 ms 10ms for FDD,20ms for TDD

10, 20 ms, 40 and80 ms

10 ms and20 ms forFDD,10 ms forTDD

Type ofchannel coding

No CodingTurbo codingConvolutionalcoding

Convolutional coding

Convolutionalcoding

No codingTurbo codingConvolutionalcoding

Convolutional coding

code rates 1/2, 1/3 1/2 1/2 1/2, 1/3 1/2

CRC size 0, 8, 12, 16, 24 16 0, 8, 12, 16, 24 0, 8, 12, 16, 24 0, 8, 12, 16,24

Resulting ratioafter static ratematching

0,5 to 4

ETSI


Attribute values CPCH DCH DSCH USCH

Dynamicpart

TransportBlock Size






TransportBlock Set Size






TransmissionTime Interval(option forTDD only)

10, 20 ms, 40 and80 ms

10, 20 ms, 40and 80 ms

10, 20 ms, 40 and80 ms

10, 20 ms,40 and 80ms

Semi-staticpart

TransmissionTime Interval(FDD, optionfor TDD NRTbearers)

10, 20 ms, 40 and80 ms

10, 20 ms, 40and 80 ms

10, 20 ms, 40 and80 ms

10, 20 ms,40 and 80ms

Type ofchannel coding


No codingTurbo codingConvolutional coding



No codingTurbo codingConvolutional coding

code rates (incase ofconvolutionalcoding)

1/2, 1/3 1/2, 1/3 1/2, 1/3 1/2, 1/3 1/2, 1/3

CRC size 0, 8, 12, 16, 24 0, 8, 12, 16, 24 0, 8, 12, 16, 24 0, 8, 12, 16,24

Resulting ratioafter static ratematching

0,5 to 4

NOTE 1: The maximum size of the Transport Block has been chosen so as to avoid any need for segmentation inthe physical layer into sub-blocks (segmentation should be avoided in the physical layer).

NOTE 2: Code rate is fixed to 1/3 in case of Turbo coding.

NOTE 3: All channels using the same resources as the BCH (i.e. the same timeslot and code, e.g. in a multiframepattern) have to use different Transport Formats than the BCH to allow the identification of the BCHchannel by physical layer parameters. Due to the differing parameters, decoding of other transportchannels than BCH will result in an erroneous CRC.

ETSI


Annex B (informative):Example of Transport format attributes for AMR speechcodecThe support for the AMR speech codec is exemplified below. On the radio interface, one Transport Channel isestablished per class of bits i.e. DCH A for class A, DCH B for class B and DCH C for class C. Each DCH has adifferent transport format combination set which corresponds to the necessary protection for the corresponding class ofbits as well as the size of these class of bits for the various AMR codec modes.

With this principle, the AMR codec mode which is used during a given TTI can be deduced from the format of thetransport channels DCH A, DCH B and DCH C for that particular TTI.

Note that a similar principle can also be applied for other source codecs e.g. other speech codecs or video codecs.

An example of transport channel description for each class of bits is given in table B.1.

Table B.1

ValueAttributeClass A Class B Class C

Dynamic part Transport Block Size 816575615855494239

103998487766354530

60400000000

Transport Block Set Size Same as the transport block sizesSemi-static part Transmission Time Interval 20 ms

Type of channel coding Convolutional codingcode rates 1/2, 1/3

+ class-specific

ratematching

None,1/2, 1/3+ class-specific

ratematching

None, 1/2 ,1/3

+ class-specific rate

matching

CRC size 8 0 0Resulting ratio after static ratematching

0.5 to 4(with no coding the ratematching ratio needs to be >1)

ETSI


Annex C (informative):Change history

Change historyTSG-RAN# Version CR Tdoc RAN New Version Subject/CommentRAN_04 - - RP-99309 3.0.0 (08/99)

Approved after TSG-RAN #4 and TSG-RAN WG2 #6 (08/99) bycorrespondence and placed under Change Control

RAN_05 3.0.0 001 RP-99461 3.1.0 (10/99)Making all transport block equally sized within a transport block set

RAN_05 3.0.0 002 RP-99461 3.1.0 UE Simultaneous Physical Channel Combinations in TDD ModeRAN_05 003 RP-99461 New CPCH parameters for physical layer primitives

postponedRAN_05 3.0.0 004 RP-99461 3.1.0 Timing advance (TDD only)RAN_05 3.0.0 005 RP-99461 3.1.0 Measurements for TDD provided by physical layerRAN_05 3.0.0 006 RP-99461 3.1.0 Change of the Downlink model of the UE in relation to PCHRAN_05 3.0.0 007 RP-99461 3.1.0 Physical channel description for TDDRAN_05 3.0.0 008 RP-99461 3.1.0 Attributes of the semi-static part and coding terminologyRAN_05 3.0.0 009 RP-99461 3.1.0 Editorial changes following LS received from WG1RAN_05 3.0.0 010 RP-99461 3.1.0 Support of Uplink Synchronization Feature in UL channels (TDD

only)RAN_05 3.0.0 011 RP-99461 3.1.0 Simultaneous reception of AICH and S-CCPCHRAN_05 3.0.0 012 RP-99461 3.1.0 Removal of Measurement Precision RequirementsRAN_05 3.0.0 013 RP-99461 3.1.0 Compressed modeRAN_05 3.0.0 014 RP-99461 3.1.0 Change of the model of the UE with respect to shared channel

multiplexingRAN_06 3.1.0 015 RP-99624 3.2.0 (12/99)

Alignment of measurement names with RANRAN_06 3.1.0 018 RP-99623 3.2.0 Compressed Mode descriptionRAN_06 3.1.0 022 RP-99624 3.2.0 Alignment with TDD layer 1RAN_06 3.1.0 023 RP-99624 3.2.0 Physical Channel ParametersRAN_06 3.1.0 025 RP-99624 3.2.0 Addition of PICH and Corrections for PrimaryRAN_06 3.1.0 026 RP-99624 3.2.0 Removal of compressed mode inband signallingRAN_06 3.1.0 028 RP-99624 3.2.0 Measurement of Transmitted carrier powerRAN_06 3.1.0 030 RP-99623 3.2.0 Editorial issuesRAN_06 3.1.0 031 RP-99624 3.2.0 Measurement of Physical Channel BER- 3.2.0 - - 3.3.0 (01/00)

E-mail approval by TSG-RAN WG2 of different implementation ofCR 015 and CR 028 according to authors' intentions

RAN_07 3.3.0 032 RP-000035 3.4.0 (03/00)Revision of CPCH model

RAN_07 3.3.0 033 RP-000035 3.4.0 Error Correction Coding for FACHRAN_07 3.3.0 034 RP-000035 3.4.0 Revision of compressed mode descriptionRAN_07 3.3.0 036 RP-000035 3.4.0 TrBLK sizeRAN_07 3.3.0 037 RP-000035 3.4.0 PDSCH multi-codeRAN_07 3.3.0 038 RP-000035 3.4.0 Primitives for CPCH Abnormal Situation HandlingRAN_07 3.3.0 039 RP-000035 3.4.0 Physical channel BERRAN_07 3.3.0 041 RP-000035 3.4.0 Editorial modification on AMR trblk sizeRAN_07 3.3.0 042 RP-000035 3.4.0 Corrections and clarifications on L1 and L2 functionality descriptionsRAN_07 3.3.0 043 RP-000035 3.4.0 Transport Block TransmissionRAN_07 3.3.0 044 RP-000035 3.4.0 Clarification to layer 1 model regarding transport blocks received by

UE with CRC failureRAN_07 3.3.0 045 RP-000035 3.4.0 Removal of SCH and SCCHRAN_07 3.3.0 046 RP-000035 3.4.0 Replacement of Time of Arrival Measurement by RTTRAN_07 3.3.0 047 RP-000035 3.4.0 Incorporation of Measurement filtering modelRAN_07 3.3.0 048 RP-000035 3.4.0 Separation of physical channel BER measurementsRAN_08 3.4.0 049 RP-000215 3.5.0 (06/00)

Maximum number of simultaneous compressed mode patternsequences per measurement purpose

RAN_08 3.4.0 050 RP-000215 3.5.0 Removal of CPICH SIR measurement quantityRAN_08 3.4.0 051 RP-000215 3.5.0 MeasurementsRAN_08 3.4.0 052 RP-000215 3.5.0 End of CPCH transmissionRAN_08 3.4.0 053 RP-000215 3.5.0 Measurements of RACH and CPCHRAN_08 3.4.0 056 RP-000215 3.5.0 Editorial modification on Transport Block SizeRAN_08 3.4.0 057 RP-000215 3.5.0 CPCH correctionRAN_08 3.4.0 058 RP-000215 3.5.0 SFN Transmission Rate and the Need to Maintain CFN in TDD ModeRAN_08 3.4.0 059 RP-000215 3.5.0 Addition of out-of-sync-configuration control primitivesRAN_08 3.4.0 060 RP-000215 3.5.0 Addition of propagation delay measurement

ETSI


Change historyRAN_08 3.4.0 061 RP-000215 3.5.0 Layer 1 LCS measurementsRAN_08 3.4.0 062 RP-000215 3.5.0 Refinement of the definition of a Transport BlockRAN_08 3.4.0 063 RP-000215 3.5.0 Corrections of CPCH Emergency stop and start of message IndicatorRAN_08 3.4.0 064 RP-000215 3.5.0 BLERRAN_09 3.5.0 065 RP-000353 3.6.0 (09/00)

Filtering period in case of periodical reportingRAN_09 3.5.0 066 RP-000353 3.6.0 UE simultaneous Physical and Transport channel combinations for

PDSCH and DSCHRAN_09 3.5.0 067 RP-000353 3.6.0 Inclusion of SIR ERROR measurementRAN_09 3.5.0 068 RP-000353 3.6.0 Simultaneous reception of PCCPCH and SCCPCHRAN_09 3.5.0 070 RP-000353 3.6.0 Removal of puncturing limit from the transport format definitionRAN_09 3.5.0 071 RP-000353 3.6.0 Clarification of the Timeslot ISCP Measurements

59

ETSI


History

Document history

V3.3.0 January 2000 Publication

V3.4.0 March 2000 Publication

V3.5.0 June 2000 Publication

V3.6.0 September 2000 Publication

TS 125 302 - V3.6.0 - Universal Mobile Telecommunications ... · 2 ETSI 3GPP TS 25.302 version...

Documents

Transcript of TS 125 302 - V3.6.0 - Universal Mobile Telecommunications ... · 2 ETSI 3GPP TS 25.302 version...