GSR9 FR34420 Architecture Description v0.5 BCCH-CCCH

1
Motorola Confidential Restricted
2 ____________________________________________________________________________________________________
1
2
3
4
5
GSM/UMTS Engineering GSR9

FR34420 A5/1 Security Hardening - Dummy Byte Randomisation
Architecture Description
6
7
8
9
10
11
12
13
14
15
16
18
19
20
21
Author(s)
Yonggang Liu
Abstract: This document describes the architectural changes that are required for the GSR9 release with the
introduction of FR34420 A5/1 security hardening dummy byte randomisation.
Document ID: GSD-GSR9-SE-AD-063

Version: 0.54
Date: 1631tsth Dec 2008releas1elease
Status: Review
3____________________________________________________________________________________________________
4Document ID: GSD-GSR9-SE-AD-063
5
Document Version: 1.0

1
2__________________________________________________________________________________________________
1
2 Distribution List
3
Motorola Swindon
System Engineering
Crane Edward-edcrane1 (GSR9 IS

originator)
Wang Jing-JINWANG1 (PM)
Bhatoolaul David-DBHATOO1 (Algorithm)
Khamnian Mohammed Sadeq-MKHAMNI1
(FR34422)
Kalachev Anton-QAK006 (GSR10)
Product Management
Connelly Russell J-QSWI1414

Ramsden Jason-jramsde1
Customer Systems Introduction and Support
Bond Peter-QSWI267
Saraiva Cristina-ACS002C
TIPS
Tomes Greg-GRTOMES1
Motorola Beijing
System Engineering
Liu Yonggang-a19236 (FR34420)

Wang Jun-W22666 (FR34420)
Wu Jing-W22231 (FR34421)
BSS Development
Li MingChu-QCH1427 (Manager)
Liu TuanBin-W21969 (Lead)
Zou Yu-WTNJ64 (CP)
ZHAO HAI-YANG-DWC834 (CM)
Wang Cheng-W22307 (OM)
Qiu Youshen-Q16456 (RSS)
He Xu.Zhong-W21952 (RSS)
GUO LI-JUAN-XVGC47 (RSS)
Firmware Development
Guo Fei-PRBF47
System Test
Cong May-QCH1389 (Test Lead)

Huang Gary-a17646 (Test Lead)
3____________________________________________________________________________________________________
5
6

Release date: <mm-dd-yyyy>
Page 2 of 41
2__________________________________________________________________________________________________
Cui LinZheng-W22145
Liu Bing-Q16458
OSS SV&V
Zhao Carol-qch1910 (SV&V Manager)

Tang Zhao-W22213
Xie Mingjun-TFV863
Motorola Hangzou
Firmware Development
LIAO Jynn-MTX678
Motorola India
Datagen Development
Kumar Gupta Mukesh-A14605 (OSSD

Manager)
Krishnan Shrikant-a22762
3
4
5
6 DOCUMENT SIGN OFF LIST
7
Role
Product Management
Name
Date
Signature
ConnellyRussellJQSWI1414
GSM/UMTS Engineering Liu TuanBin-W21969

Develop
Engineering
(BSS side)
GSM/UMTS Engineering Krishnan Shrikant-a22762
Develop
Engineering
(DataGen side)
System Integration Test Huang Gary-a17646
Group
GSM/UMTS Engineering Tang Zhao-W22213
Develop
Engineering
(V&V team)
3____________________________________________________________________________________________________
5
6

Page 3 of 41
2__________________________________________________________________________________________________
Customer
Systems
Introductions and Support
Saraiva Cristina-ACS002C
1
2 References
3[1] FR34420 Impact Statement: http://fr-database.gtss.mot.com/Feature/FR_Search/fr_display.asp?Key=34420
6[4] 3GPP TS 44.006 v6.7.0 http://www.3gpp.org/ftp/Specs/html-info/44006.htm (Mobile Station - Base Stations
7 System (MS - BSS) interface Data Link (DL) layer specification)
8[5] 3GPP TS 44.018 v6.23.0 http://www.3gpp.org/ftp/Specs/html-info/44018.htm (Mobile radio interface layer 3
9 specification; Radio Resource Control (RRC) protocol)
10[6] 3GPP TS 45.002 v6.12.0 http://www.3gpp.org/ftp/Specs/html-info/45002.htm (Multiplexing and multiple
11
access on the radio path)
12
13 Document Revision History
14
15
Version Date
Author
Contributors Change Tracker
Description
0.1
02nd Dec 2008
Yonggang Liu
0.2
05th Dec 2008
Yonggang Liu
0.3
09th Dec 2008
Yonggang Liu
0.4
16th Dec 2008
Yonggang Liu
0.5
31st Dec 2008
Yonggang Liu
Bhatoolaul
DavidDBHATOO1
1.0
SR MOTCM01125405
CR MOTCM01125409
SR MOTCM01125405
CR MOTCM01125409
SR MOTCM01125405
CR MOTCM01125409
SR MOTCM01125405
CR MOTCM01125409
SR MOTCM01125405
CR MOTCM01125409
SR MOTCM01125405
CR MOTCM01125409
Original Draft
Revise after review with
RSS/FW DEV and IST
Update
after
formal
inspection
Update
supported
platform and random
algorithm
Support randomization for
BCCH, and CCCH
16
17
18 Glossary of Terms & Acronyms
19
3GPP
AD
BSC
BSS
BTS
CM
CPU
CRA
CS
The 3rd Generation Partnership Project

Architecture Description
Base Site Controller
Base Station System
BaseTransceiverStation
ConfigurationManagement
CentralProcessingUnit
Critical Resource Analysis
Circuit Switched
3____________________________________________________________________________________________________
5
6

Page 4 of 41
2__________________________________________________________________________________________________
CTU
CTU2
CTU2D
DCML
EPG
FACCH
FIM
GGLG
GSD
GSM
GSR
LAPDm
LAU
LC
MGTS
MIPS
MIT
MOL
MS
MSC
O&M
OAM
OMC
OMC-R
OSS
PCU
RDB
ROAM
RSS
RXCDR
SACCH
SDCCH
SGSN
SITG
SMS
TCH
URC
VQ
Compact Transceiver Unit

Compact Transceiver Unit 2
Compact Transceiver Unit 2 double
Document Configuration Management Library
Equipment Planning Guide
Fast Associated Control Channel
Feature Interaction Matrix
GSM Systems Division
Global System for Mobile communications
Generic Software Release
Link Access Procedure on the Dm channel [4]
Location Area Update
Large Configuration
Message Generation Test System
Million Instructions pr second
Management Information Tree
Maintenance On Line
Mobile Station
MobileSwitchingCenter
Operations and Maintenance
Operations and Maintenance
Operations and Maintenance Center
Operations and Maintenance Center Radio
OperationsSubSystem
Packet Control Unit
Requirements Database
Reliability,Operability,Availability,Maintainability
Radio SubSystem
RemoteTranscoder
SlowAssociatedControlChannel
StandaloneDedicatedControlChannel
ServingGPRSSupportNode
SystemIntegrationTestGroup
ShortMessageService
TrafficChannel
Upgrade Rollback and Compatibility
Voice Quality
1
2
3____________________________________________________________________________________________________
5
6

