[Telecom]RAB/RB/RL/RRC

定義

RAB：Radio Access Bearer，無線接入承載：由接入層提供給NAS的在UE和CN之間傳輸使用者資料的服務。RAB可以看作是UE與CN之間接入層向非接入層提供的業務（不關心該承載是以何種方式實現的），主要用於使用者資料的傳輸。RAB直接與UE業務相關，它涉及接入層各個協定模組，在空中介面上，RAB反映為無線承載（RB）。

RB：Radio Bearer，無線承載：由層2提供給上層的在SRNC和UE之間傳輸使用者資料的服務。RRC連接也可以看作是一種承載信令的RB。

RL：Radio Link，無線鏈路：單個UE和UTRAN之間的邏輯連結，在物理實現上一條RL包含了一條或者多條無線傳輸承載。在UE與一個UTRAN接入點（通常指社區）之間最多存在一條無線鏈路。

RRC：Radio Resource Control，RRC連接在UE與UTRAN之間傳輸無線網路信令，如進行無線資源的分配等等。RRC連接在呼叫建立之初建立，在通話結束後釋放，並在期間一直維持。每個UE最多只有一個RRC連接；使用資料業務時，沒有RRC連接的狀態稱為空閒狀態（IDLE），有RRC連接的狀態分為CELL_DCH、CELL_FACH、CELL_PCH和URA_PCH四種狀態。

圖解

RAB是CN和UE之間的通道，RB是RNC和UE之間的通道，RL是NODEB和UE之間的通道，如下圖。

          

              RAB = RB+AAL2

CN<--------------------------------->UE

    Iu(AAL2)                    RB

CN<-------->RNC<-------------------->UE

                                    RL

                   NodeB<----------->UE

建RAB承載業務，必須先建立RB；想建好RB，那必須有RL，想要RL，那必須發起RRC連接建立請求。

概念解釋

1、RRC連接是為了建立UE和UTRAN之間的信令連接（SRB1-SRB4），可以通過CCH或者DCH。（SRB是RB的一種，主要用於承載信令，在控制平面，RLC 向上層提供的業務為無線信令承載）

2、RL是UE和指定CELL之間的一個專有邏輯鏈路，是為了建立RNC和NodeB之間的DCH的連接，只要資料走DCH，必須配置這個鏈路。（RL是一個邏輯概念，在CCH時，L2->L1的鏈路已經建立完成，不需要配置RL）。RL是位於Iub承載之上的，RL是Uu口的資料，Iub資料承載承載的是Iub介面的資料。一個社區只能和特定UE有一條RL，UE可以和多個社區有RL，RL的資訊有Frame Offset， Chip Offset，MAX DL Power等信息。RL不涉及到任何業務類型，只是說明UE和某個社區有無線連接，UE可以從這個連接收發資料。

3、RB是UE和UTRAN之間的連接格式集，就是Uu口L1、L2的格式問題，即物理通道、傳輸通道、邏輯通道的配置問題。如果沒有業務，RB是不需要的，因此如果要在CN/URTRN和UE之間傳信令，只要有RRC連接即可。但只要有業務，就必須配置RB。

4、RAB是UE和CN之間的連接的約定，體現在業務上，包括業務速率/Qos的配置。為了在無線環境中傳輸，就必須借助無線接入網，因此RAB分為UE和UTRAN之間的RB和CN和UTRAN之間的IU承載。UE在建多個業務時候可以有多個RAB，例如UE同時有CS域的語音業務和PS域的資料業務。

備註    
    ·                如果沒有業務要建立，例如位置區登記、更新，只需要建立RRC連接、Iu連接。

   ·                如果要在CCH上建業務，比如PS8k業務，必須建立RRC連接，Iu連接，然後建立                                          RAB、RB、Iub承載、Iu承載，但是不需要建立RL。
   ·                如果要在DCH上建CS業務，則必須建所有的連接和承載，並且RRC連接必須建立
                 在DCH上。
   ·                UE做1個CS業務，若是AMR，建立1個RAB，3個RB；UE做1個CS業務，若是VP，
                建立1 個RAB，1個RB；UE做1個CS業務+1個PS，若是AMR+PS，建立2個RAB
                ，4個RB。

