3GPP TS 24.301 V12.4.0 中文版---4

4 General

4.1 overview

4.2 EMM和ESM协议之间的连接

4.3 UE mode of operation

4.4 NAS security

4.1 概述

当前文档中描述的NAS层是UE和MME之间无线接口的控制面的最高层。(reference point “LTE-Uu”; see 3GPP TS 23.401 [10]).

这部分NAS协议的主要功能是：

UE移动性的支持

在UE和PDN GW之间建立和维持IP连接的会话管理提供支持

NAS安全也是NAS层提供的一个功能，eg，NAS信令消息的完整性保护和加密。

对于上述功能的支持，本文档将提供下面的过程：

在第五章EMM的基本过程

在第六章ESM的基本过程

完整的NAS传输包含基本过程的特定组合。这些特定组合的实例参照3GPP TS 23.401 [10]。

EPS的NAS遵守3GPP TS 24.007 [12]中的层3协议架构。但是因为EPS提供给用户”ready-to-use”的IP连接和”always-on”的体验，在attach过程时EMM和ESM过程之间有一些连接(see subclause 4.2)。

关于NAS安全控制的信令过程将在第五章作为EMM的一部分叙述。另外，当NAS信令连接建立时，包含处理EPS安全上下文和加密/完整性保护激活的原理将会在4.4章节叙述。

4.2 EMM和ESM协议之间的连接

在EPS attach过程中，网络激活默认EPS承载上下文。另外，网络能同时激活一个或者几个专用EPS承载上下文。为了这种目的，默认EPS承载上下文激活的ESM消息作为一个信息单元包含在ESM消息中发送。UE和网络并行执行attach过程，默认EPS承载上下文激活过程，和专用EPS承载上下文激活过程。UE和网络应该在专用EPS承载上下文完成之前完成默认EPS承载上下文激活过程和attach过程。attach的过程成功与否取决于默认EPS承载上下文激活过程的成功与否。如果attach过程失败，ESM过程也失败。

除了attach过程和service request过程，在EMM过程中，MME应该暂停ESM消息的传输。在service request过程中个，MME可能（may）也会暂停ESM消息的传输。

除了attach过程，在EMM过程中，UE应该暂停ESM消息的传输。

4.2A NAS信令低优先级指示的处理

注：NAS信令低优先级(see 3GPP TS 24.368 [15A], 3GPP TS 31.102 [17])

配置为NAS信令低优先级的UE除了下面的几种情况中UE需要设置low priority indicator 为 “MS is not configured for NAS signalling low priority”之外，UE应该在相应的NAS消息中包含Device properties IE并设置low priority indicator 为 “MS is configured for NAS signalling low priority”：

UE正在执行emergency bearer services的attach；

UE有emergency bearer services的PDN连接，并且正在执行EMM过程，或者正在为emergency bearer services建立PDN连接；

配置了双优先级的UE已经被上层以low priority indicator 为 “MS is not configured for NAS signalling low priority”的请求建立PDN连接；

配置为双优先级的UE已经有一个通过设置low priority indicator 为 “MS is not configured for NAS signalling low priority”的PDN连接建立了，并且正在执行EMM过程；

UE在选择的PLMN上配置使用了AC11 – 15接入优先级；或者

UE正在响应寻呼。

网络可以（may）使用NAS信令低优先级指示用于NAS层移动性管理拥塞控制和基于APN的拥塞控制。

如果NAS信令低优先级指示在PDN CONNECTIVITY REQUEST消息中提供，MME把NAS信令低优先级指示包含在默认EPS承载上下文中。

4.3 UE mode of operation UE的操作模式

4.3.1 General

4.3.2 Change of UE mode of operation

4.3.1 General

attach上EPS服务的UE应该是下面的集中操作模式之一：

PS mode 1：UE仅仅注册EPS服务，UE usage setting设置为voice centric；

PS mode 2：UE仅仅注册EPS服务，UE usage setting设置为data centric；

CS/PS mode 1：UE注册在EPS和non-PES服务，UE usage setting设置为voice centric；

CS/PS mode 2：UE注册在EPS和non-EPS服务，UE usage setting设置为data centric。

配置使用CSFB的UE应该是CS/PS mode 1或者CS/PS mode 2。这样的UE也可能被配置使用IMS，在这种情况下，发起语音通话应该优先使用vocie domain（3GPP TS24.167）。

note1：作为发起语音通信服务选择的这个域可以通过尝试CS紧急通话来忽略。

一旦有上层的请求来建立CS紧急通话：

如果UE需要发起CSFB紧急通话，但是UE不能执行CSFB，UE将会尝试选择到GERAN或者UTRAN，并且具有“IMS voice not available”的UE应该disable E-UTRAN能力来允许可能的CSFB，并且接着进行CS紧急通话建立。

如果UE能发起1xCSFB紧急通话，但是不能执行1xCSFB，UE应该尝试选择到cdma2000 1x来建立通话这个通话。

note2：不能执行CSFB或者1xCSFB紧急通话意味着UE不允许尝试CSFB/1xCSFB，或者CSFB/1xCSFB尝试失败。

配置使用SMS over SGS的UE应该是CS/PS mode 1或者CS/PS mode 2.

CS/PS mode 1的UE一旦CS域接入失败或者接收到“CS fallback not prefered”/“SMS only”indication，将根据IMS上voice的可用性来决定UE行为。在当前文档中，“IMS voice not available”是指下面条件之一：

a) UE没有配置使用IMS

b) UE没有配置使用IMS voice，i.e.当在E-UTRAN中voice domain preference，（定义在3GPP TS 24.167 [13B]），表示语音通话服务只允许通过CS域来获得。

c) UE配置使用IMS voice，但是网络在ATTACH ACCEPT消息中或者TRACKING AREA UPDATE ACCEPT消息中指示不支持通过PS会话的IMS voice。

d) UE配置使用IMS voice，网络在ATTACH ACCEPT消息中或者TRACKING AREA UPDATE ACCEPT消息中指示支持通过PS会话的IMS voice，但是上层

