EMM(EPS移动性管理)概念及流程

爱卫生

一、总述
   参考协议：TS24301，TS23401，TS36300, TS33401
   EMM (EPS mobility management)EPS移动性管理，管理UE在无线资源环境中的位置移动，包括以下几个主要功能：
   1) 位置注册
   向核心网注册UE信息。只有注册成功后，才可发起业务、发起呼叫和响应寻呼。
   2) 位置更新
   在UE的位置发生改变时，将最新的位置信息通知核心网。
   另外，UE能力信息，比如支持的算法、DRX寻呼周期长度等发生改变时，也通过位置更新通知核心网。
   EMM在网络侧的对等端为MME，如果服务的MME过载，MME将通知UE，通过位置更新，重新选择服务MME，实现负责均衡(load balance)。
   3) 业务请求(Service Request)
   注册成功后，UE需要发起业务时，首先通过ServiceReqeust，建立连接，并恢复承载。
   4) 鉴权(Authentication)
   UE和网络侧之间进行双向鉴权。
   鉴权由网络侧发起，只有合法的UE才可以注册。但当网络侧提供的鉴权参数不正确时，UE认为网络侧非法，可以拒绝。
   5）安全
   为UE和网络侧之间的信令交互提供加密和完整性保护。包括双方的算法协商、密钥的生成、加解密和完整性检查等。

二、重要的概念
1、NAS信令连接(NAS signalling connection)
    EMM在网络侧的对等端是MME。NAS信令连接是指EMM-MME之间的端对端(peer to peer)连接。如下图控制面协议栈所示：

图一 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流程，降低信令网络负荷。

图二 E-UTRAN结构图

爱卫生

1、GUTI reallocation procedure
- 功能
   1) 为UE分配GUTI
   2) 为UE分配TAI list (可选)
   GUTI重配规程在UE注册以后才能发起，也可以在Attach/TAU专用规程期间发起。
- GUTI的概念
   GUTI(Globally Unique Temporary UE Identity)，是在网络侧和UE之间信令交互时，为UE分配的一个临时ID。这样可以避免标识用户身份的IMSI在空口上传输，保护用户信息不被窃取。
   CS域UE标识为TMSI
PS域UE标识为P-TMSI
EPS为GUTI，功能更加强大。GUTI构成如下：
1) 为UE分配GUTI的MME的ID
2) MME中识别UE的ID两个部分。
<GUTI> = <GUMMEI><M-TMSI>
其中MME的ID构成如下：
<GUMMEI> = <MCC><MNC><MME Identifier>
这里MCC和MNC组成服务网络侧PLMN ID；MME Identifier包括MME组的ID，和服务MME的代码。
<MME Identifier> = <MME Group ID><MME Code>
   从以上构成可以看出，GUTI包含了3部分的信息：
   1) M-TMSI : UE的ID
   2) MME Identifier: 服务MME的ID
   3) 注册的PLMN。
  另外，M-TMSI 和MME Code组成的S-TMSI(精简的标识符)，是MME寻呼UE时使用的ID。
- 信令交互流程
   

图三 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

2、Authentication procedure
   - 功能
1) UE和网络侧互相鉴权；
2) 生成密钥。
   在网络侧不能确信UE合法时，比如NAS初始消息没有完整性保护，或者完整性检查失败等，网络侧将发起鉴权。另外，只有在NAS信令连接存在时才可发起。
   鉴权过程中，USIM根据网络侧提供的参数，生成IK和CK。所以，鉴权必须有卡。
   ME根据IK和CK生成新的密钥Kasme，这是后续加密密钥、完整性保护密钥和AS的Kenb的基础。
   经过鉴权，UE生成EPS安全上下文（security context）。

图四 鉴权流程

  - 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 当前正在使用的安全上下文。

图五：安全模式控制流程

   - 网络侧指定安全上下文的类型
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)
   

图六 Identification流程

5、Information procedure
   网络侧向UE提供信息。

爱卫生

6 附着
   - 功能
1)向EPC注册EPS业务。
2)为UE分配IP，建立UE和PDN GW之间的缺省承载(default bearer)，使得UE的IP连接永远在线.( always-on IP connectivity).
3) 还可激活多个专用承载(dedicated bearers).
4) Attach过程中产生安全上下文。投入使用后，对NAS信令进行安全保护。
    - 缺省承载和专用承载
