Radio Security

eRAN
Radio Security Feature Parameter

Description
Issue 01
Date 2014-04-26
HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2014. All rights reserved.
No part of this document may be reproduced or transmitted in any form or by any means without prior written
consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions
and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and the
customer. All or part of the products, services and features described in this document may not be within the
purchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information,
and recommendations in this document are provided "AS IS" without warranties, guarantees or representations
of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute a warranty of any kind, express or implied.
Huawei Technologies Co., Ltd.

Address: Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website: http://www.huawei.com
Email: support@huawei.com
Issue 01 (2014-04-26) Huawei Proprietary and Confidential i

Copyright © Huawei Technologies Co., Ltd.
eRAN
Radio Security Feature Parameter Description Contents
Contents
1 About This Document..................................................................................................................1

1.1 Scope..............................................................................................................................................................................1
1.2 Intended Audience..........................................................................................................................................................1
1.3 Change History...............................................................................................................................................................2
1.4 Differences Between eNodeB Types..............................................................................................................................3
2 Overview.........................................................................................................................................4
2.1 Introduction....................................................................................................................................................................4
2.2 Architecture....................................................................................................................................................................4
3 Radio Security................................................................................................................................6
3.1 Security Measures...........................................................................................................................................................7
3.1.1 Integrity Protection......................................................................................................................................................7
3.1.2 Ciphering.....................................................................................................................................................................9
3.2 Key Derivation.............................................................................................................................................................13
3.3 Activation and Change of the Security Mode..............................................................................................................14
3.3.1 Initial Security Activation Procedure........................................................................................................................14
3.3.2 Security Handling During Handovers.......................................................................................................................16
4 Related Features...........................................................................................................................19
4.1 LBFD-002004 Integrity Protection..............................................................................................................................19
4.2 LOFD-00101001 Encryption: AES..............................................................................................................................19
4.3 LOFD-00101002 Encryption: SNOW 3G....................................................................................................................20
4.4 LOFD-00101003 Encryption: ZUC..............................................................................................................................20
5 Network Impact...........................................................................................................................21
5.1 LBFD-002004 Integrity Protection..............................................................................................................................21
5.2 LOFD-00101001 Encryption: AES..............................................................................................................................21
5.3 LOFD-00101002 Encryption: SNOW 3G....................................................................................................................21
5.4 LOFD-00101003 Encryption: ZUC..............................................................................................................................22
6 Engineering Guidelines.............................................................................................................23
6.1 When to Use Radio Security........................................................................................................................................24
6.2 Required Information...................................................................................................................................................24
6.3 Network Planning.........................................................................................................................................................24
Issue 01 (2014-04-26) Huawei Proprietary and Confidential ii

eRAN
Radio Security Feature Parameter Description Contents
6.4 Deployment..................................................................................................................................................................24
6.4.1 Requirements.............................................................................................................................................................24
6.4.2 Data Preparation........................................................................................................................................................25
6.4.3 Initial Configuration..................................................................................................................................................29
6.4.4 Activation Observation..............................................................................................................................................32
6.4.5 Reconfiguration.........................................................................................................................................................32
6.4.6 Deactivation...............................................................................................................................................................33
6.5 Performance Monitoring...............................................................................................................................................34
6.6 Parameter Optimization................................................................................................................................................34
6.7 Troubleshooting............................................................................................................................................................34
7 Parameters.....................................................................................................................................36
8 Counters........................................................................................................................................40
9 Glossary.........................................................................................................................................41
10 Reference Documents...............................................................................................................42
Issue 01 (2014-04-26) Huawei Proprietary and Confidential iii

eRAN
Radio Security Feature Parameter Description 1 About This Document
1 About This Document
1.1 Scope
This document describes security measures on the radio interface, including its technical
principles, related features, network impact, and engineering guidelines.
This document covers the following features:
l LBFD-002004 Integrity Protection
l LOFD-001010 Security Mechanism
−LOFD-00101001 Encryption: AES
−LOFD-00101002 Encryption: SNOW 3G
−LOFD-00101003 Encryption: ZUC
This document applies to the following types of eNodeBs.
eNodeB Type Model
Macro 3900 series eNodeB
Micro BTS3202E and BTS3203E
LampSite DBS3900
Any managed objects (MOs), parameters, alarms, or counters described herein correspond to
the software release delivered with this document. Any future updates will be described in the
product documentation delivered with future software releases.
This document applies only to LTE FDD. Any "LTE" in this document refers to LTE FDD, and
"eNodeB" refers to LTE FDD eNodeB.
1.2 Intended Audience

This document is intended for personnel who:
Issue 01 (2014-04-26) Huawei Proprietary and Confidential 1

eRAN
l Need to understand the features described herein

l Work with Huawei products
1.3 Change History

This section provides information about the changes in different document versions. There are
two types of changes:
l Feature change
Changes in features and parameters of a specified version as well as the affected entities
l Editorial change
Changes in wording or addition of information and any related parameters affected by
editorial changes. Editorial change does not specify the affected entities.
eRAN7.0 01 (2014-04-26)
This issue does not include any changes.
eRAN7.0 Draft B (2014-03-07)

This issue includes the following changes.
Chang Change Description Parameter Affected Entity

e Type Change
Feature None None N/A

change
Editoria Added 1.4 Differences Between None N/A

l change eNodeB Types, which describes
differences in feature support
between eNodeB types.
eRAN7.0 Draft A (2014-01-20)

Compared with Issue 02 (2013-08-30) of eRAN6.0, Draft A (2014-01-20) of eRAN7.0 includes
the following changes.
Change Change Description Parameter Change

Type
Feature Changed the name of Huawei mobile element None

change management system from M2000 to U2000.
Editorial Modified the setting notes for parameters related None

change to the integrity protection algorithms and
ciphering algorithms. For details, see 6.4.2 Data
Preparation.

eRAN
1.4 Differences Between eNodeB Types

The features described in this document are implemented in the same way on macro, micro, and
LampSite eNodeBs.

