通信人家园

标题: RRCConnectionComplete带DetachRequest问题  [查看完整版帖子] [打印本页]

时间:  2011-8-4 16:46
作者: hlin841211     标题: RRCConnectionComplete带DetachRequest问题

为什么RRCConnectionComplete里可以带DetachRequestAttach发生过了吗?如果Attach发生了,为什么RRC连接会释放?
时间:  2011-8-4 19:57
作者: pxl888

<font size=\"3\">UE在idle下非关机去附着时RRCConnectionsetupComplete里带detachrequest消息。之前是发生过attach的,UE和ENB没有数据交互时,UE就进入idle状态,如果UE有数据要发送就重新发起随机接入进行RRC连接。</font>
时间:  2011-8-5 20:52
作者: hlin841211

UE和ENB没有数据交互时,UE就进入idle状态,但是UE不会在核心网注销?所有承载都还在?

[ 本帖最后由 hlin841211 于 2011-8-5 21:12 编辑 ]
时间:  2011-8-6 17:39
作者: jack1900

空口一般数秒钟没有流量就会被ENB释放,但UE到核心网的连接(默认承载)还在,UE并没有被核心网注销。只有当UE缺失TAU时,才会被核心网强制DETACH,那是以分钟/小时为数量级的。





时间:  2011-8-7 15:06
作者: CQI2_0

不是很清楚,但肯定不是楼上几位的答复,RRCSetupCmp是接入流程中的响应消息,是响应RRCSetup的,表明UE侧SRB1建立成功,一旦入网成功之后,不会主动发起这条消息。本来就是入网过程中的信令,无数据流量也属正常,所以为了这个目的是不可能的。

有一种场景需要这个,那就是IDLE下关机,由于IDLE态UE在核心网注册了的,注册目的是为了能够接收寻呼,此时如果关机,那核心网状态需要变为非注册,也就是我们打电话时常听到的对方关机的场景,这时候就需要先入网,然后通知到核心网,这条信令就可以起到这个作用。
时间:  2011-8-8 09:39
作者: hycl5410

36.331描述
A UE in RRC_CONNECTED initiates the UL information transfer procedure whenever there is a need to transfer NAS or non-3GPP dedicated information, except at RRC connection establishment in which case the NAS information is piggybacked to the RRCConnectionSetupComplete message.
这句解释了为什么detachrequest可以被带在RRC_con_cmp中。detach是NAS层信令,对于RRC层来说,是上层数据,RRC层应该用UL information transfer信令来传NAS层数据。而UE发起RRC请求之前是idle状态,必定要首先发起RRC连接请求。只不过是在一个普通的RRC连接之后“串联”了一个UL data的RRC数据包而已,这是协议明确说明可以有的。
可能发生场景楼上已经说明的很清楚了。
再解释这句“UE和ENB没有数据交互时,UE就进入idle状态,但是UE不会在核心网注销?所有承载都还在?”
答案都是肯定的。楼上各位都解释过了。没有数据传输的时候,定时器超时,就会触发S1的release,S1控制面的release就包括了RRC的release。除此之外还有用户面的release。这些release都不会影响UE在核心网的注册、EPS连接、各种bearer。RRC的release不过就是为了节省无线资源而已,没多大问题,需要用时再建即可。
时间:  2011-8-13 09:34
作者: hlin841211

看明白了,谢谢了




通信人家园 (https://www.txrjy.com/) Powered by C114