Page 5 of 41
2__________________________________________________________________________________________________
1
2 Table of Contents
3DISTRIBUTION LIST...............................................................................................................................................................2
4DOCUMENT SIGN OFF LIST.................................................................................................................................................3
5REFERENCES............................................................................................................................................................................4
6DOCUMENT REVISION HISTORY.......................................................................................................................................4
7GLOSSARY OF TERMS & ACRONYMS...............................................................................................................................4
8TABLE OF CONTENTS............................................................................................................................................................6
9LIST OF TABLES.......................................................................................................................................................................7
10LIST OF FIGURES.....................................................................................................................................................................7
111
INTRODUCTION...............................................................................................................................................................8
122
FEATURE OVERVIEW.....................................................................................................................................................8
13
14
15
16
17
18
19
20
21
2.1
CUSTOMER REQUIREMENTS...........................................................................................................................................8
2.2
FEATURE DESCRIPTION..................................................................................................................................................8
2.2.1
Assumptions & Dependencies...............................................................................................................................9
2.2.2
Feature Implementation........................................................................................................................................9
2.2.3
Feature interaction.............................................................................................................................................17
2.2.4
Behaviours..........................................................................................................................................................18
2.2.5
Impacts on EPG..................................................................................................................................................22
2.2.6
Impacts on Critical Resources............................................................................................................................22
2.2.7
Impacts on other customer documentations.......................................................................................................23
223
REQUIREMENTS TO BE COVERED BY THIS ARCHITECTURE DESCRIPTION...........................................23
234
ARCHITECTURE DESCRIPTION & ALLOCATION....................................................................................................24
24
25
26
27
28
29
30
31
32
33
34
35
36
4.1
L1 ARCHITECTURE DESCRIPTION................................................................................................................................24
4.1.1
L2 Components...................................................................................................................................................24
4.1.2
L2 External Interfaces.........................................................................................................................................24
4.2
L2 ARCHITECTURE DESCRIPTION................................................................................................................................24
4.2.1
BSS L3 Components............................................................................................................................................24
4.2.2
BSS L3 External interfaces.................................................................................................................................25
4.2.3
OSS L3 Components...........................................................................................................................................25
4.2.4
OSS L3 External interfaces.................................................................................................................................26
4.3
L4/L5 ARCHITECTURE DESCRIPTION...........................................................................................................................26
4.3.1
BSC Component..................................................................................................................................................26
4.3.2
BTS Component..................................................................................................................................................26
4.3.3
OMC-R Component............................................................................................................................................27
4.3.4
DataGen Component..........................................................................................................................................27
375
TESTABILITY....................................................................................................................................................................27
3____________________________________________________________________________________________________
5
6

Page 6 of 41
2__________________________________________________________________________________________________
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
206
5.1
IMPACTS ON TEST TOOL..............................................................................................................................................27
5.1.1
MGTS..................................................................................................................................................................27
5.1.2
BAT/QBAT...........................................................................................................................................................27
5.1.3
GGLG..................................................................................................................................................................27
5.1.4
GAILG.................................................................................................................................................................28
5.1.5
VQ test tools........................................................................................................................................................28
5.1.6
OSS test tools......................................................................................................................................................28
5.1.7
Other tools..........................................................................................................................................................28
5.2
TEST STRATEGY...........................................................................................................................................................28
5.2.1
SITG....................................................................................................................................................................28
5.2.2
Perf......................................................................................................................................................................28
5.2.3
LC........................................................................................................................................................................29
5.2.4
VQ.......................................................................................................................................................................29
5.2.5
URC.....................................................................................................................................................................29
5.2.6
EPG.....................................................................................................................................................................29
5.2.7
CRA.....................................................................................................................................................................29
5.2.8
ROAM.................................................................................................................................................................29
5.2.9
Integration test with OMC-R..............................................................................................................................29
5.3
TEST LIMITATIONS.......................................................................................................................................................30
FUTURE ENHANCEMENTS..........................................................................................................................................30
21
22
24
25 List of Tables
26
27
28
29
30
31
TABLE 1 CHANNEL, REGULAR SERVICE AND LAPDM FRAME...........................................................................................11

TABLE 2 SUPPORT CABINETS...............................................................................................................................................13
TABLE 3 EXECUTION OF RANDOMIZATION..........................................................................................................................14
TABLE 4 BSS PARAMETERS DEFINITION.............................................................................................................................17
TABLE 5 BSS/OSSD REQUIREMENT MODULES IN DOORS...............................................................................................24
TABLE 6 BSS/DATAGEN LEVEL 4 REQUIREMENT MODULES IN DOORS...........................................................................26
32
34
35 List of Figures
36
37
38
39
40
41
FIGURE 1 SACCH BLOCK WITH FORMAT B4......................................................................................................................12

FIGURE 2 FORMAT A OR B...................................................................................................................................................12
FIGURE 3 LOCATION UPDATING: SUCCESSFUL CASE............................................................................................................19
FIGURE 4 MOBILE ORIGINATING CALL ESTABLISHMENT WITH SDCCH..............................................................................20
FIGURE 5 MOBILE ORIGINATING CALL ESTABLISHMENT WITH TCH IN SIGNAL ONLY MODE..............................................21
FIGURE 6 MO CALL WITH FR34420 AND FR34421 ENABLED............................................................................................22
42
43
3____________________________________________________________________________________________________
5
6

Page 7 of 41
2__________________________________________________________________________________________________
10
11
12
13 1 Introduction
14
15This document contains the requirements and architecture considerations for the introduction of FR34420: A5/1
16Security Hardening - Dummy Byte Randomisation into GSR9. The intent of this document is to provide a clear
17and understandable description of the feature for the customer, developer, or any other audience, who desires
18insight into its scope. In following chapters, the feature or this feature indicates FR34420 if not stated
19explicitly.
20
21The content of this document is categorized into the following sections:
22
1. Introduction: General document description.
23
2. Features Overview: Describes feature functionality.
24
3. Requirements to be covered by this Architecture Description: Provide links to modules of DOORS
25
L1~L3 Requirements.
26
4. Architecture Description & Allocation: Presents architecture of each level and allocation to lower
27
level
28
5. Testability: Outline the high level strategy to verify compliance to requirements and consequently how
29
tools need to be updated.
30
6. Future Enhancements: This section captures those future enhancement opportunities.
31
32 2 Feature Overview
33
34 2.1 Customer Requirements
35A5/1 is a stream cipher used to provide over-the-air communication privacy in the GSM standard. It was initially
36kept secret, but became public knowledge through leaks and reverse engineering. A number of serious weaknesses
37in the cipher have been identified. The hack community may be at a point to replicate the public decryption in
38A5/1. Then it would be feasible to record calls of typical length and decrypt its content in a reasonable timeframe
39(even real-time), with basic equipment.
40
41The security flaw could be mitigated through the application of some workarounds that can be implemented in
42current networks: Fill bits randomization, Immediate SDCCH handover and Periodic Traffic Handover.
43
44FR34420 addresses the fill bits randomization procedure applied on downlink LAPDm frame in order to reduce
45the amount of predictable information in downlink messaging. The less predictable bits that are sent drastically
46reduce the probability of a hacker finding a solution. The feature does not require new hardware for customer and
47end user. The end user will get benefits of increasing security for voice calls and SMSs without quality
48degradation.
50
51 2.2
Feature Description
52
3____________________________________________________________________________________________________
5
6

