九十五年度「我國IPv6建置發展計畫」

Transcription

1 九十六年度 我國 IPv6 建置發展計畫 期末工作報告附件目錄 附件一 參考文獻及補充資料... P.1 ( 一 ) 標準測試分項計畫 IETF IPv6 相關 RFC 一覽表 P.1 ( 二 ) 應用推廣分項計畫 VoiceTel IPv6 5-8 月份維運報告...P.8 附件二 論文與演說發表...P.74 ( 一 ) 標準測試分項計畫...P.74 ( 二 ) 應用推廣分項計畫 VoIPv6 於企業網路之關鍵技術及應用 (2007 IPv6 Summit in Taiwan 應用推廣研討會投影片 )... P.82 ( 三 ) 應用推廣分項子計畫四 (Journal of IM)A semantic service discovery approach for ubiquitous computing...p.87 (Sigcomm2007) Internetworking Between ZigBee/ and IPv6/802.3 Network.....P.97

2 附件三 會議資料. P.103 ( 一 ) 標準測試分項計畫分項計畫會議紀錄...P.103 附件四 活動記錄....P.117 ( 一 ) 標準測試分項計畫接待法國電信總局及法國電信代表...P.117 主辦 2007 IPv6 Summit in Taiwan 測試研討會...P.117 參訪美國國家標準和技術研究院 (NIST)...P.118

3 附件一 參考文獻及補充資料 標準測試分項計畫 1. IETF IPv6 相關 RFC 一覽表 編 號 2007/09/12 製表 RFC 名稱狀態時間 [1] RFC 1809 Using the Flow Label Field in IPv6 INFORMATIONAL 1995/06 [2] RFC 1881 IPv6 Address Allocation Management. INFORMATIONAL 1995/12 [3] RFC 1883 Internet Protocol, Version 6 (IPv6) Specification Obsoleted by RFC /12 [4] RFC 1884 IP Version 6 Addressing Architecture Obsoleted by RFC /12 [5] RFC 1885 Internet Control Message Protocol (ICMPv6) for the Obsoleted by RFC /12 Internet Protocol Version 6 (IPv6) [6] RFC 1886 DNS Extensions to support IP version 6 Updated by RFC2874, 1995/12 RFC3152 Obsoleted by RFC3596 [7] RFC 1887 An Architecture for IPv6 Unicast Address Allocation INFORMATIONAL 1995/12 [8] RFC 1888 OSI NSAPs and IPv6 EXPERIMENTAL 1996/08 [9] RFC 1897 IPv6 Testing Address Allocation Obsoleted by RFC /01 [10] RFC 1924 A Compact Representation of IPv6 Addresses. INFORMATIONAL 1996/04 [11] RFC 1933 Transition Mechanisms for IPv6 Hosts and Routers. Obsoleted by RFC /04 [12] RFC 1970 Neighbor Discovery for IP Version 6 (IPv6) Obsoleted by RFC /08 [13] RFC 1971 IPv6 Stateless Address Autoconfiguration. Obsoleted by RFC /08 [14] RFC 1972 A Method for the Transmission of IPv6 Packets over Obsoleted by RFC /08 Ethernet Networks [15] RFC 1981 Path MTU Discovery for IP version 6 PROPOSED 1996/08 [16] RFC 2019 Transmission of IPv6 Packets Over FDDI Obsoleted by RFC /10 [17] RFC 2023 IP Version 6 over PPP Obsoleted by RFC /10 [18] RFC 2030 Simple Network Time Protocol (SNTP) Version 4 for INFORMATIONAL 1997/01 IPv4, IPv6 and OSI. Obsoletes RFC1769 [19] RFC 2073 An IPv6 Provider-Based Unicast Address Format Obsoleted by RFC /01 [20] RFC 2080 RIPng for IPv6. PROPOSED 1997/01 [21] RFC 2133 Basic Socket Interface Extensions for IPv6 Obsoleted by RFC /04 [22] RFC 2147 TCP and UDP over IPv6 Jumbograms Obsoleted by RFC /05 [23] RFC 2185 Routing Aspects of IPv6 Transition. INFORMATIONAL 1997/09 [24] RFC 2292 Advanced Sockets API for IPv6 INFORMATIONAL 1998/02 (Obsoleted by RFC3542) [25] RFC 2373 IP Version 6 Addressing Architecture PROPOSED 1998/07 (Obsoletes RFC1884) (Obsoleted by RFC3513) [26] RFC 2374 An IPv6 Aggregatable Global Unicast Address Format PROPOSED 1998/07 (Obsoletes RFC2073) (Obsoleted by RFC 3587) [27] RFC 2375 IPv6 Multicast Address Assignments INFORMATIONAL 1998/07 1

4 [28] RFC 2428 FTP Extensions for IPv6 and NATs. PROPOSED 1998/09 [29] RFC 2450 Proposed TLA and NLA Assignment Rules INFORMATIONAL 1998/12 [30] RFC 2452 IP Version 6 Management Information Base for the PROPOSED 1998/12 Transmission Control Protocol [31] RFC 2454 IP Version 6 Management Information Base for the PROPOSED 1998/12 User Datagram Protocol [32] RFC 2460 Internet Protocol, Version 6 (IPv6) Specification DRAFT 1998/12 (Obsoletes RFC1883) [33] RFC 2461 Neighbor Discovery for IP Version 6 (IPv6) DRAFT 1998/12 (Obsoletes RFC1970) (Updated by 4311) [34] RFC 2462 IPv6 Stateless Address Autoconfiguration (DRAFT ) 1998/12 (Obsoletes RFC1971) [35] RFC 2463 Internet Control Message Protocol (ICMPv6) for the DRAFT 1998/12 Internet Protocol Version 6 (IPv6) Specification (Obsoletes RFC1885) (Obsoleted by RFC4443) [36] RFC 2464 Transmission of IPv6 Packets over Ethernet Networks PROPOSED 1998/12 (Obsoletes RFC1972) [37] RFC 2465 Management Information Base for IP Version 6: PROPOSED 1998/12 Textual Conventions and General Group [38] RFC 2466 Management Information Base for IP Version 6: PROPOSED 1998/12 ICMPv6 Group [39] RFC 2467 Transmission of IPv6 Packets over FDDINetworks PROPOSED 1998/12 (Obsoletes RFC2019) [40] RFC 2470 Transmission of IPv6 Packets over Token Ring PROPOSED 1998/12 Networks [41] RFC 2471 IPv6 Testing Address Allocation Obsoleted by RFC /12 EXPERIMENTAL (Obsoletes RFC1897): [42] RFC 2472 IP Version 6 over PPP PROPOSED 1998/12 (Obsoletes RFC2023) [43] RFC 2473 Generic Packet Tunneling in IPv6 Specification PROPOSED 1998/12 [44] RFC 2474 Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers. PROPOSED Obsoletes RFC1455, RFC1349 Updated by RFC3168, RFC /12 [45] RFC 2491 IPv6 over Non-Broadcast Multiple Access (NBMA) PROPOSED 1999/01 networks. [46] RFC 2492 IPv6 over ATM Networks. PROPOSED 1999/01 [47] RFC 2497 Transmission of IPv6 Packets over ARCnet Networks PROPOSED 1999/01 [48] RFC 2507 IP Header Compression PROPOSED 1999/02 [49] RFC 2526 Reserved IPv6 Subnet Anycast Addresses PROPOSED 1999/03 [50] RFC 2529 Transmission of IPv6 over IPv4 Domains without PROPOSED 1999/03 Explicit Tunnels [51] RFC 2545 Use of BGP-4 Multiprotocol Extensions for IPv6 PROPOSED 1999/03 Inter-Domain Routing. [52] RFC 2553 Basic Socket Interface Extensions for IPv6 PROPOSED 1999/03 2

5 (Updated by RFC2938) (Obsoleted by RFC3493) [53] RFC 2590 Transmission of IPv6 Packets over Frame Relay Networks Specification. PROPOSED [54] RFC 2675 IPv6 Jumbograms PROPOSED (Obsoletes RFC2147) [55] RFC 2710 Multicast Listener Discovery (MLD) for IPv6 PROPOSED Updated by RFC 3590 [56] RFC 2711 IPv6 Router Alert Option PROPOSED [57] RFC 2732 Format for Literal IPv6 Addresses in URL's PROPOSED [58] RFC 2740 OSPF for IPv6. PROPOSED [59] RFC 2874 DNS Extensions to Support IPv6 Address Aggregation and Renumbering EXPERIMENTAL (Updated by RFC3152, RFC3226, RFC3363, RFC3364) [60] RFC 2893 Transition Mechanisms for IPv6 Hosts and Routers. PROPOSED Obsoletes RFC1933 Obsoleted by RFC / / / / / / / /08 [61] RFC 2894 Router Renumbering for IPv6 PROPOSED 2000/08 [62] RFC 2928 Initial IPv6 Sub-TLA ID Assignments INFORMATIONAL 2000/09 [63] RFC 3019 IP Version 6 Management Information Base for the PROPOSED 2001/01 Multicast Listener Discovery Protocol [64] RFC 3041 Privacy Extensions for Stateless Address PROPOSED 2001/01 Autoconfiguration in IPv6 [65] RFC 3053 IPv6 Tunnel Broker. INFORMATIONAL 2001/01 [66] RFC 3056 Connection of IPv6 Domains via IPv4 Clouds. PROPOSED 2001/02 [67] RFC 3089 A SOCKS-based IPv6/IPv4 Gateway Mechanism. INFORMATIONAL 2001/04 [68] RFC 3111 Service Location Protocol Modifications for IPv6. PROPOSED 2001/05 [69] RFC 3122 Extensions to IPv6 Neighbor Discovery for Inverse PROPOSED 2001/06 Discovery Specification [70] RFC 3142 An IPv6-to-IPv4 Transport Relay Translator. INFORMATIONAL 2001/06 [71] RFC 3146 Transmission of IPv6 Packets over IEEE 1394 PROPOSED 2001/10 Networks [72] RFC 3152 Delegation of IP6.ARPA. Obsoleted by RFC /08 BEST CURRENT PRACTICE [73] RFC 3162 RADIUS and IPv6 PROPOSED 2001/08 [74] RFC 3175 Aggregation of RSVP for IPv4 and IPv6 Reservations PROPOSED 2001/09 [75] RFC 3177 IAB/IESG Recommendations on IPv6 Address INFORMATIONAL 2001/09 [76] RFC 3178 IPv6 Multihoming Support at Site Exit Routers INFORMATIONAL 2001/10 [77] RFC 3226 DNSSEC and IPv6 A6 aware server/resolver message PROPOSED 2001/12 size requirements [78] RFC 3266 Support for IPv6 in Session Description Protocol PROPOSED 2002/06 (SDP). [79] RFC 3306 Unicast-Prefix-based IPv6 Multicast Addresses. Updated by 2002/08 3

6 RFC3956 RFC4489 PROPOSED [80] RFC 3307 Allocation Guidelines for IPv6 Multicast Addresses. PROPOSED 2002/08 [81] RFC 3314 Recommendations for IPv6 in Third Generation INFORMATIONAL 2003/04 Partnership Project (3GPP) Standards. [82] RFC 3315 Dynamic Host Configuration Protocol for IPv6 TRACK 2003/07 (DHCPv6) (Updated by RFC4361) [83] RFC 3319 Dynamic Host Configuration Protocol (DHCPv6) TRACK 2003/07 Options for Session Initiation Protocol (SIP) Servers [84] RFC 3363 Representing Internet Protocol version 6 (IPv6) INFORMATIONAL 2002/08 Addresses in the Domain Name System (DNS). [85] RFC 3364 Tradeoffs in Domain Name System (DNS) Support for INFORMATIONAL 2002/08 Internet Protocol version 6 (IPv6). [86] RFC 3484 Default Address Selection for Internet Protocol version PROPOSED 2003/02 6 (IPv6). [87] RFC 3493 Basic Socket Interface Extensions for IPv6. INFORMATIONAL 2003/02 [88] RFC 3513 Internet Protocol Version 6 (IPv6) Addressing Architecture. (Obsoletes RFC2553) PROPOSED (Obsoletes RFC2373) (Obsoleted by RFC4291) 2003/04 [89] RFC 3531 A Flexible Method for Managing the Assignment of INFORMATIONAL 2003/04 Bits of an IPv6 Address Block. [90] RFC 3542 Advanced Sockets Application Program Interface INFORMATIONAL 2003/05 (API) for IPv6. (Obsoletes RFC2292) [91] RFC 3582 Goals for IPv6 Site-Multihoming Architectures. INFORMATIONAL 2003/08 [92] RFC 3587 IPv6 Global Unicast Address Format. INFORMATIONAL (Obsoletes RFC2374) 2003/08 [93] RFC 3595 Textual Conventions for IPv6 Flow Label. PROPOSED 2003/09 [94] RFC 3596 DNS Extensions to Support IP Version 6. PROPOSED 2003/10 Obsoletes RFC3152, RFC1886 [95] RFC 3633 IPv6 Prefix Options for Dynamic Host Configuration PROPOSED 2003/12 Protocol (DHCP) version 6. [96] RFC 3646 DNS Configuration options for Dynamic Host PROPOSED 2003/12 Configuration Protocol for IPv6 (DHCPv6) [97] RFC 3697 IPv6 Flow Label Specification. PROPOSED 2004/3 [98] RFC bone (IPv6 Testing Address Allocation) Phaseout. INFORMATIONAL 2004/3 (Obsoletes RFC2471) [99] RFC 3736 Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6. PROPOSED 2004/4 [100] RFC 3750 Unmanaged Networks IPv6 Transition Scenarios. INFORMATIONAL 2004/4 [101] RFC 3756 IPv6 Neighbor Discovery (ND) Trust Models and INFORMATIONAL 2004/4 Threats [102] RFC 3769 Requirements for IPv6 Prefix Delegation. INFORMATIONAL 2004/6 [103] RFC 3775 Mobility Support in IPv6 PROPOSED 2004/6 [104] RFC 3776 Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents PROPOSED 2004/6 [105] RFC 3810 Multicast Listener Discovery Version 2 (MLDv2) for PROPOSED 2004/6 4

