Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Issue 01
Date 2014-04-26
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.
Website: http://www.huawei.com
Email: support@huawei.com
Contents
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
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
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.
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.
eRAN7.0 01 (2014-04-26)
This issue does not include any changes.
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.
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.
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.
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.
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.
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
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
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
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:
eNodeBs perform ciphering on RRC signaling messages and user data at the PDCP layer, as
shown in Figure 3-2.
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.
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.
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.
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.
If... Then...
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.
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.
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:
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.
4 Related Features
Impacted Features
None
Impacted Features
None
Impacted Features
None
Impacted Features
None
5 Network Impact
Network Performance
No impact.
Network Performance
None
Network Performance
None
Network Performance
None
6 Engineering Guidelines
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.
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.
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
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.
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
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
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.
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
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.
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 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
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.
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
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.
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.
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 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
7 Parameters
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
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: Snow3G(SNOW 3G Algorithm)
CAP
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
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: 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
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.
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: 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.
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: ZUC(ZUC Algorithm)
D-00101
002
LOFD-0
0101003
/
TDLOF
D-00101
003
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.
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: NULL(NULL Algorithm)
D-00101
002
LOFD-0
0101003
/
TDLOF
D-00101
003
8 Counters
9 Glossary
10 Reference Documents