TS24301-R8学习总结(1)

更新时间:2024-06-16 07:29:01 阅读量: 综合文库 文档下载

说明:文章内容仅供预览,部分内容可能不全。下载后的文档,内容与下面显示的完全一致。下载之前请确认下面内容是否您想要的,是否完整无缺。

? NAS协议实现的主要功能

? 支持UE的移动性管理(EMM);

? 支持会话管理规程(ESM),用以建立并维持UE和PDN之间的IP连接。

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

? EMM和ESM的结合

在EPS附着过程中,网络侧会激活一个默认的EPS承载上下文。此外,还会激活一个或多个专用的EPS承载上下文。

为了实现这个目的,用于激活EPS默认承载的ESM消息,是在EMM消息的一个信元(information element)中传送的。

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,key set identifier,类似于索引)来识别。

? 在安全激活之前,MME和UE需要创建EPS安全上下文。通常情况下,EPS安全上下文是在MME和UE的鉴权过程中创建的。另外,在系统之间的切换过程中(如从A/Gb模式切换到S1模式或者从Iu模式切换到S1模式),MME和UE会产生一个mapped EPS安全上下文,这个mapped EPS安全上下文是从UE

在A/Gb模式或Iu模式下已经创建的UMTS安全上下文推算出来的。

? eKSI,是由MME在鉴权过程中分配的,或者在系统之间切换时,MME从mapped 安全上下文中分配。eKSI可以用来在下一次NAS信令连接时交换安全信息,而不必重新执行一个鉴权流程。

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

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

? 重复鉴权后,UE和MME会同时存在current EPS安全上下文和new EPS安全上下文(尚未启用); ? 系统之间的切换后,UE和MME会同时存在mapped EPS安全上下文(current …)和native EPS安全上下文(之前创建)。

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

? (重)鉴权成功后,MME和UE需要删除所有旧的不同于current的EPS安全上下文。 ? 当一个新的EPS安全上下文通过SMC流程投入使用时,MME和UE需要删除之前的current EPS安全上下文。当一个新的EPS安全上下文在

inter-system期间投入使用时,MME和UE应该删除之前的current nativeEPS安全上下文。 ? 当MME和UE在inter-system切换期间产生了一个新的EPS安全上下文时,MME和UE需要删除所有存在的mapped EPS安全上下文。 ? 当一个native EPS安全上下文投入使用时,MME和UE需要删除所有的mapped EPS安全上下文。

注:UE从EMM-CONNECTED状态变换到EMM-IDLE状态时,需要保存current EPS 安全上下文。 ? 创建mapped EPS 安全上下文

? UE在inter-system间切换,需要启动TAU流程,在该过程中,为了使UE生成mapped EPS安全上下文,MME需要产生一个KSISGSN,创建一个nonceMME和用该nonceMME产生一个K’ASME。 ? MME在移交给E-UTRAN的NAS安全信息(security transparent container)中应该包括选择的NAS算法,nonceMME和产生的KSISGSN(与K’ASME关联)。

? MME需要从K’ASME推算出EPS NAS 相关密钥。并且复位mapped EPS安全上下文的downlink NAS COUNT。

? 为NAS消息建立安全交换(环境)

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

? 成功完成SMC流程后,除4.4.4 and 4.4.5指定的消息外,所有的UE和MME之间NAS消息的交换都要用current EPS安全算法进行加密和完整性保护。 ? 在inter-system间切换过程中,MME和UE之间NAS消息的安全交换通过以下几步建立:

? 与NAS安全传输有关的参数封装进AS信令中,这些AS信令是触发inter-system切换时从MME到UE传输的。UE利用这些参数生成mappedEPS安全上下文。

? 切换完成之后,UE侧发起TRACKING AREA UPDATE REQUEST消息到MME侧。UE应该使用mappedEPS安全上下文对该消息进行完整性保护。自此之后,除4.4.4和4.4.5指定的消息外,所有UE和MME之间的NAS消息的交换都要进行加密和完整性保护。

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

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

? 安全密钥的变化

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

如果存在current EPS安全上下文,那么UE和MME应该继续使用current EPS安全上下文,直到MME启动一个SMC流程为止。由MME发送的SECURITY MODE COMMAND消息包含将要使用的new EPS安全上下文的eKSI。MME需要使用new EPS安全上下文对消息进行完整性保护,但不用加密。当UE以SECURITY MODE COMPLETE响应时,它需要使用new EPS安全上下文对发送的消息进行加密和完整性保护。 MME也可以修改current EPS安全上下文或者使用一个已经存在的native EPS安全上下文。这时,MME发送一个包含将要修改的EPS安全上下文的eKSI和新选定的NAS安全算法的SECURITY MODE COMMAND消息。在这种情况下,MME需要使用修改的EPS 安全上

下文对SECURITY MODE COMMAND消息进行完整性保护,但不加密。当UE回复SECURITY MODE COMPLETE消息时,UE需要使用修改的 EPS安全上下文对该消息进行加密和完整性保护。

NAS COUNT和NAS序列号的处理

? 有两个NAS COUNT:uplink NAS COUNT和downlink NAS COUNT。

? NAS COUNT由NAS sequence number(低有效位)和NAS overflow counter(高有效位)串联而成。共24bit。由UE和MME独自维护。

