TS24301R8学习总结1.docx

TS24301R8学习总结1.docx

《TS24301R8学习总结1.docx》由会员分享，可在线阅读，更多相关《TS24301R8学习总结1.docx（86页珍藏版）》请在冰豆网上搜索。

TS24301R8学习总结1

⏹NAS协议实现的主要功能

Ø支持UE的移动性管理（EMM）；

Ø支持会话管理规程（ESM），用以建立并维持UE和PDN之间的IP连接。

注：

为了为用户提供“随时可用”和“永远在线”的体验，需要将附着过程中的EMM和ESM结合起来。

⏹EMM和ESM的结合

在EPS附着过程中，网络侧会激活一个默认的EPS承载上下文。

此外，还会激活一个或多个专用的EPS承载上下文。

为了实现这个目的，用于激活EPS默认承载的ESM消息，是在EMM消息的一个信元（informationelement）中传送的。

UE侧和网络侧同时执行附着流程，EPS默认承载上下文激活流程，和EPS专用承载上下文激活流程。

UE侧和网络侧在完成EPS专用承载上下文激活过程之前，需要完成EPS默认承载上下文激活流程与附着流程的结合。

附着流程是否成功取决于EPS默认承载上下文激活流程是否成功。

如果附着流程失败，那么ESM流程也会失败。

除附着流程之外，在EMM流程期间，ESM消息的传输需要挂起（即EMM和ESM不能同时进行？

）。

⏹UE的运行方式

UE附着到EPS服务，可以在以下操作模式下运行：

ØPS运行方式：

UE仅注册EPS服务；

ØCS/PS运行方式1：

UE可以配置为使用CS域，并且优先使用non-EPS服务；

ØCS/PS运行方式2：

UE可以配置为使用CS域，并且优先使用EPS服务。

NAS安全

⏹用于鉴权、完整性保护和加密的安全参数被绑定在EPS安全上下文中，并通过一个E-UTRAN中的密钥集标示符（eKSI，keysetidentifier，类似于索引）来识别。

⏹在安全激活之前，MME和UE需要创建EPS安全上下文。

通常情况下，EPS安全上下文是在MME和UE的鉴权过程中创建的。

另外，在系统之间的切换过程中（如从A/Gb模式切换到S1模式或者从Iu模式切换到S1模式），MME和UE会产生一个mappedEPS安全上下文，这个mappedEPS安全上下文是从UE在A/Gb模式或Iu模式下已经创建的UMTS安全上下文推算出来的。

⏹eKSI，是由MME在鉴权过程中分配的，或者在系统之间切换时，MME从mapped安全上下文中分配。

eKSI可以用来在下一次NAS信令连接时交换安全信息，而不必重新执行一个鉴权流程。

⏹当UE被要求删除一个eKSI时，UE应该将与该eKSI关联的所有密钥均视为无效。

⏹UE和MME应该能够同时维护两个EPS安全上下文,因为:

Ø重复鉴权后，UE和MME会同时存在currentEPS安全上下文和newEPS安全上下文（尚未启用）；

Ø系统之间的切换后，UE和MME会同时存在mappedEPS安全上下文（current…）和nativeEPS安全上下文（之前创建）。

⏹UE和MME需要维护的EPS安全上下文的数目由以下几个需求决定：

Ø（重）鉴权成功后，MME和UE需要删除所有旧的不同于current的EPS安全上下文。

Ø当一个新的EPS安全上下文通过SMC流程投入使用时，MME和UE需要删除之前的currentEPS安全上下文。

当一个新的EPS安全上下文在inter-system期间投入使用时，MME和UE应该删除之前的currentnativeEPS安全上下文。

Ø当MME和UE在inter-system切换期间产生了一个新的EPS安全上下文时，MME和UE需要删除所有存在的mappedEPS安全上下文。

Ø当一个nativeEPS安全上下文投入使用时，MME和UE需要删除所有的mappedEPS安全上下文。

注：

UE从EMM-CONNECTED状态变换到EMM-IDLE状态时，需要保存currentEPS安全上下文。

⏹创建mappedEPS安全上下文

ØUE在inter-system间切换，需要启动TAU流程，在该过程中，为了使UE生成mappedEPS安全上下文，MME需要产生一个KSISGSN，创建一个nonceMME和用该nonceMME产生一个K’ASME。

