Transcript 無投影片標題 - Test Page for Apache Installation

Chapter 8
多媒體應用無線網路技術
Wireless Network Techniques for
Multimedia Applications
1
課程目標
 不論是有線網路或是無線網路，不論是否擁有最
先進的技術，唯有提供豐富而多樣的應用服務，
才能吸引使用者創造龐大的商機。就如同電子郵
件是網際網路的殺手級應用，無線通訊的領域中
除了語音通話服務外，如何創造出其他殺手級的
應用以增加無線數據資料傳輸的使用率，是各家
廠商面對的最大難題。現今各廠商莫不把注意力
集中於多媒體應用上，因此本章節將介紹目前廠
商針對於無線多媒體應用所成立之聯盟與推出的
相關標準。
2
章節目錄
 簡介
 無線應用協定
 多媒體訊息服務
 Java 2微小版本J2ME
 開放式服務閘道協議
 OSA/Parlay and Parlay X 介紹
 OMA組織介紹
 結語
 作業
3
Section 8.1
簡介
Introduction
4
無線網路的特性
 網際網路蓬勃發展，各式各樣的網路應用不斷
興起。
 如何在無線網路上也能提供相同的服務
 無線網路的特性：
•
•
•
•
無線電頻寬有限  資料傳送速度慢
設備輕薄短小  螢幕小、 鍵盤輸入不易
計算能力不及個人電腦
使用電池
5
通訊協定
 專為無線環境設計各種通訊協定、程式語言 。
• 無線應用協定（Wireless Application Protocol，WAP）
• 多媒體訊息服務（Multimedia Messaging Services，
MMS）
• Java 2微小版本J2ME（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，
PoC）這些常用的服務，都是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
的底層，載送上層的資訊。
 基本上只定義了服務的架構，並不會涉入實作
的細節。
• 所以像 3GPP 要為 MMS 另定詳盡的規格書。
13
WAP 的運作方式
 無線應用協定閘道器（WAP GateWay，WGW）
介在有線與無線網路的中間，負責協調雙方的
溝通。
• 一端為TCP/IP（Transmission Control
Protocol/Internet Protocol）。
• 另一端為WAP的通訊協定。
Wireless:
WAP
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 的協定堆疊
Navigation
Discovery
Identify
Service
Lookup
PKI
Secure
Transport
Secure
Bearer
Session
Services
Auth.
Transfer
Services
Provisioning
Multimedia Messaging
Content Formats
WAE/WTA User-Agent
Push
Capability Negotiation
Sync
Cookies
Push-OTA
Hypermedia
Transfer
Transport
Services
Crypto.
Libraries
Bearer
Networks
EFI
Application
Framework
Security
Services
Protocol Framework
Service
Discovery
Streaming
Datagrams
Message
Transfer
Connections
IPv4
SMS
GHOST
FLEX
SDS
IPv6
USSD
GUTS
ReFLEX
MPAK
18
承載服務
 WAP 網路可以架在
•支援IP的承載服務層：如GPRS
•不支援IP的承載服務層：如 GSM、SMS
 WAP設計的本意就是希望能夠在眾多不同的承
載網路上提供相同的介面。
 即使底層的承載網路因科技的進步而改變，也
不會影響到上層傳輸服務的運作。
19
傳輸服務（1/2）
 傳輸服務層將來自上層非結構化的資料
（unstructured data）對應到下層的承載網路。
 傳輸服務分成兩大類：資料段（datagrams）服
務和連線（connections）服務。
 資料段服務（非連結導向）
•不事先建立連線，每一筆資料間都是完整獨立地被
傳送。
•如在支援IP的承載服務層之上使用的使用者資料段
協定（User Datagram Protocol，UDP）
•如：在無支援IP的承載服務層之上使用的無線數據
20
協定（Wireless Datagram Protocol，WDP）。
傳輸服務（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訂
定了 MMS Encapsulation 以傳送多媒體資料。
22
無線議程協定（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-HyperText Transfer Protocol，
WP-HTTP
 定義 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或使用IPv6本身提出的安全服務。
