GSM/UMTS Engineering GSR9 A5/1 Security Hardening - Dummy Byte Randomisation Architecture Description

Motorola Confidential Restricted

____________________________________________________________________________________________________

Motorola Confidential Restricted__________________________________________________________________________________________________

GSM/UMTS Engineering GSR9

FR34420 A5/1 Security Hardening - Dummy Byte RandomisationArchitecture DescriptionAuthor(s)

Yonggang LiuAbstract: 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.5Date: 31st Dec 2008

2.2.2 Feature Implementation

< Required. Using following sub-section to provide detailed introduction of the feature, and capture critical design decisions in this section, etc. A link to CD may be added.

Please be cautious to avoid duplicating requirements in this section.

>

2.2.2.1 Standards Compliance and Inter-operabilityThis feature is compliant with 3GPP TS44.006 v6.7.0 [4] which approves CR #0023 Randomizing fill bits in L2 message according to TSG DOC #GP-081417. Refer from TS44.006 v6.7.0 [4] section 5.2, each fill bit SHOULD be set to a random value when sent by the network. Otherwise, the network shall set octets containing fill bits to the binary value "00101011". In this feature, the fill bits randomization is applied to LAPDm frame transmitted on downlink channels: BCCH, CCCH (PCH, AGCH and CBCH) and DCCH (SDCCH, SACCH and FACCH). The 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 to receiver. Hence, to set fill bit(s) to a random value has no impact on the compatibility of mobile station and air interface. See section 2.2.2.2.3 for more information.< Optional. List all specifications this feature based on if it is an application feature, etc. Before filling this section, author may need PdM or CSIS IOT team to check CS/PS CN and MS compliance status. If there is potential inter-operability issue, briefly describe here. >

2.2.2.2 OverviewThis feature is optional feature in GSR9. 2 BSS parameters are provided to customer. One is used to enable or disable fill bits randomization for BCCH and CCCH (PCH, AGCH and CBCH) messages. Another one is used to enable or disable fill bits randomization for downlink DCCH (SDCCH, SACCH and FACCH) messages. The fill bits randomization action is executed on CTU, CTU2 and CTU2D radios, which are equipped in following cabinets: Horizon macro, Horizon II macro, Horizon II mini and Horizon II micro (equipped as master or expansion cabinets of any other cabinet types, refer 2.2.2.3.4).

2.2.2.3 Functions of the feature2.2.2.3.1 Option SolutionThe 3 A5/1 Security Hardening features (FR34420/34421/34422) are bundled as one solution. The feature bundle is required to be optional and controlled by only one BSS option (a51hardenOpt). The feature bundle depends on A5/1 encryption support feature and is allowed to be unrestricted only if A5/1 encryption support feature is unrestricted.MIT file is forbidden changing in order to avoid impact on OMC-R in GSR9 MOL releases because this is a feature in MOL stage. Hence, the BSS option is invisible on OMC-R. Only BSS and DataGen can access this option.BSS release notes needs to clarify that in GSR9 the option is not visible at OMC-R.

2.2.2.3.2 Database Parameters Solution

2 BSS parameters are provided to customer. One is used to enable or disable fill bits randomization for BCCH and CCCH messages. Another one is used to enable or disable fill bits randomization for downlink DCCH messages.MIT file is forbidden changing in order to avoid impact on OMC-R in GSR9 MOL releases. The scratchpad variables are the solution for the 2 BSS parameters. In the current GSR9, there are only 2 BSS level scratchpad variables remained: _bss_data,3 and _bss_data,4. If each of the 2 BSS parameters occupies one BSS level scratchpad variable per legacy method, the BSS level scratchpad variables will be used up on GSR9 after this feature. Subsequently, it will be difficult to deal with request for supporting new BSS parameter on GSR9 release in future. In fact, _bss_data,3 and_bss_data,4 are BYTE type variable, so there are total 16 bits un-used. To support the 2 BSS parameters in this feature, 2 bits are enough to satisfy their purposes; each parameter uses one bit. Hence, the following mechanism is introduced in this feature:1. In order to release 16 un-used bits from _bss_data,3 and_bss_data,4, these 2 BSS scratchpad variables are not longer supported on GSR9. On BSS side, MMI shall reject disp_element and chg_element operations on these 2 BSS scratchpad variables. On DataGen side, no change is need because these 2 BSS scratchpad variables are un-used and are not supported on DataGen yet.2. A mapping tableis created inBSS CMandMMIto translate alias name to the bit(s) of these 2 BSS scratchpad variables. The alias name can be used as a normal BSS parameter. On BSS side, MMI shall support chg_element alias name 0 and disp_element alias name 0. On DataGen side, the correct MMI command shall be re-generated based on value of these 16 bits.3. This mechanism shall always be effective in GSR9 releases since it is implemented. Therefore, it does not depend on A5/1 Security Hardening feature bundle option. So, the later features can introduce new BSS parameters in this way until all the bits are used up or remained bit(s) are not enough to meet request.4. For the BSS parameters produced in this way, their dependency is defined in the feature which introduces them. For example, the 2 BSS parameters introduced by the current feature (FR34420) are only allowed to be changed when A5/1 Security Hardening feature bundle is unrestricted. In 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 introduced BSS parameters.