ØMME在移交给E-UTRAN的NAS安全信息（securitytransparentcontainer）中应该包括选择的NAS算法，nonceMME和产生的KSISGSN（与K’ASME关联）。

ØMME需要从K’ASME推算出EPSNAS相关密钥。

并且复位mappedEPS安全上下文的downlinkNASCOUNT。

⏹为NAS消息建立安全交换（环境）

Ø通过NAS信令连接进行的NAS消息的安全交换，一般是MME在附着流程中通过启动SMC流程进行创建的。

Ø成功完成SMC流程后，除4.4.4and4.4.5指定的消息外，所有的UE和MME之间NAS消息的交换都要用currentEPS安全算法进行加密和完整性保护。

⏹在inter-system间切换过程中，MME和UE之间NAS消息的安全交换通过以下几步建立：

Ø与NAS安全传输有关的参数封装进AS信令中，这些AS信令是触发inter-system切换时从MME到UE传输的。

UE利用这些参数生成mappedEPS安全上下文。

Ø切换完成之后，UE侧发起TRACKINGAREAUPDATEREQUEST消息到MME侧。

UE应该使用mappedEPS安全上下文对该消息进行完整性保护。

自此之后，除4.4.4和4.4.5指定的消息外，所有UE和MME之间的NAS消息的交换都要进行加密和完整性保护。

⏹在S1模式之间切换时，NAS消息的安全交换需要继续；在S1模式切换到A/Gb模式或Iu模式后，NAS信令的连接断开，NAS消息不再进行安全交换。

⏹当处于EMM-IDLE模式的UE建立了一个新的NAS信令连接并且有一个有效的currentEPS安全上下文时，NAS消息的安全交换可以通过以下方式进行重建（略）。

⏹安全密钥的变化

当MME启动一个重鉴权来创建newEPS安全上下文时，鉴权过程中的消息交换要用currentEPS安全上下文进行加密和完整性保护。

如果存在currentEPS安全上下文，那么UE和MME应该继续使用currentEPS安全上下文，直到MME启动一个SMC流程为止。

由MME发送的SECURITYMODECOMMAND消息包含将要使用的newEPS安全上下文的eKSI。

MME需要使用newEPS安全上下文对消息进行完整性保护，但不用加密。

当UE以SECURITYMODECOMPLETE响应时，它需要使用newEPS安全上下文对发送的消息进行加密和完整性保护。

MME也可以修改currentEPS安全上下文或者使用一个已经存在的nativeEPS安全上下文。

这时，MME发送一个包含将要修改的EPS安全上下文的eKSI和新选定的NAS安全算法的SECURITYMODECOMMAND消息。

在这种情况下，MME需要使用修改的EPS安全上下文对SECURITYMODECOMMAND消息进行完整性保护，但不加密。

当UE回复SECURITYMODECOMPLETE消息时，UE需要使用修改的EPS安全上下文对该消息进行加密和完整性保护。

NASCOUNT和NAS序列号的处理

⏹有两个NASCOUNT：

uplinkNASCOUNT和downlinkNASCOUNT。

⏹NASCOUNT由NASsequencenumber（低有效位）和NASoverflowcounter（高有效位）串联而成。

共24bit。

由UE和MME独自维护。

⏹当NASCOUNT作为加密函数等的参数时，需要对高位补0，组成32bit的整数。

⏹UTRAN/GERAN切换到E-UTRAN过程中，如果mappedEPS安全上下文投入使用，那么NASCOUNT均要初始化为0。

⏹NASCOUNT中NASsequencenumber部分会作为NAS信令部分在UE和MME之间进行交换。

每次NAS保护消息发送后，NASCOUNT都要加1（NASsequencenumber部分加1，若溢出，则NASoverflowercounter部分加1）。

⏹Replayprotection：

保证相同的NAS信息仅被接收方接收一次。

⏹完整性保护和验证：

发送方应该使用本地存储的NASCOUNT作为完整性保护算法的输入；

接收方应该使用接收消息中的NASsequencenumber和一个估计的NASoverflowcounter组成的NASCOUNT来作为完整性保护算法的输入。

⏹加密和解密

发送方应该使用本地存储的NASCOUNT作为完整性保护算法的输入；

接收方应该使用接收消息中的NASsequencenumber和一个估计的NASoverflowcounter组成的NASCOUNT来作为完整性保护算法的输入。

⏹NASCOUNTwraparound

