Cell Update 是手机在通话状态下， 由于无线环境或者是干扰的原因， 收不到网络测下发的信令消息， 而发起的一个避免掉话的应急响应， Cell Update 可以在原小区也可以在别的小区进行更新， 如果更新成功的话， 从信令上看是掉话了的， 但是从用户感知上来说，通话仍然继续， 也就是说， 用户感觉不到掉话， 要是更新失败， 肯定是要掉话的。 解决此类原因， 尽量避免在通话状态下发起小区更新， 也就是改善无线环境， 排除上下行干扰， 优化无线链路维持参数等。
小区更新过程的主要功能如下：
(1) 通知UTRAN， 处于CELL_PCH或CELL_FACH状态的UE重新进入了服务区；
(2) 通知UTRAN， UE的AM RLC实体发生了不可恢复的RLC错误；
(3) 周期性小区更新可作为CELL_PCH或CELL_FACH状态下的UE监管机制；
(4) 通知UTRAN， 处于CELL_PCH或CELL_FACH状态下的UE发生小区重选后所在的小区；
(5) 用于处于CELL_DCH状态下的UE发生无线链路故障时的处理；
(6) 用于UE 发送UE CAPABILITY INFORMATION消息失败时的处理；
(7) 通知UTRAN， 处于CELL_PCH状态下的UE收到寻呼或需要发送上行数据态转移到CELL_FACH状态。
Cell Update 的完整信令如下
1. UE通过CCCH信道传送Cell Update REQ 消息， 请求小区更新操作。
2. NodeB 收到并处理 CELL UPDATA REQ 消息， 将消息打包成 RACH 帧发送到RNC。
3. RNC 收到并处理该 RACH 数据帧， 完成小区更新后向 NodeB 返回 CELL UPDATE COMFIRM 消息。
4.NodeB收到并处理 DCH 数据， 将消息 CELL UPDATA COMFIRM 发送给 UE。
深层次的理解：
由于终端物理层对物理信道数据进行 CRC 校验，如果误码率较高，物理层就会判断为失步(160ms），经过 T313 的时间， 没有连续检测到 N315 个同步， 定时器超时， 就会释放与原基站的 RL。 读广播，重新搜索小区，在新小区上建立无线链路， 进入 cell DCH， 收到 cell update confirm， 配置 RB 或者物理层参数。
在 RL 同步状态下， 当 CC 子系统检测到连续 N313个失步后， 给 L1C 上报一个失步状态原语，L1C 将此失步原语上报 RRC， RRC 会启动定时器 T313； CC 开始检测同步， 如果检测到连续 N315个同步， 则上报一个同步原语给 L1C， L1C 上报给 RRC， 如果 RRC 收到这个同步原语的时候T313 没有失效， 则 T313 复位， 链路保持同步状态。 如果收到这个同步原语的时间是 T313失效以后， 则链路失步， RRC 将删除无线链路， 并进入 Cell Update 过程。
小区更新流程图
小区更新过程在RRC连接模式下的任意一个状态都有可能被触发， 触发小区更新过程的原因共有七个， 它们分别介绍如下：
1． 重新进入服务区：
当UE处于CELL_FACH或CELL_PCH状态时， 在定时器T307 或者T317超 时 前 ， UE 已 经 超 出 了 服 务 区 并 又 重 新 进 入 服 务 区 ， UE 将 执 行 原 因 值 为“re-entering servce area” 的小区更新过程以通知UTRAN。
2． RLC发生不可恢复的错：
在确认模式RLC实体中， UE发现RLC无法恢复的错误， UE将执行原因值为“RLC unrecoverable error” 的小区更新过程以通知UTRAN。
3． 周期性小区更新：
当UE找到一个合适的小区驻留并处于CELL_FACH或CELL_PCH状态且信息单元（ IE） “UE Timers and constants in connected mode” 中的T305 不能设置为“infinity” ， 等待定时器T305 超时， UE将执行原因值为“periodical cell update” 的小区更新过程以实现一种监管机制。
4． 小区重选：
当UE处于CELL_PCH或者CELL_FACH状态并执行小区重选，或者当UE处于CELL_FACH状态且变量C_RNTI（CELL无线 网 络临时标识） 为 空， UE将执行原 因 值为“cell reselection” 的小区更新过程去更新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将执行原因值为“uplink data transmission” 的小区更新过程。
7． 响应寻呼：
UE处于URA_PCH或CELL_PCH状态时， 接收一条“PAGINGTYPE1” 消息， 该消息包含IE“paging RecordList” , 并选择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的值为TR E， 则在该消息IE“failurecause” 中记录下相应的值。
CELLUPDATE消息被封装在原语“CMAC_RANDOM_ACC_REQ” 中由RRC发送到MAC层， 接着由MAC子层来执行上行同步和随机接入过程。 RRC发送完“CMAC_RANDOM_ACC_REQ” 后就在下行信道上监听属于自 己的物理信息（ 由MAC子层提供， MAC把来自 网络的物理信息以原语CMAC_PHY_INFO_IND形式发送到RRC）， 若在规定时间内收到正确的物理信息， 表明上行同步建立完成， RRC将等待接收来自网络的消息。
RRC在接收到原语“CMAC_PHY_INFO_IND” 之后就会开启一个定时器（T302）， 若该定时器超时但UE仍未收到来自网络的“CELLUPDATECONFIRM” 消息， 则转作异常处理： 如果此时重发次数没有超过门限值（N302）， UE将重新初始化小区更新过程； 如果此时重发次数大于门限值则释放RRC连接， 进入空闲。 若在规定的时间内UE接收到来自网络的“CELLUPDATECONFIRM” 消息， RRC会停止T302 计时。
UTRAN在收到CELLUPDATE请求后组装小区更新证实（CELLUPDATECONFIRM） 消息， CELL UPDATE CONFIRM可以通过下行DCCH发送给UE， 也可以通过下行CCCH发送给UE， 区别仅在于出现SRNS重定位或者需要加密的情况下用DCCH， 否则用CCCH。
CELL UPDATE CONFIRM消息中的“状态指示” 字段可以指示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子层， 如果网络要进入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） 为例， 清楚地展现了整个过程原语（消息）的收发况以及状态的转移情况。
519
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