? 当NAS COUNT作为加密函数等的参数时,需要对高位补0,组成32bit的整数。

? UTRAN/GERAN切换到E-UTRAN过程中,如果mapped EPS安全上下文投入使用,那么NAS COUNT 均要初始化为0。

? NAS COUNT中NAS sequence number部分会作为NAS信令部分在UE和MME之间进行交换。每次NAS保护消息发送后,NAS COUNT都要加1(NAS sequence number部分加1,若溢出,则NAS overflower counter部分加1)。

? Replay protection:保证相同的NAS信息仅被接收方接

收一次。

? 完整性保护和验证:

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

接收方应该使用接收消息中的NAS sequence number和一个估计的NAS overflow counter组成的NAS COUNT来作为完整性保护算法的输入。

? 加密和解密

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

接收方应该使用接收消息中的NAS sequence number和一个估计的NAS overflow counter组成的NAS COUNT来作为完整性保护算法的输入。

? NAS COUNT wrap around

当MME检测到NAS COUNT接近卷绕界限(224),MME就会重启一个AKA流程,来创建新的NAS安全上下文,并且将NAS COUNT 清0;

同样地,当MME检测到UE’s uplink NAS COUNT 接近卷绕界限(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(S1 mode only)

在EMM上下文已经创建的基础上,由UE发起 - 周期性TAU(S1 mode only)

TAU过程也可用来请求预留资源来发送数据。 ? EMM连接管理规程(S1 mode only) - service request;服务请求

由UE发起,用以创建到网络侧的安全连接或请求预留资源。服务请求只能在没有UE发起的EMM专用规程运行的时候才可由UE发起。 - 寻呼规程

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

由UE侧或者网络侧发起,用以传输NAS消息。 注:在EMM专用规程进行的时候,不能发起NAS消息

传输过程

EMM模式和NAS信令连接

? 建立NAS信令连接

? 当UE处于EMM-IDLE模式,并且有NAS消息要传输时,就会请求低层建立NAS信令连接。(向低层提供RRC创建原因和呼叫类型等)

? 为了让NAS消息传送到(路由到)合适的MME,UE NAS需要向低层提供S-TMSI(精简的标示符)或者注册的全球唯一MME标示符(GUMMEI,globally unique MME identifier;由PLMN ID、MME组ID、MME编码组成) - 当UE在建立NAS信令连接过程中注册到了当前小区的TA时,UE NAS需要向低层提供S-TMSI(无须提供MME ID)。例外情况是,当UE处于EMM-IDLE模式,并发起一个TAU流程(为了达到负载均衡的目的)时,UE NAS无须向低层提供S-TMSI或者MME ID。

- 如果UE在建立NAS信令连接过程中没有注册到当前小区的TA,UE NAS无须向低层提供S-TMSI。如果UE在之前的注册中存在一个有效的已注册的MME ID,那么,UE NAS需要向低层提供该注册的MME ID。 ? 释放NAS信令连接 - 由网络侧发起。

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

a) UE接收到任一EMM原因号为#11,#12,#13,#14

或#15;或 b) UE在没有置

TRACKING AREA UPDATE REQUEST

消息的

“active”flag的情况下,接收到一个TRACKING AREA

UPDATE ACCEPT

消息。也就是说,TAU规程在

EMM-IDLE模式下发起。

注:T3340定时器超时后,UE需要在本地释放NAS信令连接。 ? 在上述情况b下

- 根据低层传来的建立UP RB(user plane radio bears)的指示,UE应该停止T3440定时器,并且通过存在的NAS信令连接发送上行信令或者通过UP bears发送用户数据。 - 如果收到DETACH REQUEST消息,UE应该停止T3440并且相应网络侧发起的去附着请求。 ? 禁止跟踪区列表

UE需要存储一个“漫游的禁止区列表”( \

roaming\)和“局部服务禁止区列表”( \provision of service\),根据不同情况删除,添加和修改。

? S101模式下禁止PLMNs列表for attach(List of forbidden PLMNs for

attach in S101 mode)

? 等效的PLMNs列表(Equivalent PLMNs list) ? 周期性TAU定时器的处理

? Periodic TAU用来周期性地通知网络侧可用的UE(信息),

这个过程通过UE中periodic TAU定时器(T3412)来控制。T3412的值由网络侧到UE侧的ATTACH ACCEPT message消息或者TRACKING AREA UPDATE ACCEPT消息中提取。

? 当T3412定时到达,periodic TAU流程将被启动,并且T3412的值赋初值。

EMM通用规程

? GUTI reallocation procedure ? GUTI概念:

? GUTI(Globally Unique Temporary UE Identity),是在网路侧和UE之间信令交互时,为UE分配的一个临时ID。这样可以避免标识用户身份的IMSI在空口上传输,保护用户信息不被窃取。 ? GUTI包含了3部分信息: - M-TMSI:UE的ID

- MME Identifier:服务MME的ID - 注册的PLMN

? GUTI综述 ? 功能:

- 为UE分配GUTI

- 为UE提供new TAI list(可选) ? GUTI

reallocation

procedure

只能由

MME