当MME检测到NASCOUNT接近卷绕界限（224），MME就会重启一个AKA流程，来创建新的NAS安全上下文，并且将NASCOUNT清0；

同样地，当MME检测到UE’suplinkNASCOUNT接近卷绕界限（224）时，MME会重启一个AKA流程。

如果因为某种原因，在卷绕之前，KASME没有创建成功，那么，MME或UE会释放NAS信令连接。

EMM的基本规程

⏹EMM的主要功能：

支持UE端的移动性管理，比如通知网络侧有关UE当前位置信息和提供用户身份的保密性。

⏹进一步功能：

提供与ESM的连接管理服务和短消息服务

注：

EMM的所有规程是建立在NAS信令连接基础上的。

⏹根据发起的方式，EMM规程可以区分为三种

ØEMM通用规程

在NAS信令连接存在的情况下，EMM通用规程可以随时发起。

由网络侧发起

-GUTI重分配

-鉴权

-SMC

-鉴别

-通知

ØEMM专用规程

任意时间，只能存在一个UE发起的EMM专用规程。

-attach；附着

由UE侧发起，附着网络侧的IMSI用于EPS服务，创建EMM上下文和默认承载

-detach；去附着

由UE侧或者网络侧发起，去附着IMSI，释放EMM上下文和所有承载

-正常TAU（S1modeonly）

在EMM上下文已经创建的基础上，由UE发起

-周期性TAU（S1modeonly）

TAU过程也可用来请求预留资源来发送数据。

ØEMM连接管理规程（S1modeonly）

-servicerequest；服务请求

由UE发起，用以创建到网络侧的安全连接或请求预留资源。

服务请求只能在没有UE发起的EMM专用规程运行的时候才可由UE发起。

-寻呼规程

由网络侧发起，用以请求创建NAS信令连接或者提示UE在网络失败的情况下进行重附着。

-NAS信息传送

由UE侧或者网络侧发起，用以传输NAS消息。

注：

在EMM专用规程进行的时候，不能发起NAS消息传输过程

EMM模式和NAS信令连接

⏹建立NAS信令连接

Ø当UE处于EMM-IDLE模式，并且有NAS消息要传输时，就会请求低层建立NAS信令连接。

（向低层提供RRC创建原因和呼叫类型等）

Ø为了让NAS消息传送到（路由到）合适的MME，UENAS需要向低层提供S-TMSI（精简的标示符）或者注册的全球唯一MME标示符（GUMMEI，globallyuniqueMMEidentifier；由PLMNID、MME组ID、MME编码组成）

-当UE在建立NAS信令连接过程中注册到了当前小区的TA时，UENAS需要向低层提供S-TMSI（无须提供MMEID）。

例外情况是，当UE处于EMM-IDLE模式，并发起一个TAU流程（为了达到负载均衡的目的）时，UENAS无须向低层提供S-TMSI或者MMEID。

-如果UE在建立NAS信令连接过程中没有注册到当前小区的TA，UENAS无须向低层提供S-TMSI。

如果UE在之前的注册中存在一个有效的已注册的MMEID，那么，UENAS需要向低层提供该注册的MMEID。

⏹释放NAS信令连接

-由网络侧发起。

Ø为了允许网路侧释放NAS信令连接，UE会在以下几种情况下启动T3340定时器：

a）UE接收到任一EMM原因号为#11，#12，#13，#14或#15；或

b）UE在没有置TRACKINGAREAUPDATEREQUEST消息的“active”flag的情况下，接收到一个TRACKINGAREAUPDATEACCEPT消息。

也就是说，TAU规程在EMM-IDLE模式下发起。

注：

T3340定时器超时后，UE需要在本地释放NAS信令连接。

Ø在上述情况b下

-根据低层传来的建立UPRB（userplaneradiobears）的指示，UE应该停止T3440定时器，并且通过存在的NAS信令连接发送上行信令或者通过UPbears发送用户数据。

-如果收到DETACHREQUEST消息，UE应该停止T3440并且相应网络侧发起的去附着请求。

⏹禁止跟踪区列表

UE需要存储一个“漫游的禁止区列表”（"forbiddentrackingareasforroaming"）和“局部服务禁止区列表”（"forbiddentrackingareasforregionalprovisionofservice"），根据不同情况删除，添加和修改。

⏹S101模式下禁止PLMNs列表forattach（ListofforbiddenPLMNsforattachinS101mode）