PDN连接是UE和PDN GW之间的连接。
每建立一条PDN连接，就产生一个缺省承载。
专用承载：只对UE特定上行的数据包，和PDN GW特定下行的数据包进行过滤的承载。
一个PDN连接，可以有多个专用承载。
如果没有专用承载，数据包都经过缺省承载传输。

图七 EPC核心网框架图

图八 附着流程计时器

    - 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。

7、Detach
  分为UE发起的MO Detach和网络侧发起的MT Detach两种。
  功能：
  -UE/网络侧去撤销注册的EPS/non-EPS服务；
  -UE/网络侧断开PDN连接，去激活EPS承载。
1) MO Detach

图九：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

图十：网络侧发起的去附着

  - 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，按照协议规定分别处理。

爱卫生

8、TAU
   - 功能
1) UE进入新的TA，向网络侧更新UE当前的位置；
2) 周期性更新；UE周期性的报告一下当前的位置。
3) UE能力发生改变，更新到网络侧。
4) 在EPS承载发生改变时，通知网络侧，哪些承载还在激活状态。

图十一 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承载改变是将激活的承载更新到网络侧。

- ACCEPT信令分析
1） EPS update result
   更新成功的类型：
   TA updated、combined TA/LA updated。以及
   TA updated and ISR activated和combined TA/LA updated and ISR activated
2） T2412 Value
   网络侧可指定新的T3412的值
3） GUTI 和TAI list
   网络侧可为UE分配新的GUTI和TAI list
4） EPS bearer context status
  在REQUEST消息中携带该信元时，网络侧将把UE侧不在激活状态的承载去激活，然后，在ACCEPT消息中将网侧处于激活状态的承载，通知UE。
  UE跟网络侧保持同步，将去激活UE侧处于激活状态，但网络侧已经去激活的承载。
5） REJECT
  如果网络侧不能接受更新，通过REJECT消息通知UE拒绝原因。

9、ServiceRequest
  - 功能
1) 由IDLE态转到CONNECTED态
  在由信令或数据需要发送时，通过SR，建立连接，恢复承载。
2) 响应网侧的Paging

  A) ServiceRequest信元分析
A.1) Security header type
    SERVICE REQUEST特有的类型

1

1

0

0

Security header for the SERVICE REQUEST message

A.2) KSI and sequence number
    指示使用的安全上下文，和系列号(是进行完整性检查的入参)
A.3) Message authentication code (short)
    UE计算的MAC，如果网络侧计算不同，将发起鉴权。

  B) 网络侧接受
  AS在RB建立后，认为SR规程成功。(网络侧不返回ACCEPT)；
  另外，不能恢复的RB，UE需本地去激活。

chen_xueping

很有帮助谢谢

zhenjiucuo

回复 爱卫生 的帖子

楼主，想问一下，不知道你是否有研究，就是Service Request在EPS中的流程与在WCDMA中的区别。
1. Service Accept从EPS消失了
2. 在EPS中一旦Service Request收到，就把所有的E-RAB全部建起来，而不是像在W中一样，可以有选择的建立？
我没从标准中找到答案。

爱卫生

回复 zhenjiucuo 的帖子

  我先尝试着回答一下第一个问题吧。就是EPC和W中关于service request流程的区别。
  区别主要可以对照一下3G的规范TS24.008以及EPC的规范24.301来一起看。先看3G中service request的使用场景，摘自TS24.008：
This procedure is used for;
- the initiation of CM layer service (e.g. SM or SMS) procedure from the MS in PMM-IDLE mode,
- the network to transfer down link signalling,
- uplink (in PMM-IDLE or PMM CONNECTED) and downlink (only in PMM-IDLE) user data,
- counting the number of mobile stations in a cell which are interested in a specific MBMS service.
- requesting the establishment of a point-to-point Radio Bearer for receiving a MBMS service.
  再来看下TS24.301中关于Service Request流程的使用场景：
This procedure is used when:
- the network has downlink signalling pending;
- the UE has uplink signalling pending;
- the UE or the network has user data pending and the UE is in EMM-IDLE mode;
- the UE in EMM-IDLE or EMM-CONNECTED mode has requested to perform mobile originating/terminating CS fallback or 1xCS fallback;
- the network has downlink cdma2000&reg; signalling pending; or
- the UE has uplink cdma2000&reg; signalling pending.
  基本来看，service request的基本功能并没有发生变化，主要是用于IDLE状态的UE要发送信令或者用户面消息的情况下去重建承载用的。但EPC增加了其他网络技术的融合，因此有和其他技术之间的interworking。
  如果用中文来说明EPC中的service request的使用场景，可以参考《3GPP系统架构演进原理与设计》的5.4章节的说明，service request主要用于：
