Digital cellular telecommunications system (Phase 2+); Flexible Layer One (FLO) (3GPP TR 45.902 version 13.0.0 Release 13)

RTR/TSGG-0145902vd00

General Information

Status
Published
Publication Date
21-Jan-2016
Technical Committee
Current Stage
12 - Completion
Due Date
19-Jan-2016
Completion Date
22-Jan-2016
Ref Project
Standard
Digital cellular telecommunications system (Phase 2+); Flexible Layer One (FLO) (3GPP TR 45.902 version 13.0.0 Release 13) - 3GPP GERAN
English language
2 pages
sale 15% off
Preview
sale 15% off
Preview

Standards Content (Sample)


ETSI TR 1145 902 V13.0.0 (201616-01)

TECHNICAL REPORT
Digital cellular telecocommunications system (Phahase 2+);
Flexibxible Layer One (FLO)
(3GPP TR 45.9.902 version 13.0.0 Release 13 13)

R
GLOBAL SYSTTEME FOR
MOBILE COMMUUNNICATIONS
3GPP TR 45.902 version 13.0.0 Release 13 1 ETSI TR 145 902 V13.0.0 (2016-01)

Reference
RTR/TSGG-0145902vd00
Keywords
GSM
ETSI
650 Route des Lucioles
F-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 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the
print of the Portable Document Format (PDF) version kept on a specific network drive within 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://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2016.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
TM
3GPP and LTE™ are Trade Marks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3GPP TR 45.902 version 13.0.0 Release 13 2 ETSI TR 145 902 V13.0.0 (2016-01)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Technical Report (TR) has been produced by ETSI 3rd Generation Partnership Project (3GPP).
The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identities or
GSM 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
http://webapp.etsi.org/key/queryform.asp.
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
ETSI
3GPP TR 45.902 version 13.0.0 Release 13 3 ETSI TR 145 902 V13.0.0 (2016-01)
Contents
Intellectual Property Rights . 2
Foreword . 2
Modal verbs terminology . 2
Foreword . 5
Introduction . 5
1 Scope . 6
2 References . 6
3 Definitions, symbols and abbreviations . 6
3.1 Definitions . 6
3.2 Abbreviations . 7
4 Motivation . 8
5 Requirements . 8
6 Overview of FLO . 9
6.1 General . 9
6.2 Principles of FLO . 9
6.3 Evolution from Release 5 . 9
6.4 Limitations . 10
6.5 Protocol architecture. 10
6.5.1 Iu mode . 10
6.5.2 A/Gb mode. 11
6.5.3 TBF configuration principles . 11
7 Layer 1 for FLO . 11
7.1 CRC Attachment . 12
7.2 Channel Coding . 13
7.3 Rate Matching . 13
7.4 Transport Channel Multiplexing . 16
7.4a Inband signalling bits . 16
7.5 Transport Format Combination Identifier (TFCI) . 16
7.6 Interleaving. 17
7.7 Signalling on HR Channels . 18
8 Layer 2 for FLO . 19
8.1 Protocol architecture in Iu mode . 19
8.1.1 General . 19
8.1.2 RLC protocol . 20
8.1.3 MAC protocol . 20
8.2 Protocol architecture in A/Gb mode . 20
8.3 RLC/MAC block structure . 20
8.3.1 General . 20
8.3.2 RLC/MAC blocks for control message transfer. 21
8.3.2.1 Downlink RLC/MAC control block format . 21
8.3.2.2 Uplink RLC/MAC control block format . 21
8.3.3 RLC/MAC blocks for data transfer . 21
8.3.3.1 Downlink RLC/MAC block for data transfer . 21
8.3.3.1.1 RLC unacknowledged mode . 21
8.3.3.1.2 RLC acknowledged mode . 22
8.3.3.1.3 RLC transparent mode . 22
8.3.3.2 Uplink RLC/MAC block for data transfer . 22
8.3.3.2.1 RLC unacknowledged mode . 22
8.3.3.2.2 RLC acknowledged mode . 22
8.3.3.2.3 RLC transparent mode . 23
ETSI
3GPP TR 45.902 version 13.0.0 Release 13 4 ETSI TR 145 902 V13.0.0 (2016-01)
8.4 Ciphering in Iu mode . 23
8.4.1 General . 23
8.4.2 Parameters settings . 23
8.4.2.1 RLC non-transparent mode . 23
8.4.2.2 RLC transparent mode . 23
8.4.2.3 RLC/MAC control messages . 24
8.5 TFC Selection . 24
8.5.1 TFC selection in the uplink . 24
8.5.2 TFC selection in the downlink . 24
8.6 Ciphering in A/Gb mode . 24
9 Layer 3 for FLO . 25
9.1 In Iu mode. 25
9.2 In A/Gb mode . 25
9.3 Transport and physical channel configuration . 25
9.4 Calculated Transport Format Combination . 26
9.4.1 Definition . 26
9.4.2 Example . 27
9.5 TFC for Signalling. 28
9.6 TBF configuration . 28
10 Testing of FLO . 28
11 Impact on Specifications . 29
Annex A (informative): Block Codes for the TFCI . 30
Annex B (informative): Header fields . 32
B.1 Payload Type (PT) field . 32
B.2 Polling (P) bit . 32
B.3 Segmentation (S) bit . 32
B.4 Reduced Block Sequence Number (RBSN) bit . 32
B.5 Radio Transaction Identifier (RTI) field . 32
B.6 Temporary Flow Identity (TFI) field . 33
B.7 Block Sequence Number (BSN) field . 33
B.7.1 General . 33
B.7.2 RLC unacknowledged mode . 33
B.7.3 RLC acknowledged mode . 33
B.8 Split Block Indicator (SPB) field . 33
B.9 Stall Indicator (SI) field . 33
B.10 Extension (E) bit . 33
B.11 Length Indicator (LI) field. 34
Annex C: Change history . 35
History . 36