Page 8 of 41
2__________________________________________________________________________________________________
12.2.1 Assumptions & Dependencies
2A5/1 Security Hardening feature bundle contains FR34420 Randomization dummy byte, FR34421 - Immediate
3SDCCH Handover and FR34422 - Periodic Traffic Handover. The feature bundle is optional as one solution and is
4allowed to be unrestricted only if A5/1 encryption support feature is unrestricted. As in GSR9 the feature is
5supported at the BSS only, there is no OMC-R impact. Platform supported is limited to CTU, CTU2 and CTU2D
6radios, which are equipped in following cabinets: Horizon macro, Horizon II macro, Horizon II mini and Horizon
7II micro (equipped as master or expansion cabinets of any other cabinet types, refer 2.2.2.3.4)..
9
102.2.2
Feature Implementation
15
162.2.2.1
Standards Compliance and Inter-operability
32
332.2.2.2
Overview
43
442.2.2.3
Functions of the feature
17This feature is compliant with 3GPP TS44.006 v6.7.0 [4] which approves CR #0023 Randomizing fill bits in L2
18message according to TSG DOC #GP-081417.
19
20Refer from TS44.006 v6.7.0 [4] section 5.2, each fill bit SHOULD be set to a random value when sent by the
21network. Otherwise, the network shall set octets containing fill bits to the binary value "00101011". Here
22SHOULD is used to specify the network behavior. So the fill bits randomization is not must-be behavior for
23network, but a recommendation. In this feature, the fill bits randomization is applied to LAPDm frame transmitted
24on downlink channels: ONLY when downlink transmission is encrypted with A5/1 algorithm. BCCH, CCCH
25(PCH, AGCH and CBCH) and DCCH (SDCCH, SACCH and FACCH). See section 2.2.2.3.4 for reason on this
26choice.
27
28The fill bit(s) is not the useful part of the LAPDm frame . [4 section 5.2]. The value of fill bit(s) has no meaning
29to receiver. Hence, to set fill bit(s) to a random value has no impact on the compatibility of mobile station and air
30interface. See section 2.2.2.2.3 for more information.
34This feature is optional feature in GSR9. 2 BSS parameters are provided to customer. One is used to enable or
35disable fill bits randomization for BCCH and CCCH (PCH, AGCH and CBCH) signaling phase messages.
36Another one is used to enable or disable fill bits randomization for downlink DCCH (SDCCH, SACCH and
37FACCH)traffic phase messages. The fill bits randomization action is executed on CTU, CTU2 and CTU2D radios,
38which are equipped in following cabinets: Horizon macro, Horizon II macro, Horizon II mini and Horizon II
39micro (equipped as master or expansion cabinets of any other cabinet types, refer 2.2.2.3.4). The randomized fill
40bits must only be transmitted after A5/1 encryption is activated.
41
45
462.2.2.3.1 Option Solution
47The 3 A5/1 Security Hardening features (FR34420/34421/34422) are bundled as one solution. The feature bundle
48is required to be optional and controlled by only one BSS option (a51hardenOpt).
49
50The feature bundle depends on A5/1 encryption support feature and is allowed to be unrestricted only if A5/1
51encryption support feature is unrestricted.
52
3____________________________________________________________________________________________________
5
6

Page 9 of 41
2__________________________________________________________________________________________________
1MIT file is forbidden changing in order to avoid impact on OMC-R in GSR9 MOL releases because this is a
2feature in MOL stage. Hence, the BSS option is invisible on OMC-R. Only BSS and DataGen can access this
3option.
4
5BSS release notes needs to clarify that in GSR9 the option is not visible at OMC-R.
6
72.2.2.3.2 Database Parameters Solution
82 BSS parameters are provided to customer. One is used to enable or disable fill bits randomization for signaling
9phaseBCCH and CCCH messages. Another one is used to enable or disable fill bits randomization for traffic
10phasedownlink DCCH messages.
11
12MIT file is forbidden changing in order to avoid impact on OMC-R in GSR9 MOL releases. The scratchpad
13variables are the solution for the 2 BSS parameters. In the current GSR9, there are only 2 BSS level scratchpad
14variables remained: _bss_data,3 and _bss_data,4. If each of the 2 BSS parameters occupies one BSS level
15scratchpad variable per legacy method, the BSS level scratchpad variables will be used up on GSR9 after this
16feature. Subsequently, it will be difficult to deal with request for supporting new BSS parameter on GSR9 release
17in future.
18
19In fact, _bss_data,3 and _bss_data,4 are BYTE type variable, so there are total 16 bits un-used. To support the 2
20BSS parameters in this feature, 2 bits are enough to satisfy their purposes; each parameter uses one bit. Hence, the
21following mechanism is introduced in this feature:
22 1. In order to release 16 un-used bits from _bss_data,3 and _bss_data,4, these 2 BSS scratchpad variables
23
are not longer supported on GSR9. On BSS side, MMI shall reject disp_element and chg_element
24
operations on these 2 BSS scratchpad variables. On DataGen side, no change is need because these 2 BSS
25
scratchpad variables are un-used and are not supported on DataGen yet.
26 2. A mapping table is created in BSS CM and MMI to translate alias name to the bit(s) of these 2 BSS
27
scratchpad variables. The alias name can be used as a normal BSS parameter. On BSS side, MMI shall
28
support chg_element alias name <value> 0 and disp_element alias name <value> 0. On DataGen
29
side, the correct MMI command shall be re-generated based on value of these 16 bits.
30 3. This mechanism shall always be effective in GSR9 releases since it is implemented. Therefore, it does not
31
depend on A5/1 Security Hardening feature bundle option. So, the later features can introduce new BSS
32
parameters in this way until all the bits are used up or remained bit(s) are not enough to meet request.
33 4. For the BSS parameters produced in this way, their dependency is defined in the feature which introduces
34
them. For example, the 2 BSS parameters introduced by the current feature (FR34420) are only allowed
35
to be changed when A5/1 Security Hardening feature bundle is unrestricted.
36
37In this feature, 2 of 16 bits are used. The other 14 bits are not used. See section 2.2.2.5 for details of 2 new
38introduced BSS parameters.
39Alias name lapdm_fb_rand_s represents BSS parameter used to enable/disable fill bits randomization for
40signaling phase messages. Alias name lapdm_fb_rand_t represents BSS parameter used to enable/disable fill bits
41randomization for traffic phase messages. They are only allowed to be changed when A5/1 Security Hardening
42feature bundle is unrestricted. They are type 2 database parameters and BTS RSS processes shall be notified of
43new value once value is changed. Their allowed value is 0 or 1. lapdm_fb_rand_s uses bit 1 of _bss_data,3 and
44lapdm_fb_rand_t uses bit 2 of _bss_data,3. Below is the bit map of scratchpad variable _bss_data,3. Bit 1 is the
45lowest bit.
3____________________________________________________________________________________________________
5
6

Page 10 of 41
2__________________________________________________________________________________________________
Bit
1
22.2.2.3.3 LAPDm Frame and Channels
3The purpose of this feature is to randomize the fill bits in downlink LAPDm frame.
4
5In this feature scope, the randomization is applied in downlink direction LAPDm frame conveyed on BCCH,
6CCCH (PCH, AGCH and CBCH) and DCCH (SDCCH, SACCH and FACCH).
7
8DCCH channels may convey services: SMSs, CS call and Location update, etc.
9
10Table below illustrates the regular services on the channels and related LAPDm frame format.
11
121
Downlink channel
BCCH
CCCH (PCH,AGCH,CBCH)
SAPI
0
Services
System broadcasting message
Paging message
Access grant message
Cell broadcasting message
Call setup messages
Location Update. Etc
LAPDm Frame Format

Bbis, A
Bbis, A, B
SDCCH
SACCH associated with

SDCCH/TCH
SYSTEM INFORMATION TYPE 5, 6 and

optionally 5bis and 5ter messages [5]
B4
FACCH
same as SDCCH with SAPI 0
A, B, Bter
SDCCH
SACCH associated with TCH
3
3
SMSs
SMSs
B
B
A, B, Bter
Table 1 Channel, Regular Service and LAPDm Frame
13
14The length of each LAPDm frame is fixed, if the contents information is not enough to fill the frame, fill bits is
15used to fill the room. The fill bit(s) is NOT the useful part of the frame. [4 section 5.2]. Hence, the receiver does
16not care the value of the fill bit(s).
17
18In periods where no other frames are scheduled for transmission and something must be sent on the radio path, a
19fill frame shall be sent. Fill frame uses Format A. [4 section 8.4.2.3]. On receipt of a fill frame, it shall be ignored.
20[4 section 8.3.3]
21
22Error: Reference source not found1 below is summary of LAPDm frame Format (A, B4, B, Bter) and channels in
23this feature scope.
24
Type of channel
SDCCH
SDCCH
SACCH associated with SDCCH
FACCH
SAPI = 0
Unacknowledged
Acknowledged
Unacknowledged
Unacknowledged
Unacknowledged
A
X
X
B4
B
X
X
Bter
X
X
X
X
3____________________________________________________________________________________________________
5
6