2.2.2.3.3 LAPDm Frame and ChannelsThe purpose of this feature is to randomize the fill bits in downlink LAPDm frame. In this feature scope, the randomization is applied in downlink direction LAPDm frame conveyed on BCCH, CCCH (PCH, AGCH and CBCH) and DCCH (SDCCH, SACCH and FACCH).

DCCH channels may convey services: SMSs, CS call and Location update, etc.

Table below illustrates the regular services on the channels and related LAPDm frame format.

Downlink channelSAPI ServicesLAPDm Frame Format

BCCH0System broadcasting messageBbis, A

CCCH (PCH,AGCH,CBCH)Paging message

Access grant message

Cell broadcasting messageBbis, A, B

SDCCH0Call setup messagesLocation Update. EtcA, B, Bter

SACCH associated with SDCCH/TCH0SYSTEM INFORMATION TYPE 5, 6 and optionally 5bis and 5ter messages [5]B4

FACCH0same as SDCCH with SAPI 0A, B, Bter

SDCCH3SMSsB

SACCH associated with TCH3SMSsB

1 Table 1 Channel, Regular Service and LAPDm FrameThe length of each LAPDm frame is fixed, if the contents information is not enough to fill the frame, fill bits is used to fill the room. The fill bit(s) is NOT the useful part of the frame [4 section 5.2]. Hence, the receiver does not care the value of the fill bit(s).In periods where no other frames are scheduled for transmission and something must be sent on the radio path, a fill 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. [4 section 8.3.3]

2 Format A is used for frames where there is no information field. It contains fill bits, Format A frame also be called fill frame. Format B may contain fill bits. B4 and Bter type frame does not contain any fill bits. Refer 3GPP TS 44.006 [4] for details of frame structure. Figure 1 below shows SACCH block with Format B4 structure. Figure 2 below shows Format A and B structure.

87654321

SpareSROFPC EPCOrdered MS power level1

Ordered timing advance (0--63)2

Address field (Layer 2)3

Control field (Layer 2)4

19 octets information (Layer 2)5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

3 Figure 1 SACCH block with Format B487654321

Address field (Layer 2)1

Control field (Layer 2)2

Length field (Layer 2)3

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)4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

4 Figure 2 Format A or B2.2.2.3.4 Supported PlatformPlatform supporting this feature is limited to: CTU, CTU2 and CTU2D, which are equipped in following cabinets: Horizon macro, Horizon II macro, Horizon II mini and Horizon II micro (equipped as master or expansion cabinets of any other cabinet types, refer below table).

CabinetSupport or not

Standalone M-CellNo

Standalone Horizon MacroSupport

Standalone H II/H II mini/H II microSupport

Master M-CellNo

Master Horizon MacroSupport

Master H II/H II mini/H II microSupport

Slave M-CellNo

Slave Horizon MacroSupport

Slave H II/H II mini/H II microSupport

5 Table 2 Support cabinetsThe decision stems from following considerations:

The capability of radio The randomization is run in radio. The better randomization algorithm, the more CPU resource consumed and the better on security. Hence, the radio scope is limited to CTU, CTU2 and CTU2D because these are the best of current radios in CPU capability.

It is better that this feature is fully supported at cabinet level. This will make configuration easy and expectation result is predicable. TCUA, TCUB and CTU2m can be equipped in MCell cabinet. TCUA and TCUB do not support the randomization while CTU2m, which uses the same code as CTU2, can support randomization. Hence, the cabinets are limited to Horizon macro, Horizon II macro, Horizon II mini and Horizon II micro to avoid such case. Based on this, this feature is forbidden on CTU2m.The channel (SDCCH or TCH) used in the communication, might be change due to handover. Hence, the radio supporting the channel is possible to change. With end user environment change, channel may be changed between the supported radios and non-supported ones.

2.2.2.3.5 Fill Bits Randomization

The fill bits randomization is to set fill bits in downlink LAPDm frame to a random value. Random value is defined in 3GPP TS 44.018 [5]. In the case the fill bits are not randomized, the fixed binary value 00101011 (0x2B) is used for fill bits, as per legacy. Fill bits randomization is a Layer 2 internal action on LAPDm frame. It has no impact on interface between layer: L1 L2 and L2 L3.

There are 3 factors impact on the execution of randomization:

A5/1 encryption is activated or not,

Value of lapdm_fb_rand_s and lapdm_fb_rand_t,

The supported platform.

At least two different methods shall be applied to determine the fill bits. Refer table below:

Legacy (0x2B): not randomize, use legacy behaviour. Fill the fill bits with 0x2B.

PN9+PN18: In this case, the BTS shall use PN9 and PN18 pseudo random Linear Feedback Shift Register (LSFR) algorithm. See section 2.2.2.4 for details of the algorithm. Other: In these cases, the randomization method shall be different with PN9+PN18. The methods are decided by development.

Downlink BCCH and CCCHDownlink DCCH without A5/1 EncryptionDownlink DCCH with A5/1 Encryption

lapdm_fb_rand_s = 0legacy (0x2B)N/AN/A

lapdm_fb_rand_s = 1OtherN/AN/A

lapdm_fb_rand_t = 0N/Alegacy (0x2B)legacy (0x2B)

lapdm_fb_rand_t = 1N/AOtherPN9+PN18

Table 3 Execution of randomizationThe reason of using at least 2 different random algorithms is based on following considerations: One aim of randomization is to improve security of A5/1 in this feature. The security is provided by encryption but not randomization. Randomization, which reduces the predictable bits, just increases security when transmission is encrypted. No encryption, no security. In the case marked as Other in above table, the transmission may be without encryption (BCCH and CCCH are always transmitted without encryption), so that random algorithm is easier to be cracked. Hence, it is to harden A5/1 security to use a different algorithm in the case PN9+PN18. At the meanwhile, PN9+PN18 method can provide good random property within capability of the supported platform. In the case marked as Other in above table, it is enough to set fill bits to a random value, no other limitation. RSS and Firmware process can choose the proper and simple method for it to meet this aim. For example: using library function rand() to generate random value.

6

7

2.2.2.4 Algorithm and analysis

The main decision point is how to randomize the fill bits. The Pseudo-random number generator algorithm can automatically create long runs with good random properties but eventually the sequence repeats exactly (or the memory usage grows without bound). The algorithm needs to be sufficient; as if not complex enough will lead to a level of predictability and therefore raise the probability of the hacker finding a solution. This section introduces the PN9+PN18 algorithm used by RSS and Firmware.2.2.2.4.1 Firmware fill frames PN9+PN18 algorithm

Firmware is responsible to randomize fill frame. Firmware shall apply the following method to determine fill bits for complete fill frames.

Algorithm initialisation:

Store a sequence, S1, of 511 bits created by the PN9 pseudo random Linear Feedback Shift Register (LSFR) algorithm (1+x5+x9).

This S1 sequence is sampled by all fill frames needing fill bits for all calls/users.

When a fill frame needs random bits then:

1. Determine a number Pos_n between 0 and 511, using 9 lsb bits generated from a PN18 pseudo random Linear Feedback Shift Register algorithm (1+x11+x18) that has been shifted once.

This one PN18 generator is used for all calls/users needing fill frames.

2. Use Pos_n to define the start point with sequence S1 to start sampling pseudo random bits to fill the fill frame.

If Pos_n is such that the end of the sequence S1 is reached before obtaining enough fill bits for the fill frame, then continue collecting bits from the beginning of sequence S1.

Seeding of Pseudo Random Generators:

The PN9 LSFR used to create Sequence S1, will require a non-zero seed value from the range {1, 2,, 511} upon initialisation. The exact value can be fixed by the appropriate CCCP FW development team, provided it is from this range.

The PN18 LSFR used to determine Pos_n, will use a seed which is at least 9 bits long, created from the timestamp from the first encrypt request received from the RSS. Given the long cycle length of the PN18 generator, there is no need to reseed the algorithm once its cycle length has been reached.

2.2.2.4.2 RSS fill bits PN9+PN18 algorithm

RSS is responsible to randomize fill bits for partially filled frames. RSS shall apply the following method to determine fill bits for partially filled frames.

Algorithm initialisation:

Store a sequence, S1, of 511 bits created by the PN9 pseudo random Linear Feedback Shift Register (LSFR) algorithm (1+x5+x9).

This S1 sequence is sampled by all fill frames needing fill bits for all calls/users.

When a fill frame needs random bits then:

3. Determine a number Pos_n between 0 and 511, using 9 lsb bits generated from a PN18 pseudo random Linear Feedback Shift Register algorithm (1+x11+x18) that has been shifted once.

This one PN18 generator is used for all calls/users needing fill frames.

4. Use Pos_n to define the start point with sequence S1 to start sampling pseudo random bits to fill the fill frame.

If Pos_n is such that the end of the sequence S1 is reached before obtaining enough fill bits for the fill frame, then continue collecting bits from the beginning of sequence S1.