[Android]System Property

Every property has a name and value. Both name and value are text strings. Property is heavily used in Android to record system setting or exchange information between processes. The property is globally visible in the whole system. Every process can get/set a property.

On system initialization, Android will allocates a block of shared memory for storing the properties. This is done in “init” daemon whose source code is at: device/system/init. The “init” daemon will start a Property Service. The Property Service is running in the process of “init” daemon. Every client that wants to SET property needs to connect to the Property Service and send message to Property Service. Property Service will update/create the property in shared memory. Any client that wants to GET property can read the property from the shared memory directly. This promotes the read performance.

The client application can invoke the API function exposed from libcutils to GET/SET a property. The source code of libcutils locates at: device/libs/cutils.

The API function is:

int property_get(const char *key, char *value, const char *default_value);

int property_set(const char *key, const char *value);

The libcutils is in turn calling the __system_property_xxx function in libc to get a property from the shared memory. The source code of libc is at: device/system/bionic.

The Property Service is also in turn calling the __system_property_init function in libc to initiate the shared memory for properties. When starting the Property Service will load the default properties from below files:

/default.prop

/system/build.prop

/system/default.prop

/data/local.prop

The properties are loaded in the above order. Later loaded properties will override the previous values. After those properties are loaded, the last loaded is the persistent properties which is persisted in /data/property.

Special Properties

If a property’s name begins with “ro.”, then this property is treated as a read-only property. Once set, the value of the property can’t be changed.

If a property’s name begins with “persist.”, then when setting this property, the value will be written to /data/property, too.

If a property’s name begins with “net.”, when when setting this property, the “net.change” property will be set automatically to contain the name of the last updated property. (It’s tricky. The netresolve module uses this property to track if there is any change on the net.* properties.)

The property “ctrl.start” and “ctrl.stop” is used to start and stop a service. Every service must be defined in /init.rc. On system startup, the init daemon will parse the init.rc and start the Property Service. Once received a request to set the property of “ctrl.start”, the Property Service will use the property value as the service name to find the service and then start the service. The service starting result is then put to the property “init.svc.”. The client application can poll the value of that property to determine the result.

Android toolbox

The Android toolbox provides two applets: setprop and getprop to get and set properties. The usage is:

getprop

setprop  

Java

The java application can use the System.getProperty() and System.setProperty() function to Get and Set the property.

Action

By default the set property will only cause "init" daemon to write to shared memory, it won't execute any script or binary. But you can add your actions to correspond to property change in init.rc. For example, in the default init.rc, you can find.

# adbd on at boot in emulator
on property:ro.kernel.qemu=1
    start adbd

on property:persist.service.adb.enable=1
    start adbd

on property:persist.service.adb.enable=0
    stop adbd

So if you set persist.service.adb.enable to 1, the "init" daemon knows it has actions to do, then it will start adbd service.

[Telecom]SFN v.s. CFN