Page 11 of 41
2__________________________________________________________________________________________________
FACCH
Acknowledged
Type of channel
SDCCH
SAPI = 3
Acknowledged
Acknowledged
B4
B
X
X
Bter
Length(octet)
1
1
1
A
X
X
X
B4
X
X
B
X
X
X
X
X
Bter
Address Field
Control Field
Length Indicator Field
Informaiton Field
Fill bits
X
X
Table 2 LAPDm frame Type and Channels
2
3Format A is used on DCCH for frames where there is no information field. It contains fill bits, Format A frame
4also be called fill frame. Format B may contain fill bits. B4 and Bter type frame does not contain any fill bits.
5Refer 3GPP TS 44.006 [4] for details of frame structure. Figure 1 below shows SACCH block with Format B4
6structure. Figure 2 below shows Format A and B structure.
7
8
Spare
SRO
6
5
4
3
2
FPC
EPC
Ordered MS power level
Ordered timing advance (0--63)
Address field (Layer 2)
Control field (Layer 2)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
19 octets information (Layer 2)
23
3____________________________________________________________________________________________________
5
6

Page 12 of 41
2__________________________________________________________________________________________________
1
3
Figure 1 SACCH block with Format B4
2
8
5
4
Address field (Layer 2)
Control field (Layer 2)
Length field (Layer 2)
1
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
The length field indicates whether or not has fill bit(s)

Format B type: 20 octets = information
Format B type: 20 octets = information + fill bit(s)
Format A type: 20 octets = fill bit(s)
Figure 2 Format A or B
4
52.2.2.3.4 Supported Platform
6Platform supporting this feature is limited to: CTU, CTU2 and CTU2D, which are equipped in following cabinets:
7Horizon macro, Horizon II macro, Horizon II mini and Horizon II micro (equipped as master or expansion
8cabinets of any other cabinet types, refer below table).
9
Cabinet
Standalone M-Cell
Standalone Horizon Macro
Standalone H II/H II mini/H II micro
Master M-Cell
Master Horizon Macro
Master H II/H II mini/H II micro
Slave M-Cell
Slave Horizon Macro
Slave H II/H II mini/H II micro
Support or not
No
Support
Support
No
Support
Support
No
Support
Support
3____________________________________________________________________________________________________
5
6

Page 13 of 41
2__________________________________________________________________________________________________
15
Table 3 Support cabinets
2
3The decision stems from following considerations:
4 The capability of radio The randomization is run in radio. The better randomization algorithm, the more
5
CPU resource consumed and the better on security. Hence, the radio scope is limited to CTU, CTU2 and
6
CTU2D because these are the best of current radios in CPU capability.
7 It is better that this feature is fully supported at cabinet level. This will make configuration easy and
8
expectation result is predicable. TCUA, TCUB and CTU2m can be equipped in MCell cabinet. TCUA
9
and TCUB do not support the randomization while CTU2m, which uses the same code as CTU2, can
10
support randomization. Hence, the cabinets are limited to Horizon macro, Horizon II macro, Horizon II
11
mini and Horizon II micro to avoid such case. Based on this, this feature is forbidden on CTU2m.
12
13The channel (SDCCH or TCH) used in the communication, might be change due to handover. Hence, the radio
14supporting the channel is possible to change. With end user environment change, channel may be changed
15between the supported radios and non-supported ones.
16
17
182.2.2.3.5 Fill Bits Randomization
19The fill bits randomization is to set fill bits in downlink LAPDm frame to a random value. Random value is
20defined in 3GPP TS 44.018 [5]. In the case the fill bits are not randomized, the fixed binary value 00101011
21(0x2B) is used for fill bits, as per legacy. See section 2.2.2.4 for details of randomization algorithm.
22
23Fill bits randomization is a Layer 2 internal action on LAPDm frame. It has no impact on interface between layer:
24L1 <> L2 and L2 <> L3.
25
26There are 43 factors impact on the execution of randomization:
27
A5/1 encryption is activated or not,
28
Messages are signal phase message/traffic phase message or others,
29
Value of lapdm_fb_rand_s and lapdm_fb_rand_t,
30
The supported platform.
31
32At least two different methods shall be applied to determine the fill bits. Refer table below:
33 Legacy (0x2B): not randomize, use legacy behaviour. Fill the fill bits with 0x2B.
34 PN9+PN18: In this case, the BTS shall use PN9 and PN18 pseudo random Linear Feedback Shift
35
Register (LSFR) algorithm. See section 2.2.2.4 for details of the algorithm.
36 Other: In these cases, the randomization method shall be different with PN9+PN18. The methods are
37
decided by development.
38
Downlink BCCH and
CCCH
lapdm_fb_rand_s = 0
lapdm_fb_rand_s = 1
lapdm_fb_rand_t = 0
legacy (0x2B)
Other
N/A
Downlink DCCH
without A5/1
Encryption
N/A
N/A
legacy (0x2B)
Downlink DCCH with

A5/1 Encryption
N/A
N/A
legacy (0x2B)
3____________________________________________________________________________________________________
5
6

Page 14 of 41
2__________________________________________________________________________________________________
lapdm_fb_rand_t = 1
16
N/A
Other
PN9+PN18
Table 4 Execution of randomization
2
3The reason of using at least 2 different random algorithms is Fill bits randomization is not specified as mandatory
4requirement for network [4 - section 5.2]. This feature chooses to apply randomization ONLY when downlink
5transmission is encrypted with A5/1 algorithm based on following considerations:
6
TheOne aim of randomization is to improve security of A5/1 in this feature.
7
The security is provided by encryption but not randomization. No encryption, no security.
8
No any improvement on security when randomization is applied without encryption. Randomization,
9
which reduces the predictable bits, just increases security when transmission is encrypted.
10
No encryption, no security. In the case marked as Other in above table, the transmission may be
11
without encryption (BCCH and CCCH are always transmitted without encryption), so that random
12
algorithm is easier to be cracked. Hence, it is to harden A5/1 security to use a different algorithm in the
13
case PN9+PN18. At the meanwhile, PN9+PN18 method can provide good random property within
14
capability of the supported platform.
15
Security will be downgraded if randomization is applied in all time. In this case, it will be much easier to
16
crack randomization algorithm in the duration the transmission is not encrypted. As long as the
17
randomization algorithm is cracked, the randomized fill bits become same predictable as they are filled
18
with legacy value (0x2B). Randomization will be no value to security.
19
So the correct countermeasure is to use randomization only when downlink transmission is encrypted.
20
The purpose of this feature is to hardening A5/1 algorithm security. Hence, this feature is effective only
21
when A5/1 encryption is activated.
22
In the case marked as Other in above table, it is enough to set fill bits to a random value, no other
23
limitation. RSS and Firmware process can choose the proper and simple method for it to meet this aim.
24
For example: using library function rand() to generate random value.
25
26Filter by this rule, only DCCH is applicable to be randomized because the CCCH group, including
27BCCH, is always transmitted without encryption.
28
29In this feature scope, the randomization is applied in downlink direction LAPDm frame conveyed on SDCCH,
30SACCH associated with SDCCH, FACCH and SACCH associated with TCH.
31
32Signal phase message mentioned in this document is message transmitted on downlink:
33
SDCCH,
34
SACCH associated with SDCCH,
35
FACCH while the channel mode of its associated TCH is in signalling only mode,
36
SACCH associated with TCH, while the channel mode of its associated TCH is in signalling only mode.
37
38Traffic phase message mentioned in this document is message transmitted on downlink:
39
FACCH, while channel mode of its associated TCH is NOT in signalling only mode.
40
SACCH associated with TCH, while channel mode of its associated TCH is NOT in signalling only
41
mode
42
3____________________________________________________________________________________________________
5
6

Page 15 of 41
2__________________________________________________________________________________________________
1These channels may convey services: SMSs, CS call and Location update, etc. However, there is not exact
2mapping between services and phase. For example: normally the SMSs are transmitted on SDCCH, and here
3messages belong to signal phase messages; if the SMSs transmitted during a call, it is transmitted on SACCH
4associated with TCH, so in this case messages belongs to traffic phase messages. Same case applies to Location
5update. For CS call, refer section 2.2.4, flow chart shows the phases in call life time.
6
7Table below illustrates the regular services on the channels for a quick reference.
87
Downlink channel
SDCCH
SAPI
0
Services
Call setup messages
Location Update. Etc
SACCH associated with