eRAN
Radio Security Feature Parameter Description 2 Overview
2 Overview
2.1 Introduction
Radio security enhances integrity and confidentiality of messages over the radio interface
between each eNodeB and UE. eNodeBs support the following radio security measures:
l Integrity protection: The sender and receiver involved in a transmission use an integrity
protection algorithm to compute the message authentication code for integrity (MAC-I)
and expected MAC-I (X-MAC), respectively. The receiver compares the two values. If the
value of the computed X-MAC is the same as that of the received MAC-I, the message
passes the integrity verification. This prevents modification of information.
l Ciphering: Ciphering algorithms convert information from plaintext to ciphertext to prevent
disclosure of information.
eNodeBs perform integrity protection and ciphering at the Packet Data Convergence Protocol
(PDCP) layer. As important inputs to integrity protection and ciphering algorithms, integrity
keys and cipher keys are derived by both UEs and eNodeBs to prevent disclosure of the keys,
which may occur if the keys are transmitted over the radio interface.
NOTE
For details about the PDCP layer, see 3GPP TS 36.323 v10.1.0.
If integrity protection and ciphering are enabled, the security mode is activated upon Radio
Resource Control (RRC) connection setup, that is, after the setup of SRB1 and before the setup
of SRB2 and data radio bearers (DRBs). SRB is short for signaling radio bearer.
Integrity protection and ciphering algorithms can be changed only during handovers. Integrity
keys and cipher keys can be changed during handovers or RRC connection reestablishment.
2.2 Architecture
Figure 2-1 shows the security architecture, which is provided in chapter 4 of 3GPP TS 33.401
v10.2.0.

eRAN
Radio Security Feature Parameter Description 2 Overview
Figure 2-1 Security architecture specified in 3GPP protocols
AN: Access Network SN: Serving Network
HE: Home Environment USIM: Universal Subscriber Identity Module
ME: Mobile Equipment
NOTE
The terms listed above are quoted from 3GPP TS 21.905 v10.3.0.
Five security feature groups are defined. Each of these feature groups faces certain threats and
accomplishes certain security objectives:
l Network access security (I): the set of security features that provide UEs with secure access
to services and in particular protect against attacks on the radio interface
l Network domain security (II): the set of security features that enable nodes to securely
exchange signaling data and user data and protect against attacks on the wireline network
l User domain security (III): the set of security features that provide secure access to UEs
l Application domain security (IV): the set of security features that enable applications in
the UE and in the provider domain to securely exchange messages
l Visibility and configurability of security (V): the set of features that enable users to inform
themselves of whether a security feature is in operation or not and whether the use and
provision of services should depend on the security feature
Radio security is a part of network access security. This document describes only the security
measures and procedures between the access network and mobile equipment.

eRAN
Radio Security Feature Parameter Description 3 Radio Security
3 Radio Security
This chapter describes two radio security measures supported by eNodeBs: integrity protection
and ciphering. It also describes the integrity and cipher key derivation processes, the initial
security activation procedure, and the security handling procedure during handovers.
For engineering guidelines, see 6 Engineering Guidelines.

eRAN
3.1 Security Measures
3.1.1 Integrity Protection

This section describes the feature LBFD-002004 Integrity Protection.
eNodeBs perform integrity protection on RRC signaling messages at the PDCP layer, as shown
in Figure 3-1. For more information, see chapter 4 in 3GPP TS 36.323 v10.1.0.
Figure 3-1 Integrity protection in PDCP entities
Integrity protection enables receiving entities (either UEs or eNodeBs) to check whether
signaling messages are modified. A sender and a receiver negotiate an integrity protection
algorithm by using RRC signaling messages.
The sender uses the negotiated integrity protection algorithm to compute a MAC-I for an RRC
signaling message based on the input parameters, including KEY, BEARER, DIRECTION,
COUNT, MESSAGE, and LENGTH. Then, the sender sends the code together with the message
to the receiver. The receiver computes the X-MAC in the same way as the sender computes
MAC-I. Then, the receiver compares the computed code with the received code.
l If the computed code differs from the received code, the receiver considers that the RRC
signaling message has been modified.

eRAN
l If the computed code is the same as the received code, the receiver considers that the RRC
signaling message passes the integrity verification.
Integrity protection must be performed on all RRC signaling messages, except those listed in
section A.6 in 3GPP TS 36.331 v10.5.0. The EIA0 algorithm (Null algorithm) is used for
integrity protection only on UEs that initiate emergency calls but fail the authentication.
Each eNodeB is configured with the parameters listed in Table 3-1 to specify the integrity
protection algorithms to be used.
Table 3-1 Parameters for integrity protection algorithms for the eNodeB
Algorithm Parameter ID Description

Priority
First ENodeBIntegrity- Each parameter can be set to one of the following

Cap.PrimaryIntegri- values:
tyAlgo l NULL(NULL Algorithm): Integrity
protection is not used.
Second ENodeBIntegrity-
Cap.SecondIntegri- l Snow3G(SNOW 3G Algorithm): The SNOW
tyAlgo 3G algorithm is used.
l AES(AES Algorithm): The AES algorithm is
Third ENodeBIntegrity- used.
Cap.ThirdIntegrityAl-
go l ZUC(ZUC Algorithm): The ZUC algorithm is
used.
These parameters must be set to different values.
Default values of the parameters are as follows:
l ENodeBIntegrityCap.PrimaryIntegrityAlgo
is set to AES(AES Algorithm) by default.
l ENodeBIntegrityCap.SecondIntegrityAlgo
is set to Snow3G(SNOW 3G Algorithm) by
default.
l ENodeBIntegrityCap.ThirdIntegrityAlgo is
set to ZUC(ZUC Algorithm) by default.
Null ENodeBIntegrity- This parameter can be set to either of the following

Cap.NullAlgo values:
l Enable(Enable NULL Algorithm): The Null
algorithm can be used.
l Disable(Disable NULL Algorithm): The Null
algorithm cannot be used, even for emergency
calls.
To activate integrity protection of RRC signaling messages, eNodeBs perform initial security
activation or security handling during handovers. For details, see 3.3 Activation and Change
of the Security Mode.
To implement integrity protection, the eNodeB and UEs involved in a transmission must use the
same integrity protection algorithm. Table 3-2 lists the mapping between the preceding integrity

eRAN
protection algorithm names and the integrity protection algorithm IDs specified in 3GPP
protocols.
Table 3-2 Mapping between the preceding integrity protection algorithm names and algorithm
IDs specified in 3GPP protocols
Integrity Algorithm Name Algorithm ID in 3GPP Protocols
NULL EIA0
Snow3G EIA1
AES EIA2
ZUC EIA3
For integrity protection of RRC signaling messages, the eNodeB and UEs must support the EIA1
and EIA2 algorithms according to section 5.1.4 in 3GPP TS 33.401 v10.2.0. They can also use
the EIA3 algorithm to implement integrity protection of RRC signaling messages according to
section 5.1.4 in 3GPP TS 33.401 v11.3.0.
3.1.2 Ciphering
This section describes the following features:
LOFD-001010 Security Mechanism
l LOFD-00101001 Encryption: AES