7 IPv6 Updates RFC 2710 [106] RFC 3831 Transmission of IPv6 Packets over Fibre Channel PROPOSED 2004/7 Obsoleted by RFC 4338 [107] RFC 3849 IPv6 Address Prefix Reserved for Documentation. INFORMATIONAL 2004/7 [108] RFC 3879 Deprecating Site Local Addresses. PROPOSED 2004/9 [109] RFC 3898 Network Information Service (NIS) Configuration Options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6). PROPOSED 2004/10 [110] RFC 3901 DNS IPv6 Transport Operational Guidelines BEST CURRENT 2004/9 PRACTICE [111] RFC 3904 Evaluation of IPv6 Transition Mechanisms for INFORMATIONAL 2004/9 Unmanaged Networks. [112] RFC 3919 Remote Network Monitoring (RMON) Protocol Identifiers for IPv6 and Multi Protocol Label Switching (MPLS). INFORMATIONAL 2004/10 [113] RFC 3956 Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address. (Updates RFC3306) PROPOSED 2004/11 [114] RFC 3963 Network Mobility (NEMO) Basic Support Protocol. PROPOSED 2005/1 [115] RFC 3964 Security Considerations for 6to4. INFORMATIONAL 2004/12 [116] RFC 3974 SMTP Operational Experience in Mixed IPv4/v6 INFORMATIONAL 2005/1 Environments. [117] RFC 4007 IPv6 Scoped Address Architecture. PROPOSED 2005/3 [118] RFC 4029 Scenarios and Analysis for Introducing IPv6 into ISP INFORMATIONAL 2005/3 Networks. [119] RFC 4038 Application Aspects of IPv6 Transition. INFORMATIONAL 2005/3 [120] RFC 4057 IPv6 Enterprise Network Scenarios. INFORMATIONAL 2005/6 [121] RFC 4074 Common Misbehavior Against DNS Queries for IPv6 INFORMATIONAL 2005/5 Addresses. [122] RFC 4075 Simple Network Time Protocol (SNTP) Configuration PROPOSED 2005/5 Option for DHCPv6. [123] RFC 4076 Renumbering Requirements for Stateless Dynamic INFORMATIONAL 2005/5 Host Configuration Protocol for IPv6 (DHCPv6). [124] RFC 4135 Goals of Detecting Network Attachment in IPv6. INFORMATIONAL 2005/8 [125] RFC 4140 Hierarchical Mobile IPv6 Mobility Management EXPERIMENTAL 2005/8 (HMIPv6). [126] RFC 4147 Proposed Changes to the Format of the IANA IPv6 INFORMATIONAL 2005/8 Registry. [127] RFC 4192 Procedures for Renumbering an IPv6 Network without INFORMATIONAL 2005/9 a Flag Day. [128] RFC 4193 Unique Local IPv6 Unicast Addresses. R. Hinden, B. PROPOSED 2005/10 Haberman. [129] RFC 4213 Basic Transition Mechanisms for IPv6 Hosts and PROPOSED 2005/10 Routers. (Obsoletes RFC2893) [130] RFC 4215 Analysis on IPv6 Transition in Third Generation INFORMATIONAL 2005/10 Partnership Project (3GPP) Networks. [131] RFC 4218 Threats Relating to IPv6 Multihoming Solutions. INFORMATIONAL 2005/10 [132] RFC 4219 Things Multihoming in IPv6 (MULTI6) Developers INFORMATIONAL 2005/10 Should Think About. [133] RFC 4241 A Model of IPv6/IPv4 Dual Stack Internet Access INFORMATIONAL 2005/12 Service. [134] RFC 4242 Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6). PROPOSED 2005/11 5

8 [135] RFC 4260 Mobile IPv6 Fast Handovers for Networks. INFORMATIONAL 2005/11 [136] RFC 4283 Mobile Node Identifier Option for Mobile IPv6 PROPOSED 2005/11 (MIPv6). [137] RFC 4291 IP Version 6 Addressing Architecture DRAFT 2006/02 (Obsoletes RFC3513) [138] RFC 4293 Management Information Base for the Internet Protocol (IP). PROPOSED 2006/04 (Obsoletes RFC2011, RFC2465, RFC2466) [139] RFC 4311 IPv6 Host-to-Router Load Sharing. PROPOSED 2005/11 [140] RFC 4330 Simple Network Time Protocol (SNTP) Version 4 for INFORMATIONAL 2006/01 IPv4, IPv6 and OSI. [141] RFC 4338 Transmission of IPv6, IPv4, and Address Resolution Protocol (ARP) Packets over Fibre Channel. PROPOSED 2006/01 (Obsoletes RFC3831, RFC2625) [142] RFC 4380 Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs). PROPOSED 2006/02 [143] RFC 4443 Internet Control Message Protocol (ICMPv6) for the DRAFT 2006/03 Internet Protocol Version 6 (IPv6) Specification (Obsoletes RFC2463) (Updates RFC2780) [144] RFC 4449 Securing Mobile IPv6 Route Optimization Using a PROPOSED 2006/06 Static Shared Key. [145] RFC 4472 Operational Considerations and Issues with IPv6 DNS. INFORMATIONAL 2006/04 [146] RFC 4477 Dynamic Host Configuration Protocol (DHCP): IPv4 INFORMATIONAL 2006/05 and IPv6 Dual-Stack Issues. [147] RFC 4487 Mobile IPv6 and Firewalls: Problem Statement. INFORMATIONAL 2006/05 [148] RFC 4489 A Method for Generating Link-Scoped IPv6 Multicast PROPOSED 2006/05 Addresses. (Updates RFC3306) [149] RFC 4554 Use of VLANs for IPv4-IPv6 Coexistence in INFORMATIONAL 2006/06 Enterprise Networks. [150] RFC 4580 Dynamic Host Configuration Protocol for IPv6 PROPOSED 2006/06 (DHCPv6) Relay Agent Subscriber-ID Option. [151] RFC 4584 Extension to Sockets API for Mobile IPv6. INFORMATIONAL 2006/07 [152] RFC 4620 IPv6 Node Information Queries. EXPERIMENTAL 2006/08 [153] RFC 4649 Dynamic Host Configuration Protocol for IPv6 PROPOSED 2006/08 (DHCPv6) Relay Agent Remote-ID Option. [154] RFC 4659 BGP-MPLS IP Virtual Private Network (VPN) PROPOSED 2006/09 Extension for IPv6 VPN. [155] RFC 4668 RADIUS Authentication Client MIB for IPv6. PROPOSED 2006/08 (Obsoletes RFC2618) [156] RFC 4669 RADIUS Authentication Server MIB for IPv6. PROPOSED 2006/08 (Obsoletes RFC2619) [157] RFC 4670 RADIUS Accounting Client MIB for IPv6. INFORMATIONAL 2006/08 (Obsoletes RFC2620) [158] RFC 4671 RADIUS Accounting Server MIB for IPv6. INFORMATIONAL 2006/08 (Obsoletes RFC2621) [159] RFC 4692 Considerations on the IPv6 Host Density Metric. INFORMATIONAL 2006/10 [160] RFC 4704 The Dynamic Host Configuration Protocol for IPv6 PROPOSED 2006/10 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option. [161] RFC 4727 Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers. PROPOSED 2006/11 [162] RFC 4773 Administration of the IANA Special Purpose IPv6 INFORMATIONAL 2006/12 6

9 Address Block. [163] RFC 4776 Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information. [164] RFC 4779 ISP IPv6 Deployment Scenarios in Broadband Access Networks. January [165] RFC 4798 Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE). PROPOSED 2006/12 INFORMATIONAL 2007/01 INFORMATIONAL 2007/02 [166] RFC 4818 RADIUS Delegated-IPv6-Prefix Attribute. PROPOSED 2007/04 [167] RFC 4843 An IPv6 Prefix for Overlay Routable Cryptographic EXPERIMENTAL 2007/04 Hash Identifiers (ORCHID). [168] RFC 4852 IPv6 Enterprise Network Analysis - IP Layer 3 Focus. INFORMATIONAL 2007/04 [169] RFC 4864 Local Network Protection for IPv6 INFORMATIONAL 2007/05 [170] RFC 4866 Enhanced Route Optimization for Mobile IPv6 PROPOSED 2007/05 [171] RFC 4877 Mobile IPv6 Operation with IKEv2 and the Revised PROPOSED 2007/04 IPsec Architecture. [172] RFC 4882 IP Address Location Privacy and Mobile IPv6: INFORMATIONAL 2007/05 Problem Statement [173] RFC 4884 Extended ICMP to Support Multi-Part Messages PROPOSED 2007/04 [174] RFC 4890 Recommendations for Filtering ICMPv6 Messages in INFORMATIONAL 2007/05 Firewalls [175] RFC 4891 Using IPsec to Secure IPv6-in-IPv4 Tunnels INFORMATIONAL 2007/05 [176] RFC 4908 Multi-homing for small scale fixed network Using EXPERIMENTAL 2007/06 Mobile IP and NEMO [177] RFC 4919 IPv6 over Low-Power Wireless Personal Area INFORMATIONAL 2007/08 Networks (6LoWPANs):Overview, Assumptions, Problem Statement, and Goals [178] RFC 4968 [179] RFC 4977 Analysis of IPv6 Link Models for Based INFORMATIONAL 2007/08 Networks Problem Statement: Dual Stack Mobility INFORMATIONAL 2007/08 網底顏色說明 深黃褐色 表示已被新文件取代 淺黃色 表示已被新文件更新 淺藍色 表示 2004 年新增文件 淺綠色 表示 2005 年新增文件 10% 灰度值 表示 2006 年新增文件 無填滿 表示 2007 年新增文件 篇數統計

10 8 Voice Tel VoIPV6 通訊平臺維運報表 2007 年 5 月 一 介面數據統計 AWstats 統計 1. 摘要 2. 每日統計圖

11 3. 每日點選明細 9

12 4. 分時統計 10

13 11 5. 客戶主機 IP 6. 網頁瀏覽時間

14 表 1-2 首頁 IPv4 來源 12

15 13 表 1-3 Softphone 下載點擊率 Softphone 下載點擊統計表日期資料統計 0:00 2:00 4:00 6:00 8:00 10:00 12:00 14:00 16:00 18:00 20:00 22:00 日統計 总计

16 14 表 1-4 WEB 服務器系統負載 WEB 服務負載 (CPU%) 統計表 日期 資料統計 0:00 2:00 4:00 6:00 8:00 10:00 12:00 14:00 16:00 18:00 20:00 22:00 日統計 時段統計 WEB 服務負載 (MEM%) 統計表 日期 資料統計

17 15 0:00 2:00 4:00 6:00 8:00 10:00 12:00 14:00 16:00 18:00 20:00 22:00 日統計 時段統計

18 16 二 用戶數據統計表 2-1 在線用戶數 線上用戶統計表日期資料統計 0:00 2:00 4:00 6:00 8:00 10:00 12:00 14:00 16:00 18:00 20:00 22:00 日統計 時段統計

19 17 表 2-2 新註冊用戶數新註冊用戶統計表日期資料統計 合計 0

20 18 表 2-3 通話時長 通話時間統計表 (second) 日期 資料統計 IPv4-to-IPv4 IPv4-to-IPv6 IPv6-to-IPv4 IPv6-to-IPv6 每日統計 <827> <102> <321> <32> <127> 分類統計 <1409>

21 19 表 2-4 通話次數 通話次數統計表 日期 資料統計 IPv4-to-IPv4 IPv4-to-IPv6 IPv6-to-IPv4 IPv6-to-IPv6 每日統計 <2> 0 2<2> <4> 1 22<4> <2> 2 6<2> <1> 0 1<1> <1> 12 14<1> <1> 4 5<1> <4> 2 7<4> <1> 12 27<1> <1> 20 21<1> 分類統計 <17>

22 20 表 2-4 Concurrent Call Concurrent Call 日期 時間區間 最大值

23 21 三 客服數據表 3-1 品質測試數據 語音品質統計表 日期 資料統計 ( 調查問卷,1 分最差,5 分最好 ) 用戶 1 用戶 2 用戶 3 用戶 4 用戶 5 用戶 6 用戶 7 用戶 8 用戶 9 用戶 10 日平均 平均

24 22 表 3-2 系統維護記錄 伺服器維護日誌 2007 年 平臺編號 IPv6_Sonet_8_1 平臺型號 : IPv6 主要負責人 : yoko 服務狀態 系統數據 時間 註冊平臺內點對點跨平臺點對點落地呼叫 WEB Proxy Billing CPU% MEM% HD% CPU% MEM SQL 記錄人備註 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 Ok Ok OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄

25 23 四 數據分析表 4-1 運營成本分析對照系統運營成本對照分析表 運營人力成本 IPv4 IPv 年 5 月 工作時數單位時間人力成本人力成本工作時數單位時間人力成本人力成本 售前諮詢 售後服務 運營設備成本 系統運維 每系統設備數每設備成本每系統運營設備成本每系統設備數每設備成本每系統運營設備成本 A-Voice 2 台 VT AMCP 台 運營資源成本 CISCO Router 3888 接入成本 PSTN 話務交換成本 IP 話務交換成本接入成本 PSTN 話務交換成本 IP 話務交換成本 A-Voice VT AMCP 市場行銷 產品開發市場調研宣傳推廣產品開發市場調研宣傳推廣 A-Voice VT AMCP 總計 IPv IPv

26 24 Voice Tel VoIPV6 通訊平臺維運報表 2007 年 6 月 一 介面數據統計 AWstats 統計 1. 摘要 2. 每日統計圖

27 3. 每日點選明細 25

28 4. 分時統計 26

29 27 5. 客戶主機 IP 6. 網頁瀏覽時間

30 表 1-2 首頁 IPv4 來源 28

31 29 表 1-3 Softphone 下載點擊率 Softphone 下載點擊統計表日期資料統計 0:00 2:00 4:00 6:00 8:00 10:00 12:00 14:00 16:00 18:00 20:00 22:00 日統計 总计

32 表 1-4 WEB 服務器系統負載 30 WEB 服務負載 (CPU%) 統計表 日期 資料統計 0:00 2:00 4:00 6:00 8:00 10:00 12:00 14:00 16:00 18:00 20:00 22:00 日統計 時段統計

33 31 WEB 服務負載 (MEM%) 統計表 日期 資料統計 0:00 2:00 4:00 6:00 8:00 10:00 12:00 14:00 16:00 18:00 20:00 22:00 日統計 時段統計

34 32 二 用戶數據統計表 2-1 在線用戶數 線上用戶統計表日期資料統計 0:00 2:00 4:00 6:00 8:00 10:00 12:00 14:00 16:00 18:00 20:00 22:00 日統計 時段統計

