RRCConnectionComplete带DetachRequest问题
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不过就是为了节省无线资源而已，没多大问题，需要用时再建即可。
UE在idle下非关机去附着时RRCConnectionsetupComplete里带detachrequest消息。之前是发生过attach的，UE和ENB没有数据交互时，UE就进入idle状态，如果UE有数据要发送就重新发起随机接入进行RRC连接。
UE和ENB没有数据交互时，UE就进入idle状态，但是UE不会在核心网注销？s1连接还在？默认承载还在？
UE和ENB没有数据交互时，UE就进入idle状态，但是UE不会在核心网注销？s1连接还在？默认承载还在？
空口一般数秒钟没有流量就会被ENB释放，但UE到核心网的连接（默认承载）还在，UE并没有被核心网注销。只有当UE缺失TAU时，才会被核心网强制DETACH，那是以分钟/小时为数量级的。
不是很清楚，但肯定不是楼上几位的答复，RRCSetupCmp是接入流程中的响应消息，是响应RRCSetup的，表明UE侧SRB1建立成功，一旦入网成功之后，不会主动发起这条消息。本来就是入网过程中的信令，无数据流量也属正常，所以为了这个目的是不可能的。
有一种场景需要这个，那就是IDLE下关机，由于IDLE态UE在核心网注册了的，注册目的是为了能够接收寻呼，此时如果关机，那核心网状态需要变为非注册，也就是我们打电话时常听到的对方关机的场景，这时候就需要先入网，然后通知到核心网，这条信令就可以起到这个作用。
看明白了，谢谢了