l LOFD-00101002 Encryption: SNOW 3G
l LOFD-00101003 Encryption: ZUC
eNodeBs perform ciphering on RRC signaling messages and user data at the PDCP layer, as
shown in Figure 3-2.

eRAN
Figure 3-2 Ciphering in PDCP entities
eNodeBs notify UEs of the ciphering algorithms by using RRC signaling messages. Both UEs
and eNodeBs derive cipher keys.
Ciphering protects RRC signaling messages and user data between an eNodeB and a UE from
illegal interception and modification. A sender and a receiver negotiate a ciphering algorithm
by using RRC signaling messages.
A sender uses a ciphering algorithm to encrypt signaling and user data based on input parameters,
including KEY, BEARER, DIRECTION, COUNT, and LENGTH. Then, the sender sends the
encrypted information to a receiver. The receiver decrypts the information based on input
parameters, including KEY, BEARER, DIRECTION, COUNT, and LENGTH.
Each eNodeB is configured with the parameters listed in Table 3-3 to specify the ciphering
algorithms to be used.

eRAN
Table 3-3 Parameters for ciphering algorithms for the eNodeB

Priority
First ENodeBCipherCap This parameter can be set to one of the following

.PrimaryCipherAl- values:
go l NULL(NULL Algorithm): Ciphering is not
used.
l Snow3G(SNOW 3G Algorithm): The SNOW
3G algorithm is used.
used.
l ZUC(ZUC Algorithm): The ZUC algorithm is
used.
l ENodeBCipherCap.PrimaryCipherAlgo is set
to AES(AES Algorithm) by default.
l ENodeBCipherCap.SecondCipherAlgo is set to
Snow3G(SNOW 3G Algorithm) by default.
l ENodeBCipherCap.ThirdCipherAlgo is set to
ZUC(ZUC Algorithm) by default.
l EnodeBCipherCap.FourthCipherAlgo is set to
NULL(NULL Algorithm) by default.
Second ENodeBCipherCap This parameter can be set to one of the following

.SecondCipherAlgo values:
l NULL(NULL Algorithm): Ciphering is not
used.
used.
used.

eRAN

Priority
Third ENodeBCipherCap This parameter can be set to one of the following

.ThirdCipherAlgo values:
used.
used.
used.
Fourth ENodeBCipherCap This parameter can be set to one of the following

.FourthCipherAlgo values:
used.
used.
used.

eRAN
To activate ciphering, eNodeBs perform the initial security activation or security handling during
handovers. For details, see 3.3 Activation and Change of the Security Mode.
To implement ciphering, the eNodeB and UEs involved in a transmission must use the same
ciphering algorithm. Table 3-4 lists the mapping between the preceding ciphering algorithm
names and the ciphering algorithm IDs specified in 3GPP protocols.
Table 3-4 Mapping between the preceding ciphering algorithm names and the ciphering
algorithm IDs specified in 3GPP protocols
Ciphering Algorithm Name Cipher Algorithm ID in 3GPP Protocols
NULL EEA0
Snow3G EEA1
AES EEA2
ZUC EEA3
For ciphering of RRC signaling messages and user data, the eNodeB and UEs must support the
EEA0, EEA1, and EEA2 algorithms according to section 5.1.3 in 3GPP TS 33.401 v10.2.0. They
can also use the EEA3 algorithm to implement ciphering of RRC signaling messages and user
data according to section 5.1.3 in 3GPP TS 33.401 v11.3.0.
3.2 Key Derivation

Keys are an important input to integrity protection and ciphering. For details about key
derivation, see chapter 6 in 3GPP TS 33.401 v10.2.0 and chapter 14 in 3GPP TS 36.300 v10.7.0.
Integrity protection and ciphering use the following three types of keys: integrity key for RRC
signaling messages, cipher key for RRC signaling messages, and cipher key for user data. To
ensure successful ciphering and deciphering and verify integrity, the UE and eNodeB involved
in each transmission must use the same keys. In addition, to ensure key security, the UE and the
eNodeB derive the keys instead of sending them over the Uu interface.
Figure 3-3 shows derivation relationships between keys for integrity protection and ciphering.
Figure 3-3 Key derivation relationships

eRAN
The elements shown in Figure 3-3 are described as follows:
l KeNodeB is used to derive KUP enc, KRRC enc, and KRRCint, and it is also used to derive
KeNodeB* during handovers. During initial RRC connection setup, the UE and mobility
management entity (MME) derive KeNodeB from the topmost key for the Evolved Universal
Terrestrial Radio Access Network (E-UTRAN).
l KRRCint is an integrity key for RRC signaling messages. The UE and eNodeB derive this
key from KeNodeB.
l KRRC enc is a cipher key for RRC signaling messages. The UE and eNodeB derive this key
from KeNodeB.
l KUP enc is used for user data ciphering. The UE and eNodeB derive this key from
KeNodeB.
l KeNodeB* is a key derived by the UE and source eNodeB in a handover from KeNodeB (or a
new NH, namely, next hop), the target physical cell identifier (PCI), and the target downlink
frequency. After the handover, the UE and target eNodeB use this KeNodeB* as a new
KeNodeB.
l NH is used by the UE and eNodeB to derive KeNodeB*. During the setup of a security
context, the UE and MME derive NH from KeNodeB. During a handover, NH is derived
from a previous NH.
l NCC, next hop chaining count, is a counter for NH. It counts the number of NH derivations
that have been performed. During a handover, NCC is used to synchronize the key chain
between the UE and the source eNodeB. In this way, NCC helps determine whether the
next KeNodeB* is derived from KeNodeB or a new NH.
NOTE
Each KeNodeB and NH correspond to values of NCC, indicating the positions of the KeNodeB and NH in the
key chain. When an RRC connection is initially set up, KeNodeB corresponds to the NCC value of 0, and
NH corresponds to the NCC value of 1.
3.3 Activation and Change of the Security Mode
3.3.1 Initial Security Activation Procedure

After receiving a UE security context from the MME, the eNodeB initiates an initial security
activation procedure, as shown in Figure 3-4.

