行政院國家科學委員會補助專題研究計畫
成果報告
※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ 視 訊 會 議 自 動 化 管 理 暨 服 務 系 統 之 建 置 ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ 計畫類別:□個別型計畫 □整合型計畫 計畫編號:NSC90-2219-E-110-001 執行期間:90 年 8 月 1 日至 91 年 7 月 31 日 計畫主持人: 中山大學計算機與網路中心 陳年興 教授 共同主持人: 中山大學計算機與網路中心 楊竹星 主任 台灣大學計算機與網路中心 林一鵬 主任 交通大學計算機與網路中心 謝續平 主任 中正大學計算機與網路中心 李新林 主任 成功大學計算機與網路中心 賴溪松 主任 計畫參與人員: 中山大學計算機與網路中心 陳舜耕 先生 中山大學計畫研究助理 包景濂 先生 執行單位: 國立中山大學資訊管理學系 國立台灣大學計算機及資訊網路中心 國立交通大學計算機與網路中心 國立中山大學資訊工程學系 國立成功大學電機工程學系 國立中正大學資訊工程學系 中 華 民 國 91 年 7 月 31 日中文摘要
我國為因應時代潮流及加速提昇國內網路技術研究,於八十八年六月十五 日完成了國家寬頻實驗網路(National Broadband Experimental Network,簡稱 NBEN)的建置,做為各種多媒體寬頻應用及各種先進通訊協定之測試平台, 以掌握未來網際網路的關鍵技術及發展,孕育高頻寬、高品質的網路環境,並 支援既有及新的應用,以滿足多樣化之服務品質需求及實現寬頻多媒體應用的 理想。 於八十九年度的研究計劃中,我們相繼將 H.323MCU 多點視訊會議控制器設 置於台灣大學、交通大學、成功大學、中山大學等四個 GigaPOP 節點,並解決 許多視訊會議上之網路架構與連線設定問題,其計劃中所得到許多的研究經驗 和成果,也均能順利應用在轉播國內、國外的研討會與遠距視訊會議上。但由 於 H.323MCU 在串聯使用上有許多複雜的設定,致使每次要使用該設備時就需 委託各 GigaPOP 節點手動調整其網路設定與視訊會議環境,會議完成後亦需要 再將設定與環境復原,且每一台 H.323MCU 在不同的頻寬下可以提供的連接節 點亦不相同,例如在每個節點使用 384Kbps 的頻寬下最多只能提供 9 個連線資 源。如果再加上複雜的 MCU 設定操作與有限的連線資源所形成的限制,往往扼 殺視訊會議應用的普及以及金錢上的浪費。因此,為讓視訊會議的建立能更方 便、連線資源能彼此共享且減少整體成本之支出,我們必須運用前一計劃所得 到的研究經驗與成果來建立一套新的管理機制,以方便管理四個 GigaPOP H.323MCU 節點之連線資源,以便協助每一個 GigaPOP 及下游學校能更方便的建 立視訊會議連線,其具體之目標為: 1. 增進視訊會議的連線品質。 2. 集中管理連線資源。 3. 連線資源有效率的運用。 4. 簡易的視訊會議議程建立、管理與自動化連線控制。 5. 增加視訊會議相關資訊的透明性與流通性。
關鍵詞:NBEN H.323、NBEN MCU、NBEN Video Conference、NBEN 遠距教學、NBEN 即時群播、NBEN 視訊會議、NBEN 視訊會議 管理、NBEN 視訊會議連線控制。
目 錄
第一章 緒論...4 1.1 計劃背景與動機...4 1.2 計劃目標...5 1.3 研究貢獻...7 第二章 研究方法與設計...8 2.1 研究方法...8 2.2 研究對象... 11 第三章 研究過程...13 3.1 分析階段...13 3.2 需求分析...13 3.3 資料蒐集...14 3.4 資料分析...14 3.5 系統功能分析...16 3.6 設計階段...17 3.6.1 自動化牽引設計...17 3.6.2 預先規劃排程設計...19 3.6.3 策略規劃...19 3.6.4 會議排程規劃...22 3.6.5 演算法假設條件...23 3.6.6 演算法之推導...26 3.6.7 網路模式...28 3.7 系統功能設計...30 3.7.1 系統架構階級圖...31 3.7.2 系統管理相關功能設計...32 3.7.3 發展階段...36 3.7.4 系統運作流程...36 3.7.5 系統發展計劃...39 第四章 程式 GUI 與流程說明 ...40 4.1.1 GUI 介紹...40 4.1.2 系統測試與評估...75 4.1.3 目前成果...75 4.1.4 測試與回饋...77 第五章 結論...79第一章 緒論
1.1 計劃背景與動機
我國為因應時代潮流及加速提昇國內網路技術研究,於八十八年六月十五日 完成了國家寬頻實驗網路(National Broadband Experimental Network,簡稱
NBEN)的建置,做為各種多媒體寬頻應用及各種先進通訊協定之測試平台,以 掌握未來網際網路的關鍵技術及發展,孕育高頻寬、高品質的網路環境,並支援 既有及新的應用,以滿足多樣化之服務品質需求及實現寬頻多媒體應用的理想。 於八十九年度的研究計劃中,我們相繼將 H.323MCU 多點視訊會議控制器 設置於台灣大學、交通大學、成功大學、中山大學等四個 GigaPOP 節點,並解 決許多視訊會議上之網路架構與連線設定問題,其計劃中所得到許多的研究經驗 和成果,也均能順利應用在轉播國內、國外的研討會與遠距視訊會議上。 但由於 H.323MCU 在串聯使用上有許多複雜的設定,致使每次要使用該設 備時就需委託各 GigaPOP 節點手動調整其網路設定與視訊會議環境,會議完成 後亦需要再將設定與環境復原,且每一台 H.323MCU 在不同的頻寬下可以提供 的連接節點亦不相同,例如在每個節點使用 384Kbps 的頻寬下最多只能提供 9 個 連線資源。如果再加上複雜的 MCU 設定操作與有限的連線資源所形成的限制,往 往扼殺視訊會議應用的普及以及金錢上的浪費。因此,為讓視訊會議的建立能更 方便、連線資源能彼此共享且減少整體成本之支出,我們必須運用前一計劃所得 到的研究經驗與成果來建立一套新的管理機制,以方便管理四個 GigaPOP H.323MCU 節點之連線資源,以便協助每一個 GigaPOP 及下游學校能更方便的 建立視訊會議連線。
1.2 計劃目標
本次計劃目標乃承續八十九年度研究計劃之研究成果,依循計劃運作期間所 發現之問題加以解決,在視訊會議自動化管理系統系統完成後將提供下列功能與 特色: 系統能提供各單位自行登錄會議相關資訊。 系統能自動依不同的參與單位產生所需的操作文件,讓操作人員輕易的進 行視訊連線。 系統能在各單位預約時間前一日,主動 E-mail 提醒該場會議參與者開會 時間及相關設定。 系統能產生更詳細的操作資料給該場視訊會議的主持單位,使之能輕易的 控制多台 MCU 進行互連。 系統提供簡易的連線控制,能在視訊會議開始時,將所有與會的參與者自 動帶入會議中,減輕 MCU 單位的操作負擔。 系統提供自動規劃最短通訊路徑的機制,能達到最低的網路負荷頻寬與最 佳的會議品質效果。 系統提供查核預約的時段是否有衝突、MCU 資源是否足夠等功能,並能提 出警示或建議會議時間。 系統具有輔助最佳化排程的機制,能手動的進行配置連線設定。 透過資源規劃、及排程演算將 MCU 資源做自動化分配與自動化文件派送功 能 提供視訊會議與遠距教學設備管理人員資訊交流管道 提供會議過程錄影,並產生 VOD 檔參與人員可於會議後觀看。 因此,為能提供以上所提列之目標功能,所以我們依下列四點作為計畫的研 究方向:1. 自動化分配與排程機制的建立
由於 MCU(多點控制器)在不同的連線速率下,可以提供給不同數量的 Client 連線,若要充分並有效率的運用各 MCU 連線資源,使得在 MCU 能負荷 的情形下於同一時段裡進行不同場次的視訊會議,則有賴於建立符合使用者需 求的自動化分配與排程機制,達到增進視訊會議的連線品質、並集中管理連線 資源與效率的目的。 2. 簡化的視訊會議議程建立與自動化連線控制機制 一般視訊會議議程的多是由會議發起單位派發會議通知訊息,並於會議前提 醒與會者,在會議的過程中有可能會運用到 H.323MCU 串聯方式進行,而在 H.323MCU 串聯使用上有許多複雜的設定,若能讓會議發起單位在建立視訊會 議議程的同時,系統能同時接管會議通知、提醒及自動連線之責任,主動通知 並適時提醒該場所有會議參與者開會時間及操作設定文件,並在會議開始前將 每一位參與者自動的牽引至視訊會議中餐與開會,如此可省去會議通知單位與 視訊會議操作人員之負擔,並可整合所有 MCU 資源。 3. 將技術問題及相關知識文件化 由於 H.323 MCU 或 Codec 常會有不明原因的問題而導致連線無法成功,或在 會議過程中臨時出現問題,或者在視訊會議設備、環境與設定上的疏忽而導致 視訊會議影音品質惡劣。因此,將各類問題處理的經驗文件化,除有助於減低 或消除類似的情形發生,更能使後續加入的 GigaPOP 或研究單位能快速的進 行知識移轉之功能。 4. 管理系統提供設備擴充功能
現階由於只有集中管理四個 GigaPOP MCU,未來如果再增加 MCU 與 Client 節點勢必會改變連線的方式,因此該如何在不增加各單位設備操作人員的負擔 下,讓新增的節點與資源能自動的導入系統,這是在開發階段就必需考量的問 題。
1.3 研究貢獻
本研究旨在運用系統分析與設計之步驟,設計一套「視訊會議自動化管理暨服 務」系統。系統於開發建置完成後,具體的貢獻分述如下: 本系統能讓每個連線單位不需經由複雜的連線設定,即能輕易的建立視訊 會議連線及 MCU 串聯,並且兼顧掌控所有可使用的 MCU 資源,供同一 時段多場會議同時進行之用。 本系統能在會議開始之前,將該場會議之參與單位自動的牽引至會議中, 並且完成 H.323 MCU 串聯的動作,並透過簡易的操作介面使系統操作人 員能快速的對未連線成功的參與單位進行連線控制。 當預約視訊會議議程完成後,系統會在預約時間快來臨時,主動 E-mail 提醒該場所有會議參與者開會時間及操作設定文件,省去系統管理與視訊 會議操作人員之負擔。 將各類問題處理的經驗文件化,除有助於減低或消除類似的情形發生,更 能使後續加入的 GigaPOP 或研究單位能快速的進行知識移轉之功能。第二章 研究方法與設計
2.1 研究方法
本研究針對 MCU 資源分配與排程的問題,應可運用資源管理的觀念來解釋 許多複雜的網路連線架構。我們觀察目前 NBEN 上各單位進行視訊會議的運作 情形,當開會人數確定時,系統操作員往往依據經驗判斷來分配 MCU 資源並加 以串聯,此經驗分配方式雖可應付目前單一會議型態,但隨著日後視訊會議慢慢 普及,單一時段多場會議同時進行,如何節省骨幹頻寬及會議連線品質,及各 MCU 節點數量的限制,勢必對系統操作人員造成極大的考驗。 MCU 資源該如做到最佳化分配與排程,就如同資源路徑管理的目的是一樣 的,以最小的成本(頻寬、各 MCU 可容納的 Site 數、傳輸路徑),提供最佳視訊 會議品質。 本研究主要目的為設計及研發一個以Web-based為主的視訊會議自動化管理 暨服務系統。依研究目的之需要,分別採用文獻分析、資料蒐集、系統開發等方 法做為研究探索的依據。分述如下: 1. 文獻分析 首先彙集資源管理等相關文獻,進行歸納及分析,除能了解資源管理中 先進規劃排程之概念,並能運用先進規劃排程之技術,以做為發展本研究「需 求分析」中資源排程之最佳化演算模式的基礎理論。 2. 資料蒐集 我們運用會議過程觀察與會議過程發生的問題及電話訪談的方式進行資 料蒐集,並於系統分析階段中進行,藉以瞭解下列三點: (1)視訊會議通知書之組成結構。 (2)資源分配表組成結構。3. 系統開發
本研究以系統開發法(system development)進行「視訊會議自動化管理 暨服務系統」的設計與建構,並以結構化系統設計(instructional systems design) 方法分析、設計、發展、測試與評估本系統。系統研發與評估架構如圖2-1。 1. 分析 需求分析 資料蒐集 資料分析 系統開發資源分 析 系統功能分析 發展技術分析 2. 設計 自動化 Call IN 設 計 預先規劃排程設計 系統功能設計 系統功能階級圖 系統管理相關功能 設計 3. 發展 系統運作流程 系統發展計劃 介面介紹與程 式流程說明 4. 測試 實施測試對象 測試方式 5. 評估 測試紀錄評估 圖 2-1 系統研發與評估架構圖
本研究之系統研發與評估架構說明如下: 1. 系統分析 (1)需求分析 從視訊會議的建立,到視訊會議舉行結束的過程中,找出可能的需 求,以界定系統應具備什麼特點與功能,此步驟以實地觀察與電話訪談 的方式進行。 (2)資料蒐集 蒐集民國91年8月1日至民國91年11月31日止,NBEN開會通知文件 與連線設定方式,以供在資料分析中所需之資料背景。 (3)資料分析 將蒐集的資料文件依據視訊會議通知書之組成結構、資源分配表組 成結構、NBEN網路中MCU連線網路圖形架構以及連線資源限制等三個 部分做拆解與探討。 (4)先進規劃排程分析 依據文獻探討部份討論的先進規劃排程策略架構,分析管理系統在 資源分配最佳化時應如何進行。 (5)系統開發資源分析 分析系統開發與實施時所有可用的資源及限制。如軟硬體設備、人 力、時間等。 (6)系統功能分析 彙總資料蒐集、資料分析、系統開發資源分析等三節所分析出的結 果,找出可行的系統功能模組。 (7)發展技術分析 對本研究欲開發的系統,所需要的相關發展技術、平台及發展工具 進行分析瞭解。
此階段包括了自動化牽引設計、預先規劃排程設計、系統功能設計、系 統功能階級圖、系統管理相關功能設計等部份,各部份依據需求階段的訴求 重點與原則,說明設計的步驟與內容。 3. 系統發展 根據系統設計規格建置視訊會議自動化管理暨服務系統。此階段以甘特 圖(Gantt Chart)規劃出每一開發階段的時間與工作內容。工作項目包括建立 系統環境、編寫網頁內容、發展各功能區、撰寫程式碼、建置資料庫、編寫 故障排除文件與操作手冊。 4. 系統測試 描述系統實施測試對象與測試進行的方式。 5. 評估 著重於導入操作管理系統的教育、流程紀錄與使用回饋。
2.2 研究對象
本研究需與被實驗對象直接接觸的階段主要為:需求分析、系統測試與評 估,下列依各階段的研究對象予以說明: 1. 需求分析的對象 本研究之需求分析是以NBEN上四個MCU負責單位(台灣大學、 交通大學、成功大學、中山大學)的系統操作人員為主要對象。研究 者對各系統操作人員進行電話訪談,藉以瞭解系統操作人員對於發展 管理系統的需求與其MCU下游單位視訊連線的架構。 2. 系統測試及評估的對象 在系統初步建構完成後,實地利用系統所產生的分配方式進行測 試,並在修改錯誤的程式碼後,再進行操作教育導入過程以獲取評估 回饋。系統測試與評估對象,係為四校MCU系統操作人員、NBEN維第三章 研究過程
3.1 分析階段
本節描述需求分析、資料蒐集、資料分析、先進規劃排程分析、系統開發 資源分析、系統功能分析與發展技術分析等內容探討。3.2 需求分析
本研究需求分析是以兩階段進行: 1. 以實地觀察的方式,紀錄視訊會議從開始建立到舉行結束的過程,以界定系 統應具備何種特點與功能。 2. 對NBEN上四個MCU負責單位(台灣大學、交通大學、成功大學、中山大學) 的系統操作人員進行訪談,藉以瞭解系統操作人員對於發展管理系統的需求 與其MCU下游單位視訊連線的架構。 研究者以實地觀察的方式,紀錄視訊會議從開始建立到舉行結束的流程如圖 3-1: 國家高速電腦中心確 認開會日期並以 E-mail 發出開會通知 信中告知各單位其 gatekeeper 設定方式 與負責協助 MCU 串 聯單位 各單位依指定的 gatekeeper 位址做 撥號連線;各 MCU 系統操作人 員協助其下游單 位排除連線問題 會議正式舉行並順利 結束 圖 3-1 預約視訊會議流程由於每次視訊會議的舉行,牽涉到許多連線設定的分配問題,此分配問題大都均 由有經驗的系統操作員解決,致使即便某些 GigaPOP 單位欲發起視訊會議申請, 都必須委由國家高速電腦中心統籌並且做好分配,再發出會議通知,因此在此癥 結上,管理系統必須要以能取代國家電腦中心所扮演的角色為出發點,故系統須 具備以下的特點與功能: 1. 系統需提供各單位可自行登錄會議相關資訊。系統需能自動的產生不同參與單 位所需的操作文件,並使之能輕易的進行視訊連線。系統需能在各單位預約時 間快來臨時,主動 E-mail 提醒該場所有會議參與者開會時間及設定。 根據對 NBEN 上四個 MCU 負責單位(台灣大學、交通大學、成功大學、中 山大學)的系統操作人員進行訪談,對於管理系統除上述之需求功能外,尚須提 供二項功能: 1. 除產生參與單位的操作文件外,系統還需產生更詳細的操作資料給該場視訊會 議的主持單位,使之能輕易的控制多台 MCU 進行互連。系統需提供簡易的連 線控制,能在視訊會議欲開始時,將所有與會的參與者自動帶入會議中,減 輕 MCU 單位的操作負擔。
3.3 資料蒐集
我們彙整民國 91 年 8 月 1 日至民國 91 年 11 月 31 日之間,每次 NBEN 開 會通知文件與連線設定方式,並將文件放置於附錄一以供資料分析部份使用。3.4 資料分析
此部份依據視訊會議通知書之組成結構、資源分配表組成結構、NBEN 網路 中 MCU 連線網路圖形架構以及連線資源限制等三個部分做探討。 1.視訊會議通知書之組成結構 依據每次 NBEN 開會通知文件所示,視訊會議通知書的主要資訊為,會議 參與單位、會議參與總人數、會議開始日期、會議開始時間、會議結束時間、會 議主題、會議討論內容等。2. 資源分配表組成結構 依據每次 NBEN 開會設定文件所示,資源分配表的主要資訊為,會議參與 單位、Gatekeeper 位址、Call_Number 等。 3. NBEN 網路中 MCU 連線網路圖形架構 依據每次 NBEN 開會時的連線設定方式,MCU 串聯以及與各下游連線單位 的連接方式如圖 4-2: 圖 4-2 MCU 與各下游單位連線示意圖 由於為了讓視訊會議有更好的品質,一般在設定 MCU 均是以 384kbps、30CIF, 根據 RADvision 文件與實際操作上的證實,在此設定上限制只允許 9 個即時連線 的支援。 台大 交大 成功 中山 台大 東華 中央 交大 清大 國高 中興 成功 中正 中山 TL
3.5 系統功能分析
本系統以MCU資源分配為設計主軸,並提供NBEN每個成員一個自動化且簡 易的環境,透過Web的方式進行操作。因此本研究根據需求分析、資料分析、先 進規劃排程等相關分析需求,彙整出管理系統所需達到的目標: 1. 系統需提供各單位可自行登錄會議相關資訊。系統需能自動的產生不同參與單 位所需的操作文件,並使之能輕易的進行視訊連線。系統需能在各單位預約時 間快來臨時,主動 E-mail 提醒該場所有會議參與者開會時間及設定。 4. 除產生參與單位的操作文件外,系統還需產生更詳細的操作資料給該場視訊會 議的主持單位,使之能輕易的控制多台 MCU 進行互連。系統需提供簡易的連 線控制,能在視訊會議欲開始時,將所有與會的參與者自動帶入會議中,減輕 MCU 單位的操作負擔。 6. 系統必須規劃最短通訊路徑的機制,以利達到最低的網路負荷頻寬與最佳的會 議品質效果。 7. 系統需具有查核預約的時段是否有衝突、MCU 資源是否足夠等功能,並適時 的提出警示或建議會議時間方案。 8. 系統需建立輔助最佳化排程的機制,當自動化排程無法進行時,能手動的進行 配置連線設定。3.6 設計階段
本研究的設計項目包括了「自動化牽引設計」、「預先規劃排程設計」、「系 統功能設計」、「系統功能階級圖」、「系統管理相關功能設計」等部分,各部 分依據需求階段的訴求重點與原則,分述說明於後續小節。研究者依據分析階段 的結果,規劃出本系統的功能階層圖,並說明各功能設計目的,完成本研究設計 階段工作。3.6.1 自動化牽引設計
依據需求分析章節中,與 MCU 系統操作人員電話訪談結果得知,「需提供 簡易的連線控制,能在視訊會議欲開始時,將所有與會的參與者自動帶入會議 中,減輕 MCU 單位的操作負擔」。為達此功能,則必須將每一個 Codec 都編列Prefix 碼,此 Prefix 碼就如同電話號碼一般,user 間可藉由撥打對方的 prefix 與 經由 gatekeeper 的牽引與對方進行連線。為能統一規劃 Prefix 碼,並且除了讓 Prefix 碼成為一個有意義的號嗎(如同一個電話號碼就代表一個家庭),還要依 據先進規劃排程分析中策略規劃層最短通訊路徑的目標進行規劃。 如圖 4-3 所示,目前 MCU 放置的位置為台灣大學、交通大學、成功大學、 中山大學,依據民國 91 年 8 月 1 日至民國 91 年 11 月 31 日止,每次 NBEN 開 會通知文件與連線設定方式,台大、中央、東華、中華電信研究所為台大 MCU 的下游連線單位,交大、清大、中興、國高為交大 MCU 的下游單位,我們大約 可以定義利用縣市與區碼來規劃 Prefix 碼。 依每一縣市 Codec 設備,將其電話的區域代碼編列計數數字,另如台北縣市 有台灣大學與台北科技大學兩具 Codec 設備,電話區碼為 02,故其 Prefix 碼為 201 與 202。以此類推,新竹縣市有國家高速電腦中心、交通大學與清華大學, 電話區碼為 035,故其 Prefix 碼為 3501、3502、3503。
圖 4-3 MCU 配置圖 N B E N 多 點 視 訊 會 議 M C U 配 置 圖 台 大 S i g n a l V C I : 3 5 I L M I V C I : 4 6 訓 練 所 中 央 研 究 所 國 高 交 大 清 大 中 興 中 正 成 大 中 山 1 5 M 1 5 M 1 5 M 1 5 M 1 5 M 1 5 M 1 5 M 1 5 M 1 5 M 1 0 M 1 0 M v p : 4 v p : 3 v p : 6 v p : 3 v p : 4 v p : 3 v p : 4 v p : 3 v p : 4 v p : 5 v p : 3 v p : 4 v p : 6 v p : 5 v p : 4 v p : 5 v p : 4 v p : 3 v p : 4 v p : 3 v p : 4 v p : 3 6 2 2 M b p s H .3 2 3 M C U H .3 2 3 M C U H .3 2 3 M C U H .3 2 3 M C U 圖 2 - 1
3.6.2 預先規劃排程設計
NBEN 網路上,對於視訊會議的品質要求甚為嚴苛,然撇除網路通訊壅塞與 障礙因素不談,品質高低的決定因素則在於各連線單位的「連線配置」是否能有 效率的降低網路的流量。但由於 MCU 所提供的連線資源有限,不當的「連線配 置」方式除了無法提高品質,還會賠上珍貴的連線資源,例如為了供應北高各一 單位進行連線,台大與中山的 MCU 則必須各釋出 2 個 site 來供應,一個兩人連 線的視訊會議會稀釋總共 4 個 site 資源,就資源的考量立場實屬浪費。 就資源最佳化的角度而言,必須以最短的時間、最高的彈性與最低的成本來 ? 到目標,視訊會議管理系統的最終目的也是如此,以最高的視訊通訊品質及節 省最低的連線資源與網路頻寬,將視訊會議品質與 MCU 的使用率做最佳化的運 用。3.6.3 策略規劃
根據前一年的研究結果得知,在考慮距離、頻寬與品質的著眼點下,MCU 的佈置與連線方式如圖 1-1 所示。最佳化的佈置與連線方式為各單位先連線至最 近的 MCU,系統操作員再將各處 MCU 串聯。對同在一 MCU 的所有單位而言, 由於距離幾乎近似,因此就如同在 LAN 的環境中運作視訊會議;對網路流量而 言,也只需一道 384K 頻寬即可達到高視訊品質。策略規劃中,我們將焦點放置在 MCU 與各連線單位的距離與同一時段中 MCU 該如何同時提供二場會議進行。若在資源限制允許下,各連線單位因最短
通訊路徑,可達到最低的網路負荷頻寬與最佳的會議品質;於資源有效運用的條 件下,系統應如何規劃同一時段中同時進行二場以上視訊會議的運作機制。 針對最短通訊路徑問題,在參考 MCU 配置圖與每次的開會連線設定後,研 究者發現每一個下游 Codec 單位均是連接最近的 MCU 接點,因此研究者重新定 義每個 Gatekeeper 歸屬管轄範圍如圖 4-4,以達到策略規劃層面所需之設計。基 隆市、台北縣、台北市、桃園縣、宜蘭縣、花蓮縣歸納為台灣大學 Gatekeeper 所屬範圍;新竹縣、新竹市、台中縣、台中市、彰化縣歸納為交通大學 Gatekeeper 所屬範圍;雲林縣、南投縣、嘉義縣、嘉義市、台南縣、台南市歸納為成功大學 Gatekeeper 所屬範圍;高雄縣、高雄市、屏東縣、台東縣歸納為中山大學 Gatekeeper 所屬範圍。 圖 4-4 Gatekeeper 歸屬管轄範圍
另外,由實驗得知,MCU 於 384kbps 的設定下只能提供 9 個連線資源,若 連線資源未超過最大負荷時,則於同一時段中剩下的連線資源可提供另一個視訊 會議使用。過去為避免各 GigaPoP 連線操作人員熟記過多的會議代碼而導致混 淆,因此均是使用 MCU 的 9384 會議代碼進行會議,但研究者於實驗過程中得 知,9384 會議代碼是設定 MCU 工作於最大負荷時的宣告代碼,當 9384 會議代 碼被使用時,MCU 會依 9384 代碼中所設定的參與人數預先保留所需要的連線資 源,換言之 9384 中設定的是 9 個連線資源,一旦 9384 代碼被使用,即便該場會 議只有 3 個人參加,剩下的 6 個連線資源於同一時段內是無法提供其他會議使 用,因此必須規劃「有意義」的會議代碼以利系統於開發時之使用。 為同一時段中 MCU 可提供二場(或以上)會議同時進行,研究者以連線負 載並配上傳輸效率組成 9384、8384、7384、6384、5384、4384、3384、2384 等 八組代碼(其中 384 無法設定於 MCU 中,因視訊會議最少需 2 個連線資源才可 成立),為避免同一時段可能不同的會議內容卻擁有相同的會議代碼,且也能符 合 MCU 之 prifix 規定,因此必須以最大負載數 9 除以各會議代碼之連線負載數, 前方再加 98 代碼,2384 需再增加 9823842、9823843、9823844 等共 4 組 2 人連 線負載會議代碼以供同一時段的不同會議內容使用,以此類推 9833842、9833843 等 3 組 3 人連線負載會議代碼;9843842 等 2 組 4 人連線負載會議代碼,以方便 同一時段 9 個最大負載供不同會議進行所需。全部的會議代碼如表 4-3 所示。 表 4-3 主碼與附碼規劃 主會 議代 碼 2384 3384 4384 5384 6384 7384 8384 9384 同一 時段 附碼 9823842 9823843 982384 9833842 9833843 9843842
3.6.4 會議排程規劃
於前一節先進規劃排程所得到的分析需求可知,此層面的重點在於衡量與派 送分配結果兩部分。由於主規劃乃自動化的分配設計,在可預期的情形下,並非 能完成所有會議複雜的連線架構,因此必須建立起讓系統管理員手動配置的功 能,以達到衡量部分的目標。派送分配的目標則是讓正確的參與單位,受到正確 的連線資料。 在資料表的設計上,本研究依循資料分析中所得到的視訊會議通知書之組成 結構,以及資源分配表組成結構,作為衡量與派送的基本資料格式,其流程如圖 4-6 所示。 圖 4-6 視訊會議通知書資料格式 當系統收到視訊會議通知書後,管理系統會將通知書中的總參與人數、開始 日期、開始時間、結束時間等欄位資料,放入最佳化排程程序與資源表做資源分 配,當分配成功後,則會依每個會議參與單位的最佳位置產生個別的 Gatekeeper 與連線撥號的 Call_Number 值。若無法分配成功,此視訊會議通知書會自動轉給 視訊會議 通知書 會議代碼 會議參與單位 會議參與總人數 會議開始日期 會議開始時間 會議結束時間 會議主題 會議內容 最佳化排程 與資源分配 資源表 資源分配表 會議代碼 Gatekeeper 位址 Call_Number 會議參與單位系統管理員,系統管理員則會調出當日當時段的資源表內容與以手動調整。
3.6.5 演算法假設條件
由於去年的研究條件係為考慮距離、頻寬與品質因素,在連線規劃上對於 MCU 的連線資源因素並未考量。故如何能在加入 MCU 的連線資源因素後,又 能顧及頻寬與品質,若利用過去比較簡單的規劃排程,將無法因應日益增多的視 訊會議使用者所需。因此今年度對於規劃排程的做法即為,同時考量會議人數、 連線資源限制、距離與連線品質等因素下,找出最佳化的規劃排程演算方式以達 到供需間的平衡。 過去連線規劃的方式是以簡易的經驗法則及透過人工的方式進行連線設 定,這樣的方式有著許多缺點,一者沒有效率,二者在面對同時段或同一天舉行 二個以上的視訊會議時,缺乏經驗的系統操作員往往只能找出局部的最佳解 (Local Optimization)組合,而無法簡單的歸納出整體最佳解(Global Optimization)組合,也因為如此視訊會議的舉行往往都只能依靠有經驗的系統 操作者來進行連線規劃與操作,使得視訊會議的服務在 NBEN 網路上仍無法成 為經常性服務。有見於此,本研究將針對以上所述重點,提出一個能兼顧同時段 多場會議的會議人數、連線資源限制、距離與連線品質等因素的規劃排程演算數 學模式,其設計步驟有以下三點: 1.演算法的研究假設條件 在進行演算法推演時,本研究需先定義演算過程中對於實際使用時之封包傳 遞延遲與網路頻寬之實際數據,做預先的假設與限制,以避免考量實際網路環境 中有可能會影響最佳化排程規劃的變動因素。本研究的假設與限制如下: (1)研算結果已涵蓋所有應考量之所有因素結構 本研究之演算結果為最終且最佳化之會議規劃排列方式,過程中已涵蓋所有會 影響排列結果及資源分配之結構概念。 (2)網路傳遞延遲之實際數據,採用有意義的替代數據進行演算由於無法偵測實際進行視訊會議時各區域的封包傳遞延遲之實際數據,故採用 有意義的替代數據進行演算。替代數據係以 MCU 放置的區域,由北到南因距 離的遠近定義 0、1、2、3 等數據,由南到北因距離的遠近定義 0、1、2、3 等 數據來代表傳遞延遲之實際數據。其意義為台大 MCU 上的所有連線單位連至 台大 MCU 因距離所產生之傳遞延遲為 0,原 gatekeeper 設置在台大的單位連 至交大 MCU 因距離所產生之傳遞延遲為 1,依此類推至中山之傳遞延遲為 3; 由中山至台大,因距離所產生之傳遞延遲可類推為 0、1、2、3 等數據。 (3)視訊會議品質會因距離所產生的傳遞延遲與頻寬負載而有相對的變化 若原先預設在台大 MCU 上之連線單位不經過台大 MCU 而直接連至中山 MCU,其對於網路頻寬的負載必定相對的增加,再加上封包的傳遞延遲,也可 直覺性定義對於視訊會議品質必定有所影響。 2. 資源分配之結構概念說明
由實驗過程中得知,當 MCU 進行串聯時,各 MCU 必須支出一個 site 資源, 串聯之主控 MCU 則必須支出串聯之總數的 site 資源,其示意如圖 4-7 與表 4-5 所示。 圖 4-7 連線規劃示意圖 MCU1 user1 MCU2
NBEN
主控端 H.323 MCU MCU3 user2 user3 user1 user2 user1 user2 user1表 4-5 各 MCU 所需支出之 site 資源表
MCU 名稱 user 佔用 site 數 MCU 串聯支出 site 數 總支出 site 數
MCU1 3 1 4 MCU2 2 1 3 MCU3 2 1 3 主控端 MCU 1 3 4 由此可知,每一筆預約資料在進行最佳化演算時,必定要重新運算 1 次,才可得 知暫時性的排列方式是否 MCU 有足夠的連線資源供使用。 3.預約單之優先排列條件 由於 MCU 資源有限,若當日有多筆預約單等待排列,預約的時段有重複時, 則系統必須先制定優先排列的條件,其條件由高至低與說明理由如下: (1)會議參與人數 因會議參與人數較多,所需佔用的連線資源也相對增多,為維持視 訊會議品質,故予以有較高優先權力先進行排程分配。 (2)預約時段 由於可能會有預約時段重疊之困擾,意指前一視訊會議才進行至一半,後 一新的會議則才要開始,為避免 MCU 的資源不足,且維繫每一會議的完整進 行,故配予次高的優先權。 本研究並未規劃有緊急性會議的最高或次高優先權,原因不外是擔心預約單 位浮報會議之重要程度,或是此為緊急必須先行排程之會議,因此系統於設計時 則將此類的緊急會議條件,交由負責管理系統維護之系統管理員處理,並提供立 即性的排程規劃程式,立即分派資源,以避免等待與其他預約單進行競爭。
3.6.6 演算法之推導
根據去年的研究結果,在考慮距離、頻寬與品質的著眼點下,MCU 最佳化 的佈置與連線方式為各單位先連線至最近的 MCU,系統操作員再將各處 MCU 串聯。再配合本研究先前設定的假設條件「網路傳遞延遲之實際數據,採用有意 義的替代數據(0,1,2,3)替代」,所得出之矩陣表如表 4-6 所示 表 4-6 矩陣表 使用單位 台大 中央 TL 交大 國高 清華 成功 中正 中山 供應 MCU1 0 0 0 1 1 1 2 2 3 Na MCU2 1 1 1 0 0 0 1 1 2 Nb MCU3 2 2 2 1 1 1 0 0 1 Nc MCU4 3 3 3 2 2 2 1 1 0 Nd 預約 人數 1 1 1 1 1 1 1 1 1設將 MCU1~4 轉換為 ma~md;由台大開始由左至右將使用單位轉換為 u1~u9; 各 MCU 某一時段之最大供應數轉換為 N 由上表可知: 供應限制 0mau1+0mau2+0mau3+1mau4+1mau5+1mau6+2mau7+2mau8+3mau9 ≦ Na 1mbu1+1mbu2+1mbu3+0mbu4+0mbu5+0mbu6+1mbu7+1mbu8+2mbu9 ≦ Nb 2mcu1+2mcu2+2mcu3+1mcu4+1mcu5+1mcu6+0mcu7+0mcu8+1mcu9 ≦ Nc 3mdu1+3mdu2+3mdu3+2mdu4+2mdu5+2mdu6+1mdu7+1mdu8+0mdu9 ≦ Nd
規劃視訊會議通知書的主要資訊為,總參與人數、開始日期、開始時間以及 結束時間等欄位資料,由於每一個 MCU 都有獨自的供給資源限制,因此在規劃 與分配資源時,會議通知書的總參與人數需求量是可以任意拆解的,比如總參與 數是 12 名,其中的 5 名可以在台灣大學的 MCU,其中的 3 名可以在交通大學的 MCU,其中的 4 名可以在中山大學的 MCU,藉此滿足每一筆會議的資源需求。 由於 MCU 串聯最少會佔用 1 個 site 資源,故需求限制為 0mau1+1mbu1+2mcu1+3mdu1 ≧ 1 0mau2+1mbu2+2mcu2+3mdu2 ≧ 1 0mau3+1mbu3+2mcu3+3mdu3 ≧ 1 1mau4+0mbu4+1mcu4+2mdu4 ≧ 1 1mau5+0mbu5+1mcu5+2mdu5 ≧ 1 1mau6+0mbu6+1mcu6+2mdu6 ≧ 1 2mau7+1mbu7+0mcu7+1mdu7 ≧ 1 2mau8+1mbu8+0mcu8+1mdu8 ≧ 1 3mau9+2mbu9+1mcu9+0mdu9 ≧ 1 於供應限制式中所提之 N 變數之計算方式,為考量各 MCU 於某一時段(例 如:早上 10:00 至 12:00)所能支出之最大連線數,例如某日之對應表中 10:00~12:00 紀錄為 96749,意謂著其所能支出之最大連線數只有 4 個資源,若此 一預約單在進行暫時性最佳化演算後其結果需以 MCU 串聯方式進行,則會議主 持人所處之 MCU 最少需提供 1(會議主持人佔用)+串聯數量(視暫時性最佳化 演算結果而定)才可完成最後的最佳化排程演算,因此於供應限制中需加入 Nn = Min(mnt1,…..,mntn) t1~tn:為預約時段中某一時刻所剩下之連線資源;於需求 限制中需加入(Sa,Sb,Sc,Sd)+ 1 ≧ Nn Sa,Sb,Sc,Sd:為各 MCU 於暫時性最 佳化演算後需要 MCU 串聯之數量。
3.6.7 網路模式
由於會議通知書的總參與人數需求量是可以任意拆解的,換句話說每個需求 單位在 MCU 的落點是會移動的,為維持策略規劃層面中最短距離的運算,我們 必須定義當預設的 MCU 資源不足時,該轉換到哪一個 MCU 來消化連線資源需 求。 根據數學模式中所定義的,MCU 最佳化的佈置與連線方式為各單位先連線 至最近的 MCU,由於無法測得網路傳遞延遲之實際數據,故各 MCU 與 MCU 間 的距離採用有意義的替代數據進行演算。替代數據係以 MCU 放置的區域,由北 到南因距離的遠近定義 0、1、2、3 等數據,由南到北因距離的遠近定義 0、1、2、3 等數據來代表傳遞延遲之實際數據。因此當預設的 MCU 資源不足時,此筆 資源需求應該由此 MCU 所處位置加 1 或減 1 的 MCU 來吸收,故移動的方向共 有四種型態,如圖 4-8。
圖 4-8 MCU 移動型態
MCU0 MCU1 MCU2 MCU3
型態一
MCU0 MCU1 MCU2 MCU3
型態二
MCU0 MCU1 MCU2 MCU3
型態三
MCU0 MCU1 MCU2 MCU3
當預設的 MCU 資源不足時,此筆資源需求就會依循的方向檢測 MCU 的 資源是否能滿足需求。
3.7 系統功能設計
根據前面「系統功能分析」、「自動化牽引設計」、「預先規劃排程設計」 部分所提的設計方式,本研究初步歸納出的系統模組如下: 1. 預約會議模組: 系統能提供各單位自行登錄會議相關資訊並進行預約,當預約時間快來臨時, 系統會主動 E-mail 提醒該場所有會議參與者開會時間及設定。 2. 自動化牽引模組 此模組能在視訊會議欲開始時,將所有與會的參與者自動帶入會議中,減輕 MCU 單位及 Codec 單位的操作負擔。 3. 自動化分配與文件分派模組 系統能自動的將視訊會議通知書中所需的條件與資源,依照先進規劃排程的演 算流程進行運算,並產生不同參與單位所需的操作文件予以寄送,同時系統也 會寄送更詳細的操作資料給該場視訊會議的主持單位。 4.系統手動分配資源模組 由於系統具有查核預約的時段是否有衝突、MCU 資源是否足夠等功能,因此 當自動化分配無法成功,系統仍需要提供手動配置的機制,或者適時的提出警示 或建議會議時間方案給該場視訊會議的主要聯絡單位。3.7.1 系統架構階級圖
本研究根據前段系統模組的結果設計系統功能階層圖(hierarchy chart)(見 圖4-2),以由上而下的方式組成樹狀架構。最高一層代表本系統,以下分七個 子系統,每一子系統下面連接數量不等的功能項目。方塊內的文字即代表子系統 功能的項目名稱。以下即是本系統之功能階層圖: 圖4-9 功能階級圖 最新 消息 站務 公告 近期 會議 公告 視訊會議自動化管理暨服務系統 關於 VC VC 計劃 簡介 會議 設備 需求 Meeting Point 軟體 設定 Radvisis on MCU 設定 軟硬體 故障排 除 會員資 料區 登錄資 料修改 查詢 會員 資料 會議預 約區 會議 預約 會議參 與者發 信 即時監 控區 會議監 控功能 問題 討論區 問題發 表與討 論 系統管 理室 查詢資 源表 分配問 題管理 C_id 會議 管理 設定/取 消使用 者帳號 新增 刪除 MCU 預 約 會 議 模 組 自 動 化 分 配 與 文 件 分 派 模 組 Mega Conference 英文網站 自 動 化 牽 引 模 組 系 統 手 動 分 配 資 源 模本系統共分成八個功能區,包括「最新消息」、「關於VC」、「成果與紀 錄區」、「會員資料區」、「會議預約區」、「即時監控區」、「問題討論區」、 「系統管理室」等。各功能區之間,皆可根據使用者的權限,自由進入該權限所 能使用的範圍。
3.7.2 系統管理相關功能設計
本研究依據「帳號權限等級」、與「資料庫設計」二個部分,分別說明本系 統在系統管理上的設計: 1. 帳號權限等級 本系統為了區分不同類型的使用者,有不同的權限,因此設計帳號權限 等級。本系統設計下列四種權限等級(如表4-7): 表4-7 各使用等級與權限功能說明 系統預設值 等級名稱 使用權限 0 訪客 僅能瀏覽本系統之公告資料、討論區文章、視訊會議相關文 件等非輸入性功能。 1 一般使用者 此身分可以使用系統中大多數的功能,包括預約會議、檢視 及修改個人資料權力、觀看查詢其他使用者資料列表等功能。 2 軟體測試用 此身分僅限於系統程式開發工程師於撰寫程式後應用於測試 程式結果時的測試帳號。 4 系統管理員 此身分僅限於 4 間 MCU 單位與國家高速電腦中心使用,具 備有高階的管理功能,包括建立刪除 MCU、變更使用者權限 與密碼、設定取消會議、刪除使用者帳號、手動配置資源能 力。 5 進階系統管 理員 除繼承系統管理員所具備之能力,更負起當預約單資源分配 失敗時,能即時的收到錯誤通知,並協助進行資源配置。2.資料庫設計 會議預約 會議參與者發 信 最新消息區 站務公告 最新會議公告 關於 VC VC 計劃簡介 會議設備需求 Meeting Point 設定 Radvision MCU 設定 軟硬體故障排除 Mega Conference 英文網站 登錄資料修改 查詢會員資料 會員資料區 會議預約區 即時監控區 會議監控功能 問題討論室 新增討論主題 參與討論主題 系統管理室 查詢資源表 分配問題管理 C_id 會議管理 NBEN 管理系統 資料庫 圖 4-9 系統環境架構圖
本系統需要使用資料庫儲存使用者的基本資料、MCU 單位資料、會議預約 資料、文件分配資料、問題討論資料,讓程式能取用並加以運用,系統環境架構 如圖 4-9 所示。本系統所使用的資料庫軟體為 Mysql。本系統使用一個資料庫, 並在資料庫中定義十三個資料表,各資料表存放內容說明如表 4-8:
表 4-8 資料表名稱與存放內容說明表 資料表名稱 資料表存放內容 使用者資料表 (user) 使用單位的基本資料,包括帳號、密碼、 聯絡電話、住址、電子郵件、緊急聯絡 電話、緊急聯絡人、Gatekeeper 位址、 視訊設備 Prifix 碼。 MCU 單位資料表 (mcu) MCU 單位名稱、MCU 內部設定位址、 MCU IP address、Gatekeeper IP address、 MCU 單位地址、MCU 單位電話、MCU 單位聯絡人姓名與電話、MCU 負責之區 域代碼。 會議預約資料表 (addcheck) 會議預約代碼、會議參與總人數、會議 參與單位、會議日期、開始時間、結束 時間、會議主題、會議內容。 文件分配資料表 (mcu_div) 參與單位名稱、會議預約代碼、由外碼 與 gatekeeper 代碼與會議代碼所組成的 Call_Number。 問題討論資料表 (disscuss、inn) 成員在討論區中互動的留言。 會議分配結果資料表 (sch_data) 紀錄某年某月某時某日幾點幾分的時 段,會議申請的情形 研討會訊息資料表 (conference) 紀錄最新消息中研討會訊息之資料 視訊管理系統教學資料表 (edusch) 日期、教學主題、教學內容、影片超連 結 國外視訊會議記錄資料表 (magasch) 日期、會議主題、會議內容、影片超連 結 NBEN 議程紀錄資料表 (nbensch) 日期、會議主題、會議內容、會議文件 超連結、操作文件超連結、評估回饋超 連結、影片超連結 站務公告資料表 (news) 日期、公告內容、顯示與否 研究資源資料表 (resource) 資源名稱、資源連結、顯示與否 研習課程資料表 (study) 日期、課程主題、課程介紹超連結、顯 示與否
3.7.3 發展階段
本研究的發展階段包括了「系統運作流程」、「系統發展計劃」、「介面介 紹與程式流程」三部份,各部份內容分述說明於後續小節。3.7.4 系統運作流程
1.使用者註冊流程 圖 4-10 使用者註冊流程 每位使用者在填入基本資料後,系統會根據使用者所處縣市自動判斷其所屬的 Gatekeeper 位址與視訊會議設備的 Prifix 編號。 2.身分認證流程 圖 4-11 身分認證流程 Gatekeep 與Prefix最 佳化設定 各單位 基本資料 e-mail NBEN 系統管理 資料庫 告知設定值 及設定方式 首頁 驗證身分 check.php 服務主頁 是 否 註冊帳號使用者填入登入帳號與密碼後,若是註冊會員系統會依使用者權限給予操作功能 使用,若非或帳號密碼錯誤則無法進入。 3.會議預約流程 圖 4-12 會議預約流程 一般參與者 輸入預約資料 系統產生暫存性會議代碼 此時系統提供兩 種會議參與者登錄方法E-MAIL 通知預約者如何登記參與會議的方法,並委請 轉寄 E-MAIL 內容給其他一般參與者,同時提高權限為會議主持人,一般參與者 藉由 E-MAIL 內容指示進入登記參與(需使用者帳號與密碼)(必須在會議開始 前三天完成)會議主持人利用自行點選的方式,將欲參與的單位做登記的動作。 一般參與者 單日預約 輸入年、 月、日 、時、分與 E-MAIL 登記參 與會議 會議主持人 會議前三 天完成 E-MAIL 建立暫存性 會議代碼 會議參與 單位加入 點選參與 會議名單
4.自動化 Agent 功能 圖 4-13 自動化 Agent 流程 系統每天凌晨 12 點均會自動的檢查資料庫中的預約單資料,並依預約單的資料 判斷需進行何種功能系統會在會議開始前的第四天通知該場會議主持人確認 預約資料是否需修改若不需修改則會在會議開始前的第三天自動將預約單進 行資源分配若資源分配成功系統會立刻發給各與會單位一封 E-MAIL(內容為 詳細的連線設定資料)Agent 會再一次於會議前一天自動發給該場會議參與者 設定信資料以提醒參與者準時參與會議。 委任會議主持人 一般參與者 判斷 功能 建立正式 會議設定 設定信 NBEN 管理系 統資料 庫 預約 資料 Agent E-MAIL Agent NBEN 管理系 統資料 庫 系統管理員 委任會議主持人
3.7.5 系統發展計劃
本系統根據分析及設計階段內容,並配合實驗對象的實施與評估進度,擬定 系統發展計畫。本研究所發展的系統其流程以甘特圖(Gantt Chart )表示,如 圖4-14: 2001 8 月 2001 9 月 2001 10 月 2001 11 月 2001 12 月 2002 1 月 2002 2 月 2002 3 月 2002 4 月 2002 5 月 2002 6 月 2002 7 月 階 段 工作項目 參與人員 需求分析 研究者 MCU 人員 資料分析 研究者 先進規劃 排程分析 研究者 MCU 人員 系統 功能分析 研究者 分 析 發展技術 分析 研究者 自動化牽 引設計 研究者 預先規劃 排程設計 研究者 設 計 系統功能 設計 研究者 發 展 系統建立 研究者 系統測試 研究者 NBEN 成員 I2 成員 測 試 評 估 系統評估 研究者 NBEN 成員 I2 成員 圖4-14 甘特圖第四章 程式 GUI 與流程說明
4.1.1 GUI 介紹
本系統共分成八個功能區,包括「最新消息」、「關於VC」、「成果與紀 錄區」、「會員資料區」、「會議預約區」、「即時監控區」、「問題討論區」、 「系統管理室」等。除「關於VC」未與資料庫作連結外,其餘七個功能皆與資 料庫連結,且皆可根據使用者的權限自由進入該權限所能使用的範圍。 1、登入程序說明 (1)登入畫面 本系統採用使用者身份認證機制,以確保使用者的合法性,並同時確定 使用者的使用權限,故登入本系統必須輸入帳號及密碼。所有的使用者都必 須經過線上註冊成功後,取得帳號及密碼,才能成為學習社群的成員。當使 用者透過瀏覽器連接至本系統時,即可於首頁中鍵入其帳號及密碼(如圖 4-15),按登入後,便由系統判斷其帳號是否合法及權限等級。登入功能 login.htm 驗證身分 nben/check.php 服務主頁 default.htm 是 否 服務主頁 default.htm 傳遞變數1 傳 遞 變 數 2 當使用者通過身分認證後,系統會依據其權限等級決定可使用或可瀏覽的功能 或內容,因此畫面配置也會依使用者權限而有所不同。 (2)登入之程式流程 圖4-16 登入之流程圖 表4-9 登入流程之程式敘述表 檔案流程 Userlogin.htmnben/check.phpdefault.htm login.htm 傳遞變數 1 username、passwd 傳遞變數 2 session_username、session_unit_name、session_priv 迴圈判斷為是 迴圈判斷為否 default.htm是由topmenu.php、news.htm、foot.htm組成,當使用者之帳號與密 碼經過check.php判斷後,會將使用者帳號(session_username)、單位名稱 (session_unit_name)、使用者權限代碼(session_priv)以session的方式儲存, 以供系統其他的功能使用。
2、使用者註冊程序說明 (1)註冊畫面 使用者依序填入單位、密碼、地址、所處縣市、單位電話、設備操作人員 等詳細資料後,系統會立即依其所填入之資料進行分析(最佳化Gatekeeper與 Prefix分析)(如圖4-17),並在處理完成後立即回覆e-mail告知註冊者,並委請 註冊者依e-mail之內容調整其視訊會議設備之相關設定,完成註冊程序,如圖 4-18。註冊完成後,使用者便可使用系統進行視訊會議管理。 圖4-17 使用者註冊畫面
圖4-18 註冊之e-mail回函 (2)註冊之程式流程 圖4-19 註冊之程式流程 表4-10 註冊流程之程式敘述表 檔案流程 Usernewuser.phpnewuser.htmnewuser.phpdefault.htm 傳遞變數 1 unit_name、username、passwd、passwd2、address、city、tel1、 em、tel2、email Gatekeep與 Prefix最佳化 設定與儲存 newuser.php 傳遞變數1 e-mail NBEN 系統管理 資料庫 告知設定值 及設定方式 註冊申請單 newuser.htm
最佳化Gatekeeper與Prefix分析係以使用者所處之縣市做分析,系統會依據於 MCU資料表中各MCU負責之區域,將使用者資料予以落點找出離使用者最近 的 Gatekeeper 位 址 以 及 計 算 無 重 複 之 Prefix 碼 , 其 分 析 之 程 式 碼 放 置 在 newuser.php中。 3、「最新消息」程序說明 (1)最新消息畫面 提供站務報告、研討會訊息、討論主題、研習課程及研究資源等資訊的呈 現。站務報告提供關於系統與站務方面相關訊息公告;研討會訊息提供欲進行 雙向即時視訊會議之全國大型研討會之訊息公告;討論主題係將各使用者之最 新發表問題列出;研討課程係以公告國家高速電腦中心之教育課程或研討會訊 息為主;研究資源提供關於視訊會議技術、設備等國內、外相關廠商之網站連 結為主。 圖4-20 最新消息之畫面
(2)「最新消息」之程式流程 圖 4-21 最新消息之程式流程 表 4-11 最新消息之程式敘述表 傳遞變數 1 con_title 傳遞變數 2 number、subject 傳遞變數 3 news_date、news_content 傳遞變數 4 res_title、res_link 傳遞變數 5 study_date、study_title、study_link 4、「關於 VC」程序說明 (1)「關於 VC」畫面 「關於 VC」區中提供許多關於視訊會議之軟、硬體設備介紹,其中包含 VC 計畫簡介、會議設備需求、MeetingPoint 軟體設定、Radvision MCU 設定、 軟體體故障排除、TANET 2 英文網站等資料,方便使用者了解視訊會議相關設 備及軟硬體設定。 最新消息 newsright.php conference 資料表 disscuss 資料表 news 資料表 resource 資料表 study 資料表 傳遞變數1 傳遞變數2 傳遞變數3 傳遞變數4 傳遞變數5
圖 4-22 關於 vc 畫面 (2)「關於 VC」之程式流程 茲將「關於 VC」之所有網頁連結與目錄位置列出,如表 4-12。 表 4-12 關於 vc 之程式敘述表 VC 計畫簡介 menu2/aboutright.htm 會議設備需求 menu2/demend.htm MeetingPoint 軟體設定 menu2/software.htm
Radvision MCU 設定 menu2/mcu.htm 軟硬體故障排除 menu2/software.htm TANET 2 英文網站 mc2/index.htm
5、「成果與紀錄區」畫面 提供「NBEN 視訊會議自動化管理暨服務系統」計畫的整體研究成果,其中 包括簡介整個計畫之背景、目標;於 NBEN 議程紀錄中,詳細的紀錄每一次 NBEN 會議的開會文件、過程影片與障礙排除文件;於國外視訊會議記錄中記錄著每一 次與國外視訊會議團體互動的過程錄影;於視訊管理系統教學中存放著操作視訊 會議管理系統的教學影片,供所有會員學習如何使用「NBEN 視訊會議自動化管 理暨服務系統」。另外,此功能區之資料內容均用使用者權限控管,所有使用者 必須經過「登入」的認證程序,方可瀏覽權限內所能閱讀之資料。 圖 4-23 成果與紀錄區畫面
圖 4-24 NBEN 議程紀錄之畫面 (2)「成果與紀錄區」之程式流程 圖 4-25 NBEN 議程紀錄功能之程式流程 當使用者點選「NBEN 議程紀錄」功能時,系統會依據該使用者之使用權限 (leader_priv 值)向 nbensch 資料表取出適當的內容。 NBEN 議程紀錄 menu7/nbensch.php nbensch 資料表 傳遞變數1
圖 4-26 國外視訊會議記錄之程式流程 此「國外視訊會議記錄」功能可供一般使用者瀏覽,無權限之控制。 圖 4-27 視訊管理系統教學之程式流程 此「視訊管理系統教學」功能可供一般使用者瀏覽,無權限之控制。 表 4-13 成果與紀錄區之程式敘述表 檔案目錄 menu7 研究成果功能路徑 repright.htm 傳遞變數1 con_date、con_title、document/con_note_link、 document/con_doc_link、con_err_link、con_vod_link 傳遞變數2 maga_date、maga_title、maga_content、maga_link 傳遞變數3 edu_date、edu_title、edu_content、edu_link 6、「會員資料區」程序說明 (1)會員資料區畫面 「登錄資料修改」允許使用者更改其聯絡的資訊,例如:單位聯絡資料、操 作人員聯絡資料..等,此資料有助於視訊會議議程各單位互相聯絡之用。 「查詢會員資料」主要提供使用者以”關鍵字”的方式查詢線上使用者的資 料,且輸入的代號或暱稱可以是不完整的,只要是與使用者有關的關鍵字,系統 都會幫您尋找出與此關鍵字有關的使用者。 國外視訊會議紀錄 menu7/magasch.php magasch 資料表 傳遞變數2 視訊管理系統教學 menu7/teacsch.php edusch 資料表 傳遞變數3
圖 4-28 使用者資料修改畫面
(2)「會員資料區」之程式流程 圖4-30 登入資料修改之程式流程 表4-14 登入資料修改之程式敘述表 檔案目錄 menu3 登錄資料修改 功能路徑 update.php 傳遞變數1 unit_name、tel1、em、tel2、email 使 用 者 點 選 登 錄 資 料 修 改 功 能 後 , 系 統 會 先 取 出 使 用 者 登 入 時 所 留 下 的 session_username值,之後存取user資料表完成修改動作。 圖4-31 查詢會員資料之程式流程 表4-15 查詢會員資料之程式敘述表 檔案目錄 menu3 檔案流程 Userquery.htmq1.htmq2.phpq3.php
傳遞變數 2 搜尋 user 資料表中 username 與 unit_name 字串與傳入之 key
變數類似之紀錄 傳遞變數 3 傳入*值,列出所有 user 資料表中所有會員資料 傳遞變數 4 Username 登入資料修改 menu3/update.php user 資料表 傳遞變數1 查詢會員資料 query.htm 結果顯示 q2.php 傳遞變數2 傳遞變數3 使用者資料 q3.php 傳遞變數4 user 資料表
使用者在進入 query 後,可利用關鍵字查詢(select * from user where username like
'%$key%' or unit_name like '%$key%' order by username)或全部列出的方式 (select * from user order by username)查詢其他使用者資訊。
7、「會議預約區」程序說明 (1)「會議預約區」畫面 「會議預約區」提供使用者三個對於會議預約管理有關的功能,會議預約、 修改會議資料、會議參與者發信。 會議預約顧名思義係為預約視訊會議議程,使用者只需點選預約日期與鍵入 會議相關資料,接著點選會議參與人員即可完成預約動作。預約會議完成後,系 統會於會議前 4 天寄信給會議主持人,詢問會議相關資料是否確定,會議前 3 天執行連線資源分配功能,會議前 1 天執行派送提醒信件給所有會議參與者。 修改會議提供修改日期、修改會議參與人員與刪除預約會議等功能,方便預 約者能自助式的修改會議資料。 會議參與者發信功能係提供該場會議之所有與會人員聯絡之用,系統會列出 與會名單中有登入者之會議,接著只需鍵入聯絡訊息即可對所有與會人員或特定 與會人員派發信件。
圖 4-36 會議參與者群組發信畫面 (2)「會議預約區」程式流程 圖 4-37 會議預約之程式流程 一般參與者 日期點選 schedule/month.php 傳 遞 變 數 1 E-MAIL schedule/ordermail.php 登記參 與會議 會議主持人 會議前三 天完成 E-MAIL 建立暫存 性會議代碼 schedule/add.php 點選參與 會議名單 schedule/selectlist.php 時段點選 schedule/day2.php 傳遞變數 2 會議參與 單位加入 schedule/orderadd.php 傳遞變數 3 傳 遞 變 數 4 傳遞變數 5 會議主持人 傳遞變數 6 確認參與 會議名單 schedule/a.php 傳 遞 變 數 7 addcheck 資料表
表 4-16 會議預約之程式流程敘述表 檔案目錄 schedule 程式流程 Monthday2add.phporderadd.phpselectlist.phpa.php ordermail.php 傳遞變數 1 year、month、day 傳遞變數 2 year、month、day、time、sector 傳遞變數 3 year、month、day、time、sector、stopt、title、content 傳遞變數 4 c_id、year、month、day、user_id、nowrun 傳遞變數 5 http://vc.nben.net.tw/menu4/addcheck.php?c_id=$c_id 傳遞變數 6 c_id、year、month、day 傳遞變數 7 c_id、selB 當預約會議進入至 schedule/orderadd.php 步驟時,系統會依傳入之時間變數比對 當日的時間,若預約時間為三天內(包含第三天)舉行,預約者必須立即確認會 議參與名單(schedule/selectlist.php);若預約時間為三天之後舉行,預約者可利 用點選會議參與名單方式(schedule/selectlist.php)或 e-mail 通知各單位自行加入 方式(schedule/ordermail.php)以確認會議參與名單。 圖 4-39 修改會議資料之程式流程 修改會議資料 conf_fix.php 修改日期 chage_day.php 傳遞變數1 傳遞變數3 傳遞變數5 addcheck 資料表 修改參與名單 chage_man.php 刪除會議 del_conf.php 傳遞變數2 判斷是否 已分配連線資源 chage_day3.php chage_man3php del_conf.php 傳遞變數4 還原資源並 重新建立 mcu_back.fn speed.php div_fun3.fn addcheck & sch_date & mcu_div 資料表 是 否 傳遞變數7 傳遞變數6 傳遞變數8
表 4-17 修改會議資料之程式敘述表 檔案目錄 menu4 程式流程 conf_fix.phpchage_day.phpchage_day2.phpchage_day3.phpspeed.php chage_man.phpchage_man2.phpchage_man3.phpspeed.php del_conf.phpdel_conf.php 傳遞變數 1 iyear、imonth、user_id、cnumber、date、playt、stopt、doc 傳遞變數 2 c_id、leader、divok 傳遞變數 3 c_id、iyear、imonth、iday、divok、nowrun 傳遞變數 4 c_id、iyear、imonth、iday、out、divok、nowrun 傳遞變數 5 c_id、divok 傳遞變數 6 c_id 傳遞變數 7 c_id、out、number2、date、playt、stopt 傳遞變數 8 c_id、out、number2、date、playt、stopt、doc 當使用者點選修改會議資料時,系統會取出該使用者登入時之 ession_username, 並列出當月份該使用者有預約的預約單資料,同時與目前的時間比對是否已經做 完連線資源分配功能,以決定 divok 值(1:已分配 0:未分配)。接著使用者點 選修改資料、修改參與名單或刪除會議等功能,系統會先將送入之資料與目前的 日期作比對,以決定 nowrun 值(是否修改後的日期已在三天內,1:要分配 0: 不分配)是否要進行連線資源分配。divok 值決定是否執行 function/mcu_back.fn (連線資源還原程式);nowrun 值決定是否執行 function/div_fun3.fn(連線資源 分配程式)。 圖 4-40 會議參與者發信之程式流程 會議參與 者發信 groupmail.php addcheck 資料表 user 資料表 確定收信人員 groupselect.php 發信 a.php 傳遞變數1 傳遞變數2
表 4-18 會議參與者發信之程式敘述表 檔案目錄 menu6 程式流程 groupmail.phpgroupselect.phpa.php 傳遞變數 1 c_id、leader 傳遞變數 2 out 使用者在點選「會議參與者發信」後,系統從 addcheck 資料表中取出尚未舉行 視訊會議且該使用者存在於預約單中的全部資料,接著使用者只需鍵入聯絡資料 與點選收信單位即可發信,此功能會在視訊會議結束後關閉。 7、「即時監控區」程序說明 (1)「即時監控區」畫面 「即時監控區」提供使用者於視訊會議舉行時具有控制所有連線單位的能力,包 括 MCU 串聯、控制某一單位連線加入、聲音靜音、影像送出等即時性功能。此 功能區會在視訊會議開始前的 15 分鐘才可使用。系統會先以登入使用者為會議 主持人帳號搜尋預約單資料庫,接著列出該使用者當日所有預約列表,系統只會 開放會議前 15 分鐘可進入即時監控區,若非 15 分鐘內之條件則只會列出該場會 議的詳細資料。
(2)「即時監控區」程式流程 圖 4-43 即時監控之程式流程 表 4-19 即時監控區之程式敘述表 檔案目錄 menu5 程式流程 mcufirst.phpmcucall.phpnumcontrol.php mcu_view.php 傳遞變數 1 iyear、imonth、iday 、user_id 傳遞變數 2 c_id、leader 傳遞變數 3 c_id 傳遞變數 4 c_id、leader 傳遞變數 5 c_id、divok mcufirst.php 會先以登入使用者為會議主持人帳號搜尋預約單資料庫,接著列出 該使用者當日所有預約列表,若會議開始時間距離系統主機時間為 15 分鐘內即 可進入即時監控區(mcucall.php),若非 15 分鐘內則只會列出該場會議的詳細 資料(mcu_view.php)。當傳遞變數 2 進入 mcucall.php 程式,該程式會由 mcu_div 與 user 資料表中取出資料,接者向 MCU 發出 MCU 串聯
(http://$address_ip[$row[2]]/INVT/$row[3]?Invite=99.$gk_address[$row[4]].$row[5])、該場所 即時控制選單 mcucall.php 傳遞變數1 傳遞變數3 傳遞變數5 addcheck 資料表 會議資料瀏覽 mcu_view.php 傳遞變數2 即時監 控功能 mcufirst.php 會議參與者 連線選單 numcontrol.php 否 傳遞變數4 是 mcu & mcu_div & user 資料表
有參與者連線進入視訊會議指令 (http://$address_ip[$leader_address]/INVT/$leader_callid?Invite=$l_call_number2),隨後則進 入控制畫面。會議主持人可依會議通知單內的內容點選欲控制的 MCU 位置並填 入會議代碼即可,另可利用會議參與者連線選單(numcontrol.php)向 MCU 發 出 MCU 串聯或某一參與單位進入會議之控制指令。 8、「問題討論區」程序說明 (1)「問題討論區」畫面 為了讓視訊會議的相關問題能彼此交流,系統藉由討論區方式,讓視訊會議的相 關議題能彼此的討論與分享。 圖 4-44 問題討論區之畫面
(2)「問題討論區」程式流程 圖 4-45 問題討論區之程式流程 表 4-20 問題討論區之程式敘述表 檔案目錄 discuss 程式流程 新增主題時:disscuss2.phpdisscuss2.php 回覆主題時:disscuss2.phpinner2.phpinner2.php 傳遞變數 1 cr、last、name、num、subject、address 傳遞變數 2 email、name、subject、content、cr、last、num、address 傳遞變數 3 content、email、name、subject、address、cr、last 傳遞變數 4 relation、email、name、subject、content、address、cr 傳遞變數 5 relation 9、「系統管理室」程序說明 (1)「系統管理室」畫面 系統管理室主要用於維護整個系統運作,其功能包括:「查詢資源表」、「C_id 會議管理」、「最新消息管理」、「成果紀錄管理」、「使用者管理」、「MCU 管理」。 新增主題功能 disscuss2.php disscuss 資料表 新增主題功能 inner2.php inn 資料表 傳遞變數1 傳遞變數2 傳遞變數3 傳遞變數4 傳遞變數5
圖 4-48 最新消息管理畫面
圖 4-50 成果紀錄管理畫面
圖 4-52 使用者管理查詢之畫面
圖 4-54 修改 MCU 相關資料之畫面 (2)「系統管理室」程式流程 圖 4-55 查詢資源表程式流程 表 4-21 查詢資料表之程式敘述表 檔案目錄 Sysadmin 程式流程 Sourcetime.phplooksource.php 傳遞變數 1 year、month、day、playt、stopt 查詢資源表 sourcetime.php 結果顯示 looksource.php 傳遞變數1 資源應對表
「查詢資源表」主要功能為查詢某年某月某日某時段之各校 MCU 連線資源剩餘 情況。所有連線資源剩餘情形均盎置在對應之連線資源應對表(order 目錄), 應對表檔名 20020822.csv,其所表達為 2002 年 8 月 22 日之資源內容。 圖 4-56 C__id 會議管理之程式流程 表 4-22 C_id 會議管理之程式敘述表 檔案目錄 sysadmin 程式流程 q2.phpfixday.phpfixday2.phpfixday3.phpspeed.php fixman.phpfixman2.phpfixman3.phpspeed.php delconfer.phpdelconfer.php errmain.phppointok.php../mcu_div.php
傳遞變數 1 搜尋 user 資料表中 username 與 unit_name 字串與傳入之 key 變數類似之紀錄 傳遞變數 2 傳入*值,列出所有 user 資料表中所有會員資料 傳遞變數 3 c_id、divok 傳遞變數 4 c_id、date、startarr、stoparr 傳遞變數 5 c_id、iyear、imonth、iday、divok、nowrun 傳遞變數 6 c_id、iyear、imonth、iday、out、divok、nowrun 傳遞變數 7 c_id、divok 傳遞變數 8 c_id、divok 傳遞變數 9 c_id 傳遞變數 10 c_id、out、number2、date、playt、stopt、doc 傳遞變數 11 c_id、out、number2、date、playt、stopt
傳遞變數 12 username, unit_name, c_id, outlink, address、call_id、c_id
C_id會議管理 cidadmin.php 結果顯示 q2.php 傳遞變數1 傳遞變數2 修改日期 fixday.php 傳遞變數5 傳遞變數6 修改參與名單 fixman.php 刪除會議 delconfer.php 傳遞變數3 判斷是否 已分配連線資源 fixday3.php fixman3php delconfer.php 傳 遞 變 數 4 還原資源並 重新建立 mcu_back.fn speed.php div_fun3.fn addcheck & sch_date & mcu_div 資料表 是 否 傳遞變數11 傳遞變數9 傳遞變數10 手動資源分配 errmain.php 傳遞變數7 確認配置 pointok.php 傳遞變數8 傳遞變數12
為能快速找尋到預約單代碼,系統提供單一預約單代碼搜尋與列出當月份所有預 約單代碼兩種方式,列出的同時系統會先與目前的時間比對是否已經做完連線資 源分配功能,以決定 divok 值(1:已分配 0:未分配)。接著系統管理員點選修 改資料、修改參與名單或刪除會議等功能,若該預約單是屬於資源分配錯誤,則 手動資源分配耕能才會開啟,系統管理員可依照所需要的動作,對預約單資料予 以更動管理。 圖 4-57 最新消息管理之程式流程 最新消息管理 newmanager.php 站務報告管理 manager.php 研討會管理 manager.php 研習課程管理 manager.php 研究資源管理 manager.php 修改 modnews.php modcon.php modstudy.php modref.php 新增 addnews.php addcon.php addstudy.php addref.php 刪除 delnews.php delcon.php delstudy.php delref.php News & conference & study & resource 資料表