35 33 表 2-2 新註冊用戶數新註冊用戶統計表日期資料統計 合計 1

36 34 表 2-3 通話時長 通話時間統計表 (second) 日期資料統計 IPv4-to-IPv4 IPv4-to-IPv6 IPv6-to-IPv4 IPv6-to-IPv6 每日統計 <12> <1262> <51> <250> <0> <31> <91> <12> <2211> <149> <0> <13> <259> <228> <0> <19> 分類統計的

37 35 表 2-4 通話次數 通話次數統計表 日期 資料統計 IPv4-to-IPv4 IPv4-to-IPv6 IPv6-to-IPv4 IPv6-to-IPv6 每日統計 <77> <22> <41> <20> <0> <1> <37> <12> <101> <8> <0> <1> <7> <0> <37> 分類統計

38 36 表 2-4 Concurrent Call Concurrent Call 日期時間區間 最大值

39 37 三 客服數據表 3-1 品質測試數據 語音品質統計表 日期 資料統計 ( 調查問卷,1 分最差,5 分最好 ) 用戶 1 用戶 2 用戶 3 用戶 4 用戶 5 用戶 6 用戶 7 用戶 8 用戶 9 用戶 10 日平均 平均

40 38 表 3-2 系統維護記錄 伺服器維護日誌 2007 年 平臺編號 IPv6_Sonet_8_1 平臺型號 : IPv6 主要負責人 : yoko 服務狀態 系統數據 時間註冊 平臺內點對點 跨平臺點 Proxy Billing 對點 落地呼叫 WEB CPU% MEM% HD% CPU% MEM SQL 記錄人備註 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 Ok Ok OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄

41 39 四 數據分析表 4-1 運營成本分析對照系統運營成本對照分析表 IPv4 IPv 年 6 月 運營人力成本 工作時數單位時間人力成本人力成本工作時數單位時間人力成本人力成本 售前諮詢 售後服務 系統運維 運營設備成本 每系統設備數每設備成本每系統運營設備成本每系統設備數每設備成本每系統運營設備成本 A-Voice 2 台 VT AMCP 台 CISCO Router 3888 運營資源成本 接入成本 PSTN 話務交換成本 IP 話務交換成本接入成本 PSTN 話務交換成本 IP 話務交換成本 A-Voice VT AMCP 市場行銷 產品開發市場調研宣傳推廣產品開發市場調研宣傳推廣 A-Voice VT AMCP 總計 IPv IPv

42 40 Voice Tel VoIPV6 通訊平臺維運報表 2007 年 7 月 一 介面數據統計 AWstats 統計 1. 摘要 2. 每日統計圖

43 3. 每日點選明細 41

44 42

45 4. 分時統計 43

46 44 5. 客戶主機 IP 6. 網頁瀏覽時間

47 45 表 1-2 首頁 IPv4 來源

48 46 表 1-3 Softphone 下載點擊率 Softphone 下載點擊統計表日期資料統計 0:00 2:00 4:00 6:00 8:00 10:00 12:00 14:00 16:00 18:00 20:00 22:00 日統計 总计

49 表 1-4 WEB 服務器系統負載 47 WEB 服務負載 (CPU%) 統計表 日期 資料統計 0:00 2:00 4:00 6:00 8:00 10:00 12:00 14:00 16:00 18:00 20:00 22:00 日統計 時段統計

50 48 WEB 服務負載 (MEM%) 統計表 日期 資料統計 0:00 2:00 4:00 6:00 8:00 10:00 12:00 14:00 16:00 18:00 20:00 22:00 日統計 時段統計

51 49 二 用戶數據統計表 2-1 在線用戶數 線上用戶統計表 日期資料統計 0:00 2:00 4:00 6:00 8:00 10:00 12:00 14:00 16:00 18:00 20:00 22:00 日統計 時段統計

52 50 表 2-2 新註冊用戶數新註冊用戶統計表日期資料統計 合計 6

53 51 表 2-3 通話時長 通話時間統計表 (second) 日期 資料統計 IPv4-to-IPv4 IPv4-to-IPv6 IPv6-to-IPv4 IPv6-to-IPv6 每日統計 <54> 0 314<54> <36> <36> <179> 0 849<179> <12> 0 12<12> <19> 0 19<19> <38> 0 38<38> <6> 17 23<6> 分類統計的

54 52 表 2-4 通話次數 通話次數統計表 日期 資料統計 IPv4-to-IPv4 IPv4-to-IPv6 IPv6-to-IPv4 IPv6-to-IPv6 每日統計 <4> 0 23<4> <2> 1 40<2> <8> 0 9<8> <9> 0 35<9> <1> 0 1<1> <1> 0 1<1> <1> 0 1<1> <1> 3 4<1> 分類統計

55 53 表 2-4 Concurrent Call Concurrent Call 日期時間區間 最大值

56 54 三 客服數據表 3-1 品質測試數據 語音品質統計表 日期 資料統計 ( 調查問卷,1 分最差,5 分最好 ) 用戶 1 用戶 2 用戶 3 用戶 4 用戶 5 用戶 6 用戶 7 用戶 8 用戶 9 用戶 10 日平均 平均

57 55 表 3-2 系統維護記錄 伺服器維護日誌 2007 年 平臺編號 IPv6_chief_8_1 平臺型號 : IPv6 主要負責人 : yoko 服務狀態 系統數據 Proxy Billing 時間註冊 平臺內點對點 跨平臺點對點 落地呼叫 WEB CPU% MEM% HD% CPU% MEM SQL 記錄人備註 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 Ok Ok OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄

58 56 四 數據分析表 4-1 運營成本分析對照系統運營成本對照分析表 IPv4 IPv 年 7 月 運營人力成本 工作時數單位時間人力成本人力成本工作時數單位時間人力成本人力成本 售前諮詢 售後服務 系統運維 運營設備成本 每系統設備數每設備成本每系統運營設備成本每系統設備數每設備成本每系統運營設備成本 A-Voice 2 台 VT AMCP 台 CISCO Router 3888 運營資源成本 接入成本 PSTN 話務交換成本 IP 話務交換成本接入成本 PSTN 話務交換成本 IP 話務交換成本 A-Voice VT AMCP 市場行銷 產品開發市場調研宣傳推廣產品開發市場調研宣傳推廣 A-Voice VT AMCP 總計 IPv IPv

59 57 Voice Tel VoIPV6 通訊平臺維運報表 2007 年 8 月 一 介面數據統計 AWstats 統計 1. 摘要 2. 每日統計圖

60 3. 每日點選明細 58

61 4. 分時統計 59

62 60 5. 客戶主機 IP 6. 網頁瀏覽時間

63 表 1-2 首頁 IPv4 來源 61

64 62 表 1-3 Softphone 下載點擊率 Softphone 下載點擊統計表 日期資料統計 0:00 2:00 4:00 6:00 8:00 10:00 12:00 14:00 16:00 18:00 20:00 22:00 日統計 总计

65 表 1-4 WEB 服務器系統負載 63 WEB 服務負載 (CPU%) 統計表 日期 資料統計 0:00 2:00 4:00 6:00 8:00 10:00 12:00 14:00 16:00 18:00 20:00 22:00 日統計 時段統計

66 64 WEB 服務負載 (MEM%) 統計表 日期 資料統計 0:00 2:00 4:00 6:00 8:00 10:00 12:00 14:00 16:00 18:00 20:00 22:00 日統計 時段統計

67 65 二 用戶數據統計表 2-1 在線用戶數 線上用戶統計表 日期 資料統計 0:00 2:00 4:00 6:00 8:00 10:00 12:00 14:00 16:00 18:00 20:00 22:00 日統計 時段統計

68 66 表 2-2 新註冊用戶數新註冊用戶統計表日期資料統計 合計 0

69 67 表 2-3 通話時長 通話時間統計表 (second) 日期 資料統計 IPv4-to-IPv4 IPv4-to-IPv6 IPv6-to-IPv4 IPv6-to-IPv6 每日統計 <3923> <246> <1817> <100> <62> <598> <1982> <74> <52> 分類統計的 <8854>

70 68 表 2-4 通話次數 通話次數統計表 日期 資料統計 IPv4-to-IPv4 IPv4-to-IPv6 IPv6-to-IPv4 IPv6-to-IPv6 每日統計 <16> <18> <7> <14> <3> <1> <22> <36> <9> <3> 分類統計 <129>

71 69 表 2-4 Concurrent Call Concurrent Call 日期時間區間 最大值

72 70 三 客服數據表 3-1 品質測試數據 語音品質統計表 日期 資料統計 ( 調查問卷,1 分最差,5 分最好 ) 用戶 1 用戶 2 用戶 3 用戶 4 用戶 5 用戶 6 用戶 7 用戶 8 用戶 9 用戶 10 日平均 平均

73 71 表 3-2 系統維護記錄 伺服器維護日誌 2007 年 平臺編號 IPv6_chief_8_1 平臺型號 : IPv6 主要負責人 : yoko 服務狀態 系統數據 時間 註冊平臺內點對點跨平臺點對點 落地呼叫 WEB Proxy Billing CPU% MEM% HD% CPU% MEM SQL OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK yoko 記錄人 備註 radius 异常跳出 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 Ok Ok OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄 OK OK OK OK OK yoko 狀態記錄

74 72 四 數據分析表 4-1 運營成本分析對照系統運營成本對照分析表 IPv4 IPv 年 8 月 運營人力成本 工作時數單位時間人力成本人力成本工作時數單位時間人力成本人力成本 售前諮詢 售後服務 系統運維 運營設備成本 每系統設備數每設備成本每系統運營設備成本每系統設備數每設備成本每系統運營設備成本 A-Voice 2 台 VT AMCP 台 CISCO Router 3888 運營資源成本 接入成本 PSTN 話務交換成本 IP 話務交換成本接入成本 PSTN 話務交換成本 IP 話務交換成本 A-Voice VT AMCP 市場行銷 產品開發市場調研宣傳推廣產品開發市場調研宣傳推廣 A-Voice VT AMCP 總計 IPv IPv

75 五 : IPv6 系統目前冊號碼 791, 資料來源 :subscriber 系統資庫 73

76 附件二 論文與演說發表 標準測試分項計畫 協助交通部及 TWNIC 協辦 IPv6 教育訓練 ( 公務人員專班 ) 標準測試分組上課教材 ( 資料太 多, 僅附上標準測試投影片, 以供參考 ) 74

77 75

78 76

79 77

80 78

81 79

82 80

83 81

84 82

85 83

86 84

87 85

88 86

89 A semantic service discovery approach for ubiquitous computing Reen-Cheng Wang Yao-Chung Chang Ruay-Shiung Chang Abstract Services in the ubiquitous computing are heterogeneous in nature. To be pervasive, these services should be defined in terms of their functionality and capabilities rather than the meaningless Universally Unique IDentifiers (UUIDs) or types of services. With that, clients can access the proper service based on semantic requests, rather then a pre-configured profile. In this paper, we study the requirements for semantic query to be feasible in service discovery processes. Current discovery protocols and the concept of semantics are brought together to construct a framework to realize the semantic service discovery for ubiquitous computing. Many issues are discussed in relation to service discovery topologies, ontology languages, and semantic query languages. Keywords Semantics Service discovery Ubiquitous computing Introduction The usage of wireless-enabled handheld devices has seen an exponential growth in the past few years. It has facilitated the development of ubiquitous computing infrastructures for service provisioning. Mobile devices want to access various services from ubiquitous resources. Moreover, users have the expectation to have contextaware services (Bellavista, Corradi, Montanari, and Stefanelli, 2003). However, without a through knowledge at the client side, it is still hard to retrieve and interact with the resources in such a scenario. In the last decade, several discovery protocols have Reen-Cheng Wang Ruay-Shiung Chang Dept. of Computer Science and Information Engineering, National Dong Hwa University, Hualien, Taiwan, R.O.C. {rcwang, rschang}@mail.ndhu.edu.tw Yao-Chung Chang Dept. of Computer Science & Information Engineering, National Taitung University, Taitung, Taiwan, R.O.C. ycc@nttu.edu.tw been investigated such as Bluetooth Service Discovery Protocol (SDP) (Bluetooth SIG, 2004), Jini (Jini Community, 2006), Salutation (Salutation Consortium, 1999), Service Location Protocol (SLP) (Guttman, Perkins, Veizades, and Day, 1999), Universal Plug and Play (UPnP) Simple Service Discovery Protocol (SSDP) (UPnP Forum, 2000), and Zero Configuration Networking (Zeroconf) (Steinberg and Cheshire, 2005). All of them use similar matching techniques, which exploit patterns such as ID, UUID, types, or names. Other discovery protocols that have emerged within the Web Services research community, namely Electronic Business using extensible Markup Language (ebxml) (OASIS/ebXML Registry Technical Committee, 2001) and Universal Description, Discovery and Integration (UDDI) (Clement, Hately, Riegen, and Rogers, 2004), rely on the exact matching of XML-based keywords, generally defined within fixed, standard taxonomies. However, the use of exact matching of patterns or keywords does not represent a suitable discovery solution for ubiquitous computing. For example, if a user is looking for a printer service, services which are named laserprinter or lpr would not match with the request. The lacks of the flexibility make the discovery in ubiquitous computing difficult, especially when users are moving around heterogeneous environments. It is quite difficult for them to obtain all the knowledge of services nearby. In order to overcome this problem, the adoption of semantic languages to describe and retrieve resources will be a good solution. The benefit lies in the fact that they permit explicit context representation at a high level of abstraction. To our knowledge, only few studies have addressed the problem of semantically enhancing resource discovery for ubiquitous computing (Avancha, Joshi, and Finin, 2002; Chakraborty, Perich, Avancha, and Joshi, 2001; Toninelli, Corradi, and Montanari, 2005) and they are suitable only for specific architectures. In Internet, some semantic-based techniques (Dogac, Kabak, and Laleci, 2004; Paolucci, Kawamura, Payne, and Sycara, 2002) are emerged in the field of Web Services. As the reasons argued in (Edwards, 2006), Web Services based protocols, such as ebxml and UDDI, provide no 87