eRAN
Figure 3-4 Initial security activation procedure
1. After an RRC connection is set up, the MME derives KeNodeB and NH and sends UE security
capabilities and the KeNodeB to the eNodeB. The UE security capabilities include the
ciphering and integrity protection algorithms supported by the UE.
2. Based on local prioritized algorithms and UE security capabilities, the eNodeB selects the
highest-priority integrity protection algorithm that is supported by the UE.
3. Based on local prioritized algorithms and UE security capabilities, the eNodeB selects the
highest-priority ciphering algorithm that is supported by the UE.
4. The eNodeB uses the selected algorithms to derive KUP enc, KRRCint, and KRRC enc from
KeNodeB and sets related ciphering and integrity protection parameters for the PDCP layer.
5. The eNodeB sends the UE a Security Mode Command message, which contains security-
related parameters indicating security algorithms. The message is sent over SRB1 and is
only integrity-protected by the eNodeB.
6. The eNodeB receives a response message from the UE.

eRAN
If... Then...
The message is Security Mode Complete The security activation is successful.

NOTE
The Security Mode Complete message is sent
over SRB1 and is only integrity-protected by
the UE.
The message is Security Mode Failure The security activation fails.

NOTE
The Security Mode Failure message is sent over
SRB1 without ciphering or integrity protection.
7. If the security activation is successful, both integrity protection and ciphering are activated.
If algorithms other than the Null algorithm are used, the eNodeB performs integrity
protection on RRC signaling messages and then ciphering on both the RRC signaling
messages and MAC-I, and performs only ciphering on user data.
NOTE
The UE uses the same integrity protection algorithm for all SRBs and the same ciphering algorithm for all
SRBs and DRBs. Integrity protection and ciphering may use different algorithms.
Security procedures are activated for emergency calls. For UEs in limited service mode or UEs
not authenticated, the eNodeB uses the Null algorithm for integrity protection and ciphering.
For other UEs, the eNodeB uses the algorithms selected in the preceding procedure.
For more details about the initial security activation procedure, see chapter 7 in 3GPP TS 33.401
v10.2.0 and section 5.3.4 in 3GPP TS 36.331 v10.5.0.
3.3.2 Security Handling During Handovers

Integrity protection and ciphering algorithms may be changed during handovers. Keys used by
the algorithms may be changed during handovers or RRC connection reestablishment.
A handover may be performed from a source eNodeB to a target eNodeB over the X2 or S1
interface, called X2 handover or S1 handover, respectively. The security handling procedure for
S1 handover is similar to that for X2 handover. This section describes the security handling
procedure for X2 handover, as shown in Figure 3-5.

eRAN
Figure 3-5 Procedure for security handling during an X2 handover
Following is the procedure for security handling during an X2 handover:
1. The UE sends a Measurement Report message to the source eNodeB.

2. The source eNodeB decides to perform an X2 handover for the UE. Then, the source
eNodeB derives KeNodeB* from KeNodeB (or NH), the target PCI, and the target downlink
frequency.
NOTE
If the NH on the source eNodeB is already used, KeNodeB is used to derive KeNodeB*. If the NH on
the source eNodeB is not used, the NH is used to derive KeNodeB*.
3. The source eNodeB encapsulates a security context (including the UE security capabilities,
NCC, and KeNodeB*) into a Handover Request message and sends the message to the target
eNodeB over the X2 interface.
4. After receiving the Handover Request message, the target eNodeB takes the following
actions:

eRAN
a. Selects the highest-priority integrity protection and ciphering algorithms supported

by the UE, based on the local prioritized algorithms.
b. Uses the KeNodeB* forwarded by the source eNodeB as KeNodeB and uses the selected
algorithms to derive KUP enc, KRRCint, and KRRC enc from the KeNodeB.
c. Sets security-related parameters for the PDCP layer based on the selected integrity
protection and ciphering algorithms and keys. The security-related parameters are to
be used after the handover.
5. The target eNodeB sends the source eNodeB a Handover Request Acknowledge message,
which contains the NCC of the source eNodeB and the selected security algorithms.
6. The source eNodeB sends the UE an RRC Connection Reconfiguration message, which
contains the NCC and security algorithms provided by the target eNodeB.
The message is encrypted and integrity-protected by using the pre-handover security-
related parameters.
7. The UE derives KeNodeB* from the local KeNodeB and the received NCC, uses UE-supported
integrity protection and ciphering algorithms to derive KUP enc, KRRCint, and KRRC enc from
the KeNodeB*, and sets security-related parameters for the PDCP layer based on the
algorithms.
The security-related parameters are to be used after the handover.
8. After the UE is handed over successfully, it sends an RRC Connection Reconfiguration
Complete message to the target eNodeB. The message is encrypted and integrity-protected
by using the post-handover security-related parameters.
9. The target eNodeB uses the post-handover security-related parameters to perform integrity
protection and ciphering on RRC signaling messages and also ciphering on user data.
10. The target eNodeB sends the MME a Path Switch Request message, informing the MME
of the handover completion.
11. Upon receiving the Path Switch Request message, the MME increases NCC by 1 and
derives a new NH from the previously stored NH.
12. The MME sends the target eNodeB a Path Switch Request Acknowledge message, which
contains the new NCC and NH.
13. The target eNodeB saves the new NCC and NH for use in the next handover.
NOTE
If the target eNodeB does not receive a Path Switch Request Acknowledge message, the NCC and
NH at the target eNodeB are not updated. Therefore, the target eNodeB must use KeNodeB to derive
KeNodeB* in the next handover.
14. The target eNodeB sends the source eNodeB a UE Context Release message, instructing
the source eNodeB to release the UE context.
For more details about the procedure for security handling during handovers, see chapter 7 in
3GPP TS 33.401 v10.2.0 and chapter 14 in 3GPP TS 36.300 v10.7.0.

eRAN
Radio Security Feature Parameter Description 4 Related Features
4 Related Features
4.1 LBFD-002004 Integrity Protection

Prerequisite Features
None
Mutually Exclusive Features

None
Impacted Features
None
4.2 LOFD-00101001 Encryption: AES

None

None
Impacted Features
None

eRAN
Radio Security Feature Parameter Description 4 Related Features
4.3 LOFD-00101002 Encryption: SNOW 3G

None

None
Impacted Features
None
4.4 LOFD-00101003 Encryption: ZUC

None

None
Impacted Features
None

eRAN
Radio Security Feature Parameter Description 5 Network Impact
5 Network Impact
5.1 LBFD-002004 Integrity Protection

