Site

GSM / WiMAX Business Division

All Rights Reserved © Alcatel-Lucent

STUTTGART

Originators Support of A5/3 ciphering algorithm

Elisabeth Chorques, Release B11

Joachim Schmidt

System : ALCATEL-LUCENT GSM BSS

Sub-system : SYS-TLA
Document Category : PRODUCT DEFINITION

ABSTRACT
This SFD describes the "Support of A5/3 ciphering algorithm" feature. A5/3 is a new ciphering algorithm
specified first for UMTS, and now also defined for GSM in 55.216. It will be used for circuit switched
channels (TCH & SDCCH), not with GPRS. The ciphering is seen as stronger than A5/1. Different from A5/1
and A5/2, it is not supported by all MS in the field.
The key aspects of this feature are the encryption itself (in the BTS) and the selection of the A5 algorithm (in
the BSC).

Approvals
Name S.BARRE/ G.DAEL E. BRUTH J.-P. GRUAU
App. SYT Manager / OSY Manager TPL PLM

REVIEW
Ed. 01 Proposal 01 07/04/13 Wireless/GSM&WiMAX/R&D/SYT/rma/207079

Ed. 01 Proposal 02 07/05/11 Wireless/GSM&WiMAX/R&D/SYT/rma/207080

Ed. 01 Proposal 03 28/06/07 Wireless/GSM&WiMAX/R&D/SYT/rma/207093

HISTORY
the first proposal is based on the memo 206274 Ed.05
Ed. 01 Proposal 01 07/03/23
second proposal
Ed. 01 Proposal 02 07/04/13

Ed. 01 Proposal 03 07/05/11 third proposal

Ed. 01 Released 02/07/07

ED 01 Released Support of A5/3 ciphering algorithm

0097_01.doc 3BK 10204 0097 DTZZA 1/48

03/07/2007
 TABLE OF CONTENTS
All Rights Reserved © Alcatel-Lucent

SUMMARY OF OPEN POINTS .........................................................................................................................7

1 INTRODUCTION ...........................................................................................................................................8
1.1 Scope 8
1.2 Document Structure ............................................................................................................................8
1.3 Definitions and pre-requisite ..............................................................................................................9
1.3.1 Ciphering usage prior to B11.......................................................................................................9
1.3.2 Parameter naming in the SFD.....................................................................................................9
2 HIGH-LEVEL DESCRIPTION .....................................................................................................................10
2.1 Functional Requirements..................................................................................................................10
2.1.1 Activation and optionality of the feature ....................................................................................10
2.2 Overall description of the proposed solutions...............................................................................10
2.2.1 Description of the basic A5/3 feature ........................................................................................10
2.2.2 Optional: optimised algorithm for SDCCH/TCH selection in order to maximize A5/3 usage....11
2.3 Compliance to the Marketing Requirements ..................................................................................11
2.4 Compliance to 3GPP standard .........................................................................................................12
2.5 Working Assumptions.......................................................................................................................12
2.6 Dependencies ....................................................................................................................................12
2.7 HW Coverage......................................................................................................................................13
2.8 Decision criteria .................................................................................................................................15
2.8.1 Standardisation..........................................................................................................................15
2.8.2 Competition ...............................................................................................................................15
2.8.3 Customer ...................................................................................................................................15
2.8.4 Gains .........................................................................................................................................15
2.8.4.1 Telecom gains..........................................................................................................................15
2.8.4.2 Operational gains.....................................................................................................................16
2.8.5 Risks ..........................................................................................................................................16
3 SYSTEM IMPACTS.....................................................................................................................................17
3.1 Telecom ..............................................................................................................................................17
3.1.1 Functional-level description.......................................................................................................17
3.1.1.1 Basic feature: A5/3 ciphering ...................................................................................................17
3.1.2 Telecom Specification impacts..................................................................................................19
3.1.2.1 Ciphering Procedure ................................................................................................................19
3.1.2.2 Classmark Handling.................................................................................................................19
3.1.2.3 External Channel Change........................................................................................................19
3.1.2.4 Internal Channel Change .........................................................................................................19
3.1.2.5 Handover Management ...........................................................................................................19
3.1.2.6 BSS Telecom Parameters .......................................................................................................19
3.1.2.7 DTM Functional Specification ..................................................................................................19
3.1.3 Interfaces ...................................................................................................................................19
3.1.3.1 Radio interface (TS 45.002, TS 45.008, TS 44.006, TS 44.060, TS 44.018, 24.008, etc)......19
3.1.3.2 Abis interface (TS 48.058 only for information) .......................................................................20
3.1.3.3 A interface (TS 48.008, TS 48.006 etc) ...................................................................................20
3.1.4 Simulations ................................................................................................................................20
3.2 Operation and maintenance .............................................................................................................21
3.2.1 Functional level description .......................................................................................................21
3.2.2 OMC-R parameters ...................................................................................................................21
3.2.3 Optionality management at OMC-R ..........................................................................................22
3.2.4 Modelisation of OMC-R parameters..........................................................................................22
3.2.4.1 OMC GDMO impacts ...............................................................................................................22
3.2.4.2 ACIE Interface impacts ............................................................................................................23

ED 01 Released Support of A5/3 ciphering algorithm

0097_01.doc 3BK 10204 0097 DTZZA 2/48

03/07/2007
 3.2.4.3 OMC-BSC interface impacts....................................................................................................23
3.2.4.4 OMC-MFS interface impacts....................................................................................................23
All Rights Reserved © Alcatel-Lucent

3.2.5 Other parameters ......................................................................................................................23

3.2.6 PM counters ..............................................................................................................................24
3.2.7 PM indicators.............................................................................................................................24
3.2.8 Migration B10 → B11 ................................................................................................................25
3.2.9 Java scripts................................................................................................................................25
3.2.10 Fault Management.....................................................................................................................26
3.2.11 Usage State on Demand (USD) ................................................................................................26
3.2.12 Configuration Management .......................................................................................................26
3.2.12.1 BTS ciphering capability (BTS_CIPH_CAP parameter) ..................................................26
3.2.12.2 TRX/TRE ciphering capability (TRX/TRE_CIPH_CAP parameter at BSC/OMC level)...26
3.2.12.3 Ciphering procedure: BSS_CIPH_LIST parameter replaced by CELL_CIPH_SET
parameter.................................................................................................................................29
3.2.13 Software Management .............................................................................................................29
3.2.14 O&M Specification impacts .......................................................................................................30
3.2.14.1 Software maintenance specification ................................................................................30
3.2.14.2 LCM specification ............................................................................................................30
3.2.14.3 HCM specification............................................................................................................30
3.2.14.4 IMO specification .............................................................................................................31
3.2.14.5 Network supervision specification ...................................................................................31
3.2.14.6 NMPP specification..........................................................................................................31
3.2.14.7 TMN specification ............................................................................................................31
3.2.14.8 PM File format..................................................................................................................31
3.2.14.9 OMC/BSC MIB.................................................................................................................32
3.2.14.10 OMC-BSS SW/HW file format .........................................................................................33
3.2.14.11 OMC/MFS MIB.................................................................................................................34
3.2.14.12 O&M Abis interface..........................................................................................................35
3.2.14.13 Message Dictionary .........................................................................................................37
3.3 Validation............................................................................................................................................38
3.3.1 Testing tools ..............................................................................................................................38
3.3.2 Test strategy ..............................................................................................................................38
3.3.2.1 System tests coverage.............................................................................................................38
3.3.2.2 Overall strategy for system tests..............................................................................................38
3.4 Methods ..............................................................................................................................................38
3.5 GCDs 39
3.6 Engineering rules ..............................................................................................................................39
4 SUBSYSTEM IMPACTS .............................................................................................................................40
4.1 BTS 40
4.2 BSC 40
4.2.1 Change of the BSS ciphering capability: ...................................................................................40
4.2.2 Change of the BSS ciphering procedure:..................................................................................40
4.3 Transcoder .........................................................................................................................................41
4.4 MFS 41
4.5 OMC-R.................................................................................................................................................41
4.5.1 HMI Impacts ..............................................................................................................................41
4.5.2 OMC modelization .....................................................................................................................41
4.5.3 Optional feature .........................................................................................................................41
4.5.4 Overview of the impact upon OMC specs .................................................................................41
- BTS HW Parameters..................................................................................................................................42
Define the mapping for TRX_CIPH_CAP and remove the BTS level one. ..................................................42
4.6 NPO 42
4.6.1 LASER .......................................................................................................................................42
4.7 Polo 42
4.8 OEF 43
5 PERFORMANCE & SYSTEM DIMENSIONING.........................................................................................44

ED 01 Released Support of A5/3 ciphering algorithm

0097_01.doc 3BK 10204 0097 DTZZA 3/48

03/07/2007
 5.1 Traffic model ......................................................................................................................................44
5.2 Performance .......................................................................................................................................44
All Rights Reserved © Alcatel-Lucent

5.3 Load constraints................................................................................................................................44

6 IMPACTS SUMMARY.................................................................................................................................45
7 GLOSSARY ................................................................................................................................................47
7.1 Abbreviations .....................................................................................................................................47
7.2 Terminology .......................................................................................................................................47
8 ANNEX A: 3GPP STANDARD REMINDER...............................................................................................48

ED 01 Released Support of A5/3 ciphering algorithm

0097_01.doc 3BK 10204 0097 DTZZA 4/48

03/07/2007
All Rights Reserved © Alcatel-Lucent

INTERNAL REFERENCED DOCUMENTS

Not applicable

REFERENCED DOCUMENTS

Alcatel-Lucent references

[1] 3BK 11202 0156 DSZZA Ciphering Procedure

[2] 3BK 11202 0433 DSZZA Classmark Handling

[3] 3BK 11202 0435 DSZZA External Channel Change

[4] 3BK 11202 0437 DSZZA Internal Channel Change

[5] 3BK 11202 0436 DSZZA Handover Management

[6] 3BK 11202 0434 DSZZA DTM Functional Specification

[7] 3BK 11203 0134 DSZZA BSS Telecom Parameters

[8] 3BK 11203 0135 DSZZA BSC Counters Catalogue

[9] 3BK 11203 0138 DSZZA Layer 3 Message Dictionary - Air interface

[10] 3BK 11203 0139 DSZZA Layer 3 Message Dictionary - A interface

[11] 3BK 11203 0140 DSZZA Layer 3 Message Dictionary - Abis interface

