Professional Documents
Culture Documents
0250 08
0250 08
Site
Wireless Division
VELIZY
Originators
C. LEJEUNE
RELEASE B12
System
Sub-system
Document Category
:
:
:
ABSTRACT
This document lists and defines all parameters and timers that are specified by BSS telecom specification
documents.
Name
App.
Name
App.
Approvals
MICHEL ROBERT
SYT team leader
ZHANG HUA
BSC DPM
NOEMI KIRELY
SU BO
MFS DPM
RAIMUND SABELLEK
BTS DPM
ROBERTO ALBU
OMC DPM
MICHEL WU
SYT DPM
REVIEW
Ed. 01 Proposal 01
2010/12/17
Ed.01 Proposal 02
2011/02/25
Ed.01 Proposal 03
2011/03/18
Ed.01 Proposal 04
2011/05/26
Ed 01 Released
2011/06/29
ED8 RELEASED
1/43
HISTORY
Ed. 01 Proposal 01
2010/11/26
2010/12/17
Ed.01 proposal 03
2011/02/25
ED8 RELEASED
2/43
Ed.01 proposal 04
2011/03/18
Ed.01 proposal 05
2011/05/26
Ed.01 Released
2011/06/29
Ed.02 Released
2011/08/11
ED8 RELEASED
3/43
Ed.03 Released
2011/11/10
ED8 RELEASED
4/43
Ed.04 Proposal01
2011/11/25
OP1 : the MFS parameters (IP@ and port) for GBoIP and IPGCH
have to be managed by the LR BSC as for the other IP interfaces
of the BSC)
OP2: POLO and CAE template will manage the CAE PS parameters
applicable to LR
OP3: editorial change in text fields to avoid MFS , BSCGP, or
GP/GPU in LR PS parameters
OP4: list of CS features non applicable to LR (TDM mode,
max_tch_per_ccp, etc.) to be completed
OP5: to generate a single new GCD table for LR parameters (step
1 of the converged LR)
Ed.04 Proposal02
2012/01/27
Ed.04 Proposal03
2012/03/23
ED8 RELEASED
5/43
Ed.04 Released
2012/06/11
ED8 RELEASED
2012/07/05
Ed.05 Released
6/43
Ed.06 Released
2012/08/30
Ed.07 Released
2012/12/12
Ed.08 released
2013/02/08
ED8 RELEASED
7/43
TABLE OF CONTENTS
INTERNAL REFERENCED DOCUMENTS................................................................................... 9
1 INTRODUCTION ........................................................................................................ 14
3 GLOSSARY .............................................................................................................. 39
ED8 RELEASED
8/43
REFERENCED DOCUMENTS
GSM References
[1]
3GPP TS 03.41
[2]
3GPP TS 03.49
[3]
3GPP TS 44.006
[4]
3GPP TS 44.008
[5]
3GPP TS 44.012
[6]
3GPP TS 44.060
[7]
3GPP TS 45.002
[8]
3GPP TS 45.008
[9]
3GPP TS 48.006
[10]
3GPP TS 48.008
[11]
3GPP TS 48.056
[12]
3GPP TS 48.058
[13]
3GPP TS 48.060
[14]
3GPP TS 48.061
ED8 RELEASED
9/43
CCITT/ITU References
[15]
[16]
[17]
[18]
[19]
ED8 RELEASED
10/43
Proprietary documents
[20]
Handover preparation
[21]
[22]
[23]
Normal Assignment
[24]
Ciphering procedure
[25]
Call release
[26]
Channel modification
[27]
Classmark handling
[28]
[29]
[30]
Radio measurements
[31]
[32]
[33]
[34]
[35]
[36]
[37]
[38]
[39]
[40]
[41]
ED8 RELEASED
11/43
[42]
[43]
[44]
[45]
[46]
LapD Management
[47]
[48]
Handover management
[49]
[50]
[51]
[52]
[53]
[54]
[55]
[56]
[57]
[58]
[59]
[60]
[61]
[62]
[63]
ED8 RELEASED
(Gb
12/43
[64]
[65]
[66]
[67]
[68]
[69]
[70]
RELATED DOCUMENTS
None
PREFACE
None.
ED8 RELEASED
13/43
INTRODUCTION
The aim of this document is to provide complete information for Telecom system parameters
implementation.
This document provides for each parameter: its accessibility, its instantiation, its allowed logical values and
its possible relationships with other parameters. The coding of the parameters is indicated wherever it is
relevant.
In the main part of the document, parameters have been grouped by sub-system (BSC, BTS, MFS and
transcoder), and are listed in alphabetical order.
Default values for parameters depending on the type of cell or on the number of TRX are given at the end of
the document, before the index.
Coding rules reflect the coding of the parameters in the external interfaces (when applicable). This coding
shall be respected as far as possible in the internal interfaces.
However, if the coding of the internal interface is different from what is expressed in the coding rule (i.e.
the external interface), the min., max. CODED values that are additionally indicated in the BSS telecom
parameters catalogue will reflect the internal values.
NB : with the introduction of the BSS over IP feature, several parameters have been introduced, and with
them the question about their catalogue, BTP or BOP ? It has been decided to add the new parameters
(addresses, ports, timers, thresholds) in the right catalogue according to their related protocol: in the
BOP for the O&M protocol (OML, TCSL, BSC O&M, MFS O&M) and in the BTP for the telecom protocol (RSL,
IPTCH, IPGCH, Asig, A user plane, GSL). This rule is not retroactive.
NB: From B12, the new parameters are applicable to Evolution products only.
NB: Inside a B12 network, the parameters of a legacy MFS are not described in the present B12 BTP, but in
the B11 one. But for the BSC G2, on contrary to the MFS, their parameters are described in the present
B12 BTP, because a G2 BSC of a B12 network offers a B12 interface; although it remains internally with a
B11 functionnal level. When some restrictions or specific behaviors are required, they are described in the
present B12 BTP.
ED8 RELEASED
14/43
This section gives a short explanation for each field describing the parameters.
The complete description of parameters is given in the file 0250_xxa.doc. The parameters are sorted by
sub-system, and then in alphabetical order.
Constraints:
- Mandatory
- Upper case string with length < 100 characters
- Square brackets ([ and ]) are allowed only for describing the element of an array
- semi-colons (;) are not allowed.
- Hyphens (-) shall be avoided (use _ instead)
- name beginning with number (ie. 0..9) is forbidden (due to MIB constraint)
Some parameters are duplicated in BSC and MFS. In this case, the NE concerned is indicated between
brackets at the end of the name.
Note that from the OMC point of view, there is only one parameter, whose value is sent to BSC and MFS.
Note: agreed naming rule, applicable to the system (CST) dimensioning parameters of the MFS:
- Such parameter is named xxx_GP3 when a specific value is applicable to boosted GP board (ie. GP3)
only.
- Such parameter is named (or renamed in case xxx_GP was existing in B11) xxx_GP2 when a specific
value is applicable to old GP board (ie. GP2) only.
- Such parameter is named xxx_GP when a common value is applicable to both boards, boosted GP and
old GP (ie. GP2 and GP3). In such case, it may happen that the new following DSP/PTU naming
convention is not followed (DSP remaining, as inherited from the previous release)
In addition, depending on the processor where the PTU/SW is hosted, the following DSP/PTU additionnal
naming rule applied:
- In IP mode:
PTU/SW is hosted in the BTS on a TRE (either G3/G4/G5/MC), and _PTU_xx_IP_ is included in the name
(DSP replaced by PTU_xx_IP).
- In TDM mode:
On GP3,the RLC/MAC part of the PTU is hosted on the multicore processor (and the MEGCH part of the
PTU is still on the DSP), then _PTU_ is included in the name (DSP replaced by PTU) when the parameter
value comes from a limitation of the RLC/MAC part .
On GP2, the PTU/SW is hosted on the DSP, then _DSP_ is included in the name; but DSP is then replaced
by PTU in order to keep the same prefix as GP3 one (PTU is more generic than DSP).
ED8 RELEASED
15/43
If the parameter is to be displayed at OMC-R, the name that shall appear on the OMC-R screen is
given in the field HMI name.
Constraints:
- Optional
- String with length < 100 characters
2.3 Definition
Definition:
Constraints:
- Mandatory
This field indicates if the parameter is related to GPRS (GSM packet) or to GSM circuit.
Constraints:
- Mandatory
- Values are limited to the following list:
Table : Domains
ED8 RELEASED
Code
Meaning
GSM
16/43
GPRS
E-GPRS
2G-3G
LCS
VGCS
IP
DTM
2G-LTE
2.5 Sub-system
Definition:
Constraints:
- Mandatory
- Values are limited to the following list:
BSC : even for the parameters used by the BTS and which are sent by the BSC to the BTS (via
RSL or OML).
BTS
MFS
TC
OMC
2.6 Instance
Definition:
Constraints:
- Mandatory
- Values are limited to the following list:
ED8 RELEASED
17/43
ED8 RELEASED
18/43
Table : Instances
Instance
Meaning
cell
adj
3G cell
BTS
BSS
BSC
MFS
MSC
BC
BSCproc
TRAU
TRX
ACH
Trunk
N7ch
OMC
GPU
ED8 RELEASED
19/43
BVC
DSP
PDCH
PDCH group
PVC
Abis link
Abis segment
Abis group
SCTP EndPoint
IP-GSL
ED8 RELEASED
20/43
NSE
SGSN-IPEndPoint
IPEndPoint
LTE cell
In the PCU, one NSE is defined per PMU for each SGSN
connected to the BSS
Note that for all parameters per adjacency, the OMC does not verify the mandatory rules. For these
parameters, the OMC only verifies that the value corresponds to the one of the target cell.
2.7 Category
Definition:
This field indicates if each instance of a parameter may take the same value throughout the
network, or if there is the necessity for different instances to take different values. It also shows the
nature of the changeability of the parameter by operator procedures.
Constraints:
- Mandatory
- Values are limited to the following list:
ED8 RELEASED
21/43
Config.
SITE (CAE)
Network (CDE)
System (CST)
Meaning
(Customer Application Engineering parameter).
Parameter which can be different from one
instance to another instance (e.g. cell to cell or
from BSC to BSC or from MFS to MFS)
(Customer Design Engineering parameter).
Parameter which can be specific for a customer
and valid for the complete network (even if that
network is composed of several own PLMNs).
Constant data. Parameter that cannot or shall not
be modified by the operator (This parameter can
be hard coded or defined in a config file read at
the NE restart. It is not known by the operator)..
Constraints:
- Mandatory
- Values are limited to the following list:
Config.
None (DLS)
None
ED8 RELEASED
Meaning
the parameter is present in the BSC or MFS
database, but not in the BSS-OMC interface
(MIB). As a consequence, its modification
requires a data base reload.
22/43
Config.
Meaning
Displayed
Virtual, Displayed
Virtual, Changeable
Set by create
ED8 RELEASED
Virtual (DLS)
23/43
Among all possible constellations only the ones listed in the tables below are permitted. They depend
on the sub-system (e.g. BSC, MFS). The tables below indicate also the consequences in terms of
migration and if the value of a parameter of such a kind can be modified / customised.
2.9.1
Sub-system: BSC
Category
System(CST)
OMC-R access
Changeable
None (DLS)
NO
Migration
NO
comments
In DLS
Parameter hard
coded
Displayed
Network(CDE)
None (DLS)
Value can be
customised
at
initialisation via
the CDE-table.
NO
(Migration
only
in
extraordinar
y cases)
Value
not
changeable, but
default
value
might
be
customised
via
the CDE-table if
it is a new
parameter.
Yes
(DLS
migration)
Yes
Yes
No
Yes
(DLS
migration)
Virtual
changeable
Value might be
changed
by
changing value(s)
of
the
parameter(s) it is
depending on.
Yes
Virtual (DLS)
No
No
Set by create
Displayed
Site (CAE)
None(DLS)
Displayed
Changeable
None (DLS
restricted)
&
Parameters
depending
on
the
type
of
connected MSC
Yes
Access restricted
to
Alcatel
Lucent team
See 2.25.1 for more detail about the migration rules of BSC parameters.
ED8 RELEASED
24/43
2.9.2
Sub-System: MFS
Category
System(CST)
OMC-R access
Changeable
Migration
Network(CDE)
None (DLS)
None (not in DLS)
None (DLS)
Site (CAE)
Set by create
Default value is
set by OMC or
the
MFS
at
creation of the
corresponding
instance.
Yes.
Displayed
Depending
the case
Depending
on the case
Changeable
Yes
ED8 RELEASED
NO
NO
Value might be
customised
via
BUL files
by MFS
on
Yes.
OMC
migrates
radio
data
(via
reinit+resynchro) that
are present
at
OMC/
MFS itf.
MFS
migrates
ater/ Gb/ HW
data
(via
data
conversion
scim)
that
are present
at
OMC/
MFS itf.
comments
25/43
Virtual
changeable
None (DLS)
Value might be
changed
by
changing value(s)
of
the
parameter(s) it is
depending on
Default value is
set by the MFS
Yes
By MFS
Parameter
unknown
from
the OMC
See 2.25.2 for more detail about the migration rules of MFS parameters.
2.9.3
Sub-System: OMC
Category
Site (CAE)
2.9.4
OMC-R access
Changeable
Changeable
Yes
Migration
Yes
Comments
No
migration
rules defined in
the BSS telecom
parameters
Sub-System: BTS
Category
OMC-R access
Changeable
Migration
Comments
System (CST)
No
No
Hard coded
Network (CDE)
No
No
Parameter
configured
FU.CPF file
Site (CAE)
No
No
Depending
on
the case (FU.CPF
file or deduced
from
another
parameter)
2.9.5
via
Sub-System: TC
Category
System (CST)
ED8 RELEASED
OMC-R access
None (not in DLS)
Changeable
No
Migration
No
Comments
Hard coded
26/43
This field indicates if the default value depends on the cell type. If yes, these default values shall be
given in a specific table.
Constraints:
- Mandatory (default = no)
- Possible values: No, Yes
This field indicates if the default value depends on the number of TRX in the cell. If yes, these
default values shall be given in a specific table.
Constraints:
- Mandatory (default = no)
- Possible values: No, Yes
2.12 Type
Definition:
Constraints:
- Mandatory
- Values are limited to the following list:
ED8 RELEASED
Type
Description
Flag
Timer
Timer
Threshold
Threshold
Number
Number
27/43
Reference
List of numbers
Abstract
parameter
Abstract parameter
An abstract parameter results from
the combination of several
parameters (like a structure)
Bitmap
IP address
Enumerated
2.13 Unit
Definition:
Constraints:
- Mandatory.
- Values are limited to the following list:
Table : Units
ED8 RELEASED
Unit
Meaning
None-
No unit
byte
byte
kbit
kbit
kbit/s
kbit/s
mn
minute
second
BSS TELECOM PARAMETERS - RELEASE B12
3BK 11203 0250 DSZZA
28/43
ms
millisecond
percent
dB
dB
dBm
dBm
SAmfr
2xSAmfr
51mfr
bper
bit period
it corresponds to 48/13 s,
and a distance of about 550m
CBper
kbyte
kbyte
km
km
ppb
Constraints :
- Mandatory
ED8 RELEASED
29/43
Constraints:
- Mandatory
- Numerical value: integer or floating point
- Same format is used for Minimum value, Maximum value and Default value fields.
ED8 RELEASED
30/43
Coded Min indicates coded value of minimum value of parameter (see 2.14).
Coded_default indicates coded value of default value of parameter (see 2.16), or is empty.
Coded Max indicates coded value of maximum value of parameter (see 2.15).
Remark: the coded values (Coded Min, Coded_default and Coded Max) describe how the parameter is
coded inside the software. The coded value may be different than its corresponding real value: for
example, the (real) minimum value of MAX_GPRS_CS is 2 (means CS-2) and its Coded Min is 1 (coded
in two bits: 01).
When the default value is None, for implementation purpose, a coded default value may be
specified (e.g. a coded default value may be needed when the relative object is created before the
operator customized the parameter value) or not (e.g. the parameter is mandatory at the object
creation time). In case of not empty coded default value, the OMC shall not display that dummy
coded default value and highlight the missing configuration to the operator. Two ways may be used
to define, in the BTP, that dummy value: 1) that value is defined outside the coded range of validity
(but is included in the MIB); or 2) that value is defined inside the coded range of validity, which has
been extended with that particular value included.
Constraints:
- Mandatory
- Coded value shall conform to the coding rules (2.17).
ED8 RELEASED
31/43
This field contains any additional comments relevant for the parameter, for internal use.
Constraints:
- Optional
The internal comment is also used to map the parameters on to the MRs of the release. For exemple:
a new parameter, introduced in MR1 (ie not present in MR0), will be tagged This parameter is a
MR1 parameter.
an old parameter, removed from MR1 (but still present in MR0), will be tagged This parameter is
not relevant from MR1
a parameter, existing from the first MR of the release (either coming from previous release or
linked to a new feature supported from the first MR of the relase) will not be tagged
The extraction of the customer parameters managed by GCD is based on this tag. Nothing prevents the
other subsystems to use it, if needed.
ED8 RELEASED
32/43
indicates possible relationship rules with other parameters and whether these rules are
recommended or mandatory
Remark: mandatory rules have to be checked by the relevant entities (OMC-R, DLS population tools,
etc.).
Recommended rules are purely informative and shall not be checked (because the check cannot be
performed due to unavailability of the value or the check is not required for a pure
recommendation).
Constraints:
- Optional
- String with length < 255 characters
2.23 Feature
Definition:
This field indicates the feature the parameter is related to. It usually refers to the SFD (or the RFD)
that first introduced this parameter.
Constraints:
- Optional
- String with no length constraints
33/43
- Optional
- String with length < 255 characters
System (CST)
Network (CDE)
Site (CAE)
Present
in Old Rel
Present
in New Rel
Migration
Type
No
Yes
None
Not applicable
Yes
Yes
None
Not applicable
No
Yes
None
Not applicable
Yes
Yes
None
(note1)
Not applicable
No
Yes
None
(note2)
Not applicable
Yes
Yes
Value of previous
release
OR
Explicit rule
(note3)
ED8 RELEASED
34/43
When a mandatory rule is added in New release, an explicit rule may be required in order to ensure that
that new mandatory rule is fulfilled for any valid value (customized or changed by the operator) used in
the previous Old release.
2.25.2 Sub-System: MFS
The Site (CAE) MFS parameters are either migrated by the OMC or by the MFS itself.
Of course, a parameter could be migrated by the OMC, only if it is OMC changeable by the OMC, ie:Site
(CAE) and <> None and <> Displayed
The MFS considers two types of CAE parameters:
The parameters with (BSS, or Cell or Adj) as instance: these parameters are migrated by the OMC,
which then downloads the migrated value into the MFS. In the past, they were used to be
identified as related to the radio domain, but the applicable domain has been enlarged to other
domains (like Gb, Gb flex, ); so now on, they are identified by their related object instance,
which is persisted by the OMC between different releases.
The parameters with other instance (like PVC, NSE, IP-GSL,): the others site (CAE) parameters
are migrated by the MFS itself and then the OMC uploads then the migrated values
The present table summarizes the migration rules defined in the BTP, according to category of the
parameter.
Category
System (CST)
Network (CDE)
Site (CAE) +
Not OMC
changeable
OR
Present
in Old Rel
Present
in New Rel
ED8 RELEASED
No
Yes
None
Not applicable
Yes
Yes
None
Not applicable
No
Yes
None
Not applicable
Yes
Yes
None
No
Yes
Migration of new
Bx MFS parameters
by the MFS
(note2)
Yes
Yes
Migration
of
common Bx-1/Bx
MFS parameters by
the MFS
Value of previous
release
Migration of new
Bx MFS parameters
by the OMC (note2)
Migration
Type
No
Yes
(note1)
Not applicable
OR
Explicit rule
(note3)
35/43
Yes
Yes
Migration
of
common Bx-1/Bx
MFS parameters by
the OMC
Value of previous
release
OR
Explicit rule
(note3)
Note1: At each New release, a new customer BUL fiel is generated by the MFS. The values of the Old file
are not migrated.
Note2: We cannot talk about real migration for new parameters, but rather about initialisation with the
default value (when any is defined) or with the coded default value (when no default value is specified in
the BTP, because the value is customer network dependent, like the bases for IP addresses and for
TCP/UDP ports). As soon as a parameter is initialized by a sub-system (OMC or MFS), it is used to be
migrated also by that sub-system in the next release.
Note3: The explicit rule generally involves parameters present in the Old release.
An explicit rule is also specified when several migration paths (coming from different MR of the Old
release) are existing
When a mandatory rule is added in New release, an explicit rule may be required in order to ensure that
that new mandatory rule is fulfilled for any valid value (customized or changed by the operator) used in
the previous Old release.
2.25.3 Sub-System: OMC
No migration rules defined in the BSS telecom parameters
2.25.4 Sub-System: BTS
No parameter is migrated, since none is in the DLS.
2.25.5 Sub-System: TC
No parameter is migrated, since none is in the DLS.
ED8 RELEASED
36/43
Parameters such as cell or sub-system identifiers SHALL NOT be included in the list;
Parameters enables / disables a new feature SHALL NOT be included in the list.
Parameters in DLS and Restricted
When the default value is defined to None, the CDE table contains the corresponding coded default
value (ex: the parameters that shall be initialized by the operator, and for which a default value is
meaningless).
ED8 RELEASED
37/43
The range of values (and default value, if present) is the one, the operator used to manage, ie the one
described in 2.14 and 2.15 (of the general sheet of the access database).
NB : when the coded range (2.18) is different, POLO shall perform the required translation, according to
the coding rule (2.17).
When using Polo, a parameter can be populated in the BSC with 2 main different ways:
-on a per instance basis: the operator defines the value per object (eg per cell). There is only a subset of cell
parameters managed in this way. Those parameters are qualified as 'cell design' parameters,
- via CAE template .
Additionally, there is the possibility to define 'exceptions' applied on top of the templates.
The criteria to set a parameter in a CAE template file follow:
-The parameter shall have a default value, which is meaningful (different of "None" and a value really
significant for the customer).
Usually, feature activation flags do not fulfill that criteria; for them the cell design way is advised.
Addresses, frequencies, neighboring cells... are not part of templates.
- The advised default value shall be meaningful for several cells (either valid for all cells of the BSS or
valid for some types of cell, or some frequency ranges). Thresholds, timers used in algorithms are
generally part of CAE templates.
If the value is really cell specific (different values in different cells), the other way is advised.
ED8 RELEASED
38/43
GLOSSARY
AGCH
ARFCN
BCCH
BLKS
BLocKS
BSC
BSCGP
BSS
BTS
CCCH
CHAN.
Channel
CND
Configuration Data
CRC
CS
Circuit Switched
DPC
DTX
Discontinuous Transmission
FACCH
GPRS
GSL
IE
Information Element
LAPD
LCS
LoCation Services
LR
Light Radio
LRC
LR Controler/Cloud element
LSB
MFS
ED8 RELEASED
39/43
MSB
MSC
MTP
NA
Not Applicable
OIE
OML
OPC
PCH
Paging Channel
PCU
PS
Packet Switched
RACH
RRM
RSL
RX
Receiver
SACCH
SCCP
SCH
Synchronisation CHannel
SDCCH
SMSCB
SPI
SSF
SPA
SSP/SSA
TCH
Traffic Channel
TS
Time slot
ED8 RELEASED
40/43
If the timer expires then the assignment or handover will fail with an appropriate message being
returned to the MSC depending upon the reason for attempted radio channel seizure. If the failed
radio channel seizure was associated with an internal handover then the attempt will fail and the
next cell in the preferred cell list will be attempted (if allowed).
Location : DTC controlling the SCCP connection
T_SMS_EST_CNF
It is started when sending the first short message to the RFMNGT. It is stopped at the reception of
the message SMS_EST_CNF. If the timer expires then the set-up of the SAPI 3 connection will fail and
an appropriate failure message will be sent to the MSC.
Location : DTC controlling the SCCP connection
T_DEL_RLS
It is started when the MSC starts the release procedure (CLEAR_REQ not sent to the MSC), provided
that the speech/data path across the BSC is established. It is used to prevent the RFMNGT controlling
the connected radio channel receiving the RLS_REQ from the DH_TCU before the CLEAR_CMND
message is received from the BSSAP.
Location : DTC controlling the SCCP connection
T_MOD_REQ
It is started at the beginning of the in call modification procedure when the BSSAP triggers the
RFMNGT to send the MODE_MODIFY message to the BTS. It is stopped at the reply from the RFMNGT.
If the timer expires the in call modification procedure will fail and an ASS_FAIL message will be
returned to the MSC.
Location : DTC controlling the SCCP connection
ED8 RELEASED
41/43
It is started during the immediate assignment and SDCCH handover procedures after the successful
selection of an SDCCH channel by the SDCCH RM. It will be stopped when the confirmation is received
of the successful or unsuccessful activation of the selected SDCCH channel. If the timer expires the
selected SDCCH channel will be set to FREE in the SDCCH resource manager function and be available
for selection once more when the next CHANNEL_REQUIRED message is received over the random
access channel.
Location : Broadcast TCU (RFMNGT_C_HANDLER)
T_B
It is started at the end of the immediate assignment procedure waiting for the confirm message from
the selected BSSAP. The confirm message will be sent by the selected BSSAP in parallel to the
sending of the SCCP_CONN_REQ message to the MSC. If the timer expires then the seized radio
channel will be released using the normal release procedure towards the MS and BTS and locally
within the BSC.
Location : TCU controlling the SDCCH channel seized by the MS in response to the earlier
transmission of the immediate assignment message
T_C
It is started during the normal assignment procedure and the internal intra-cell handover procedure
(TCH or SDCCH) after the channel activation. It is stopped at the reception of the EST_IND from the
BTS or the reception of a clearing message (CLEAR_CMND, RELEASE_CH) from the BSSAP. If the timer
expires then the activated radio channel will be released towards the BTS and locally within the BSC
using the normal release procedure.
Location : TCU controlling the selected and activated TCH or SDCCH channel
T_I
It is started when either the ASS_CMND or the HND_CMND is sent to the MS. It is stopped either at the
reception of a clearing message from the BSSAP (CLEAR_CMND or RELEASE_CH) or at the reception of
the EST_IND from the BTS. If the timer expires then the old radio channel will be released using the
normal release procedure towards the MS and BTS and locally within the BSC.
Location : TCU controlling the serving (old) TCH or SDCCH channel
T_C_INTER
It is used during the internal inter-cell handover and external handover procedures. It is started after
the activation of the channel waiting for EST_IND message from the BTS. This timer is equivalent in
function to timer T_C but is used as a protection timer when an inter-cell handover is involved
(internal or external) whilst timer T_C is used as a protection timer during normal assignments and
intra-cell handovers. If the timer expires then the activated radio channel will be released towards
the BTS and locally within the BSC using the normal release procedure.
Location : TCU controlling the selected and successfully activated target TCH or SDCCH channel
ED8 RELEASED
42/43
END OF DOCUMENT
ED8 RELEASED
43/43