- About this Guide
- Mobility Management Entity Overview
- Mobility Management Entity Configuration
- 128K eNodeB Connections
- A-MSISDN Functionality
- Access Restriction based on Regional Zone Code
- APN Override
- Backup and Recovery of Key KPI Statistics
- Cause Code #66
- Cell Broadcast Center - SBc Interface
- Cell Traffic Trace
- Closed Subscriber Groups
- CSFB and SMS over SGs Interface
- CSFB for 1xRTT
- DDN Throttling
- Default APN for DNS Failure
- eDRX Support on the MME
- Emergency Bearer Services
- Enhanced Congestion Control and Overload Control
- Enhanced Multimedia Priority Service (eMPS)
- Enhanced Event Logging
- Foreign PLMN GUTI Management
- GTP-C Load and Overload Control on MME
- GUTI Re-allocation
- Heuristic and Intelligent Paging
- HSS-based P-CSCF Restoration
- Idle-mode Signaling Reduction
- IMSI Manager Overload Control
- IMSI Manager Scaling on the MME
- Integrity and Confidentiality Algorithms for UE
- IPNE Service
- Limiting the Number of SGWs Tried
- Load Balancing and Rebalancing and VoLTE Offloading
- Local Emergency Numbers List
- Location Services
- MBMS for MME (eMBMS)
- Operator Policy
- Operator Specific QCI
- Operator Policy Selection Based on IMEI-TAC
- Overcharging Protection
- Paging Priority IE Support
- Power Saving Mode (PSM) in UEs
- QoS Profile Support
- S13 Additional IMEI Check
- Selective Authentication
- Session Tracing
- SGW Blacklisting on the MME
- SGSN-MME Combo Optimization
- Single Radio Voice Call Continuity
- SRVCC for 1xRTT
- State-Location Information Retrieval Flag
- TAI-based Routing for 20-bit and 28-bit eNB ID
- Timer-based GBR Bearer Deactivation
- UDPC2 Support for MME/SGSN
- UE Relocation
- VLR Management
- Troubleshooting the MME Service
- Monitor the MME Service
- Engineering Rules
MME Administration Guide, StarOS Release 21.1
Bias-Free Language
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
- Updated:
- January 26, 2017
Chapter: Integrity and Confidentiality Algorithms for UE
Integrity and
Confidentiality Algorithms for UE
This chapter describes the implementation of Integrity and Confidentiality Algorithms for UEs in Liminted Service Mode (LSM), and UEs that cannot be authenticated by the MME, to establish emergency calls.
Feature Description
In this feature, UEs that are in limited service mode (LSM) and UEs that cannot be authenticated by the MME are allowed to establish emergency calls.
MME uses EEA0 (Integrity) and EIA0 (Ciphering) algorithms for emergency attach requests even if the UE does not advertise the support of these algorithms in the request message, to successfully process the VoLTE emergency calls. These algorithms successfully process the VoLTE calls irrespective of the validation level configured for a UE.
The MME provides options to authenticate emergency attaches using the following CLI:
ue-validation-level { auth-only | full | imsi | none }
Using the above command syntax, it is possible to configure the MME to allow or disallow unauthenticated UEs in LSM to establish bearers for emergency calls. To establish bearers for an emergency call for unauthenticated UEs in LSM, the MME allows NAS protocol to use EIA0 and EEA0 as the integrity and ciphering algorithm respectively.
If the MME allows an unauthenticated UE in LSM to establish bearers for emergency calls on receiving an emergency attach request message from the UE, the MME:
-
Selects an algorithm based on the UE's announcement only if the MME supports the requested algorithm. If the MME does not support the requested algorithm or if there is no algorithm announced, then the EEA0 and EIA0 algorithms are used.
-
Set the UE EPS security capabilities to only contain EIA0 and EEA0 when sending these to the eNB in the following messages:
 Note | As a result, the MME only sends a UE with EPS security capability containing EIA0 and EEA0 to the eNB when selecting EIA0 for NAS integrity protection because the eNB is only capable of selecting EIA0 for AS integrity protection and EEA0 for AS confidentiality protection. In general, if EIA0 is used for NAS integrity protection, then EIA0 will always be used for AS integrity protection or vice-versa |
The rules for when the MME selects the EIA0 for NAS integrity protection, and when the UE accepts a NAS security mode command selecting EIA0 for NAS integrity protection depends on whether the UE and MME can be certain that no EPS NAS security context can be established. For more information on these rules, refer to 3GPP 33.401 specifications document.
Configuration Information
The MME provides options to authenticate emergency attaches using the following CLI:
ue-validation-level { auth-only | full | imsi | none }
-
The auth-only keyword specifies that only authenticated UEs are allowed to use the emergency bearer services.
-
The full keyword specifies that only UEs that have been authenticated, and have successfully passed subscription and location validation, are allowed to use the emergency bearer services.
-
The imsi keyword specifies that UEs with an International Mobile Subscriber Identity are allowed to use the emergency bearer services regardless of authentication. Even if authentication fails, the UE is granted access to use emergency bearer services.
-
The none keyword specifies that all UEs are allowed to use the emergency bearer services. This keyword is used as a default option.
Feedback