- 在厂家决定的一段时间周期内，上层没有提供指示说UE在IMS上语音通话是可用的，或者

- 上层指示UE在IMS上语音通话不可用。

Note3：如果条件a,b,c都是false，上层需要时间来尝试IMS注册。UE在IMS上语音通话是可用的这个来自上层的指示事件比厂商决定时间周期要长，NAS层假设UE在IMS上是不能语音通话的。（eg. 当试图IMS注册导致的延迟或者因为为了SIP信令获得EPS承载上下文导致的延迟）。

其他条件可能存在，但是这些取决于实现。

4.3.2 Change of UE mode of operation

4.3.2.1 General

4.3.2.2 Change of UE’s usage setting

4.3.2.3 Change of voice domain preference for E-UTRAN

4.3.2.4 Change or determination of IMS registration status

4.3.2.5 Change of configuration regarding the use of SMS

4.3.2.1 General

UE操作模式可以由于以下原因变化：eg

对于具有CS语音能力的UE，UE usage setting的变化；

对于具有CS语音能力的UE，E-UTRAN voice domain preference的变化，（see 3GPP TS 24.167 [13B]）

UE能否在IMS上语音通话可用性的变化

关于SMS使用配置的变化，（see 3GPP TS 24.167 [13B]）

图4.3.2.1.1和图4.3.2.1.2描述了当UE usage setting，E-UTRAN voice domain preference或者关于SMS配置改变时不同UE操作模式的变化。

4.3.2.2 Change of UE’s usage setting

只要当UE的usage setting变化，UE根据操作模式依照 table 4.3.2.2.1 and table 4.3.2.2.2来执行相应的过程。

a) UE在PS mode 1或者PS mode 2



b) UE在CS/PS mode 1或者CS/PS mode 2

4.3.2.3 Change of voice domain preference for E-UTRAN

只要当UE的E-UTRAN voice domain preference变化，UE根据操作模式依照 table 4.3.2.3.1 and table 4.3.2.3.2来执行相应的过程。

a) UE在PS mode 1或者PS mode 2



b) UE在CS/PS mode 1或者CS/PS mode 2

4.3.2.4 Change or determination of IMS registration status

只要当UE在IMS上语音通话可用性的变化（eg，只要IMS注册状态发生变化），UE会根据操作模式依照table 4.3.2.4.1 and table 4.3.2.4.2来执行相应的动作。

a) UE在PS mode 1



b) UE在PS mode 2

4.3.2.5 Change of configuration regarding the use of SMS.

只要当UE的关于SMS的配置发生变化，UE根据操作模式依照table 4.3.2.5.1 and table 4.3.2.5.2来执行相应的过程。

a) UE在PS mode 1或者PS mode 2



b) UE在CS/PS mode 1或者CS/PS mode 2

4.4 NAS security

4.4.1 一般

本节描述了在UE和MME EPS安全上下文和用于UE和MME之间的EPS NAS消息的安全保护程序的处理原则。安全保护涉及的EMM和ESM NAS消息的完整性保护和加密。

对于NAS安全的控制信令程序是EMM协议的一部分，细节在第5条中描述。

注：在网络上使用加密的是运营商的选择。在本节中，对于便于描述，假设加密时使用的，除非明确地另有说明。未经加密的网络的操作是由MME配置的，它始终选择了“空的加密算法”EEA0实现。

4.2.2 EPS安全上下文的处理

4.2.2.1 General

4.4.2.2 Establishment of a mapped EPS security context during intersystem handover

4.4.2.3 Establishment of secure exchange of NAS messages

4.4.2.4 Change of security keys

4.4.2.5 Derivation of keys at CS to PS SRVCC handover from A/Gb mode to S1 mode or from Iu mode to S1 mode

4.2.2.1 General

鉴权，完整性保护和加密的安全参数是和EPS安全上下文联系在一起的，并在使用一个秘钥集标识eKSI来标识。这些安全上下文之间的关系定义在3GPP TS 33.401 [19]。

在安全激活之前，MME和UE需要建立EPS安全上下文。通常，EPS安全上下文是作为MME和UE之间EPS鉴权过程的结果而创建的。EPS安全上下文是下面两种方式之一：

在从A/Gb mode到S1 mode或者从Iu mode到S1 mode的异系统切换时，MME和UE从A/Gb mode或者Iu mode已经建立的UMTS安全上下文生成一个映射的EPS安全上文（mapped），或者

在从A/Gb mode到S1 mode或者从Iu mode到S1 mode的CS到PS SRVCC切换时，MME和UE从A/Gb mode或者Iu mode已经建立的CS UMTS安全上下文来生成一个映射的EPS安全上下文（mapped）。

当MME发起Security Mode Control过程或者从A/Gb mode到S1 mode或者从Iu mode到S1 mode的异系统切换时，UE和MME开始使用EPS安全上下文。这个被网络投入使用的最近的EPS安全上文叫做current EPS安全上下文。current EPS安全上下文可以是native类型或者mapped类型。

秘钥集标识eKSI是在EPS鉴权过程或者在异系统切换过程（作为mapped EPS安全上下文）由MME分配的。eKSI包含安全上下文的类型用来指示这个EPS安全上文是一个native 还是 mapped。当EPS安全上下文是一个native时，eKSI是KSI-ASME，当当前EPS安全上下文是mapped类型的时，eKSI是KSI-SGSN。

当没有执行新的EPS鉴权过程的新NAS信令连接建立时或者当MME发起Security Mode Control过程时，eKSI标识的EPS安全上下文开始用于建立NAS消息的安全交换。为了这个目的，初始NAS消息（(i.e. ATTACH REQUEST, TRACKING AREA UPDATE REQUEST, DETACH REQUEST, SERVICE REQUEST and EXTENDED SERVICE REQUEST)）和SECURITY MODE COMMAND消息在NAS key set identifier IE或者KSI的eKSI值部分包含一个eKSI，和sequence number IE标识current EPS安全上下文用来对NAS消息完整性保护。