[12] 3BK 11203 0141 DSZZA Alcatel BSS Application Document to 3GPP

[13] 3BK 11204 0373 DSZZA OMC/BSC PM File Format Specification

[14] 3BK 11204 0395 DSZZA Software Maintenance

[15] 3BK 11204 0369 DSZZA OMC-BSS MIB Specification

[16] 3BK 11204 0372 DSZZA OMC/BSC SW/HW Files Format Specification

[17] 3BK 11204 0374 DSZZA O&M Abis interface

[18] 3BK 11204 0408 DSZZA Migration to Release B10

[19] 3BK 11204 0368 DSZZA BSS O&M parameters

[20] 3BK 11204 0410 DSZZA O&M Traffic model

[21] 3BK 11204 0390 DSZZA Initialisation & Maintenance

[22] 3BK 11204 0396 DSZZA Hardware Configuration Management

ED 01 Released Support of A5/3 ciphering algorithm

0097_01.doc 3BK 10204 0097 DTZZA 5/48

03/07/2007
 3GPP references
All Rights Reserved © Alcatel-Lucent

[23] 3GPP TS 24.008 V7.6.0 Mobile radio interface Layer 3 specification; Core network
protocols; Stage 3 (Release 7)

[24] 3GPP TS 42.009 V4.1.0 Security aspects (Release 4)

[25] 3GPP TS 43.020 V6.4.0 Security related network functions (Release 6)

Base Station Controller - Base Transceiver Station (BSC -
[26] 3GPP TS 48.058 V6.1.0 BTS) interface; Layer 3 specification (Release 6)
Specification of the A5/3 Encryption Algorithms for GSM and
[27] 3GPP TS 55.216 V6.2.0 ECSD, and the GEA3 Encryption Algorithm for GPRS;
Document 1: A5/3 and GEA3 Specifications (Release 6)

RELATED DOCUMENTS

Alcatel-Lucent documents

Alcatel-Lucent ref. List related documents, typically other SFDs which have an
interaction with the present SFD.

[28] 3BK xxxxx xxxxx DSZZA Title

3GPP CRs

3GPP TS CR nb Rev Title Author Accepted?

(Y/N)

ED 01 Released Support of A5/3 ciphering algorithm

0097_01.doc 3BK 10204 0097 DTZZA 6/48

03/07/2007
 PREFACE
All Rights Reserved © Alcatel-Lucent

This document is the input paper for the feature “Support of A5/3 ciphering algorithm” inside R&D. It will
further on be used as reference for the development of that feature in each subsystem.

SUMMARY OF OPEN POINTS

OP 1: There is a small risk that the G4 TRE SW size is increased over the OMU Flash size.

ED 01 Released Support of A5/3 ciphering algorithm

0097_01.doc 3BK 10204 0097 DTZZA 7/48

03/07/2007
All Rights Reserved © Alcatel-Lucent

1 INTRODUCTION

1.1 Scope
The present document aims to be the basis for decision of a proposed change to be made on the BSS
system. It provides all necessary information related to functional description, gains, description of the
system impacts and subsystem impacts.

1.2 Document Structure

The section 2 of this document presents :

• the functional requirements,
• an overall description of the features,
• the compliance to marketing requirements and to the 3GPP standard,
• which working assumptions have been made
• and the dependencies,
• as well as some decision criteria such as the risk, the gain, etc associated to the features addressed by
the present SFD.

The section 3 identifies the system impacts: it gives the principles and presents the functional split of the
feature between subsystems. The interactions within the BSS between the various modules, layers, etc are
shown as well as the interaction with the other Network Elements. Impacts on telecom and O&M Step2
specifications are also given in this section. The validation strategy is presented as well as the impacts on
GCD, methods and engineering rules.

The section 4 recaps the impacts for each subsystem.

The section 5 addresses the performance and system dimensioning concerns.

The section 6 identifies and describes the open points that have been raised in the various reviews.

The section 7 is a sum up of the system impacts.

The section 8 contains the glossary of the present document.

Annex A contains a description of the 3GPP standard features that meet the functional requirements
expressed in section 2.

Addition of annex is encouraged to give further information/details collected during the elaboration of the
SFD.

ED 01 Released Support of A5/3 ciphering algorithm

0097_01.doc 3BK 10204 0097 DTZZA 8/48

03/07/2007
 1.3 Definitions and pre-requisite
All Rights Reserved © Alcatel-Lucent

1.3.1 Ciphering usage prior to B11

- Due to former export restrictions there were three different BTS masterfiles per HW generation
reflecting the different ciphering capabilities (A5/0 only, A5/0+1 and A5/0+2), all TREs of a BTS have
the same ciphering capabilities

- At OMC side the parameter BTS_CIPH_CAP represents the BTS "ciphering usage". When the user
modifies this parameter the OMC instructs the BSC and BTS to load the new BTS SW (with the
corresponding master file name, OMU-CPF is not changed). After this the new setting of
BTS_CIPH_CAP is given to the BSC (Creation/Modification of the BTS). Today the possible settings
are:

- BTS_CIPH_CAP= A5/0 which goes with the BTS SW MF A5/0 → BTS with TRX which only
have to support A5/0

- BTS_CIPH_CAP= A5/1 which goes with the BTS SW MF A5/1 (In fact A5/0 + A5/1) → BTS with
TRX which only have to support A5/0 or TRX which have to support A5/0 + A5/1

- BTS_CIPH_CAP= A5/2 which goes with the BTS SW MF A5/2 (In fact A5/0 + A5/2) → BTS
with TRX which only have to support A5/0 or TRX which have to support A5/0 + A5/2

- In the Hardware Audit the BTS reports its cipher capabilities (corresponding to the BTS SW which is
running; BTS knows on its own) to the OMC-R per TRX (TLV#113, SBL FU), but taken per BTS (for
display in the OMC only). There was no direct reporting of the cipher capabilities from BTS to BSC.