• Secure transport：在傳輸層上運作的安全機制。
 如 WP-TCP之上使用的 TLS（Transport Layer Security）。
 在WDP之上採用的無線傳輸層安全性（Wireless Transport
Layer Security，WTLS）。
31
安全服務（2/2）
 在不同的層次可使用不同的方式來提供安全性：
• PKI（Public Key Infrastructure）：提供公開密秘鑰
匙（public-key）進行加密，以及對憑證（certificate）
的管理。
• WIN（Wireless Identity Module）：提供使用者資料
的識別與認證。
• Authentication：用於認證用戶端與伺服器。
 如在議程服務層之可採用HTTP Client Authentication。
 在傳輸服務層之上可採用 WTLS（在WDP之上）與TLS
（在TCP之上）。
• Cryptographic Libraries：在應用平台上，提供資料
32
簽章的機制，避免資料被修改或複製。
服務探索（Service Discovery）
 提供用戶得知系統提供那些服務的機制：
• 外部功能性介面（External Functionality Interface，
EFI）：透過EFI可以在手持設備上加入一些嵌入式
的功能模組，藉此使用WAE外的功能。
• 組態設定（Provisioning）：WAP系統提供的一個機
制，讓無線手持設備取得必要的組態設定
• 導航探索（Navigation discovery）：這樣的機制讓
手持設備發現網路提供的新功能。
• 服務查表（Service lookup）：提供像網域名稱系統
（Domain Name System，DNS）這樣查詢的功能。
33
Section 8.2.2
存取全球資訊網
34
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的前身。
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 閘道器存
取網頁資料的範例
WAP
用戶端設備
WAP 閘道器
WAE
WSP
Web
伺服器
WAE
WSP
HTTP
HTTP
WTP
WTP
WTLS
WTLS
SSL
SSL
WDP
WDP
TCP
TCP
Bearer
Bearer
IP
IP
37
圖 8-3 WAP 2.0 使用 WAP 代理伺服
器的範例
WAP
用戶端設備
WAP Proxy
WAE
Web
伺服器
WAE
HTTP*
HTTP*
HTTP
HTTP
TCP*
TCP*
TCP
TCP
IP
IP
IP
IP
Wireless
Wireless
Wired
Wireless
38
WP-HTTP（以HTTP*表示）與WP-TCP（以TCP*表示）。
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版本。
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系統互動的閘道器。
MMS proxy-relay。
 可以整合在MMS伺服器之中。
44
MMS 基本元件 (2/2)
 MMS 架構中包含下列的元件：
• 電子郵件伺服器（E-mail server）
 提供MMS透過傳統網路上的E-mail傳送的服務。
 舊有無線訊息系統（legacy wireless messaging
system）
• 提供支援現行各類型的無線訊息系統，包含了傳呼
與SMS系統。
• 當要想傳送多媒體訊息給無MMS功能的手機時，就
會透過舊有無線訊息系統代送簡訊，告知其多媒體
訊息的網址，就可透過網際網路來觀看。
45
圖 8-4 MMS 的基本架構
MMS
儲存設備
一般手機
MMSS
L
Clou
d
舊有無線
訊息系統
MMS Server
Clou
d
Application
MMSA
E
MMS M
MMS Client
E-mail Server
MMS Proxy Relay
MMSR
Application
MMSA
MMS Client
Cloud
MMSM
MMS
儲存設備
MMSS
Cloud
其他 MMS系統
MMS Server
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訊息。
WSP/ WP-HTTP
HTTP
MMS用戶端
WAP閘道器
MMS代理伺服器中繼器
48
圖 8-6 MMS 操作流程圖
Originating
MMS Client
WAP
POST
Originating MMS
Proxy-Relay
Target MMS
Proxy-Relay
Target
MMS Client
1. M-Send.req
2. M-Send.conf
(3)
4. M-Notification.req
5. M-NotifyResp.ind
WAP
PUSH
Time Passes
6. WSP/HTTP GET.req
7. M-Retrieve.conf
WAP
GET
8. M-Acknowledge.ind
(9)
WAP
PUSH
10. M-Delivery.ind
49
MMS 操作流程 (1/3)
 步驟1. Originating MMS client使用WAP機制，