System Capacity
No impact.
Network Performance
No impact.
5.2 LOFD-00101001 Encryption: AES

System Capacity
None
Network Performance
None
5.3 LOFD-00101002 Encryption: SNOW 3G

System Capacity
None
Network Performance
None

eRAN
Radio Security Feature Parameter Description 5 Network Impact
5.4 LOFD-00101003 Encryption: ZUC

System Capacity
None
Network Performance
None

eRAN
Radio Security Feature Parameter Description 6 Engineering Guidelines
6 Engineering Guidelines
This chapter provides engineering guidelines for radio security.

eRAN
6.1 When to Use Radio Security

To enhance security and signaling correctness on the radio interface, it is recommended that
integrity protection and ciphering be always enabled. The integrity protection is enabled by
default.
6.2 Required Information

None
6.3 Network Planning

None
6.4 Deployment
6.4.1 Requirements
Operating Environment
The UE and MME must meet the following requirements as stipulated in sections 5.1.3 and 5.1.4
in 3GPP TS 33.401 v10.2.0:
l The UE and MME support the EEA0 (Null), EEA1 (SNOW 3G), EEA2 (AES), or EEA3
(ZUC) algorithms for ciphering of non-access stratum (NAS) signaling.
l The UE and MME support the EIA1 (SNOW 3G), EIA2 (AES), or EIA3 (ZUC) algorithms
for integrity protection of NAS signaling.
l The UE supports the EIA0 (Null) algorithm for integrity protection of NAS signaling and
RRC signaling.
NOTE
The ZUC algorithm is stipulated in 3GPP Release 11. For details, see 3GPP TS 33.401 v11.3.0.
UE and MME should implement NAS signaling security. UE and eNodeB should implement RRC signaling
security. That means different protocol layers should implement their own security. When NAS signaling
is encapsulated in RRC signaling to transfer between UE and eNodeB, both NAS signaling security and
RRC signal security should be used.
Integrity protection and ciphering on the radio interface are configured on each eNodeB and
take effect in all cells under the eNodeB.
Hardware
The LTE baseband process unit type c (LBBPc) does not support the ZUC algorithm. Therefore,
the LBBPc cannot be installed in the Macro or Lampsite eNodeB when the ZUC algorithm is
used for integrity protection or ciphering.

eRAN
Transmission Networking
None
License
Integrity protection is not under license control.
Ciphering is under license control. The operator has purchased and activated the license for the
feature listed in Table 6-1.
Table 6-1 License information for radio security
Feature ID Feature Name License NE Sales Unit

Control Item
LOFD-001010 Security Security eNodeB per eNodeB

Mechanism Mechanism
(FDD)
6.4.2 Data Preparation

This section describes the data that you need to collect for setting parameters. Required data is
data that you must collect for all scenarios. Collect scenario-specific data when necessary for a
specific feature deployment scenario.
There are three types of data sources:
l Network plan (negotiation required): parameter values planned by the operator and
negotiated with the EPC or peer transmission equipment
l Network plan (negotiation not required): parameter values planned and set by the operator
l User-defined: parameter values set by users
Integrity Protection Algorithms

The following table describes the parameters that must be set in the ENodeBIntegrityCap MO
to prioritize the integrity protection algorithms used by an eNodeB.

eRAN
Parame Parameter ID Data Source Setting Notes

ter
Name
Primary ENodeBIntegri Network plan (negotiation This parameter specifies the

integrity tyCap. not required) first-priority integrity protection
algorith PrimaryIntegri- algorithm for the eNodeB.
m tyAlgo You are not advised to set this
parameter to NULL(NULL
Algorithm); otherwise,
information modification cannot
be prevented.
The ENodeBIntegrity-
Cap.PrimaryIntegrityAlgo,
ENodeBIntegrity-
Cap.SecondIntegrityAlgo, and
ENodeBIntegrity-
Cap.ThirdIntegrityAlgo
parameter values must be set to
different values.
Second ENodeBIntegri Network plan (negotiation This parameter specifies the

integrity tyCap. not required) second-priority integrity
algorith SecondIntegri- protection algorithm for the
m tyAlgo eNodeB.
You are not advised to set this
be prevented.
ENodeBIntegrity-
ENodeBIntegrity-
different values.

eRAN
Parame Parameter ID Data Source Setting Notes

ter
Name
Third ENodeBIntegri Network plan (negotiation This parameter specifies the

integrity tyCap. not required) third-priority integrity
algorith ThirdIntegri- protection algorithm for the
m tyAlgo eNodeB.
be prevented.
ENodeBIntegrity-
ENodeBIntegrity-
different values.
NULL ENodeBIntegri Network plan (negotiation Set this parameter based on the
Algorith tyCap.NullAlgo not required) local regulations.
m config
switch
NOTE
UEs only complying with 3GPP Release 8 support the Null algorithm for integration protection. UEs
complying with 3GPP Release 9 or later do not choose the Null algorithm for integration protection.
Ciphering Algorithms
The following table describes the parameters that must be set in the ENodeBCipherCap MO
to prioritize the ciphering algorithms used by an eNodeB.

eRAN
Parameter Parameter ID Source Setting Description

Name
Primary ENodeBCipherCa Network plan This parameter specifies the first-

cipher p. (negotiation not priority ciphering algorithm for
algorithm PrimaryCipherAl- required) the eNodeB.
go You are not advised to set this
information cannot be protected
by ciphering.
The
ENodeBCipherCap.PrimaryCi
pherAlgo,
ENodeBCipherCap.SecondCip
herAlgo,
ENodeBCipherCap.ThirdCiph
erAlgo, and
ENodeBCipherCap.
FourthCipherAlgo parameter
values must be set to different
values.
Second ENodeBCipherCa Network plan This parameter specifies the

cipher p. (negotiation not second-priority ciphering
algorithm SecondCipherAlgo required) algorithm for the eNodeB.
by ciphering.
The
pherAlgo,
herAlgo,
erAlgo, and
ENodeBCipherCap.
values.

eRAN
Parameter Parameter ID Source Setting Description

Name
Third ENodeBCipherCa Network plan This parameter specifies the

cipher p. (negotiation not third-priority ciphering algorithm
algorithm ThirdCipherAlgo required) for the eNodeB.
by ciphering.
The
pherAlgo,
herAlgo,
erAlgo, and
ENodeBCipherCap.
values.
Fourth ENodeBCipherCa Network plan This parameter specifies the