90 automatic mechanism for adding or removing resources in the directory. They clearly are not true service discovery systems. Thus we will not discuss these kinds of approaches. In this paper, we discuss the issues of a semantic service discovery system design for ubiquitous computing. This system enables users to express their service requirements at a higher level of abstraction, and performs service discovery based on the semantic matching. We discuss the design criteria of existing topologies, ontology languages, query languages, and their interactions. Each design issue is elaborated with some suggestions. The rest of the paper is structured as follows. Section "Service discovery infrastructures" provides an introduction of current service discovery systems. Section "Ontology languages" reviews existing ontology languages for semantic services. Section "A design approaches for semantic service discovery" describes the architecture we proposed, and discusses the issues including topologies, ontology languages, and query languages. Finally, the paper is concluded in Section "Conclusions". Service discovery infrastructures To implement a semantic discovery system, we first examine the existing service discovery protocols. Since there are many of them, our examination will only present some of the most important characteristics of the protocols. Others can be found in several surveys (Edwards, 2006; Helal, 2002; Richard, 2002). Bluetooth Bluetooth is a short range wireless technology. It defines a non-ip-based discovery protocol, SDP. SDP is based on UUIDs and with one or more standardized profiles, which define the operations available to clients. A client sends an inquiry message to initiate the discovery. Corresponding Bluetooth devices in the discoverable state respond with their UUID. After a device has been discovered, a Protocol Descriptor List in the SDP is consulted to find out which protocols can be used to initiate contact with the device. So, SDP uses only UUIDs and attributes that the service specification have adopted. Avancha et al. (Avancha, Joshi, and Finin, 2002) has proposed an extension of Bluetooth SDP with semantic descriptions written in Resource Description Framework (RDF) or DARPA Agent Markup Language (DAML) (DAML, 2006) + Ontology Inference Layer (OIL) (OIL, 2000). But it is not a peer-to-peer concept which is inapplicable in real ubiquitous environments. Jini Based on the Java language, Jini is a platform independence protocol. It can provide service discovery without shared knowledge between services and clients. A service delivers mobile code directly to a client. A collection of Jini services forms a Jini federation. Jini Lookup Service (JLS) is in charge of maintaining the dynamic information about the available services in the Jini federation. Every service must discover one or more JLS before it can enter a federation. When a service wishes to make its presence known to the network, it will register itself by uploading a proxy object to a JLS. This proxy can be used by the clients to contact the service. When searching for a service, the searcher sends out a multicast User Datagram Protocol (UDP) request. After receiving the results from JLS, the searcher can download the proxy objects and run them locally in order to establish contacts with the desired service. Jini s search mechanisms reflect Java s ubiquitous use. Clients can search for services by ID, proxy or attribute Java language types, or attribute contents. JLS is necessary for the discovery to work. Salutation Salutation is a platform-independent service discovery and session management protocol proposed by the Salutation Consortium. The goal of Salutation is to solve the problem of service discovery and utilization among various appliances in wide areas. The architecture is based on service brokers called Salutation Managers (SLMs) in the network. SLMs use Transport Managers (TMs) to achieve network independence and connect to remote SLMs. A device that wishes to provide a service registers itself with an SLM, or provides its own SLM and makes it available on the network. The SLM can classify the services based on their Functional Units (FU), and the SLM can be discovered by both unicast and broadcast method. To discover a service, a request is sent to an SLM, which tries to match the request with the FUs in the SLM directory. The SLMs can exchange information among themselves, creating a topology of the network, or propagate requests to other SLMs. Service Location Protocol The SLP, which is defined by Internet Engineering Task Force (IETF), focuses on IP-based networks, and relies heavily on Transmission Control Protocol (TCP) and UDP to determine existence, location and settings of the services offered. It is a language independent protocol for automatic resource discovery on IP networks utilizing an agent-oriented infrastructure. There are three types of agent in SLP: User agent (UA), Service agent (SA) and 88

91 Directory agent (DA). The UA is responsible for discovering available DA, and acquiring service handles on behalf of users service request. The SA is in charge of advertising the service handles to DA. DA is responsible for collecting service handles and maintaining the directory of advertised services. The system can operate with or without DAs. When operating without a DA, the UA will send a multicast request to directly discover services, and will receive unicast replies. When there is a DA present, clients and services will direct all their registration and query traffic to it. Service descriptions in SLP are Service Uniform Resource Locators (srvurls) that categorize service types, such as srvurl = srvurl srvtype srvurl = "service:"<srvtype>"://"<addrspec> srvtype = "service:<abstract-type>:<concrete-type>" Services publish their existence through service registration messages containing their service types, service URL, and attributes. Clients can search on the basis of the service s types or attributes. In response to a service request, they receive a reply containing the URLs of matching services. Universal Plug and Play UPnP extends the Microsoft PnP peripheral model to support service discovery in network. UPnP uses SSDP for discovery services over IP networks, which can operate with or without a lookup service. In addition, SSDP operates on the top of HTTP over both unicast and multicast UDP. When entering a network, devices broadcast an advertisement containing its type, unique identifier, and an URL. If a lookup service is present, it can record this advertisement to be subsequently used to satisfy clients requests. Additionally, each node on the network may also observe this advertisement. When a client wants to discover a service, it can either contact the service directly through the URL that is stored within the service advertisement, or it can broadcast a request for the desired type of device. The client retrieves device and service descriptions of the devices found, using the URLs embedded in the advertisements. These descriptions are based on templates defined by the UPnP forum. SSDP device descriptions can also have an URL hyperlink to an HTML presentation page, which can be used to control the device or service and view information about it. SSDP identifies resources using uniform resource identifiers and unique IDs which reflect UPnP s Web-centric focus. Zero Configuration Networking Zeroconf, also known by Apple's trade name of Bonjour, and previously as Rendezvous, is based on work by the IETF s Zeroconf working group in It is a set of technologies that allow two or more computers to communicate with each other without any external configuration. It combines multicast Domain Name System (mdns) (Cheshire and Krochmal, ) with Domain Name System service discovery (DNS-SD) (Cheshire and Krochmal, 2006) to leverage existing Internet protocols. mdns is a special Domain Name System (DNS) service for local network without conventional DNS server. In Zeroconf, mdns piggybacks DNS by defining a new top-level domain,.local, and presumes that names ending in.local. are meaningful only on the local link and are thus analogous to link-local IP addresses. mdns sends any DNS query for a name ending in.local. to a special multicast address. Hosts on the local link that can resolve the name respond with their addresses. DNS-SD is largely a set of naming conventions describing how services will be represented in DNS records. It defines no new operations and no new DNS record types. It s fully compatible with, but doesn t require, mdns. Clients use DNS-SD by issuing requests for DNS PoinTeR (PTR) records, indicating the service types they wish to find. DNS-SD names service types using the format _type._protocol.domain. When DNS-SD is working with mdns, clients can use the.local. domain as well, allowing service discovery to occur without managed DNS services. The returned PTR records contain service instance name. To resolve a particular service instance name, a client issues a query for DNS SerViCe (SVC) records for that name. The records returned by the query contain the service s host and port number. DNS-SD considers the human-readable service instance names to be the services canonical names. This naming approach presents a subtle difference between DNS-SD and many of the other discovery systems, which use globally unique service IDs to define services. Ontology languages To implement a semantic service, no matter it is a semantic web or semantic service discovery, a proper ontology language is needed. Several ontology languages have been developed during the last few years. We can classify them into two categories: XHTML-based and XML-based. XHTML-based ontology languages are easy to implement. Simple HTML Ontology Extension (SHOE) (Heflin, Hendler, and Luke, 1999) and Microformats (Khare, 2006) are two of them. XHTML-based ontology languages SHOE, developed at the University of Maryland, was created as an XHTML framework incorporating machinereadable semantic knowledge. The agents in the SHOE 89

92 architecture gather meaningful information from Web pages, improving search mechanisms, and knowledge gathering. This process consists of three phases: defining ontology, annotating HTML pages with ontological information, and having an agent semantically retrieving information by searching all of the existing pages and keeping information updated. The microformat is another approach to encoding semi-structured information in ordinary XHTML. It is a simple convention for embedding semantic markup for a specific problem domain in human-readable documents. Clever application of existing XHTML elements and its powerful class attribute system can make it easier to describe common types of semi-structured information. Although these XHTML-based architectures are simple, the tags used in these approaches are still human readable. It requires a translation before agent can understand the metadata. It is not a good design choice for machineprocessed semantic service discovery. XML-based ontology languages XML-based ontology languages are more complicated but can provide better machine-readable support. XMLbased Ontology Exchange Language (XOL) (Karp, Chaudhri, and Thomere, 1999), Resource Description Framework (RDF) (Beckett, 2004) and RDF Schema (RDFS) (Brickley and Guha, 2004), and Web Ontology Language (OWL) (McGuinness and Harmelen, 2004) are in this category. XOL was designed by the US bioinformatics community for the exchange of ontology definitions among a heterogeneous set of software systems. Its development was inspired by Ontolingua (Farquhar, Fikes, and Rice, 1997) and merged the high expressiveness of Open Knowledge Based Connectivity Lite protocol (Chaudhri et al., 1998). There are no automatic tools designed for XOL ontology development. Users have to use an XML editor to write XOL files. RDF and RDFS, developed by the World Wide Web Consortium (W3C) for describing Web resources, allow the specification of the semantics of data based on XML. The RDF data model is equivalent to the semantic networks formalism. Its abstract syntax is a set of triples which contains three components written in the order of subject, predicate, and object. The subject is an RDF Uniform Resource Identifier (URI) reference or a blank node. The predicate (also known as the property) is an RDF URI reference. And the object can be RDF URI reference, a literal or a blank node. A set of RDF triples can be used to construct an RDF graph using the semantic relations. The RDFS provides mechanisms for defining the relationships between properties and resources. RDF/RDFS is widely used as a representation format in many tools and projects, such as Amaya (Amaya, 2007), Table 1. Comparisons of discovery protocols Protocol Topology Matching Key Bluetooth SDP P2P Type or Attributes (UUID) Jini Hybrid Type, ID, or Attributes Salutation P2P or Directory Type or Attributes SLP P2P or Type or Directory Attributes (LDAPv3) UPnP SSDP P2P or Directory Type or ID Zeroconf P2P Type Mozilla (MozillaRdf, 2006), protégé (Protege, 2007), OntoStudio (OntoStudio, 2007), and so on. OWL is a revision of the DAML + OIL web ontology language. It is a W3C recommended ontology language. Instead of presenting information to humans such as HTML, it is designed to be used by applications that need to process the content of information. OWL facilitates greater machine interpretability of Web content than that supported by XML or RDF by providing additional vocabulary along with a formal semantics. OWL is built on RDF and RDFS. OilEd (OilEd, 2006), OntoEdit (OntoEdit, 2002), and Protégé-OWL (Protege-OWL, 2007) are tools that can author OWL ontologies. There are other languages that have been used for building ontologies. Gomez-Perez and Corcho (Gomez- Perez and Corcho, 2002) have described some of them with analysis and comparisons. A design approaches for semantic service discovery The six service discovery technologies we have discussed above are representative of some current approaches. Some attributes that related to the following semantic discussions are summarized in Table 1. And we have also reviewed six kinds of ontology languages, which are kernels of semantic technologies, in the previous section. In this section, we will pay more attentions to issues related to semantic service discovery protocol design. While P2P is the ultimate goal of ubiquitous computing, it is a great challenge for semantic service discovery. Although some researches have constructed models for semantic P2P computing (Cai and Frank, 2004; Nejdl et al., 2003), the heavy overhead is not suitable for light protocols like service discovery. Thus, we propose a centralized agent model as shown in Fig 1. The scenario is a user who wants to print out a photo in his digital camera within a ubiquitous environment. There are four printers nearby, which are named HP Laserjet, Canon BubbleJet, Epson Stylus Photo, and Epson AcuLaser Color. The digital camera must use semantic service discovery to find a suitable Photo Printer without 90

93 environment knowledge. Because the printers are made from different manufactures, their ontology servers are at different locations on the Internet, which are managed by their own companies. The steps in Fig. 1 can be categories into two major phases: - Phase 1: Service registration (1.1) All the services should exchange their ontologies with local semantic service discovery agents. (1.2) Based on the exchanged ontologies from services, the agent will retrieve the global ontologies from Internet if necessary. - Phase 2: User requesting and accessing a service (2.1) User issues a request to a semantic service discovery agent to obtain a semantic service. (2.2) Semantic service discovery agent will parse the query language, match the ontology database, and return suitable or the optimal answers to the user. (2.3) User selects one from the answers then asks for the service. (2.4) The service responds and the discovery process is finished. The issues in service registration The first phase focuses on service registration. There are two questions. First, which existing service discovery architectures are applicable for implementing semantic functions? Second, which ontology languages are appropriated to exchange semantic service discovery information? Subjects of service discovery protocols Table 2. Issues of service discovery protocols in service registration Protocol Bluetooth SDP Jini Salutation SLP UPnP SSDP Zeroconf Centralized Controller N/A Jini Lookup Service Salutation Managers Directory agent Control Point N/A Event Notification Not Supported Remote Events Availability Checking (periodic and automatic) SLP extension for event notification Service publishes event when state variable changes Not Supported Semantic Design Requirement Not supported OK Partial OK OK Not Supported be treated as a specific service type, for instance _semanticagent._http.local. in Zeroconf. All the service discovery protocols undoubtedly can lookup a specific service. The topology problem is our first issue. Because most user devices in ubiquitous computing lack computational power for processing the complicated semantic searches, such as the digital camera in Fig.1, they always need someone else to collect, analyze and retrieve ontology from the local or global network. Thus, using smart agents to mediate service discovery requests is necessary. The smart agent can be built on a home gateway, a media center machine, a set-top-box, etc. Besides smart agent devices, the service discovery protocol must support the architecture. From the six discovery protocols we surveyed, the Bluetooth SDP and Zeroconf can not support centralized controllers. Others can fulfill the requirement with their special components: Jini has JLS component. Salutation has SLM node. SLP is with DA. And UPnP can work with control points. Of the examined technologies, Jini, Salutation, SLP, and UPnP meet this goal of agent buildup. The issue of how a service can find an agent for registration is not a problem. The agent can Fig 1. Semantic service discovery framework 91