在当前文档中，当UE需要删除eKSI，UE需要设置eKSI的值为”no key is available”，并且认为与其相关联的KASME or K’ASME, EPS NAS ciphering key 和EPS NAS integrity key无效（i.e.和eKSI相关的EPS安全上下文不在有效）。

Note：在一些规范中，可能使用加密秘钥序列号代替秘钥集标识eKSI。

UE和MME需要同时保持两个EPS安全上下文，也就是说，current EPS安全上下文和non-current EPS安全上下文，因为：

在EPS重新鉴权后，UE和MME都有一个current EPS安全上下文和non-current EPS安全上下文（还没有投入使用的，也就是partial nativeEPS安全上下文）；

在从A/Gb mode到S1 mode或者从Iu mode到S1 mode的异系统切换后，UE和MME都有一个mapped EPS安全上下文（这个mapped上下文是current EPS安全上下文）和一个non-current native EPS安全上下文（这个上下文是在之前接入S1 mode或者S101 mode时创建的）。

需要由UE和MME同时保持的EPS安全上下文的数量是受到下面因素限制的：

在成功EPS（重新）鉴权后，创建了新的partial native EPS安全上下文，MME和UE可以删除non-current EPS安全上下文了。

当partial native EPS安全上下文通过security mode control 过程投入使用时，MME和UE可以删除之前的current EPS安全上下文。

当MME和UE在emergency bearer service的attach过程或者UE已经有emergency bearer service的PDN连接的TAU过程中使用null integrity和null ciphering算法来建立EPS安全上下文时，MME和UE可以删除之前的current EPS安全上下文。

当一个新的mapped EPS安全上下文或者EPS安全上下文在从A/Gb mode到S1 mode或者从Iu mode到S1 mode的异系统切换中使用null integrity和null ciphering算法来投入使用时，MME和UE不应该删除之前的current native EPS安全上下文，MME和UE应该删除任何partial native EPS安全上下文。

如果没有之前的current native EPS安全上下文存在，MME和UE不应该删除partial native EPS安全上下文。

当MME和UE在从A/Gb mode到S1 mode或者从Iu mode到S1 mode的异系统切换产生一个新的mapped EPS安全上下文，MME和UE应该删除任何存在的current mapped EPS安全上下文。

当通过security mode control过程一个non-current full native EPS安全上下文投入使用时，MME和UE应该删除之前的current mapped EPS安全上下文。

当UE或者MME从EMM-REGISTERED转移到EMM-DEREGISTERED状态时，如果current EPS安全上下文是mapped EPS安全上下文和non-current full native EPS安全上下文存在，接着non-current EPS安全上下文应该成为current EPS安全上下文。此外，UE和MME应该删除任何mapped EPS安全上下文或者partial native EPS安全上下文。

当UE从除了EMM-NULL状态之外的其他状态进入到EMM-DEREGISTERED状态时，或者当UE中断attach过程没有离开EMM-DEREGISTERED状态时，UE应该在USIM上或者在非易失性存储器上标记EPS安全上下文为无效。

4.4.2.2 Establishment of a mapped EPS security context during intersystem handover

为了在UE从A/Gb mode到S1 mode或者从Iu mode到S1 mode的异系统切换生成mapped EPS安全上下文，MME应该生成一个KSI-SGSN，创建一个nonce-MME，并使用nonce-MME和KSI-SGSN生成K’ASME，（see 3GPP TS 33.401 [19]）。MME应该在切换到E-UTRAN的NAS安全透传数据包中包含选择的NAS算法、nonce-MME、KSI-SGSN。MME应该从K’ASME生成EPS NAS秘钥。

KSI-SGSN+nonce-MME===》K’ASME===》EPS NAS Keys

当UE收到执行切换到E-UTRAN的命令时，UE使用NAS安全透传数据包中接收到的nonce-MME生成K’ASME（see 3GPP TS 33.401 [19]）。此外，UE应该使用接收到的KSI-SGSN生成K’ASME，并从K’ASME生成EPS NAS秘钥。

KSI-SGSN（from MME）+nonce-MME（from MME）===》K’ASME===》EPS NAS Keys

当UE有一个emergency bearer service的PDN连接，并且没有current UMTS安全上下文，MME应该在切换到E-UTRAN的NAS安全透传数据包中设置EIA0和EEA0作为NAS选择的算法。MME应该创建一个本地生成的K’ASME。MME在切换到E-UTRAN的NAS安全透传数据包中设置相关联安全上下文的KSI值为“000”，并设置安全上下文标志类型为”mapped security context”。

当UE收到切换到E-UTRAN的命令时，并且有emergency bearer service的PDN连接时，如果在切换到E-UTRAN的NAS安全透传数据包中选择EIA0和EEA0作为NAS安全算法，UE应该创建本地生成的K’ASME。UE应该把相关联安全上下文的KSI值设置为接收到的KSI值。

如果从A/Gb mode到S1 mode或者从Iu mode到S1 mode的异系统切换在EMM-CONNECTED状态没有成功完成，MME和UE应该删除新的mapped EPS安全上下文。

4.4.2.3 Establishment of secure exchange of NAS messages

通过NAS信令连接的NAS消息的安全交换是通过在attach过程中发起security mode command过程由MME建立的。在成功完成security mode command过程之后，UE和MME之间所有交换的NAS消息都使用current EPS安全算法来完整性保护，并且除了subclause 4.4.5指定的消息除外，UE和MME之间所有交换的NAS消息都是使用current EPS 安全算法加密的。

在从A/Gb mode到S1 mode或者从Iu mode到S1 mode的异系统切换过程中，MME和UE之间的NAS消息的安全交换是通过：

通过包裹在从MME到UE触发异系统切换的AS信令中的NAS安全相关参数的发送来实现的。UE使用这些参数来生成mapped EPS安全上下文。