cipher p. (negotiation not fourth-priority ciphering
algorithm FourthCipherAlgo required) algorithm for the eNodeB. The
value NULL(NULL
Algorithm) is recommended.
That is, it is recommended that the
NULL algorithm be set as the
fourth-priority ciphering
algorithm for the eNodeB.
The
pherAlgo,
herAlgo,
erAlgo, and
ENodeBCipherCap.
values.
6.4.3 Initial Configuration

Using the CME to Perform Batch Configuration for Newly Deployed eNodeBs
Enter the values of the parameters listed in Table 6-2 in a summary data file, which also contains
other data for the new eNodeBs to be deployed. Then, import the summary data file into the

eRAN
CME for batch configuration. For detailed instructions, see section "Creating eNodeBs in
Batches" in the initial configuration guide for the eNodeB.
The summary data file may be a scenario-specific file provided by the CME or a customized
file, depending on the following conditions:
l The MOs in Table 6-2 are contained in a scenario-specific summary data file. In this
situation, set the parameters in the MOs, and then verify and save the file.
l Some MOs in Table 6-2 are not contained in a scenario-specific summary data file. In this
situation, customize a summary data file to include the MOs before you can set the
parameters.
Table 6-2 Parameters related to the integrity protection and ciphering algorithms
MO Sheet in the Parameter Group Remarks

Summary Data
File
ENodeBInt User-defined sheet Primary integrity algorithm, None

egrityCap Second integrity algorithm,
Third integrity algorithm,
NULL algorithm
ENodeBCip User-defined sheet Primary cipher algorithm, None

herCap Second cipher algorithm, Third
cipher algorithm, Fourth cipher
algorithm,
Using the CME to Perform Batch Configuration for Existing eNodeBs

Batch reconfiguration using the CME is the recommended method to activate a feature on
existing eNodeBs. This method reconfigures all data, except neighbor relationships, for multiple
eNodeBs in a single procedure. The procedure is as follows:
Step 1 After creating a planned data area, choose CME > Advanced > Customize Summary Data
File (U2000 client mode), or choose Advanced > Customize Summary Data File (CME client
mode), to customize a summary data file for batch reconfiguration.
NOTE
For context-sensitive help on a current task in the client, press F1.
Step 2 Choose CME > LTE Application > Export Data > Export Base Station Bulk Configuration
Data (U2000 client mode), or choose LTE Application > Export Data > Export Base Station
Bulk Configuration Data (CME client mode), to export the eNodeB data stored on the CME
into the customized summary data file.
Step 3 In the summary data file, set the parameters in the MOs listed in Table 6-2 and close the file.
Step 4 Choose CME > LTE Application > Import Data > Import Base Station Bulk Configuration
Data (U2000 client mode), or choose LTE Application > Import Data > Import Base Station
Bulk Configuration Data (CME client mode), to import the summary data file into the CME,
and then start the data verification.

eRAN
Step 5 After data verification is complete, choose CME > Planned Area > Export Incremental
Scripts (U2000 client mode), or choose Area Management > Planned Area > Export
Incremental Scripts (CME client mode), to export and activate the incremental scripts.
----End
Using the CME to Perform Single Configuration

On the CME, set the parameters listed in the "Data Preparation" section for a single eNodeB.
The procedure is as follows:
Step 1 In the planned data area, click Base Station in the upper left corner of the configuration window.
Step 2 In area 1 shown in Figure 6-1, select the eNodeB to which the MOs belong.
Figure 6-1 MO search and configuration window
Step 3 On the Search tab page in area 2, enter an MO name, for example, CELL.
Step 4 In area 3, double-click the MO in the Object Name column. All parameters in this MO are
displayed in area 4.
Step 5 Set the parameters in area 4 or 5.
Step 6 Choose CME > Planned Area > Export Incremental Scripts (U2000 client mode), or choose
Area Management > Planned Area > Export Incremental Scripts (CME client mode), to
export and activate the incremental scripts.
----End

eRAN
Using MML Commands

l Integrity protection
Run the MOD ENODEBINTEGRITYCAP command to prioritize the integrity protection
algorithms used by the eNodeB.
l Ciphering
Run the MOD ENODEBCIPHERCAP command to prioritize the ciphering algorithms
used by the eNodeB.
MML Command Examples

MOD ENODEBINTEGRITYCAP: PrimaryIntegrityAlgo=AES, SecondIntegrityAlgo=Snow3G,
ThirdIntegrityAlgo=ZUC, NullAlgo=Enable;
MOD ENODEBCIPHERCAP: PrimaryCipherAlgo=AES, SecondCipherAlgo=Snow3G,
ThirdCipherAlgo=ZUC, FourthCipherAlgo=NULL;
6.4.4 Activation Observation

Trace a UE that supports integrity protection or ciphering over the Uu interface. If the traced
SecurityModeCommand message contains the information element (IE)
securityAlgorithmConfig, as shown Figure 6-2, the corresponding algorithms have been
activated. For definitions of the IEs, see sections 5.1.3 and 5.1.4 in 3GPP TS 33.401 v10.2.0.
The ZUC algorithm is stipulated in 3GPP Release 11. For details, see 3GPP TS 33.401 v11.3.0.
Figure 6-2 Message traced over the Uu interface
For details about the signaling procedure for initial security activation, see section 5.3.4 in 3GPP
TS 36.331 v10.5.0. Different from the signaling procedure for initial security activation, the
procedure for security handling during a handover enables request and response messages to be
sent over SRB0 without ciphering or integrity protection.
6.4.5 Reconfiguration
eNodeBs can be reconfigured one by one on the GUI, or in batches on the Configuration
Management Express (CME) using the batch reconfiguration operations, batch modification
center, templates, or radio data planning file. For detailed reconfiguration procedures, see the
reconfiguration guide for the eNodeB.

eRAN
Integrity Protection Algorithms

Configure the ENodeBIntegrityCap MO to adjust the integrity protection algorithm priorities
for an eNodeB. For details about the related parameters and setting descriptions, see Integrity
Protection Algorithms in 6.4.2 Data Preparation. It is recommended that reconfiguration be
performed according to setting notes.
Ciphering Algorithms
Configure the ENodeBCipherCap MO to adjust the ciphering algorithm priorities for an
eNodeB. For details about the related parameters and setting descriptions, see Ciphering
Algorithms in 6.4.2 Data Preparation. It is recommended that reconfiguration be performed
according to setting notes.
6.4.6 Deactivation
Using the CME to Perform Batch Configuration