Seeding of Pseudo Random Generators:

The PN9 LSFR used to create Sequence S1, will require a non-zero seed value from the range {1, 2,, 511} upon initialisation. The exact value can be fixed by the appropriate CCCP FW development team, provided it is from this range.

The PN18 LSFR used to determine Pos_n, will use a seed which is at least 9 bits long, created from the timestamp for when a DRI becomes B-U XORed with the absolute time and/or frame counter.

Given the long cycle length of the PN18 generator, there is no need to reseed the algorithm once its cycle length has been reached.

2.2.2.5 OAM impactsThis feature has no OMC-R impact.

disp_element and chg_element operations on _bss_data,3 will be rejected.disp_element and chg_element operations on _bss_data,4 will be rejected.

disp_options command will support A5/1 Security Hardening feature bundle option.

Table below shows details of BSS parameters: lapdm_fb_rand_s and lapdm_fb_rand_t.

Parameterlapdm_fb_rand_slapdm_fb_rand_t

DescriptionSwitch to enable/disable fill bits randomization for BCCH and CCCH (PCH, AGCH and CBCH) messagesSwitch to enable/disable fill bits randomization for downlink DCCH (SDCCH, SACCH and FACCH) messages

Min00

Max11

Default00

Value TypeIntegerInteger

InstanceOne per BSSOne per BSS

DependencyConfigure this element is allowed only if A5/1 Security Hardening feature bundle is unrestrictedConfigure this element is allowed only if A5/1 Security Hardening feature bundle is unrestricted

Type2

BTS [RSS] processes need to be notified of a change of this item.2

BTS [RSS] processes need to be notified of a change of this item.

AccessRead/Write - Only BSS and DATAGEN can access this itemRead/Write - Only BSS and DATAGEN can access this item

Value Definition0 = disabled

1 = enabled0 = disabled

1 = enabled

Bit OccupiedBit 1 of _bss_data,3Bit 2 of _bss_data,3

8 Table 4 BSS Parameters definitionBelow is the bit map of scratchpad variable _bss_data,3. Bit 1 is the lowest bit. Bit87654321

9 Following need be clarified in GSR9 release notes:

1. In GSR9 the A5/1 hardening feature bundle option is not visible at OMC-R.

2.2.2.6 Operability impactsNo impact.

2.2.2.7 Performance and Capacity

No impact on system capacity.

The randomization algorithm is executed by RSS and firmware, Firmware DSP MIPS utilisation will be increased. See section 2.2.2.4 and 2.2.6 for details.< Optional. If the feature has impacts on system capacity, performance and key stats and KPI, briefly describe in this section from concerned perspectives, etc. >

2.2.2.8 RA impactsNo impact.< Optional. If the feature has impacts on system reliability and availability, briefly describe in this section, etc. >

2.2.2.9 Design Constraints

See section 2.2.2.3.4 for details.

2.2.3 Feature interaction

Fill bits randomization is a Layer 2 internal action on LAPDm frame. It has no directly interaction with other features. Followings are factors impact on the execution of randomization:

A5/1 encryption is activated or not,

Messages are conveyed on which channels: BCCH/CCCH (AGCH,PCH and CBCH) or downlink DCCH,

The supported platform.

The other features may impact the status of the factors in run time dynamically. In fact this feature does not care that, it just checks the condition, if allowed, the randomization is executed; otherwise not be executed.2.2.3.1

2.2.3.2 FR34421 and FR34422This feature together with FR34421 and FR34422 will be delivered to customer as one solution. Customer may prefer to enabling 3 features together in order to improve security on A5/1 encryption. FR34421 will initiate a SDCCH handover immediately after A5/1 encryption is activated on downlink transmission, and stop downlink transmission except to send HANDOVER COMMAND before handover complete. See figure 6 in section 2.2.4 for a sample flows with FR34421.FR34422 will perform periodical handover after call setup. Generally, it has no direct interaction on this feature. In this case, the handover messages belong to downlink DCCH messages and the randomization condition may be changed. For example: a call handover from supported platform to non-supported platform or vice-versa; or the A5/1encryption is not activated or supported on new channel.

2.2.4 Behaviours

In this section, messages flow charts below illustrate the transition of the ciphering and message on downlink DCCH, and point out which randomization algorithm is executed. The running platform and BSS parameters: lapdm_fb_rand_s/ lapdm_fb_rand_t are assumed satisfied for randomization execution. The Ciphering mode setting in flow charts are assumed to enable A5/1 encryption. Refer section 2.2.2.3.5 and 2.2.2.4 for randomization algorithms Other and PN9+PN18. Figure 3 below shows the location update successful case.

10 Figure 3 Location updating: successful caseFigure 4 below shows Mobile originating call establishment with SDCCH.

