【正文】 務(wù)，RB是不需要的，因此如果要在CN/URTRN和UE之間傳信令，只要有RRC連接即可（實(shí)際上也有無線承載，即SRB），但只要有業(yè)務(wù)，就必須配置RB，同樣，必須配置Iub承載（只要有DCH就必須去配置DCH FP的承載，同RL一樣）。（4）RAB是UE和CN之間的連接的約定，體現(xiàn)在業(yè)務(wù)上，主要是Qos的配置。為了在無線環(huán)境中傳輸，就必須借助無線接入網(wǎng)，因此RAB分為UE和UTRAN之間的RB和CN和UTRAN之間的IU承載。（5）相關(guān)的問題就可以這要理解了： 如果沒有業(yè)務(wù)要建立，例如位置區(qū)登記、更新，只需要建立RRC連接、Iu連接，而不需要去建立RL、Iub承載、Iu承載、RAB、RB。 如果要在CCH上建業(yè)務(wù)，比如PS8k業(yè)務(wù)，必須建立RRC連接，Iu連接，然后建立RAB、RB、Iub承載、Iu承載，但是不需要建立RL。 這時(shí)一旦RB失敗，業(yè)務(wù)已經(jīng)失敗，RNC將回復(fù)CN消息RAB指配響應(yīng)指示失敗，CN決定是否釋放業(yè)務(wù)。 如果要在DCH上建CS業(yè)務(wù)，則必須建所有的連接和承載，并且RRC連接必須建立在DCH上，這樣： 一旦RRC連接失敗，釋放所有的連接和承載，包括RL； 一旦RL配置失敗，如果存在原先配置，則恢復(fù)到原先配置，RNC自己不會去釋放RRC、RL、Iu等，回復(fù)CN RAB指配響應(yīng)指示失敗，按照CN新的指令去執(zhí)行，業(yè)務(wù)肯定要失敗的，一般來說，如果CN發(fā)現(xiàn)業(yè)務(wù)失敗了，將會發(fā)起IU釋放的流程。 一旦RB配置失敗，CS業(yè)務(wù)是不行了，如果是在RL RECFG COMMIT之前收到RB配置失敗，RL恢復(fù)到原來的RL，RNC回復(fù)CN RAB指配響應(yīng)指示失敗，由CN決定新的流程；如果是在RL RECFG COMMIT之后收到RB配置失敗，因?yàn)镽NC無法恢復(fù)原來的RL，因此所有的業(yè)務(wù)都失敗了，RNC向CN回復(fù)RAB指配響應(yīng)指示失敗，同時(shí)釋放所有的連接和承載。 如果要在DCH上建PS業(yè)務(wù)，所有的連接和承載都得建立，如果RRC連接建立在DCH上，對于RRC、RL、RB配置失敗的處理同CS一樣，如果RRC連接建在CCH上時(shí)，其實(shí)處理還是一樣的?。注意一點(diǎn)：在PS業(yè)務(wù)釋放的時(shí)候，CN發(fā)RAB指配，這時(shí)候需要去重新申請兩個(gè)碼道的資源去傳信令，如果沒有資源了，則異常釋放，不會執(zhí)行RL重配和RL刪除了。（6）在TDSCDMA中，一個(gè)UE最多只有一個(gè)RRC連接，當(dāng)執(zhí)行硬切換時(shí)，最多可以有兩條RL，但一般都只有一個(gè)RL（包括組合業(yè)務(wù)），多RAB，兩個(gè)Iu連接（1CS+1PS），多RB。（7）SRB呢？從某種意義上說，SRB和RB是個(gè)孿生兄弟，SRB是信令RB，在建立RRC連接的時(shí)候，SRB就建立起來了，為了傳遞UE和UTRAN之間的信令，而RB是用戶面RB，只有在建立業(yè)務(wù)的時(shí)候，即需要傳遞用戶面數(shù)據(jù)的時(shí)候才建立RB。在小區(qū)建立的時(shí)候，SRB0就已經(jīng)建立了，傳CCCH信令，SRB1SRB4在RRC建立的時(shí)候建，傳DCCH信令，SRB5以上都是業(yè)務(wù)RB，其實(shí)就是RB。呼叫釋放信令詳解（前后臺）呼叫釋放流程信令圖 釋放RRC連接釋放RRC連接上下行直傳：（1）（2）（3）（4）（5）（6）UTRAN直接傳輸U(kuò)E與CN之間的NAS消息（包括釋放請求和釋放完成等）。UE發(fā)起呼叫釋放的主要的NAS消息關(guān)系如下：UE發(fā)起呼叫釋放的主要的NAS消息關(guān)系圖釋放RRC連接：（7）CN通過給RNC發(fā)送RANAP消息Iu Release Command消息發(fā)起專用信道的釋放過程。（8）RNC向CN回送RANAP消息Iu Release Complete（9）CN與RNC通過ALCAP協(xié)議釋放Iu承載（10）RNC向UE發(fā)送RRC消息RRC Connection Release來釋放該RRC連。（11）UE向RNC回送RRC消息RRC Connection Release Complete確認(rèn)RRC連接的釋放（12）RNC向NodeB發(fā)送NBAP消息Radio Link Deletion （13）NodeB向RNC回送NBAP消息Radio Link Deletion Response （14）NodeB通過ALCAP協(xié)議釋放與RNC的Iub傳輸承載。UE發(fā)起僅釋放Iu連接而不釋放RRC連接的流程圖呼叫釋放過程前后臺信令解析RANAP_IU_RELEASECOMMAND RANAP_IU_RELEASECOMMAND消息見0 ，消息中主要包含以下屬性：l nAS CAUSE：指示釋放的原因。本例為正常釋放。 RANAP_IU_RELEASECOMMAND消息RRC_RRC_CONN_REL RRC_RRC_CONN_REL消息分析見0 ，消息中主要包含以下屬性：ln308：指示n308的次數(shù)，詳見系統(tǒng)消息1中定時(shí)器的描述。lreleaseCause：指示釋放的原因值，本例為正常釋放。RRC_RRC_CONN_REL消息NBAP_RL_DEL_REQ NBAP_RL_DEL_REQ消息分析見0 ，消息中主要包含以下屬性：lrL ID：指示需要釋放的無線鏈路編號。NBAP_RL_DEL_REQ消息導(dǎo)致呼叫釋放的異常分析CN發(fā)起 Uu接口釋放 CNUE: Disconnect Operator determined barring Oamp。M 干預(yù) Normal call clearing 網(wǎng)絡(luò)側(cè)發(fā)起呼叫釋放（正常釋放） busy 被叫忙 Destination out of order 網(wǎng)絡(luò)側(cè)異常 No circuit/channel available 資源不夠或 CN異常 Network out of order 網(wǎng)絡(luò)側(cè)異常 requested circuit/channel not available 該用戶不支持請求的 QoS Resources unavailable, unspecified 網(wǎng)絡(luò)側(cè)異常UE發(fā)起 Uu接口釋放 UECN: Disconnect Normal call clearing 用戶發(fā)起呼叫釋放（正常釋放） Uu接口 RRC連接釋放 RRC 連接釋放過程是由其它釋放過程間接導(dǎo)致的，如 CN的NAS 層發(fā)起釋放、 UE NAS層發(fā)起釋放、RNC 發(fā)起的 Iu 釋放。 RNCUE: RRC Connection Release normal event 網(wǎng)絡(luò)側(cè)或 UE 側(cè)發(fā)起正常呼叫釋放以及其它異常引起的RRC連接釋放Iu接口釋放 CN與 RNC都可以發(fā)起特定 UE 的 Iu 接口釋放。RNC 向 CN發(fā)送 Iu Release Request 發(fā)起特定 UE 的 Iu 連接釋放，并可間接導(dǎo)致 Uu 接口釋放。CN向 RNC 發(fā)起的 Iu Release過程不能由 CN RANAP層直接發(fā)起，它是由其它釋放過程間接產(chǎn)生的，如 CN的 NAS 層發(fā)起釋放、UE NAS 層發(fā)起釋放、RNC 發(fā)起的 Iu 釋放。 RNCCN: Iu Release Request RAB preempted 搶占低優(yōu)先級用戶 Successful Relocation SRNS 重定位過程成功，釋放源 RNC Iu UP Failure Iu連接建立過程中或SRNS重定位過程中，CN響應(yīng) IuUP 失敗 Release due to UE generated signaling connection release 用戶進(jìn)行組合業(yè)務(wù)時(shí)（CS+PS），UE 發(fā)起釋放其中一個(gè)域的業(yè)務(wù)連接 No Resource Available Iu 連接建立時(shí) Iu 資源不充足 Release due to UTRAN Generated Reason 通信過程中由于UTRAN側(cè)原因?qū)е碌尼尫牛?RNC 收到 Node B 的 Radio Link Failure Indication