ETSI
3GPP TR 45.902 version 13.0.0 Release 13 5 ETSI TR 145 902 V13.0.0 (2016-01)
Foreword
rd
This Technical Report has been produced by the 3 Generation Partnership Project (3GPP).
The contents of the present document are subject to continuing work within the TSG and may change following formal
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an
identifying 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.
Introduction
A new type of physical layer is proposed for the GSM/EDGE Radio Access Network (GERAN): the flexible layer one
(FLO). The main advantage of FLO is that the configuration of the physical layer (e.g. channel coding and interleaving)
is specified at call setup. This means that the support of new services such as IP Multimedia Subsystem (IMS) services
can be handled smoothly without having to specify new coding schemes in each release.
Through several enhancements such as reduced granularity and flexible interleaving, the radio bearers offered by FLO
would not only fulfil the IMS requirements in terms of flexibility and performance, but also greatly improve the link
level performance of real-time IMS services compared to GERAN Release 5.
The objective of this TR is to provide an overview of FLO, its architecture and study the impacts it has on the GERAN
radio protocol stack.
ETSI
3GPP TR 45.902 version 13.0.0 Release 13 6 ETSI TR 145 902 V13.0.0 (2016-01)
1 Scope
The present document provides an overview of the flexible layer one, its architecture and studies the impacts it has on
the GERAN radio protocol stack.
2 References
The following documents contain provisions, which, through reference in this text, constitute provisions of the present
document.
• References are either specific (identified by date of publication, edition number, version number, etc.) or
non-specific.
• For a specific reference, subsequent revisions do not apply.
• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same
Release as the present document.
[1] 3GPP TR 21.905: 'Vocabulary for 3GPP Specifications'.
[2] 3GPP TS 22.101, 'Service Principles'.
[3] 3GPP TS 22.228, 'Service requirements for the IP Multimedia Core Network Subsystem'.
[4] 3GPP TS 23.107, 'QoS Concept and Architecture'.
[5] 3GPP TS 23.228, 'IP Multimedia Subsystem'.
[6] 3GPP TS 25.201, 'Physical layer - General description'.
[7] 3GPP TS 25.212, 'Multiplexing and channel coding (FDD)'.
[8] 3GPP TS 25.331, 'RRC Protocol Specification'.
[9] 3GPP TS 32.201, 'Specification of the 3GPP Confidentiality and Integrity Algorithms'.
[10] 3GPP TS 44.018: 'Radio Resource Control protocol'.
[11] 3GPP TS 44.118: 'Radio Resource Control protocol, Iu mode'.
[12] 3GPP TS 44.060: 'Radio Link Control/Medium Access Control protocol'.
[13] 3GPP TS 44.160: 'Radio Link Control/Medium Access Control protocol, Iu mode'.
[14] 3GPP TS 45.002: 'Multiplexing and multiple access on the radio path'.
[15] 3GPP TS 45.003: 'Channel Coding'.
[16] 3GPP TS 45.005: 'Radio transmission and reception'.
3 Definitions, symbols and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply.
Active Transport Channel: a transport channel is active during a TTI if it carries a transport block.
ETSI
3GPP TR 45.902 version 13.0.0 Release 13 7 ETSI TR 145 902 V13.0.0 (2016-01)
Dynamic attributes: for one transport channel, the values of the dynamic attributes are different among transport
formats. They are configured by Layer 3 and can change on a TTI basis under the control of the MAC sublayer.
Empty Transport Format: a transport format such that no transport block is carried over the transport channel (i.e. the
transport channel is inactive).
Empty Transport Format Combination: a transport format combination that is made up only of empty transport
formats.
Inactive Transport Channel: a transport channel is inactive during a TTI if it does not carry a transport block (i.e. the
transport block size is zero).
Radio Frame: The result of applying rate matching to a transport block along with its associated CRC that have first
been channel encoded.
Radio Packet: The set of one or more radio frames together with the applicable coded TFCI that form the volume of
payload that can be transmitted on a basic physical subchannel for any given TTI.
Semi-static attributes: for one transport channel, the values of the semi-static attributes are common to all transport
formats. They are configured by Layer 3 and can only be changed by Layer 3 signalling.
Transport Block: block exchanged on a transport channel between the physical layer and the MAC sublayer.
Transport Channel: SAP between the physical layer and the MAC sublayer.
Transport Format: configuration of a transport channel, including for instance channel coding, CRC size, etc.
Transport Format Combination: allowed combination of transport format(s) of the different transport channels that
are multiplexed together on a basic physical subchannel.
Transport Format Combination Indicator: layer one header that indicates the transport format combination that has
been selected for each radio packet.
Transport Format Combination Set: set of allowed transport format combinations on a basic physical subchannel.
Transport Format Indicator: index identifying a particular transport format within the transport format set.
Transport Format Set: set of all transport formats defined for a particular transport channel.
Transmission Time Interval: rate at which transport blocks are exchanged between the physical layer and the MAC
sublayer on a transport channel.
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ADCH Associated Dedicated CHannel
CCTrCH Coded Composite Transport CHannel
CDCH Control-plane Dedicated CHannel
CTFC Calculated Transport Format Combinations
DCH Dedicated CHannel
FLO Flexible Layer One
GERAN GSM/EDGE Radio Access Network
IMS IP Multimedia Subsystem
MAC Medium Access Control
QoS Quality of Service
PDU Protocol Data Unit
RAN Radio Access Network
RLC Radio Link Control
RRC Radio Resource Control
RT Real Time
SDU Service Data Unit
SAP Service Access Point
TB Transport Block
ETSI
3GPP TR 45.902 version 13.0.0 Release 13 8 ETSI TR 145 902 V13.0.0 (2016-01)
TBF Temporary Block Flow
TF Transport Format
TFI Temporary block Flow Identity
TFS Transport Format Set
TFIN Transport Format INdicator
TFC Transport Format Combination
TFCI Transport Format Combination Indicator
TFCS Transport Format Combination Set
TrCH Transport Channel
TTI Transmission Time Interval
UDCH User-plane Dedicated CHannel
UTRAN Universal Terrestrial Radio Access Network