- The required ciphering capabilities for the BTS are delivered to the BTS by the BSC in the TLV#75
(per sector, but used BTS wide) during the BTS Configuration Scenario (in the normal case it is
equal to the reported capabilities in TLV#113)

- Parameter BSS_CIPH_LIST: list of cipher algorithms according to their prio; only two possibilities:
Priority 1 = A5/1 or A5/2, Priority 2 = A5/1 or A5/2

- For a certain call segment the BSC chooses the encryption algorithm matching the MSC ciphering
requirements, the MS & BTS ciphering capabilities and takes into account the priorities given in
BSS_CIPH_LIST

1.3.2 Parameter naming in the SFD

The name TRE_CIPH_CAP is used in this specification as a shortcut for the cipheringCapabilityTDM
+ cipheringCapabilityIP parameters on the interfaces (BTS-OMC and BTS-BSC) in the
HwCapabilityInfo-FU and in the TRE-HW-CAPABILITY structs.

The parameter TRX_CIPH_CAP doesn't appear on an interface. It is used in the BSC for the ciphering
procedure and is mapped from TRE_CIPH_CAP. The particular Abis mode has to be considered.

The name CELL_CIPH_SET is used in this doc for the parameter cellciphset with the type Cell-Ciph-Set in
the OMC/BSC MIB.

ED 01 Released Support of A5/3 ciphering algorithm

0097_01.doc 3BK 10204 0097 DTZZA 9/48

03/07/2007
All Rights Reserved © Alcatel-Lucent

2 HIGH-LEVEL DESCRIPTION

2.1 Functional Requirements

A5/3 is a new ciphering algorithm specified first for UMTS, and now also defined for GSM in 55.216. It will be
used for circuit switched channels, not with GPRS.
The ciphering with A5/3 is seen as stronger than with A5/1. Different from A5/1 and A5/2, it is not supported
by all MS in the field and also not by all TRE generations.

A5/3 is an open source algorithm, so there is no need to make separate BSS software packages with and
without A5/3 (→ for A5/1 see also WA 3).

As ciphering of VGCS channels is not supported (and VGCS feature is in “restriction”), A5/3 impact on
VGCS is not analysed here.

2.1.1 Activation and optionality of the feature

Activation level of the feature cell level

Feature commercially optional Yes
Control of the activation at the per TRE quantity
OMC-R

The only A5/3 capable TRE shall be taken into account for the optionality, see section 3.2.3 for more details
on the management at OMC-R level.

2.2 Overall description of the proposed solutions

The introduction of the A5/3 ciphering algorithm into the Alcatel-Lucent BSS requires the new encryption
itself (in the BTS) and the selection among the different A5 algorithms (in the BSC).

A5/3 encryption and decryption is done in the L1 of the BTS and in the mobile. It has the same input/output
parameters as A5/1 or A5/2 for GMSK. Activation of A5/3 is done on a per call segment basis (CS only). A
BSS and a TRX must be able to handle no ciphering, A5/1 and A5/3 in parallel (on different calls).

2.2.1 Description of the basic A5/3 feature

For a call segment, A5/3 is used if:

- the MS supports A5/3. This is indicated in classmark 2 (see 24.008, §10.5.1.6)

- the TRX supports A5/3 in the intended service and current Abis mode (TDM or IP)
- the operator has enabled A5/3 support for the cell
- the NSS allows the use of A5/3
- DTM is not enabled in the cell or DTM is enabled and the Ciphering Mode Setting Capability of the
MS bit is set

This selection is done in the BSC (the MSC gives in a bitfield a set of permitted algorithms on call basis e.g.
in the CIPHER MODE COMMAND message, s. 48.008 §3.2.2.10). The BSC will always give A5/3 priority
over A5/1.

ED 01 Released Support of A5/3 ciphering algorithm

0097_01.doc 3BK 10204 0097 DTZZA 10/48

03/07/2007
 This means that the matching set of algorithms between MS, NSS, OMC-R and TRX capabilities has to be
calculated. If the result is more than one algorithm, the one with the highest A5 number will be used (i.e.
All Rights Reserved © Alcatel-Lucent

A5/3 has the highest priority). The priority table used before B11 (BSS_CIPH_LIST) is useless.

If no CIPHER MODE COMMAND message has been sent by MSC the algorithms allowed by NSS should be
considered as "A5/0 only".

Note: specific rules apply for MS in DTM, see §3.1.1.1.3

The cipher algorithm to use is signalled to the BTS via RSL (according to 48.058), using the existing
messages. (The chosen encryption algorithm is reported from BSC to MSC e.g. in the ASSIGNMENT
COMPLETE message)

To allow the mix of non-A5/3 capable and A5/3 capable TRX, the cipher capabilities have to be reported
from BTS to BSC on a per TRX basis. Therefore the TLV#128 in the BTS-HW-CAP-REPORT on the OML is
extended with the cipher capabilities.

The cipher capabilities are already reported from BTS to OMC (transparently through the BSC) on a per TRX
basis (TLV#113, SBL FU).

2.2.2 Optional: optimised algorithm for SDCCH/TCH selection in order to maximize A5/3
usage
The basic feature as described in §2.2.1 will use or not use A5/3 for a call segment depending on the
ciphering capabilities of the TRX chosen for the call segment (given that MS, OMC-R AND NSS allow the
usage of A5/3). In order to maximize the A5/3 usage in the network an MS supporting A5/3 in a cell where
A5/3 is enabled could preferentially be allocated on a A5/3 capable TRX. In the same way, MS not
supporting A5/3 could preferentially be allocated on a not A5/3 capable TRX.

As this preference given to A5/3 could potentially be to the detriment of EGPRS resources, it could be
handled via a flag EN_A53_ALLOC_STRATEGY.

PLM: this option is not needed (it is believed that in the field, the BTS will contain either only a few TREs
supporting A5/3, or only a few TREs not supporting A5/3, and the improvement would be worth doing it only
when there is a share of about 50% TREs not supporting A5/3 and 50% of TREs supporting A5/3)
→ WA 4: There will be no optimised algorithm for TCH/SDCCH selection (the switch
EN_A53_ALLOC_STRATEGY will not be implemented)

2.3 Compliance to the Marketing Requirements

This section shall identify the compliance of each feature item to one or more marketing requirements. In
case a feature item, as described in the previous section, bears some limitations/restrictions, they shall
clearly be stated in the ‘Comments’ part.

Feature Item Compliance Comments

ED 01 Released Support of A5/3 ciphering algorithm

0097_01.doc 3BK 10204 0097 DTZZA 11/48

03/07/2007
 2.4 Compliance to 3GPP standard
All Rights Reserved © Alcatel-Lucent

43.020 states in section 4.9: "It is mandatory for A5/1, A5/3 and non encrypted mode to be implemented in
mobile stations. It is prohibited to implement A5/2 in mobile stations. No other A5 algorithms shall be
supported in mobile stations."
This means: mobiles before R6 have A5/1 and A5/2, mobiles from R6 onwards have A5/1 and A5/3 (→ WA
1).

48.008, 48.058 and 44.018 are generic with respect to the ciphering algorithm, i.e. they all define 8 ciphering
algorithm possibilities ("no ciphering" and 7 different A5 algorithms). Currently only A5/1, A5/2 and A5/3 are
defined.

2.5 Working Assumptions

WA 1: As the use of A5/2 seems anyhow prohibited for new releases, A5/2 support can be removed from
the BSS. PLM : migration from A5/2 to A5/1 will be completed at B11 times, so from PLM point of view OK.

WA 2: TLV#75 is removed from the scenarios (OML and IOM), since today every TRE is able to do A5/1.
And a check for A5/3 capability cannot be done on BTS basis.

WA 3: There will be only one BTS masterfile in B11 per transmission mode (TDM or IP) including all
ciphering algorithms (depending on the TRE generation) since according to
http://www.gsmworld.com/using/algorithms/index.shtml all members of the GSM association are allowed to
use A5/1.

WA 4: There will be no optimised algorithm for TCH/SDCCH selection (the switch

EN_A53_ALLOC_STRATEGY will not be implemented)

WA 5: Optimised algorithm for SDCCH selection will not be implemented

WA 6: A check on the selected ciphering algorithms inside the parameter CELL_CIPH_SET, i.e. to refuse
the setting of only "A5/0 + A5/3", is only done at the OMC. No check is done at the BSC.
WA 7: There are different possibilities for the BSC (and OMC) to get a consistent view of the ciphering
capabilities of a TRE/TRX in every scenario. The solution described in 3.2.12.2 is taken as working
assumption.

2.6 Dependencies
In this section, the technical dependencies between features of this SFD and with features addressed by
other SFDs or already implemented are identified.

Each dependency has to be qualified by anyone of the 3 following statements.

Feature "TBC"

• requires i.e. identify the features which are required by the present one

ED 01 Released Support of A5/3 ciphering algorithm

0097_01.doc 3BK 10204 0097 DTZZA 12/48

03/07/2007
 Feature Dependency
All Rights Reserved © Alcatel-Lucent

• is enhanced by i.e. identify the features which bring an enhancement of the present feature

Feature Dependency

• is incompatible with i.e. identify the features which are technically incompatible with the present feature

Feature Dependency

• will be enhanced by the following future evolutions

Feature Dependency

• decreases the interest of i.e. identify the features (already existing or candidate for implementation)
which become less interesting or even useless if the present feature is implemented

Feature Dependency

Each dependency has to be described and the functionality required/enhanced/incompatible/less

interesting/useless has to be clearly identified.

2.7 HW Coverage
This section defines the HW coverage of the feature(s). A synthetic and exhaustive table shall be provided
where the different HW generation of each subsystem are listed.

The HW coverage of the feature(s) shall be given on a per implementation step basis where needed.

Also, the dependency on the 3GPP release of the Mobile Station and/or SGSN and/or MSC, etc shall be
indicated.

Network element:

In the following tables, indicate :

X: The feature is supported on the NE with software impacts.
N: The feature is not supported on the NE or on a NE generation (typical case is when a feature impacts
this kind of NE but has not been developped on all the generations of this kind of NE)
-: The feature does not impact NE SW

ED 01 Released Support of A5/3 ciphering algorithm

0097_01.doc 3BK 10204 0097 DTZZA 13/48

03/07/2007
 Support
BTS Generation: A9100 (Evolium standard) X
All Rights Reserved © Alcatel-Lucent

A9110 (M4M) N
A9110-E (M5M) X
SUMP X
SUMA X
SUMX X

TRE Generation: G3 (GPRS only) N

G4 (GPRS & EDGE) X1
G5 (TWIN) in tx div X
G5 (TWIN) in 2 modules X

BSC Generation: BSC G2 X

Evolium BSC (Mx) with TPV1 X
Evolium BSC (Mx) with TPV3 X

MFS Generation: MFS AS800 -

MFS DS10 -
MFS with GPU2 -
MFS with GPU3 -
Evolium MFS (Mx) -

Transcoder: TRAU G2 with DT16 -

TRAU G2 with MT120 -
TRAU G2.5 (with MT120) -
TRAU G2.5 (with MT120-WB) -

O&M: OMC-R X
POLO X
OEF X
LASER -
NPO X

External dependencies:

External dependencies
(precise also if the support of the feature is
3GPP
optional or mandatory)
Feature name introduction
Others release
MS MSC SGSN (SMLC,
RNC…)
A5/3 ciphering X (opt.) X (mand.)

1
Note: A5/3 can not be used on G4 TRE in IP mode (performance limitation)

ED 01 Released Support of A5/3 ciphering algorithm

0097_01.doc 3BK 10204 0097 DTZZA 14/48

03/07/2007
All Rights Reserved © Alcatel-Lucent

2.8 Decision criteria

2.8.1 Standardisation

The feature is fully stable (for signalling the ciphering algorithms the specs were generic since Rel. 4, but the
A5/3 algorithm itself (55.216 & 43.020) was specified in Rel. 6)

2.8.2 Competition

Most of our competitors will implement it in 2006 or 2007

2.8.3 Customer

TMO: Candidate B11 Committed in 2006 Orange RFQ (if A5/1 cracked before end 2006 in real time with
light equipment…)

2.8.4 Gains

It is important to qualify and quantify the gains brought by the feature(s). This has to be done for each step of
implementation if any.

2.8.4.1 Telecom gains

Provide here for each feature the gains for the listed applications/events and others if relevant. The detailed
calculations should be provided in annex.

The gains could show in this section what can be achieved if the feature(s) described in the present SFD are
implemented.

Feature A

Without the With the Comments

feature feature

Ping duration

WAP access duration

WAP page download duration

Web page download duration

DL FTP throughput

UL FTP throughput

Cell re-selection duration

(intra-RA / inter-RA if any
difference, 2G-2G or 2G-3G)

...

ED 01 Released Support of A5/3 ciphering algorithm

0097_01.doc 3BK 10204 0097 DTZZA 15/48

03/07/2007
All Rights Reserved © Alcatel-Lucent

Feature B

Without the With the Comments

feature feature

Ping duration

WAP access duration

WAP page download duration

Web page download duration

DL FTP throughput

UL FTP throughput

Cell re-selection duration

(intra-RA / inter-RA if any
difference, 2G-2G or 2G-3G)

...

2.8.4.2 Operational gains

none (enhanced security?)

2.8.5 Risks
List here the identified risks for each feature (IOT with MS, IOT with Core Network, late availability of new
3GPP release-compliant terminals, etc).

The level of details contained in sections 3 and 4 should allow for a direct production of the system and
subsystem specifications.

In particular, in the case of limited interaction with other features, it shall allow for a parallel update of both
Step1/2 and Step3/4 documents.

In some cases however, fine tuning of interactions between features are addressed separately e.g. in step2
documents. Also, for complex features, a delta document gathering the impacts on all step2 documents can
precede the detailed production of steps 2/3/4 documents.

ED 01 Released Support of A5/3 ciphering algorithm

0097_01.doc 3BK 10204 0097 DTZZA 16/48

03/07/2007
All Rights Reserved © Alcatel-Lucent

3 SYSTEM IMPACTS

3.1 Telecom

3.1.1 Functional-level description

3.1.1.1 Basic feature: A5/3 ciphering

General for each call segment (e.g. between handovers): Once a TCH or SDCCH is selected, if A5/3 is
supported and/or allowed by the MS, MSC, OMC-R and the TRX, then it will be used.

3.1.1.1.1 Call setup

Air Abis A

MS BTS BSC MSC

TRX1
IMMEDIATE ASSIGNMENT
IMMEDIATE ASSIGNMENT 1

SABM / SDCCH
SDCCH unciphered

CIPHER MODE CMD

ENCRYPTION COMMAND
CIPHERING MODE CMD
2
SDCCH ciphered
HANDOVER CMD
HANDOVER CMD 3

TRX2 ASSIGNMENT REQUEST

ASSIGNMENT COMMAND
ASSIGNMENT COMMAND 4

SABM / FACCH
TRX3
TCH ciphered

Figure 1: Call setup example (incomplete drawing)

1. At initial SDCCH allocation (i.e. call setup), ciphering is not started, so this SDCCH will first be
established without ciphering.

2. Ciphering algorithm will be chosen at reception of CIPHER MODE COMMAND and will take into
account the TRX capabilities (see § 2.2.1).

ED 01 Released Support of A5/3 ciphering algorithm

0097_01.doc 3BK 10204 0097 DTZZA 17/48

03/07/2007
 3. If a SDCCH handover takes place, it might happen that the ciphering capabilities of the new TRX
are different from the previous one, and therefore need to be taken into account, leading to a
All Rights Reserved © Alcatel-Lucent

possible change of the ciphering algorithm during the handover.

4. With the reception of the ASSIGNMENT REQUEST message the selection of the ciphering
algorithm is done again for the TCH. For normal (non VGCS) TCH assignments, ciphering selection
will be done based on the Encryption Information IE stored when Cipher Mode Command was
received (Encryption Information IE in Assignment request is only sent for VGCS calls).

In each of the steps 2.-4. the selection of the ciphering algorithm according to §2.2.1 has to be performed.
This requires that, from MS point of view, the ciphering algorithm can be changed during the call.

(Note 1: a Phase 1 MS can not change the ciphering algorithm during channel changes, but there is no need
to as they don't support A5/3 and A5/2 won't be supported in B11, so A5/1 will be used)
Note 2: TS 44.018: "The ASSIGNMENT COMMAND message shall not contain a cipher mode setting IE
that indicates "start ciphering" unless a CIPHERING MODE COMMAND message has been transmitted
earlier …"

3.1.1.1.2 TCH Handover

If a TCH handover takes place, it might happen that the ciphering capabilities of the new TRX are different
from the previous one, and therefore need to be taken into account, leading to a possible change of the
ciphering algorithm during the handover.

If an internal or external handover condition is met (before the sending of the CHANNEL ACTIVATION and
HANDOVER CMD on the Abis) the BSC calculates the ciphering algorithm according to §2.2.1. This
selection will be signalled with the ciphering information in the CHANNEL ACTIVATION to the new TRX
and HANDOVER CMD (or ASSIGNMENT CMD in case of intra-cell HO) to the old TRX (in the latter only
necessary if different from the previous setting).

For internal HO the NSS settings concerning ciphering to be considered by the BSC are taken from the
CIPHER MODE COMMAND, for external HO also from the HANDOVER REQUEST.

3.1.1.1.3 Specific rules for DTM capable MS

Up to recent Release 6 specifications of 3GPP, it was not possible to change the ciphering algorithm when
establishing DTM (I.E. Cipher Mode Setting missing in DTM ASSIGNMENT COMMAND => “hole” in the
rec).

This has been recently corrected in Release 6, but as the BSS does not know whether the MS is compliant
with these Release 6 specs or a previous version, a bit has been added in MS Classmark 3 to indicate
whether the MS supports or not ciphering changes in DTM (Ciphering Mode Setting Capability bit).

If this bit is set to 1, there is no restriction: the most optimised algorithm can be chosen at any time.

If this bit is set to 0, it means that whenever the MS enters DTM, then it will not be possible to change the
ciphering algorithm, i.e. if the MS was previously on a TCH or SDCCH using A5/3, and is now assigned for
DTM a TCH on a TRX not supporting A5/3, then the assignment will fail, because the MS is not able to
understand that the ciphering algorithm has been changed to A5/1.

Therefore, it is proposed that for a DTM capable MS whose Ciphering Mode Setting Capability bit is
set to 0, A5/3 shall not be used in cells where DTM is enabled. In this case a Cipher Mode Setting IE
is not sent in the DTM ASSIGNMENT COMMAND

ED 01 Released Support of A5/3 ciphering algorithm

0097_01.doc 3BK 10204 0097 DTZZA 18/48

03/07/2007
All Rights Reserved © Alcatel-Lucent

3.1.2 Telecom Specification impacts

3.1.2.1 Ciphering Procedure

changes according to the fact that

- TRX rather than BTS ciphering capabilities have to be considered in BSC (TRX_CIPH_CAP)
- operator settings have to be considered (CELL_CIPH_SET)
- A5/2 is not supported in B11, but A5/3 will be supported
- parameters BSS_CIPH_LIST and BTS_CIPH_CAP are removed
- A5/3 shall not be used in a certain case of DTM (§3.1.1.1.3)

3.1.2.2 Classmark Handling

- A5/2 is not supported in B11

- support of A5/3 ciphering capabilities in classmark 2
- support Ciphering Mode Setting Capability bit in classmark 3

3.1.2.3 External Channel Change

- take into account operator settings (CELL_CIPH_SET) and TRX ciphering capabilities instead of
BTS capabilities for external channel changes

3.1.2.4 Internal Channel Change

- take into account operator settings (CELL_CIPH_SET) and TRX ciphering capabilities instead of
BTS capabilities for internal channel changes

3.1.2.5 Handover Management

- take into account of the operator setting for CELL_CIPH_SET & TRX ciphering capability instead of
BTS capabllity for internal cells.

3.1.2.6 BSS Telecom Parameters

- remove BSS_CIPH_LIST on BSC

- add CELL_CIPH_SET on BSC , managed from OMC
- remove BTS_CIPH_CAP on BSC
- add TRX_CIPH_CAP on BSC

3.1.2.7 DTM Functional Specification

- for a DTM capable MS whose Ciphering Mode Setting Capability bit is set to 0, A5/1 shall always be
used in cells where DTM is enabled

3.1.3 Interfaces

3.1.3.1 Radio interface (TS 45.002, TS 45.008, TS 44.006, TS 44.060, TS 44.018, 24.008, etc)

Take into account A5/3 bit in MS classmark 2 and new bit(Ciphering Mode Setting Capability) introduced in
MS classmark 3, e.g. in the messages "CM Service Requrest" (24.008), "Paging Response" or "Classmark
Change" (44.018).

see also 3.1.3.2

ED 01 Released Support of A5/3 ciphering algorithm

0097_01.doc 3BK 10204 0097 DTZZA 19/48

03/07/2007
 3.1.3.2 Abis interface (TS 48.058 only for information)
All Rights Reserved © Alcatel-Lucent

Whenever the ciphering algorithm needs to be modified during a channel change (typically, the old channel
does not support A5/3, and the new one does, and vice-versa), following actions will be performed:
− Case of TCH assignment (SDCCH -> TCH assignment)
o CHANNEL ACTIVATION: new ciphering information shall be included in Encryption
Information I.E.
o ASSIGNMENT COMMAND: new ciphering information shall be included in Cipher Mode
Setting I.E.
− Case of intracell SDCCH or TCH handover: same modifications as for TCH assignment
− Case of intercell SDCCH or TCH handover: no change compared to current behaviour (change of
ciphering algorithm already supported from signalling point of view)
o CHANNEL ACTIVATION: new ciphering information shall be included in Encryption
Information I.E.
o HANDOVER COMMAND: new ciphering information shall be included in Cipher Mode
Setting I.E.
− Case of DTM assignment:
o If the MS supports ciphering changes in DTM: same rules as above apply
o If the MS does not support ciphering changes in DTM, then Cipher Mode Setting I.E. shall
NOT be included in DTM ASSIGNMENT COMMAND

3.1.3.3 A interface (TS 48.008, TS 48.006 etc)

The "Encryption Information" IE (48.008, §3.2.2.10) is contained in

- assignment request (VGCS only)
- handover request
- cipher mode command
- VGCS/VBS assignment request (VGCS only)

The "Chosen Encryption Algorithm" IE (48.008, §3.2.2.44) is contained in

- assignment complete (if the algorithm has changed)
- handover request
- handover request ack
- handover performed
- cipher mode complete

change "A5/3: not supported" to "A5/3: supported", TS 48.008 is generic with respect to the ciphering
algorithm

3.1.4 Simulations

This section indicates the simulations to be done / already done to help further definition of the feature.

ED 01 Released Support of A5/3 ciphering algorithm

0097_01.doc 3BK 10204 0097 DTZZA 20/48

03/07/2007
 3.2 Operation and maintenance
All Rights Reserved © Alcatel-Lucent

3.2.1 Functional level description

The main actions performed by the O&M part are the

• management of the parameter CELL_CIPH_SET which reflects the operator settings for the
permitted ciphering algorithms in a cell (in the OMC/BSC MIB)

• display of the ciphering capabilities of each TRE (parameter TRE_CIPH_CAP) delivered through the
Hardware Audit Service

• supervision of the activation and optionality of the feature

3.2.2 OMC-R parameters

New parameters:

Parameter Definition Sub- Instan Category2 / Type4 Range /

name system -ce OMC-R default
access3 value

CELL_CIPH_SET Indicates in a 8 bit field the BSC cell Site (CAE), A number: Default
(BTP) allowed ciphering algorithms changeable value:
by the operator (each bit each bit: A5/0 (no
represents an A5 algorithm). '0' = ciphering
algorithm )
The values can be: not
permitted
- A5/0
'1' =
- A5/0 + A5/1 algorithm
permitted
- A5/0 + A5/1 +A5/3
bit 0 :a5-0 ;
The A5/0 is always set. bit 1: a5-1 ;
bit 2: a5-2 ;
bit 3: a5-3 ;
The setting of only A5/0 + A5/3
bit 4: a5-4 ;
should be refused, because
bit 5: a5-5 ;
today not all mobiles support
bit 6: a5-6 ;
A5/3. (→ WA 6) bit 7: a5-7

(parameter for the

optionality → 4.5.3)

2
The valid options are: Site (CAE), Network (CDE), System (CST), Not Used (NU)
3
The valid options are: changeable, set by create, displayed, OMC local display, Virtual – changeable,
Virtual – displayed.
4
The valid options are: abstract, flag, list of numbers, number, reference, threshold, timer.

ED 01 Released Support of A5/3 ciphering algorithm

0097_01.doc 3BK 10204 0097 DTZZA 21/48

03/07/2007
All Rights Reserved © Alcatel-Lucent

TRE_CIPH_CAP Indicates the ciphering OMC TRE Site (CAE), A number: Default
(BOP) algorithms supported by the displayed value:
TRE. each bit:
'0' = A5/0 (no
The values can be: algorithm ciphering
not ) + A5/1
- A5/0 + A5/1 supported are
always
- A5/0 + A5/1 +A5/3 '1' = set.
algorithm
supported

The parameter consists of bit 0: a5-0 ;

bit 1: a5-1 ;
two bytes: one for TDM the
bit 2: a5-2 ;
other for IP. The OMC shall bit 3: a5-3 ;
display the capabilities per bit 4: a5-4 ;
TRE of the current and the bit 5: a5-5 ;
alternative Abis mode to bit 6: a5-6 ;
the operator. bit 7: a5-7

Mandatory rules: None

Removed parameters:
- Existing parameters shall be modified as follows:

Parameter name Modification

BSS_CIPH_LIST This parameter is removed and replaced by CELL_CIPH_SET. The

(Priority i) priority is fixed by the BSC: A5/3 has always priority over A5/1
(otherwise A5/3 would never be used). see the reasons in
i = 1 to 7 configuration Mgt

BTS_CIPH_CAP This parameter is removed, see the reasons in configuration Mgt.

3.2.3 Optionality management at OMC-R

Refer to 2.1.1.

The feature is activated with the CELL_CIPH_SET.

All the A5/3 capable TRE of the cell are counted. When the number of TRE exceeds the sold number of TRE
registered in the OMC-R, the OMC-R blocks the operator.
The number of A5/3 capable TRE have to be re-counted after switching to/from IP mode. When changing
the mode from IP to TDM the counter could possibly exceed the threshold.

3.2.4 Modelisation of OMC-R parameters

3.2.4.1 OMC GDMO impacts

The GDMO will define attributes that correspond to the following BOP/BTP parameters:

ED 01 Released Support of A5/3 ciphering algorithm

0097_01.doc 3BK 10204 0097 DTZZA 22/48

03/07/2007
 - CELL_CIPH_SET - on alcatelSector (EML) and cell (RNL) if the MOI corresponds to a B11 release
- TRE_CIPH_CAP - on alcatelLapdLink (EML) if the MOI corresponds to an RSL, regardless of the release
All Rights Reserved © Alcatel-Lucent

The GDMO will remove the EML and RNL parameters corresponding to BSS_CIPH_LIST and
BTS_CIPH_CAP BOP/BTS parameters.

The GDMO will define, in the scope of optional features, counters at EML and RNL level for the number of
A5/3 capable TREs. In EML the counter will be at sector level and in RNL at network level.

3.2.4.2 ACIE Interface impacts

ACIE will be aligned with removed parameters. It will add CELL_CIPH_SET in RNL export and
TRE_CIPH_CAP in EML export.

All other new parameters are filtered-out as being deductible from other exported parameters.

3.2.4.3 OMC-BSC interface impacts

Refer to OMC-BSC MIB.

3.2.4.4 OMC-MFS interface impacts

No impact

3.2.5 Other parameters

List the new / modified parameters that are not accessible from the OMC-R.

Parameter Definition Sub- Instan Category / Type6 Range /

name system -ce OMC-R default
access5 value

TRX_CIPH_CAP Indicates the ciphering BSC TRX None (in A number: Default
(BTP) algorithms supported by the DLS) value:
TRX in the DLS. each bit: A5/0 (no
'0' = ciphering
The values can be: ) + A5/1 i
algorithm
- A5/0 + A5/1 not are
supported always
- A5/0 + A5/1 +A5/3 set.
'1' =
algorithm
supported
The BSC updates the DLS
accordingly. The parameter bit 0: a5-0 ;
consists of two bytes: one for bit 1: a5-1 ;
TDM the other for IP. The BSC bit 2: a5-2 ;
considers the capabilities of bit 3: a5-3 ;
the particular Abis mode. bit 4: a5-4 ;
bit 5: a5-5 ;
bit 6: a5-6 ;

5
The valid options are: None (in DLS), None (not in DLS)
6
The valid options are: abstract, flag, list of numbers, number, reference, threshold, timer.

ED 01 Released Support of A5/3 ciphering algorithm

0097_01.doc 3BK 10204 0097 DTZZA 23/48

03/07/2007
 bit 7: a5-7
All Rights Reserved © Alcatel-Lucent

3.2.6 PM counters

Note:. It is SYT responsibility

Please see also if the observations counters (e.g RTCH) must be modified. Refer to PM File Format
document for the format of these observations.

Counters in the BSC

Counter Mnemonic Definition Type Measured

number object

MCxxx Number of Assignment Request 110 Cell

messages received, for MS
supporting A5/3

MCxxx Number of Cipher Mode Command 110 Cell

received from the MSC, allowing A5/3,
for a MS supporting A5/3 in a cell
where A5/3 is enabled

MCxxx Number of successful Cipher Mode 110 Cell

Command procedures for usage of
A5/3

MCxxx Number of non A5/3 assignments for 110 Cell

A5/3 Cipher Mode Commands due to
non A5/3 support of TRX (the MS
supports A5/3, A5/3 is enabled in the
cell, but the channel currently
allocated to the MS is on a TRX/TRE
that does not support A5/3)

MCxxx Number of 44.018 Assignment 110 Cell

Command / Handover Command
messages sent to an MS, with A5/3 as
ciphering algorithm

MCxxx Number of 44.018 Assignment 110 Cell

Command / Handover Command
messages sent to an MS, w/o usage
of A5/3 (the MS supports A5/3, A5/3 is
enabled in the cell, but the channel
allocated to the MS is on a TRX/TRE
that does not support A5/3)

3.2.7 PM indicators

Note:.It is PCS responsibility based on the new/modified counters.

ED 01 Released Support of A5/3 ciphering algorithm

0097_01.doc 3BK 10204 0097 DTZZA 24/48

03/07/2007
 List the new / modified indicators.
All Rights Reserved © Alcatel-Lucent

Mnemonic Definition Formula

3.2.8 Migration B10 → B11

Migration with OEF :

Parameters:
BTS_CIPH_CAP: it is removed, nothing to do
BSS_CIPH_LIST: it is removed (replaced by CELL_CIPH_SET)
CELL_CIPH_SET:
- By default, the A5/0 is set in CELL_CIPH_SET.
- If A5/1 or A5/2 was set in BSS_CIPH_LIST: the A5/1 is forced in CELL_CIPH_SET of all cells.

BSSMAP file:
OEF updates the new BSSMAP file:
Currently following File-IDs for Evolium BTS master files exist in the old BSSMAP file:
- 112 : BTS Evolium with A5/1 encryption algorithm in TDM mode
- 113 : BTS Evolium with A5/2 encryption algorithm in TDM mode
- 114 : BTS Evolium without encryption in TDM mode A5/0

Migration rules:
When migrating to B11, the A5/2 capability is cancelled automatically by OEF (if present in the previous
configuration). It is replaced (or “forced”) by A5/1.
When OEF finds 112, 113 or 114 in old BSSMAP file, it replaces them by the 112 File -Id in the new
BSSMAP file (unique file for TDM mode).
Remark: Reuse of the 112 file Id which represents all the possible encryption algorithms :
A5/0 or A5/0 + A5/1 or A5/0 + A5/1 + A5/3. Inside the BTS, it depends on the TRE capability.
Note: As the OMC triggers an hardware audit as soon as the migration is finished, the hardware capabilities
displayed to the operator and those retrieved by the BSC through a periodic audit (later) could be misaligned
for some time.

3.2.9 Java scripts

List the required Java scripts at OMC-R (needed to value complex parameters, like TRX-level parameters,
list-type parameters, etc) (to be filled in by O&M people). For each Java script, the required operator inputs
plus a high-level description of the algorithms to be run should be provided.

To be updated by OMC team

ED 01 Released Support of A5/3 ciphering algorithm

0097_01.doc 3BK 10204 0097 DTZZA 25/48

03/07/2007
 3.2.10 Fault Management
All Rights Reserved © Alcatel-Lucent

In case of TRE failure, the TRX may be remapped to another TRE with another capability. But the feature
A5/3 has no impacts on the TRE/TRX re-mapping algorithm.

3.2.11 Usage State on Demand (USD)

No Impact.

3.2.12 Configuration Management

3.2.12.1 BTS ciphering capability (BTS_CIPH_CAP parameter)

B10 Current situation:

Due to former export restrictions there were three different BTS masterfiles per HW generation reflecting the
different ciphering capabilities (A5/0 only, A5/0+1 and A5/0+2), all TREs of a BTS have the same ciphering
capabilities

At OMC side the parameter BTS_CIPH_CAP represents the BTS "ciphering usage". When the user modifies
this parameter the OMC instructs the BSC and BTS to load the new BTS SW (with the corresponding master
file name, OMU-CPF is not changed). After this the new setting of BTS_CIPH_CAP is given to the BSC
(Creation/Modification of the BTS). Today the possible settings are:

- BTS_CIPH_CAP= A5/0 which goes with the BTS SW MF A5/0 → BTS with TRX which only
have to support A5/0

- BTS_CIPH_CAP= A5/1 which goes with the BTS SW MF A5/1 (In fact A5/0 + A5/1) → BTS with
TRX which only have to support A5/0 or TRX which have to support A5/0 + A5/1

- BTS_CIPH_CAP= A5/2 which goes with the BTS SW MF A5/2 (In fact A5/0 + A5/2) → BTS
with TRX which only have to support A5/0 or TRX which have to support A5/0 + A5/2

In B11:

There is no more A5/2 and only one BTS SW MF with inside the files for old TRE (A5/0 or A5/0 + A5/1) and
the files for new TRE which support A5/3 (A5/0 + A5/1 + A5/3). The old G3 TRE cannot support the A5/3.

Remark: the old TRE G1 and G2 are no more supported in B11.

There will be only one BTS masterfile in B11 per transmission mode (TDM or IP) including all ciphering
algorithms (depending on the TRE generation) since according to
http://www.gsmworld.com/using/algorithms/index.shtml all members of the GSM association are allowed to
use A5/1.

Because of only one BTS SW MF, the BTS_CIPH_CAP parameter is no more used and can be removed
from the parameters at BTS creation/modification.

The ciphering capability is now defined at TRX level.

3.2.12.2 TRX/TRE ciphering capability (TRX/TRE_CIPH_CAP parameter at BSC/OMC level)

B10 Current situation:

The required ciphering capabilities for the BTS was delivered to the BTS by the BSC in the
btsCipheringCapabilities parameter TLV#75 (per sector, but used BTS wide) at the BTS Configuration
Scenario following the modification of the BTS_CIPH_CAP parameter at the OMC.

ED 01 Released Support of A5/3 ciphering algorithm

0097_01.doc 3BK 10204 0097 DTZZA 26/48

03/07/2007
 B11:
All Rights Reserved © Alcatel-Lucent

As the BTS ciphering capability is no more at BTS level (BTS_CIPH_CAP removed), the
btsCipheringCapabilities parameter which indicates for the whole BTS the required ciphering capabilities in
CDM block 3 is removed (→ WA 2).

Now the BSC needs this ciphering capability at TRX level for its ciphering procedure.

The BSC gets the TRE capability through the Hardware Capability Update Service (new BSC parameter
TRE_CIPH_CAP) during a complete BSC/BTS audit (scenario in IMO document). It always considers the
TRX capabilities of the particular Abis mode (TDM or IP) for the ciphering procedure.

Now the OMC also needs to retrieve the TRE ciphering capability for the display to the operator. It is done
through the Hardware Audit Service which is transparent to the BSC.

The TRE_CIPH_CAP and TRX_CIPH_CAP parameters (described at OMC-R parameter chapter) at BSC
and OMC level reflect both the ciphering capabilities depending in fact on the TRE generation.

How to trigger these BSC and OMC audits ? Several scenarios must be distinguished:

1) At 'extension/reduction TRE'

The BTS triggers a complete BSC/BTS audit to the BSC (BTS-Audit-Needed) (scenario in HCM document).
The BSC during the BSC/BTS DB audit retrieves the TRE capabilities and maps them to TRX capabilities. At
the end of this audit as a SBL has been added or removed, the BTS sends to the OMC an alarm BTS-HW-
RESYNC. Then the OMC sends an HW audit request to the BSC in order to retrieve the TRE capabilities.

Conclusion: There is no specific impact on extension/reduction TRE scenario.

2) At the 'migration' B10 ->B11 (also 'SW change')