SDCCH/TCH
SYSTEM INFORMATION TYPE 5, 6 and

optionally 5bis and 5ter messages [5]
FACCH when associated TCH in

signal only mode
same as SDCCH with SAPI 0
FACCH when associated TCH is

NOT in signal only mode
handover messages. etc
SDCCH
3
3
SMSs
SMSs
Table 5 DCCH and regular services
9
10lapdm_fb_rand_s is used to enable or disable fill bits randomization for signaling phase messages.
11lapdm_fb_rand_t is used to enable or disable fill bits randomization for traffic phase messages. These 2 BSS level
12parameters are provided to operator to control this feature in real time. RSS is notified once value is changed, and
13then RSS notifies Firmware. In this way randomization can be performed on-demand.
14
17cabinets of any other cabinet types, refer below table).
18
Standalone M-Cell
Standalone Horizon Macro
Standalone H II/H II mini/H II
micro
Master M-Cell
Master Horizon Macro
Master H II/H II mini/H II
micro
Slave M-Cell
Slave Horizon Macro
Slave H II/H II mini/H II micro
198
No
Support
Support
No
Support
Support
No
Support
Support
Table 6 Support cabinets
20
21The decision stems from following considerations:
3____________________________________________________________________________________________________
5
6

Page 16 of 41
2__________________________________________________________________________________________________
1 The capability of radio The randomization is run in radio. The better randomization algorithm, the more
2
CPU resource consumed and the better on security. Hence, the radio scope is limited to CTU, CTU2 and
3
CTU2D because these are the best of current radios in CPU capability.
4 It is better that this feature is fully supported at cabinet level. This will make configuration easy and
5
expectation result is predicable. TCUA, TCUB and CTU2m can be equipped in MCell cabinet. TCUA
6
and TCUB do not support the randomization while CTU2m, which uses the same code as CTU2, can
7
support randomization. Subsequently the feature is partially supported in MCell when such cabinet
8
contains CTU2m and TCUA/TCUB. Hence, the cabinets are limited to Horizon macro, Horizon II macro,
9
Horizon II mini and Horizon II micro to avoid such case. Based on this, this feature is forbidden on
10
CTU2m.
11
12The channel (SDCCH or TCH) used in the communication, might be change due to handover. Hence, the radio
13supporting the channel is possible to change. Compared with the other 3 factors, this is the most dynamical factor.
14With end user environment change, channel may be changed between the supported radios and non-supported
15ones.
16
17
19
202.2.2.4
21
Algorithm and analysis
22The main decision point is how to randomize the fill bits. The Pseudo-random number generator algorithm can
23automatically create long runs with good random properties but eventually the sequence repeats exactly (or the
24memory usage grows without bound). The algorithm needs to be sufficient; as if not complex enough will lead to
25a level of predictability and therefore raise the probability of the hacker finding a solution. This section introduces
26the PN9+PN18 algorithm used by RSS and Firmware.
27
282.2.2.4.1 Firmware fill frames PN9+PN18 algorithm
29
30Firmware is responsible to randomize fill frame. Firmware shall apply the following method to determine fill bits
31for complete fill frames.
32
33Algorithm initialisation:
34
35 Store a sequence, S1, of 511 bits created by the PN9 pseudo random Linear Feedback Shift Register
36
(LSFR) algorithm (1+x5+x9).
37
38 This S1 sequence is sampled by all fill frames needing fill bits for all calls/users.
39
40When a fill frame needs random bits then:
41
42 1. Determine a number Pos_n between 0 and 511, using 9 lsb bits generated from a PN18 pseudo random
43
Linear Feedback Shift Register algorithm (1+x11+x18) that has been shifted once.
44
45
This one PN18 generator is used for all calls/users needing fill frames.
46
3____________________________________________________________________________________________________
5
6

Page 17 of 41
2__________________________________________________________________________________________________
1 2. Use Pos_n to define the start point with sequence S1 to start sampling pseudo random bits to fill the
2
fill frame.
3
4
If Pos_n is such that the end of the sequence S1 is reached before obtaining enough fill bits
5
for the fill frame, then continue collecting bits from the beginning of sequence S1.
6
7Seeding of Pseudo Random Generators:
8
9The PN9 LSFR used to create Sequence S1, will require a non-zero seed value from the range {1, 2,, 511}
10upon initialisation. The exact value can be fixed by the appropriate CCCP FW development team, provided it is
11from this range.
12
13The PN18 LSFR used to determine Pos_n, will use a seed which is at least 9 bits long, created from the
14timestamp from the first encrypt request received from the RSS.
15
16Given the long cycle length of the PN18 generator, there is no need to reseed the algorithm once its cycle length
17has been reached.
18
192.2.2.4.2 RSS fill bits PN9+PN18 algorithm
20
21RSS is responsible to randomize fill bits for partially filled frames. RSS shall apply the following method to
22determine fill bits for partially filled frames.
23
24Algorithm initialisation:
25
26 Store a sequence, S1, of 511 bits created by the PN9 pseudo random Linear Feedback Shift Register
27
(LSFR) algorithm (1+x5+x9).
28
29 This S1 sequence is sampled by all fill frames needing fill bits for all calls/users.
30
31When a fill frame needs random bits then:
32
33 3. Determine a number Pos_n between 0 and 511, using 9 lsb bits generated from a PN18 pseudo random
34
Linear Feedback Shift Register algorithm (1+x11+x18) that has been shifted once.
35
36
This one PN18 generator is used for all calls/users needing fill frames.
37
38 4. Use Pos_n to define the start point with sequence S1 to start sampling pseudo random bits to fill the
39
fill frame.
40
41
If Pos_n is such that the end of the sequence S1 is reached before obtaining enough fill bits
42
for the fill frame, then continue collecting bits from the beginning of sequence S1.
43
44Seeding of Pseudo Random Generators:
45
3____________________________________________________________________________________________________
5
6

Page 18 of 41
2__________________________________________________________________________________________________
1The PN9 LSFR used to create Sequence S1, will require a non-zero seed value from the range {1, 2,, 511}
2upon initialisation. The exact value can be fixed by the appropriate CCCP FW development team, provided it is
3from this range.
4
5The PN18 LSFR used to determine Pos_n, will use a seed which is at least 9 bits long, created from the
6timestamp for when a DRI becomes B-U XORed with the absolute time and/or frame counter.
7
8Given the long cycle length of the PN18 generator, there is no need to reseed the algorithm once its cycle length
9has been reached.
10
12
132.2.2.5
OAM impacts
14
15This feature has no OMC-R impact.
16
17disp_element and chg_element operations on _bss_data,3 will be rejected.
18disp_element and chg_element operations on _bss_data,4 will be rejected.
19disp_options command will support A5/1 Security Hardening feature bundle option.
20
21Table below shows details of BSS parameters: lapdm_fb_rand_s and lapdm_fb_rand_t.
22
Parameter
Description
lapdm_fb_rand_s
Switch to enable/disable fill bits
randomization for signaling phaseBCCH
and CCCH (PCH, AGCH and CBCH)
messages
Min
0
Max
1
Default
0
Value Type Integer
Instance
One per BSS
Dependency Configure this element is allowed only if
A5/1 Security Hardening feature bundle is
unrestricted
Type
2
BTS [RSS] processes need to be notified
of a change of this item.
Access
Read/Write - Only BSS and DATAGEN
can access this item
Value
0 = disabled
Definition
1 = enabled
Bit
Bit 1 of _bss_data,3
Occupied
239
lapdm_fb_rand_t
Switch to enable/disable fill bits
randomization for traffic phasedownlink
DCCH (SDCCH, SACCH and FACCH)
messages
0
1
0
Integer
One per BSS
Configure this element is allowed only if
A5/1 Security Hardening feature bundle is
unrestricted
2
BTS [RSS] processes need to be notified of
a change of this item.
Read/Write - Only BSS and DATAGEN can
access this item
0 = disabled
1 = enabled
Bit 2 of _bss_data,3
Table 7 Table 8 BSS Parameters definition
24Below is the bit map of scratchpad variable _bss_data,3. Bit 1 is the lowest bit.
3____________________________________________________________________________________________________
5
6