94 Table 3. Ontology languages for constructing semantic service in ubiquitous computing Category Ontology Languages Ontology Information Notes XHTML based XML based Simple HTML Ontology Extension (SHOE) annotation HTML pages human readable, require a translation before agent can understand the metadata For Ubiquitous Computing Unsuitable Microformats class attribute system Unsuitable XML-based Ontology Exchange Language (XOL) Resource Description Framework (RDF) and RDF Schema (RDFS) Web Ontology Language (OWL) Open Knowledge Based Connectivity Lite protocol RDF URI reference XML or RDF Build tools: XML editor Build tools: Amaya, Mozilla, protégé, OntoStudio Build tools: OilEd, OntoEdit, Protégé- OWL OK Good Good The second issue is the event notification ability in each protocol. An agent should keep track of the current status of services. For instance, while the smart agent matches the require service for the user, it has better to know if a printer is ready, or out of paper. Bluetooth SDP and Zeroconf can not support this kind of mechanism. Jini can use its remote events to satisfy the requirement. Salutation can not support the event notification from the service side. However, it has an automatic checking function at the smart agent side, which can be used to probe the status of services. Although it is non-real-time, it is a workable solution. SLP supports event notification. And UPnP can publishes event when a state variable changes. Of the examined technologies, Jini, SLP, and UPnP meet this requirement. Salutation can work but not so well. The two issues are summarized in Table 2. Subjects of ontology languages The third issue is the selection of ontology languages. From the ontology languages we surveyed, all of them can achieve the semantic service discovery requirement. But from the perspective of ubiquitous computing, a generalized globally model is the best choice. Take the Fig. 1 for example. If the three ontology servers (HP, Epson, and Canon) use proprietary or non-standard ontology languages differently, the smart agent must implement different kinds of query mechanisms for matching the semantics. It will cause another compatible issue. Thus, we would rather adopt from the Semantic Web standard such as RDF/RDFS, and OWL. They are better ontology languages for semantic service discovery in realistic deployment. The ontology languages for ubiquitous computing are summarized in Table 3. The issues in phase (1.2) are the same as problems in Semantic Web. Oberle et al. have discussed a lot in their work (Oberle, Volz, Staab, and Motik, 2004) and we will not detail them here. The issues in user request and access a service The second phase is the behavior from users end. The problem is: which service discovery architectures are applicable for users requesting and accessing services with semantic mechanics? And which query languages are appropriated to be used in the semantic service discovery? Subjects of flexibility The major issue in users service request is the flexibility. If the client can only send out specific searching parameters, such as UUID, the semantic search will become useless. As the scenario in Fig. 1, the user needs to specify a baseline of color, 600dpi or above, and 4*6 size for its printing service to make a quality photo output. If the discovery service only supports UUID or type, the digital camera must have the knowledge of all UUID devices for picking up a suitable one. It is surely impracticable for ubiquitous computing. Look inside the surveyed service discovery protocols, Bluetooth SDP uses globally reserved unique identifiers for predefined service types. Jini describes services from a programming perspective. Salutation can carry semantic information with its Functional Units. SLP can be extended from the communication with DAs. UPnP uses XML format, which allows more information to be described. Zeroconf can only query via type. As 92

95 Table 4. Issues of service discovery protocols in semantic search request Flexibility Protocol Service Description Requiremen t Bluetooth SDP UUID Jini Programming perspective OK Salutation Functional unit OK SLP UPnP SSDP XML Zeroconf Extended from the communication with DAs Type summarized in Table 4, Jini, Salutation, SLP, and UPnP meet this goal of flexibility. Subjects of query languages Not supported OK OK Not supported The second issue in users service request is the selection of query languages. In phase (2.1) and (2.2), users will issue a request to the agent and wait for the response. In these phases, the query language will play an important role between user and agent. Another design trail is that the user sends out a simple text request to the agent and the agent queries the database using the query language. No matter which kind is used, the function of query language will affect the response a lot. In the previous section, we have chosen RDF/RDFS and OWL as our primary target. The query languages of these architectures should be taken into consideration. Because OWL query languages are still an open research issue, only very few initiative can be referenced (Richard, Patrick, and Ian, 2005; Pan et al., 2004). We would like to focus on RDF query languages here. From the existing concept of relational database management system, most of the RDF query languages today are relational-based, such as SPARQL (its name is a recursive acronym that stands for SPARQL Protocol and RDF Query Language) (Prud'hommeaux and Seaborne, 2006), RDF Query Language (RQL) (Karvounarakis et al, 2002), and TRIPLE (Decker et al., 2005). SPARQL is the descendant of SquishQL (Miller, Seaborne, and Reggiori, 2002) and RDF Data Query Language (RDQL) (Seaborne, 2004). It is one of the RDF querying candidates at the W3C. With sets of triples of subjects, predicates and objects, SPARQL queries for RDF data amounts to matching graph patterns. It supports four different query-result forms, which vary in the type of results returned. The results are sets of mappings from the variables occurring within the query. RQL (and also its successors Sesame RDF Query Language (SeRQL) (Broeskstra and Kampman, 2003) and easy RDF Query Language (erql) (Wleklinski, 2004)) provides the ability of both data and schema querying. It supports generalized path expressions featuring variables on both nodes and edges of the RDF graph. RQL is far more expressive than most other RDF query languages. However, it deviates slightly from the standard data model for RDF and RDFS. For example every property must have exactly one domain and range specified. TRIPLE is a rule-based query, inference, and transformation language for RDF. Its syntax is close to F- Logic (Kifer, Lausen, and Wu, 1995), which is convenient for querying semi-structured data. However, TRIPLE does not distinguish between rules and queries where the results are bindings of free variables in the query. Since the output is a table of variables and possible bindings, TRIPLE does not fulfill the closure property. Notation3 (N3) (Berners-Lee, Connolly, and Hawke, 2003) provides a text-based syntax for RDF and conforms to the RDF data model. It allows users to define rules which can be used for the purpose of querying. Although N3 has many features such as orthogonality, closure and safety, it is cumbersome in real work. Algae (Prud'hommeaux, 2004) is a reactive rule-based query language based on algernon and then algae. It was developed as part of the W3C Annotea project. It adopted N3 syntax for queries and assertions. Queries select a result set with a query string and collect the results with a collect string. Answers to Algae queries are bindings for query variables as well as triples from the RDF graph as proofs of the answer. Versa (Ogbuji, 2005; Olson and Ogbuji, 2002) takes an interesting navigational access approach. It has constructs for a forward traversal of one or more RDF properties, which have the format subjects - predicates - > boolean. The subjects are used to evaluate statements whose subject value is equivalent to any of the resources and the result is converted to a list. With respect to the result list, the predicates then be examined and excluded. Finally, the boolean is evaluated with respect to the objects of each statements. These expressions return a list of all objects of matching triples. Within these matching rules, Versa converts a single resource or literal to a list. The fact that a traversal expression is again a list of expression allows us to nest expressions in order to create more complex queries. Versa offers some support for rules since it allows traversing predicates transitively. 93

96 Table 5. Summary of semantic query languages and their problems Query Type Features Problems Language SPARQL (SquishQL, RDQL) RQL (SeRQL, erql) TRIPLE Notation3 Algae (Algernon) Versa Relational-based W3C candidates Relational-based Relational-based Rule-based Text-based Reactive rule-based Navigational access [subjects, predicates, objects] matching graph patterns four types of query-result results are sets of mappings both data and schema querying path expressions on both nodes and edges of the graph rule-based query, inference, and transformation language output is a table of variables and possible bindings users to define rules orthogonality, closure and safety adopted N3 syntax query string <=binding=>collect string (subjects - predicates -> boolean) nest expressions OK Deviate from RDF/ RDFS standard Fail the closure property Cumbersome in real work OK OK The RDF query languages introduced are summarized in Table 5. What is really interesting is which are suitable for service discovery? Environments in the ubiquitous computing are heterogeneous. From this point of view, rule-based query languages are useful in semantic service discovery. Take the scenario in Fig. 1 for example. Assume the user is an assistant engineer in a company, who is only allowed to use inkjet printers in the office. Only senior engineers and managers are permitted to use laser printers. When the user uses the digital camera to operate the print function, the camera will ask for print service in service discovery. All of the Service A(HP Laserjet), Service B(Epson AcuLaser Color), Service C(Epson Stylus Photo) and Service D(Canon BubbleJet) and will be the candidates because of their semantic meaning. After filtering out the criteria described in Section Subjects of flexibility, Service B, C, and D are selected. If there is a RFID tag in the user s identification card, which can provide the information about assistant engineer to the discovery agent, the agent can invoke identity rule in service discovery process. Thus, the camera will get the reply of Epson Stylus Photo@C and Canon BubbleJet@D for its allowable choice. In the above example, services are the same, and queries are the same. But the response can be different based on different rules. From this point of view, TRIPLE, N3, Algae, and Versa provide this kind of ability. Another constrain is that service discovery should be simple and fast. Too complicated query languages such as N3 may incur too much overhead. The proofs of the answers are the benefit which Algae provides but it is unnecessary for ubiquitous service discovery in most cases. TRIPLE has the problem of non-closure property, which is not good for agents. Thus, Versa is the best choice in these query languages. Phase (2.3) and (2.4) are the basic functions of every service discovery protocols. They should depend on the specifics of each service. Conclusions Undoubtedly, services in the ubiquitous computing are heterogeneous. They should be defined in terms of their functionality and capabilities. These functionality and capability descriptions should be used by the clients to discover the services. In this paper, we have surveyed six kinds of current service discovery protocol for ubiquitous computing, and propose a framework of semantic service discovery. In this framework, we have discussed the issues of service registration, and its reciprocal work with current ontology languages. From users perspective, the issues of query and query language selection have also been discussed. Although this paper only considers a subset of the service discovery protocols, ontology languages, and RDF query languages proposed so far, it makes quite clear that the research community has not yet settled on a dominant paradigm for discovering semantic service in ubiquitous computing. This is the first step of semantic service discovery system design. We hope that with the implementations of ubiquitous computing increasing exponentially, semantic service discovery can lead us to a more convenient way for pervasive accessibility. 94

97 Acknowledgements This research is supported in part by the ROC NSC under contract numbers NSC E , NSC E , and Taiwan NICI IPv6 Steering Committee. References Amaya (2007), URL: Avancha, S., Joshi, A., and Finin, T., (2002). Enhancing the Bluetooth Service Discovery Protocol. IEEE Computer, 35(6), Beckett, D. (2004), RDF/XML Syntax Specification, W3C Recommendation. Bellavista, P., Corradi, A., Montanari, R., and Stefanelli, C. (2003). Context-Aware Middleware for Resource Management in the Wireless Internet. IEEE Transaction on Software Engineering, 29(12), Berners-Lee, T., Connolly, D., and Hawke, S. (2003). Semantic Web Tutorial Using N3. Tutorial at the 12 th International WWW Conference, Budapest, Hungary. Bluetooth SIG (2004). Bluetooth Specification Version EDR. Brickley, D., and Guha, R. V. (2004). RDF Vocabulary Description Language 1.0: RDF Schema. W3C Recommendation. Broeskstra, J. and Kampman, A. (2003). SeRQL: A Second Generation RDF Query Language. SWAD-Europe Workshop on Semantic Web Storage and Retrieval, Amsterdam, Netherlands. Cai, M. and Frank, M, (2004). RDFPeers: A Scalable Distributed RDF Repository based on A Structured Peer-to-Peer Network. Proceeding of the 13 th International WWW Conference, New York, USA Chakraborty, D., Perich, F., Avancha, S., and Joshi, A. (2001). DReggie: Semantic Service Discovery for M-Commerce Applications. Workshop on Reliable and Secure Applications in Mobile Environment. Chaudhri, V. K., Farquhar, A., Fikes, R., Karp, P. D., and Rice, J. P. (1998) Open Knowledge Base Connectivity 2.0. Technical Report KSL-98-06, Knowledge System Laboratory, Stanford University. Cheshire, S., and Krochmal, M. (2006). DNS-Based Service Discovery. IETF Internet Draft draft-cheshire-dnsext-dns-sd- 04.txt (work in progress). Cheshire, S., and Krochmal, M. (2006-2). Multicast DNS. IETF Internet Draft draft-cheshire-dnsext-multicastdns-06.txt (work in progress). Clement, L., Hately, A., Riegen, C. V., and Rogers, T. (2004). UDDI Version 3.0.2(draft). UDDI Spec Technical Committee. DAML (2006), URL: Decker, S., Sintek, M., Billig, A., Henze, N., Dolog, P., Nejdl, W., Harth, A., Leicher, A., Busse, S., Ambite, J. L., Weathers, M., Neumann, G., and Zdun, U. (2005). TRIPLE - an RDF Rule Language with Context and Use Cases. W3C Workshop on Rule Languages for Interoperability, Washington, D.C., USA. Dogac, A., Kabak, Y., and Laleci, G.B. (2004). Enriching ebxml Registries with OWL Ontologies for Efficient Service Discovery. Proceeding of 14th International Workshop on Research Issues on Data Engineering, Edwards, W. K. (2006). Discovery Systems in Ubiquitous Computing. IEEE Pervasive Computing, 5(2), Farquhar, A., Fikes, R., and Rice, J. (1997). The Ontolingua Server: a tool for collaborative ontology construction. International Journal of Human-Computer Studies, 46(6), Gómez-Pérez, A., and Corcho, O. (2002). Ontology Languages for the Semantic Web. IEEE Intelligent Systems, 17(1), Guttman, E., Perkins, C., Veizades, J., and Day, M. (1999). Service Location Protocol Version 2. IETF RFC Heflin, J., Hendler, J., and Luke, S. (1999). SHOE: A Knowledge Representation Language for Internet Applications. Technical Report CS-TR-4078, University of Maryland, College Park. Helal, S. (2002). Standards for Service Discovery and Delivery. IEEE Pervasive Computing, 1, Jini Community (2006). Jini Discovery and Join Specification Version 3.0. Karp, R., Chaudhri, V., and Thomere, J. (1999). XOL: An XML- Based Ontology Exchange Language (version 0.4). URL: Karvounarakis, G., Alexaki, S., Christophides, V., Plexousakis, D., and Scholl, M. (2002). RQL: A Declarative Query Language for RDF. The 11th International WWW Conference, Honolulu, Hawaii, USA. Khare, R, (2006). Microformats: the next (small) thing on the semantic Web?. IEEE Internet Computing, 10(1), Kifer, M., Lausen, G., and Wu, J. (1995). Logical foundations of object oriented and frame-based languages. Journal of the ACM, 42(4), McGuinness, D. L. and Harmelen, F. V. (2004). OWL Web Ontology Language Overview. W3C Recommendation. Miller, L., Seaborne, A., and Reggiori, A. (2002). Three Implementations of SquishQL, a Simple RDF Query Language. Proceeding of thee First International Conference on Semantic Web, MozillaRdf (2006), URL: Nejdl, W., Wolpers, M., Siberski, W., Schmitz, C., Schlosser, M., Brunkhorst, I., and Loser, A. (2003). Super-peer-based routing and clustering strategies for RDF-based peer-to-peer networks. Proceeding of the 12th International. WWW Conference, Budapest, Hungary, OASIS/ebXML Registry Technical Committee (2001). OASIS/ebXML Registry Information Model v2.0. Oberle, D., Volz, R., Staab, S., and Motik, B. (2004). An Extensible Ontology Software Environment. Handbook on Ontologies, , Springer. Ogbuji, C. (2005). Versa: Path-Based RDF Query Language. O'Reilly XML.com, URL: OIL (2000), URL: OilEd (2006), URL: Olson, M. and Ogbuji, U. (2002). Versa Specification. URL: OntoEdit (2002), URL: OntoStudio (2007), URL: Pan, J. Z., Franconi, E., Tessaris, S., Glimm, B., Siberski, W., Stamou, G., Tzouvaras, V., Horrocks, I., Li, L., and Wache, H. (2004) Report on Query Language Design and Standardization. Technical report, The Knowledge Web project. Paolucci, M., Kawamura, T., Payne, T., and Sycara, K., (2002). Importing the Semantic Web in UDDI, Web Services. E- Business and Semantic Web Workshop, Springer Verlag, Toronto, Ontario, Canada. Protégé (2007), URL : Protégé-OWL (2007), URL: Prud'hommeaux, E. (2004). Algae RDF Query Language. W3C, URL: 95