1）针对空闲状态的UE有下行数据到达核心网，由核心网侧发起业务请求过程。
2）网络针对空闲状态的UE需要发起信令过程（如注销等过程）。
3）空闲状态的UE有上行的数据或信令需要发送。
4）空闲状态的UE对网络的寻呼进行响应。
  还有一个重要的区别是，W中的service request消息是作为一个单独的消息发送，而EPC/LTE的要求之一是UE从空闲态转入激活状态过程，控制面的延迟应小于100ms，因此信令需要尽量的精简，所以EPC中的service request消息是包含在RRC连接建立请求消息中的，在建立RRC连接的同时，MME就可以开始对业务请求消息进行响应。节省了一个RRC连接建立的处理时间。

爱卫生

  然后，我再试着回答下第二个问题，就是service accept消息消失了。
  Serivce accept消息是当UE发起serivce request时的网络侧的回应。而根据TS24.301，UE需要在以下场景中调用service request流程：
a) the UE in EMM-IDLE mode receives a paging request with CN domain indicator set to "PS" from the network;
b) the UE, in EMM-IDLE mode, has pending user data to be sent;
c) the UE, in EMM-IDLE mode, has uplink signalling pending;
d) the UE in EMM-IDLE or EMM-CONNECTED mode is configured to use CS fallback and has a mobile originating CS fallback request from the upper layer;
e) the UE in EMM-IDLE mode is configured to use CS fallback and receives a paging request with CN domain indicator set to "CS", or the UE in EMM-CONNECTED mode is configured to use CS fallback and receives a CS SERVICE NOTIFICATION message;
f) the UE in EMM-IDLE or EMM-CONNECTED mode is configured to use 1xCS fallback and has a mobile originating 1xCS fallback request from the upper layer;
g) the UE in EMM-CONNECTED mode is configured to use 1xCS fallback and accepts cdma2000&reg; signalling messages containing a 1xCS paging request received over E-UTRAN;
h) the UE, in EMM-IDLE mode, has uplink cdma2000&reg; signalling pending to be transmitted over E-UTRAN;
i) the UE, in EMM-IDLE or EMM-CONNECTED mode, is configured to use 1xCS fallback, accepts cdma2000&reg; signalling messages containing a 1xCS paging request received over cdma2000&reg; 1xRTT, and the network supports dual Rx CSFB or provide CS fallback registration parameters (see 3GPP TS 36.331 [22]);
j) the UE, in EMM-IDLE or EMM-CONNECTED mode, has uplink cdma2000&reg; signalling pending to be transmitted over cdma2000&reg; 1xRTT, and the network supports dual Rx CSFB or provide CS fallback registration parameters (see 3GPP TS 36.331 [22]); or
k) the UE performs an inter-system change from S101 mode to S1 mode and has user data pending.
  然后，根据图5.6.1.1.1，service request流程成功建立的标志是，如下图：

  也就是说，当收到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中的 ...

  最后，再来尝试回答下第三个问题，但这个只是个人想法，仅供参考啊。
  问题是“在EPS中一旦Service Request收到，就把所有的E-RAB全部建起来，而不是像在W中一样，可以有选择的建立？"
  先看W中的实现，确实，根据TS23.060是这么说的“When the Service Type indicates Data, the UE may also include PDP context activity information to indicate which PDP contexts need to transfer data.“，以及网络侧的行为是“The SGSN may in addition use PDP context activity information provided by the UE in the Service Request to decide which RABs to set up. ”根据上面两句话，就可以判断出，W中UE发起service request消息，里面可以携带PDP上下文的状态，总共可以有11个，哪个是active的，哪个是inactive的。然后SGSN根据这个信息来决定由选择性的激活特定的PDP上下文而非全部。
  再看EPC中的实现，根据TS23.401是这么说的“This step activates the radio and S1 bearers for all the active EPS Bearers. ”。代表MME收到UE的service request请求后，将激活所有的这个UE的承载，包括default bearer还有dedicated bearer。而不是像W中的有选择性的激活PDP上下文。
  以上你对楼主问题的现象描述。
  再来看下W和EPC中关于Service Request的描述。W的在TS24.008中描述，字段组成如下：