Page 19 of 41
2__________________________________________________________________________________________________
Bit
1
2
3
6
72.2.2.6
Following need be clarified in GSR9 release notes:

1. In GSR9 the A5/1 hardening feature bundle option is not visible at OMC-R.
Operability impacts
8No impact.
10
112.2.2.7
Performance and Capacity
172.2.2.8
RA impacts
20
212.2.2.9
Design Constraints
12No impact on system capacity.

13The randomization algorithm is executed by RSS and firmware, Firmware DSP MIPS utilisation will be
14increased. See section 2.2.2.4 and 2.2.6 for details.
16
18No impact.
24cabinets of any other cabinet types, refer below table). See section 2.2.2.3.4 for details.
36
372.2.3 Feature interaction

38
39Fill bits randomization is a Layer 2 internal action on LAPDm frame. It has no directly interaction with other
40features. Followings are factors impact on the execution of randomization:
41
A5/1 encryption is activated or not,
42
Messages are conveyed on which channels: signal phase message/traffic phase message or
43
othersBCCH/CCCH (AGCH,PCH and CBCH) or downlink DCCH,
44
The supported platform.
45The other features may impact the status of the factors in run time dynamically. In fact this feature does not care
46that, it just checks the condition, if allowed, the randomization is executed; otherwise not be executed.
47
482.2.3.1
FR24620 Call Setup Time Improvement in GSM network
56
572.2.3.2
FR34421 and FR34422
49In FR24620 BSS will assign a TCH with signalling only channel mode but not SDCCH to MS during call setup.
50In this condition, messages transmitted on TCH belong to signalling phase messages, and randomization is
51controlled by BSS parameter lapdm_fb_rand_s.
52
53When call setup completes, BSS will change TCH channel mode to allow CS call traffic to transmit on the TCH.
54In this condition, messages transmitted on TCH belong to traffic phase messages, and randomization is controlled
55by BSS parameter lapdm_fb_rand_t.
58This feature together with FR34421 and FR34422 will be delivered to customer as one solution. Customer may
59prefer to enabling 3 features together in order to improve security on A5/1 encryption.
60
3____________________________________________________________________________________________________
5
6

Page 20 of 41
2__________________________________________________________________________________________________
1FR34421 will initiate a SDCCH handover immediately after A5/1 encryption is activated on downlink
2transmission, and stop downlink transmission except to send HANDOVER COMMAND before handover
3complete. See figure 6 in section 2.2.4 for a sample flows with FR34421.
4
5FR34422 will perform periodical handover after call in traffic phasesetup. Generally, it has no direct interaction
6on this feature. In this case, the handover messages belong to traffic phasedownlink DCCH messages and the
7randomization condition may be changed. For example: a call handover from supported platform to non8supported platform or vice-versa; or the A5/1encryption is not activated or supported on new channel.
14
152.2.4 Behaviours
16
17In this section, messages flow charts below illustrate the transition of the ciphering and message phaseon
18downlink DCCH, and point out which impact on whether or not the randomizationrandomization algorithm is
19executed. The running platform and BSS parameters: lapdm_fb_rand_s/ lapdm_fb_rand_t are not considered here,
20they are assumed satisfied for randomization execution. The Ciphering mode setting in flow charts are assumed
21to enable A5/1 encryption. Refer section 2.2.2.3.5 and 2.2.2.4 for randomization algorithms Other and
22PN9+PN18.
3____________________________________________________________________________________________________
5
6

Page 21 of 41
2__________________________________________________________________________________________________
1
2Figure 3 below shows the location update successful case. Messages since 1 belong to signal phase messages. The
3randomization conditions are satisfied since 2. Fill bits randomization will be executed since 2.
4
3____________________________________________________________________________________________________
5
6

Page 22 of 41
2__________________________________________________________________________________________________
3____________________________________________________________________________________________________
5
6

Page 23 of 41
2__________________________________________________________________________________________________
1
10
Figure 3 Location updating: successful case
2
3____________________________________________________________________________________________________
5
6

Page 24 of 41
2__________________________________________________________________________________________________
1
2Figure 4 below shows Mobile originating call establishment with SDCCH.. The randomization conditions are
3satisfied since 2. Messages since 1 belong to signal phase messages. Messages since 3 belong to traffic phase
4messages. The randomization conditions are satisfied since 2. Fill bits randomization will be executed since 2.
5
3____________________________________________________________________________________________________
5
6

Page 25 of 41
2__________________________________________________________________________________________________
3____________________________________________________________________________________________________
5
6

Page 26 of 41
2__________________________________________________________________________________________________
1
11
Figure 4 Mobile originating call establishment with SDCCH
3____________________________________________________________________________________________________
5
6

Page 27 of 41
2__________________________________________________________________________________________________
1
2Figure 5 below shows Mobile originating call establishment with TCH. Messages since 1 belong to signal phase
3messages. Messages since 3 belong to traffic phase messages. The randomization conditions are satisfied since 2.
4Fill bits randomization will be executed since 2. This case may appear if FR24620 Call Setup Time Improvement
5in GSM network is enabled.
6
3____________________________________________________________________________________________________
5
6

Page 28 of 41
2__________________________________________________________________________________________________
3____________________________________________________________________________________________________
5
6

Page 29 of 41
2__________________________________________________________________________________________________
1
12
Figure 5 Mobile originating call establishment with TCH in signal only mode
3____________________________________________________________________________________________________
5
6

Page 30 of 41
2__________________________________________________________________________________________________
1Figure 6 below shows Mobile originating call establishment with FR34420 enabled. Here is the description of this
2flow chart:
3 1. After point 1, the call enters into signal phase.
4 2. After point 2, downlink transmission is in A5/1 encryption.FR34421 initiates a SDCCH HO immediately
5
on old SDCCH old cell. If there are fill bits during transmitting HANDOVER COMMAND message, the
6
fill bits will be randomized.
7 3. Point 3 to 4, call handovers to new SDCCH on new cell.
8 4. After point 4, assume the new channel still support A5/1 encryption. Since this point, downlink
9
transmission still is in signal phase, randomization condition is satisfied on new SDCCH.
10 5. Call enters into traffic phase. Randomization condition is satisfied on TCH.
11
3____________________________________________________________________________________________________
5
6

Page 31 of 41
2__________________________________________________________________________________________________
3____________________________________________________________________________________________________
5
6

Page 32 of 41
2__________________________________________________________________________________________________
113
Figure 6 MO call with FR34420 and FR34421 enabled
42.2.5 Impacts on EPG

5No impact.
7
82.2.6 Impacts on Critical Resources

9
10This section summarises the CRA impacts for this feature based on the analysis for the feature. These impacts will
11be considered in the release level CRA reports for GSR9. The CRA impacts considered are Memory and CPU
12Utilisation.
13
14This section covers the CRA impacts based on analysis to date.
15
162.2.6.1 Memory
17For firmware, there is a look-up table to store the random fill bits for fill frames. The size of the table is 84bytes
18(672bits).
19
20For RSS, there is a look-up table to store the random fill bits for fill bits. The size of the table is 84bytes (672bits).
21
222.2.6.2 Radio DSP MIPS Utilisation
23The randomization algorithm is executed by RSS and firmware, and Radio CPU and Firmware DSP MIPS
24utilisation will be increased. See section 2.2.2.4 for details of random algorithm.
25
26The radio CPU utilisation increased by RSS should be very little because the code change is simple and quite
27small. Especially compared with the total code of RSS, the code change is quite small; hence the impact is very
28little.
29
30The firmware code is time sensitive, if a DSP can not complete task in required timeslot, the DRI may be reset
31with DRI alarm 29 reported.
32
33A simple pilot testing has been performed to choose the algorithm. The result shows the solution mentioned in
342.2.2.4 is affordable. The exact impacts are still to be determined. This will be further evaluated during
35development and test phase. The BTS stress and performance testing will be required to verify the impacts.
38
39
402.2.7
Impacts on other customer documentations
41
42 68P02901W17: Installation and Configuration: GSM System Configuration.