EMM-REGISTERED状态下发起;也可在attach和TAU流程中隐式地执行GUTI重配规程。 ? NOTE

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

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

?

具体流程

UEGUTI REALLOCATION COMMANDMMEStart T3450Stop T3450GUTI REALLOCATION COMPLETE

? 网络侧发起GUTI重配规程:

网络侧向UE侧发送GUTI REALLOCATION COMMAND消息,并且启动T3450定时器;

该消息包含GUTI(也可能包含TAI list)

? UE侧完成GUTI重配(后)的操作

UE侧从GUTI REALLOCATION COMMAND消息中提取并存储GUTI和TAI list后,向MME发送一个GUTI REALLOCATION COMPLETE消息。

UE把新的GUTI置为有效,旧的GUTI置为无效;

如果GUTI REALLOCATION COMMAND消息中包含TAI list,

那么UE把新的TAI list置为有效,旧的TAI list置为无效,否则,旧的TAI list 仍为有效; ? 网路侧完成GUTI重配(后)的操作

当MME收到UE回送的GUTI REALLOCATION COMPLETE 消息后,MME停止定时器T3450的计时并将之前发送的新的GUTI置为有效,旧的GUTI置为无效,(若包含TAI list,则作同样地处理)。 ? UE侧出现的异常情况 a)

GUTI REALLOCATION COMPLETE

消息发送失败,并且低层指示

TAI发生改变。(如因为移动而造成小区切换)

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

- 如果当前TAI仍在TAI list中,那么由UE决定如何重新运行正在运行的GUTI 重配规程(个人理解:完全重新运行或者接着之前状态运行)。 b)

GUTI REALLOCATION COMPLETE消息发送失败,并且低层指示没

有TAI改变。

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

? 网络侧出现的异常情况

a) 低层(链路)失败

如果网络侧在收到GUTI REALLOCATION COMPLETE消息之前发生低层(链路)失败,那么网络侧会视new GUTI和

old GUTI均为有效,若有TAI list,同理。 期间,网络侧将会:

- 首先使用old GUTI中的old S-TMSI在old TAI list中进行寻呼尝试,如果之前的GUTI REALLOCATION COMMAND消息中配合old GUTI有new TAI list,那么new TAI list也应该用于寻呼。根据UE侧的响应,网络侧可以重启GUTI重配规程。如果在old and new TAI list域中收到响应,那么网络侧应该重启GUTI规程;如果没有收到响应,那么网路侧应该使用new GUTI中的new S-TMSI来进行寻呼尝试。在这种情况下,如果GUTI REALLOCATION COMMAND消息中配合new GUTI有new TAI list,那么应该使用new TAI list 来代替old TAI list。根据UE侧响应,网络侧应该视new GUTI为有效,old GUTI 为无效。

(疑:old GUTI和new GUTI如何划分的?之所以进行GUTI重配,是因为GUTI可能发生了变化,这样就有old和new之分了)

- 如果网络侧需要建立NAS信令连接,那么网路侧需要使用IMSI进行寻呼。(理解为原始的手机号,此时可被它人识别) - 如果UE使用new GUTI那么将new GUTI视为有效,此外,与之关联的new TAI list亦为有效。

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

b) T3450超时

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

REALLOCATION COMMAND

GUTI

消息。这样的重复过程只能进行

四次,如果T3450第五次超时,那么网络侧要中止重配规程,并按规则进行相应处理。 c) GUTI重配和EPS 附着流程发生冲突

(疑:同一UE的附着流程?通用规程不是在NAS信令连接基础上进行的吗?NAS信令连接应该象征着UE已经附着了吧?那么,为何又发起附着流程呢?) - 如果网络侧在完成GUTI重配之前收到ATTACH REQUEST消息,那么,网络侧需要在删除EMM上下文之后处理附着流程。

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

- 同上,需要中止GUTI重配,并处理detach规程 e) GUTI重配和TAU规程冲突

- 同上,网路侧需要先中止当前GUTI重配规程,然后处理TAU规程,之后再执行一个新的GUTI重配规程。 f) GUTI重配和service request规程冲突

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

(疑:与各自独立处理有区别吗?如果没有区别,那么应该就没有冲突之说了吧?)

g) 低层指示,因为切换原因,NAS PDU没有递交成功 - 在MME内部切换,且目标TA在TAI list 中时,如果GUTI

REALLOCATION COMMAND消息没有递交成功,那么在

MME内

部切换成功后,MME需要重传GUTI REALLOCATION COMMAND 消息。如果低层指示切换失败,并且SI信令连接存在,那么MME亦需重传GUTI REALLOCATION COMMAND 消息。 注:如果在随后的GUTI REALLOCATION COMMAND 消息中包含一个不同的new GUTI和可选的new TAI list,那么UE同样认为这个最新的GUTI和TAI list是有效的。 EMM专用规程 ? 概述

? 附着流程用于附着到EPC,享用EPS的分组服务。 ? 附着的两个目的

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

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

? 附着成功后,会在MME中建立UE的上下文,UE和PDN GW之间建立默认负载,因此为UE提供“永远在线”的IP连接。网络侧也可能会在附着过程中激活一个专用承载。 ? 附着过程中,UE也会获得IPv4和IPv6地址的本地代理 ? 在共享网络中,UE应该选择一个PLMN ID,UE将选择的PLMN ID和系统广播消息中的TAC(tracking area code)组