98 Prud'hommeaux, E., and Seaborne, A. (2006). SPARQL Query Language for RDF. W3C Working Draft. Richard, F., Patrick, H., and Ian, H. (2005). OWL-QL - A Language for Deductive Query Answering on the Semantic Web. Journal of Web Semantics, 2(1), Richard, G. G. (2002). Service Discovery Protocols and Programming. Developer Guides. McGraw-Hill Education. Salutation Consotium (1999). Salutation Architecture Specification V2.0c. Seaborne, A. (2004). RDQL - A Query Language for RDF. URL: Steinberg, D., and Cheshire, S. (2005). Zero Configuration Networking : The Definitive Guide, O'Reilly Media Inc., Sebastopol, CA, USA. Toninelli, A., Corradi, A., and Montanari, R. (2005). Semantic Discovery for Context-Aware Service Provisioning in Mobile Environments, The 1st Intl. Workshop on Managing Context Information in Mobile and Pervasive Environments, Agya Napa, Cyprus. UPnP Forum (2000). UPnP Device Architecture. Wleklinski, F. (2004). easy RDF Query Language (erql), URL: 96

99 Internetworking Between ZigBee/ and IPv6/802.3 Network Reen-Cheng Wang Department of Computer Science and Information Engineering, National Dong Hwa University 1, Sec. 2, Da Hsueh Rd., Shoufeng, Hualien, 97401, Taiwan, R.O.C Ruay-Shiung Chang Department of Computer Science and Information Engineering, National Dong Hwa University 1, Sec. 2, Da Hsueh Rd., Shoufeng, Hualien, 97401, Taiwan, R.O.C Han-Chieh Chao Department of Electronic Engineering, National Ilan University 1, Sec. 1, Shen-Lung Rd., I-Lan, 260, Taiwan, R.O.C #251 ABSTRACT With the rising demand of home automation and sensor networks, the IEEE specification outlines a new class of physical and MAC layer protocols targeted at low power devices, personal area networks, and sensor nodes. Based on IEEE , many upper layer protocols are proposed. The ZigBee is the most popular one. However, the ZigBee itself is not compatible with the IP-based network. It is a great challenge to integrate these two kinds of networks together. In this paper, we proposed an internetworking mechanism to overcome this problem. The architecture forms an overlay network on both ZigBee and IPv6 networks and helps the packets to transmit crossover the regions. The design is dedicated to the IPv6 only because many features of IPv6 are used inside the framework. Categories and Subject Descriptors C.2.1 [Computer-Communication Networks]: Network Architecture and Design Network communications, Wireless communication. General Terms Design. Keywords IEEE , IEEE802.3, Interworking, IPv6, ZigBee. 1. INTRODUCTION With the rising demand for pervasive computing and ubiquitous network access, wireless local area networks (WLANs) become very popular in the past few years. To convey information over relatively short distances, several wireless technologies and wireless personal area networks (WPANs) are proposed and being Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. IPv6 07, August 31, 2007, Kyoto, Japan. Copyright 2007 ACM /07/ $5.00. extensively discussed. Unlike WLANs, connections effected via WPANs involve little or no infrastructure. This feature allows small, power-efficient, and inexpensive solutions to be implemented for a wide range of devices. IEEE approved the standard for the low-rate WPAN (LR-WPAN) as [1] in Especially designed for low data rate wireless connectivity devices with limited battery consumption, defines the physical layer (PHY) and medium access control (MAC) sublayer specifications typically operating in the radius of 10m and more. The maximum raw data rate is 250 kb/s to satisfy a set of simple needs such as consumer electronics, home automation, industrial controls, and sensor applications. The specification is focused on low complexity, low cost, low power consumption, and low data rate wireless connectivity among inexpensive devices. For the same LR-WPAN purpose and based on , the most popular upper layer protocol, ZigBee [2], was developed by the ZigBee Alliance in The ZigBee protocol standard contains the specifications of the network layer (NWK) and application layer (APL). Inside the APL, functions are defined separately as the application support sub-layer (APS), the ZigBee device objects (ZDO), the ZigBee device profile (ZDP), the application framework (AF), and ZigBee security services. The comparisons of ISO OSI, TCP/IP, and ZigBee/ are shown in Figure 1. Since the TCP/IP has become the dominant protocol in the Internet due to its widespread use and reliability, and also the Ethernet is a de facto networking standard, the demand for Figure 1. Protocol Stacks Mapping 97

100 internetworking between ZigBee/ and TCP/IP/802.3 is inevitable. However, the design of ZigBee/ is incompatible with the TCP/IP network. In this paper, we propose an internetworking architecture to overcome this problem. The design is dedicated to IPv6 only because many features of IPv6 are used inside the framework. The rest of this paper is organized as follows. Section 2 presents an overview of other approaches and their problems. Section 3 outlines some design criteria and our solutions. Section 4 explains our mechanism with examples. And finally, the paper is concluded in Section RELATED WORKS In this section, we review some related technologies first. Because of the many problems occurred in IPv4, such as the IP address shortage, all the solutions for integrating LR-WPAN and IP are focused on IPv6 only. They include IPv6 over ZigBee, IPv6 over Low-Power Wireless Personal Area Networks (6LoWPAN) [3], IP-Net [4], and a translation solution [5]. The comparisons of the first three protocols are shown in Figure 2. Because and are different at physical layer, it is undoubtedly that there should have an interconnect node, which acts as a gateway between two networks. A simple network diagram is presented in Figure 3 for the following discussions. 2.1 IPv6 over ZigBee The straight forward method to make IPv6 work over ZigBee is to put the IPv6 stack on the top of ZigBee NWK layer. All the ZigBee nodes are assigned with an IPv6 address. At Gateway B, if a packet is received from the network, it will be encapsulated into ZigBee NWK and forwarded to the network. On the other hand, when a packet is transmitted from Node C to Host A, Gateway B will decapsulate the packet and use the IPv6 payload inside to continue the transmission. Because the data communication in ZigBee/ is asynchronous message-passing, only UDP can be used with IPv6 in this scenario. The key issue of IPv6 over ZigBee is the packet size problem. According to the specification, the maximum PHY service data unit is 127 bytes. In a data frame, after reducing the 23 bytes MAC header, 2 bytes frame check sequence (FCS), and 8 bytes NWK header, there are only 94 bytes left for the IPv6 packet. If the security mechanism (such as AES-CCM-128) is enabled, only 81 bytes will be left. This is quite tight for an IPv6 packet, which has 40 bytes basic header and even more extension headers. Also, the ZigBee/ does not support packet fragmentation. It can not handle the 1280 bytes minimum transfer unit required by IPv LoWPAN 6LoWPAN is a working group in the IETF. It focuses on defining the transmission of IPv6 Packets over IEEE networks. As shown in Figure 2, it creates an adaptation layer above the MAC to support the IPv6 data packet. The adaptation layer is used to handle the packet fragmentation so that an IPv6 packet can be separated into many frames for transmitting. The working group lists lots of problems in current development in [6]. Besides, it throws the ZigBee stack away. Without ZigBee NWK, all the routing structures, address assignment, and data forwarding must be redesigned. This poses a great challenge for future realization. 2.3 IP-Net IP-Net is designed by the Helicomm Inc. and used in their product, IP-Link, which is developed with the Silicon Laboratories Inc. As presented in Figure 2, it is a dual stack approach. Both the 6LoWPAN design and ZigBee stack are working on the same MAC. Although it endows a node with both IPv6 and ZigBee functions, only one of them can be used at the same time. Thus, it is not an internetworking solution. Also, it has all the problems that 6LoWPAN has. 2.4 A Translation Solution The only internetworking mechanism we can find today is in [5]. It is a NAT-PT [7] like solution. Take Figure 3 for example. When the network initiates, Host C must register its IPv6 address (IP C ) to pre-assigned Gateway B (IPv6 address: IP B ; ZigBee address: Z B ). B will help C to get its ZigBee address (Z C ). Node A must register its ZigBee address (Z A ) to B, too. If A wants to communicate with C, it sends out the packet to Z C. B will translate the packet into IPv6 format with "Destination IP address = IP C " and "Source IP address = IP B ". In the reverse path, for communicating from C to A, A will send the packet to IP B with a data payload which contains "Destination ZigBee address =Z C " and "Source ZigBee address = Z A ". After B receives the packet, it decapsulates the packet, looks for the payload, and translates it to format. The framework works. But users must pre-configure their hosts with fixed gateway address. The NAT-PT like design also breaks Figure 2. Protocol Stacks of Different Approaches Figure 3. Network Diagram 98

101 many end-to-end features such as information security. Service discovery, one of the most important functions in ZigBee network, is unsolved. Also, the mechanism can not perform cross regions transmission, such as the communication between A and E. Because all the mechanisms above are not proper to integrate ZigBee/ and IPv6/802.3 networks together, we design a novel overlay mechanism for the internetworking. 3. THE OVERLAY INTERNETWORKING DESIGN In this section, we will state the design criteria and our solutions for each criterion. Design Criteria: C.1. Each ZigBee node should be assigned with a global unicast IPv6 address. C.2. Each IPv6 host which may communicate with ZigBee node should obtain a ZigBee address. C.3. Service discovery should be propagated to different network domain. C.4. Broadcast data in ZigBee network should be transferred to proper IPv6 hosts. C.5. Data packet transformations in the gateways should be as simple as possible and should not break the end-to-end model above the transport layer. To satisfy the above criteria, we integrate many techniques to form an overlay network. The details are discussed in the following. 3.1 IPv6 Prefix Delegation [8][9] To keep the end-to-end communication model between hosts and nodes, we would like to assign each ZigBee node with an IPv6 address. Although the gateway at the edge is a more powerful ZigBee device with Ethernet interface, it is still hard to guarantee that the gateway can perform all the functions of a classical IPv6 router, running the RIPng or OSPFv3. Thus, we make the gateway support the IPv6 prefix delegation function and act as a requesting router. With the delegated prefix, every ZigBee device can have its own IPv6 address. It is obvious that ZigBee nodes can not perform IPv6 Stateless Autoconfiguration, and also the nodes may not have enough memory to keep its IPv6 address. The address assignment is done in a simple mapping method shown in Figure 4. This mapping mechanism is very useful when a packet is transferred from an IPv6 host to a ZigBee node. The gateway can easily remove the prefix part of the destination address and get the destination ZigBee address. It is not necessary to parse the payload to get the information about the real destination. The IPv6 address does not really exist on the ZigBee nodes. It is only a pseudo address at the gateway. Thus, the gateway can ignore the processes such as sending out a Prefix Advertisement to the side after prefix delegation received. Also, the ZigBee extended addresses are globally unique so that we can guarantee the mapping addresses will not conflict with each other even without IPv6 duplicate address detection (DAD) process. This will solve criteria C.1 and part of C UPnP [10] UPnP is used to solve both criteria C.2 and C UPnP with C.2 When an IPv6 host wants to join a ZigBee network, it must find a ZigBee coordinator to obtain its ZigBee address. The PAN ID is the keyword of the type of device in UPnP SSDP (Simple Service Discovery Protocol) discovery. When a gateway receives the SSDP discovery, it will transform the packet to ZigBee Service Discovery format and pass it to the network. The transformation will keep the record in a table for a period so that the response ZigBee address assignment packet can reply to the proper IPv6 host UPnP with C.3 UPnP is also used in the two way service discoveries when an IPv6 host or a ZigBee node wants to find some services in another network. In this case, the service discovery functions which are defined in ZDO will be transformed to the XML format at the gateway for the SSDP discovery and vice versa. With UPnP, the network will be more flexible. We do not have to manage a lot of pre-assigned parameters such as gateway address at the beginning. 3.3 IPv6 Multicast Because ZigBee is an ad-hoc wireless network, it has to support the broadcast function for many purposes. For example, the beacon frame is this kind of packet without specific destination. This raises a problem while IPv6/802.3 hosts join in the ZigBee network. If we transform all the broadcast messages in the ZigBee network and the all node multicast messages in IPv6 network to each other, the huge amount of IPv6 all node multicast message will crash the low data rate ZigBee network. Thus, we set up an IPv6 multicast group for each PAN ID. The gateway which is at Figure 4. IPv6 Address Assignment to ZigBee nodes Figure 5. IPv6 Address Assignment to ZigBee nodes 99