43 68P02901W23: Technical Description: BSS Command Reference
44 68P02901W36: Technical Description: BSS Implementation.
45 68P02901W72: Software Release Notes: BSS/RXCDR GSR9
46
47BSS release notes needs to clarify that in GSR9 the A5/1 hardening feature bundle option is not visible at OMC48R.
60
3____________________________________________________________________________________________________
5
6

Page 33 of 41
2__________________________________________________________________________________________________
1
2 3 Requirements to be covered by this Architecture Description

3
4DOORS (http://ecapps.mot.com/PS/site/default.aspx) is the formal requirement repository.
5The L1/L2/L3 requirements for GSR9 FR34420 are located in following DOORS areas:
6Prefix path: DOORS-7-1-Central-Server36682 -> Development -> GTSS ->
Level
L1 SYS
L2 RAN
L3
BSC/BTS
L2 OSS
L3
DataGen
714
9
10 4
11
GSD -> GSM_GPRS ->L1RS

Path
Modules
1TR_System
2TR_RAN
3TR_LegacyBSC
OSSD -> OSSD-LegacyGSM ->L2RS

OSSD -> OSSD-LegacyGSM ->L3RS -> L3-Datagen
2TR_OSSD_OSS_L2
3TR_OSSD_DG
Table 9 Table 10 BSS/OSSD Requirement Modules in DOORS
Architecture Description & Allocation
14
15 4.1 L1 Architecture Description

164.1.1 L2 Components
17
184.1.1.1
BSS
21
224.1.1.2
MSC
25
264.1.1.3
SGSN
29
304.1.1.4
MS
33
344.1.1.5
OSS (OMC-R)
19Details of impacts on BSS to support this feature can be found in section 2.2.
23No impact.
27No impact.
31No impact. See section 2.2.2.1.

35No impact.
37
384.1.2
L2 External Interfaces
404.1.2.1
MSC-BSS Interface (A-Interface)
43
444.1.2.2
SGSN-BSS interface (Gb-interface)
41No impact.
45No impact.
47
3____________________________________________________________________________________________________
5
6

Page 34 of 41
2__________________________________________________________________________________________________
14.1.2.3
BSS-MS Interface (Air Interface)
4
54.1.2.4
BSS-OSS Interface
2No impact. See section 2.2.2.1

6No impact.
8
9 4.2 L2 Architecture Description

104.2.1 BSS L3 Components
12
134.2.1.1
BSC
22
234.2.1.2
PCU
26
274.2.1.3
BTS
32
334.2.1.4
RXCDR
16
17New per BSS parameters lapdm_fb_rand_s and lapdm_fb_rand_t are introduced for the feature. Once these 2
18parameters are changed, BSC need notify BTS of the new value.
19
20BSS forbids operator accessing per BSS parameters _bss_data,3 and _bss_data,4.
24No impact.
28BTS handles the notification of lapdm_fb_rand_s and lapdm_fb_rand_t value change. RSS and Firmware
29performs random algorithm and set fill bits to random value when condition is satisfied. Details can be found in
30section 2.2.2.3.4 and 4.3.2.
34No impact.
36
374.2.2
BSS L3 External interfaces
39
404.2.2.1
RXCDR-BSC Interface
43
444.2.2.2
BSC-BTS Interface
48
494.2.2.3
PCU-BSC Interface
52
534.2.2.4
BSC-OMC/R interface
41No impact.
45BSC need notify BTS of the new value once BSS parameters lapdm_fb_rand_s and lapdm_fb_rand_t are
46changed.
50No impact.
54No impact.
56
574.2.3
584.2.3.1
OSS L3 Components
OMC-R
59No impact.
3____________________________________________________________________________________________________
5
6

Page 35 of 41
2__________________________________________________________________________________________________
1
24.2.3.2
DataGen
5
6New per BSS parameters lapdm_fb_rand_s and lapdm_fb_rand_t are introduced for the feature.
8
94.2.4 OSS L3 External interfaces

10No impact.
12
13 4.3 L4/L5 Architecture Description

14BSS Level 4 requirements will be created and defined by the BSS development teams and Datagen Level 4
15requirements will be created and defined by the Datagen development teams.
16
17These L4 requirements will be included in the DOORS modules detailed in Error: Reference source not
18foundbelow.
19
20Prefix path: DOORS-7-1-Central-Server36682 -> Development -> GTSS ->
Level
L4 BSS
L4
DataGen
2115
22
234.3.1
244.3.1.1
Path
OSSD -> OSSD-LegacyGSM ->L4RS -> L4-DataGen
Modules
4TR_GSD_DEV
4TR_OSSD_DG
Table 11 Table 12 BSS/Datagen Level 4 Requirement Modules in DOORS
BSC Component
CM
25CM is updated to support new BSS option A5/1 Security Hardening feature bundle (a51hardenOpt).
26CM is updated to support new per BSS parameters lapdm_fb_rand_s and lapdm_fb_rand_t.
27Upon the value change of lapdm_fb_rand_s, CM is updated to notify RSS of the new value.
28Upon the value change of lapdm_fb_rand_t, CM is updated to notify RSS of the new value.
29
304.3.1.2
MMI
31MMI command disp_options is updated to support new BSS option: A5/1 Security Hardening feature bundle
32(a51hardenOpt).
33MMI command chg_element and disp_element are updated to support new per BSS parameters lapdm_fb_rand_s
34and lapdm_fb_rand_t.
35MMI command chg_element and disp_element are updated to forbid operator accessing per BSS parameters
36_bss_data,3 and _bss_data,4.
37
3____________________________________________________________________________________________________
5
6

Page 36 of 41
2__________________________________________________________________________________________________
14.3.2 BTS Component
24.3.2.1
RSS
3RSS is updated to handle lapdm_fb_rand_s value change event sent from CM.
4RSS is updated to handle lapdm_fb_rand_t value change event sent from CM.
5RSS is updated to set the fill bits in downlink BCCH and CCCH (AGCH, PCH and CBCH) LAPDm frame to a
6random value on the supported platform when lapdm_fb_rand_s is enabled.ALL of the following conditions are
7satisfied: See section 2.2.2.3.5.
8 the LAPDm frame is conveyed on following downlink channels: SDCCH, SACCH associated with
9
SDCCH and TCH in signalling only channel mode.
10 the downlink transmission is encrypted with A5/1 algorithm
11
on CTU, CTU2 and CTU2D radios, which are equipped in following cabinets: Horizon macro, Horizon II
12
macro, Horizon II mini and Horizon II micro
13 lapdm_fb_rand_s is enabled
14
15RSS is updated to set the fill bits in downlink DCCH (SDCCH, SACCH and FACCH) LAPDm frame to a random
16value on the supported platform when lapdm_fb_rand_t is enabledALL of the following conditions are satisfied:.
17See section 2.2.2.3.5.
18 the LAPDm frame is conveyed on downlink FACCH or SACCH associated with TCH, the channel mode
19
of the corresponding TCH is other than signalling only
20 the downlink transmission is encrypted with A5/1 algorithm
21 on CTU, CTU2 and CTU2D radios, which are equipped in following cabinets: Horizon macro, Horizon II
22
macro, Horizon II mini and Horizon II micro
23 lapdm_fb_rand_t is enabled
24
25RSS is updated to notify firmware that whether or not the current condition is satisfied for randomization. The
26notification is only sent out when the condition takes place transition. For example: the condition is changed from
27satisfied to not satisfied for signal or traffic phaseDCCH messages and vice versa.
28
294.3.2.2
Firmware
30Firmware is updated to handle notification from RSS, which indicates whether or not the current condition is
31satisfied for randomization.
32Firmware is updated to set the fill bits in downlink LAPDm fill frame to a random value when condition is
33satisfied. The condition is same as that for RSS. See section 4.3.2.1.
34
354.3.3 OMC-R Component

36No impact.
37
384.3.4
394.3.4.1
DataGen Component
Revgen
40Revgen is updated to support new BSS option A5/1 Security Hardening feature bundle (a51hardenOpt).
3____________________________________________________________________________________________________
5
6

Page 37 of 41
2__________________________________________________________________________________________________
1Revgen is updated to support new per BSS parameters: lapdm_fb_rand_s and lapdm_fb_rand_t.
2
34.3.4.2
Gcmd
4Gcmd is updated to support new per BSS parameters: lapdm_fb_rand_s and lapdm_fb_rand_t.
5
64.3.4.3
MCDF
7MCDF is updated to support new per BSS parameters: lapdm_fb_rand_s and lapdm_fb_rand_t.
8
9
14
15 5
Testability
17
18 5.1
Impacts on Test Tool
28
295.1.1 MGTS
30No impact.
32
335.1.2 BAT/QBAT
34No impact.
35
375.1.3 GGLG
38No impact.
39
415.1.4 GAILG
42No impact.
43
455.1.5 VQ test tools

46No impact.
47
495.1.6 OSS test tools

50No impact.
52
535.1.6.1
Stater
56
575.1.6.2
Exercisor
615.1.6.3
Other OSS system test tools
54No impact.
58No impact.
60
62No impact.
64
655.1.7 Other tools

66A tool able to monitor the air link messages including layer 2 messages is required.
67RTA and TEMS are options.
3____________________________________________________________________________________________________
5
6

Page 38 of 41
2__________________________________________________________________________________________________
1
2 5.2 Test strategy

3It is able to observe that whether or not randomization is executed by checking whether or not the fill bit(s) is
4filled with the legacy value (0x2B). This is the mainly method for system test team to check the result on
5randomization. See section 5.3 for this test limitation.
6
95.2.1 SITG
10System testing is needed to verify the feature functionality and feature interactions. The testing should cover the
11following main points:
12
13 BSS option for A5/1 Security Hardening feature bundle.
14 The forbidden BSS parameters _bss_data,3 and _bss_data,4.
15 New per BSS parameters lapdm_fb_rand_s and lapdm_fb_rand_t introduced for the feature.
16 Randomization on CTU, CTU2 and CTU2D radios, which are equipped in following cabinets: Horizon
17
macro, Horizon II macro, Horizon II mini and Horizon II micro.
18 Randomization executed in procedure: SMSs, Circuit Switch domain call, Location Update.
19 Feature interactions with the following features as detailed in section Error: Reference source not found.
20
o FR24620 Call Setup Time Improvement in GSM network
21
o FR34421 A5/1 Security Hardening - Immediate SDCCH Handover
22
o FR34422 A5/1 Security Hardening - Periodic Traffic Handover
23
24
265.2.2 Perf
27The randomization algorithm is performed by RSS and Firmware when encoding Downlink LAPDm frame on
28DCCH and downlink transmission is ciphered with A5/1 algorithm. The execution of the randomization increases
29Radio CPU workload. Performance testing of the BTS is required for the feature and it is recommended that the
30BTS performance testing be carried out as early as possible. The Radio CPU workload increased is variable based
31on various factors as call model, configuration etc and it is recommended that the feature is tested using various
32call models and configurations.
33
34SMSs/Call setup phase/location updates have a high possibility to invoke the randomization algorithm. The
35duration of these services normally is short, but the whole procedure is conveyed via LAPDm frame. A large
36amount of such service reaching at a concentre time frame will result in the worst cases in a short duration.
37
38Regarding the TCH, the randomization algorithm is only possibly invoked in SACCH and FACCH. The BTS
39shall afford the workload under the peak situation of CS call.
40
425.2.3 LC
43Upon the change of lapdm_fb_rand_s and lapdm_fb_rand_t, BSC CM needs to notify the RSS process in BTS. In
44a Large configure BSC with 140 sites, BSC CM need to send 140 notification messages. LC testing is required to
45verify this scenario. The focus point is that whether or not all the BTSs get the notification.
46
47As BSS level parameters, it is obvious that customer uses them for deploying purpose. It should be stable
48configuration and will not be changed frequently.
49
3____________________________________________________________________________________________________
5
6

Page 39 of 41
2__________________________________________________________________________________________________
1
35.2.4 VQ
4No voice quality testing is required for this feature. The randomization is performed on LAPDm frame, which
5conveys only signal information. There is no impact on voice traffic data.
6
85.2.5 URC
9URC testing is required to verify the Datagen functionality for this feature including the support for the new BSS
10level parameters lapdm_fb_rand_s and lapdm_fb_rand_t.
11
135.2.6 EPG
14No EPG testing is required for this feature.
15
175.2.7 CRA
18No specific CRA testing is required for this feature as the CRA impacts for the feature will be addressed within
19the functional testing (see section Error: Reference source not found) and performance and capacity testing for the
20feature (see section Error: Reference source not found).
21
235.2.8 ROAM
24No ROAM testing is required for this feature.
25
275.2.9 Integration test with OMC-R

28No required.
30
31 5.3 Test Limitations

32The random algorithm is difficult to be verified. For the value has been randomized, it is difficult to know
33whether or not is the expectation result, because expectation is dynamically changed and difficult to be predicted.
34The method for verifying random algorithm needs further investigation.
36
37 6 Future Enhancements
38No.
47
3____________________________________________________________________________________________________
5
6

Page 40 of 40

GSR9 FR34420 Architecture Description v0.5 BCCH-CCCH

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

GSR9 FR34420 Architecture Description v0.5 BCCH-CCCH

Hochgeladen von

Copyright:

Verfügbare Formate

1

Motorola Confidential Restricted

GSM/UMTS Engineering GSR9

Document ID: GSD-GSR9-SE-AD-063

Document Version: 1.0

Motorola Confidential Restricted

Crane Edward-edcrane1 (GSR9 IS

Connelly Russell J-QSWI1414

Customer Systems Introduction and Support

Liu Yonggang-a19236 (FR34420)

Cong May-QCH1389 (Test Lead)

Document Version: 1.0

Motorola Confidential Restricted

Zhao Carol-qch1910 (SV&V Manager)

Kumar Gupta Mukesh-A14605 (OSSD

GSM/UMTS Engineering Liu TuanBin-W21969

Document Version: 1.0

Motorola Confidential Restricted

02nd Dec 2008

05th Dec 2008

09th Dec 2008

16th Dec 2008

31st Dec 2008

The 3rd Generation Partnership Project

Document Version: 1.0

Motorola Confidential Restricted

Compact Transceiver Unit

Document Version: 1.0

Motorola Confidential Restricted

REQUIREMENTS TO BE COVERED BY THIS ARCHITECTURE DESCRIPTION...........................................23

ARCHITECTURE DESCRIPTION & ALLOCATION....................................................................................................24

Document Version: 1.0

Motorola Confidential Restricted

TABLE 1 CHANNEL, REGULAR SERVICE AND LAPDM FRAME...........................................................................................11

FIGURE 1 SACCH BLOCK WITH FORMAT B4......................................................................................................................12

Document Version: 1.0

Motorola Confidential Restricted

Document Version: 1.0

Motorola Confidential Restricted

Standards Compliance and Inter-operability

Functions of the feature

Document Version: 1.0

Motorola Confidential Restricted

Document Version: 1.0

Motorola Confidential Restricted

LAPDm Frame Format

SACCH associated with

SYSTEM INFORMATION TYPE 5, 6 and

same as SDCCH with SAPI 0

Table 1 Channel, Regular Service and LAPDm Frame

Document Version: 1.0

Motorola Confidential Restricted

Table 2 LAPDm frame Type and Channels

Document Version: 1.0

Motorola Confidential Restricted

The length field indicates whether or not has fill bit(s)

Document Version: 1.0

Motorola Confidential Restricted

Table 3 Support cabinets

Downlink DCCH with

Document Version: 1.0

Motorola Confidential Restricted

Table 4 Execution of randomization

Document Version: 1.0