zhenjiucuo 发表于 2011-8-21 23:49
回复 爱卫生 的帖子
楼主，想问一下，不知道你是否有研究，就是Service Request在EPS中的流程与在WCDMA中的 ...
[attach]350[/attach]
图一 EMM控制平面协议栈
所以，NAS信令连接包括UE和eNB之间的通过空口(Uu)的RRC连接，以及eNB和MME之间通过S1接口的S1 AP连接，两个部分。
2、EMM规程
EMM的功能通过发起EMM规程实现，EMM规程可以分为3类：
1) 通用规程(EMM common procedures)
只有在NAS信令连接已经建立时，才可发起通用规程。通用规程都是由网络侧发起：
- GUTI reallocation; 为UE分配标识符GUTI。
- authentication; 鉴权
- security mode control; 安全模式控制
- identification; 鉴别
- EMM information. 通知
2) 专用规程（EMM specific procedures）
由UE发起，同一时间只能发起一个专用规程。
- attach and combined attach.向网络侧注册EPS和non-EPS服务。
- detach and combined detach. 向网络侧去注册EPS和non-EPS服务。
- normal tracking area updating and combined tracking area updating;
- periodic tracking area updating.
3) 连接管理规程(EMM connection management procedures)
- service request. 建立和网络侧的安全连接，为发生数据请求资源。没有专用规程在运行时，才可发起。
- paging procedure. 网络侧通知UE建立NAS信令连接。或者在网络侧出现错误时，通知UE重新Attach。
- transport of NAS messages. 传输NAS消息
2、initial NAS message
为进行NAS规程，首先需要建立NAS连接。NAS初始消息，就是触发建立NAS信令连接的消息，有以下几个：
- ATTACH REQUEST;
- DETACH REQUEST;
- TRACKING AREA UPDATE REQUEST;
- SERVICE REQUEST;
- EXTENDED SERVICE REQUEST.
这些消息就是NAS的专用规程和SR规程的第一条消息。
NAS初始消息一定是不加密的。但如果已经建立的安全上下文，可进行完整性保护。
3、Establishment of the NAS signalling connection
在UE处于EMM-IDLE模式，需要发生NAS初始消息时，UE将请求AS建立RRC连接。成功后，转入CONNECTED态，认为NAS连接已经建立。
4、Release of the NAS signalling connection
在规程结束时，由网络侧主动发起。RRC连接释放完成后，UE进入IDLE态，认为NAS连接已经释放。
5、TAI和TAI list
TAI(Tracking Area identity)用于标示一个跟踪区域(Tracking Area)，由PLMN ID和 TAC (Tracking Area Code) 的组成。TAI列表，由MME分配，属于同一个服务MME的跟踪区域。在TAI list范围内的跟踪区域发生改变时，不必发起位置更新。
网络侧寻呼UE时，也在整个TAI list范围内发起寻呼，这样，不论UE处于TAI list内哪一个TAI，都可以接收。
TAI list由运营商在网络规划时确定，在UE注册、位置更新、或GUTI重配时，通知UE。
TAI list等同于GERAN的LAI(位置区)和UTRAN的RAI(路由区)。
划分为TAI列表的优点?
答：TAI list中的成员，可属于不同的eNB，但一定属于同一个MME。并且可以根据网络的热点和非热点地区来设置TAI list，减少TAU流程，降低信令网络负荷。
[attach]351[/attach]
图二 E-UTRAN结构图
[attach]352[/attach]
图三 GUTI重分配流程
其中 GUTI REALLOCATION COMMAND信元如下：
IEI | Information Element | Type/Reference | Presence | Format | Length |
Protocol discriminator | Protocol discriminator 9.2 | M | V | 1/2 | |
Security header type | Security header type 9.3.1 | M | V | 1/2 | |
GUTI reallocation command message identity | Message type 9.8 | M | V | 1 | |
GUTI | EPS mobile identity 9.9.3.12 | M | LV | 12 | |
54 | TAI list | Tracking area identity list 9.9.3.33 | O | TLV | 8-98 |
[attach]359[/attach]
图四 鉴权流程
- UE鉴权网络侧操作：
UE解析Request消息，获得以下信息：
1) KSI
网络侧为UE分配的安全上下文的ID，鉴权成功后生成的安全上下文，通过KSI检索。
2) RAND
USIM计算鉴权结果RES的入参之一。
3) AUTH
AUTN = (SQN xor AK)||AMF||MAC
在E-UTRAN鉴权时， AFM标志位必须为1。否则返回Authentication Failure拒绝网络侧。
如果SQN超出范围，也返回Authentication Failure拒绝网络侧。
USIM根据SQN和AS计算一个新的MAC，然后检查AUTH中携带的MAC。二者相同时，认为网络侧合法。然后根据RAND计算鉴权结果RES，并通过Authentication Response返回网络侧。
如果MAC不同，UE认为网络侧非法，通过Authentication Failure拒绝网络侧。
- 网络侧鉴权UE操作：
根据UE返回的Authentication Response消息，比较USIM计算的RES跟预期的RES是否一致。
如果不一致，则网络侧鉴权UE失败，将根据UE在初始NAS消息中携带的UE ID反别处理：
1) UE ID为GUTI
网络侧通过Identification规程，让UE提供IMSI，如果跟网侧保存的IMSI不同，则网侧重新发起鉴权。
2) UE ID为IMSI
网络侧认为UE不合法，通过Authentication Reject拒绝UE。
3、Security mode control procedure
- 功能
1) 协商安全算法，确定EPS安全上下文并投入使用，使用新协商的安全算法和鉴权产生的密钥，对NAS信令进行保护。
2) 修改已有的安全上下文，协商新的安全算法。
- EPS安全上下文(EPS security context)
包括以下内容：
1) KSI 安全上下文的ID；4 bits，其中第4个bit为上下文的类型。
2) Kasme 鉴权产生的基础密钥；
3) Uplink NAS COUNT 上行NAS消息计数器，安全保护的入参；
4) Downlink NAS COUNT 下行NAS消息计数器，安全保护的入参；
5) 加密算法的ID和完整性保护算法的ID；
6) 加密密钥和完整性保护密钥。(根据Kasme计算的)。
- EPS安全上行文有3种：
1) native security context 在本制式下计算产生的安全上下文。需要存卡，再次开机时重新使用。
2) mapped security context 从其它制式切换过来后，根据其它制式的信息推算的安全上下文。不存卡，关机时删除。
3) current security context 当前正在使用的安全上下文。
[attach]360[/attach]
图五：安全模式控制流程
- 网络侧指定安全上下文的类型
1) 使用native
鉴权规程后，产生了安全上下文。网络侧通过COMMAND消息的KSI指定安全上下文类型为native。
2) 使用mapped
刚从其它制式切换过来，UE发起TAU（TRACKING AREA UPDATING），其中TAU Request消息中携带了GPRS ciphering key sequence number IE。网络侧将根据切换前制式下的信息生成mapped安全上下文，并通过COMMAND消息的KSI指定安全上下文类型为mapped。
另外，SMC协商算法的过程中，网络侧将从UE的安全能力信息中挑选二者都支持的算法。因此，网络侧保存的UE安全能力必须和UE自身的安全能力一致。在COMMAND消息中，网络侧将之前Attach/TAU过程中获得的UE安全能力信息反馈给UE。
- UE判断网络侧指定的安全上下文是否支持
UE从COMMAND中解析如下主要内容：
1) UE安全能力信息。跟自身安全能力比较，二者必须一致，否则UE通过REJECT消息，拒绝协商。
2) KSI类型为native：如果当前使用的是mapped，删除，然后根据KSI找到自己的native安全上下文投入使用。
3) KSI类型为mapped：根据COMMAD消息中的NONCEue(保存在NV中)，NONCEmme重新计算密钥K’amse，生产mapped安全上下文，并投入使用。
然后UE使用最新协商的算法对COMPLETE消息进行安全保护。
4、Identification procedure
网络侧让UE提供IMSI(International Mobile Subscriber Identity)、IMEI(International Mobile Equipment Identity)
[attach]361[/attach]
图六 Identification流程
5、Information procedure
网络侧向UE提供信息。
[attach]364[/attach]
图七 EPC核心网框架图
[attach]362[/attach]
图八 附着流程计时器
- UE发起Attach
1) ATTACH REQUEST消息不加密。
如果UE存在安全上下文，则对REQUEST进行完整性保护，并在REQUEST中，携带有效的KSI。网络侧根据Header type，将选择KSI指定的安全上下文投入使用。
如果UE不存在安全上下文，则REQUEST没有保护。网络侧将发起鉴权和SMC，产生新的安全上下文。
另外，如果对保护的REQUEST完整性检查失败时，网络侧也会发起鉴权和SMC。
2) Attach类型(EPS attach type)
UE根据自身配置，决定是Normal，还是Combined类型。
3) UE ID(EPS mobile identity)
如果UE存在有效的GUTI（可从卡中获得），UE ID就设置为GUTI，同时把上次注册的TAI也通知网络侧(网络侧依此产生新的TAI list)。
否则，UE ID就设置为IMSI。
注意：如果UE ID为GUTI，在鉴权失败时，网络侧会让UE重新提供IMSI。
4）UE能力(UE network capability)
将UE支持的安全算法等信息通知网络侧，在协商安全上下文时使用。
5) ESM message container
在Attach过程，至少建立一个PDN连接(缺省承载)。UE通过ESM container，将PDN连接请求(PDN CONNECTIVITY REQUEST)发送到网络侧。
6) DRX参数(Discontinuous Reception)
为了省电，UE可以不连续接收寻呼。DRX就是接收寻呼的周期。只有在UE需要不连续接收寻呼时，才携带此参数。
- 网络侧接受Attach
如果网络侧接受Attach，将构造ATTACH ACCEPT消息通知UE：
1) EPS attach result
Normal、Combined，还是EPS only。
如果是EPS only(Combined Attach仅EPS成功)，ACCEPT将在EMM COUSE信元中指示non-EPS失败原因。
2) GUTI
如果UE指示的ID为IMSI、或为GUTI非法，或是其它MME分配的GUTI，则服务MME将为UE分配新的GUTI。
另外，MME通知UE新的TAI list。
3) T3412
周期性TAU定时器的时长。
4) ESM message container
网络侧响应PDN激活请求，发起缺省承载激活ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST.
5) Equivalent PLMNs
网络侧有等价PLMN，则通知。
6) Emergency number list
发送相同国家码(MCC)的紧急呼叫号码列表。
- 网络侧不接受Attach
通过ATTACH REJECT通知UE拒绝原因：
比如：#3 (Illegal UE); or #6(Illegal ME); #7(EPS services not allowed)等。
UE根据拒绝原因，按照协议做相应处理：换网，或同一网络下重新注册、或进限制服务等。
- UE完成Attach
UE解析ACCEPT：
1) 激活缺省承载
将缺省承载激活请求ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST
通知ESM。如果可以激活，ESM会返回ACTIVATE DEFAULT EPS BEARER CONTEXT ACCEPT，并携带在ATTACH COMPLETE中，通知网络侧。
2) 更新TAI list
只有重选到TAI list范围以外的小区，才发起位置更新。
3) 更新Equivalent PLMNs
UE从中剔除禁止PLMN列表中的PLMN，更新到AS，在小区重选时，可选到等价PLMN下的小区。
4) Attach已经成功，在进入空闲态时，启动T3412，超时后，发起周期性TAU。
[attach]363[/attach]
图九：UE发起的去附着
- Detach类型
分为关机去注册，和非关机去注册两种。
非关机去注册又细分为EPS去注册，和Combined EPS/non-EPS去注册。
另外，在拔卡时，UE根据之前注册的服务，决定是发起EPS去注册，还是Combined EPS/non-EPS去注册。
UE通过DETACH REQUEST消息的Detach type标识类型，占8 bits。
其中，第4个bit表示：正常去注册(normal detach) 还是关机（switch off）。
如果是正常去注册，通过1-3个bits，细分类型：EPS detach、IMSI detach和combined EPS/IMSI detach。
- UE标识
信元EPS mobile identity携带了UE的标识符，为有效的GUTI，或者IMSI。
- KSI
指示UE当前使用的EPS安全上下文的类型，为mapped或native两种。
- 关机Detach
UE尝试在5秒内发出DETACH REQUEST消息，发出后：
如果当前使用的安全上下文为native，保存；
如果为mapped，则删除，保存UE未使用的native安全上下文。
关机Detach不需要网侧的ACCEPT消息，直接关机。
- 非关机Detach
网络侧在保存安全上下文、去激活EPS承载后，通过DETACH ACCEPT消息通知UE。
2) MT Detach
[attach]365[/attach]
图十：网络侧发起的去附着
- Detach类型
网络侧通过DETACH REQUEST消息的Detach type信元指示类型，分为re-attach required、re-attach not required和IMSI detach共3类。
- re-attach required类型：
UE本地去激活所有EPS承载(不用和网侧交互)，向网络侧回复DETACH ACCEPT消息。在Detach规程完成后，网络侧释放连接，然后，UE再次发起Attach，重新注册服务。
- IMSI detach类型：
UE保持EPS承载，将CS域的更新状态设置为U2态，然后向网络侧回复DETACH ACCEPT消息，并发起Combined TAU，重新注册non-EPS服务。TAU REQUEST消息指示更新类型为”combined TA/LA updating with IMSI attach”.
- re-attach not required类型：
不需要重新Attach，此时，UE根据DETACH REQUEST消息的EMM cause信元，解析网络侧发起Detach的原因。这些Detach原因有#2 (IMSI unknown in HSS)、#3 (Illegal UE); #6(Illegal ME); #7(EPS services not allowed)等。UE需根据EMM cause，按照协议规定分别处理。
[attach]366[/attach]
图十一 TAU流程及计时器
- REQUEST信令分析
1） EPS update type
更新类型：
TA updating：Normal更新；
combined TA/LA updating：同时更新TA和LA；
combined TA/LA updating with IMSI attach：通过TAU注册IMSI;
periodic updating：周期性更新。
2） KSI
UE通过KSI指示当前使用的安全上下文的类型和ID。
3） Old GUTI
指示网侧分配的GUTI。
4）使用mapped安全上下文时，相关的信元
在EMM-CONNECTED从其它制式切换到LTE时，UE发起TAU，其中TAU REQUEST消息使用新生成的mapped安全上下文加以安全保护。
A）Non-current native NAS key set identifier：
如果UE已经存在一个native安全上下文，将通过此信元通知网络侧。以便在TAU完成后，选择使用哪个安全上下文。
B）GPRS ciphering key sequence number：
使用mapped安全上下文进行完整性检查的入参。
C）NonceUE：
生成mapped安全上下文的密钥
5）当UE network capability、MS network capability、UE radio capability information update needed、Mobile station classmark 2、Mobile station classmark 3、Supported Codecs在UE的能力参数发生改变时，通知网络侧。
6）EPS bearer context status
EPS承载改变是将激活的承载更新到网络侧。
1 | 1 | 0 | 0 | Security header for the SERVICE REQUEST message |
谢谢[attach]827[/attach]
也就是说，当收到MME侧关于用户面承载建立的AS指示就应视为Service Request流程成功完成了。
然后再看5.6.1.4 Service request procedure accepted by the network
“For cases a, b, c, h and k in subclause 5.6.1.1, the UE shall treat the indication from the lower layers that the user plane radio bearer is set up as successful completion of the procedure. The UE shall stop the timer T3417 and enter the state EMM-REGISTERED.”
上面就提到，对于上述a,b,c,h,k这几种场景，只要UE收到了来自底层的用户面无线承载成功建立的指示，就应该认为service request流程成功的完成，用的是treat ... as ...。然后进入EMM-REGISTERED状态。
所以，就没有Service Accept消息了。我猜这样做的目的主要还是为了减少空口的符合，因为service accept消息和承载成功建立消息都可以用来指示service request流程的完成，功能是重复的，没有必要在一个消息报文里面重复携带两种具有同样功能的消息。因此，Service Accept消息就被拿掉了。
zhenjiucuo 发表于 2011-8-21 23:49
回复 爱卫生 的帖子
楼主，想问一下，不知道你是否有研究，就是Service Request在EPS中的流程与在WCDMA中的 ...
[attach]828[/attach]
图1：3G中的Service Request消息字段内容
而EPC中关于Service Request的描述在TS24.301中描述，字段组成如下：
[attach]829[/attach]
图2：EPC中的Service Request消息字段内容
对比后就会发现，EPC中的Service Request消息做了很多精简，4个IE全部是强制的，总长也只有4个字节了，而W中则是变长的，强制字段为9个字节，而可选部分为27个字节，总共是36个字节。因此EPC的service request占用的资源更小，但也能实现相同的功能。而网络侧则将用户的所有承载激活，应该是为了增强用户体验吧。另外，也可能是做了调研，发现大多数用户可能都只有一个default bearer或者像现在的只有一个PDP Context。所以虽然说是激活所有的，但实际上可能还是一个。但我觉得规范里面用词欠妥，不应该用all the active EPS Bearers,而应该是all the available EPS Bearers，因为既然已经active了，还要你激活干什么？
另外，还需要提到，EPC中的Service Request有两种，前面提到一种，还有一种叫做Extened Service Request，字段组成如下：
[attach]830[/attach]
图三：EPC中的Extended Service Request消息字段内容
在里面发现了3G的Service Request消息中对应PDP Context Status的EPS Bearer Context Status，但这个Extended Service Request是有条件触发使用的，要求网络侧的支持。“For cases a, b, c, h and k, if the UE is configured for NAS signalling low priority, and the last received ATTACH ACCEPT message or TRACKING AREA UPDATE ACCEPT message from the network indicated that the network supports use of EXTENDED SERVICE REQUEST for packet services, the UE shall send an EXTENDED SERVICE REQUEST message with service type set to "packet services via S1". If the last received ATTACH ACCEPT message or TRACKING AREA UPDATE ACCEPT message from the network did not indicate that the network supports use of EXTENDED SERVICE REQUEST for packet services, the UE shall instead send a SERVICE REQUEST message. ”
另外，这个Extended Service Request还用于CS Fallback流程，规范里也有指明。并且这个Extend Service Request也不一定能用于网络侧来选择性的激活EPS Bearer，这个规范里没有明确说。
zhenjiucuo 发表于 2011-8-24 07:17
回复 爱卫生 的帖子
多谢！
qiandl 发表于 2011-11-18 00:04
" 3) 业务请求(Service Request)
注册成功后，UE需要发起业务时，首先通过ServiceReqeust，建立连接，并 ...
hxp_hust 发表于 2013-12-3 18:55
请问active flag这个IE在哪？我在attach request里没有找到这个IE，还是在别的消息里？
amr 发表于 2013-12-9 15:51
看协议流程无论是UE还是网络侧发起的去附着，最后都要释放S1连接。
但看去附着类型，有单独的针对CS域和 ...
| 欢迎光临 51学通信技术论坛 (http://51xuetongxin.com/bbs/) | Powered by Discuz! X2 |