Batch reconfiguration using the CME is the recommended method to deactivate a feature on
eNodeBs. This method reconfigures all data, except neighbor relationships, for multiple
eNodeBs in a single procedure. The procedure for feature deactivation is similar to that for
feature activation described in Using the CME to Perform Batch Configuration for Existing
eNodeBs In the procedure, modify parameters according to Table 6-3.
Table 6-3 Parameters related to ciphering
MO Sheet in the Parameter Group Setting Notes

Summary Data
File
ENodeBCiph User-defined sheet Primary cipher Set this parameter to NULL

erCap algorithm (NULL Algorithm).
Integrity protection cannot be deactivated.
Using the CME to Perform Single Configuration

On the CME, set parameters according to Table 6-3. For details, see Using the CME to Perform
Single Configuration described for feature activation.
Using MML Commands

l Integrity protection
l Ciphering
Run the MOD ENODEBCIPHERCAP command to deactivate ciphering.

eRAN
MML Command Examples

MOD ENODEBCIPHERCAP: PrimaryCipherAlgo=NULL, SecondCipherAlgo=Snow3G,
ThirdCipherAlgo=ZUC, FourthCipherAlgo=AES;
6.5 Performance Monitoring

None
6.6 Parameter Optimization

None
6.7 Troubleshooting
Fault Description
After eNodeB initial configuration is completed, a UE fails to access the network. The result of
Uu interface tracing on the U2000 client indicates that the UE sends the eNodeB a
SecurityModeFailure message as a response to a SecurityModeCommand message.
Fault Handling
Identify and solve the problem by performing the following operations:
Step 1 Check security capabilities of the UE (that is, the ciphering algorithms and integrity protection
algorithms supported by the UE) by viewing the uESecurityCapabilities IE in the
S1AP_INITIAL_CONTEXT_SETUP_REQ message traced over the S1 interface.
Figure 6-3 uESecurityCapabilities IE in the S1AP_INITIAL_CONTEXT_SETUP_REQ

message
In the uESecurityCapabilities IE, the encryptionAlgorithms IE indicates the ciphering

algorithms supported by the UE, and the integrityProtectionAlgorithms IE indicates the integrity
protection algorithms supported by the UE.
l If all bits are zero, the UE supports only the Null algorithm.
l The leftmost bit of the IEs indicates whether the UE supports the SNOW 3G algorithm.
l The second bit from the left indicates whether the UE supports the AES algorithm.
l The third bit from the left indicates whether the UE supports the ZUC algorithm.

eRAN
The value 1 indicates that the UE supports the corresponding algorithm, and the value 0 indicates
that the UE does not support the algorithm.
Step 2 Based on local prioritized algorithms on the eNodeB and UE security capabilities, check whether
the eNodeB and UE support the same integrity protection and ciphering algorithms.
If... Then...
The eNodeB and UE support the Contact Huawei technical support.

same algorithms
The eNodeB and UE support Check whether the settings for integrity protection and
different algorithms ciphering algorithms are correct in the UE, or contact
the UE manufacturer for technical support.
----End

eRAN
Radio Security Feature Parameter Description 7 Parameters
7 Parameters
Table 7-1 Parameter description
MO Parame MML Feature Feature Description

ter ID Comma ID Name
nd
ENodeB PrimaryI MOD LBFD-0 Integrity Meaning: Indicates the highest-priority integrity
Integrity ntegrity ENODE 02004 / Protecti protection algorithm supported by the eNodeB.
Cap Algo BINTE TDLBF on GUI Value Range: NULL(NULL Algorithm), Snow3G
GRITY D-00200 (SNOW 3G Algorithm), AES(AES Algorithm), ZUC
CAP 4 (ZUC Algorithm)
LST Unit: None
ENODE
BINTE Actual Value Range: NULL, Snow3G, AES, ZUC
GRITY Default Value: AES(AES Algorithm)
CAP
ENodeB SecondI MOD LBFD-0 Integrity Meaning: Indicates the second-priority integrity
Integrity ntegrity ENODE 02004 / Protecti protection algorithm supported by the eNodeB.
Cap Algo BINTE TDLBF on GUI Value Range: NULL(NULL Algorithm), Snow3G
LST Unit: None
ENODE
GRITY Default Value: Snow3G(SNOW 3G Algorithm)
CAP

eRAN

nd
ENodeB ThirdInt MOD LBFD-0 Integrity Meaning: Indicates the third-priority integrity
Integrity egrityAl ENODE 02004 / Protecti protection algorithm supported by the eNodeB.
Cap go BINTE TDLBF on GUI Value Range: NULL(NULL Algorithm), Snow3G
LST Unit: None
ENODE
GRITY Default Value: ZUC(ZUC Algorithm)
CAP
ENodeB NullAlg MOD LBFD-0 Integrity Meaning: Indicates whether the eNodeB can use the null
Integrity o ENODE 02004 / Protecti algorithm for integrity protection. If this switch is turned
Cap BINTE TDLBF on off, the null algorithm cannot be used for integrity
GRITY D-00200 protection. When this switch is turned off, the eNodeB
CAP 4 selects an integrity protection algorithm based on the
LST algorithm priorities specified by PrimaryIntegrityAlgo,
ENODE SecondIntegrityAlgo, and ThirdIntegrityAlgo, but
BINTE skips the null algorithm.
GRITY GUI Value Range: Disable(Disable NULL Algorithm),
CAP Enable(Enable NULL Algorithm)
Unit: None
Actual Value Range: Disable, Enable
Default Value: Enable(Enable NULL Algorithm)
ENodeB Primary MOD LOFD-0 Encrypti Meaning: Indicates the highest-priority ciphering
CipherC CipherA ENODE 0101001 on: AES algorithm supported by the eNodeB. The value NULL
ap lgo BCIPHE / Encrypti indicates that ciphering is not applied.
RCAP TDLOF on: GUI Value Range: NULL(NULL Algorithm), Snow3G
LST D-00101 SNOW (SNOW 3G Algorithm), AES(AES Algorithm), ZUC
ENODE 001 3G (ZUC Algorithm)
BCIPHE LOFD-0 Encrypti Unit: None
RCAP 0101002 on: ZUC
/ Actual Value Range: NULL, Snow3G, AES, ZUC
TDLOF Default Value: AES(AES Algorithm)
D-00101
002
LOFD-0
0101003
/
TDLOF
D-00101
003

eRAN