(英) SFN            Cell System Frame Number counter. SFN is sent on BCH. SFN is used for paging groups and system information scheduling etc.     In FDD SFN = BFN adjusted with T_cell.    In TDD, if Inter Node B synchronisation port is used, SFN is locked to the BFN (i.e. SFN mod 256 = BFN mod 256).    Range: 0 to 4095 frames. CFN            Connection Frame Number (counter). CFN is the frame counter used for the L2/transport channel synchronisation   between UE and UTRAN. A CFN value is associated to each TBS and it is passed together with it through the MAC-L1 SAP.        CFN provides a common frame reference (at L2) to be used e.g. for synchronised transport channel reconfiguration . The duration of the CFN cycle is longer than the maximum allowed transport delay between MAC and L1 (in UTRAN side, between SRNC and Node B, because the L1 functions that handle the transport channel synchronisation are in the Node B).    Range: 0 to 255 frames. When used for PCH the range is 0 to 4095 frames. (中) 概念 SFN：System Frame Number，社區系統幀號計數器。 CFN：Connect Frame Number，連接幀號計數器。 解釋 SFN 被包含在系統消息中在 BCH 通道上對整個社區進行廣播（對應物理通道 P-CCPCH），用來尋呼群組和系統資訊的調度。 CFN是下行和上行專用物理通道DPCH相關的幀記號，用於UE和UTRAN傳輸通道的同步。SFN是在UE進行社區同步時從P-CCPCH中讀取的資訊，CFN是在進行二次交織後用來識別無線幀用的。 SFN-CFN觀測時間差（observed time difference） SFN-CFN觀測時間差：單位是無線幀。同時UE中CFN與目標相鄰社區SFN之間的時間差。切換時，RNC可以根據該參數判斷UE與鄰社區的同步情況。這項測量用於切換定時的目的，用來識別啟動集社區和鄰區的時間差。 SFN-SFN觀測時間差 這項測量用於識別兩個社區之間的時間差。SFN-SFN觀測時間差表示UE接收到相鄰兩個社區的P-CCPCH幀的起始時刻之差。

[Telecom]Cell Camping

• 當找到suitable cell，手機Camping On之後，進入閒置模式(Idle Mode)。   
• 在閒置模式時，手機將監控BCH、PCH、同步和進行Power Control。實行PLMN和Cell Selection、Cell Reselection與Cell Camping以及Location Registration。  
• 當手機Camping on cell後，會不斷執行Cell reselection。至於Camping on any cell的時機僅於手機無法Camping on suitable cell，如Emergency call。 

[Telecom]3G：UMTS狀態下資料業務的終端狀態-IDLE、CONNECTED

UE有兩種基本的運行模式：空閒模式(idle mode)和連接模式(connected mode)

3G-UMTS的狀態機制，在UE使用共用通道時，可以使用為用戶優化資源管理，但結構複雜，設計、實現和運營增加了複雜度。

1、空閒模式：

UE處於待機狀態，沒有業務的存在，UE和UTRAN之間沒有連接（UTRAN 不保留空閒模式下的UE 資訊），UTRAN內沒有任何有關此UE的資訊；通過非接入層標識如IMSI、TMSI或P-TMSI等標誌來區分UE；

2、連接模式：

·                當UE完成RRC連接建立時，UE才從空閒模式轉移到連接模式；

·                UE有4種狀態： Cell-DCH, Cell-FACH, Cell-PCH, URA-PCH。通過無線網路臨時標識區分UE；

·                當 RRC 連接釋放後 UE 從連接模式到空閒模式；

·                電路域業務的使用者只有空閒、Cell-DCH狀態。

2.1  CELL_DCH 狀態（Dedicated channel）

·                UE處於啟動狀態，正在利用自己專用的物理通道進行通信，上下行都具有專用通道，同時根據 UTRAN的分配情況，UE 可以使用專用傳輸通道 DCH、上行共用傳輸通道 USCH、下行共用傳輸通道 DSCH，以及這些傳輸通道的組合。

·                對於控制通道也使用專用的控制通道DCCH來進行傳輸。

·                UTRAN準確的知道UE所位於的社區。

2.2  CELL-FACH狀態（Forward access channel）

·                UE處於啟動狀態，但是上下行都只有少量的資料需要傳輸，UE 與 UTRAN之間不存在專用物理通道連接，上下行的資料在公共通道上傳輸（如RACH）。

·                下行需要隨時監聽FACH上是否有自己的資訊。在上行方向可以使用公共或共用傳輸通道， UE在任何時候都可以在相關傳輸通道上發起接入過程（不必先發起尋呼）。

·                根據 UTRAN的分配情況，UE 在此狀態下可以使用 USCH 或 DSCH 傳輸通道，UTRAN 也可以根據 UE 最後一次執行的社區更新過程，知道 UE 當前所處的社區。

·                在CELL-FACH狀態下無需保持上行同步，當有上下行資料發送時，終端或基站會通過重新建立上行同步的機制恢復傳輸。CELL-FACH狀態的這一特點能夠儘量減少維持同步帶來的系統開銷和終端的功耗。

