Inter-SGSN RAU更新

爱卫生

图例：Inter-SGSN RAU流程

   当手机在不断移动的过程中，跨越了RA，而这个RA又是由不同的SGSN来管理的，这就会触发手机发起Inter-SGSN RA更新流程。信令流程如下：

1 MS根据手机的测量报告，发现即将离开当前小区，并且将进入一个新的小区，而这个小区是属于另外一个RA（MS通过对比存储在SIM卡中的RAI（这个是由在附着或RA更新阶段SGSN分配给MS的)和空口收到的RAI，判断将进入一个新的RA，因此将发起一个RA更新请求消息发给SGSN，这也是一个NAS消息，所以需要SGSN处理。由BSC进行透传。这个RA更新请求包括之前所在RA的RAI（因此也叫old RAI)、P-TMSI（由之前RA服务的SGSN分配的临时ID、更新类型（代表这是一个正常的RAU而不是周期性的RAU)给新SGSN（也就是为新RA服务的SGSN）。BSS在BSSGP消息中加入小区全球标识CGI后，上层的NAS消息透传给new SGSN。

2 新SGSN通过判断old RAI不是自己服务的RA，了解到这是一个inter-SGSN的RAU，所以新SGSN将向old SGSN发送身份请求消息去请求用户的MM（移动性管理）上下文以及PDP上下文信息。那新SGSN怎么找到old SGSN呢？是通过对old RAI的解析完成的，这可以是在SGSN上静态配置，也可以通过DNS查询来得到，最后的结果就是得到了old SGSN的IP地址，通过Gn接口发送出去给old SGSN。

  old SGSN收到以后，将MS的MM和PDP上下文信息发给new SGSN。包括MS未使用的鉴权参数，QOS profile，PDP上下文状态，分配的MS的IP地址等信息。

3 执行加密功能；建立了到网络侧的安全关联之后，MS在空口的消息将由LLC或RLC层完成加密；这个很重要，因为有可能后续的PDP激活流程如果需要到radius鉴权用户身份的话，则NAS消息里可能会携带PCO选项包括用户名和口令，这样很不安全，一定要加密。

4 新SGSN向old SGSN返回SGSN上下文确认；old SGSN收到该确认后，标记该MS上下文中的相关信息无效。如果前面的鉴权未通过，则新SGSN应该拒绝该MS的路由区更新请求，old SGSN则当作什么也没有发生；

5 在收到新SGSN的SGSN上下文确认消息后，old SGSN在一定的时期内将相关的N-PDU转发给新SGSN；这是因为MS在移动到新的RA之前，可能有下行数据正在传递，可能还没传完就来到了新的RA，这时，old SGSN需要将缓存的数据通过Gn接口传递给新SGSN，来保证下行用户数据能转发给MS。

6 新SGSN向GGSN发出更新PDP上下文请求（包含新SGSN地址、TEID、商定的QoS），这将通知GGSN如果还有下行数据要发送，请发送给我---新SGSN，不要再发送给old SGSN了，GGSN则返回更新PDP上下文响应（包含TEID），用于新SGSN发送MS的上行数据；

7 新SGSN向HLR发出位置更新消息（包含SGSN编号、SGSN地址、IMSI），通知HLR更新用户位置，现在的MS将由我来为这个MS提供服务，有什么事就找我吧！

8 HLR说知道了，以后有事就找你。并且向old SGSN发出位置取消消息（包含IMSI、取消类型），old SGSN删除相应的MM和PDP上下文后返回位置取消确认（包含IMSI）；因为HLR需要告诉old SGSN回收相应的资源，例如内存等（因为用户已经走了，上下文信息也转给目的网络SGSN了并得到了对方的确认，没有必要再保存了）。

9 HLR通知新SGSN关于用户的签约数据（包含IMSI、GPRS签约数据如QOS/签约的APN等），新SGSN创建相应的MM上下文后返回插入用户数据确认消息（包含IMSI）

10 HLR向新SGSN返回位置更新确认（包含IMSI）；

11 新SGSN将为该MS分配新的P-TMSI，用于标识这个MS在当前RA的临时身份。并向MS返回路由区更新接受消息（包含新分配的P-TMSI、P-TMSI签名等），另外，和附着流程一样，在RAU accept消息中，还要给MS分配新的ready timer、周期性RAU计时器、以及告知MS当前的RAI。
12 MS在收到P-TMSI后将存入SIM卡中，同时还保存ready timer以及周期性RAU计时器以及当前的RAI到SIM中，以保持和网络侧的状态同步。并返回路由区更新完成消息（包含P-TMSI），完成整个Inter-SGSN RAU流程。

GPRS_2

看到版主上面SGSN间的RAU，很清晰，向转户口流程，但想起网上这样一个光杆信令流程，注意到ReroutingRequest
和Rerouting Confirm,怎么感觉都有点突兀。

呵呵，本人没有研究过这方面的协议。纯属业余学习。

rubik

如果RAU reject会有什么cause呢，现在发现一个大量路由区更新失败的case，但是还没有解决！！！

爱卫生

回复 rubik 的帖子

  这个得看具体的场景。你可以说一下具体的情况，如果方便可以提供以下log或抓包。大家一起帮着分析一下。
  但如果只是按照原理上说的，这个RAU Reject的Cause是在TS24.008中定义的。在9.4.17中有关于RAU Reject消息的构成。Cause是携带在GMM Cause这个IE中的。
  这些GMM Cause包括如下：（在10.5.5.14 GMM Cause中定义）

IMSI unknown in HLR

Illegal MS

IMEI not accepted

Illegal ME

GPRS services not allowed

GPRS services and non-GPRS services not allowed

MS identity cannot be derived by the network

Implicitly detached

PLMN not allowed

Location Area not allowed

Roaming not allowed in this location area

GPRS services not allowed in this PLMN

No Suitable Cells In Location Area

MSC temporarily not reachable

Network failure

MAC failure

Synch failure

Congestion

GSM authentication unacceptable

Not authorized for this CSG

No PDP context activated

}

} retry upon entry into a new cell

}

Semantically incorrect message

Invalid mandatory information

Message type non-existent or not implemented

Message type not compatible with the protocol state

Information element non-existent or not implemented

Conditional IE error

Message not compatible with the protocol state

Protocol error, unspecified

rubik

我抓包了，但是现网的，太大了，不方便传啊，找了半天找到了到了你这里面对应的cause，MS identity cannot be derived by the network (9) 是这个，但是还是不知道怎么解决啊，

rubik

想再抓一下Gn的看看是不是两个厂家的SGSN配合有问题，但是不方便抓

爱卫生

回复 rubik 的帖子

建议看下这篇RAU reject cause分析。应该有你想要的答案。{:soso_e100:}

zglaojiang

回复 爱卫生 的帖子

爱老板，你什么时候有空也把3G的那个跨SGSN路由区更新像这样讲一下吧，因为里面有些流程不一样，看了你讲的2G的流程这么清晰。很想再听一下3G的流程。

爱卫生

zglaojiang 发表于 2011-8-7 20:25
回复 爱卫生 的帖子

爱老板，你什么时候有空也把3G的那个跨SGSN路由区更新像这样讲一下吧，因为里面有些流 ...

  3G的Inter-SGSN RAU也已经介绍了。不过是针对23060的翻译，并加入了自己的一点理解。
  可参考帖子6.9 位置管理功能（含RAU和SRNS重选等信令流程）。
  附一张图过来（Iu模式下的Inter-SGSN RAU流程图）：

注释1：图例36中，所有步骤除了2,3,5和9,其他对于基于Gn/Gp还是基于S4的SGSN来说是公共的架构。对于基于S4-SGSN的交互，步骤（A)和（B)在6.9.2.1a章节描述。

注释2：对于紧急附着,如果MS不能成功鉴权,步骤10,11,12,13和14不能执行。

  1）RRC连接要首先建立，如果之前没有完成的话。MS发送RAU Request消息（P-TMSI,old RAI,old P-TMSI签名，更新类型，follow on request,MS无线接入能力,DRX参数,MS网络侧能力，附加的P-TMSI/RAI，语音域优先级和UE使用设置）给new SGSN.MS应设置一个follow-on request--如果它有pending的上行流量（信令或用户数据）。SGSN可以使用，作为一个实现的可选项，使用follow-on request来指示在完成RAU流程后，释放或保留Iu连接。更新类型应指示：

- RAU是否是由RA的变化而触发的；

- RAU是否由周期性RAU计时器超时触发；

- 是否是联合的RA/LAU，如果MS已经IMSI附着并且LAU应在网络模式I下执行; 或；

- 带有IMSI附着请求的联合RA/LAU---如果MS需要在网络模式I下执行IMSI附着。

  SRNC应在转发给3G-SGSN之前加入RAI。这个RAI和SRNC发送给MS的MM information里携带的RAI一致。CSG ID应在MS如果是通过CSG小区或混杂小区里发送RAU里包含。CSG接入模式应在MS通过混杂小区里发送RAU request消息时提供。如果CSG接入模式不能提供但CSG ID提供了，SGSN应认为这是一个CSG小区。

  MS无线接入能力在“MS网络能力”章节描述。DRX参数包含GERAN/UTRAN的DRX循环长度以及其他可能的RAT，例如E-UTRAN。

  如果具有E-UTRAN能力的UE的TIN指示为“GUTI"并且UE持有了一个正确的GUTI，那UE指示GUTI作为old P-TMSI以及old RAI。如果UE的TIN指示为“P-TMSI"或"RAT-related TMSI"并且UE持有了一个正确的P-TMSI以及相关的RAI，那这两个元素将指示为old P-TMSI和old RAI。将GUTI映射为一个P-TMSI和RAI在TS23.401描述。在Iu模式RAU的场景，TIN指示为“P-TMSI”或“RAT-related TMSI"

  如果具有E-UTRAN能力的UE持有了一个正确的P-TMSI以及相应的RAI，那UE指示这些参数作为附加的P-TMSI/RAI，不管是否old P-TMSI以及old RAI指示了相同的参数或从GUTI映射得到了相应的参数。都不管。

  Gn/Gp SGSN应忽略附加的P-TMSI/RAI。

  UE根据它的配置设置语音域优先级和UE使用设置，在5.3.15描述。

注释3：发送RAU Request消息给SGSN，触发对为相应MS的RAN和SGSN之间的信令连接的建立。

  2）如果RAU是一个Inter-SGSN RAU并且MS是在PMM-IDLE状态，new SGSN发送SGSN context request消息（old P‑TMSI, old RAI, old P‑TMSI Signature) 给old SGSN来得到MS的MM和PDP上下文。如果new SGSN为为多CN节点提供了Intra Domain连接，新SGSN可以从old RAI和old P-TMSI来得到old SGSN，并发送SGSN context request消息给这个old SGSN。反之，新SGSN从old RAI得到old SGSN的地址。在任何场景，新SGSN将得到一个SGSN地址作为它认为是的old SGSN。个得到的SGSN它要么自己就是old SGSN，或者是关联到相同的SGSN POOL区域里的某个SGSN，这个POOL区域的某个SGSN会根据P-TMSI来得到真正的old SGSN，并将这个消息中继给这个pool里面真正的old SGSN。old SGSN验证old P-TMSI签名并且响应一个合适的原因代码--如果它和old SGSN存储的值不匹配的话。这将在新SGSN发起一个安全功能。如果安全功能对MS鉴权成功，新SGSN应发送一个SGSN context request（old RAI,MS已验证,IMSI）消息给old SGSN.MS已验证指示新的SGSN已经对MS进行过鉴权。如果old P-TMSI签名正确或如果new SGSN指示已对MS进行过鉴权,old SGSN开始一个计时器。如果MS在old SGSN未知，old SGSN响应一个合适的错误代码。

  如果带有紧急承载的UE没有在old SGSN鉴权（是一个网络支持不鉴权的UE)，old SGSN将继续后续流程，通过发送context response消息，并且在它不能验证context request的时候开始一个计时器。

  2a）如果MS在old 3G-Gn/Gp-SGSN是PMM-CONNECTED状态，或者是在intra-Gn/Gp-SGSN RAU的case里，如果MS是在PMM-CONNECTED状态并且RAU是通过和之前建立的Iu连接不同的另外一条Iu连接接收到的，则old Gn/Gp SGSN发送SRNS Context Request消息给old SRNS来重新获取PDP上下文的序列号并包含在SGSN Context Response消息里。一旦接收到这个消息，SRNS缓存并且停止发送下行PDU给MS并返回一个SRNS Context Response（IMSI,GTP-SNDs，GTP-SNUs，PDCP-SNUs）消息。SRNS应包括每个PDP上下文的将发送给MS的下一个序列的GTP序列号以及下一个要被封装进隧道发送给GGSN的上行PDU的GTP序列号。对于每一个已经激活的使用了无损PDCP的PDP上下文，SRNS应包括上行PDCP序列号（PDCP-SNU)。PDCP-SNU应是MS期望的下一个序列中PDCP序列号（每一个active无线承载）。3G-SGSN不需要完成PDCP序列数字到SNDCP序列号的转换。

  SNDCP,GTP和PDCP序列号数字和S4-SGSN是不相关的，因为网络侧不应配置“要求按序分发”，没有确认模式的NSAPIs(SNDCP)并且不少于UTRAN PDCP的丢失，在章节“Network Configuration for Interaction with E-UTRAN and S4-SGSNs”描述。

3)old 3G-SGSN响应一个SGSN Context Response（MM上下文,PDP上下文,协商的演进ARP)消息。对每个PDP上下文,old 3G-SGSN应包含下一个将被封装到隧道传给GGSN的上行GTP PDU的GTP序列号，以及下一个将要发送给MS的下一个PDU的下行GTP序列号。每个PDP上下文也包含PDCP序列号---如果PDCP序列号从old SRNS收到的话。当new 3G-SGSN之前如果从RAU Request消息里收到了MS网络侧能力的时候，则应忽略包含在SGSN Context Response消息里的MM上下文里的MS网络侧能力。从old 3G-SGSN收到的GTP序列号仅当针对PDP上下文（QOS profile）要求按序分发的时候才有意义。
  如果UE从old 3G Gn/Gp-SGSN收到了紧急业务但是UE是UICCless，IMSI则不能在SGSN Context Response消息的MM和PDP上下文里包含。对于紧急附着的UE，如果IMSI不能鉴权，那么IMSI应被标记为未鉴权。
  对于S4-SGSN之间的RAU，old SGSN应在Context Response消息里包含change reporting action。
  4）安全功能应执行。这个流程在章节“安全功能”中定义。如果SGSN Context Response消息不包含IMEISV并且支持ADD功能，SGSN则要求MS提供IMEISV。如果安全功能不能正确鉴权MS,RAU将被拒绝，并且new SGSN应发送一个拒绝指示给old SGSN.old SGSN应继续工作，就好象SGSN Context Request从来没收到一样。
  如果new SGSN配置了允许未鉴权的紧急业务,则new SGSN的行为应如下：
- 当MS只有紧急承载业务时,SGSN或者跳过鉴权以及安全设置或者接受这个可能失败的鉴权并且继续RAU流程,或者；
- 如果MS既有紧急又有非紧急承载业务并且鉴权失败，SGSN将继续RAU流程并且去激活所有的非紧急PDP上下文，这在9.2.4.2描述。
  5）如果RAU是一个Inter-SGSN RAU，new SGSN发送一个SGSN Context Acknowledge消息给old SGSN.这将通知old Gn/Gp SGSN，new SGSN已经接收到了属于这个已激活的PDP上下文的数据包。只有old Gn/Gp SGSN可以转发数据给一个new Gn/Gp或S4-SGSN。一个new S4-SGSN将给old Gn/Gp SGSN指示从SGW来的预留的TEID和IP地址参数，所以old Gn/Gp SGSN可以在需要的时候转发数据包。SGW丢弃所有从old Gn/Gp SGSN接收到的数据包。
  old SGSN标记这个上下文和MSC/VLR的关联以及在GGSN和HLR中的信息是invalid。这将触发MSC/VLR，GGSN和HLR被更新---如果MS在完成当前正在进行的RAU流程之前又回到了old SGSN的RA，又给old SGSN发起了一个RAU流程的时候。
  6)如果在old 3G-Gn/Gp SGSN中，MS是在PMM-CONNECTED状态或在一个intra-Gn/Gp-SGSN RAU的case里，如果MS是通过除了已经建立的Iu连接的另外一条Iu连接收到的RAU并且是PMM Connected,那old 3G-Gn/Gp-SGSN发送一个SRNS Data Forward命令（RAB ID,传输层地址,Iu Transport Association）消息给SRNS。一旦从3G-SGSN接收到SRNS Data Forward Command消息，SRNS应启动数据转发计时器。
  7)对于每个指示的RAB,SRNS开始复制并且将缓存的GTP PDU放入隧道中发送给old 3G-Gn/Gp SGSN.对于每个使用了无损PDCP的无线承载，SRNS应开始将已经部分传递的以及已经传递但没有确认的PDCP-PDU和它们相应的PDCP序列号一起放入隧道中，并且开始复制和
将缓存的GTP PDU放入隧道中传递给old 3G-Gn/Gp-SGSN。一旦从3G-Gn/Gp SGSN接收到SRNS Data Forward Command消息,SRNS应开始数据转发计时器。
  8)如果RAU是一个Inter-SGSN RAU，old 3G-SGSN将GTP PDU放入隧道发送给new 3G-SGSN。3G-SGSN不用执行PDCP序列号到SNDCP序列号的转换。
  9)如果RAU是一个Inter-SGSN RAU并且如果MS在new 3G-SGSN不是PMM-CONNECTED状态，new SGSN发送一个update pdp context request（new SGSN地址，协商的QOS，协商的演进ARP,TEID,服务网络ID，CGI/SAI，RAT类型，MS信息变更报告支持指示，NRSN)给相关的GGSN。SGSN应发送一个服务网络ID给GGSN。NRSN指示网络侧请求的承载控制的SGSN支持。协商的演进ARP指示了SGSN支持演进ARP特性。如果new SGSN从old SGSN的SGSN Context Response消息里没有收到协商的演进ARP，那么new SGSN应根据TS23.401附录E的说明，从协商的QOS profile里的分配/保持优先级中去获取这个值。GGSN更新它的PDP上下文字段并且返回一个update PDP Context Response（TEID,禁止payload压缩，APN限制，MS信息变更报告action，CSG信息报告action，BCM，协商的演进ARP)。GGSN根据本地策略或PCC来设置协商的演进ARP。根据TS23.401附录E的映射原则，协商的QOS profile中的分配/保持优先级是从演进的ARP获取到的。禁止payload压缩指示SGSN可以为这个PDP上下文来协商不进行数据压缩。SGSN如果能够从GGSN收到了协商的演进ARP，则应应用这个协商的演进ARP。
注释4：如果RAU是由一个在new 3G-SGSN中PMM-CONNECTED状态的MS发起的Inter-SGSN RAU，则在章节“Serving RNS Relocation Procedures”描述。
   10）如果RAU是一个Inter-SGSN RAU，new SGSN通知HLR关于SGSN的变化，通过发送update location（SGSN Number，SGSN地址，IMSI,IMEISV,IMS over PS会话的同质支持）消息给HLR来通知。如果ADD功能支持的话将发送IMEISV。IMS over PS会话的同质支持指示“IMS Voice over PS会话”是否在服务的SGSN的所有RA中能同质的支持。
   11) 如果RAU是一个Inter-SGSN RAU，HLR发送cancel location（IMSI, Cancellation Type）给old SGSN，并将cancellation type设置为更新流程。如果在步骤2描述的计时器没有运行，old SGSN将删除MM和PDP上下文/EPS承载上下文，old S4-SGSN释放附加的SGW资源---当new SGSN是一个Gn/Gp SGSN或者当SGW变化执行的时候。 GTPV1 SGSN上下文传递信令指示给old S4-SGSN，new SGSN是一个Gn/Gp SGSN，并没有指示任何SGW的变化。当在步骤2的计时器运行时，当这个计时器超时后，MM和PDP/EPS承载上下文和任何受到影响的SGW资源被移除，并且SGSN接收到一个cancel location。old S4-SGSN通过发送delete session request（原因，操作指示）消息给SGW来删除SGW的承载。如果ISR激活了，原因将指示old SGW应删除在其他old核心网节点中的承载资源---通过发送delete bearer request消息给其他的CN节点。old S4-SGSN不设置操作指示flag。这将指示给SGW,SGW不能发起到PGW的删除流程。
  当步骤2的计时器超时并且没有从S4-SGSN收到Cancel location，S4-SGSN移除PDP上下文/EPS承载上下文，但是保留MM上下文。
  步骤2启动的定时器确保MM和PDP上下文/EPS承载上下文在old SGSN中保持着---在MS完成当前正在进行的RAU之前又发起了到另一个new SGSN的inter-SGSN RAU流程的case里。old SGSN通过cancel location ACK(IMSI)确认。
  11a）一旦接收到cancel location，如果MS在old 3G-SGSN是PMM-CONNECTED状态，old 3G-SGSN发送一个Iu release command消息给old SRNC。当数据转发计时器超时，SRNS响应一个Iu release complete消息。

12)如果RAU是一个inter-SGSN RAU，HLR发送插入签约数据ISD（IMSI，签约数据）消息给new SGSN。new SGSN验证在新RA的MS的存在。如果因为区域签约限制或接入限制（例如CSG签约）MS不允许附着到这个RA，SGSN将拒绝这个RAU请求并带上合适的原因值，并返回一个insert subscriber data ack（IMSI,SGSN Area Restricted）消息给HLR.如果网络支持MOCN的配置来支持网络共享,SGSN可以，如果MS是一个不支持网络共享功能的MS,在这个例子里决定发起一个重定向---通过发送reroute命令给RNS，在TS23.251描述，以此来代替RAU request的拒绝。如果所有检查成功，SGSN构建这个MS的MM上下文并返回ISD ACK(IMSI)消息给HLR。如果在S4-SGSN和HSS之间使用sd接口，则不使用ISD和ISD ACK消息。如果替代，签约数据是由HSS在update location ACL(步骤13）消息中携带的。签约数据可以包含这个PLMN的CSG签约数据。
  如果在一个CSG小区发起一个RAU流程，new SGSN应检查是否CSG ID是包含在CSG签约信息里并没有超时.如果CSG ID不存在或超时，SGSN应发送一个RAU拒绝消息给MS并带上合适和原因值。MS应从其允许的CSG列表中移除CSG ID---如果存在的话。
  13）如果RAU是一个Inter-SGSN RAU，HLR通过发送update location ack（IMSI,GPRS签约数据（仅当s6d接口使用时））消息给new SGSN来对update location进行确认。
  14）如果更新类型指示这个一个联合的带有IMSI附着请求的RA/LAU，或如果在RAU时发生了LA的改变，这个关联将被建立,new SGSN发送一个location update request（new LAI,IMSI,SGSN number,Location update type）给VLR。位置更新类型应指示为IMSI附着--如果update type在步骤1里指示为联合的RA/LAU并带有IMSI附着请求。反之，位置更新类型应指示为正常的位置更新。当SGSN不能为多CN节点提供Intra Domain Connection的功能时,VLR number将从RAI里获取。当SGSN提供了这个功能时,SGSN使用RAI以及从IMSI得到的哈希值来决定VLR Number。SGSN开始到new MSC/VLR的位置更新流程---一旦接收到步骤8里的从HLR发过来的第一个ISD消息）。VLR创建并更新和SGSN的关联---通过对SGSN Number进行排序。在支持网络共享的网络，location update request包含了选择的核心网络运营商的ID---如果SGSN之前从RNS接收到了这个信息。这在TS23.251描述。
  15）如果在VLR的签约数据表明没有得到HLR的确认，new VLR通知HLR。HLR取消old VLR并且插入签约用户数据到new VLR。
    a）new VLR发送一个update location（new VLR)给HLR.
    b）HLR取消在old VLR的数据，通过发送cancel location（IMSI)给old VLR。
    c）old VLR发送cancel location ack（IMSI)确认。
    d）HLR发送ISD(IMSI,签约数据）给new VLR.
    e）new VLR通过ISD ACK(IMSI)确认。
    f）HLR给new VLR发送update location ACK(IMSI)响应。
  16）new VLR分配一个新的TMSI并且响应一个location update accept（VLR TMSI)给SGSN.VLR TMSI在VLR没有发生变化时候可选。
  17）new SGSN验证MS在新RA的存在。如果因为漫游限制或接入限制（例如CSG限制）MS不允许附着到这个小区，或签约检查失败，SGSN将拒绝RAU并给出合适的原因代码。如果网络侧支持网络共享的MOCN配置，且MS是一个不支持“网络共享”的MS，在这个case里将决定通过发送reroute命令来发起一个重定向给RNS，在TS23.251描述，来代替RAU的拒绝。如果所有的检查都成功，new SGSN为这个MS建立MM和PDP上下文/EPS承载上下文。New SGSN给MS响应一个RAU Accept（P-TMSI,VLR TMSI,P-TMSI签名,IMS voice over PS会话支持指示，紧急业务支持）。IMS voice over PS会话支持指示根据5.3.8章节描述所设置。
  激活的ISR永不在inter-SGSN RAU的case里指示，在TS23.401描述。具有E-UTRAN能力的UE设置TIN为“P-TMSI”或“RAT-related TMSI"，根据TS23.401的RAU流程描述的一样。
  如果为了MS激活了ISR，当S4-SGSN在intra SGSN的场景里接收到RAU Request消息，S4-SGSN应通过在RAU Accept消息里指示ISR已激活来保持ISR。
  如果RAU流程是通过手动CSG选择发起的或发生在一个CSG小区，MS一旦接收到RAU Accept消息，则应加入CSG ID到它的允许的CSG列表中--如果列表中没有的话。手动的CSG选择在MS有已经建立的紧急承载业务的时候不支持。
  如果用户平面建立的执行是和RAU Accept联合执行的，并且RAU是通过一个混杂（hybird）小区执行的，那SGSN应在RANAP消息中发送一个指示说明UE是不是一个RAN的CSG成员。根据这个信息，RAN可以执行针对CSG和非CSG成员的不同QOS待遇。
注释5： 如果UE通过一个混杂小区接收到一个RAU Accept消息，UE不应将相应的CSG ID加入到它的允许的CSG列表。这个过程是由OTA或OMA DM流程来完成的。
  紧急业务支持指示告知MS支持紧急的PDP上下文，例如MS允许在需要的时候请求激活一个紧急PDP上下文。
  如果因为区域签约限制，或不是允许的CSG,一个带有正在进行紧急承载业务的MS不允许接入到RA或CSG小区，SGSN应接受这个RAU请求并且去激活所有非紧急的PDP上下文，在9.2.4.2描述。如果RAU流程是在PMM-IDLE/STANDBY状态发起的，所有非紧急的PDP上下文将被去激活---通过SGSN和MS之间的不带PDP上下文去激活信令的RAU流程。MS应避免在紧急承载业务时接入到GERAN。
  18）MS确认TMSI的重分配，通过返回一个RAU Compelete消息给SGSN。
  19）new SGSN发送TMSI Reallocation Compete消息给VLR---如果MS确认了VLR TMSI。
注释6：步骤15，16，19只有在步骤14执行了以后才能执行。
注释7：new SGSN可以在步骤4的安全功能完成后发起RAB建立，或等待RAU流程的完成。对于MS，RAB的建立可能在步骤1的RAU request消息发出之后的任何时间发生。
  对于一个拒绝的RAU操作，因为区域签约，漫游限制或接入限制（TS23.221和TS23.008),new SGSN不能构建MM上下文。在从HLR接收到签约数据的case里，new SGSN可以构建MM上下文并且存储MS的签约数据以此来优化SGSN和HLR之间的信令。一个reject应带上合适的代码返回给MS并且PS信令连接应被释放。一旦返回到idle，MS的行为应根据TS23.122来。如果网络侧支持网络共享的MOCN配置,SGSN可以，如果MS不支持网络共享，在这里将决定通过发送reroute命令来发起一个重定向给RNS，在TS23.251描述，来代替RAU的拒绝。
  如果new SGSN不能在一个或多个GGSN/PGW中更新PDP上下文/EPS承载上下文,new SGSN应根据章节“SGSN-initiated PDP Context Deactivation Procedure”的描述来去激活相应的PDP上下文/EPS承载上下文。这不应导致SGSN拒绝RAU。
    PDP上下文/EPS承载上下文应从old SGSN发给new SGSN，并按照一定的优先级顺序，例如在SGSN Context Response消息里的最重要的PDP上文/EPS承载上下文优先。（优先级的方法和取决于实现，但应该给予当前的activity。）
   New SGSN应为了从使用S4接口GGSN/PGW或old S4-SGSN接收来的，每个PDP上下文/EPS承载上下文里的APN限制来决定最大的APN限制
，并且存储这个新的最大APN限制值。
  如果new SGSN不能支持和old SGSN那样相同数量的active PDP上下文/EPS承载上下文，new SGSN应使用old SGSN发过来的优先次序来决定哪些PDP上下文/EPS承载上下文需要保持active，哪些需要删除。在任何场景，new SGSN应首先更新在一个或多个GGSN/PGW里的所有上下文，然后去激活那些不能保持的上下文，在章节“SGSN-initiated PDP Context Deactivation Procedure”描述。这不应导致SGSN拒绝RAU。
注释8：如果MS是在PMM-CONNECTED状态，PDP上下文已经在Forward Relocation Request消息里发送，在"Serving RNS relocation procedures"章节描述。
    如果RAU失败并且超过允许的最大次数，或如果SGSN返回了带原因的RAU Reject消息，MS应进入PMM-DETACHED状态。
   如果LAU消息指示一个拒绝，这将通知MS，MS不能接入一个非PS业务知道一个成功的位置更新流程被执行。