Other abbreviations used in the present document are listed in 3GPP TR 21.905.
4 Motivation
The need for a flexible layer one for the Release 6 of GERAN is driven by the introduction of IMS services. For an
efficient support of IMS services, requirements are set on the radio bearer service of the RAN (see 3GPP TS 22.101,
3GPP TS 22.228, 3GPP TS 23.228 and 3GPP TS 23.107):
- the radio bearers should be flexible enough to efficiently deploy any IP multimedia applications;
- the radio bearers should allow the transport of several flows in parallel (e.g. text and video);
- the radio bearers should satisfy the user in a spectral efficient manner;
- the radio bearer should support the UMTS QoS concept and architecture.
So as to fulfil these requirements in an efficient manner, a flexible layer one is needed. Thanks to the flexible layer one
optimised support of real time IMS services is made possible in GERAN.
5 Requirements
The flexible layer one should:
- fulfil most of the IMS requirements in terms of radio bearer service attributes;
- support the multiplexing of parallel flows on to a basic physical subchannel;
- provide an optimisation of spectral efficiency through the support of different interleaving depths, unequal error
protection/detection, reduced channel coding rate granularity and support of 8PSK and GMSK modulations;
- provide an efficient support of real time IMS services;
- be applicable to both modes of operation: A/Gb mode and Iu mode;
- minimize the impacts on the radio protocols;
- minimize the overhead introduced by the radio protocol stack;
- not introduce an unfeasible number of test configurations;
- be future proof;
- within reason, be compatible with legacy transceiver implementations.
ETSI
3GPP TR 45.902 version 13.0.0 Release 13 9 ETSI TR 145 902 V13.0.0 (2016-01)
6 Overview of FLO
6.1 General
In GERAN Release 5, the MAC sublayer is responsible for the mapping between the logical channels (traffic or control
channels) and the basic physical channels (see 3GPP TS 45.002). The logical channels are the channels the physical
layer offers to the MAC sublayer. Until now these logical channels and the mapping to the basic physical channel have
been fully specified in 3GPP TS 45.002.
A different approach has been taken in UTRAN, where instead of providing logical channels the physical layer offers
Transport Channels (TrCH), which can be used by the MAC sublayer (see 3GPP TS 25.201). A transport channel is
used to transmit one data flow with a given QoS over the radio interface. A number of transport channels can be active
at the same time and multiplexed at the physical layer. The transport channels are configured at call setup by the
network.
With FLO, the concept of transport channels used in UTRAN can be reused in GERAN i.e. the physical layer offers one
or several transport channels to the MAC sublayer.
6.2 Principles of FLO
With FLO, the physical layer of GERAN offers one or several transport channels to the MAC sublayer. Each of these
transport channels can carry one data flow providing a certain Quality of Service (QoS). A number of transport channels
can be multiplexed and sent on the same basic physical subchannel at the same time.
The configuration of a transport channel i.e. the number of input bits, channel coding, interleaving etc. is denoted the
Transport Format (TF). As in UTRAN, a number of different transport formats can be associated to one transport
channel. The configuration of the transport formats is completely controlled by the RAN and signalled to the MS at call
setup. In both the MS and the BTS, the transport formats are used to configure the encoder and decoder units. When
configuring a transport format, the RAN can choose between a number of predefined CRC lengths and block lengths.
On transport channels, transport blocks (TB) are exchanged between the MAC sublayer and the physical layer on a
transmission time interval (TTI) basis. For each TTI a transport format is chosen and indicated through the transport
format indicator (TFIN). In other words, the TFIN tells which transport format to use for that particular transport block
on that particular TrCH during that particular TTI. When a transport channel is inactive, the transport format with a
transport block size of zero (empty transport format) is selected.
Only a limited number of combinations of the transport formats of the different TrCHs are allowed. A valid
combination is called a Transport Format Combination (TFC). The set of valid TFCs on a basic physical subchannel is
called the Transport Format Combination Set (TFCS). The TFCS is signalled through the Calculated Transport Format
Combinations (CTFC).
In order to decode the received sequence the receiver needs to know the active TFC for a radio packet. This information
is transmitted in the Transport Format Combination Indicator (TFCI) field. This field is basically a layer 1 header and
has the same function as the stealing bits in GSM. Each of the TFC within a TFCS are assigned a unique TFCI value
and when a radio packet is received this is the first to be decoded by the receiver. From the decoded TFCI value the
transport formats for the different transport channels are known and the actual decoding can start.
In case of multislot operation, there shall be one FLO instance for each basic physical subchannel. Each FLO instance is
configured independently by Layer 3 and as a result gets its own TFCS. The number of allocated basic physical
subchannels depends on the multislot capabilities of the MS.
6.3 Evolution from Release 5
In GERAN Release 5, logical channels are offered by the physical layer to the MAC sublayer. With FLO, transport
channels are offered by the physical layer to the MAC sublayer.
In GERAN Release 5, speech frames, RLC/MAC blocks, data frames and blocks of info bits are exchanged on logical
channels between the physical layer and the MAC sublayer. With FLO, transport blocks are exchanged on transport
channels between the physical layer and the MAC sublayer.
ETSI
3GPP TR 45.902 version 13.0.0 Release 13 10 ETSI TR 145 902 V13.0.0 (2016-01)
In GERAN Release 5, a fixed set of coding schemes are standardized for each logical channel in 3GPP TS 45.003. With
FLO, transport formats are configured at call setup for each transport channel.
In GERAN Release 5, only one logical channel can be sent per radio block. With FLO, the transport format
combinations allow a number of transport channels to be multiplexed within the same radio block.
In GERAN Release 5, the coding scheme and/or the content of the radio block is indicated by the stealing bits. With
FLO, the TFC and thereby the active transport formats of the TrCHs is indicated by the TFCI.
6.4 Limitations
The following assumptions are made in order to limit the complexity of FLO:
- FLO shall be used on dedicated channels only, maintaining the 26-multiframe structure for which the SACCH
shall be treated as a separate logical channel based on Release 5 format;
- All TrCHs shall use the same TTI: the same length as in GSM/GPRS of Release 5, i.e. 20ms;
- FLO shall provide at most 8 transport channels per basic physical subchannel;
- FLO shall support a maximum of 4 active transport channels per radio packet per basic physical subchannel;
- The size of the TFCI shall be limited to 5 bits, allowing a maximum of 32 different TFCs per basic physical
subchannel;
- A maximum of 32 different TFs is allowed per TrCH;
- One RLC PDU cannot be mapped across multiple basic physical subchannels.
6.5 Protocol architecture
6.5.1 Iu mode
Figure 1 below illustrates the protocol architecture in conjunction with FLO in Iu mode:

ETSI
3GPP TR 45.902 version 13.0.0 Release 13 11 ETSI TR 145 902 V13.0.0 (2016-01)
Control-plane User-plane
PDCP PDCP
RRC PDCP
RLC
RLC RLC RLC RLC
RLC
RLC
TBFs
MAC
Transport Channels
FLO
FLO
FLO
PHY
Figure 1: Protocol Architecture for FLO in Iu mode
The physical layer offers transport channels to the MAC sublayer. MAC is responsible for mapping temporary block
flows (see 3GPP TS 44.160) on appropriate transport channels.
One type of transport channel is introduced: Dedicated CHannel (DCH). A DCH is a unidirectional channel dedicated
to one MS used in uplink or downlink. A mobile station may have one or more TrCHs of type DCH active at the same
time.
6.5.2 A/Gb mode
Text will be added when FLO concepts for A/Gb mode have stabilized.
6.5.3 TBF configuration principles
Each TBF is mapped to 1 transport channel per each timeslot assigned to the TBF (see subclause 6.4) for sending RLC
data blocks. When a TBF is assigned multiple timeslots, the transport channels used by the TBF shall be configured
with the same Transport Format Set. RLC/MAC control blocks are transmitted using the signalling TFC.
On a timeslot, several TBFs may be multiplexed onto the same transport channel. In this case, the receiver identifies
which TBF a transport block belongs to by means of the TFI field or a radio bearer identifier.
7 Layer 1 for FLO
The architecture of FLO is depicted in the Figure 2 below. A one-step interleaving has been assumed. This implies that
all TrCHs on one basic physical subchannel have the same interleaving depth.
ETSI
3GPP TR 45.902 version 13.0.0 Release 13 12 ETSI TR 145 902 V13.0.0 (2016-01)
Layer 2
TrCH(i+1)  . TrCH(I)
TrCH(i)
Transport Block d , d , d ,.,d
i,1 i,2 i,3 i,D
i
CRC Attachment
Code Block u ,u ,u ,.,u
i,1 i,2 i,3 i,U
i
Channel Coding
Encoded Block c ,c ,c ,.,c
i,1 i,2 i,3 i,C
i
Rate Matching
Radio Frame f , f , f , K, f
i,1 i,2 i,3 i,V
i
Transport
Channels
Multiplexing
CCTrCH
m , m ,m , K, m
1 2 3 N
data
Inband signalling bits
(downlink only)
TFCI Mapping
Radio Packet h , h , h ,., h
1 2 3 N
radio
Interleaving
i ,i ,i ,.,i
1 2 3 N
radio
Physical Channels
Figure 2: FLO Architecture
7.1 CRC Attachment
Error Detection is provided on each transport block through a cyclic redundancy check (CRC). The size of the CRC to
be used is fixed on each TrCH and configured by Layer 3 (semi static attribute of the transport format): 0, 6, 12 or 18
bits. Code blocks are output from the CRC attachment. The entire transport block is used to calculate the parity bits.
The parity bits are generated by one of the following cyclic generator polynomials, and appended to the transport block:
18 17 14 13 11 10 8 7 6 3 2
- gCRC18(D) = D + D + D + D + D + D + D + D + D + D + D + 1  as in SACCH/TP
12 11 10 8 5 4
- gCRC12(D) = D + D + D + D + D + D + 1 as in GPRS
6 5 3 2
- gCRC6(D) = D + D + D + D + D + 1   as in TCH/AFS
The resulting upper limits for the residual bit error rate (RBER), listed in Table 1 below, fulfil the QoS requirements
specified in 3GPP TS 23.107.
ETSI
3GPP TR 45.902 version 13.0.0 Release 13 13 ETSI TR 145 902 V13.0.0 (2016-01)
Table 1: RBER
CRC Size RBER
-2
6 bits 2.10
-4
12 bits 2.10
-6
18 bits 4.10
7.2 Channel Coding
After CRC attachment, the code blocks are processed through channel coding, producing encoded blocks.
Only one type of coding is proposed for use in Release 6, the same 1/3 convolutional code of constraint length 7 as in
EGPRS, defined by the following polynomials (see 3GPP TS 45.003):
2 3 5 6
G4 = 1 + D + D + D + D
2 3 6
G7 = 1 + D + D + D + D
4 6
G5 = 1 + D + D + D
7.3 Rate Matching
The rate matching is the core of FLO. In rate matching, bits of an encoded block on a transport channel are repeated or
punctured. Since the block size is a dynamic attribute, the number of bits on a transport channel can vary between
different transmission times. When it happens, bits are repeated or punctured to ensure that the total bit rate after TrCH
multiplexing is identical to the total channel bit rate of the allocated basic physical subchannel.
When only one transport channel is active at a time, the coding rate only depends on the transport block size and on the
available channel bandwidth. But when more than one transport channel is active, the coding rate also depends on the
rate matching attributes associated to each transport channel. The rate-matching attribute is used to calculate the number
of bits to be repeated or punctured for each transport channel.
Higher layers assign the rate matching attribute for each transport channel. This attribute is semi-static and can only be
changed through higher layer signalling. The rate matching attributes define priorities between the coded bits of
different transport channels. The higher the rate matching attribute is, the more important the coded bits are. By setting
different rate matching attributes to different transport channels, the effective coding rate (as a result of puncturing or
repeating bits of an encoded block) of the transport channels can be adjusted.
Outputs from the rate matching are called radio frames. For every radio packet the rate matching produces one radio
frame per encoded block, i.e. per TrCH.
The rate matching algorithm for GERAN is based on the UTRAN one defined in 3GPP TS 25.212. A few
simplifications are made since there is no spreading factor, nor compressed mode, nor special cases such as turbo codes
and therefore many parameters of the UTRAN algorithm can be fixed either to 0 or 1 in GERAN.
Notation used:
x Round x towards -∞, i.e. integer such that x −1 < x ≤ x .
⎣⎦ ⎣ ⎦
x Absolute value of x.
I Number of TrCHs in the coded composite transport channel (CCTrCH).
N Total number of bits that are available in a radio packet for the CCTrCH.
data
N Number of bits in an encoded block before rate matching on TrCH i with transport format combination j.
i, j
ΔN If positive, ΔN denotes the number of bits that have to be repeated in an encoded block on TrCH i
i, j i, j
with transport format combination j in order to produce a radio frame.
ETSI
3GPP TR 45.902 version 13.0.0 Release 13 14 ETSI TR 145 902 V13.0.0 (2016-01)
If negative, ΔN denotes the number of bits that have to be punctured in an encoded block on TrCH i
i, j
with transport format combination j in order to produce a radio frame.
If null, no bits have to be punctured nor repeated, i.e. the rate matching is transparent and the content of
the radio frame is identical to the content of the encoded block on TrCH i with transport format
combination j.
RM Semi-static rate matching attribute for transport channel i.
i
e Initial value of variable e in the rate matching pattern determination algorithm.
ini
e Increment of variable e in the rate matching pattern determination algorithm.
plus
e Decrement value of variable e in the rate matching pattern determination algorithm.
minus
Z Intermediate calculation variable.
i, j
R Redundancy pattern index used for retransmissions of signalling transport blocks on half rate channels
(see subclause 7.5). In all other cases R = 0.
For each radio packet using transport format combination j, the number of bits to be repeated or punctured ΔN within
i,j
one encoded block for each TrCH i is calculated with the following equations:
Z = 0
0, j
i
⎢ ⎥
⎛ ⎞
⎜ RM × N ⎟× N
⎢ ∑ m m, j data ⎥
m=1
⎝ ⎠
⎢ ⎥
Z = for all i = 1 … I
i, j
I
⎢ ⎥
RM × N
∑ m m, j
⎢ ⎥
m=1
⎣ ⎦
ΔN = Z − Z − N for all i = 1 … I
i, j i, j i−1, j i, j
For the calculation of the rate matching pattern of each TrCH i the following relations are defined:
e = 2 × N
plus
i, j
e = 2× ΔN
minus
i, j
if ΔN < 0
i, j
e
plus
if ≥ 2
e
minus
e N
plus i, j
d = =   -- average distance between punctured bits
e
ΔN
min us
i, j
e = 1+ (R mod d ) × e
⎡ ⎤
ini minus
else
e N
plus i, j
-- average distance between transmitted bits
d = =
e − e
N − ΔN
plus min us
i, j i, j
ETSI
3GPP TR 45.902 version 13.0.0 Release 13 15 ETSI TR 145 902 V13.0.0 (2016-01)
e = 1+ (R mod d ) × (e − e )
⎡ ⎤
ini plus min us
end if
else e = 1
ini
The rate matching rule is as follows:
if ΔN < 0    -- puncturing is to be performed