合成TAI。选择的PLMN ID 需要向E-UTRAN说明。每当UE接收到一个EMM cause#11“PLMN not allowed”的

TRACKING AREA UPDATING REJECT消息,之前选择的

PLMN ID

都将被存储到“forbidden PLMN list”中。每当UE接收到一个EMM cause#13“roaming not allowed in this tracking area”的

TRACKING AREA UPDATING REJECT

消息,或者#12

“tracking area not allowed”,或者#15“no suitable cells in tracking Area”,与之相关的TAI存储到相应的list中。 ? 一个附着计数器用来限制因附着失败而继续尝试附着的次数。根据计数器的值执行不同的特殊操作。在以下情况下,复位该计数器: - UE 开机; - USIM卡插入;

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

- 用于EPS服务的combined EPS attach procedure因为cause#2、#16、#17、#18or #22而完成;

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

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

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

复位。

? 用于EPS服务的附着规程

UE启动该规程仅用于EPS服务(非on-EPS)。当UE启动EPS附着规程时,UE应该以EPS attach type IE来启动“EPS attach”。 ? 附着流程的启动

当处于EMM-DEREGISTERED状态时,UE向MME发送ATTACH REQUEST消息来启动附着流程,同时启动T3410定时器,并且进入

EMM-REGISTERED-INITIATED

状态。如果定时器

T3402当前正运行,UE需要停止T3402,如果定时器T3411正运行,UE需要停止T3411。

? 如果UE既不支持A/Gb模式也不支持Iu模式,那么UE需要如下处理ATTACH REQUEST消息中的old GUTI或者IMSI IE:

- 如果有,UE需要在ATTACH REQUEST消息中包含一个有效的GUTI和最后访问注册的TAI。如果没有有效地GUTI,UE需要在ATTACH REQUEST消息中包含IMSI。 ? 如果UE支持A/Gb模式或者Iu模式,UE需要如下处理old GUTI或者IMSI IE():

- 如果TIN(Temporary Identity used in Next update)指明了“P-TMSI”,并且UE保存了一个有效的P-TMSI和RAI,那么UE应该将P-TMSI和RAI映射到old GUTI或者IMSI IE中。如果一个P-TMSI signature与P-TMSI相关联,MS需要将其包

含进old P-TMSI signature IE中,此外,如果UE保存了一个有效的GUTI,UE需要在附加的GUTI IE中指明GUTI。 - 如果TIN指明了“GUTI”或者“RAT-ralated TMSI”并且UE保存了一个有效的GUTI,UE需要在old GUTI or IMSI IE中指明GUTI。

- 如果TIN已经删除,并且:1)UE保存了一个有效的GUTI,UE需要在old GUTI or IMSI IE中指明GUTI;2)否则,如果UE保存了一个有效的P-TMSI和RAI,UE需要将P-TMSI和RAI映射进old GUTI or IMSI IE中,如果一个P-TMSI signature与P-TMSI相关联,MS需要将其包含进old P-TMSI signature IE中。

- 否则,UE需要将IMSI包含进old GUTI or IMSI IE中。 ? UE应该在发送ATTACH REQUEST 消息的同时(结合)发送一个PDN CONNECTIVITY REQUEST消息来请求PDN连接(该消息包含在ESM消息IE中)。

? 如果UE支持A/Gb模式或者Iu模式或者UE希望向网络侧指明它的UE specific DRX参数,UE需要在ATTACH REQUEST消息的DRX参数IE包含UE specific DRX 参数。

? 如果存在有效的NAS安全上下文,UE需要对ATTACH REQUEST消息和PDN CONNECTIVITY REQUEST消息进行完整性保护,否则,不用进行完整性保护。

UEStart T3410ATTACH REQUESTMMEStop T3410ATTACH ACCEPTStart T3450ATTACH COMPLETEStop T3450ORATTACH REQUESTStart T3410ATTACH REJECTStop T3410

? EMM通用规程的启动

当网络侧收到一个ATTACH REQUEST消息,该消息中包含old GUTI or IMSI IE and the Additional GUTI IE with the same encoded mobile

identity type \,网络侧应该将前

者作为P-TMSI和RAI,后者作为GUTI。

根据接收到的ATTACH REQUEST 消息中的信息(如IMSI、GUTI和KSI),网路侧可能会启动EMM通用规程(如鉴别、鉴权和SMC规程)。这些规程是在附着规程期间执行的。 ? 网络侧接受(accept)附着

如果网络侧接受了附着请求,MME需要向UE发送一个ATTACH ACCEPT消息,并且启动T3450,MME需要同时发送一个包含在ESM消息IE中的ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST消息来激活专用承载。网络侧也可以启动

一个专用承载的激活流程。

如果网路侧接受了附着请求,MME需要删除存储的UE radio capability information,if any。

如果UE在ATTACH REQUEST消息中包含了UE network capability IE 或者MS network capability IE(UE和MS啥区别?),或者两者皆有,MME需要根据接收IE中定义的最大长度来存储从UE接收的所有字节。