在切换后，通过从UE到MME的TAU过程的发送来实现。UE应该发送使用mapped EPS安全上下文完整性保护但是没有加密的TAU消息。从这个时间点往前，UE和MME之间交换的所有NAS消息都是使用mapped EPS安全上下文完整性保护的，并且除了subclause 4.4.5指定的消息除外，UE和MME之间所有交换的NAS消息都是使用mapped EPS 安全算法加密的。

在S1mode到S1 mode的切换之后，NAS消息的安全交换应该继续。在S1 mode到A/Gb mode 或Iu mode的异系统切换时，或者当NAS连接释放时，NAS消息的安全交换才会终止。

当EMM-IDLE模式的UE建立一个新NAS信令连接并且有一个有效的current EPS安全上下文，NAS消息的安全交换应该根据以下方式进行重建：

除了在下面case3描述的之外，UE应该发送使用current EPS安全上下文完整性保护但是没有加密的initial NAS消息。UE应该包含eKSI指示initial NAS消息中的current EPS安全上下文的值。MME应该检查包含在initial NAS消息中的eKSI是否属于MME中一个可用的EPS安全上下文，并且应该验证这个NAS消息的MAC。如果验证成功，MME可能（may）重建NAS消息的安全交换：

- 通过回复一个使用current EPS安全上下文完整性保护和加密的NAS消息来完成重建。从这个时间点开始，UE和MME之间的所有交换的NAS消息都是完整性保护的，并且除了subclause 4.4.5指定的消息除外，UE和MME之间所有交换的NAS消息都是加密的。或者

- 通过发起security mode command过程来完成重建。这可以使MME把一个non-current EPS安全上下文投入使用，或者通过选择一个新的NAS安全算法修改current EPS安全上下文。

如果initial NAS消息是SERVICE REQUEST消息或者EXTENDED SERVICE REQUEST消息，NAS消息的安全交换被来自底层的用户面无线承载已经成功建立的指示所触发。在成功完成这个过程后，UE和MME之间的所有NAS消息的交换都是完整性保护的，并且除了subclause 4.4.5指定的消息除外，UE和MME之间所有交换的NAS消息都是加密的。

如果UE没有current EPS安全上下文，并且在从A/Gb mode到S1 mode或者从Iu mode到S1 mode的异系统切换后执行TAU过程，UE应该发送没有完整性保护和加密的TAU消息。UE应该包含nonce和GPRS加密秘钥序列号来创建mapped EPS安全上下文。MME创建一个新的mapped EPS安全上下文并且通过发起security mode command过程把这个上下文投入使用，并且在UE和MME中这个上下文变成current EPS安全上下文。这样就冲建立NAS消息的安全交换。

4.4.2.4 Change of security keys

当MME发起重新鉴权来常见一个新的EPS安全上下文时，鉴权过程中交换的消息是使用current EPS安全上下文来完整性保护和加密的。

UE和MME应该持续使用current EPS安全上下文直到MME发起security mode command过程。MME发送的SECURITY MODE COMMAND消息包含要使用的新EPS安全上下文的eKSI。么应该发送使用新EPS安全上下文完整性保护但是没有加密的SECURITY MODE COMMAND消息。当UE响应SECURITY MODE COMMAND消息时，UE应该使用新EPS安全上下文完整性保护和加密的这个消息。

MME也可能通过SECURITY MODE COMMAND消息（包含要修改的这个EPS安全上下文的eKSI和包含选择的新NAS安全算法集合）来修改current EPS安全上下文，或者把non-current EPS 安全上下文投入使用。这种情况下，MME应该使用修改过的EPS安全上下文完整性保护但是没有加密的SECURITY MODE COMMAN发送。当UE使用SECURITY MODE COMPLETE消息响应，UE应该使用修改过的EPS安全上下文完整性保护和加密这个消息。

4.4.2.5 Derivation of keys at CS to PS SRVCC handover from A/Gb mode to S1 mode or from Iu mode to S1 mode

在从A/Gb mode到S1 mode或者从Iu mode到S1 mode因为CS到PS SRVCC切换时(see 3GPP TS 23.216 [8])，UE应该为PS域从CS域的UMTS安全上下文生成一个mapped EPS安全上下文。

在从A/Gb mode到S1 mode因为CS到PS SRVCC切换时，在没有任何新的鉴权过程时，加密可能（may）会开始，完整性保护应该（should）开始。

note 1：如果current EPS安全上下文是一个GSM安全上下文，则从A/Gb mode到S1 mode或者从Iu mode到S1 mode因为CS到PS SRVCC切换不支持。

Note 2:对于紧急通话，从A/Gb mode或者从Iu mode到S1 mode的CS到PS SRVCC切换是不支持的。

（网络端行为）

对于从A/Gb mode或者从Iu mode到S1 mode的CS到PS SRVCC切换，为了生成一个mapped EPS安全上下文，MSC创建NONCE-MSC，并使用CS UMTS完整性秘钥/CS UMTS加密秘钥/创建的NONCE-MSC生成CK’PS 和IK’PS（specified in annex B.6 in 3GPP TS 33.102 [18]）。MSC使用KSI’PS把CK’PS 和IK’PS联系起来。KSI’PS设置为和CS UMTS完整性秘钥和CS UMTS加密秘钥相关联的KSI’PS的值。MSC传输CK’PS, IK’PS和KSI’PS给MME。MME通过设置K’AMSE为从MSC接收到的CK’PS和IK’PS两个的级联 (i.e. CK’PS || IK’PS)来创建一个mapped EPS安全上下文。MME应该使用KSISGSN来关联K’ASME，MME应该设置KSISGSN 为从MSC接收到的KSI’PS。MME应该切换到E-UTRAN的NAS透传数据包中包含NAS算法，NONCEMME和生成的KSISGSN (和K’ASME相关联) 。MME应该从K’ASME生成EPS NAS秘钥。

（UE端行为）

当收到执行CS到PS SRVCC切换S1 mode的命令时，ME应该使用CS UMTS integrity key, the CS UMTS ciphering key和从CS to PS SRVCC切换命令中的接收到的NONCEMSC（specified in annex B.6 in 3GPP TS 33.102 [18]）。ME应该忽略从CS to PS SRVCC切换命令中的接收到的NONCEMME。

