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需要将其包