i, j
e = e   -- initial error between current and desired puncturing ratio
ini
m = 1   -- index of current bit
do while m ≤ N -- for each bit of the encoded block of TrCHi

i, j
e = e – e  -- update error
minus
if e ≤ 0 then  -- check if bit number m should be punctured
puncture bit b -- bit is punctured
im
e = e + e -- update error
plus
end if
m = m + 1  -- next bit
end do
else if ΔN > 0  -- repetition is to be performed
i, j
e = e   -- initial error between current and desired puncturing ratio
ini
m = 1   -- index of current bit
do while m ≤ N -- for each bit of the encoded block of TrCHi

i, j
e = e – e  -- update error
minus
do while e ≤ 0 -- check if bit number m should be repeated
repeat bit b  -- repeat bit
i,m
e = e + e -- update error
plus
end do
m = m + 1  -- next bit
end do
else    -- ΔN = 0
i, j
do nothing  -- no repetition nor puncturing
end if.
ETSI
3GPP TR 45.902 version 13.0.0 Release 13 16 ETSI TR 145 902 V13.0.0 (2016-01)
7.4 Transport Channel Multiplexing
For every radio packet to be transmitted, one radio frame from each active TrCH is delivered to the TrCH multiplexing.
These radio frames are serially multiplexed to form a CCTrCH. The order in which each radio frame is multiplexed is
determined by the number of the associated TrCH (which is assigned during TrCH configuration).
7.4a Inband signalling bits
In the downlink direction, inband signalling bits (used to control the TFC selection algorithm in the MS, see subclause
8.5) are attached at the beginning of the CCTrCH.
The inband signalling bits are used to transmit a TFCI sequence. The number of coded inband signalling bits in each
radio packet is equal to the size of the coded uplink TFCI. For each channel type, its value is derived from the size of
the uncoded uplink TFCI (which is dependent on the number of TFCs in the uplink TFCS) following the rules in
subclause 7.5.
7.5 Transport Format Combination Identifier (TFCI)
The size of the TFCI depends on the number of TFCs needed. The smaller this is, the sh
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.

Loading comments...