2.3  CELL_PCH 狀態（ Paging channel ）

·                UE上下行都沒有資料傳送，UE 與 UTRAN 之間不存在專用物理通道連接，但需要監聽尋呼通道，以便收聽尋呼，因此UE此時進入非連續接收，可有效的節電。

·                UTRAN根據 UE 上次在 CELL_FACH狀態下執行的最後一次社區更新過程，準確的知道UE所位於的社區，這樣， UE所位於的社區變化後，UTRAN需要更新UE的社區資訊。

·                如果 UE 需要發送上行資料（回應尋呼或者發起呼叫） ，必需先從 CELL_PCH狀態轉移到 CELL_FACH狀態。

2.4  URA_PCH 狀態 （ Paging channel ）

·                UE上下行都沒有資料傳送，UE 與UTRAN之間不存在專用物理通道連接，需要監聽尋呼通道，進入非連續接收（使用 DRX 方式去監聽 PICH所指示的 PCH通道）。

·                UTRAN 根據 UE 上次在 CELL_FACH狀態下執行的最後一次URA更新過程，知道 UE 當前所處的 URA。UTRAN只知道UE所位於的URA（一個URA包含多個社區），也就是說，UTRAN只在UE位於的URA發生變化後才更新其位置資訊，這樣更加節約了資源，減少了信令。

·                如果 UE 需要發送上行資料（回應尋呼或者發起呼叫），必需先從 URA_PCH 狀態轉移到 CELL_FACH狀態。

	Uu介面	Iu介面	網路尋呼信令負荷	終端耗電
Cell_DCH	使用專用通道，有RRC連接	存在連接	低	高
Cell_FACH	使用公共通道，有RRC連接	存在連接	低	高
Cell_PCH	無RRC連接	存在連接	低	中
URA_PCH	無RRC連接	存在連接	中	低
空閒狀態	無RRC連接	不存在連接	高	低

原文出處 : http://blog.sina.com.cn/s/blog_6617106b01015usi.html

[Telecom]WCDMA的呼叫流程分析(轉)

一、概述

    當前，第三代移動通信系統已經越來越成為人們關注的焦點，作為兩大主流體制之一

的WCDMA系統將在未來全球移動通信市場扮演重要的角色。對無線通訊系統來說，一個呼叫能否建立是一個很重要的問題。呼叫的建立涉及無線網路中的很多網路元素，是通信系統的基本功能。對WCDMA系統的呼叫流程進行分析將有助於整個系統的測試和維護。本文主要

介紹電路交換（CS）和封包交換（PS）兩種業務的呼叫流程，並進行對比分析。

二、WCDMA的系統結構

    本節我們將介紹一下WCDMA的系統結構及協定棧結構。對呼叫流程中將涉及的網路元素和協議層我們將重點描述。

    從功能上，WCDMA系統由三部分組成：CN（核心網）、UTRAN（UMTS地面接入網）和UE（使用者設備）。CN負責處理與外部網路之間的呼叫和資料連接的交換和路由選擇。UTRAN處理所有與無線接入相關的功能。UE則是與使用者的介面。CN與UTRAN之間的介面稱為Iu介面，

UTRAN與UE之間的介面稱為Uu介面。

    WCDMA的系統結構，其中UTRAN是由一個或多個無線網路子系統（RNS）組成。一個RNS由一個無線網路控制器（RNC）和一個或多個Node B組成。RNC可以通過Iur介面與另一個RNC相連。RNC與Node B之間通過Iub介面相連。

    在這裡我們介紹的呼叫流程是從UE與CN之間的端到端的呼叫流程，其中包括UE主動發起呼叫（我們通常稱之為UE起呼）和UE接受呼叫（UE被呼）。由於呼叫的另一端可能為PSTN、PLMN、ISDN等不同網路系統終端，將涉及有線或無線網路之間的消息交互，我們將不在此介紹。

    下面給出了WCDMA系統的協定棧，我們將簡要介紹一下呼叫流程中可能涉及到的協議模塊。與無線接入無關的高層協定模組我們通稱為非接入層（NAS），NAS層存在於UE和CN中