After the migration from B10 to B11, a global BTS audit is performed for all BTS in parallel. The new
Ciphering Capability at TRE level are not detected by the BSC (no sending of HW-CAP-REQ ) and the
global audit ends without DLS updated. The new values of these capabilities will be taken into account later
during the next periodic BTS audit or during a BTS audit linked to an operator command. Again mapping of
TRE capabilities to TRX capabilities.

At the end of the migration the OMC sends an HW audit request to the BSC in order to retrieve the TRE
capabilities

Conclusion: There is no specific impact on migration scenario.

3) At the 'change mode' IP<->TDM

During the change mode scenario, BSC shall perform again the mapping of the TRE capability to TRX
capability (for the call handling the capabilities of the particular Abis mode will be considered).

Remark: The current BSC/BTS audit requested by the BTS at the end of the change mode due to BTS RSL
endpoints discrepancy is kept.

Similar to the migration, the OMC at the end, sends an HW audit request to the BSC in order to retrieve the
TRX capabilities but there should be no change (refer to the TRX_CIPH_CAP parameter)

Conclusion: There is no specific impact on change mode scenario, but BSC always considers the TRX
capabilities of the particular Abis mode.

ED 01 Released Support of A5/3 ciphering algorithm

0097_01.doc 3BK 10204 0097 DTZZA 27/48