102 the same network of the coordinator (such as the Gateway B) will act as the rendezvous point of the multicast group. This can satisfy criterion C Extended IP Switching [11] Now all the nodes in the ZigBee network have their ZigBee and IPv6 unicast address, all the gateways has their ZigBee, IPv6 unicast, and IPv6 multicast address, and all the hosts in the IPv6 network have their ZigBee, IPv6 unicast, and IPv6 multicast address. The ZigBee network and IPv6 network are overlaid together. The last thing we want to do is to accelerate the transforming speed for data packet and also keep the end-to-end security. Unlike the [5], we use an IP-switching like mechanism to accomplish our purpose. All the data packet transformations are done below the network and the NWK layer, with simple header replacement just as IP Switching does. Without digging information from APL payload, the replacement will work with a simple table lookup. Because the entire NWK payload can keep untouched, we can enable the AES-CCM at APL layer to safeguard our data security. This fulfills criterion C EXAMPLES OF TRANSMISSION FLOWS The protocol stack of our mechanism is presented in Figure 5. Use the network diagram in Figure 3 as an example. Three kinds of flows are discussed in this section to explain more details about our mechanism. 4.1 From ZigBee/ to IPv6/802.3 Figure 6 shows the process of Node A (ZigBee/ ) communicating with Host C (IPv6/802.3) through Gateway B. Figure 6. From ZigBee/ to IPv6/802.3 Network Join is the necessary initiation step to form a ZigBee network. Because B is set up to be the coordinator, all nodes have to send their Join Request to B. From the viewpoint of A, B is at the same ZigBee network as A. Thus, the join process follows the ZigBee standard. The extended ZigBee address of A is fixed on the chip as the MAC address of an Ethernet network interface card. The network discovery (ND) Request/Confirm process is used to scan the wireless communication channel. And Join Request/Reply helps A to get its short ZigBee Address. Both extended and short ZigBee address of A are defined as Z A because ZigBee can use any of them. At the same time, B will build up a pseudo IPv6 address IP A (IPv6 Prefix from prefix delegation + Extended ZigBee Address of A) in its Unicast Mapping Table for A. Besides, from the viewpoint of C, it has its own IP C without any information about the coordinator at the beginning. The UPnP SSDP Request can help C to lookup the coordinator B in the IPv6 network. Because C is in a wire network, the ND Request/Confirm process can be ignored. C is a host (not a gateway) so that the Join Request will indicate it as "End node" type. This is used for the CSkips algorithm to calculate the ZigBee short address for C. The Join Reply will assign a short ZigBee address Z C to C and record the mapping IP C ->Z C in the unicast mapping table in B. At the same time, IPv6 Multicast Group Join/Confirm will assign an IPv6 Group Multicast Address to C for the ZigBee broadcast message purpose. The transmission process starts from ZigBee service discovery. A would like to access a service which C has, but A does not know it. A performs a standard broadcast ZigBee service discovery to all nodes. When B receives the packet, it transforms the SD request to SSDP Request message by mapping the source address to IP A and destination address to IPv6 Group Multicast Address. C will receive this multicast packet. C knows it can provide the service that A wants, so it replies to IP A with a confirmation. B will transform this SSDP reply to SD response format by mapping all the IPv6 address in network layer header to ZigBee address in the NWK header. When the peering is set up, the data transmission is quite simple. A sends out a packet to Z C directly. B will transform the packet to IP C with simple header replacement. The acknowledge (Ack) message from C will reply to IP A, which is also simply transformed by B to A. The only thing should be mentioned here is that the IPv6 Data Ack is not the TCP acknowledgment packet. Because ZigBee network is connectionless and transmits via message passing, the IPv6 Data Ack must be handled by the application layer so that the TCP timeout and the retransmission problems will not occur. 4.2 From IPv6/802.3 to ZigBee/ Figure 7 shows the reverse path communication which is initiated by Host C (IPv6/802.3) through the Gateway B to the Node A (ZigBee/ ). The network join process is the same so that we will not explain it again. The same as previous scenario, C has no idea that A owns the matched service in the beginning. The service discovery is started from C sending out an SSDP request message. When the Gateway B gets the request packet, it then transforms the packet to broadcast ZigBee Service Discovery format with the source 100

103 address mapped to Z C. A will get the SD request, finds out that it has the service, and replies with an SD response. When the response packet reaches B, it then transforms it to a unicast SSDP reply format, with the address mapping Z C -> IP C and Z A ->IP A. After C receives the SSDP reply, the peering connection is established. Now, A can start to transfer messages to C. The data packet is a standard IPv6 packet, with the payload containing ZigBee APL data type which is used to communicate with ZDO or ZDP. This is implemented in the application layer in hosts. The benefit of the payload following the ZigBee specification is to keep the security and limit the packet length so that it will not be too large while in transformation. The gap between ZigBee APL data size (94 bytes) and IPv6 MTU in (1280 bytes) is filled with zero so that the gateway can transform the payload with just simply discard the filler bits. B will replace the IPv6 Header with ZigBee NWK header and forward the packet. After A gets the data, a Data Confirm will be sent back to Z C. B will replace the ZigBee NWK Header with IPv6 header. All the necessary information can be found in its unicast mapping table. Finally A gets the confirmation and the transition then finishes. 4.3 Cross Regions Example The last flow we would like to show is a cross regions communication. The data goes from a ZigBee/ network, through an IPv6/802.3 network, and reaches a node in another ZigBee/ network. An example is shown in Figure 8 when Node A communicates with the Node E through Gateway B and Gateway D. The network begins with network join. A joins the ZigBee network using the standard procedure. D is a gateway which is also a ZigBee node and has to join the network. From the viewpoint of the coordinator B, D is from an network. So the join process is the same as an IPv6 host does, such as the Host C s process in Section 4.1. The difference is that D is a gateway, which must indicate itself as Router node type in the Join Request. This makes some differences in ZigBee address assignment based on the CSkip algorithm. Also, it has to synchronize with the coordinator gateway periodically to get the updated unicast mapping table. The joining of E is a little different. E sends out an ND Request, which D will handle and response the ND Confirm. After that, E sends out its Join Request. Because D already knows where the coordinator is, D will replace the NWK header with IPv6 header and forward the packet to B. B will treat E as an IPv6 host and assign a ZigBee short address to E in the Join Confirm. Because D has already joined the IPv6 multicast group, it is not necessary to do again while E joins the network. The service discovery processes are not much different. A sends out a broadcast SD Request. B transforms it to the SSDP Request with multicast. And D transforms the packet again to the broadcast SD Request. After E matches the service, it sends back an SD Response. D transforms it to the SSDP Response with destination address IP A. B transforms it to the SD Response with destination address Z A. A gets the packet at the end and establishes the peering. The data communication now can start. A sends out the data request to Z E directly. B replaces the NWK and forwards to IP E. D replaces IPv6 header to NWK header with destination to Z E. Then E will receive the data. The Data Confirm is sent to Z A, which converts to IP A at D and back to Z A at B. All the above examples show our mechanism is working in ZigBee/ to IPv6/802.3, IPv6/802.3 to ZigBee/ , and cross regions scenarios. Network Join Service Discovery Node A ND Request ND Confirm ZB_Join Request ZB_Join Confirm SD Request (Src: ZC; Dst: B_addr) SD Response (Src: ZA; Dst: ZC) Gateway B (coordinator) SSDP -> SD, IP C ->Z C, M_addr -> B_addr SD -> SSDP, Z A ->IP A, Z C->IP C, SSDP Request SSDP Reply ZB_Join Request IPv6_MG Join ZB_Join Confirm IPv6_MG Confirm SSDP Request (Src: IPC; Dst: M_addr) SSDP Reply (Src: IPA; Dst: IPC) Host C Data Transfer Data Request (Src: ZC; Dst: ZA) Data Confirm (Src: ZA; Dst: ZC) IP C->Z C, IP A ->Z A, Z A ->IP A, Z C ->IP C IPv6 Data Packet (Src: IPC; Dst: IPA) IPv6 Data Ack (Src: IPA; Dst: IPC) Src: Source Address M_addr: Group Multicast Address TERMS Dst: Destination Address B_addr: Broadcast Address ND: ZigBee Network Discovery ZG_Join: ZigBee Network Join SD: ZigBee Service Discovery IPv6_MG: IPv6 Multicast Group Figure 7. From IPv6/802.3 to ZigBee/ Figure 8. Cross regions 101

104 5. CONCLUSIONS In this paper, we present a novel gateway design which can overlay the ZigBee/ and the IPv6/802.3 networks together and internetworking among them. It can easily be extended to all kind of IPv6 networks such as IPv6/802.11, IPv6/UMTS, etc. Unlike the IPv6/ which is discussed by IETF 6LoWPAN working group or the ZigBee bridge mode which is drafted by ZigBee Alliance to connect two ZigBee networks together, our mechanism is operative not only between ZigBee/ and IPv6/802.3 but also multiple ZigBee/ networks connected by IPv6/802.3 networks. In our design, each ZigBee devices is assigned with a Global Unicast IPv6 address so that every IPv6 node can communicate with it directly. On the other hand, each IPv6 node who wants to communicate with the ZigBee devices is also assigned with a ZigBee short address. The IPv6 Multicast Group is also established in all correlated IPv6 nodes for relaying broadcast messages from ZigBee network. From the viewpoint of a ZigBee node, every IPv6 host is like another ZigBee node because it has a ZigBee address for communication. Besides, from the viewpoint of an IPv6 host, every ZigBee nodes is like another IPv6 host because it has an IPv6 address. The gateways will handle all the transformation. All the other ZigBee nodes and IPv6 hosts can keep unchanged. The design is quite useful for connecting the two kinds of networks. The mechanism works on Layer 3 and below so that it can keep the APL layer security if needed. However, a known problem is the "address in address" issue. Future ZigBee profiles may contain address information inside the APL layer. This is like the application layer gateway (ALG) problem in the IPv4/IPv6 NAT- PT design. It is a future work. 6. ACKNOWLEDGEMENT The research is supported by Taiwan NICI IPv6 Steering Committee. 7. REFERENCES [1] Standard , Part 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks (LR-WPANs). IEEE, May [2] ZigBee Specification Version 1.0. ZigBee Alliance, December [3] Montenegro, G., Kushalnagar,N., Hui, J., and Culler, D. Transmission of IPv6 Packets over IEEE Networks. IETF Internet Draft draft- ietf-6lowpan-format-13 (work in progress), April [4] Karayannis, G. IPv6 over IEEE , IETF 61st meeting presentation, November [5] Sakane, S., Ishii, Y., Toba, K., Kamada, K., and Okabe, N. A translation method between nodes and IPv6 nodes. In Proceeding of the International Symposium on Applications and the Internet Workshops 2006 (SAINT 2006) (Phoenix, Arizona, USA, January 23-27, 2006), [6] Kushalnagar, N., Montenegro, G., and Schumacher, C. 6LoWPAN: Overview, Assumptions, Problem Statement and Goals. IETF Internet Draft draft-ietf-6lowpan-problem-08 (work in progress), February [7] Tsirtsis, G., and Srisuresh, P. Network Address Translation - Protocol Translation (NAT-PT). IETF RFC 2766, February [8] Troan, O., and Droms, R. IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6. IETF RFC 3633, December [9] Miyakawa, S. and Droms, R. Requirements for IPv6 Prefix Delegation. IETF RFC 3769, June [10] UPnP Device Architecture. UPnP Forum, June [11] Newman, P., Lyon, T., and Minshall, G. Flow Labelled IP: A Connectionless Approach to ATM, In Proceeding of IEEE Infocom 1996, (San Francisco, CA, USA, March 24-28, 1996), 3,

105 附件三 會議資料 標準測試分項計畫 IPv6 設備驗證技術之研發 (11064) 計畫會議紀錄 會議名稱 :96 年度 NICI IPv6 標準測試分組每月定期 Review 時間 :2007/01/18 09:30 a.m. 地點 :607 會議室 散會 :11:30 A.M. 主席 : 陳錦洲 紀錄 : 邱萬德 姓名簽名姓名簽名 鄭石源 陳錦洲 曹志誠 劉冠廷 陳雪姬 凌芳瑜 楊青芬 邱萬德 應志宏 主席報告 : 1. 略 討論及決議事項 : 1. 完成每月預定進度 2. 萬德報告九十六年度 IPv6 設備驗證技術之研發工作規劃, 如附件 3. 96/01/02 清華大學高速網路研究室 Live6 Agent Keeper 1.0 至 NICI 標準測試實驗室進行 IPv6 Ready Logo Phase I 互連性測試 103

106 4. 96/01/04 審查宜蘭大學電資學院 IPv6 DNS ALG Proxy 1.0 IPv6 Ready Logo Phase I 申請 案, 其申請 ID 為 TW /01/05 審查訊舟科技 Print Server PS-1207UWG V1.20 IPv6 Ready Logo Phase I 申請 案, 其申請 ID 為 TW /01/05 亞洲大學師生三十餘人參訪 NICI 標準測試實驗室 7. 96/01/05 完成繳交 95 年度 IPv6 標準測試分組年度總結報告 8. 96/01/08 鴻海精密工業公司透過電話進行 IPv6 Ready Logo Phase I 技術交流 9. 96/01/08 華碩電腦研發處透過電話進行 IPv6 Ready Logo Phase I 技術交流 /01/11 國立臺灣師範大學資訊工程研究所透過電話進行 IPv6 Ready Logo Phase I 技術 交流 /01/11 大陸信息產業部通信計量中心透過電子郵件進行技術交流 /01/11 宜蘭大學電資學院 IPv6 DNS ALG Proxy 1.0 榮獲 IPv6 Ready Logo Phase I 銀質 標章,Logo ID 為 /01/15 東友科技股份有限公司參訪 NICI 標準測試實驗室, 進行了解臺灣 IPv6 測試服 務以及國際 IPv6 Ready Logo 現況簡介 /01/15 完成繳交 96 年度 IPv6 標準測試分組計畫書 /01/16 輔導清華大學高速網路研究室 Live6 Agent Keeper 1.0 IPv6 Ready Logo Phase I 申請案, 其申請 ID 為 TW /01/16 訊舟科技 Print Server PS-1207UWG V1.21 榮獲 IPv6 Ready Logo Phase I 銀質標 章,Logo ID 為

107 17. 96/01/17 明泰科技 Alpha Networks Inc. 至 NICI 標準測試實驗室, 進行 IPv6 Ready Logo Phase I 互連性測試 /01/18 國立中正大學高速網路實驗室透過電話與電子郵件進行 IPv6 Ready Logo Phase I 技術交流 IPv6 設備驗證技術之研發 (11064) 計畫會議紀錄 會議名稱 :96 年度 NICI IPv6 標準測試分組每月定期 Review 時間 :2007/02/16 09:30 a.m. 地點 :607 會議室散會 :11:30 A.M. 主席 : 陳錦洲 紀錄 : 邱萬德 姓名簽名姓名簽名 鄭石源 陳錦洲 曹志誠 劉冠廷 陳雪姬 凌芳瑜 楊青芬 邱萬德 主席報告 : 1. 略 討論及決議事項 : 1. 完成每月預定進度 2. 完成九十六年度計劃查核點 產出以及負責人變更, 詳如附件 105