注:这些信息转发到new MME(inter-MME切换)或者new SGSN(inter-system 切换)。

如果在ATTACH REQUEST消息的DRX 参数IE中包含了specific DRX 参数,MME需要用接收参数代替所有存储的UE specific DRX 参数,并将其用于下行信令和数据的传输。 MME应该在ATTACH ACCEPT消息中assign and include UE注册到的TAI list。根据接收到的ATTACH ACCEPT消息,UE应该删除old TAI list并存储接收到的TAI list。UE接收到ATTACH ACCEPT消息后,需要停止T3410。

GUTI重配规程可能作为附着规程的一部分。当ATTACH REQUEST 消息中包含IMSI,或者MME认为UE提供的GUTI无效,或者UE提供的GUTI是另一个MME分配的,MME需要给UE分配一个新的GUTI。此时,MME需要在ATTACH ACCEPT消息中包含进新分配的GUTI和TAI list。在这种情况下,MME应该进入EMM-COMMON-PROCEDURE-INITIATED状态。

在一个共享网络中,TAI list中的TAIs可以包含不同的PLMN ID。 如果ATTACH ACCEPT消息中包含一个GUTI,UE应该将该GUTI作为新的temporary identity。UE需要删除old GUTI并存储新分配的GUTI。反之,UE需要保存old GUTI(if any available)。 如果UE支持A/Gb模式或者Iu模式,当接收到ATTACH ACCEPT 消息后,UE需要将它的TIN设置为“GUTI”。

MME也可能在ATTACH ACCEPT消息中包含一个等效PLMNs的列表,列表的每个入口包括一个PLMN code(MCC+MNC),UE从forbidden PLMNs列表中删除相应的PLMN code后,将其存储起来。此外,UE加入到该注册的PLMN中。每当UE接收到ATTACH ACCEPT消息,UE都会替换stored list。如果ATTACH ACCEPT消息中不包含list,UE要删除存储的list。 当UE接收到一个绑定了

REQUEST消息的

ACTIVATE DEFAULT EPS BEARER CONTEXT

ATTACH ACCEPT消息时,UE应该将该ACTIVATE

ESM子层。一

DEFAULT EPS BEARER CONTEXT REQUEST消息前转/送到

旦从ESM子层收到默认EPS承载上下文已经激活的指示,UE将会与ATTACH COMPLETE消息一起向网络层发送一个包含在ESM消息IE中的ACTIVATE DEFAULT EPS BEARER CONTEXT ACCEPT消息。

此外,UE需要复位附着计数器和TAU计数器,进入EMM-REGISTERED状态并设置EPS update status为EU1 UPDATED。

如果UE在附着规程期间接收到任何的

BEARER CONTEXT REQUEST消息,UE

ACTIVATE DEDICATED EPS

需要将该消息送到ESM子层,

并且在成功附着后对该消息send a response。

如果附着规程是在S101模式下启动的,那么必须通知低层规程的成功完成。

一旦接收到ATTACH COMPLETE消息,MME要停止T3450,进入EMM-REGISTERED状态,并将ATTACH ACCEPT消息中的GUTI置为有效。 ? 网路侧拒绝附着

如果网路侧不能接受附着请求,MME需要向UE发送一个包含相应EMM cause value 的ATTACH REJECT消息。如果附着规程是因为默认承载创建失败,或者ESM规程失败等MME应该在ATTACH REJECT消息中绑定一个包含在ESM消息IE中的PDN CONNECTIVITY REJECT消息。在这种情况下,EMM cause value应被置为#19—“ESM failure”。

一旦接收到ATTACH REJECT消息,UE应该停止T3410,并且根据不同的EMM cause value 作以下处理: 略。。。

? UE侧发生的异常

a) 访问阻止,因为access class barring 或者NAS信令连接

被网路侧拒绝。如果因为“信令”而拒绝,附着流程将不能启动。UE在当前服务小区并执行小区重选流程。当

“信令”连接正常后,附着流程立即启动。

b) 在接收到ATTACH ACCEPT or ATTACH REJECT 消息

之前发生低层链路失败或者NAS信令连接断开。此时,附着流程将被中止。 c) T3410

UE中止附着流程,NAS信令连接在本地释放。 d) EMM cause value之外的ATTACH REJECT

e) 进入new TA。如果一个附着流程完成之前进入一个new

TA,附着流程需要中止并且立即重启。如果TA切换发生在ATTACH ACCEPT之后但是ATTACH COMPLETE之前,那么附着流程需要重启。如果附着流程(前一个)期间分配了一个GUTI,那么这个GUTI应该应用在附着流程(后一个)中。

f) Mobile originated detach required

如果一个附着流程需要中止,UE启动一个detach procedure。 g) 与detach 流程冲突

UE在EMM-REGISTERED-INITIATED期间接收到DETACH REQUEST消息,并且detach type

指明“re-attach not required”,那么,detach 流程将被执行,attach 流程中止;否则,attach流程将被执行,DETACH REQUEST消息被忽略。

h) 底层指示ATTACH REQUEST消息或者ATTACH

COMPLETE小时发送失败。 UE重启附着流程 i)

如果与ATTACH ACCEPT消息绑定的ACTIVATE DEFAULT

BEARER CONTEXT REQUEST消息因为