03/07/2007
 3.2.12.2.1 Alternative solutions
All Rights Reserved © Alcatel-Lucent

The solution described in 3.2.12.2 is taken as working assumption (WA 7). It has been considered as the
best compromise between BSC effort and extensibility. Other solutions have been investigated:

alt. A) same as described in 3.2.12.2, but BTS sends the capabilties coded as enumeration (a5-0_a5-1
(0), a5-0_a5-1_a5-3 (1), a5-1_IP_ a5-3_TDM (2) ) both to BSC and to OMC

⊕ immediate knowledge of BSC at change mode time

⊕ single parameter

⊖ translation of TRE_CIPH_CAP to TRX_CIPH_CAP in BSC

⊖ restricted extensibility

alt. B) BSC is able to trigger audit at change mode time; usage of a sinlge bitstring with actual capability
between BSC and BTS

⊕ no translation

⊕ immediate knowledge of BSC at change mode time

⊕ single parameter

⊖ possibly different codings of capabilities between the 2 audits (BTS -> BSC, BTS -> OMC)

alt. C) BSC erases RSL endpoint at change mode TDM -> IP in such a way that we get systematic 'BTS
audit needed' following CDM after TDM->IP change mode; usage of bitstring with actual capability
between BSC and BTS, no immediate audit at change mode IP-> TDM

⊕ no translation

⊕ immediate knowledge of BSC at TDM ->IP transition

⊕ single parameter

⊖ delayed knowledge in BSC in IP-> TDM transition (BSC does not benefit of regain of A5/3, but
this situation will be very very seldom on the field)

⊖ possibly different codings of capabilities between the 2 audits (BTS -> BSC, BTS -> OMC)

Conclusion:
Whatever the solution, there is a delay at migration time: BSC is aware of the new capability only through
periodic BSC-BTS audit. Generally OMC is aware sooner.

ED 01 Released Support of A5/3 ciphering algorithm

0097_01.doc 3BK 10204 0097 DTZZA 28/48

03/07/2007
 Whatever the solution, if the capability of a certain TRE is depending on the [TDM/IP] mode, it might be
useful that the operator gets the 'compound' capability ie A5/3 in TDM-A5/1 in IP in such a way that he
All Rights Reserved © Alcatel-Lucent

knows in advance what will happen when he will be in IP

3.2.12.3 Ciphering procedure: BSS_CIPH_LIST parameter replaced by CELL_CIPH_SET

parameter

B10 Current situation :

List of cipher algorithms according to their priority. Each one for one priority: 1 ->7. So several parameters.
Only two possibilities:
Priority 1 = A5/1 or A5/2
Priority 2 = A5/1 or A5/2
The 'no ciphering' algorithm (A5/0) is not taken into account..
B11 :
The parameters are modified. Only one parameter with no more priority. It reflects the allowed ciphering
algorithms set by the operator. (A5/0 is always set).
The values can be:
- A5/0
- A5/0 + A5/1
- A5/0 + A5/1 + A5/3
The setting of only A5/0 + A5/3 should be refused, because today not all mobiles will support A5/3 (→ WA
6).

3.2.13 Software Management

There will be only one BTS masterfile in B11 per transmission mode (TDM or IP) including all possible
ciphering algorithms since according to http://www.gsmworld.com/using/algorithms/index.shtml all members
of the GSM association are allowed to use A5/1.
- The TDM BTS Master file: it includes all files related to the TREs and the ciphering algorithms they
can support that is to say:
o A5/0+1+3 files for G4/G5 TREs
o A5/0+1 files for G3 TREs

- The IP BTS Master file: it includes all files related to the TREs and the ciphering algorithms they can
support that is to say:
o A5/0+1+3 files for G5 TREs
o A5/0+1 files for G3/G4 TREs
OEF must take into account the fact that there are two BTS Master files at the creation of the “download
package”. Refer to software maintenance specification for the description.
It also must be taken into account that the new BTS package will be bigger due to bigger files and then the
BSS download will take more time.

ED 01 Released Support of A5/3 ciphering algorithm

0097_01.doc 3BK 10204 0097 DTZZA 29/48

03/07/2007
All Rights Reserved © Alcatel-Lucent

3.2.14 O&M Specification impacts

This section describes the main changes in the existing Alcatel-Lucent BSS O&M specifications, and the
new specifications to be planned when applicable (to be filled by OSY people).

3.2.14.1 Software maintenance specification

3.2.14.2 LCM specification

No impact

3.2.14.3 HCM specification

Modify BTS hardware capability Scenario

IF Ciphering Usage is changed

New values are sent to the BSC

BSC acknowledges the new values

Is no more relevant.

OMC-R Use case BSC Use case

Modify BTS hardware capability Modify BTS characteristics

Modify BTS hardware capability

Program Abis Transmission

Remove the following remark:

Remark: the BSC use case "Modify BTS characteristics is only used in case of Ciphering usage change.

Use Case «Create a BTS» and Use Case «Modify BTS Hardware capability»

Remove the following parameter:

Ciphering Usage (****) Ciphering algorithm to be used on the Optional No ciphering

BTS:

• "A5.0": no ciphering

• "A5.1": ciphering with A5.1 algorithm

or no ciphering

• "A5.2": ciphering with A5.2 algorithm

or no ciphering

ED 01 Released Support of A5/3 ciphering algorithm

0097_01.doc 3BK 10204 0097 DTZZA 30/48

03/07/2007
All Rights Reserved © Alcatel-Lucent

(****) The ciphering usage is used to determine the name of the OMU-CPF: see (*). There is no need to change the hardware: for BTS
G1/G2 with DRFU and Evolium BTS the same hardware is able to manage the 3 options.

And the following description:

If the ciphering usage parameter is modified, the new value of the parameter is sent to the BSC in a
LOGICALPARM-MODIFY (HW-BTS-TYPE) message while BTS_O&M is still disabled to insure that the
value of the parameter and the ciphering software are compatible when BTS_O&M is re-initialised.

Use Case «Modify BTS characteristics»

Remove of Ciphering usage in the following description:

If Qmux Address, BTS IP address, BTS IP identifier, Master/Slave, OCXO synchronisation mode, Antenna
diversity, or Ciphering usage are modified, new characteristic values are saved in the BSC database.

O&M Action «Configure BTS»

Remove the following line in the table:

Modify BTS Configuration Modify BTS HW

Capabilities

Ciphering usage X

O&M Action «E1 Change mode from TDM to IP» and O&M-Action «E1 Change mode from IP to
TDM »

no specific impact on change mode scenario, but BSC always considers the TRX capabilities of the
particular Abis mode.

3.2.14.4 IMO specification

Refer to configuration Management (TRX_CIPH_CAP). Changes according to the change of Hardware

Capability Update Service (BSC-BTS audit)

3.2.14.5 Network supervision specification

3.2.14.6 NMPP specification

3.2.14.7 TMN specification

No impact

3.2.14.8 PM File format

Counter type 110 impact

ED 01 Released Support of A5/3 ciphering algorithm

0097_01.doc 3BK 10204 0097 DTZZA 31/48