NOTE 3: 在切换到E-UTRAN过程中NAS安全透传数据包中接收到的NONCEMME不在这次切换和任何秘钥生成中被ME或者MME使用。

ME应该通过级联CK’PS 和 IK’PS (i.e. CK’PS || IK’PS.)来创建K’ASME，ME应该使用KSISGSN关联生成的秘钥K’ASME。ME应该设置KSISGSN值（和K’ASME关联）为从网络NAS安全透传数据包中接收到的KSISGSN值。

NOTE 4: 尽管这种情况是和SRVCC的MSC server增强有关，但是名字KSISGSN保持不变，以免在同一个域中引入一个新的名字。

（UE端行为）

ME应该从K’ASME中生成EPS NAS秘钥(CK’ and IK’)（specified in 3GPP TS 33.401 [19]）。当从A/Gb mode 或者 Iu mode到S1 mode的CS to PS SRVCC成功完成切换时，ME应该应用这些生成的EPS NAS安全秘钥(CK’ and IK’)，并重置mapped EPS安全上下文中上下行NAS COUNT的值（ie set to 0），并且代替在ME中已经为PS域建立的mapped EPS安全上下文。如果已经建立的current EPS 安全上下文是native类型的，那么current EPS安全上下文将变成non-current native EPS安全上下文，并在ME中重写任何存在的non-current native EPS安全上下文。

（网络端行为）

当从A/Gb mode 或者 Iu mode到S1 mode的CS to PS SRVCC成功完成切换时，网络应该代替已经为PS域建立的mapped EPS安全上下文。如果已经建立的current EPS 安全上下文是native类型的，那么current EPS安全上下文将变成non-current native EPS安全上下文，并在MME中重写任何存在的non-current native EPS安全上下文。

（没有切换成功的情况）

如果从A/Gb mode 或者 Iu mode到S1 mode的CS to PS SRVCC切换还没有成功完成，UE和网络应该删除为PS域新生成的mapped EPS安全上下文。另外，如果已经建立的EPS安全上下文的eKSI等于为PS域新生成的EPS安全上下文的KSI-SGSN，则网络应该删除已经为PS域建立的mapped EPS安全上下文。

4.4.3 Handling of NAS COUNT and NAS sequence number

4.4.3.1 General

4.4.3.2 Replay protection

4.4.3.3 Integrity protection and verification

4.4.3.4 Ciphering and deciphering

4.4.3.5 NAS COUNT wrap around

4.4.3.1 General

每一个EPS NAS安全上下文应该和两个独立的计数器NAS COUNT：一个是上行NAS消息的，一个是下行NAS消息的。这个NAS COUNT使用24bit表示，并且在UE和MME中独立的保持。这个NAS COUNT是由NAS序列号（8个最低位重要的bit）和NAS溢出计数器（16个最高位中重要的bit）。

当NAS COUNT输入到NAS加密或者NAS完整性算法中，应该认为是由24bit后面加上8bit的zeros组成的32bit。

上行NAS COUNT的值被存储在或者从USIM/非易失性存储器上读出（see 附录C），这个值应该应用在下次NAS消息中。

下行NAS COUNT的值被存储在或者从USIM/非易失性存储器上读出（see 附录C），这个值是最大的下行NAS COUNT使用在成功完整性检查NAS消息。

NAS COUNT的NAS序列号部分应该作为NAS信令的一部分在UE和MME之间交换。在每一个新的或者重传的发出去的安全保护的NAS消息后，发送端都应该把NAS COUNT值加一，除了如果底层指示建立RRC连接失败时的初始NAS消息。特别的，在发送端，NAS序列号也应该加一，如果这个结果是0，NAS溢出计数器应该加一(see subclause 4.4.3.5)。接收端应该估算发送端使用的NAS COUNT值。特别的，如果估计的NAS序列号翻转了，NAS应该加一。

因为idle模式下从S1 mode to A/Gb mode or Iu mode系统间切换在NAS token派生出来之后，UE应该把上行NAS COUNT加一。

当MME在idle模式下从S1 mode to A/Gb mode or Iu mode系统间切换时通过SGSN接收到NAS token时，MME应该检查这个NAS token（specified in 3GPP TS 33.401 [19]）subclause 9.1.1，并且使用成功NAS token成功检查的上行NAS COUNT来更新上行NAS COUNT。

NOTE1：如果MME在connected模式下从S1 mode to A/Gb mode or Iu mode系统间切换时通过SGSN接收的，MME不会检查NAS token。

在从UTRAN/GERAN 到E-UTRAN切换过程中，当生成一个mapped EPS安全上下文并投入使用，MME应该设置这个EPS安全上下文的上下行NAS COUNT为0. UE应该也设置上下行NAS COUNT为0.

在从E-UTRAN 到UTRAN/GERAN切换中，MME在NAS安全透传数据包中设置当前下行NAS COUNT值。 (see subclause 9.9.2.6).

在切换到E-UTRAN/从E-UTRAN切换中，MME应该在创建NAS安全透传数据包之后把下行NAS COUNT值加一。 (see subclause 9.9.2.6 and 9.9.2.7).

NOTE2：在从UTRAN/GERAN 到E-UTRAN切换中，NAS安全透传数据包被视为UE和MME之间一个内含的（implicit）SECURITY MODE COMMAND消息，然而，MME认为这个发送的NAS安全透传数据包作为初始SECURITY MODE COMMAND消息的发送来为了生成并投入使用一个mapped EPS安全上下文来处理NAS COUNT。

在一些NAS消息中，只有8bit NAS序列号中的5bit用于传输。在这种情况下，接收端应该评估序列号中保留的3位最重要的bit。

4.4.3.2 Replay protection

replay protection应该在UE和MME端接收NAS消息来应用。但是，因为replay protection的实现不影响节点之间的互用性，对于实现没有指定的机制。