nd
ENodeB Second MOD LOFD-0 Encrypti Meaning: Indicates the second-priority ciphering
CipherC CipherA ENODE 0101001 on: AES algorithm supported by the eNodeB. The value NULL
ap lgo BCIPHE / Encrypti indicates that ciphering is not applied.
TDLOF Default Value: Snow3G(SNOW 3G Algorithm)
D-00101
002
LOFD-0
0101003
/
TDLOF
D-00101
003
ENodeB ThirdCi MOD LOFD-0 Encrypti Meaning: Indicates the third-priority ciphering
CipherC pherAlg ENODE 0101001 on: AES algorithm supported by the eNodeB. The value NULL
ap o BCIPHE / Encrypti indicates that ciphering is not applied.
TDLOF Default Value: ZUC(ZUC Algorithm)
D-00101
002
LOFD-0
0101003
/
TDLOF
D-00101
003

eRAN

nd
ENodeB FourthC MOD LOFD-0 Encrypti Meaning: Indicates the fourth-priority ciphering
CipherC ipherAlg ENODE 0101001 on: AES algorithm supported by the eNodeB. The value NULL
ap o BCIPHE / Encrypti indicates that ciphering is not applied.
TDLOF Default Value: NULL(NULL Algorithm)
D-00101
002
LOFD-0
0101003
/
TDLOF
D-00101
003

eRAN
Radio Security Feature Parameter Description 8 Counters
8 Counters
Table 8-1 Counter description
Counter ID Counter Name Counter Feature ID Feature Name

Description
1526727171 L.SecurMode.S1.R Number of security Multi-mode: None Security Mechanism

x mode configurations GSM: None Security Mechanism
received over the S1
interface UMTS: None
LTE:
LOFD-001010
TDLOFD-001010
1526727172 L.SecurMode.Cmd Number of security Multi-mode: None Security Mechanism

mode commands GSM: None Security Mechanism
sent over the Uu
interface UMTS: None
LTE:
LOFD-001010
TDLOFD-001010
1526727173 L.SecurMode.Cmp Number of Multi-mode: None Security Mechanism

successful security GSM: None Security Mechanism
mode configurations
received from the UMTS: None
UE LTE:
LOFD-001010
TDLOFD-001010
1526727174 L.SecurMode.Fail Number of security Multi-mode: None Security Mechanism

mode configuration GSM: None Security Mechanism
failures received
from the UE UMTS: None
LTE:
LOFD-001010
TDLOFD-001010

eRAN
Radio Security Feature Parameter Description 9 Glossary
9 Glossary
For the acronyms, abbreviations, terms, and definitions, see Glossary.

eRAN
Radio Security Feature Parameter Description 10 Reference Documents
10 Reference Documents
1. 3GPP TS 33.401 v10.2.0, "Security architecture"

2. 3GPP TS 33.401 v11.3.0, "Security architecture"
3. 3GPP TS 36.300 v10.7.0, "Overall description"
4. 3GPP TS 36.323 v10.1.0, "Packet Data Convergence Protocol (PDCP) specification"
5. 3GPP TS 36.331 v10.5.0, "Radio Resource Control (RRC)"


Radio Security

Hochgeladen von

Dokumentinformationen

Originaltitel

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

Radio Security

Hochgeladen von

Copyright:

Verfügbare Formate

eRAN

Radio Security Feature Parameter

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue 01 (2014-04-26) Huawei Proprietary and Confidential i

1 About This Document..................................................................................................................1

Issue 01 (2014-04-26) Huawei Proprietary and Confidential ii

Issue 01 (2014-04-26) Huawei Proprietary and Confidential iii

1 About This Document

eNodeB Type Model

Macro 3900 series eNodeB

Micro BTS3202E and BTS3203E

1.2 Intended Audience

Issue 01 (2014-04-26) Huawei Proprietary and Confidential 1

l Need to understand the features described herein

1.3 Change History

eRAN7.0 Draft B (2014-03-07)

Chang Change Description Parameter Affected Entity

Feature None None N/A

Editoria Added 1.4 Differences Between None N/A

eRAN7.0 Draft A (2014-01-20)

Change Change Description Parameter Change

Feature Changed the name of Huawei mobile element None

Editorial Modified the setting notes for parameters related None

Issue 01 (2014-04-26) Huawei Proprietary and Confidential 2

1.4 Differences Between eNodeB Types

Issue 01 (2014-04-26) Huawei Proprietary and Confidential 3

Issue 01 (2014-04-26) Huawei Proprietary and Confidential 4

Figure 2-1 Security architecture specified in 3GPP protocols

AN: Access Network SN: Serving Network

HE: Home Environment USIM: Universal Subscriber Identity Module

ME: Mobile Equipment

Issue 01 (2014-04-26) Huawei Proprietary and Confidential 5

For engineering guidelines, see 6 Engineering Guidelines.

Issue 01 (2014-04-26) Huawei Proprietary and Confidential 6

3.1 Security Measures

3.1.1 Integrity Protection

Figure 3-1 Integrity protection in PDCP entities

Issue 01 (2014-04-26) Huawei Proprietary and Confidential 7

Algorithm Parameter ID Description

First ENodeBIntegrity- Each parameter can be set to one of the following

Null ENodeBIntegrity- This parameter can be set to either of the following

Issue 01 (2014-04-26) Huawei Proprietary and Confidential 8

Integrity Algorithm Name Algorithm ID in 3GPP Protocols

LOFD-001010 Security Mechanism

l LOFD-00101001 Encryption: AES

Issue 01 (2014-04-26) Huawei Proprietary and Confidential 9

Figure 3-2 Ciphering in PDCP entities

Issue 01 (2014-04-26) Huawei Proprietary and Confidential 10

Table 3-3 Parameters for ciphering algorithms for the eNodeB

Algorithm Parameter ID Description

First ENodeBCipherCap This parameter can be set to one of the following

Second ENodeBCipherCap This parameter can be set to one of the following

Issue 01 (2014-04-26) Huawei Proprietary and Confidential 11

Algorithm Parameter ID Description

Third ENodeBCipherCap This parameter can be set to one of the following

Fourth ENodeBCipherCap This parameter can be set to one of the following

Issue 01 (2014-04-26) Huawei Proprietary and Confidential 12

3.2 Key Derivation

Figure 3-3 Key derivation relationships

Issue 01 (2014-04-26) Huawei Proprietary and Confidential 13

The elements shown in Figure 3-3 are described as follows: