本帖最后由 爱卫生 于 2012-4-18 22:50 编辑
回复 rHao1116 的帖子
以下为转载: “控制平面到RLC层的通道叫做SRB,用户平面到RLC层的通道叫做RB。SRB下来对应CCH,传输的信令;RB下来对应TCH,传输的业务。SRB1是RLC的 UM模式,传输不可靠的信令,诸如cellupdata complete消息 SRB2是RLC的 AM模式,用于传输可靠的信令。 SRB3/4是RLC的AM模式 ,用于传输NAS层信息。 这里需要强调的是,掉话与正常释放之间的区别。正常的业务释放一般是由电路域用户挂机或分组域结束访问数据业务,UE 通过上行直传告知CN 需要结束业务、释放资源、停止计费等。然后CN 向RNC 发起释放。而异常的业务释放,也就是掉话,一般是由于空口失步导致RNC 侧某个定时器超时,RNC 不可能无限制地为该链路保持资源等待下去。因此,超时之后,RNC 会认为链路已经无法恢复,于是向CN发起RAB Release Request或Iu Release Request,触发掉线。也就是说,正常释放与异常掉话的主要区别在于其释放过程,前者由CN 向RNC 发起,而后者由RNC向CN发起。”这个异常释放流程参考23.060的12.7.2。 RAB异常释放的常见原因有: (1)用户行为的原因。用户突然拔出数据卡导致数据卡掉电,或者未正常释放,NodeB侧会检测到上行失步,向RNC上报Radio Link Failure,当Radio Link Failure积累到一定次数,RNC会向CN发起释放,导致掉线统计。 (2)终端侧的原因。例如signaling Connection Release Indication引起的掉线。协议中引入signaling Connection Release Indication的最初目的,是为了防止终端异常而网络侧检测不到,导致网络侧无法释放资源的问题,因此signaling Connection Release Indication 触发IuRelease Request,本意是统计终端故障引起的掉线。而有的终端制造商为了降低产品耗电,设定在没有PS流量30 s后,会主动发送“signaling Connection Release Indication”,这就属于对信令的不规范使用。此过程是UE在用户不使用业务时主动发起的,不会影响用户主观感受,还可以主动释放空口资源,节省终端电源。为能更客观地反应网络的无线掉线率,后期各设备商的RNC侧在统计掉线率时,一般将Singnalling Connection ReleaseIndication引起的Iu Release Requst排除在外。此外,对很多终端而言,当上/下行均没有业务流量时,终端和系统会分别上报测量值为0的4B测量报告,RNC对测量报告进行计数,当两个方向连续收到的测量值为0的4B测量报告个数达到进入Idle状态门限后,RNC会主动发起Iu Release Request,释放原因为用户去激活(User Inactivity),UE进入Idle状态。网络侧释放Iu连接和RAB资源后,当用户侧再次发起业务请求时,UE会自动进行RRC连接,直接进行RAB 重建,无须进行PDP 激活,整个过程不影响用户感受。对于此种原因触发的Iu Release Requst,也不应算做异常掉线。 |