多媒体应用无线网路技术.ppt

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