小区更新.doc

小区更新过程：(2009-05-30 11:40:26)

小区更新过程在RRC连接模式下的任意一个状态都有可能被触发，触发小区更新过程的原因共有七个，它们分别介绍如下。
    1．重新进入服务区：当UE处于CELL_FACH或CELL_PCH状态时，在定时器T307或者T317超时前，UE已经超出了服务区并又重新进入服务区，UE将执行原因值为“re-enteringservicearea”的小区更新过程以通知UTRAN。
    2．RLC发生不可恢复的错：在确认模式RLC实体中，UE发现RLC无法恢复的错误，UE将执行原因值为“RLCunrecoverableerror”的小区更新过程以通知UTRAN。
    3．周期性小区更新：当UE找到一个合适的小区驻留并处于CELL_FACH或CELL_PCH状态，且信息单元（IE）“UETimersandconstants in connected mode”中的T305不能设置为“infinity”，等待定时器T305超时，UE将执行原因值为“periodical cell update”的小区更新过程以实现一种监管机制。
    4．小区重选：当UE处于CELL_PCH或者CELL_FACH状态并执行小区重选，或者当UE处于CELL_FACH状态且变量C_RNTI（CELL无线网络临时标识）为空，UE将执行原因值为“cellreselection”的小区更新过程去更新UTRAN中UE现在所驻留的当前小区的参数。
    5．无线链路失败：可以认为是无线链路失败的典型情况只有两种，一种是当UE在CELL_DCH状态发生无线链路失败；另一种就是当“UE Capabiltiy Information”消息传输失败时。若这两种情况发生任意一种，UE都将执行原因值为“Radio link failure”的小区更新过程。
    6．上行链路数据传输：当UE处于CELL_PCH或者URA_PCH状态时，如果UE要在上行链路上发送RLC数据PDU或控制PDU，并且用RB1或序号大于1的RB来承载，则UE将执行原因值为“uplinkdatatransmission”的小区更新过程。
    7．响应寻呼：UE处于URA_PCH或CELL_PCH状态时，接收一条“PAGINGTYPE1”消息，该消息包含IE“pagingRecordList”,并选择IE“utran-Identity”且保证该U-RNTI（UNTRAN无线网络临时标识）与分配给UE的U-RNTI一致，另外不包含IE“CN originated page to connected mode UE”, 若以上条件都满足，UE则会发起原因为“utran -pagingResponse”的小区更新过程。
    小区更新过程的详细流程：
    虽然触发小区更新过程的原因有七个之多，但是不管触发该过程的原因是什么，执行小区更新过程的流程都是一样的。小区更新过程的基本流程如图1所示。

图1 小区更新过程的基本流程

图2 触发的小区更新过程详细流程
    一旦小区更新过程被触发，首先停止监管周期性小区更新过程的定时器（T305），另外不论此时UE处于RRC连接模式下的什么状态都将转移到CELL_FACH状态。在该状态下，RRC会发送一条“CMAC_FCH_CONFIG_REQ”原语到MAC层去，使MAC进入FCH状态并配置FCH状态下的相关参数。UE将在上行CCCH向UTRAN发送一个小区更新请求(CELLUPDATE)消息。该消息的内容包括小区更新的原因、U-RNTI值、可选的测量信息以及是否存在出错原因等信息单元。小区更新的原因对应于以上七个原因中的一个，U-RNTI值就为网络为该UE分配的U-RNTI值。如果在组装该消息的时候发现专门用于记录消息出错的变量PROTOCOL_ERROR_INDICATOR或FAILURE_INDICATOR的值为TRUE，则在该消息IE“failurecause”中记录下相应的值。
    CELLUPDATE消息被封装在原语“CMAC_RANDOM_ACC_REQ”中由RRC发送到MAC层，接着由MAC子层来执行上行同步和随机接入过程。RRC发送完“CMACRANDOM_ACC_REQ”后就在下行信道上监听属于自己的物理信息（由MAC子层提供，MAC把来自网络的物理信息以原语CMAC_PHY_INFO_IND形式发送到RRC），若在规定时间内收到正确的物理信息，表明上行同步建立完成，RRC将等待接收来自网络的消息。
    RRC在接收到原语“CMAC_PHY_INFO_IND”之后就会开启一个定时器（T302），若该定时器超时但UE仍未收到来自网络的“CELLUPDATECONFIRM”消息，则转作异常处理：如果此时重发次数没有超过门限值（N302），UE将重新初始化小区更新过程；如果此时重发次数大于门限值则释放RRC连接，进入空闲。若在规定的时间内UE接收到来自网络的“CELLUPDATE CONFIRM”消息，RRC会停止T302计时。
    UTRAN在收到CELLUPDATE请求后组装小区更新证实（CELLUPDATECONFIRM）消息，CELL UPDATE CONFIRM可以通过下行DCCH发送给UE，也可以通过下行CCCH发送给UE，区别仅在于出现SRNS重定位或者需要加密的情况下用DCCH，否则用CCCH。
    CELLUPDATECONFIRM消息中的“状态指示”字段可以指示UE的进入状态。如果UTRAN指示UE进入CELL_DCH状态，则该消息中必须包含一个专用物理传输信道。若UTRAN指示UE进入CELL_FACH状态，而如果此时消息中没有分配新的C-RNTI，并且旧的C-RNTI已不存在，且如果重发次数没有超过门限值（N302），UE将重发CELLUPDATE请求；如果重发次数超过了门限值，网络将会释放RRC连接。UTRAN还可以通过该消息指示UE进入URA_PCH或者CELL_PCH状态，但进入这两个状态必须包含IE“UTRAN DRX cycle length coefficient”，否则将把该消息当作无效处理。该消息还可以包含释放无线承载的IE，重配置无线承载的IE以及改变某些已经存在的无线承载的某些属性的IE。此外该消息还可以给UE分配一个新的U-RNTI和可用的传输信道该传输信道的传输格式、每个CcTrCH中可用的传输信道格式组合集以及传输信道所对应的物理信道的相关信息（包括时隙、编码方式等信息）。
    UE端接收到CELLUPDATECONFIRM消息后，根据消息的内容配置MAC子层，如果网络要求UE进入CELL_DCH状态，则还需要物理层进行收/发同步。若该同步过程失败，UE会转作失同步处理：UE会去做测量，根据测量值重选小区，选择到合适的小区之后就会发原因为“Radio link failure”的小区更新过程；如果没有找到合适的小区（UE此时丢失覆盖），UE就会发起小区选择过程。如果此同步过程成功，UE就根据CELL UPDATE CONFIRM 消息中包含的信息单元，决定是否发送响应消息或者发送什么样的响应消息给UTRAN。UE将用AM RLC模式发送响应消息给UTRAN。响应消息被封装在原语RLC_AM_DATA_REQ中由RRC发送给RLC，RRC在收到RLC的确认之后（RLC_AM_DATA_CNF），就认为该消息已经发送出去了，小区更新过程结束。
如果UTRAN不接受UE的小区更新请求，则在下行CCCH上发送一个RRC连接释放(RRCCONNECTIONRELEASE)消息，UE收到该消息后返回空闲状态。
    下面是以UE在CELL_PCH状态下发起主叫，触发原因为“上行数据传输”的小区更新过程的流程（如图2）为例，清楚地展现了整个过程原语（消息）的收发情况以及状态的转移情况。