，主要處理與業務相關的功能。實體層我們稱之為L1層。在Uu介面上，實體層是WCDMA系統中重要的部分，主要處理無線資料的傳輸。而Iub、Iu以及Iur介面是有線連接的，實體層通常是指光纖、電纜等物理連接實體。媒體接入控制（MAC）和無線鏈路控制（RLC）協議屬於第二層（L2）,主要提供資料的傳輸和交換。無線資源控制（RRC）協議主要完成無線資源的管理和分配。其中Node B的RRC、RLC、MAC模組僅完成系統廣播功能，大部分無線資源管理功能都在RNC中實現。Node B應用部分（NBAP）主要處理Iub介面的信令，FP則處理各介面的資料傳輸。無線接入網應用部分（RANAP）和網路業務接入點（RNSAP）協議分別處理Iu以及Iur介面的信令傳輸。在呼叫流程中主要涉及Uu、Iub以及Iu介面及相關協定模塊，我們主要介紹與WCDMA無線接入相關的部分，其他如RNC與Node B、RNC與CN之間有線傳輸（在Release99協議中採用ATM傳輸）採用的均是通用的傳輸方式，我們將不再介紹。

三、呼叫處理流程

    在介紹呼叫處理流程之前，我們首先要瞭解幾個概念：RRC連接。RRC連接是UE與UTRAN的RRC協定層之間建立的一種雙向點到點的連接。對一個UE來說，至多存在一條RRC連接。RRC連接在UE與UTRAN之間傳輸無線網路信令，如進行無線資源的分配等等。RRC連接在呼叫建立之初建立，在通話結束後釋放，並在期間一直維持。

    Iu信令連接。如果說RRC連接建立了UE與UTRAN之間的信令通路，那麼Iu信令連接則是建立了UE與CN之間的信令通路。Iu信令連接主要傳輸UE與CN之間非接入層信令。在UTRAN中，非接入層信令是通過上下行直接傳輸信令透明傳輸的。