图1：3G中的Service Request消息字段内容

  而EPC中关于Service Request的描述在TS24.301中描述，字段组成如下：

图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，字段组成如下：

图三：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

回复 爱卫生 的帖子

多谢！
但是，在3G中，Service Request如果是Idle进入Connected状态，则也不需要Service Accept，AS建立链接就够了。一般都是在有Iu链接的条件下，比如需要重建其中被释放的一个或几个RAB，则需要Service Request和Service Accept。结合你回答的第三个问题，个人感觉可能是在连接态不会再发Service Request了，因为每次Idle态转连接态时所有的E-RAB都建好了。有没可能是这样？

爱卫生

zhenjiucuo 发表于 2011-8-24 07:17
回复 爱卫生 的帖子

多谢！

  谢谢。你的这番话纠正了我的一些理解。我很认同你的观点。针对你说的：“个人感觉可能是在连接态不会再发Service Request了，因为每次Idle态转连接态时所有的E-RAB都建好了。”我非常同意。
  因为我仔细对比了3G中TS24008和EPC中TS24301关于Service Request使用场景的说明，在TS24008中明确提到“
1 The purpose of this procedure is to transfer the PMM mode from PMM-IDLE to PMM-CONNECTED mode, and/or to assign radio access bearer in case of PDP contexts are activated without radio access bearer assigned. In latter case, the PMM mode may be PMM-IDLE mode or may alternatively be the PMM-CONNECTED mode if the MS requires radio access bearer re-establishment.
2 This procedure is used for; uplink (in PMM-IDLE or PMM CONNECTED) and downlink (only in PMM-IDLE) user data.
3 If the SERVICE REQUEST message was sent in PMM-CONNECTED mode, then the reception of the SERVICE ACCEPT message shall be treated as a successful completion of the procedure. “这就足以证明3G中service request如你所说你可以在连接态发送的。
  但在TS24301中，得到的说明却是：“
1 The purpose of the service request procedure is to transfer the EMM mode from EMM-IDLE to EMM-CONNECTED mode and establish the radio and S1 bearers when uplink user data or signalling is to be sent.
2 This procedure is used when:the UE in EMM-IDLE or EMM-CONNECTED mode has requested to perform mobile originating/terminating CS fallback or 1xCS fallback;
3 The UE shall invoke the service request procedure when: 后面定义了a到k共11种UE应调用service request流程的场景，但仔细看过后发现没有一种是要求UE在连接态去重建没有激活的RAB的”
   这足以证明你的观点，就是在EPC中根据就不允许在EMM连接态去发送Service Request，除非有一种特例就是CS fallback。
  

qiandl

" 3) 业务请求(Service Request)
   注册成功后，UE需要发起业务时，首先通过ServiceReqeust，建立连接，并恢复承载。"
请教，是这样的吗？不是attach流程结束后就可以直接使用业务了吗？有点迷惑？

爱卫生

qiandl 发表于 2011-11-18 00:04
" 3) 业务请求(Service Request)
   注册成功后，UE需要发起业务时，首先通过ServiceReqeust，建立连接，并 ...

  是这样的。有很多手机是开机自动要做PS域的附着，但他们当时又不上网。所以，在附着的时候，实际上会有一个active flag，如果置1的话，MME将会把空口和S1的bearer全部保留而不会释放，并且不会切换UE的ECM状态。但如果没有置1，则MME将会把E-RAB释放掉并将UE状态切换到ECM-IDLE状态。这时候，UE如果要上网就需要发起Service Request流程去重建空口和S1的bearer。

hxp_hust

请问active flag这个IE在哪？我在attach request里没有找到这个IE，还是在别的消息里？

爱卫生

hxp_hust 发表于 2013-12-3 18:55
请问active flag这个IE在哪？我在attach request里没有找到这个IE，还是在别的消息里？

tau request

amr

看协议流程无论是UE还是网络侧发起的去附着，最后都要释放S1连接。

但看去附着类型，有单独的针对CS域和PS域的去附着。这些的话S1连接是无需释放的吧

amr

顺便再问如果手机关闭上网服务，这样算是EPS DETACH吗？

爱卫生

amr 发表于 2013-12-9 15:51
看协议流程无论是UE还是网络侧发起的去附着，最后都要释放S1连接。

但看去附着类型，有单独的针对CS域和 ...

去附着的话，网络侧就感知不到用户存在了，S1肯定要释放的。