Chapter 8 多媒體應用無線網路技術 Wireless Network Techniques for Multimedia Applications 1
課程目標 Ø 不論是有線網路或是無線網路，不論是否擁 有最先進的技術，唯有提供豐富而多樣的應 用服務，才能吸引使用者創造龐大的商機。就 如同電子郵件是網際網路的殺手級應用，無 線通訊的領域中除了語音通話服務外，如何 創造出其他殺手級的應用以增加無線數據資 料傳輸的使用率，是各家廠商面對的最大難 題。現今各廠商莫不把注意力集中於多媒體 應用上，因此本章節將介紹目前廠商針對於 無線多媒體應用所成立之聯盟與推出的相關 標準。 2
章節目錄 Ø 簡介 Ø 無線應用協定 Ø 多媒體訊息服務 Ø Java 2微小版本 J 2 ME Ø 開放式服務閘道協議 Ø OSA/Parlay and Parlay X 介紹 Ø OMA組織介紹 Ø 結語 Ø 作業 3
Section 8. 1 簡介 Introduction 4
無線網路的特性 Ø 網際網路蓬勃發展，各式各樣的網路應用 不斷興起。 Ø 如何在無線網路上也能提供相同的服務 Ø 無線網路的特性： • • 無線電頻寬有限 資料傳送速度慢 設備輕薄短小 螢幕小、 鍵盤輸入不易 計算能力不及個人電腦 使用電池 5
通訊協定 Ø 專為無線環境設計各種通訊協定、程式語 言。 • 無線應用協定（ Wireless Application Protocol， WAP） • 多媒體訊息服務（ Multimedia Messaging Services， MMS） • Java 2微小版本 J 2 ME（ Java 2 Platform， Micro Edition） 6
國際組織 Ø 發展通訊協定的國際組織對於無線產業的 未來有不可輕忽的重要性。 • 開放式服務閘道協議（ Open Service Gateway initiatives， OSGi） • OSA/Parlay架構 • 開放行動聯盟（ Open Mobile Alliance， OMA）。 7
OSGi Ø OSGi定義的 作平台，讓使用者依據自己 的需求，透過網路將遠端供應商提供的服 務程式或加值服務下載至終端設備裝置， 並可自動安裝執行。 8
OSA/Parlay Ø OSA/Parlay是一穩定而可彈性運用的系統開 發平台，上層之應用程式開發者只要利用 OSA/Parlay提供的應用程式介面（ Application Programming Interface， API），就可開發新的 行動通訊服務，而不必接觸底層電信核心 網路的協定。 9
OMA Ø OMA在推動無線通訊上所扮演的角色，則 是在追求應用服務的互通性。像是多媒體 訊息服務或是行動對講機（ Push-to-talk over Cellular， Po. C）這些常用的服務，都是 OMA公 佈的行動服務標準，成為各業者遵循的方針。 10
Section 8. 2 無線應用協定 Wireless Application Protocol， WAP 11
WAP Forum Ø 在 1997年，Nokia、 Ericsson、 Motorola和 Phone. com組成了無線應用協定論壇（ Wireless Application Protocol Forum， WAP Forum）。 • 負責制訂在無線網路上的通訊標準 • 審核由 業界組織和標準團體所提出的無線網 路應用通訊協定草案。 • 目前 WAP 已併入 OMA 中。 Ø 無線應用協定（ Wireless Application Protocol， WAP）就是由WAP Forum所制訂的一組通訊 12 協定。
WAP 的特性 Ø 採用 OSI 階層式的架構。 Ø 模組化。 Ø 各種承載網路（ bearer network）都可做為WAP 的底層，載送上層的資訊。 Ø 基本上只定義了服務的架構，並不會涉入 實作的細節。 • 所以像 3 GPP 要為 MMS 另定詳盡的規格書。 13
WAP 的運作方式 Ø 無線應用協定閘道器（ WAP Gate. Way， WGW） 介在有線與無線網路的中間，負責協調雙 方的溝通。 • 一端為 TCP/IP（ Transmission Control Protocol/Internet Protocol）。 • 另一端為 WAP的通訊協定。 Wireless: WAP Gateway Internet: TCP/IP 14
WAP 2. 0 Ø 2001年 8月發表新的 WAP 2. 0 的規格。 Ø 與舊有版本 WAP 1. x 相容。 Ø 整合許多在網際網路上既有的通訊協定（如 TCP、 HTTP），期望讓無線網路上的 WAP協 定與網際網路協定整合，使得有線網路與 無線網路間的溝通更為順暢。 15
Section 8. 2. 1 無線應用協定架構 16
WAP 協定堆疊 Ø WAP的堆疊架構圖如同圖 8 -1。 • • • 承載服務（bearer service） 傳輸服務（transport service） 轉送服務（transfer service） 議程服務（session services） 應用平台（application framework） Ø 橫跨上述所有的層次的層次： • 安全服務（security services） • 服務探索（service discovery） 17
圖 8‑ 1 WAP 的協定堆疊 18
承載服務 Ø WAP 網路可以架在 • 支援 IP的承載服務層： 如 GPRS • 不支援 IP的承載服務層： 如 GSM、 SMS Ø WAP設計的本意就是希望能夠在眾多不同 的承載網路上提供相同的介面。 Ø 即使底層的承載網路因科技的進步而改變， 也不會影響到上層傳輸服務的運作。 19
傳輸服務（1/2） Ø 傳輸服務層將來自上層非結構化的資料 （ unstructured data） 對應到下層的承載網路。 Ø 傳輸服務分成兩大類： 資料段（datagrams） 服 務和連線（connections） 服務 。 Ø 資料段 服務 （非 連結導向 ） • 不事先建立連線，每一筆資料間都是完整獨立 地被傳送。 • 如在支援 IP的承載服務層之上使用的使用者資 料段協定 （ User Datagram Protocol， UDP） • 如： 在無支援 IP的承載服務層之上使用的無線數 據協定（Wireless Datagram Protocol， WDP） 。 20
傳輸服務（2/2） Ø 連線服務 （ 連結導向 ） • 在支援 IP的承載服務層之上 ， 先建立連線才傳 送資料。 • 如 無線輪廓傳輸控制協定（ Wireless Profiled-TCP， WP-TCP） WP-TCP針對無線通訊的環境將 TCP 。 進行最佳化以減少不必要的額外負荷 ， 但仍保 留基本 TCP的功能，故可以與標準的 TCP互動。 21
轉送服務 Ø 負責讓來自上層結構化的資料（ structured data） 在兩個網路實體間轉送。 Ø 轉送傳輸服務層可能提供的服務項目包括： • Hypermedia transfer： 提供超媒體資料的轉送。 ü 當下層是 UDP或 WDP時，這一層可採用 WSP與 WTP。 ü 當下層是 WP-TCP， 這一層可採用 WP-HTTP。 • Streaming： 提供轉送視訊（ video） 與音訊（audio） 這 樣同步撥放的資料。 • Message transfer： 提供像 email與即時訊息（instant message） 這樣非同步的多媒體資料。為此 WAP訂 22 定了 MMS Encapsulation 以傳送多媒體資料。
無線議程協定（ Wireless Session Protocol， WSP） Ø 針對無線網路低頻寬、高傳輸延遲的特 性， 提出的處理溝通雙方通訊的機制。 Ø WSP支援 “採用主從架構（ client-server architecture） 之上層應用程式 ”間的資料交換。 Ø WSP中訂定了 存取網頁的協定標準，提供類 似 HTTP的功能。 23
無線交易協定（ Wireless Transaction Protocol， WTP） Ø 處理來自 使用者代理程式（ User Agent， UA） 與應用伺服器之間的請求和回應（ request/response）。 Ø 功能類似 TCP， 提供上層 WSP可靠的傳輸服 務 。但相較於 TCP， WDP的設計可減少無線 手持裝置所需的運算時間與對記憶體的需 求。 Ø 在 WAP 1. x的版本中，就是結合了 WSP、 WTP 及 WDP， 在無支援 IP的承載網路上傳送網頁 超媒體資料。 24
無線輪廓超文件傳輸協定 Ø Wireless Profiled-Hyper. Text Transfer Protocol， WPHTTP Ø 定義 WAP 的 設備必須支援那一些 HTTP 1. 1 中 提出的方法（method）。 • 如果是 HTTP 用戶端必須支援 GET/POST • 如果是 HTTP 伺服器則必須支援 GET/HEAD/POST/OPTIONS 等方法。 • 利用 WP-HTTP 可以達成上層 pull 與 push 的功能。 • WP-HTTP支援超媒體訊息內文的壓縮 。 25
Push & Pull Ø Pull： 傳統上用戶端向伺服器提出存取網頁 的方式。 Ø 推播（ push） 伺服器主動送出網頁給用戶端。 ： • PAP（ Push Access Protocol） 協定 主動地將要傳送 的內容 （ push content） 和傳遞方式的指令送到 push 代理閘道器 。 • 在無線 的 部份則使用 在 議程服務層的 Push-OTA 提供的服務 ， 讓訊息從 push代理閘道器 送給 WAP 用戶端 。 26
議程服務（1/2） Ø 議 程 服 務 就 像 OSI的 議 程 層 （ session layer） ， 讓不同網路實體建立、 持溝通的狀態， 維 以 便提出要求或傳送資料。 Ø 議程服務可能提供的服務項目包括： • Capacity negotiation： 許 用 戶端 與 網 路 端 交 換 在 允 傳輸上、管理上、描述上的規格與偏好。 • Push-OTA（ Over The Air） 將 要 推 播 （ ： push） 息 從 訊 網 路 端 的 push代 理 閘 道 器 （ push proxy gateway） 發 送到 WAP用戶端，提供網路主動啟動的傳輸服務。 ü 實現於 WSP或是 WP-HTTP之上的協定。 27
議程服務（2/2） Ø 議程服務可能提供的服務項目包括： • Sync： 用於同步複製資料。 • Cookie： 用 於 超 媒 體 傳 送 ， 應 用 程 式 在 代 理 應 讓 伺服器（ proxy server） 用 戶端 上 建 立 使 用 者 的 或 資 料 ，做 為 下 次 連 結 的 參 考 資 訊 。請 參 考 HTTPState規格書。 28
應用平台（1/2） Ø 提 供 一 個 讓 服 務 提 供 者 與 內容 提 供 者 可 以 快速地開發服務的應用環境。 Ø 能提供的服務項目包括： • WAE/WTA user-agent： 規範 支援 WAE或 WTA的手 持行動設備應有的功能 。 ü 無線應用環境 （ Wireless Application Environment， WAE） 在考量手持行動設備上僅能使用微型瀏覽器的情況下， 提出適用的 markup語言。 ü 無線電話應用（ Wireless Telephony Application， WTA） 則 是在無線應用環境中，提供像是撥打電話、電話轉接 等電話控制功能以提供電話服務。 29
應用平台（2/2） Ø 能提供的服務項目包括： • Push： 推播的技術能讓應用程式伺服器，主動將 資料傳送到無線用戶設備上。 • Multimedia messaging： MMS。 指 • Content formats： 這部份列舉在 WAP上適用的資料 格式，例如彩色圖片、影音等資料格式。 30
安全服務（1/2） Ø 包括認證（authentication）、 保障資料不會被篡 改以確保資料傳輸的整體性（ data integrity）， 保護使用者的隱私（ privacy） 與不可否認 （ nonrepudiation） 安全考量 。 等 Ø 在不同的層次可使用不同的方式來提供安全 性： • Secure bearer： 在承載網路上運作的安全機制 。 ü 如 IP 網路上採用 IPSec或使用 IPv 6本身提出的安全服務。 • Secure transport： 在傳輸層上運作的安全機制 。 ü 如 WP-TCP之上使用的 TLS（ Transport Layer Security）。 31 ü 在 WDP之上採用的 無線傳輸層安全性（ Wireless Transport
安全服務（2/2） Ø 在不同的層次可使用不同的方式來提供安 全性 ： • PKI（ Public Key Infrastructure）： 供公開密秘鑰匙 提 （ public-key） 進行加密，以及對憑證（ certificate） 的 管理。 • WIN（ Wireless Identity Module）： 供使用者資料 提 的識別與認證。 • Authentication： 用於認證用戶端與伺服器。 ü 如在議程服務層之可採用 ü 在傳輸服務層之上可採用 在 TCP之上）。 HTTP Client Authentication。 WTLS（ WDP之上）與TLS（ 在 • Cryptographic Libraries： 在應用平台上，提供資料 32
服務探索（Service Discovery） Ø 提供用戶得知系統提供那些服務的機制： • 外部功能性介面（ External Functionality Interface， EFI）： 過 EFI可以在手持設備上加入一些嵌入 透 式的功能模組，藉此使用 WAE外的功能。 • 組態設定（Provisioning）： AP系統提供的一個機 W 制，讓無線手持設備取得必要的組態設定 • 導航探索（Navigation discovery）： 樣的機制讓手 這 持設備發現網路提供的新功能。 • 服務查表（Service lookup）： 供像網域名稱系統 提 （ Domain Name System， DNS） 這樣查詢的功能。 33
Section 8. 2. 2 存取全球資訊網 34
WAP 1. x 存取網站的方式 Ø 圖 8 -2是 WAP 1. 0的全球資訊網存取範例。 Ø WAP閘道器位於 WAP用戶端與 Web伺服器 間進行協定的轉換，將非連結導向（ datagram ）的無線承載網路上的傳輸協定（使用 WSP、 WTLS、 WDP）轉成有線IP網路上連結 導向的傳輸協定（使用 HTTP、 SSL與 TCP）。 • SSL（ Secure Sockets Layer）：透過資料加密與對伺 服器認證的安全機制提供安全性。 • SSL是 TLS的前身。 35
WAP 1. x 與 WAP 2. 0 版本網站存取 方式之差異 Ø 為了適應無線傳輸的環境， WAP 2. 0引用 TCP並加入設定的建議而改成 WP-TCP， 另 外引用 HTTP以改成 WP-HTTP。 • WP-HTTP取代了 WSP和 WTP。 • WP-TCP取代 WDP。 Ø 可以容易地與 HTTP 1. 1/TCP 進行協定的轉 換，而且利用資料壓縮或建議參數設定等 方式，有效地使用無線 IP網路 。 36
圖 8‑ 2 WAP 1. x 使用 WAP 閘道器 存取網頁資料的範例 37
圖 8‑ 3 WAP 2. 0 使用 WAP 代理伺 服器的範例 WP-HTTP（ HTTP*表示）與WP-TCP（ TCP*表示）。 以 以 38
WML與 XHTML Ø 無線標記語言（ Wireless Markup Language， WML） WAP 1. 0 為了在無線環境中存取網 是 頁而設計的標記 語言，定義於 WAE層。 Ø WAP 2. 0 使用 XHTML與 CSS做為新的傳輸語 言。 • 串接式樣表（Cascading Style Sheets， CCS） 用於描 述文件顯示於瀏覽器上的方式，讓呈現（ presentation） 的方式與真正的資料分開。 • 可延伸超文字標記語言（ Extensible Hyper. Text Markup Language， XHTML） 是符合可延伸標記語 言（ e. Xtensible Markup Language， XML） 規範的 39
WAP的優點 Ø WAP為無線傳輸通訊市場提供了一個可以 發展先進通訊應用技術，以及擷取網際網 路的共通環境。 WAP技術的發展，將可以縮 小行動通訊和網際網路間的差距，使得更 多的服務在無線網路得以實現。 40
Section 8. 3 多媒體訊息服務 Multimedia Messaging Services， MMS 41
MMS 的特性 Ø MMS提供無線通訊系統中多媒體訊息傳遞 的解決方案。 Ø 是 WAP協定上層的應用，因此並不會因為 底層傳輸方式變更或是使用不同的 作平 台而無法動作。 Ø MMS採取公開標準。 Ø 可傳送文字、圖形、鈴聲、影像、語音，使得 訊息內容擁有動感以及聲光效果。 Ø MMS也定義了手機與 E-mail的介面，使 MMS 42 也能提供 E-mail的服務。
Section 8. 3. 1 多媒體訊息服務基本架構 43
MMS 基本元件 (1/2) Ø MMS 架構中包含下列的元件 ： • MMS用戶端（ MMS client） 或稱為 MMS用戶代理人 （ MMS User Agent， MMS UA） • 應用程式 （ Application） • MMS伺服器（MMS server） ü 提供多媒體訊息儲存的服務。 • MMS代理伺服器 -中繼器（MMS proxy-relay） ü 負責轉送多媒體訊息，也是與其他 道器。MMS proxy-relay。 ü 可以整合在 MMS伺服器之中。 MMS系統互動的閘 44
MMS 基本元件 (2/2) Ø MMS 架構中包含下列的元件 ： • 電子郵件伺服器（ E-mail server） ü 提供 MMS透過傳統網路上的 E-mail傳送的服務。 Ø 舊有無線訊息系統（ legacy wireless messaging system） • 提供支援現行各類型的無線訊息系統，包含了 傳呼與 SMS系統。 • 當要想傳送多媒體訊息給無 MMS功能的手機時， 就會透過舊有無線訊息系統代送簡訊，告知其 多媒體訊息的網址，就可透過網際網路來觀看。 45
圖 8‑ 4 MMS 的基本架構 46
Section 8. 3. 2 多媒體訊息服務的傳送流程 47
圖 8‑ 5 MMS 用戶端和 MMS Proxy Relay 之間的介面 Ø WAP閘道器與 MMS proxy-relay間，採用HTTP 協定來傳送 MMS的訊息。 Ø WAP閘道器與 MMS用戶端間，則可利用 WAP 1. x訂定的無線議程協定（ WSP） 或是 WAP 2. 0的 WP-HTTP來傳輸 MMS訊息。 48
圖 8‑ 6 MMS 操作流程圖 49
MMS 操作流程 (1/3) Ø 步 驟 1. Originating MMS client使 用 WAP機 制 ， 將 相 關 資 訊 與 多 媒 體 訊 息 一 併 封 裝 於 MSend. req的 內容 中 ，利 用 下 層 WSP傳 送 到 發 送 端 系 統 之 Originating MMS proxy-relay。這 個 讓 用 戶端 把 資 料 傳 給 系 統 端 的 動 作 稱 為 WAP POST。 Ø 步 驟 2. Originating MMS proxy-relay回 應 訊 息 M-send. conf表示已收到。 Ø 步 驟 3. Originating MMS proxy-relay 將 多 媒 體 訊 息 轉 送 到 目 的 地 端 系 統 之 Target MMS 50 proxy-relay。
MMS 操作流程 (2/3) Ø 步驟 4. Target MMS proxy-relay利用 WAP PUSH機制將 M-Notification. req通知 Target MMS client。 Ø步 驟 5. Target MMS client回 應 MNotify. Resp. ind， 示 已 經 可 以 從 Target MMS 表 proxy-relay端收取多媒體訊息。 Ø 步 驟 6. Target MMS client利 用 WAP的 機 制 ， 送出WSP或HTTP GET. req向Target MMS proxy -relay要 求 傳 送 多 媒 體 訊 息 。 個 讓 用 戶端 這 向系統端提出要求， 得資料的動作稱為 取 51 WAP GET。
MMS 操作流程 (3/3) Ø 步驟 7. Target MMS proxy-relay以 M-Retrieve. conf 傳送多媒體訊息給 Target MMS client。 Ø 步驟 8. Target MMS client回應 MAcknowledge. ind， Target MMS proxy-relay確 讓 認 Target MMS client已經收到多媒體訊息。 Ø 步驟 9. Target MMS proxy-relay將狀況報告回 報給 Originating MMS proxy-relay。 Ø 步驟 10. Originating MMS proxy-relay利用 WAP PUSH的機制發送 M-Delivery. ind傳送報告給 52 Originating MMS client。
Section 8. 3. 3 多媒體訊息服務之訊息架構和編碼 53
MMS 訊息 Ø MMS訊息是由多媒體訊息表頭和訊息主體 所組成。 • 若採用 WAP 1. x架構，就會被封裝於無線議程協 定（ WSP） 的封包內，如同圖 8 -7所示。 Ø MMS表頭（ header） 表示多媒體訊息主體（ message body） 的相關資訊。 • 例如訊息主體的型態和 MMS版本。 Ø 訊息主體（message body） 的內容為要傳送的 資料。 • 包含多種型態的多媒體元素（ multimedia elements）， 54 例如有文字、圖片或是影像等。
圖 8‑ 7 MMS 訊息的結構 Ø 呈 現元素（presentation element） • 同步多媒體綜合語言（ Synchronized Multimedia Integration Language， SMIL） Ø MMS使用多用途網路 郵件擴展（ Multipurpose Internet Mail Extension， MIME） 格式，描述各個多媒 體元素的類型。 JPEG AMR H. 263 55
Section 8. 4 Java 2 微小版本 J 2 ME Java 2 Platform， Micro Edition 56
J 2 ME Ø J 2 ME 是針對消費性與嵌入式裝置，例如行 動電話、PDA、 電視機上盒（set-top boxes）、 資訊通訊系統（ telematics systems） 與眾多的 嵌入式系統裝置而設計的 Java家族的成員。 Ø J 2 ME 平台是由一系列標準的 Java應用程式 介面（ Application Programming Interface， API） 所構成。 • 由 Java協會審議過程（ Java Community Process， JCP） 所制定。 57
圖 8‑ 8 Java 2 平台技術 58
Section 8. 4. 1 J 2 ME的架構 59
J 2 ME 的架構 Ø J 2 ME 的架構中定義了基本組態（ configuration）， 設定該裝置應該要具備的最基本功能。 • 如對硬體的需求與所提供的基本類別函式庫（ library） 等。 class Ø J 2 ME 提供所謂的類別輪廓（ profile） 的模組化 的套件 ， 架在基本組態之上，提供更多的服務。 Ø 選用性的類別組合（ optional package） 供選用。 Ø 基本組態、類別輪廓與選用性的類別組合，便 建構了 Java執行環境（runtime environment）。 • 選用不同的套件，便可讓裝置設備有不同的特色或 應用。 60
基本組態 Ø 基本組態由 Java虛擬機器（Java Virtual Machine， JVM） 和一個最小的類別函式庫集 合所構成，提供了 J 2 ME 程式執行的平台。 Ø JVM安裝於作業系統上，類別函式庫則提供 基本的功能。 Ø J 2 ME 提供兩種基本組態： • Connected Limited Device Configuration（ CLDC） • Connected Device Configuration（ CDC） 61
CLDC Ø 為網路傳輸速度慢、較低階的處理器與有 限的記憶體的裝置所提出之設計。 • 如行動電話、雙向傳呼器和 PDA Ø 要求包括最少 128 KB 的 Flash 或 ROM用 來 永久地儲存 Java 虛擬機器與基本類別函式 庫，以及 32 KB 的 RAM 用於動態地載入應 用程式於其中。 Ø Sun Microsystem 針對 CLDC 基本組態提供一 個可供參考與實作的 Java虛擬機器，稱為 Kilobyte Virtual Machine（ KVM）。 62
CDC Ø 設計給擁有較多的記憶體、較快的處理器 與較大網路頻寬的裝置。 • 如 電視機上盒、住家閘道器（ residential gateway）、 車上衛星通訊系統與較高階的 PDA。 Ø 包含完整的 Java虛擬機器，並有較大的類別 函式庫。 Ø Sun Microsystem 針對 CDC 提供一個可供參 考與實作的 Java虛擬機器，稱為 Compact Virtual Machine（ CVM）。 63
類別輪廓 Ø 基本組態必須與較高階層的類別輪廓做結 合，以進一步的定義應用程式的運作方式、 使用者介面與網路存取等特殊性質。 Ø J 2 ME 規格中定義的類別輪廓： • 行動訊息設備輪廓（ Mobile Information Device Profile， MIDP） • 基礎輪廓（Foundation Profile， FP） • 個人輪廓（Personal Profile， PP） • 個人基本輪廓（ Personal Basis Profile， PBP） 64
MIDP Ø 是以 CLDC基本組態為基礎的輪廓。 • 提供行動應用程式所需的核心功能，包括使用 者介面、網路連結、本地的資料儲存與應用程式 管理。 Ø 當 MIDP與 CLDC結合時，便提供一個為行動 設備設計的完整 Java執行環境。 Ø 設備裝置需要的硬體基本需求 • MIDP需要額外的 128 KB的 RAM於 CLDC基本組 態之上，以及 8 KB的 ROM做為永久儲存記憶體 之用。 • 顯示器最少需要 96 × 54 Pixel 的螢幕尺寸 65
FP Ø 當以 CDC為基礎時，其上的類別輪廓可以一 層一層往上疊。 Ø 只要加入新的類別輪廓，就可提供其所需 的功能。 Ø FP 是建構在 CDC 基本組態上之最底層的輪 廓。 • 提供 CDC 基本組態網路相關介面的能力，且能 夠被用於低階且沒有使用者介面的嵌入式實作。 66
PP Ø PP是一個以 CDC基本組態為基礎的輪廓。 Ø 為需要圖形使用者介面或網路應用程式的 裝置而設計。 • 例如高階的 PDA、智慧型手機裝置或遊戲操縱台。 Ø PP包含所有 Abstract Window Toolkit（ AWT）函 式庫，並且提供網路驗證。 67
PBP Ø PBP是 PP的一個子集，提供具有網路連結的 裝置一個應用程式的執行環境，並且支援 基本的圖形呈現能力或需要使用特別化圖 形套件的特殊應用程式。 Ø 適合 PBP的裝置包括電視機上盒與車上衛 星通訊系統。 68
選用性的類別組合 (1/2) Ø J 2 ME平台可以使用選用性的類別組合進一 步地延伸其功能。 Ø 應用於特殊的市場需求，提供標準的 API讓 現存或新興的技術使用。 • 例如藍芽、網頁服務、無線訊息、多媒體以及資 料庫連結。 69
選用性的類別組合 (2/2) Ø 選用性的類別組合可支援下列四種應用服 務： • J 2 ME安全與信任服務（ Security And Trust Services API for J 2 ME， SATSA）：透過安全元件的整合，提 供需要安全與信任的 J 2 ME服務之應用程式 API。 • J 2 ME網頁服務（J 2 ME Web service）：提供網頁存 取的服務。 • J 2 ME客戶端主動探尋規格（ J 2 ME client provisioning specification）：提供客戶端主動探尋服 務項目的標準存取介面。 • 行動媒體應用程式介面（ mobile media API）：允許 70 較小型的無線裝置支援通常只適用於現今的桌
Section 8. 4. 2 Jini 介紹 71
Java RMI Ø Remote Method Invocation， RMI Ø RMI 是將現有 Java 擴展到分散式網路上的 技術。RMI 讓 JVM上 的物件可以呼叫遠端 虛擬機器上物件中的函式（ method）執行，讓 程式設計師以分散式 Java技術實作應用程式。 Ø 在 J 2 SE和 J 2 ME上都已有 Java RMI。 72
Jini (1/2) Ø Jini 是 Sun Microsystems 利用 Java 平台所發展 出來的小型程式，與 Java 一樣具備跨平台特 性，可在任何地方執行。 Ø Jini 能透過原有的 Java 環境，以軟體或硬體 的型式外加到電腦設備或電子裝置上面。任 何支援 Jini 的產品，都可以互相使用與交換 資源。 Ø 在 Jini系統中，每件事物都可視為 一種服務。 當用戶使用一 個位在 Jini 環境 中的互動裝置 時，同時在這環境下的其他裝置和資源也可 73 一起使用，使用的方式就像使用手中的裝置
Jini (2/2) Ø Jini這樣的系統架構，具有分散式計算、簡 化的網路服務及管理能力，其核心技術即 為 RMI，即是在定義這些服務之間的通訊方 式。 Ø Jini 系統主要是由基礎建設（ infrastructure）、 程式設計模型（ programming model）及服務（ services）三方面所構成。 74
基礎建設 Ø 基礎建設定義了最小的 Jini技術核心，其包 含以下幾個部分： • Discovery/Join protocol：提供了如何讓網路上任何 種類的資源加入聯盟的方式，包括如何加入、如 何找尋其他服務等。 • e. Xtended RMI：提供 Jini的元件彼此溝通時所使用 的機制。 • Distributed security：定義了Jini聯盟成員的使用權 限。 • Lookup service：用來展現聯盟中的所有成員，以 及幫助使用者尋找網路資源，或者負責提供聯 75 盟中的資源給使用者用。
程式設計模型 Ø Jini提供一些分散式的程式設計模型， Jini的 基礎構造就是利用這些模型組合而成的。 模型所提供的介面包括以下幾種： • Leasing interface：負責管理物件被使用的時間。 • Two phase commit interface：是一個羽量級的（lightweight）、物件導向的（ object-oriented）介面。負責 管理分散式交易（ transaction）的動作，如 back、 roll forward等。 • Events interface：在分散式計算的環境中，必須確 保程式執行的先後順序，利用事件的觀念可以 幫助我們解決這個問題。 76
服務 Ø Jini 技術的發展目標，是讓各種網路組成服 務，而該項服務的用戶端可以被輕易的組 合、拆解、並加以維護。 Ø Jini 技術是在所有的通訊協定之上層來執行， 因此不論是有線網路或是無線網路都可運 作。在網路建立後， Jini技術便能夠讓使用 者在網路上提供或取用服務。 77
Section 8. 5 開放式服務閘道協議 Open Service Gateway initiatives， OSGi 78
OSGi (1/2) Ø 開放式服務閘道協議（ Open Services Gateway initiative， OSGi）起始於西元1999年 3月，是為 了提供更多元的服務給終端使用者所制定 的開放式規格。 Ø OSGi的目標，是希望將遠端的服務程式從 服務提供者，經由網路的連結，傳送到住家 閘道器，最後再由本地的網路傳達給設備 裝置，並自動安裝執行。 Ø 透過住家閘道器，使用者也可從遠端透過 住家閘道器去控制家庭網路中的家用設備。 79
OSGi (2/2) Ø OSGi利用 Java跨平台的特性，不同的廠商所 開發出來的服務，或是硬體設備，都可互相 搭配使用。 Ø 具有與作業平台無關（ platform independent） 和與應用程式無關（ application independent） 的優點。 Ø OSGi雖然是以住家閘道器為主要市場，但 也可應用於車上衛星通訊系統、 PDA、行動 電話以及其他相關的環境中。 80
OSGi的架構 Ø 下三層為住家閘道器應有的架構（硬體平台、 驅動程式、作業系統）。 Ø 上三層為 OSGi服務平台。 • 是一個 Java虛擬機器與其他 Java套件、一個 OSGi 框架（ OSGi framework）和一些應用套裝服務（ application bundles）的組合。 Ø 最上層的應用服務軟體稱為套裝服務（ bundles），依據不同設備不同需求，可以被 動態地安裝、更新和解安裝。 81
圖 8‑ 9 OSGi 的架構 82
OSGi 的優點 Ø 從提供應用的廠商的角度看來， 提供一個統一的 API。 OSGi便是 • 下層使用 Java技術，便可以跨不同的硬體與作業 系統等平台。 • 上層不同廠商只要依據 API開發套裝服務，便可 在不同的產品使用。 Ø 當然 OSGi服務平台必須擁有周密的安全機 制，提供操作者有效的 具來控制裝置的 安全運作。 83
Section 8. 6 OSA/Parlay and Parlay X 介紹 Introduction to OSA/Parlay and Parlay X 84
設計電信加值服務的困難點 Ø 長久以來，開發新的電信服務應用軟體，需 配合下層電信網路的架構。所以對於不同 的電信網路，就需為同一服務開發多套軟 體，造成軟體重複開發上資源的浪費。 Ø 底層電信網路架構複雜，難以讓上層應用 軟體直接運用。 Ø 對於電信加值服務的提供者而言，開發系 統的成本及難度難以掌控。 85
開放的共通介面 Ø 參考網際網路蓬勃發展的成功經驗，開放 性實為帶動相關技術得以快速成長的主因。 Ø 未來想要開發出更好的通訊服務，必須將 各種網路環境整合在一起，服務才能多樣 性。各種網路環境的整合，必須仰賴一個開 放的、標準化的共通介面。 • 上層之應用程式開發者，只要面對這一套標準 而簡易的服務存取介面，而不必再接觸底層電 信核心網路的溝通協定。 • 服務存取介面的實現，即底層網路的運作則交 給電信業者各自努力。 86
OSA/Parlay Ø OSA/Parlay 的概念是要提供一個穩定而可 彈性運用的系統開發平台。 • OSA全名為 Open Service Access，是 3 GPP之 作 小組之一。 • Parlay Group 創立的目的為提供一個共通的開放 標準介面，根據此服務存取介面，所架構出的開 放式 • 由於 Parlay所提出的標準規格十分豐富，並且符 合開放式的架構，與 3 GPP組織的精神大多一致。 因此 3 GPP便擷取 Parlay API部分相關的內容作為 3 GPP OSA主要執行細則，故稱為 OSA/Parlay。 87
OSA API Ø OSA/Parlay 可視為一組應用程式介面（ OSA Application Programming Interface， OSA API）， 介於應用程式與核心網路之間的介面。 • OSA/Parlay API 是由 Parlay Group 所訂定。 • 上層的應用程式皆以單一標準的規格與 OSA/Parlay溝通。 • 應用程式的指令透過 OSA/Parlay，轉譯成底層核 心網路上服務主機所能接受的專用指令與傳輸 協定。 • 轉譯的動作則由各個電信業者分別開發相對應 的程式碼，提供相對應的服務。 88
圖 8‑ 10 OSA/Parlay 架構圖 SCF OSA Framework SCS 89
OSA/Parlay的架構圖 Ø OSA 提供 API 給應用伺服器（ application server）使用，以建立應用（ application）。 Ø 在 API 與應用伺服器之間，可以利用如 CORBA/IIOP等技術建立一層分散式處理環 境（ distributed processing environment）。 Ø OSA 之下則是提供服務的各個電信系統元 件，例如 HLR、 CSE、 WGW WPP 等各種伺服 器 Ø OSA本身的元件，包括 SCS、 SCF 和 OSA 90 framework，如下所述。
Service Capability Server（ SCS） Ø SCS 所扮演的角色，就像是個轉換閘道器（ gateway），負責將底層網路中不同服務主機 之傳輸規格，轉換為 OSA/Parlay API的格式 給上方的應用程式。 91
Service Capability Feature（ SCF） Ø SCF 是為 SCS 提供網路功能的程式，例如 是用 Java 來實作的介面類別（ interface class）。 Ø OSA/Parlay 定義了以下的 SCF： • • • 話務控制（call control） 數據議程控制（ data session control） 使用者互動（user interaction） 行動（ mobility） 帳號管理（account management） 計費（ charging） 92
OSA框架（ OSA Framework） Ø OSA Framework 用於支援 SCS 的 作環境， 提供安全控管與註冊管理機制。 Ø 另外，Framework也負責連接上層應用軟體 之認證及授權，檢視所提供的功能（ service discovery）、建立服務合約（ service agreement）、 允許對核心網路內伺服器的存取。 Ø OSA Framework 與 SCS 真正實現的方式無關。 93
OSA 所提供的服務網路 94
Parlay X Ø 2003 年 Parlay Group 制定 Parlay X APIs 標準 介面規格。。 Ø Parlay X APIs 介面提供一組簡單易使用的 API，讓應用程式開發者容易地利用 Web Service 技術來存取系統業者所提供的電信 網路，大幅減低上層應用程式的開發時間。 95
Parlay X 的架構 Ø 圖 8 -11 左半部為 OSA/Parlay的架構，右半邊 是 Parlay X的架構。 • 原先 OSA/Parlay 的架構仍太複雜。 • Parlay X 增加了 Parlay X Web Service 介面。 • Parlay X Web Service 介面的 作是自動找尋 Parlay X API 相對應之 OSA/Parlay Gateway（即 SCS） 介面。 • 無需再知道 SCF 的 APIs。 Ø 以 Parlay X 發展的應用程式 B 可用簡單地使 用 OSA/Parlay Gateway 所提供的網路服務功 96 能。
圖 8‑ 11 OSA/Parlay 與 Parlay X 97
Parlay X API (1/2) Ø Parlay Group 訂定出的 Parlay X API： • • 第三方通話控制服務（ Third-party Call Control） 來電通知服務（ Call Notification） 簡訊服務（SMS） 多媒體訊息服務（ MMS） 付款服務（Payment） 帳戶管理服務（Account Management） 用戶狀態服務（Terminal Status） 98
Parlay X API (2/2) • Parlay Group 訂定出的 Parlay X API： • • • 用戶位置服務（Terminal Location） 通話處理服務（ Call Handling） 播放聲音通話服務（ Audio Call） 多媒體會議服務（ Multimedia Conference） 通訊錄管理服務（ Address List Management） 線上狀態服務（ Presence） 99
OSA/Parlay 的目的 Ø OSA/Parlay提出一個開放性的架構與標準化 的介面 • 要讓開發電信服務應用軟體商所應具備的技術 門檻能夠降低。 • 希望讓內容供應商可以快速的發展出新的應用 服務。 • 吸引原先從事網際網路技術的應用開發者，投 入電信網路加值服務的開發。 • 電信服務平台清楚地劃分電信加值服務提供者 與電信系統業者的分 ，降低系統開發所需成 本，進而加速電信服務的發展，以及電信網路與 其他異質網路的結合。 100
Section 8. 7 OMA組織介紹 Introduction to Open Mobile Alliance 101
OMA 的起源 Ø開放行動聯盟（ Open Mobile Alliance， OMA） 成 立 於 2002年 6月 ， 由 行 動 通 訊 產業 所 發 是 起、成立的組織。 Ø OMA的 概 念 最 初 是 由 Open Mobile Architecture、 WAP Forum發起， 在整合了LIF、 Sync. ML Initiative、 MMS-IOP、 Wireless Village、 MGIF、 MWIF等組織。 Ø OMA會員涵蓋了局端業者、設備商、網路供 應商、軟體公司、內容供應商等。 102
OMA 的目的 Ø OMA 的成立是為了創造一個訂定行動服務 （ mobile service）規格的中心，提升行動服務 的互通性（interoperability）。 Ø 達到 “無論使用何種設備或作業系統，無論 提供何種服務，無論採用何種行動通訊承 載網路，都可以與其他系統相互溝通並且 交換訊息 ”的目的。 103
OMA 的 作憲章 Ø 依 據 市 場 與 客 戶的 需 求 ， 定 高 品 質 及 且 制 得到回響的標準與規格。 Ø成立互通性測試中心， 含多種不同標準 包 的互通測試。 Ø 保 持 與 其 他 國 際 標 準 組 織 (如 ： IETF, 3 GPP 2, W 3 C, JCP)的 合 作 關 係 ， 確 保 標 準 以 的互通性。 Ø 提供 OMA成員最大的利益。 104
OMA 的 作群組 Ø OMA組織內區分為多個 作群組，分別負 責發展訂定不同行動服務的標準，包含了 Billing、 Browsing、 Client Provisioning、 DNS、 Digital Rights Management、 Download、 Email Notification、 Game Server、 IMPS、 MMS、 User Agent Profile、 Device Management、 Sync. ML、 Data Synchronization、 Push-to-talk over Cellular、 Mobile Web Service、 Presence & Availability等 眾多行動服務。 105
圖 8‑ 12 OMA 組織架構圖 106
加入 OAM Ø 台 灣 從 政 府 到 產業 界 ， 來 越 重 視 行 動 、 越 無 線 產業 上 Service的 推 動 ， OMA正 是 制 定 這 些 Service相關標準的組織。 Ø 如 果 台 灣 能 積 極 加 入 OMA Service標 準 的 訂 定 ， 更 有 助 於 台 灣 以 提 供 Service來 增 加 行 將 動、無線產業的產值（而非只是量） 。 Ø 加 上 OMA會 員 在 Service訂 定 階 段 就 能 先 期 掌 握 相 關 標 準 ， 提 供 台 灣 產業 更 多 的 反 能 應 時 間 ， 更 快 速 將 OMA Service提 供 給 使 可 用者，掌握市場服務先驅者的利基。 107
Section 8. 8 結語 Summary 108
Summary Ø 隨著行動通訊技術的發展，無線傳輸的速 率已大幅提升，然而目前全球各地，不論是 GPRS或 3 G網路，數據傳輸使用量明顯偏低。 其主要的原因，是因為目前行動通訊所能 提供的服務有限且非必要的總量偏低下相 對造成無線傳輸費用居高不下。若想解決 這樣無線網路使用率偏低的困境，唯有降 低開發應用服務的難度與門檻，才能提供 多元化的服務，方是推展無線數據傳輸服 務的治本之道。 109
Homework 110
Скачать презентацию Chapter 8 多媒體應用無線網路技術 Wireless Network Techniques for Multimedia
8dc86eb8cf800c10ac85c1d7a5faf1a9.ppt