UE ESM子层原因被

UE拒绝,UE需要启动detach规程。 j)

底层指示S101模式到S1模式的切换被取消,UE应中止附着流程并进入态。

- 对于case b,c,d UE作如下处理:

T3410停止计时,附着次数计数器加1(除非已经为5) - 如果附着计数器小于5: T3411启动,状态改为

EMM-DEREGISTERED.ATTEMPTING-TO-ATTACH。EMM-DEREGISTERED.NO-CELL-AVAILABLE

当T3411超时,重启附着流程。 - 如果附着次数计数器为5

UE删除所有的GUTI,TAI list,最后访问注册的TAI,等效PLMNs列表 和 KSI;设置update status为EU2 NOT UPDATED,并且启动T3402.UE状态改为

EMM-DEREGISTERED.ATTEMPTING-TO-ATTACH或

者可选的EMM-DEREGISTERED.PLMN-SEARCH来执行PLMN重选。 如果UE支持A/Gb模式或者Iu模式,UE需要额外的处理GMM参数,GMM状态,GPRS update status,P-TMSI,P-TMSI

signature,RAI和GPRS加密密钥序列号等。 ? 网络侧发生的异常 a) 底层失败

如果在MME收到ATTACH COMPLETE消息之前发生低层失败,并且已经分配了new GUTI。此时,网路侧应将old 和 new GUTI均置为有效;直到old GUTI被网路侧认为无效之前,网路侧不能重发ATTACH ACCEPT。在这期间,网路侧应该:启动一个鉴别过程,之后是一个GUTI重配过程(如果old GUTI被UE在随后的消息中使用)。 b) Protocol error c) T3450暂停

T3450第一次超时,网络侧重发ATTACH ACCEPT消息,并且复位重启T3450。这个重发过程只能重复4次,当第五次超时时,附着流程应该中止。

d) 在ATTACH ACCEPT消息发送之后且ATTACH COMPLETE

消息接收之前又接收到了ATTACH REQUEST消息 - 如果在前后两次接收到的ATTACH REQUEST消息中有一个或多个IE不同,那么之前的附着流程将中止,新的附着流程继续;

- 如果IE相同,那么ATTACH ACCEPT消息将被重发,并且重启T3450(与之相关联的重发(附着)计数器不增1) e) 接收到多于一个的ATTACH REQUEST,并且没有发送

ATTACH ACCEPT 或者ATTACH REJECT消息

基本同上,如果前后消息中IE不同,那么中止之前的附着请求并执行新的附着流程;如果IE相同,那么继续之前的附着流程,并忽略之后的附着请求。

f) 在EMM-REGISTERED状态下接收到ATTACH REQUEST

消息

此时,网络侧会启动EMM通用规程,如果该ATTACH REQUEST消息是已经附着的UE发来的,网路侧将删除其对应的EMM上下文,EPS承载上下文,并处理这个新的ATTACH REQUEST。

g) 在ATTACH COMPLETE消息之前接收到TRACKING AREA

UPDATE REQUEST消息

T3450将停止。分配的GUTI置为有效,执行TAU流程。

? 一个TAU尝试计数器用来限制被拒绝的TAU尝试的次数;该TAU尝试计数器在以下情况下复位: - 一个附着流程成功完成; - 一个TAU流程成功完成;

- 一个TAU流程被拒绝,因为以下原因:EMM cause#11、#12、#13、#14、#15、#25。 此外,当UE处于

EMM-REGISTERED.ATTEMPTING-TO-UPDATE

或者

EMM-REGISTERED.ATTEMPTING-TO-UPDATE-MM

子状态,并且进入一

个新的TA或者T3402超时时,TAU尝试计数器也要复位。

? 正常和周期TAU规程 ? 概述

周期TAU通过UE中的T3412定时器来控制,当T3412定时器超时时,周期TAU规程启动。

? Combined attach procedure for EPS services and non-EPS service(S1 mode only) ? 概述

联合EPS附着流程用于工作在CS/PS mode1或者CS/PS mode2的UE请求EPS和non-EPS服务。

联合EPS附着流程也用于工作于。。。的UE在已经附着到non-EPS服务的情况下附着到EPS服务。

在这种情况下,UE应该启动EPS attach type IE为“combined EPS/IMSI attach”的联合EPS附着流程。 ? 联合附着流程的启动

处于EMM-DEREGISTERED状态的UE通过向网路侧发送一个ATTACH REQUEST消息来启动联合附着流程,启动T3410并进入EMM-REGISTERED-INITIATED状态。

如果没有有效的TMSI,UE需要在TMSI状态IE中包含有关信息。此外,如果UE存储了一个有效的本地ID,UE应该将其添加进ATTACH REQUEST消息侧old location area ID IE中。 ? EMM通用规程的启动

根据获得的信息,比如IMSI、GUTI、KSI等,网络侧可能启

动EMM通用规程。 ? 网络侧接受联合附着 ? Combined attach successful

以下是attach for non-EPS service的情形?:

TMSI重分配可能作为联合附着流程的一部分,then分配的TMSI与LAI(location area identification)被包含进ATTACH ACCEPT消息中。这种情况下,MME启动T3450,并进入EMM-COMMON-PROCEDUE-INITIATED状态。