03/07/2007
 To be seen after having defined new counters if a new block has to be added in type 110.
All Rights Reserved © Alcatel-Lucent

3.2.14.9 OMC/BSC MIB

Modify BTS hardware capability:

The group “Hardware-BTS-Type” is modified:
- The btsciphcap field is removed
- The bts-ciph-cap parameter is removed

Modify BSC parameters:

The group "BSC-Parameters-Type” is modified:
- The bssciphlist field is replaced by the cellciphset
- The bss-ciph-list parameter is removed

Modify cell parameters:

The group "Cell-Chars-Type” is modified:
- The cellciphset field is added at the end of the group:

en2g3ghonoserviceho [77] En-2G-3G-HO-No-Service-HO OPTIONAL,

thrcellload3greq [78] Thr-Cell-Load-3G-Req OPTIONAL
cellciphset [79] Cell-Ciph-Set OPTIONAL

- The Cell-Ciph-Set field is added at the end of the group:

Cell-Ciph-Set ::= [PRIVATE XXXX]

-- Reference : { bdd, /see bss telecom parameters/ } --
-- Abbrev. : { /na/ } --
-- OMC Usage : { modify - C } --
-- Purpose : { List of encryption algorithms A5/0 (No enc), A5/1..A5/7 in --
-- the cell } --
-- Update Rules : { /see bss telecom parameters/ } --
-- R,U,D : { range : /na/, --
-- units : /na/, --
-- default : no-enc } --
-- Comment { FALSE = algorithm not supported; --
-- TRUE = algorithm supported; --

ED 01 Released Support of A5/3 ciphering algorithm

0097_01.doc 3BK 10204 0097 DTZZA 32/48

03/07/2007
 -- no-enc is always set to TRUE } --
SEQUENCE {
All Rights Reserved © Alcatel-Lucent

no-enc [0] BOOLEAN,

a5-1 [1] BOOLEAN,
a5-2 [2] BOOLEAN,
a5-3 [3] BOOLEAN,
a5-4 [4] BOOLEAN,
a5-5 [5] BOOLEAN,
a5-6 [6] BOOLEAN,
a5-7 [7] BOOLEAN
}

3.2.14.10 OMC-BSS SW/HW file format

BTS SW MF names:

The format has not changed for BTS SW Master files from B9 and OMU CPF that is to say:
 AAAACDEF.0FE:

AAAA: A string of four (4) characters belonging to [“A”..“Z”] and/or [“0”..“9”] and/or [”-”]

But the BTS-SW master files names are now described as follow::

First A character: This character is always: “B”

Second A character: This character is now always “M ” since the G2 BTS does not exist anymore.

Third A character: This character is now always “0” since this character does not give the ciphering
mode anymore.

Last A character: This character gives the BTS mode: “S”= TDM mode, “I”: IP mode (Present when IP
supported )

For BTS OMU-CPF files:

• for all Evolium BTS : AAAA always equal to 00O2

Remarks due to the fact that the BTS G2 are removed since B11 :
- The following BTS-SW master files related to BTS G2 are removed:
106 : BTS with DR FUs with A5/1 encryption algorithm
107 : BTS with DR FUs with A5/2 encryption algorithm
108 : BTS with DR FUs without encryption

File numbers:

ED 01 Released Support of A5/3 ciphering algorithm

0097_01.doc 3BK 10204 0097 DTZZA 33/48

03/07/2007
 Currently following File-IDs for Evolium BTS master files are defined in the B10 document for the BSSMAP
file:
All Rights Reserved © Alcatel-Lucent

- 112 : BTS Evolium with A5/1 encryption algorithm in TDM mode

- 113 : BTS Evolium with A5/2 encryption algorithm in TDM mode
- 114 : BTS Evolium without encryption in TDM mode A5/0
- 115: BTS Evolium with A5/1 encryption algorithm in IP mode
- 116: BTS Evolium with A5/2 encryption algorithm in IP mode
- 117 : BTS Evolium without encryption in IP mode A5/0

New following File-IDs for Evolium BTS master files will be defined in the B11 document for the BSSMAP
file:
- 112 : BTS Evolium in TDM mode whatever the encryption algorithm
- 113 : BTS Evolium in IP mode whatever the encryption algorithm

3.2.14.11 OMC/MFS MIB

No impact

ED 01 Released Support of A5/3 ciphering algorithm

0097_01.doc 3BK 10204 0097 DTZZA 34/48

03/07/2007
 3.2.14.12 O&M Abis interface
All Rights Reserved © Alcatel-Lucent

For Hardware Capability Update Service (BSC-BTS audit):

B10 Current situation:

TRE-HW-CAPABILITY ::= [PRIVATE 128] SET {
sblIdentity SBL-IDENTITY,
frequencyRange FREQUENCY-RANGE,
edgeCapability EGPRS-CAP,
twoPcmMode TWO-PCM-MODE,
8PskHpCapability CAPABILITY OPTIONAL,
GmskPowerCapability GMSK-POWER OPTIONAL,
8pskPowerCapability 8PSK-POWER OPTIONAL,
BtsIpRslEndpoint IP-RSL-ENDPOINT OPTIONAL,
BtsIpGchCtrlEndpoint IP-GCH-ENDPOINT OPTIONAL
}

B11:
The TreHWCapabilities parameters do not contain at the moment the ciphering capability of the TRX
(TRX_CIPH_CAP).

