TS24301R8学习总结1.docx
- 文档编号:11437668
- 上传时间:2023-03-01
- 格式:DOCX
- 页数:86
- 大小:165.50KB
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
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- TS24301R8 学习 总结
![提示](https://static.bdocx.com/images/bang_tan.gif)