replay protection必须确保一个和同一个NAS消息不能被接收端接收两次。特别的，对于给定的NAS安全上下文，一个给定的NAS COUNT值应该最多一次和仅仅在消息完整性检查正确通过时才能被接收。

4.4.3.3 Integrity protection and verification

发送端应该使用它贝蒂存储的NAS COUNT作为完整性保护算法的输入。

接收端应该使用包含在接收消息中的NAS序列号（或者是接收消息中NAS序列号5bit的估计中得到）和NAS溢出计数器（defined in subclause 4.4.3.1）来形成完整性保护验证算法的NAS COUNT输入值。

计算完整性保护信息的算法定义在3GPP TS 33.401 [19]，完整性保护应该包含安全保护的NAS消息中的octet 6 to n，也就是说sequence number IE和NAS message IE。SERVICE REQUEST消息的完整性保护定义在subclause 9.9.3.28.。除了要完整性保护的数据之外，常数BEARER ID，DIRECTION bit, NAS COUNT and NAS integrity key都是完整性保护算法的输入。这些参数在3GPP TS 33.401 [19].中描述。

在成功完整性保护验证之后，接收到应该使用这个NAS消息中的估计的NAS COUNT来更新响应的本地存储的NAS COUNT。

完整性验证不适用于EIA0没有使用的情况。

4.4.3.4 Ciphering and deciphering

发送端应该使用本地存储的NAS COUNT作为加密算法的输入。

接收端应该使用包含在接收消息中的NAS序列号（或者是接收消息中NAS序列号5bit的估计中得到）和NAS溢出计数器（defined in subclause 4.4.3.1）来形成解密算法的NAS COUNT输入值。

NAS加密算法的输入参数有常数BEARER ID, DIRECTION bit, NAS COUNT, NAS encryption key和加密算法生成的加密数据流的长度。

4.4.3.5 NAS COUNT wrap around

当如上面的规范指定的增加NAS COUNT，如果MME检测到MME的下行NAS COUNT后者UE的上行NAS COUNT是接近wrap around（close to 224），MME应该采取以下动作：

If there is no non-current native EPS security context with sufficiently low NAS COUNT values, 如果没有低 NAS COUNT值的non-crrent EPS安全上下文，当新NAS安全上下文发起时，MME应该发起新的AKA过程，并导致会有一个新建立的NAS安全上下文和NAS COUNT将设置为0。

否则，MME可以使用足够低的NAS COUNT值来激活non-current native EPS安全上下文或者发起新的AKA过程。

如果因为某些原因，新的KASME在NAS COUNT wrap around之前还没有使用AKA来建立，节点（MME或者UE）需要发送NAS消息就应该代替释放NAS信令连接。先于发送下一个上行NAS消息，UE应该删除指示current EPS安全上下文的eKSI。

当EIA0用来NAS完整性算法，UE和MME应该允许NAS COUNT wrap around。如果NAS COUNT wrap around发生，下面的需要将会适用：

UE和MME应该继续适用current 安全上下文。

MME不应该发起EPS AKA过程

MME不应该释放NAS信令连接

UE不应该执行本地对NAS信令连接的释放。

4.4.4 Integrity protection of NAS signalling messages

4.4.4.1 General

对于UE，一旦有有效的EPS安全上下文存在并且已经投入使用，NAS消息的完整性保护信令是必须的。对于网络，一旦NAS信令连接的NAS消息安全交换已经建立了，NAS消息的完整性保护信令也是必须的。所有NAS信令消息的完整性保护是NAS的职责。完整性保护是网络来激活的。

在current 安全上下文中“null完整性保护算法”EIA0只允许在非授权的UE在紧急承载建立时才允许使用。为了设定NAS消息的安全头类型，UE和MME应该应用相同的规则，不管是在安全上下文中指定的是“null完整性保护算法”或者是任何其他完整性保护算法。

如果“null完整性保护算法”EIA0选择作为完整性保护算法，接收端应该认为使用安全头指示为完整性保护的NAS消息是完整性保护的。

完整性保护的和NAS信令消息的验证详细过程见规范3GPP TS 33.401 [19].

当加密和完整性保护都激活时，NAS消息首先加密然后再把加密过的NAS消息和NAS序列号使用计算出来的MAC来完整性保护。

当只有完整性保护激活，加密没有激活时，未加密的NAS消息和NAS序列号使用计算出来的MAC来进行完整性保护。

当在EPS attach过程，ESM消息附带在EMM消息后面，只有一个sequence number IE和一个消息authentication code IE（对于combined NAS消息）。

4.4.4.2 Integrity checking of NAS signalling messages in the UE

除了下面列出的消息，没有NAS信令消息应该在UE中通过接收EMM实体或者转发到ESM实体来处理，直到网络为NAS信令建立建立了NAS消息的安全交换：

EMM消息

IDENTITY REQUEST（如果请求的ID参数是IMSI）

AUTHENTICATION REQUEST

AUTHENTICATION REJECT

