國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
第五章、 CCN 分散式資料庫架構設計
5.1、CCN 資料庫建置需求
表 5.1 為 CCN 網路建置需求，本研究主要是著重在提升資料庫的可靠度，進而提 升全系統的可靠度。
表 5.1、CCN 網路建置需求
在 CCN 網路中所建置的資料庫建置的需求與一般公司所使用的資料庫建置需求是 不盡相同的，為突顯 CCN 資料庫與一般資料庫的差異，表 5.2 是我們針對 CCN 群組資 料庫及交易資料庫做一需求比較：
表 5.2、CCN 資料庫及交易資料庫需求比較表
CCN 資料庫
交易資料庫建置可行性 佈建速度要快
建置成本要低
佈建速度慢
建置成本高 持續性需求 系統可靠度較低
系統回復能力快
系統可靠度高
系統回復能力快
錯誤容忍度 高 低
資料安全性 低 高
資料庫複雜度 低 高
項目 資料庫
54
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
由表 5.2 比較得知，CCN 資料庫與交易資料庫的特性，因使用的環境不同，而有些 許的差異，CCN 資料庫注重的是建置時效及低成本，交易資料庫注重的是低錯誤率、
一致性及安全性，在資料庫複雜度方面，交易資料庫架構及資料表設計較為複雜，反之 CCN 資料庫因需快速佈建，故複雜度並無交易資料庫複雜。
5.2、CCN 資料庫設計
CCN 網路元件中，已包含 User Profile DB、Service Definition DB、Admission Policy DB 及 Network Data DB，分別儲存一般用戶資料、Policy 及網路狀態，而為達成 CCN 網路的群組通訊模式，在 CCN 網路內建置群組資料庫(Agent Group DB)及群組成員位置 資料庫(Mobility Management DB)，Agent Group DB 內主要是管控群組資料及群組成員 的相關資料，如：群組註冊簡碼、群組代碼等資訊，此外，為讓群組成員在撥號時能夠 順利找到對方目前所在的位置，規劃 Mobility Management DB 記錄每個 user 目前所在的 位置。如圖 5.1 方框所示。
Mobility Management DB
Agent Group DB User Profile DB
Service Definition DB
Admission Policy DB
Network Data DB
圖 5.1、CCN 網路之 DB
圖 5.2 表 示 Agent Group DB 及 Mobility Management DB 之 實 體 關 係 模 型 (Entity-Relationship Model)，在 Agent Group DB 及 Mobility Management DB 中主要有三 個實體(Entity)：群組資料、群組成員資料及群組成員所在位置，與群組相關的屬性為：
55
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
群組編號、群組名稱、群組狀態等，與群組成員相關的屬性為：群組成員編號、群組成 員的狀態、IMSI、IMEI，與群組成員位置相關的屬性為：群組成員編號、群組所在的 BS 號碼，其中，群組與群組成員為一對多的關係，即一個通訊群組裡會有多個群組成 員，一個群組成員只隸屬於一個通訊群組；群組成員與其所在位置紀錄為一對一的關係，
即一個群組成員只會在一座基地台範圍內，一筆位置紀錄只屬於一個群組成員。當有群 組通訊需求時，發話端成員撥出受話端群組號碼後，經系統呼叫此群組內所有成員，並 由一名群組成員應答後，即進入一對一通話。另因 CCN 網路頻寬資源有限，且群組間 通話的緊急程度也不相同，因此另規劃群組間的通話優先權，通訊較為緊急者，則優先 權愈高。當群組成員建立通話時，系統將根據雙方所屬群組以決定通話優先權，優先權 高者，則優先分配通話頻道及通話 QoS。
Agent Group belong to User reside Location
BS_No
UserID UserStatus
IMEI
IMSI PhoneNumber
GroupID GroupName
Communication Priority
圖 5.2、實體關係模型 5.2.1、 資料表設計
根據實體關係模型，規劃四個資料表如圖 5.3 所示，相關資料表說明如下：
Agent Group：儲存 CCN 群組的基本資料，包含：群組編號(Group_No)、群組 名稱(Group_name)及群組優先權(Priority)。
User：儲存已註冊之 CCN 使用者的基本資料，包含：user 編號(User_ID)
、user 手機號碼(PhoneNumber)、user 手機的 IMSI、IMEI 及 user 目前的狀態 (User_Status)。
56
‧
Group_Member：儲存群組及群組成員之間的對應關係。
HLR：儲存 user 目前所在的基地台編號。 其他 node，稱之為 partition。因此，我們在設計 CCN 群組資料庫時，需考慮實際運作，
及根據資料表之特性，來決定是否需將資料做 partition，以下將針對 Group_Member 及 HLR 資料表是否需做 parition 做一分析說明：
Group_Member 資料表
在進入群組通話時，發話端成員撥出受話端群組號碼，系統必須查詢在 CCN 網路中所對應群組之成員，此時，系統將會查詢整個群組資料表(full table search)。另考慮 Group_Member 僅儲存群組成員資料，資料量並無 HLR 資料量 大，故不需做 partition。
HLR 資料表
系統找到所有受話端成員資料後，即於 HLR 查詢時僅需找到部份受話成員 (partial table search)後即啟動呼叫(call setup)，另 HLR 資料量較大，故需做 partition，以節省空間。
我們彙整 Group_Member 資料表及 HLR 資料表之特性說明如表 5.3。
57
‧
Group_Member HLR VLR
Content
儲存群組資料及其與群組在本研究中，我們根據上述 Group_Member 及 HLR 二個資料表之特性，提出對應 的分散式架構，以提高 CCN 網路的可靠度。
為了更進一步說明 CCN 分散式資料庫建置方式，我們假設 CCN 網路採用樹狀拓樸 如圖 5.4 所示，每個 node 代表一個基地台，並定義 node A 為 Survival BS，node B~I 為 Isolated BS，根據資料結構中樹狀結構的定義，node A 為 root node，node B、C、E、F 為 internal node，node D、G、H、I 為 leaf node。
項目 資料表
58
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
圖 5.4、CCN 拓樸範例
根據表 5.3 分析 Group_Member 及 HLR 資料表的特性，本研究分別提出了數種 建 置架構：(1)用於 Group_Member 資料表的階層備援式架構(Hierarchical Redundancy Architecture)、(2)用於 HLR 資料表的階層備援式架構、(3)用於 HLR 資料表的鄰近階層 備援式架構(Hierarchical Neighboring Redundancy Architecture)。採用階層備援式架構的 好處為：因 CCN 網路拓樸為樹狀架構，系統較易判斷資料之儲存位置，且在查詢時不 需使用繁瑣的位置計算，只需往上或往下搜尋即可，故，本研究採用階層式架構儲存資 料，俾利系統運作。
5.3.1、 Group_Member 資料表儲存架構
用於 Group_Member 資料表的階層備援式架構(Hierarchical Redundancy Architecture)，
為在 CCN 網路中根據所設計的樹狀拓樸，選擇數個階層，將 Group_Member 資料表複 製到這些階層的 node，這些 node 我們稱之為 storage node，而 storage node 所在的階層，
稱為 storage level，例如：node A、D、E、F(以方框標示)為 storage node。如圖 5.5 所示。
Survival BS
59
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
圖 5.5、Group_Member-階層備援式架構範例
在階層備援式架構之基礎下，我們可視使用者對建購成本及可靠度之需求來決定儲 存密度(間隔階數多者，即儲存密度較低，反之，其儲存密度較高。隔一階之架構其 storage node，分佈於階層 1、3、5….，餘者以此類推)。考量 CCN 網路拓樸之階層數不宜過高，
本研究以間隔階數為一、二、三之儲存架構為限，如圖 5.6、5.7、5.8 所示：
圖 5.6、Group_Member 階層備援式架構-隔一階儲存
儲存 Group_Member 資料表
60
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
圖 5.7、Group_Member 階層備援式架構-隔二階儲存
圖 5.8、Group_Member 階層備援式架構-隔三階儲存 5.3.2、 HLR 資料表儲存架構
根據表 5.3 所列 HLR 資料表的特性，設計對應的儲存架構。在進入通話程序前，發 話端需從 HLR 找到受話端的位置，但發話端不知道受話端在那裡，因此，為了解決這 個問題，提出二種建置架構：階層備援式架構(Hierarchical Redundancy Architecture)及鄰
61
‧
近階層備援式架構(Neighboring Hierarchical Redundancy Architecture)。
假設大部份使用者之位置有 locality 存在，亦即，多數使用者在特定位置駐留時間 較長。假設系統將使用者之註冊所在 node 設為初始 home location，之後隨著使用者之 位 置 變 動 而 更 改 為 最 常 駐 留 node ， 我 們 依 據 locality 之 高 低 ， 將 話 務 區 分 三 種 communication 類型：Intra-cell communication(兩個通話中的使用者同在一個 cell)、
Adjacent-cell communication( 兩 個 通 話 中 的 使 用 者 在 鄰 近 的 cell) 及 Remote communication(兩個通話中的使用者相距二個或多個 cell)，我們假設每個 cell 內的 home user 比 visitor 多，而兩個使用者間之話務頻率依兩者相距之遠近而有不同，故 Intra-cell 與 Adjacent-cell communication 之通話頻率比 Remote communication 高，兩者之比值稱 為 Locality Ratio，如以下公式表示。
此外，我們定義 Intra-cell、Adjacent-cell Communication 與 Remote-cell Communication 之相對頻率為 Locality Adjusted Frequency，如下所示。
Locality Adjusted frequency of Intra-Cell and Adjacent-Cell Communication=
圖 5.9、home user 與 visitor 在同一 cell 數量比較 有關這二種備援架構說明如下：
階層備援式架構(Hierarchical Redundancy Architecture)：
規 劃 每 個 node 儲 存 自 己 及 其 下 所 有 node 的 HLR 資 料 表
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
partition，例如：node A(Survial BS)儲存 node A 及 B~I 所有的資料，node B(Isolated BS)儲存 node B 及 node D、E、H、I 的資料，此外，我們在此定義 HLRi為 node A 成員的 Partition，HLRS,T,R….= ⋃i=S,T,R… HLRi，如圖 5.10 所示。
圖 5.10、HLR-階層備援式架構範例
鄰近階層備援式架構(Neighboring Hierarchical Redundancy Architecture)：
此架構為儲存自己及其下一階層 child node 的 HLR 資料表 partition，root node 儲存完整的 HLR。例如：node A 儲存 node A~M 的資料 node E 儲存 node E、H、
I 的資料。與階層備援式架構相同，另定義 HLRi 為 node A 成員的 prtition，
HLRS,T,R….= ⋃i=S,T,R… HLRi，如圖 5.11 所示。
儲存 HLRB,D,E,G,H,I,L
⋃i=A to M HLRi
儲存 HLRF,J,K,M
63
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
圖 5.11、HLR-鄰近階層備援式架構範例
5.4、查詢及更新資料演算法
當 user 啟動撥號、通話流程或移動位置時，皆會查詢、更新 Group_Member 及 HLR
資料表，在此，我們定義 Query Path 與 Update Path，Query Path 為每次查詢時由發話端 成員所在 node 發送至某個 storage node 查詢資料之路徑，Update Path 為 update message 所經過的路徑，而其路徑為一個從新位置 node 到所有 storage node 的 multicast tree。有 關 Group_Member 階層備援式架構及 HLR 階層備援式、鄰近階層備援式架構的查詢與 更新資料演算法，我們用示意圖及 pseudo code 來說明。5.4.1、 Group_Member 資料表查詢及更新資料演算法
查詢之示意圖如圖 5.12 所示，假設發話端在 node B，Group_Member 資料表儲存於 node A、D、E、F、L 及 M 時，查詢時所經過之路徑，即 Query Path。
儲存 HLRF,J,K 儲存 HLRB,D,E
⋃i=A to M HLRi
64
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
圖 5.12、Group_Member 查詢資料示意圖
圖 5.13 主要是在 Group_Member 階層備援式架構查詢的 pseudo code，當 user 撥出 群組號碼後(輸入群組號碼)，找出最近的 node 與其 Query Path，立即與其資料庫連線，
找出符合的群組成員。
Group_Member-Hierarchical Redundancy Architecture--Query Pseudo Code：
Input CalleeGroupNo
nodeIP=null /* nearest node IP */
CalleeData=null do
{
nodeIP=Find_Nearest_Node() Connect nodeIP
CalleeData=Find_Callee_Data(CalleeGroupNo) }
圖 5.13、Group_Member-階層備援式架構查詢資料 pseudo code 更新資料時，利用 Update Path 將所有的 replication 更新，如圖 5.14 所示。
Caller
65
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
圖 5.14、Group_Member 更新資料示意圖
當 user 的基本資料有異動時，先查詢所有儲存 Group_Member 的 node，並透過 Update Path 將所有的 replication 更新後，再一一更新 Group_Member 資料，如圖 5.15 所示。
Group_Member-Hierarchical Redundancy Architecture--Update Pseudo Code：
Input GroupMemberData nodeIP={} /* node IP List*/
count=0 /*node IP Count*/
do {
nodeIP=FindNodeList() count=nodeIP.Size
while(i<=count) {
Connect nodeIP
Update_GroupMember_Data(GroupMemberGroupNo, GroupMemberData) }
}
圖 5.15、Group_Member-階層備援式架構更新資料 pseudo code 5.4.2、 HLR 資料表查詢及更新資料演算法
查詢之示意圖如圖 5.16、5.17 所示，假設發話端在 node G，受話端在 node F，無論 是採階層備援式或鄰近階層備援式架構，Query Path 皆為 G→D→B→A。
Group Member
66
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
假設發話端在 node G，受話端在 node I，若採階層備援式架構，Query Path 為 G→
D→B，若採鄰近階層備援式架構，查詢時所經過之 link 為 G→D→B→A。
圖 5.16、HLR-階層備援式架構查詢資料示意圖
圖 5.17、HLR-鄰近階層備援式架構查詢資料示意圖
更新之示意圖如圖 5.18 及 5.19 所示，假設群組成員之 home location 為 node G，異 動至 node F 時所經過之 link，即 Update Path。
儲存 HLRB,D,E,G,H,I,L
儲存 HLRB,D,E
⋃i=A to M HLRi
⋃i=A to M HLRi
Caller
Callee
Callee Caller
Callee
67
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
圖 5.18、HLR-階層備援式架構更新資料示意圖
圖 5.19、HLR-鄰近階層備援式架構更新資料示意圖
圖 5.20 主要在說明 HLR-階層備援式架構查詢的 pseudo code，當輸入受話端成員的
圖 5.20 主要在說明 HLR-階層備援式架構查詢的 pseudo code，當輸入受話端成員的