108 3. 96/01/19~96/01/20 參加 96 年度 IPv6 建置發展計畫各分項計畫之計畫書審查會議 4. 主持人 : 財團法人台灣網路資訊中心董事長賴飛羆 ( 天籟 ) 5. 96/01/24 國立中正大學高速網路實驗室透過電話進行 IPv6 Ready Logo Phase I 技術交 流 6. 96/01/26 清華大學高速網路研究室 Live6 Agent Keeper 1.0 榮獲 IPv6 Ready Logo Phase I 銀質標章,Logo ID 為 /01/30~96/01/31 國立中正大學高速網路實驗室透過電話進行 IPv6 Ready Logo Phase I 技術交流 8. 96/02/01 明泰科技 Alpha Networks Inc. 研發之 Layer 2 Switch DGS-3400 Series 2.00 至 NICI 標準測試實驗室, 進行 IPv6 Ready Logo Phase I 互連性測試 9. 96/02/02 國立臺灣師範大學資訊工程研究所 XML Lab. 研發之 Carv6-SOAP GW v1.0 至 NICI 標準測試實驗室進行第一次 IPv6 Ready Logo Phase I 互連性測試 /02/07 國立中正大學高速網路實驗室研發之 Ubiquitous IMv6 Gateway 1.0 至 NICI 標 準測試實驗室進行 IPv6 Ready Logo Phase I 互連性測試 /02/09 輔導國立中正大學高速網路實驗室研發之 Ubiquitous IMv6 Gateway 1.0 IPv6 Ready Logo Phase I 申請案, 其申請 ID 為 TW /02/12 國立臺灣師範大學資訊工程研究所 XML Lab. 研發之 Carv6-SOAP GW v1.0 至 NICI 標準測試實驗室進行第二次 IPv6 Ready Logo Phase I 互連性測試 /02/15 明泰科技 Alpha Networks Inc. 研發之 Layer 2 Switch DGS-3400 Series 2.00 榮獲 IPv6 Ready Logo Phase I 銀質標章,Logo ID 為

109 14. 96/02/15 輔導國立臺灣師範大學資訊工程研究所 XML Lab. 研發之 Carv6-SOAP GW v1.0 IPv6 Ready Logo Phase I 申請案, 其申請 ID 為 TW IPv6 設備驗證技術之研發 (11064) 計畫會議紀錄 會議名稱 :96 年度 NICI IPv6 標準測試分組每月定期 Review 時間 :2007/03/23 09:30 a.m. 地點 :607 會議室 散會 :11:30 A.M. 主席 : 陳錦洲 紀錄 : 邱萬德 姓名簽名姓名簽名 鄭石源 陳錦洲 曹志誠 劉冠廷 陳雪姬 凌芳瑜 楊青芬 邱萬德 主席報告 : 1. 略 討論及決議事項 : 1. 完成每月預定進度 2. 96/02/20 國立中正大學高速網路實驗室研發之 Ubiquitous IMv6 Gateway 1.0 榮獲 IPv6 Ready Logo Phase I 銀質標章, 其 Logo ID 為 /02/26 審查國立臺灣師範大學資訊工程研究所 XML Lab. 研發之 Carv6-SOAP GW 107

110 v1.0 IPv6 Ready Logo Phase I 申請案, 其申請 ID 為 TW /03/02 國立臺灣師範大學資訊工程研究所 XML Lab. 研發之 Carv6-SOAP GW v1.0 榮 獲 IPv6 Ready Logo Phase I 銀質標章, 其 Logo ID 為 /03/15 前往神準公司報告國際 IPv6 產品認證發展簡介 6. 96/03/21 完成 IPv6 功能需求規範建議書 V1.0 初稿 7. 96/03/22~96/03/23 崑山科技大學網路安全與量子密碼實驗室研發之 6IDS 3.5 至 NICI 標 準測試實驗室進行 IPv6 Ready Logo Phase II Core 互連性測試 IPv6 設備驗證技術之研發 (11064) 計畫會議紀錄 會議名稱 :96 年度 NICI IPv6 標準測試分組每月定期 Review 時間 :2007/04/14 09:30 a.m. 地點 :607 會議室 散會 :11:30 A.M. 主席 : 陳錦洲 紀錄 : 邱萬德 姓名簽名姓名簽名 鄭石源 陳錦洲 曹志誠 劉冠廷 陳雪姬 凌芳瑜 楊青芬 邱萬德 主席報告 : 1. 略 108

111 討論及決議事項 : 1. 完成每月預定進度 2. 完成 IPv6 Ready Logo Phase II SIP 符合性測試平台建置技術報告, 並完成開會審查 3. 96/03/27 明泰科技 Alpha Networks Inc. 至 NICI 標準測試實驗室進行 IPv6 Ready Logo Phase II Core 互連性測試平台建置技術交流 4. 96/03/28~96/03/29 協助交通部及 TWNIC 於行政院主計處電子處理資料中心協辦 IPv6 教育訓練 ( 公務人員專班 ) 5. 96/03/28 明泰科技 Alpha Networks Inc. 透過 進行 IPv6 Ready Logo Phase II Core 互連性測試平台建置技術交流 6. 96/04/02 明泰科技 Alpha Networks Inc. 透過 進行 IPv6 Ready Logo Phase II Core 互連性測試平台建置技術交流 7. 96/04/04~96/04/09 輔導崑山科技大學網路安全與量子密碼實驗室研發 6IDS 3.5 IPv6 Ready Logo Phase II Core 申請案, 申請 ID 為 TW-2-C /04/10 協助交通部及 TWNIC 於行政院主計處電子處理資料中心協辦 IPv6 教育訓練 ( 公務人員專班 ) 9. 96/04/11 富士康至 NICI 標準測試實驗室了解 IPv6 Ready Logo 認證程序與測試方式 IPv6 設備驗證技術之研發 (11064) 計畫會議紀錄 會議名稱 :96 年度 NICI IPv6 標準測試分組每月定期 Review 109

112 時間 :2007/05/11 09:30 a.m. 地點 :607 會議室散會 :11:30 A.M. 主席 : 陳錦洲 紀錄 : 邱萬德 姓名簽名姓名簽名 鄭石源 陳錦洲 曹志誠 劉冠廷 陳雪姬 凌芳瑜 吳立凡 邱萬德 主席報告 : 1. 略 討論及決議事項 : 1. 完成每月預定進度 2. 96/05/01 楊青芬離退以及吳立凡到職, 已完成計畫人力變更 3. 96/04/16~96/05/04 審核 Yokogawa EFP100 T_ALL_01_01_RELEASE IPv6 Ready Logo Phase II Core 申請案, 其申請 ID 為 JP-2-C /04/18 派員參加 IPv6 Summit 議程會議, 討論 IPv6 Summit 議程以及相關籌備事宜 5. 96/04/19 明泰科技 Alpha Networks Inc. 研發之 D-Link DGS-3600 Series R2.20 至 NICI 標 準測試實驗室進行 IPv6 Ready Logo Phase I 互連性測試 6. 96/04/20 輔導明泰科技 Alpha Networks Inc. D-Link DGS-3600 Series R2.20 IPv6 Ready Logo Phase I 申請案, 其申請 ID 為 TW /04/20 崑山科技大學網路安全與量子密碼實驗室研發之 6IDS 3.5 至 NICI 標準測試實 110

113 驗室進行 IPv6 Ready Logo Phase II Core 互連性測試 8. 96/04/23 協助交通部及 TWNIC 完成普及物件連網基礎建設計畫書修正 9. 96/04/25 前往嶺東科技大學報告 IPv6 Ready Logo 發展現況 /04/27 友勁科技 CAMEO 至 NICI 標準測試實驗室進行 IPv6 Configured Tunnel 互連 性測試 /05/03~96/05/04 完成 IPv6 標準測試分項計畫 96 年度計畫期中報告 /05/07 崑山科技大學網路安全與量子密碼實驗室研發 6IDS 3.5 IPv6 Ready Logo Phase II Core 申請案, 榮獲 IPv6 Ready Logo Phase II Core 金質標章, 其 Logo ID 為 02-C /05/10 明泰科技 Alpha Networks Inc. 研發之 D-Link DGS-3600 Series R2.20 榮獲 IPv6 Ready Logo Phase II Core 銀質標章, 其 Logo ID 為 IPv6 設備驗證技術之研發 (11064) 計畫會議紀錄 會議名稱 :96 年度 NICI IPv6 標準測試分組每月定期 Review 時間 :2007/06/14 09:30 a.m. 地點 :607 會議室 散會 :11:30 A.M. 主席 : 陳錦洲 紀錄 : 邱萬德 姓名簽名姓名簽名 鄭石源 陳錦洲 曹志誠 劉冠廷 111

114 陳雪姬 凌芳瑜 吳立凡 邱萬德 主席報告 : 1. 略 討論及決議事項 : 1. 完成每月預定進度 2. 96/05/13~96/05/19 參加日本第九屆 TAHI IPv6 測試研討會及 IPv6 Ready Logo 委員管理 會議與技術會議 3. 96/05/18 協助交通部及 TWNIC 於台南成功大學資訊大樓四樓協辦 IPv6 教育訓練 4. 96/05/23 參加第二次 IPv6 Summit in Taipei 議程會議 5. 96/05/31 協助交通部及 TWNIC 於行政院主計處電子處理資料中心協辦 IPv6 教育訓練 ( 公務人員專班 ) 6. 96/06/08 協助交通部及 TWNIC 於中山大學計算機與網路中心 ( 圖書資訊大樓 ) 地下一樓 視訊研討室協辦 IPv6 教育訓練 7. 96/06/12~96/06/13 審核 Yokogawa EFP100 T_ALL_01_01_RELEASE IPv6 Ready Logo Phase II Core 申請案, 其申請 ID 為 JP-2-C /06/14 派員至 TWNIC 參加 Hexago 訓練課程 IPv6 設備驗證技術之研發 (11064) 計畫會議紀錄 會議名稱 :96 年度 NICI IPv6 標準測試分組每月定期 Review 112

115 時間 :2007/07/24 09:30 a.m. 地點 :607 會議室散會 :11:30 A.M. 主席 : 陳錦洲 紀錄 : 邱萬德 姓名簽名姓名簽名 鄭石源 陳錦洲 曹志誠 劉冠廷 陳雪姬 凌芳瑜 吳立凡 邱萬德 主席報告 : 1. 略 討論及決議事項 : 1. 完成每月預定進度 2. 96/07/24 芳瑜報告 SIP Transaction 簡介, 分享 SIP 測試經驗, 報告資料詳如附件 3. 96/07/02~96/07/04 審核 Yokogawa EFP100 T_ALL_01_01_RELEASE IPv6 Ready Logo Phase II Core 申請案, 其申請 ID 為 JP-2-C /07/03, 96/07/05, 96/07/12, 96/07/13,96/07/24 透過電子郵件與鴻海精密工業協調 IPv6 Ready Logo Phase I 互連測試事宜 5. 96/07/19 協助交通部及 TWNIC 於 TWNIC 協辦 IPv6 教育訓練 6. 96/07/24 派員參加 Hexago Gateway6 IPv6 Tunnel Broker 進階教育訓練於台灣網路資訊 中心四樓會議室舉行 7. 96/07/24 透過電話與電子郵件與鴻佰科技公司簡介 IPv6 Ready Logo Phase I 認證 113

116 8. 96/07/24 歐盟方面 IPv6 相關活動負責人 Jacques BABOT 參訪台灣網路資訊中心 TWNIC IPv6 設備驗證技術之研發 (11064) 計畫會議紀錄 會議名稱 :96 年度 NICI IPv6 標準測試分組每月定期 Review 時間 :2007/08/14 09:30 a.m. 地點 :607 會議室散會 :11:30 A.M. 主席 : 陳錦洲 紀錄 : 邱萬德 姓名簽名姓名簽名 鄭石源 陳錦洲 曹志誠 劉冠廷 陳雪姬 凌芳瑜 吳立凡 邱萬德 主席報告 : 1. 略 114

117 討論及決議事項 : 1. 完成每月預定進度 2. 96/08/14 萬德完成 IPv6 Ready Logo Phase II DHCPv6 符合性測試平台建置技術報告, 並完成開會審查 3. 96/07/25 鴻海精密工業研發之 T07X AD03008t 至標準測試實驗室進行 IPv6 Ready Logo Phase I 互連測試 4. 96/07/26 透過電話與電子郵件與鴻佰科技公司簡介 IPv6 Ready Logo Phase I 認證 5. 96/07/30 參加 IPv6 計畫工作進度會議 (TWNIC 10F 會議室舉行 ) 6. 96/07/31 透過電話與鴻佰科技公司簡介 IPv6 Ready Logo Phase I 認證 7. 96/08/02, 08/03 透過電話與電子郵件與鴻佰科技公司討論 IPv6 Ready Logo Phase I 符合 性測試 8. 96/08/06 前往 Foxconn 報告 IPv6 協定簡介及符合性與互通性測試 9. 96/08/09 參加 IPv6 計畫期中審查會議 /08/10 前往晶睿公司報告 IPv6 ready Logo 互通性測試 /08/10 透過電話輔導鴻海精密工業 IPv6 Ready Logo Phase I 申請事宜 115

118 116

119 附件四 活動記錄 標準測試分項計畫 (1) 接待法國企業總局 (Directorate General for Enterprise) 及法國電信代表 (96/6/21) (2) 主辦 2007 IPv6 Summit in Taiwan IPv6 測試研討會 (96/06/22) 標準測試分組召集人中華電信研究所梁隆星所長 經濟部標準檢驗局陳介山局長 117

120 Phase II 標章得主 Phase I 標章得主 D-Link 郭副總經理俊鏞報告 CHTTL 陳錦洲博士報告 (3) 拜訪美國 NIST 和 Telcordia 合影 (96/08/20~24) 參觀 NIST 世界級之無塵實驗室 Telcordia IMS 實驗室成員合影留念 118