ATTACH REJECT (if the EMM cause is not #25);

DETACH ACCEPT (for non switch off);

TRACKING AREA UPDATE REJECT (if the EMM cause is not #25);

SERVICE REJECT (if the EMM cause is not #25).

NOTE：这些消息是被UE没有完整性保护接收的，因为在特定的情景，这些消息是在安全被激活之前由网络来发送的。

所有的ESM消息都是完整性保护的。

一旦NAS消息的安全交换已经建立了，UE的EMM或者ESM接收实体不应该处理任何NAS信令消息，直到这些消息已经被NAS成功完整性检查了。如果NAS信令消息还没有成功的通过完整性检查时接收到了，接着UE的NAS应该丢弃这个消息。SECURITY MODE COMMAND消息的处理还没有被成功通过完整性检查（specified in subclause 5.4.3.5）。如果任何NAS消息是没有完整性保护接收到了（即使网络已经建立起来了NAS消息的安全交换），NAS都应该丢失这个消息。

4.4.4.3 Integrity checking of NAS signalling messages in the MME

除了下面列出的消息，没有NAS信令消息应该在UE中通过接收EMM实体或者转发到ESM实体来处理，直到网络为NAS信令建立建立了NAS消息的安全交换：

EMM消息

ATTACH REQUEST

IDENTITY REQUEST（如果请求的ID参数是IMSI）

AUTHENTICATION RESPONSE;

AUTHENTICATION FAILURE;

SECURITY MODE REJECT;

DETACH REQUEST;

DETACH ACCEPT;

TRACKING AREA UPDATE REQUEST.

NOTE：TRACKING AREA UPDATE REQUEST消息是由UE没有使用完整性保护发送的，如果TAU消息是由于idle模式下系统间切换引起的，并且UE中没有current EPS安全上下文。另外一些被不使用完整性保护被MME接收，因为特定的情况，他们是在安全被激活之前由UE发送的。

所有的ESM消息都是完整性保护的，除了PDN CONNECTIVITY REQUEST，如果它是附在ATTACH REQUEST消息后面，并且NAS安全没有激活时发送的。

一旦NAS消息的安全交换已经建立了，直到为NAS信令连接建立了NAS消息安全交换，MME的接收端EMM实体应该处理下面的NAS信令，尽管包含在消息中的MAC完整性检查失败或者不能检查，因为EPS安全上下文在网络中不可用：

ATTACH REQUEST;

IDENTITY RESPONSE (if requested identification parameter is IMSI);

AUTHENTICATION RESPONSE;

AUTHENTICATION FAILURE;

SECURITY MODE REJECT;

DETACH REQUEST (if sent before security has been activated);

DETACH ACCEPT;

TRACKING AREA UPDATE REQUEST;

SERVICE REQUEST;

EXTENDED SERVICE REQUEST.

NOTE 2: 这些消息是在当MAC完整性检查失败或者不能验证的时候由MME处理的，因为在特定的情况下，这些消息是由UE使用在网络端失效的EPS安全上下文保护来发送的。

如果ATTACH REQUEST消息完整性检查失败，且不是对紧急承载服务的attach 请求，MME应当在进一步处理attach request之前对用户鉴权。对于紧急承载服务的attach过程的处理参看subclause 5.5.1.2.3 and subclause 5.4.2.5.

如果RACKING AREA UPDATE REQUEST 消息完整性检查失败，且UE在TRACKING AREA UPDATE REQUEST消息中提供了一个nonce-UE，GPRS加密秘钥序列号，P-TMSI和RAI。MME应该发起security mode control过程把一个新的mapped EPS安全上下文投入使用；否则，如果UE仅仅有一个对非紧急承载服务的PDN连接，MME应当发起鉴权过程。对于UE有一个紧急承载服务的PDN连接的情况参考subclause 5.5.3.2.3 and subclause 5.4.2.5。

如果SERVICE REQUEST or EXTENDED SERVICE REQUEST消息完整性检查失败，并且UE仅仅只有非紧急承载服务的PDN连接，MME应当发送SERVICE REJECT，并且EMM原因为 #9 “UE identity cannot be derived by the network”，并保留EMM上下文和EPS安全上下文不变。当UE有一个紧急承载服务的PDN连接，且完整性检查失败，即使没有EPS安全上下文可用，MME可能may跳过鉴权过程，并直接按照subclause 5.4.3.处理security mode control 过程的处理。在成功完成service request过程之后，网络应当去激活所有的非紧急EPS承载。紧急EPS承载不应当被去激活。

一旦NAS消息的安全交换已经建立，在MME中接收EMM和ESM实体不应该处理任何NAS信令消息，除非这些消息已经被NAS成功完整性检查了。如果任何NAS信令消息在没有成功通过完整性检查时收到了，MME的NAS应当丢弃这个消息。如果任何接收到的NAS信令消息，即使NAS消息的安全交换已经建立，但仍没有完整性保护，NAS应当丢弃这个消息。

4.4.5 Ciphering of NAS signalling messages

网络端加密的使用是一个运营商的选择，取决于MME配置。当网络运营商没有配置加密，MME应当在current安全上下文中对所有的UE指示”null ciphering algorithm” EEA0 (see subclause 9.9.3.23) 。对于在NAS的外面设置了安全头类型的，UE和MME应当应用相同的规则，不管”null ciphering algorithm”或者在安全上下文中指示的任何加密算法。

当UE建立了一个新的NAS信令连接，应该发送不加密的初始NAS消息。

UE应当发送ATTACH REQUEST消息，一直不加密。

UE应当发送TRACKING AREA UPDATE REQUEST消息，一直不加密。

当NAS消息的安全交换已经建立时，UE应当开始开始NAS消息的加密和解密。从这个时间点开始，除了显式定义的，UE应当发送所有的加密的NAS消息，直到NAS信令连接释放，或者UE执行系统间切换到A/Gb或者Iu模式。

MME应当如subclause 4.4.2.3描述的开始NAS消息的加密和解密。从这个时间点开始，除了SECURITY MODE COMMAND 消息，MME应当发送所有的加密的NAS消息知道NAS信令连接释放，或者UE执行系统间切换到A/Gb或者Iu模式。

一旦在MME和UE之间的NAS开始加密，接收到应该丢弃没有加密的NAS消息（这些NAS消息根据规范中描述的规则应当加密而没有加密）。

如果选择”null ciphering algorithm” EEA0作为加密算法，包含指示加密的安全头的NAS消息认为是加密的。

NAS信令消息的详细加密和解密过程见规范3GPP TS 33.401 [19].

4.5 Disabling and re-enabling of UE’s E-UTRA capability

当UE disable E-UTRA能力，UE应该按照如下处理：

a）选择注册的PLMN或者equivalent PLMN的另一个RAT(GERAN or UTRAN)。

b）如果注册的PLMN或者equivalent PLMN的另一个RAT不能找到，就按照3GPP TS 23.122 [6]执行PLMN选择。如果E-UTRA能力的disable不是因为UE对EPS only服务发起detach过程，UE可能（may）重现enable 这个PLMN选择的E-UTRA能力

c）如果没有其他允许的PLMN和RAT组合可用，UE可能may保留对注册的PLMN的E-UTRAN的EPS服务的注册。如果UE选择这个选项，UE可能may周期性的尝试选择一个能提供non-EPS服务的另一个PLMN和RAT组合。至于怎么周期性的扫描，这是根据UE的实现决定。

如果E-UTRA能力的disable不是因为UE发起对EPS only服务的detach过程，并且E-UTRA能力在执行上面的b) or c)时没有重新enable，接着UE应该在执行PLMN选择时重新enable E-UTRA能力。

如果UE disable E-UTRA能力是因为IMS 语音不可用和CSFB不可用，在当PLMN选择执行的时候将重选enable E-UTRA能力，接着UE应该记住E-UTRA能力disable时PLMN的ID，并且在接下来的PLMN选择中使用存储的信息来执行3GPP TS 23.122 [6]。

当支持A/Gb and/or Iu mode和S1 mode的UE需要待在A/Gb or Iu mode，为了避免不必要的从UTRAN/GERAN到E-UTRAN切换或者小区重选，UE应当disable E-UTRA能力。

在ATTACH REQUEST消息和UE在重选到GERAN或者UTRAN之后的ROUTING AREA UPDATE REQUEST消息，UE不应当设置MS Radio Access capability IE的E-UTRA支持bit (see 3GPP TS 24.008 [13], subclause 10.5.5.12a)，Mobile Station Classmark 3 IE的E-UTRA支持bit(see 3GPP TS 24.008 [13], subclause 10.5.1.7)，MS network capability IE的ISR 支持bit (see 3GPP TS 24.008 [13], subclause 10.5.5.12) ，

在ATTACH REQUEST消息和ROUTING AREA UPDATE REQUEST消息中，UE应当使用MS network capability IE中的EPC能力bit相同的值(see 3GPP TS 24.008 [13], subclause 10.5.5.12)。

UE NAS层应该指示给接入层AS，E-UTRA能力的disable。

在ATTACH REQUEST消息和UE在重选到GERAN或者UTRAN之后的ROUTING AREA UPDATE REQUEST消息，如果在UE的E-UTRA能力disable之后有任何能力bit的改变，UE应当改变MS network capability IE(see 3GPP TS 24.008 [13], subclause 10.5.5.12)。

NOTE：在EMM-idle模式，UE可以仅仅disable E-UTRA能力。

如果UE在选择到GERAN or UTRAN RAT之前，UE在disable UE的E-UTRA能力, UE不应该执行detach过程，subclause 5.5.2.1.

如果UE需要disable E-UTRA并选择GERAN或者UTRAN RAT上，且UE在EMM-CONNECTED mode，UE应该在选择GERAN或者UTRAN RAT之前释放建立的NAS信令连接，并进入EMM-idle mode。

如果E-UTRA能力时因为尝试选择GERAN或者UTRAN RAT处理CS紧急呼叫建立而disable E-UTRA能力(see subclause 4.3.1)，enable E-UTRA能力是UE实现相关。

the UE mode of operation changes from CS/PS mode 1 of operation to CS/PS mode 2 of operation;

the UE mode of operation changes from PS mode 1 of operation to PS mode 2 of operation; or

the UE powers off and powers on again or the USIM is removed;

As an implementation option, the UE may start a timer for enabling E-UTRA when the UE’s attach attempt counter or tracking area updating attempt counter reaches 5 and the UE disables E-UTRA capability for cases described in subclauses 5.5.1.3.4.3, 5.5.1.3.6, 5.5.3.3.4.3 and 5.5.3.3.6. On expiry of this timer:

if the UE is in Iu mode or A/Gb mode and is in idle mode as specified in 3GPP TS 24.008 [13] on expiry of the timer, the UE should enable the E-UTRA capability;

if the UE is in Iu mode or A/Gb mode and an RR connection exists, the UE shall delay enabling E-UTRA capability until the RR connection is released; and

if the UE is in Iu mode and a PS signalling connection exists but no RR connection exists, the UE may abort the PS signalling connection before enabling E-UTRA capability.

For other cases, it is up to the UE implementation when to enable the E-UTRA capability.

如果E-UTRA能力disable是因为UE对EPS only服务发起detach过程(see subclause 5.5.2.2.2)，一旦上层请求re-attach EPS服务，UE应当重新enable E-UTRA。如果E-UTRA disable是因为接收到EMM cause #14 “EPS services not allowed in this PLMN”, 当UE关机并且重新或者USIM卡移除时，UE应当重新enable E-UTRA能力。如果E-UTRA能力disable是因为其他原因，UE应该按照如下方式来enable E-UTRA能力：

UE操作模式从CS/PS mode 1转换到CS/PS mode 2

UE操作模式从PS mode 1转换到PS mode 2

UE关机重启或者USIM移除。

作为实现的一个选择选项，当UE 的attach 尝试计数器或者TAU尝试计数器到达5时，UE may可能开启一个enable E-UTRA的定时器，并UE disable E-UTRA能力subclauses 5.5.1.3.4.3, 5.5.1.3.6, 5.5.3.3.4.3 and 5.5.3.3.6.。一旦这个定时器超时：

如果UE在 Iu mode or A/Gb mode，并且在idle状态（specified in 3GPP TS 24.008 [13]），一旦定时器超时，UE应该enable E-UTRA能力。

如果UE在 Iu mode or A/Gb mode，并且RR连接存在，UE应该延迟enable E-UTRA能力直到RR连接释放。

如果UE在 Iu mode ，并且PS连接存在，但是RR连接不存在，UE may可能在enable E-UTRA能力之前终止PS连接。

对于其他的情况，视UE的实现来决定什么时候enable E-UTRA 能力。

4.6 Applicability of procedures

4.6.1 Relay nodes

中继节点应该支持对于一个支持S1模式的UE必选的所有的过程。

也有一个功能仅仅适用于中继节点，在那样的情况下使用名字”中继节点“代替”ＵＥ“．