11 Figure 4 Mobile originating call establishment with SDCCHFigure 5 below shows Mobile originating call establishment with TCH. This case may appear if FR24620 Call Setup Time Improvement in GSM network is enabled.

12 Figure 5 Mobile originating call establishment with TCH in signal only modeFigure 6 below shows Mobile originating call establishment with FR34420 enabled. 1. 2. 3. 4. 5.

13 Figure 6 MO call with FR34420 and FR34421 enabled

2.2.5 Impacts on EPGNo impact.< Optional. If the feature has impacts on EPG, briefly describe impacts in this section, etc. >

2.2.6 Impacts on Critical Resources

This section summarises the CRA impacts for this feature based on the analysis for the feature. These impacts will be considered in the release level CRA reports for GSR9. The CRA impacts considered are Memory and CPU Utilisation.

This section covers the CRA impacts based on analysis to date.

2.2.6.1 Memory

For firmware, there is a look-up table to store the random fill bits for fill frames. The size of the table is 84bytes (672bits).

For RSS, there is a look-up table to store the random fill bits for fill bits. The size of the table is 84bytes (672bits).

2.2.6.2 Radio DSP MIPS Utilisation

The randomization algorithm is executed by RSS and firmware, and Radio CPU and Firmware DSP MIPS utilisation will be increased. See section 2.2.2.4 for details of random algorithm.The radio CPU utilisation increased by RSS should be very little because the code change is simple and quite small. Especially compared with the total code of RSS, the code change is quite small; hence the impact is very little.

The firmware code is time sensitive, if a DSP can not complete task in required timeslot, the DRI may be reset with DRI alarm 29 reported.

A simple pilot testing has been performed to choose the algorithm. The result shows the solution mentioned in 2.2.2.4 is affordable. The exact impacts are still to be determined. This will be further evaluated during development and test phase. The BTS stress and performance testing will be required to verify the impacts.

< Optional. If the feature has impacts on critical resources, such as increased CPU utilization by some algorithms or increased memory usage, briefly describe impacts in this section, etc. In this section, author provides impacts estimation after discussing with CRA SME. >

2.2.7 Impacts on other customer documentations 68P02901W17: Installation and Configuration: GSM System Configuration.

68P02901W23: Technical Description: BSS Command Reference

68P02901W36: Technical Description: BSS Implementation. 68P02901W72: Software Release Notes: BSS/RXCDR GSR9BSS release notes needs to clarify that in GSR9 the A5/1 hardening feature bundle option is not visible at OMC-R.< Requires. List all customer documents that need to be updated for this feature, including following but not limited to following documents.,

68P02901W01: System Information- GSM Overview

68P02901W17: Installation and Configuration: GSM System Configuration68P02901W23: Technical Description: BSS Command Reference

68P02901W26: Maintenance Information: Alarm handling at the OMC-R

68P02901W36: Technical Description: BSS Implementation

68P02901W56: Maintenance Information: GSM Statistics Application68P02901W58: Maintenance Information: BSS Timers

68P02901W72:Software Release Notes: BSS/RXCDR

68P02901W73: Software Release Notes: Northbound Interface (NBI)

>

3 Requirements to be covered by this Architecture Description