UE接收到ATTACH ACCEPT消息后,存储接收到的LAI,停止T3410,reset the location update attempt counter and set the update status to U1 UPDATE。如果消息中包含一个IMSI,说明UE没有被分配任何的TMSI,此时,UE应删除相应的所有TMSI。如果消息中包含一个TMSI,那么,UE应将该TMSI作为new temporary ID。UE删除old TMSI并存储new TMSI。如果ATTACH ACCEPT消息中既不包含TMSI也不包含IMSI,UE将使用任何可得的old TMSI。 如果收到一个联合有

REQUEST消息的

ACTIVATE DEFAULT EPS BEARER CONTEXT

ATTACH ACCEPT消息,UE应向网路侧发送

一个联合有ACTIVATE DEFAULT EPS BEARER CONTEXT ACCEPT消息的ATTACH COMPLETE

消息。此后,UE

进入

EMM-REGISTERED状态和MM-IDLE状态,并设置EPS update status to EU1 UPDATE。

(疑:承载的建立应该是UE侧主动发起的吧?为何此处是网络侧向UE发起建立承载请求呢?)

当接收到UE发来的ATTACH COMPLETE消息后,MME停止T3450,进入EMM-REGISTERED状态,并将新的TMSI置为有效。

? 仅用于EPS 服务的联合附着成功 以下仅针对non-EPS service only?:

根据ATTACH ACCEPT消息中的EMM cause value,UE作不

同处理:

#2 HSS中没有IMSI,漫游情形; #16 MSC赞不可得; #17 网络失败; #22 阻塞;

#18 CS域无法使用。

? 网络侧拒绝联合附着

如果附着请求不能被网路侧的EPS或non-EPS服务接受,MME需要向UE发送一个包含EMM cause value的ATTACH REJECT消息。如果附着规程是因为默认EPS承载创建失败或者ESM规程失败,MME需要在ATTACH REJECT消息中绑定一个PDN CONNECTIVITY REJECT消息。这种情况下,EMM cause value置为#19“ESM failure”。 #3 非法UE

#6 非法ME

#8 拒绝EPS and non-EPS服务 #7 拒绝EPS服务 #11 拒绝PLMN #12 拒绝TA #13 本TA拒绝漫游 #14 本PLMN拒绝EPS服务 #15 TA中没有合适小区 #25 this CSG未授权 ? UE侧发生的异常

根据附着尝试计数器的值,UE作以下处理:

- 如果update status 为U1 UPDATE 并且附着尝试计数器小于5,那么UE应该维持update status为U1 UPDATED,新的MM状态为MME IDLE的子状态NORMAL SERVICE。 - 如果附着尝试计数器小于5,而且update status 不同于U1 UPDATED,那么UE应该删除所有的LAI、TMSI、加密密钥序列号和等效PLMNs列表,并且置update status 为U2 NOT UPDATED。MM状态仍保持为MM LOCATION UPDATING PENDING。

- 如果附着尝试计数器等于5,then UE应删除所有的LAI、TMSI、加密密钥序列号和等效PLMNs列表并且置update status为U2 NOT UPDATED。工作于CS/PS mode1的UE应

该选择GERAN or UTRAN RAT并且处理响应的MM or GMM 专用规程。

? 网路侧发生的异常

除case a and c之外,old TMSI 应保持有效,直到UE在随后的消息中启用了一个new TMSI。

Detach procedure 去附着流程 ? 概述

去附着流程用于:

- UE针对EPS服务释放(去附着); - UE从最后连接的PDN断开;

- 工作在CS/PS mode1 or CS/PS mode2的UE通过联合去附着流程针对EPS 服务和non-EPS服务或仅针对non-EPS服务去附着;

- 网路侧通知UE,它不再能访问EPS了。

去附着流程唤醒条件:UE关机;USIM卡拔出;EPS capability 或者UE 的CS Fallback capability被关闭。

如果针对EPS服务的去附着流程被执行,该UE的EPS承载上下文被本地置为无效(不用UE和MME的端对端信令传输)。 去附着流程成功完成后,UE和MME需要删除EPS mapped 安全上下文。

如果UE支持A/Gb mode 或者Iu mode ,UE应该存储TIN到MME

的非易失存储器中,用于随后的附着流程。 ? UE侧启动去附着流程

去附着流程通过UE侧发送一个DETACH REQUEST消息来启动去附着流程。该消息中的Detach type IE指明了去附着时因为“关机”还是其它,也指明了去附着是仅针对EPS服务,还是仅针对non-EPS服务,还是针对两者。如果UE有一个mapped EPS 安全上下文作为current EPS 安全上下文,UE需要设置安全上下文类型的flag为“mapped security context”,否则,设为“native security context”。

如果去附着并非因为关机造成并且UE处于

EMM-REGISTERED or

EMM-REGISTERED-INITIATED状态,UE在发送完DETACH REQUEST 消

息后应启动T3412。UE要存储current EPS 安全上下文。如果去附着流程是仅针对

non-EPS

服务,UE

需进入

EMM-REGISTERED.IMSI-DETACH-INITIATEDEMM-DEREGISTERED-INITIATED

状态,否则,UE需进入