將 相 關 資 訊 與 多 媒 體 訊 息 一 併 封 裝 於 MSend.req的內容中，利用下層WSP傳送到發送
端系統之Originating MMS proxy-relay。這個讓
用 戶 端 把 資 料 傳 給 系 統 端 的 動 作 稱 為 WAP
POST。
 步驟2. Originating MMS proxy-relay回應訊息Msend.conf表示已收到。
 步驟3. Originating MMS proxy-relay 將多媒體訊
息轉送到目的地端系統之Target MMS proxy50
relay。
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 proxyrelay要求傳送多媒體訊息。這個讓用戶端向系
統端提出要求，取得資料的動作稱為WAP GET。
51
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傳送報告給
Originating MMS client。
52
Section 8.3.3
多媒體訊息服務之訊息架構和編碼
53
MMS 訊息
 MMS訊息是由多媒體訊息表頭和訊息主體所組
成。
•若採用WAP1.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）
格式，描述各個多媒體
元素的類型。
WSP Header
MMS Header
Message Body
Presentation
Text
Image
JPEG
Audio
AMR
Video
H.263
55
Section 8.4
Java 2 微小版本 J2ME
Java 2 Platform，Micro Edition
56
J2ME
 J2ME 是針對消費性與嵌入式裝置，例如行動
電話、PDA、電視機上盒（set-top boxes）、資
訊通訊系統（telematics systems）與眾多的嵌
入式系統裝置而設計的Java家族的成員。
 J2ME 平台是由一系列標準的Java應用程式介
面（Application Programming Interface，API）
所構成。
• 由 Java協會審議過程（Java Community Process，
JCP）所制定。
57
圖 8-8 Java 2 平台技術
Optional
Packages
Optional
Packages
Java 2
Enterprise
Edition
(J2EE)
Java 2 Micro Edition (J2ME)
Personal
Profile
Java 2
Standard Edition
(J2SE)
Java Virtual Machine
RMI
FP
MIDP
CDC
CLDC
Java Card
APIs
CVM
KVM
Card VM
58
Section 8.4.1
J2ME的架構
59
J2ME 的架構
 J2ME 的架構中定義了基本組態（configuration），
設定該裝置應該要具備的最基本功能。
•如對硬體的需求與所提供的基本類別函式庫（class
library）等。
 J2ME 提供所謂的類別輪廓（profile）的模組化的
套件，架在基本組態之上，提供更多的服務。
 選用性的類別組合（optional package）供選用。
 基本組態、類別輪廓與選用性的類別組合，便建
構了Java執行環境（runtime environment）。
•選用不同的套件，便可讓裝置設備有不同的特色或應
60
用。
基本組態
 基本組態由Java虛擬機器（Java Virtual Machine，
JVM）和一個最小的類別函式庫集合所構成，
提供了 J2ME 程式執行的平台。
 JVM安裝於作業系統上，類別函式庫則提供基
本的功能。
 J2ME 提供兩種基本組態：
• Connected Limited Device Configuration（CLDC）
• Connected Device Configuration（CDC）
61
CLDC
 為網路傳輸速度慢、較低階的處理器與有限的
記憶體的裝置所提出之設計。
•如行動電話、雙向傳呼器和PDA
 要求包括最少 128 KB 的 Flash 或 ROM用 來
永久地儲存 Java 虛擬機器與基本類別函式庫，
以及 32KB 的 RAM 用於動態地載入應用程式
於其中。
 Sun Microsystem 針對 CLDC 基本組態提供一