⏹等效的PLMNs列表（EquivalentPLMNslist）

⏹周期性TAU定时器的处理

ØPeriodicTAU用来周期性地通知网络侧可用的UE（信息），这个过程通过UE中periodicTAU定时器（T3412）来控制。

T3412的值由网络侧到UE侧的ATTACHACCEPTmessage消息或者TRACKINGAREAUPDATEACCEPT消息中提取。

Ø当T3412定时到达，periodicTAU流程将被启动，并且T3412的值赋初值。

EMM通用规程

⏹GUTIreallocationprocedure

◆GUTI概念：

ØGUTI（GloballyUniqueTemporaryUEIdentity），是在网路侧和UE之间信令交互时，为UE分配的一个临时ID。

这样可以避免标识用户身份的IMSI在空口上传输，保护用户信息不被窃取。

ØGUTI包含了3部分信息：

-M-TMSI：

UE的ID

-MMEIdentifier：

服务MME的ID

-注册的PLMN

◆GUTI综述

Ø功能：

-为UE分配GUTI

-为UE提供newTAIlist（可选）

ØGUTIreallocationprocedure只能由MME在EMM-REGISTERED状态下发起；也可在attach和TAU流程中隐式地执行GUTI重配规程。

ØNOTE

-GUTI重配规程一般以加密模式执行

-一般情况下，GUTI重配与其他移动管理规程作为TAU的一部分。

◆具体流程

Ø网络侧发起GUTI重配规程：

网络侧向UE侧发送GUTIREALLOCATIONCOMMAND消息，并且启动T3450定时器；

该消息包含GUTI（也可能包含TAIlist）

ØUE侧完成GUTI重配（后）的操作

UE侧从GUTIREALLOCATIONCOMMAND消息中提取并存储GUTI和TAIlist后，向MME发送一个GUTIREALLOCATIONCOMPLETE消息。

UE把新的GUTI置为有效，旧的GUTI置为无效；

如果GUTIREALLOCATIONCOMMAND消息中包含TAIlist，那么UE把新的TAIlist置为有效，旧的TAIlist置为无效，否则，旧的TAIlist仍为有效；

Ø网路侧完成GUTI重配（后）的操作

当MME收到UE回送的GUTIREALLOCATIONCOMPLETE消息后，MME停止定时器T3450的计时并将之前发送的新的GUTI置为有效，旧的GUTI置为无效，（若包含TAIlist，则作同样地处理）。

◆UE侧出现的异常情况

a）GUTIREALLOCATIONCOMPLETE消息发送失败，并且低层指示TAI发生改变。

（如因为移动而造成小区切换）

-如果当前TAI不在TAIlist中，那么GUTI重配规程将停止，并且启动一个TAU规程；

-如果当前TAI仍在TAIlist中，那么由UE决定如何重新运行正在运行的GUTI重配规程（个人理解：

完全重新运行或者接着之前状态运行）。

b）GUTIREALLOCATIONCOMPLETE消息发送失败，并且低层指示没有TAI改变。

-由UE侧决定如何重新运行GUTI重配规程。

◆网络侧出现的异常情况

a）低层（链路）失败

如果网络侧在收到GUTIREALLOCATIONCOMPLETE消息之前发生低层（链路）失败，那么网络侧会视newGUTI和oldGUTI均为有效，若有TAIlist，同理。

期间，网络侧将会：

-首先使用oldGUTI中的oldS-TMSI在oldTAIlist中进行寻呼尝试，如果之前的GUTIREALLOCATIONCOMMAND消息中配合oldGUTI有newTAIlist，那么newTAIlist也应该用于寻呼。

根据UE侧的响应，网络侧可以重启GUTI重配规程。

如果在oldandnewTAIlist域中收到响应，那么网络侧应该重启GUTI规程；如果没有收到响应，那么网路侧应该使用newGUTI中的newS-TMSI来进行寻呼尝试。

在这种情况下，如果GUTIREALLOCATIONCOMMAND消息中配合newGUTI有newTAIlist，那么应该使用newTAIlist来代替oldTAIlist。

根据UE侧响应，网络侧应该视newGUTI为有效，oldGUTI为无效。

（疑：

oldGUTI和newGUTI如何划分的？

之所以进行GUTI重配，是因为GUTI可能发生了变化，这样就有old和new之分了）

-如果网络侧需要建立NAS信令连接，那么网路侧需要使用IMSI进行寻呼。