状态,如果detach type 指明去附着针对

MM IMSI DETACH

non-EPS服务或EPS和non-EPS服务,UE应进入

PENDING状态。

如果UE将要关机,UE应该尝试时间为5s的发送DETACH REQUEST消息。。。在这期间,UE在发送完

DETACH REQUEST后可能立即关机。发

送完消息后,UE应删除current EPS 安全上下文(如果同native 安全上下文不同)。

UEStart T3421DETACH REQUESTMMEStop T3421DETACH ACCEPTor UE at switch off:DETACH REQUEST

? UE注册EPS服务启动去附着流程

如果网络侧接收到DETACH REQUEST消息,网路侧需要向UE发送一个DETACH ACCEPT消息,并且存储current EPS安全上下文(如果detach type IE 未指明“关机”)。否则,当网络侧接收到

REQUEST

DETACH

后,该去附着流程就结束(因UE已经关机)。接收到因

“关机”而发送的DETACH REQUEST消息后,MME应删除current EPS安全上下文(如果不同于native EPS 安全上下文)。

网络侧和UE侧需使EPS 承载上下文无效(无须响应信令传输)?。

UE接收到DETACH ACCEPT消息后,应停止T3412。

UE在网络侧被标记为inactive(非活动),网路侧进入EMM-REGISTERED状态。

工作于PS模式的UE需进入EMM-REGISTERED状态。 工作于CS/PS mode1 或者CS/PS mode2的UE需进入EMM-NULL状态。

? UE启动的联合去附着流程的完成(UE initiated combined detach procedure

completion)

网路侧接收到DETACH REQUEST消息后,应向UE回送一个DETACH ACCEPT消息。如果detach type IE指明“非关机”而去附着,那么根据其值,进行如下处理: - combined EPS/IMSI detach:

网络侧针对EPS和non-EPS服务将UE标记为“非活动”态;网络侧和UE侧均进入状态。 - IMSI detach:

网络侧仅针对non-EPS服务将UE标记为“非活动”态;网络侧和UE侧均进入MM-NULL and EMM-REGISTERED状态。

? UE侧发生的异常

a) 访问阻塞:因为access class barring或者NAS信令连接建立

被网路侧拒绝。

若访问因“信令”而阻塞,去附着信令流程将不会启动,UE驻留在当前服务小区并启动小区重选过程。如果当前小区授权了“信令”传输,或者UE移动到了一个“信令”授权的小区,那么UE根据需要立即启动去附着信令流程。 b) 收到DETACH ACCEPT消息之前发生底层失败或NAS 信

令连接断开。去附着流程应中止,UE根据需要进入相应状态。 c) T3421超时

EMM-DEREGISTERED and MM-NULL

若5次之内,UE重发消息并重启定时器。若达到了5次,则中止去附着流程,并根据情况进入相应状态。 d) 去附着冲突

若在UE启动的去附着流程完成之前,UE收到了一个网路侧启动的DETACH REQUEST消息,那么UE根据相应规定处理,并向网络侧发送一个DETACH ACCEPT消息。 e) 去附着和EMM通用规程冲突

? 因“关机”而detach

- UE在完成去附着流程之前接收到任何EMM通用规程消息,均忽略之,并继续去附着流程; ? 因“非关机”而detach

- UE在完成去附着只之前接收到GUTI REALLOCATION COMMAND,

an EMM STATUS or an EMM INFORMATION消息,应忽略之,并继续

去附着流程; - 如果接收到

AUTHENTICATION REQUEST, SECURITY MODE

COMMAND or IDENTITY REQUEST消息,UE需要分别响应之,并

继续去附着。 f) 进入new TA

如果在完成去附着之前,UE进入一个TAI list 之外的new TA,去附着流程需要中止,并且在TAU流程之后重启去附着流程。如果是因为拔出USIM卡而执行的去附着流程,UE需要中止去附着流程并进入EMM-DEREGISTERED状态。

g) DETACH REQUEST消息发送失败,(因)并底层指示TAI改变

如果current TAI不在TAI list中,那么UE启动TAU规程后再启动去附着;

如果current TAI来TAI list 中,那么UE重启去附着流程。 h) 非因底层指示TAI改变,而发送的DETACH REQUEST消息发送

失败

UE重启去附着流程。

? 网路侧发生的异常 a) b)

CSG ID of the CSG cell is not in the Allowed CSG list of the UE which sends the detach request

Lower layers indication of non-delivered NAS PDU due to handover

网路侧启动去附着流程 ? 网路侧启动去附着流程

网路侧通过向UE侧发送DETACH REQUEST消息或EMM消息(EMM cause#10 “implicitly detached”)来启动去附着流程。网络侧会在EMM cause IE中对detach request 指明原因。网络侧启动T3422.万一detach type IE 为“re-attach required”或者EMM消息with EMM cause #10,MME需要存储current EPS 安全上下文。否则,current EPS 安全上下文将被删除(若不同于mapped 安全上下文)。如果detach type IE为“re-attach not required”或则“re-attach required”,网络侧需要置UE locally EPS 承载上下文为无效并进入EMM-DEREGISTERED-INITIATED状态。

本文来源:https://www.bwwdw.com/article/uwz3.html

Top