個可供參考與實作的Java虛擬機器，稱為
Kilobyte Virtual Machine（KVM）。
62
CDC
 設計給擁有較多的記憶體、較快的處理器與較
大網路頻寬的裝置。
• 如電視機上盒、住家閘道器（residential gateway）、
車上衛星通訊系統與較高階的PDA。
 包含完整的Java虛擬機器，並有較大的類別函
式庫。
 Sun Microsystem 針對 CDC 提供一個可供參考
與實作的Java虛擬機器，稱為Compact Virtual
Machine（CVM）。
63
類別輪廓
 基本組態必須與較高階層的類別輪廓做結合，
以進一步的定義應用程式的運作方式、使用者
介面與網路存取等特殊性質。
 J2ME 規格中定義的類別輪廓：
• 行動訊息設備輪廓（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)
 J2ME平台可以使用選用性的類別組合進一步
地延伸其功能。
 應用於特殊的市場需求，提供標準的API讓現
存或新興的技術使用。
• 例如藍芽、網頁服務、無線訊息、多媒體以及資料
庫連結。
69
選用性的類別組合 (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）：允許
較小型的無線裝置支援通常只適用於現今的桌上型70
電腦中的多媒體應用程式與服務。
Section 8.4.2
Jini 介紹
71
Java RMI
 Remote Method Invocation，RMI
 RMI 是將現有 Java 擴展到分散式網路上的技
術。RMI 讓 JVM上 的物件可以呼叫遠端虛擬
機器上物件中的函式（method）執行，讓程式
設計師以分散式Java技術實作應用程式。
 在J2SE和J2ME上都已有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：提供了如何讓網路上任何
種類的資源加入聯盟的方式，包括如何加入、如何
找尋其他服務等。
• eXtended RMI：提供Jini的元件彼此溝通時所使用的
機制。
• Distributed security：定義了Jini聯盟成員的使用權限。
• Lookup service：用來展現聯盟中的所有成員，以及
幫助使用者尋找網路資源，或者負責提供聯盟中的
資源給使用者用。
75
程式設計模型
 Jini提供一些分散式的程式設計模型，Jini的基
礎構造就是利用這些模型組合而成的。模型所
提供的介面包括以下幾種：
• Leasing interface：負責管理物件被使用的時間。
• Two phase commit interface：是一個羽量級的
（light-weight）、物件導向的（object-oriented）介
面。負責管理分散式交易（transaction）的動作，如
roll 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 的架構
Application Bundles
OSGi Framework
Java Virtual Machine
& Class Libraries
Operating System
Device Drivers
Hardware Platform
82
OSGi 的優點
 從提供應用的廠商的角度看來，OSGi便是提供
一個統一的API。
• 下層使用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，是3GPP之工作小
組之一。
• Parlay Group 創立的目的為提供一個共通的開放標
準介面，根據此服務存取介面，所架構出的開放式
• 由於Parlay所提出的標準規格十分豐富，並且符合
開放式的架構，與3GPP組織的精神大多一致。因此
3GPP便擷取Parlay API部分相關的內容作為3GPP
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 架構圖
Application
server
Application
Distributed Processing Environment (Ex: CORBA/IIOP)
discovery
SCF
Open
Service
Access
framework
charging
OSA
Framework HLR
OSA API
Interface
class
call control
service capability server
CSE
WGW
WPP
Other
server
SCS
89
OSA internal API
OSA/Parlay的架構圖
 OSA 提供 API 給應用伺服器（application
server）使用，以建立應用（application）。
 在 API 與應用伺服器之間，可以利用如
CORBA/IIOP等技術建立一層分散式處理環境
（distributed processing environment）。
 OSA 之下則是提供服務的各個電信系統元件，
例如 HLR、CSE、WGW WPP 等各種伺服器
 OSA本身的元件，包括SCS、SCF 和 OSA
framework，如下所述。
90
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 所提供的服務網路
Application Servers
OSA API
OSA API
SCS
SCS
PoC SCF
SIP
Adapter
Isc
P-CSCF
AAA SCS
Server
SIP
Adapter
RADIUS
Adapter
Proprietary
Ik
RTP
Proxy
Is
RTP
AAA SCF
PAM SCS
Server
Proprietary
Adapter
Billing
Gateway
RADIUS
AAA
Server
GLMS
Im
OSA-based
AAA
SCS
PAM SCF
PoC SCS Server
OSA API
GTP/GTP’
SCTP
HSS
SCTP
MS-1
802.1X AP
MS-5
WLAN/Cellular
Handset
WGSN
802.1X AP
MS-2
802.1X AP
MS-4
802.1X AP
MS-3
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
Application A
Application B
Parlay X APIs
Parlay X Web Service
OSA/Parlay X APIs
OSA/Parlay Gateway
Network Protocol
(e.g.SIP)
Network Elements
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 、 SyncML
Initiative、MMS-IOP、Wireless Village、MGIF、
MWIF等組織。
 OMA會員涵蓋了局端業者、設備商、網路供應
商、軟體公司、內容供應商等。
102
OMA 的目的
 OMA 的成立是為了創造一個訂定行動服務
（mobile service）規格的中心，提升行動服務
的互通性（interoperability）。
 達到“無論使用何種設備或作業系統，無論提
供何種服務，無論採用何種行動通訊承載網路，
都可以與其他系統相互溝通並且交換訊息”的
目的。
103
OMA 的工作憲章
 依據市場與客戶的需求，制定高品質及且得到
回響的標準與規格。
 成立互通性測試中心，包含多種不同標準的互
通測試。
 保 持 與 其 他 國 際 標 準 組 織 ( 如 ： IETF, 3GPP,
3GPP2, W3C, 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、
SyncML、Data Synchronization、Push-to-talk
over Cellular、Mobile Web Service、Presence &
Availability等眾多行動服務。
105
圖 8-12 OMA 組織架構圖
BOARD
TECHNICAL
PLENARY
OPERATIONS
& PROCESSES
BROWSER
& CONTENT
GAMES
SERVICES
RELEASE PLANNING
& MANAGEMENT
DEVICE
MANAGEMENT
LOCATION
MOBILE
WEB SERVICES
MESSAGING
PRESENCE
& AVAILABILITY
PRQUIREMENTS
ARCHITECTURE
DATA
SYNCHRONISATION
SECURITY
INTEROPERABILITY
圖例
Committee
Working Group
DEVELOPERS
INTERESTS
MOBILE COMMERCE
& CHARGING
PUSH TO TALK
OVER CELLULAR
106
加入 OAM
 台灣從政府到產業界，越來越重視行動、無線
產 業 上 Service 的 推 動 ， OMA 正 是 制 定 這 些
Service相關標準的組織。
 如果台灣能積極加入OMA Service標準的訂定，
將更有助於台灣以提供Service來增加行動、無
線產業的產值（而非只是量） 。
 加上OMA會員在Service訂定階段就能先期掌握
相關標準，能提供台灣產業更多的反應時間，
可更快速將OMA Service提供給使用者，掌握
市場服務先驅者的利基。
107
Section 8.8
結語
Summary
108
Summary
 隨著行動通訊技術的發展，無線傳輸的速率已
大幅提升，然而目前全球各地，不論是GPRS
或3G網路，數據傳輸使用量明顯偏低。其主要
的原因，是因為目前行動通訊所能提供的服務
有限且非必要的總量偏低下相對造成無線傳輸
費用居高不下。若想解決這樣無線網路使用率
偏低的困境，唯有降低開發應用服務的難度與
門檻，才能提供多元化的服務，方是推展無線
數據傳輸服務的治本之道。
109
Homework
110