【導讀】綁定標識與DCH綁定在一起。建立Iub數(shù)據(jù)傳輸承載需要NodeB確認。RNC在FACH信道上發(fā)送RRCConnectionSetup消息給UE。該消息包括了UE請求的業(yè)務類型等信息，例如語音業(yè)務。通過初始直接傳輸過程后，可使用該信令連接傳輸UE和CN之間的NAS消息。告知網(wǎng)絡(luò)側(cè)UE已經(jīng)按照鑒權(quán)要求完成了鑒權(quán)。NAS消息被透明的傳輸?shù)経TRAN。UE向網(wǎng)絡(luò)側(cè)說明BearerCapability以及CalledNumber等內(nèi)容。關(guān)鍵點2，3，4，5：UE是否支持PDSCH，8PSK，PUSCH

　　

【正文】 4） ，可以通過 CCH或者 DCH，如果建立在 DCH，上下行各占用 1 個碼道（ SF=16）〔在 HS 業(yè)務建立的時候，要占用兩個碼道；且 PS 的速率包括信令連接占的碼道〕。類似還有 RNC 和 NodeB 之間的Iub 連接， RNC 和 CN 之間的 IU 連接，但是 Iub 連接是一直存在的，不需要在每次 UE 和CN 連接都去建立和釋放，而 Iu連接則必須每次去建立和釋放（這里是指面向連接的信令和數(shù)據(jù)承載，無連接的除外）。 （ 2） RL 是為了建立 RNC 和 NodeB 之間的 DCH的連接，只要數(shù)據(jù)走 DCH，必須配置這個鏈路。 RL 是一個邏輯概念，其實就是一個格 式集，數(shù)據(jù)在 L2 和 L1 之間傳輸（ MACDDCH/HSDSCH/DSCH/USCH FPDPCH/HSDPSCH 傳輸信 道 和 MACD FLOW（ macdhmachs）），在 DCH時要增加 /修改 DCH FP/HSDSCH FP，因此要配置，而在 CCH 時， L2L1 的鏈路已經(jīng)建立完成，因此不需要配置 RL，但 RNC 和 NodeB 的連接是存在的，所以 RL是格式集。在 RL之下還有一個叫 Iub 數(shù)據(jù)傳輸承載的東西，它和 RL的主要區(qū)別在于 Iub 數(shù)據(jù)承載承載的是 Iub 接口的數(shù)據(jù)，而 RL 是 Uu 口的數(shù)據(jù)， RL 是位于Iub 承載之上的。（可以這樣理解： Iub 承載是 AAL2 承載，公共信道的 FP 是建立在 AAL2上的，因此小區(qū)建立的時候會建立一些承載，如果要使用 DCH 信道，也要先建立 DCH 的AAL2 承載。） （ 3） RB 是 UE 和 UTRAN 之間的連接格式集，就是 UU 口 L L2的格式問題，即物理信道、傳輸信道、邏輯信道的配置問題。如果沒有業(yè)務， RB 是不需要的，因此如果要在CN/URTRN 和 UE 之間傳信令，只要有 RRC 連接即可（實際上也有無線承載，即 SRB），但只要有業(yè)務，就必須配置 RB，同樣，必須配置 Iub承載（只要有 DCH就必須去配置 DCH FP 的承載，同 RL 一樣）。 （ 4） RAB 是 UE 和 CN之間的連接的約定，體現(xiàn)在業(yè)務上，主要是 Qos 的配置。為了在無線環(huán)境中傳輸，就必須借助無線接入網(wǎng)，因此 RAB 分為 UE 和 UTRAN 之間的 RB 和 CN和 UTRAN 之間的 IU 承載。 （ 5）相關(guān)的問題就可以這要理解了： 如果沒有業(yè)務要建立，例如位置區(qū)登記、更新，只需要建立 RRC連接、 Iu 連接，而不需要去建立 RL、 Iub 承載、 Iu 承載、 RAB、 RB。 如果要在 CCH 上建業(yè)務，比如 PS8k業(yè)務，必須建立 RRC連接， Iu連接，然后建立 RAB、RB、 Iub 承載、 Iu 承載，但是不需要建立 RL。 這時一旦 RB 失敗，業(yè)務已經(jīng)失敗， RNC 將回復 CN 消息 RAB 指配響應指示失敗， CN決定是否釋放業(yè)務。 如果要在 DCH 上建 CS 業(yè)務，則必須建所有的連接和承載，并且 RRC 連接必須建立在DCH 上，這樣： 一旦 RRC 連接失敗，釋放所有的連接和承載，包括 RL； 一旦 RL配置失敗，如果存在原先配置，則恢復到原先配置， RNC 自己不會去釋放 RRC、RL、 Iu等，回復 CN RAB 指配響應指示失敗，按照 CN 新的指令去執(zhí)行，業(yè)務肯定要失敗的，一般來說，如 果 CN 發(fā)現(xiàn)業(yè)務失敗了，將會發(fā)起 IU 釋放的流程。 一旦 RB配置失敗， CS 業(yè)務是不行了，如果是在 RL RECFG COMMIT 之前收到 RB配置失敗， RL恢復到原來的 RL， RNC 回復 CN RAB 指配響應指示失敗，由 CN 決定新的流程；如果是在 RL RECFG COMMIT 之后收到 RB配置失敗，因為 RNC無法恢復原來的 RL，因此所有的業(yè)務都失敗了， RNC 向 CN回復 RAB 指配響應指示失敗，同時釋放所有的連接和承載。 如果要在 DCH 上建 PS 業(yè)務，所有的連接和承載都得建立，如果 RRC 連接建立在 DCH上，對于 RRC、 RL、 RB配置失敗的處理同 CS一樣，如果 RRC連接建在 CCH上時，其實處理還是一樣的 ?。注意一點：在 PS業(yè)務釋放的時候， CN 發(fā) RAB 指配，這時候需要去重新申請兩個碼道的資源去傳信令，如果沒有資源了，則異常釋放，不會執(zhí)行 RL 重配和 RL刪除了。 （ 6）在 TDSCDMA中，一個 UE 最多只有一個 RRC 連接，當執(zhí)行硬切換時，最多可以有兩條 RL，但一般都只有一個 RL（包括組合業(yè)務），多 RAB，兩個 Iu連接（ 1CS+1PS），多RB。 （ 7） SRB 呢？從某種意義上說， SRB 和 RB是個孿生兄弟， SRB 是信令 RB，在建 立 RRC連接的時候， SRB 就建立起來了，為了傳遞 UE 和 UTRAN 之間的信令，而 RB 是用戶面RB，只有在建立業(yè)務的時候，即需要傳遞用戶面數(shù)據(jù)的時候才建立 RB。在小區(qū)建立的時候，SRB0 就已經(jīng)建立了，傳 CCCH信令， SRB1SRB4 在 RRC 建立的時候建，傳 DCCH 信令，SRB5 以上都是業(yè)務 RB，其實就是 RB。 呼叫釋放信令詳解（前后臺） 呼叫釋放流程信令圖 釋放 RRC 連接 釋放 RRC 連接 上下行直傳： （ 1）（ 2）（ 3）（ 4）（ 5）（ 6） UTRAN 直接傳輸 UE 與 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 確認 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 ，消息中主要包含以下屬性： l n308：指 示 n308 的次數(shù)，詳見系統(tǒng)消息 1 中定時器的描述。 l releaseCause：指示釋放的原因值，本例為正常釋放。 RRC_RRC_CONN_REL消息 NBAP_RL_DEL_REQ NBAP_RL_DEL_REQ 消息分析見 0 ， 消息中主要包含以下屬性 ： l rL ID： 指示需要釋放的無線鏈路編號。 NBAP_RL_DEL_REQ 消息 導致呼叫釋放的異常分析 CN 發(fā)起 Uu 接口釋放 CNUE: Disconnect Operator determined barring Oamp。M 干預 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 連接釋放過程是由其它釋放過程間接導致的，如 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 連接釋放，并可間接導致 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 響應 IuUP 失敗 Release due to UE generated signaling connection release 用戶進行組合業(yè)務時（ CS+PS），UE 發(fā)起釋 放其中一個域的業(yè)務連接 No Resource Available Iu 連接建立時 Iu 資源不充足 Release due to UTRAN Generated Reason 通信過程中由于 UTRAN 側(cè)原因?qū)е碌尼尫?，? RNC 收到 Node B 的 Radio Link Failure Indication