認證。出於網路安全性能考慮，在呼叫建立時，網路必須對UE進行認證。

    無線接入承載（RAB）。RAB可以看作是UE與CN之間接入層向非接入層提供的業務，主要用於使用者資料的傳輸。RAB直接與UE業務相關，它涉及接入層各個協定模組，在空中介面上，RAB反映為無線承載（RB）。

    無線承載（RB）。RB是UE與UTRAN之間L2向上層提供的業務。上面我們提到的RRC連接也可以看作是一種承載信令的RB。

    無線鏈路（RL）。無線鏈路是指一個UE和一個UTRAN接入點之間的邏輯連接，它在物理實現上通常是由一到多個無線承載傳輸組成。在UE與一個UTRAN接入點（通常指社區）之間最多存在一條無線鏈路。

    1、 CS起呼流程

    電路交換業務起呼流程主要有以下幾個基本過程：

    第一步，建立RRC連接。起呼時，首先由UE的RRC接收到非接入層的請求發送RRC連接建立請求消息給UTRAN，在該消息中包含被叫UE號碼，業務類型等等。UTRAN接收到該消息後，根據網路情況分配無線資源，並在RRC CONNECTION SETUP消息中發送給UE，UE將根據消息配置各協定層參數，同時返回確認消息。

    RRC連接建立有兩種情況：公共通道上的RRC連接建立和專用通道上的RRC連接建立。兩者的區別在於RRC連接使用的傳輸通道不同，因而連接建立的流程有所區別。

    公共通道上的RRC連接建立

    專用通道上的RRC連接建立

    第二步，Iu信令連接的建立。在RRC連接建立後，UE將向CN發送業務請求。此時UE的RRC發送INITIAL DIRECT TRANSFER消息，在該消息中包含非接入層的資訊（CM SERVICE RE QUEST）。RNC接收到該消息後，RNC的RANAP發送INITIAL UE MESSAGE，將UE的非接入層消息透明轉發給CN，在該消息發送的同時建立Iu信令連接。在Iu信令連接建立後，UE和CN之間的非接入層消息傳輸使用DOWNLINK DIRECT TRANSFER和UPLINK DIRECT TRANSFER消息進行。具體流程如下圖所示：

    第三步，認證。Iu信令連接建立後，CN需要對UE進行認證。認證是非接入層功能，在 UTRAN中透明傳輸。具體操作見第二步的流程中3－6消息內容。

    第四步，RAB的建立。UE業務請求被網路接收後，CN將根據業務情況分配無線接入承載（RAB）。同時在空中介面將建立相應的無線承載（RB）。

    需要注意的是，4－8條消息若在RRC連接建立中建立了無線鏈路，則需要進行上述無線鏈路的重配置過程，若在RRC連接中沒有建立無線鏈路，即建立了公共通道上的RRC連接時，則在此應進行無線鏈路建立的過程。

    第五步，等待應答。此時UE將等待被呼叫方應答，進入通話狀態。

    下面是對整個電路交換業務UE起呼的一個整體流程圖。

    2、 CS被呼流程

    CS被呼流程基本與起呼流程相似，只是在RRC連接建立前，UE首先接收到尋呼通道上的 PAGING TYPE 1消息，然後進行RRC連接的建立。以後各部分同起呼流程。

    3、 PS起呼流程

    封包交換業務起呼流程有以下幾個基本過程：

    第一步，建立RRC連接。

    第二步，Iu信令連接的建立。

    第三步，UE的認證和安全模式控制。

    第四步，ATTACH。建立UE和服務GPRS業務節點（SGSN）之間的邏輯連接。

    第五步，業務請求及分組資料協定（PDP）啟動。UE非接入層發送業務請求，並啟動PDP。

    第六步，RAB的建立。UE業務請求被網路接收後，CN將分配無線接入承載（RAB）。在空中介面將建立相應的無  線承載（RB）。

    第七步，等待應答。UE等待CN響應。當UE接收到PDP RESPONSE消息，此時可以發送接收IP數據包。

    需要說明的是，WCDMA系統的分組業務是“即時線上”的，就是說使用者和網路始終連接

。通常在使用者終端開啟時，便進行ATTACH操作，與SGSN建立邏輯連接。在需要進行分組業務資料傳輸時，直接啟動PDP就可以了。因此，在實際操作時流程如下圖所示：

    在UE上電時通常會執行1－5步，ATTACH到網路上，並一直保持附著狀態。在需要進行資料傳輸時，執行6－10步呼叫過程。

    4、 PS被呼流程

    與電路交換一樣，PS被呼流程也與起呼流程相似，只是在接收到PAGING消息後進行。

四、總結

    從上述可以看出，一個呼叫流程進行涉及到UE、UTRAN、CN各個網路元素，參與消息交互和傳遞的協定模組很多。對呼叫流程進行分析有助於瞭解網路實際情況、及時發現網路故障，便於我們對網路進行維護和測試。

  原文出處:  http://blog.sina.com.cn/s/blog_46f8eb87010003bj.html

[Telecom]UTRA FDD Frequency Bands (UMTS band, WCDMA Band)

Band number	Name	Uplink (MHz)	Downlink (MHz)	Remarks
I	UMTS2100	1920 - 1980	2110 - 2170	IMT-2000 / UMTS Core band
II		1850 - 1910	1930 - 1990	GSM1900 band
III	UMTS1800	1710 - 1785	1805 - 1880	GSM1800 band
IV	UMTS1700	1710 - 1755	2110 - 2155	Pairing with the core band
V	UMTS850	824 - 849	869 - 894	For the USA
VI	UMTS800	830 - 840	875 - 885	For Japan
VII	UMTS2600	2500 - 2570	2620 - 2690	IMT-2000 extension band
VIII	UMTS900	880 - 915	925 - 960	GSM900 band
IX	UMTS1700	1749.9 - 1784.9	1844.9 - 1879.9	Japanese version of UMTS1700
X	Extended UMTS1700	1710 - 1770	2110 - 2170