策略規劃

根據前一年的研究結果得知，在考慮距離、頻寬與品質的著眼點下，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

配，當分配成功後，則會依每個會議參與單位的最佳位置產生個別的 Gatekeeper 與連線撥號的 Call_Number 值。若無法分配成功，此視訊會議通知書會自動轉給

視訊會議

Gatekeeper 位址 Call_Number 會議參與單位