TRE-HW-CAPABILITY ::= [PRIVATE 128] SET {

sblIdentity SBL-IDENTITY,
frequencyRange FREQUENCY-RANGE,
edgeCapability EGPRS-CAP,
twoPcmMode TWO-PCM-MODE,
8PskHpCapability CAPABILITY OPTIONAL,
GmskPowerCapability GMSK-POWER OPTIONAL,
8pskPowerCapability 8PSK-POWER OPTIONAL,
BtsIpRslEndpoint IP-RSL-ENDPOINT OPTIONAL,
BtsIpGchCtrlEndpoint IP-GCH-ENDPOINT OPTIONAL,
cipheringCapabilityTDM CipheringCapability OPTIONAL,
cipheringCapabilityIP CipheringCapability OPTIONAL
}
CipheringCapability ::= BIT STRING {
noEncryption(0),
a5-1(1),
a5-2(2),
a5-3(3),
a5-4(4),
a5-5(5),

ED 01 Released Support of A5/3 ciphering algorithm

0097_01.doc 3BK 10204 0097 DTZZA 35/48

03/07/2007
 a5-6(6),
a5-7(7)
All Rights Reserved © Alcatel-Lucent

For Hardware Audit Service (OMC-BTS)

B10:
HwCapabilityInfo-FU ::= SEQUENCE {
cipheringCapability CipheringCapability,
rateCapability RateCapability,
rslRateCapability RSL-RateCapability,
twoPCMLinks Capability,
GmskPowerCapablity TxPowerLevel,
8pskPowerCapability TxPowerLevel,
twincapabilitiesUsage TwinCapUsage,
dummy INTEGER (255)
}

CipheringCapability ::= BIT STRING { --bit 0 always set to 1

noEncryption(0),
a5-1(1),
a5-2(2),
a5-3(3),
a5-4(4),
a5-5(5),
a5-6(6),
a5-7(7)
}

B11:
HwCapabilityInfo-FU ::= SEQUENCE {
cipheringCapabilityTDM CipheringCapability,
cipheringCapabilityIP CipheringCapability,
rateCapability RateCapability,
rslRateCapability RSL-RateCapability,
twoPCMLinks Capability,

ED 01 Released Support of A5/3 ciphering algorithm

0097_01.doc 3BK 10204 0097 DTZZA 36/48

03/07/2007
 GmskPowerCapablity TxPowerLevel,
8pskPowerCapability TxPowerLevel,
All Rights Reserved © Alcatel-Lucent

twincapabilitiesUsage TwinCapUsage,
dummy INTEGER (255)
}

BTS Configuration/Reconfiguration Service

B10:

HW-CHARACTERICS ::= [3] EXPLICIT SET {

sectorHwCharacteristicsList SET SIZE (1 .. MaxSECTOR) OF
SECTOR-HW-CHARACTERISTICS OPTIONAL,
btsCipheringCapabilities BTS-CIPH-CAP,
masterSlave MASTER-SLAVE,
treFrequencyRange SEQUENCE SIZE (1 .. MaxFU) OF
ASSUMED-FREQUENCY-RANGE OPTIONAL
}

BTS-CIPH-CAP ::= [PRIVATE 75] CipheringCapability

B11:

HW-CHARACTERICS ::= [3] EXPLICIT SET {

sectorHwCharacteristicsList SET SIZE (1 .. MaxSECTOR) OF
SECTOR-HW-CHARACTERISTICS OPTIONAL,

masterSlave MASTER-SLAVE,
treFrequencyRange SEQUENCE SIZE (1 .. MaxFU) OF
ASSUMED-FREQUENCY-RANGE OPTIONAL
}

3.2.14.13 Message Dictionary

ED 01 Released Support of A5/3 ciphering algorithm

0097_01.doc 3BK 10204 0097 DTZZA 37/48

03/07/2007
 3.3 Validation
To be filled in by VAL people, when technical content of the SFD is stable.
All Rights Reserved © Alcatel-Lucent

3.3.1 Testing tools

This section gives the list of tools needed to validate the feature. For each tool, it is mentioned :

- if the tool is a new one

- if the tool is modified compared to the previous release

- if the tool is used without modification compared to the previous release

Note that "tools" should include all what is external to the BSS product : so it includes mobiles, SGSN, etc.

3.3.2 Test strategy

3.3.2.1 System tests coverage

This section gives a first estimate of the split between the subsystem tests and the system tests.

The following points are addressed :

- what is and is not to be explicitly tested at system level ?
- can the feature be validated completely at sub-system level ?
- what is the added value of system tests compared to sub-system tests ?

3.3.2.2 Overall strategy for system tests

This section gives the guidelines that will be followed when defining the test plan.
It gives, for system tests, the categories of tests that are needed to validate the features.

- functional tests : tests performed with MS simulators and CORE network simulators, the purpose is to
validate basic scenarios, error cases, etc. Note that the real added value of functional tests versus end to
end tests needs to be addressed.

- end to end tests: tests performed with real mobile and real CORE network. Purpose is to validate the
feature from an end user point of view.

- performance tests : this is a specific case of end to end tests with a specific purpose : measurement of the
improvement brought by the feature. Note that the objective in terms of performance improvement has to be
described in the technical part of the SFD.

- Telecom and O&M load tests

- migration tests : it should be mentioned if specific migration tests are needed because of this feature

- industrialisation tests : it should be addressed in co-operation with SED team (see section on impact on
methods)

3.4 Methods
This section describes the anticipated impacts on the development and writing of Field Procedure Designs
(to be filled in by SED or/and O&M people).

ED 01 Released Support of A5/3 ciphering algorithm

0097_01.doc 3BK 10204 0097 DTZZA 38/48

03/07/2007
 3.5 GCDs
This section describes the anticipated impacts on the Generic Customer Documentation. Two kinds of
All Rights Reserved © Alcatel-Lucent

documentation can be impacted: Descriptive Documentation; Operations and Maintenance Documentation

(e.g. if the man machine interface is impacted, then the OMC online help, administrative procedures, module
replacement procedures, ... may be affected) (to be filled in by SED people).

3.6 Engineering rules

This section describes the anticipated impacts on the engineering rules (to be filled in by SED people).

ED 01 Released Support of A5/3 ciphering algorithm

0097_01.doc 3BK 10204 0097 DTZZA 39/48

03/07/2007
All Rights Reserved © Alcatel-Lucent

4 SUBSYSTEM IMPACTS

4.1 BTS
- The btsCipheringCapabilities parameter is no more taken into account in the BTS Configuration
Service.
- At the Hardware Capability Update Service and Hardware Audit Service, the BTS must give the
supported ciphering algorithms for each TRE and both Abis modes.
- TRE: A5/3 implementation in L1 (encoder, decoder and FPGA)
- TRE: SCP:
o send cipher capabilities to OMU via IOM
o allow A5/3 code point
- OMU: changes implied by OML change

OP 1: There is a small risk that the G4 TRE SW size is increased over the OMU Flash size.

4.2 BSC

4.2.1 Change of the BSS ciphering capability:

Removing of the BTS HW capability at BTS level: BTS_CIPH_CAP parameter

The BSC takes no more into account of the ciphering capability at BTS level. This was sent to the BSC
through the “modify BTS hardware capability” scenario between OMC and BSC.

Between BSC and BTS at the BTS Configuration Service, the parameter btsCipheringCapabilities is
removed.

New ciphering capability at TRX level: TRX_CIPH_CAP parameter

The BSC needs the ciphering capabilities of the TRX for the selection of the ciphering algorithm for a call
segment. It receives it through the Hardware Capability Update Service with the new parameters
cipheringCapabilityTDM and cipheringCapabilityIP and maps the TRE capability into TRX capability
in the DLS.
In the ciphering procedure it considers the capabilities of the particular Abis mode.

4.2.2 Change of the BSS ciphering procedure:

The BSS_CIPH_LIST parameter sent by the OMC becomes CELL_CIPH_SET parameter

For a certain call segment the BSC chooses the encryption algorithm matching the MSC ciphering
requirements, the MS and TRX ciphering capabilities and the ciphering allowed by the operator in the cell.
For DTM also the Ciphering Mode Setting Capability bit in MS Classmark 3 has to be considered
(§3.1.1.1.3).
The impacted scenarios are:
- classmark handling to get the A5/3 capability of the mobile
- take into account ciphering capabilities of the TRX instead of BTS

ED 01 Released Support of A5/3 ciphering algorithm

0097_01.doc 3BK 10204 0097 DTZZA 40/48

03/07/2007
 - take into account the new parameters CELL_CIPH_SET per cell.
All Rights Reserved © Alcatel-Lucent

4.3 Transcoder
No impact

4.4 MFS
No impact

4.5 OMC-R
- It is no more possible to change the ciphering capability for the BTS. The BTS_CIPH_CAP is
removed. Refer to configuration Mgt, OMC/BSC MIB and parameter chapter.

- The ciphering algorithm can be enable/disable by the operator as before. The BSS_CIPH_LIST
parameter has changed and replaced by the CELL_CIPH_SET parameter. Refer to configuration
Mgt, OMC/BSC MIB and parameter chapter.

- The TRX ciphering capability must be displayed following a Hardware audit request.

4.5.1 HMI Impacts

- The BTS_CIPH_CAP parameter is no more used and can be removed from the parameters at BTS
creation/modification in BSSUSM.(modify BTS hardware capability scenario).

- The BSS_CIPH_LIST is replaced with the CELL_CIPH_SET parameter. The ciphering HMI is
modified in RNUSM. No more priority to display. The A5-2 is removed and the A5-3 is added.

- The TRX_CIPH_CAP parameter is displayed in BSSUSM

4.5.2 OMC modelization

No impact

4.5.3 Optional feature

refer to section 3.2.3

4.5.4 Overview of the impact upon OMC specs

LCM:

- MF-Set BSS Telecom Parameters (SC/PRC)

Remove references to BSS_CIPH_LIST

- MF- Set Cell Options Parameters (SC/PRC)

Add CELL_CIPH_SET as a modifiable parameter.

- MF-Logical Audit - Cell Level (SC)

Add the check for optional features locking in case of A5/3.

ED 01 Released Support of A5/3 ciphering algorithm

0097_01.doc 3BK 10204 0097 DTZZA 41/48

03/07/2007
 KeyGen:
All Rights Reserved © Alcatel-Lucent

Add in "Dimensioning (OMC3 Limits)" the parameter corresponding to the limit for A5/3 encoding.

HW/SW Management:

- MF-Create BTS & MF-Modify BTS Hardware Capabilities

Remove references to ciphering modification.

Static Mapping:

- BTS HW Parameters
Define the mapping for TRX_CIPH_CAP and remove the BTS level one.

4.6 NPO

− Support the indicators (refer to new indicators chapter)

− Support of the new parameters (refer to OMC-R parameters)

4.6.1 LASER

No impact

4.7 Polo

POLO HW:

In B10, operator use parameter “Ciphering_usage” in btsdef.csv, to indicate the BTS ciphering capabilities.
The relation/domain should be populated in R_BEQ_HWIN.D_ENC_ALG.

In B11, this population is obsolete and should be replaced by new parameter TRX_CIPH_CAP, which is to
indicate ciphering capabilities of the TRX. This new parameter should be set in sectdef.csv now. And the
corresponding relation/domain could be R_CONF_CU.D_CIPH_CAP (newly added in B11).

POLO Logical:

1. As BSS-CIPH-LIST will be removed in B11, POLO will not need to populate it into
R_BSS_PAR2.D_ALG_PRIO.

2. New parameter CELL_CIPH_SET is added to indicate the allowed or not encryption algorithm list by
CELL. POLO will add new input parameter in CEL table and populate them into R_CELL_IN.D_CIPH_SET
(newly added in B11).

ED 01 Released Support of A5/3 ciphering algorithm

0097_01.doc 3BK 10204 0097 DTZZA 42/48

03/07/2007
 4.8 OEF
All Rights Reserved © Alcatel-Lucent

Refer to migration, software management and BSC HW/SW File format.

ED 01 Released Support of A5/3 ciphering algorithm

0097_01.doc 3BK 10204 0097 DTZZA 43/48

03/07/2007
All Rights Reserved © Alcatel-Lucent

5 PERFORMANCE & SYSTEM DIMENSIONING

5.1 Traffic model

Describe here the changes the feature(s) will imply in the traffic model (e.g. less TBF establishments, new
messages to process, etc).

5.2 Performance
Describe here the impacts on the performances of our system (e.g. shorter TBF establishment durations,
etc).

5.3 Load constraints

Describe here the load increase the feature(s) will generate on the various processors and/or interfaces.
Based on the load constraints, describe the impacts on the feature(s) (e.g. an optimisation is done to reduce
the load, or some parameters have been introduced to mitigate the load, etc). Describe also the impacts of
the feature on the system capacity.

ED 01 Released Support of A5/3 ciphering algorithm

0097_01.doc 3BK 10204 0097 DTZZA 44/48

03/07/2007
All Rights Reserved © Alcatel-Lucent

6 IMPACTS SUMMARY

Equipments:

BTS BSC G2 Evolium BSC MFS Legacy EvoliumMFS TC

X X X

OMC-R LASER NPO OEF Polo

X X X X

Interfaces:
Telecom
Radio Abis A Ater Gb Lb BTS-TC
X X ?

MFS-BTS in TDM
MFS-BSC PMU-PTU MFS-BTS in IP mode
mode

O&M:
To be filled in by O&M experts
Abis-O&M BSC-O&M TC-O&M MFS-O&M Q3
X X

List of impacted SYT step 2 documents:

- Ciphering procedure
- Handover Management
- Classmark Handling
- External Channel Changes
- Internal Channel Changes
- DTM Functional Specification
- BTP
- BSC counters catalogue
- Layer 3 A interface dictionary
- Layer 3 Abis interface dictionary
- Layer 3 Air interface dictionary
- Application Document

List of impacted OSY step 2 documents:

- PM file format
- Software maintenance

ED 01 Released Support of A5/3 ciphering algorithm

0097_01.doc 3BK 10204 0097 DTZZA 45/48

03/07/2007
 - BSC – OMC MIB
- OMC SW/HW File format
All Rights Reserved © Alcatel-Lucent

- Abis O&M interface (OML)

- Migration
- BOP
- Traffic Model
- Initialisation & Maintenance (IMO)

ED 01 Released Support of A5/3 ciphering algorithm

0097_01.doc 3BK 10204 0097 DTZZA 46/48

03/07/2007
All Rights Reserved © Alcatel-Lucent

7 GLOSSARY

7.1 Abbreviations
Give the definition of each abbreviation used in the present document.

7.2 Terminology
Give, when necessary an unambiguous definition of terms and concepts used in the present document.
Reference to standards is allowed.

ED 01 Released Support of A5/3 ciphering algorithm

0097_01.doc 3BK 10204 0097 DTZZA 47/48

03/07/2007
All Rights Reserved © Alcatel-Lucent

8 ANNEX A: 3GPP STANDARD REMINDER

This annex should give an overview of all the features that are defined in the 3GPP standard and that could
meet the functional requirements expressed in the input MFD/RFD(s).

END OF DOCUMENT

ED 01 Released Support of A5/3 ciphering algorithm

0097_01.doc 3BK 10204 0097 DTZZA 48/48

03/07/2007