（理解为原始的手机号，此时可被它人识别）

-如果UE使用newGUTI那么将newGUTI视为有效，此外，与之关联的newTAIlist亦为有效。

-如果UE使用oldGUTI，那么新的GUTI重配规程之后可以紧跟一个鉴别规程。

b）T3450超时

GUTI重配过程的时间由T3450控制，如果T3450超时，那么网络侧需要复位并重启T3450，然后重传GUTIREALLOCATIONCOMMAND消息。

这样的重复过程只能进行四次，如果T3450第五次超时，那么网络侧要中止重配规程，并按规则进行相应处理。

c）GUTI重配和EPS附着流程发生冲突

（疑：

同一UE的附着流程？

通用规程不是在NAS信令连接基础上进行的吗？

NAS信令连接应该象征着UE已经附着了吧？

那么，为何又发起附着流程呢？

）

-如果网络侧在完成GUTI重配之前收到ATTACHREQUEST消息，那么，网络侧需要在删除EMM上下文之后处理附着流程。

d）GUTI重配和UE发起的detach规程冲突

-同上，需要中止GUTI重配，并处理detach规程

e）GUTI重配和TAU规程冲突

-同上，网路侧需要先中止当前GUTI重配规程，然后处理TAU规程，之后再执行一个新的GUTI重配规程。

f）GUTI重配和servicerequest规程冲突

同上，网络侧会同时处理两个规程

（疑：

与各自独立处理有区别吗？

如果没有区别，那么应该就没有冲突之说了吧？

）

g）低层指示，因为切换原因，NASPDU没有递交成功

-在MME内部切换，且目标TA在TAIlist中时，如果GUTIREALLOCATIONCOMMAND消息没有递交成功，那么在MME内部切换成功后，MME需要重传GUTIREALLOCATIONCOMMAND消息。

如果低层指示切换失败，并且SI信令连接存在，那么MME亦需重传GUTIREALLOCATIONCOMMAND消息。

注：

如果在随后的GUTIREALLOCATIONCOMMAND消息中包含一个不同的newGUTI和可选的newTAIlist，那么UE同样认为这个最新的GUTI和TAIlist是有效的。

EMM专用规程

⏹概述

Ø附着流程用于附着到EPC，享用EPS的分组服务。

Ø附着的两个目的

-工作于PS操作模式的UE附着进行EPS服务；

-工作于CS/PSmode1或者CS/PSmode2的UE附着进行EPS和non-EPS服务。

Ø附着成功后，会在MME中建立UE的上下文，UE和PDNGW之间建立默认负载，因此为UE提供“永远在线”的IP连接。

网络侧也可能会在附着过程中激活一个专用承载。

Ø附着过程中，UE也会获得IPv4和IPv6地址的本地代理

Ø在共享网络中，UE应该选择一个PLMNID，UE将选择的PLMNID和系统广播消息中的TAC（trackingareacode）组合成TAI。

选择的PLMNID需要向E-UTRAN说明。

每当UE接收到一个EMMcause#11“PLMNnotallowed”的TRACKINGAREAUPDATINGREJECT消息，之前选择的PLMNID都将被存储到“forbiddenPLMNlist”中。

每当UE接收到一个EMMcause#13“roamingnotallowedinthistrackingarea”的TRACKINGAREAUPDATINGREJECT消息，或者#12“trackingareanotallowed”，或者#15“nosuitablecellsintrackingArea”，与之相关的TAI存储到相应的list中。

Ø一个附着计数器用来限制因附着失败而继续尝试附着的次数。

根据计数器的值执行不同的特殊操作。

在以下情况下，复位该计数器：

-UE开机；

-USIM卡插入；

-一个附着规程成功完成；

-用于EPS服务的combinedEPSattachprocedure因为cause#2、#16、#17、#18or#22而完成；

-一次附着过程cause#11、#12、#13、#14、#15or#25而被拒绝；

-网络侧启动detach规程，并因为cause#11、#12、#13、#14、#15or#25而完成。

此外，当UE在EMM-DEREGISTERED.ATTEMPTING-TO-ATTACH子状态下并且进入一个newTA或者T3402超时时，附着计数器也会复位。

◆用于EPS服务的附着规程

UE启动该规程仅用于EPS服务（非on-EPS）。

当UE启动EPS附着规程时，UE应该以EPSattachtypeIE来启动“EP