DOORS (http://ecapps.mot.com/PS/site/default.aspx) is the formal requirement repository.

The L1/L2/L3 requirements for GSR9 FR34420 are located in following DOORS areas:

Prefix path: DOORS-7-1-Central-Server36682 -> Development -> GTSS ->LevelPathModules

L1 SYSGSD -> GSM_GPRS ->L1RS1TR_System

L2 RANGSD -> GSM_GPRS ->L2RS2TR_RAN

L3 BSC/BTSGSD -> GSM_GPRS ->L3RS3TR_LegacyBSC

L2 OSSOSSD -> OSSD-LegacyGSM ->L2RS2TR_OSSD_OSS_L2

L3 DataGenOSSD -> OSSD-LegacyGSM ->L3RS -> L3-Datagen3TR_OSSD_DG

14 Table 5 BSS/OSSD Requirement Modules in DOORS< Required. Provide links to modules of DOORS L1~L4 Requirements, all algorithm documents and impacted EISs. In order to minimize effort to update AD every time when there is requirement update, it is suggested not to populated requirements exported from DOORS in this section. >

4 Architecture Description & Allocation

< Required. This is expected to be a list of the sub-systems architecture (next level of decomposition) required to decompose the indicated requirements. >

4.1 L1 Architecture Description

4.1.1 L2 Components

4.1.1.1 BSSDetails of impacts on BSS to support this feature can be found in section 2.2.< Optional. Briefly decompose functions to this NE if applicable >

4.1.1.2 MSCNo impact.< Optional. Briefly decompose functions to this NE if applicable >

4.1.1.3 SGSNNo impact.< Optional. Briefly decompose functions to this NE if applicable >

4.1.1.4 MS No impact. See section 2.2.2.1.< Optional. Briefly decompose functions to this NE if applicable >

4.1.1.5 OSS (OMC-R)No impact.< Optional. Briefly decompose functions to this NE if applicable >

4.1.2 L2 External Interfaces

< Optional. If there is any new/updated external messages on A interface, Gb interface or air interfaces, list them in following sub-sections and highlight what are new/updated. >

4.1.2.1 MSC-BSS Interface (A-Interface)No impact.< Optional. Briefly decompose functions to this interface if applicable >

4.1.2.2 SGSN-BSS interface (Gb-interface)No impact.< Optional. Briefly decompose functions to this interface if applicable >

4.1.2.3 BSS-MS Interface (Air Interface)No impact. See section 2.2.2.1< Optional. Briefly decompose functions to this interface if applicable >

4.1.2.4 BSS-OSS InterfaceNo impact.< Optional. Briefly decompose functions to this interface if applicable.Or a link to 4.2.2.4 is OK >

4.2 L2 Architecture Description4.2.1 BSS L3 Components

< Optional. Briefly decompose functions to lower level entity if applicable >

4.2.1.1 BSCThe 3 A5/1 Security Hardening features (FR34420/34421/34422) are bundled as one solution. The feature bundle is required to be optional and controlled by only one BSS option (a51hardenOpt).New per BSS parameters lapdm_fb_rand_s and lapdm_fb_rand_t are introduced for the feature. Once these 2 parameters are changed, BSC need notify BTS of the new value. BSS forbids operator accessing per BSS parameters _bss_data,3 and _bss_data,4.

< Optional. Briefly decompose functions to this NE if applicable >

4.2.1.2 PCUNo impact.< Optional. Briefly decompose functions to this NE if applicable >

4.2.1.3 BTSBTS handles the notification of lapdm_fb_rand_s and lapdm_fb_rand_t value change. RSS and Firmware performs random algorithm and set fill bits to random value when condition is satisfied. Details can be found in section 2.2.2.3 and 4.3.2.< Optional. Briefly decompose functions to this NE if applicable >

4.2.1.4 RXCDRNo impact.< Optional. Briefly decompose functions to this NE if applicable >

4.2.2 BSS L3 External interfaces

< Optional. Briefly decompose functions to interfaces between lower level entities if applicable >

4.2.2.1 RXCDR-BSC Interface No impact.< Optional. Briefly decompose functions to this interface if applicable >

4.2.2.2 BSC-BTS InterfaceBSC need notify BTS of the new value once BSS parameters lapdm_fb_rand_s and lapdm_fb_rand_t are changed.< Optional. Briefly decompose functions to this interface if applicable >

4.2.2.3 PCU-BSC Interface No impact.< Optional. Briefly decompose functions to this interface if applicable >

4.2.2.4 BSC-OMC/R interfaceNo impact.< Optional. Briefly decompose functions to this interface if applicable >

4.2.3 OSS L3 Components

4.2.3.1 OMC-RNo impact.< Optional. Briefly decompose functions to this NE if applicable >

4.2.3.2 DataGenThe 3 A5/1 Security Hardening features (FR34420/34421/34422) are bundled as one solution. The feature bundle is required to be optional and controlled by only one BSS option (a51hardenOpt).

New per BSS parameters lapdm_fb_rand_s and lapdm_fb_rand_t are introduced for the feature.< Optional. Briefly decompose functions to this NE if applicable >

4.2.4 OSS L3 External interfacesNo impact.< Optional. Briefly decompose functions to interfaces between lower level entities if applicable Since BSC-OMC/R interface described in previous section, there is no need to duplicate here.>

4.3 L4/L5 Architecture DescriptionBSS Level 4 requirements will be created and defined by the BSS development teams and Datagen Level 4 requirements will be created and defined by the Datagen development teams.

These L4 requirements will be included in the DOORS modules detailed in Table below. Prefix path: DOORS-7-1-Central-Server36682 -> Development -> GTSS ->LevelPathModules

L4 BSSGSD -> GSM_GPRS ->L4RS4TR_GSD_DEV

L4 DataGenOSSD -> OSSD-LegacyGSM ->L4RS -> L4-DataGen

4TR_OSSD_DG

15 Table 6 BSS/Datagen Level 4 Requirement Modules in DOORS

4.3.1 BSC Component

4.3.1.1 CM

CM is updated to support new BSS option A5/1 Security Hardening feature bundle (a51hardenOpt). CM is updated to support new per BSS parameters lapdm_fb_rand_s and lapdm_fb_rand_t. Upon the value change of lapdm_fb_rand_s, CM is updated to notify RSS of the new value.Upon the value change of lapdm_fb_rand_t, CM is updated to notify RSS of the new value.4.3.1.2 MMI

MMI command disp_options is updated to support new BSS option: A5/1 Security Hardening feature bundle (a51hardenOpt).MMI command chg_element and disp_element are updated to support new per BSS parameters lapdm_fb_rand_s and lapdm_fb_rand_t.MMI command chg_element and disp_element are updated to forbid operator accessing per BSS parameters _bss_data,3 and _bss_data,4.4.3.2 BTS Component

4.3.2.1 RSS

RSS is updated to handle lapdm_fb_rand_s value change event sent from CM.RSS is updated to handle lapdm_fb_rand_t value change event sent from CM.

RSS is updated to set the fill bits in downlink BCCH and CCCH (AGCH, PCH and CBCH) LAPDm frame to a random value on the supported platform when lapdm_fb_rand_s is enabled. See section 2.2.2.3.5. RSS is updated to set the fill bits in downlink DCCH (SDCCH, SACCH and FACCH) LAPDm frame to a random value on the supported platform when lapdm_fb_rand_t is enabled. See section 2.2.2.3.5. RSS is updated to notify firmware that whether or not the current condition is satisfied for randomization. The notification is only sent out when the condition takes place transition. For example: the condition is changed from satisfied to not satisfied for DCCH messages and vice versa.

4.3.2.2 Firmware

Firmware is updated to handle notification from RSS, which indicates whether or not the current condition is satisfied for randomization.Firmware is updated to set the fill bits in downlink LAPDm fill frame to a random value when condition is satisfied. The condition is same as that for RSS. See section 4.3.2.1.4.3.3 OMC-R Component

No impact.4.3.4 DataGen Component

4.3.4.1 Revgen

Revgen is updated to support new BSS option A5/1 Security Hardening feature bundle (a51hardenOpt). Revgen is updated to support new per BSS parameters: lapdm_fb_rand_s and lapdm_fb_rand_t. 4.3.4.2 Gcmd

Gcmd is updated to support new per BSS parameters: lapdm_fb_rand_s and lapdm_fb_rand_t. 4.3.4.3 MCDF

MCDF is updated to support new per BSS parameters: lapdm_fb_rand_s and lapdm_fb_rand_t. < Required. Describe features impacts on SW FA (L4) or processes (L5) or even to function level (L6) by briefly describing what are new/updated on SW FAs or processes. Detailed allocation information will be covered by the requirements format exported from DOORS, which shows allocate to info. Include a reference link to feature impacts on sub-functions spreadsheet. GSR9 matrix is at: http://compass.mot.com/go/202249928. A folder will be created for GSR10.

>

5 Testability < This section is expected to outline the high level strategy to verify compliance to requirements and consequently how tools need to be updated to support verification of new requirements. >

5.1 Impacts on Test Tool < Required. Analysis impacts on system test tools from system function and test point of view for following tools,

MGTS

BAT/QBAT

GGLG

GAILG

VQ test tools

OSS Test tools, including stater and exercisor Other tools

. >

5.1.1 MGTSNo impact.< Optional. Briefly describe impacts on this tool if applicable >

5.1.2 BAT/QBATNo impact.

< Optional. Briefly describe impacts on this tool if applicable >

5.1.3 GGLGNo impact.

< Optional. Briefly describe impacts on this tool if applicable >

5.1.4 GAILGNo impact.

< Optional. Briefly describe impacts on this tool if applicable >

5.1.5 VQ test toolsNo impact.

< Optional. Briefly describe impacts on this tool if applicable >

5.1.6 OSS test toolsNo impact.< Optional. AD author briefly describe impacts on OSS system test tools with support from OSS test team if applicable >

5.1.6.1 StaterNo impact.< Optional. Briefly describe impacts on this tool if applicable. Tool design document can be found at: http://dcmlweb.cig.mot.com/cgi-bin/main.cgi?Action=ViewAll&Location=/OSS/GSR8/OSS_DEV/HLD/006. >

5.1.6.2 ExercisorNo impact.< Optional. Briefly describe impacts on this tool if applicable >

5.1.6.3 Other OSS system test toolsNo impact.< Optional. Briefly describe impacts on other OSS test tools if applicable >

5.1.7 Other toolsA tool able to monitor the air link messages including layer 2 messages is required.RTA and TEMS are options.< Optional. Briefly describe impacts on other tools if not described above >

5.2 Test strategyIt is able to observe that whether or not randomization is executed by checking whether or not the fill bit(s) is filled with the legacy value (0x2B). This is the mainly method for system test team to check the result on randomization. See section 5.3 for this test limitation.

< Required. Briefly describe system test strategy for following aspects, Following sub-sections are applicable for a feature having both RAN/BSS and OSS impacts. For OMC-R feature, section 5.2.1 to 5.2.9 can be replaced by OSS specific test strategy guidelines. >. >

5.2.1 SITGSystem testing is needed to verify the feature functionality and feature interactions. The testing should cover the following main points:

BSS option for A5/1 Security Hardening feature bundle. The forbidden BSS parameters _bss_data,3 and _bss_data,4.

New per BSS parameters lapdm_fb_rand_s and lapdm_fb_rand_t introduced for the feature.

Randomization on CTU, CTU2 and CTU2D radios, which are equipped in following cabinets: Horizon macro, Horizon II macro, Horizon II mini and Horizon II micro. Randomization executed in procedure: SMSs, Circuit Switch domain call, Location Update.

Feature interactions with the following features as detailed in section 2.2.3. FR34421 A5/1 Security Hardening - Immediate SDCCH Handover FR34422 A5/1 Security Hardening - Periodic Traffic Handover< Optional. Briefly describe SITG test strategy, e.g., call load, test configuration, and feature combination, etc >

5.2.2 PerfThe randomization algorithm is performed by RSS and Firmware when encoding Downlink LAPDm frame on DCCH and downlink transmission is ciphered with A5/1 algorithm. The execution of the randomization increases Radio CPU workload. Performance testing of the BTS is required for the feature and it is recommended that the BTS performance testing be carried out as early as possible. The Radio CPU workload increased is variable based on various factors as call model, configuration etc and it is recommended that the feature is tested using various call models and configurations.

SMSs/Call setup phase/location updates have a high possibility to invoke the randomization algorithm. The duration of these services normally is short, but the whole procedure is conveyed via LAPDm frame. A large amount of such service reaching at a concentre time frame will result in the worst cases in a short duration. Regarding the TCH, the randomization algorithm is only possibly invoked in SACCH and FACCH. The BTS shall afford the workload under the peak situation of CS call.< Optional. Briefly describe perf test strategy, e.g., call load, test configuration, and tools used etc >

5.2.3 LCUpon the change of lapdm_fb_rand_s and lapdm_fb_rand_t,BSC CM needs to notify the RSS process in BTS. In a Large configure BSC with 140 sites, BSC CM need to send 140 notification messages. LC testing is required to verify this scenario. The focus point is that whether or not all the BTSs get the notification.As BSS level parameters, it is obvious that customer uses them for deploying purpose. It should be stable configuration and will not be changed frequently.

< Optional. Briefly describe LC test strategy, e.g., call load, test configuration, and feature combination, etc >

5.2.4 VQNo voice quality testing is required for this feature. The randomization is performed on LAPDm frame, which conveys only signal information. There is no impact on voice traffic data.< Optional. Briefly describe VQ test strategy, e.g., call load, test configuration, etc >

5.2.5 URCURC testing is required to verify the Datagen functionality for this feature including the support for the new BSS level parameters lapdm_fb_rand_s and lapdm_fb_rand_t.

< Optional. Briefly describe URC test strategy, e.g., call load, test configuration, etc >

5.2.6 EPGNo EPG testing is required for this feature.

< Optional. Briefly describe EPG test strategy, e.g., call load, test configuration, feature combinations, etc >

5.2.7 CRANo specific CRA testing is required for this feature as the CRA impacts for the feature will be addressed within the functional testing (see section 5.2.1) and performance and capacity testing for the feature (see section 5.2.2).

< Optional. Briefly describe CRA test strategy, e.g., call load, test configuration, etc >

5.2.8 ROAMNo ROAM testing is required for this feature.< Optional. Briefly describe ROAM test strategy from RA perspective and OAM perspective, e.g., call load, test configuration, etc >

5.2.9 Integration test with OMC-RNo required.

< Optional. Briefly describe test strategy where real OMC-R is needed>

5.3 Test LimitationsThe random algorithm is difficult to be verified. For the value has been randomized, it is difficult to know whether or not is the expectation result, because expectation is dynamically changed and difficult to be predicted. The method for verifying random algorithm needs further investigation.< Optional. Briefly discuss areas may not be tested due to test limitations, etc. >

6 Future Enhancements No.

< Optional. This section captures those future enhancement opportunities what cant be implemented in current release due to various reasons like:

Technical complexity

No Market needs

Time-to market pressure

Etc

For each enhancement, describe what are issues the enhancement can resolve, and how the enhancement resolve the issue, provide pros and cons for the solution, and provide reasons why the enhancement is not supported in current release.

Unlike update to other sections, update to this section does not need SR/CR since not product change is needed. Author can choose to update this section when there is need to change other sections.

>

____________________________________________________________________________________________________

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

Document Version: 1.0

1____________________________________________________________________________________________________

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

Document Version: 1.0

Release date:

Page 3 of 30