JJ-300.10
ECHONET Lite 及び IoT アプリケーション
向け
ホームネットワーク通信インタフェース(IEEE802.15.4/4e/4g 920MHz 帯無線)Home network Communication Interface for ECHONET Liteand IoT applications (IEEE802.15.4/4e/4g 920MHz-band
Wireless)
第 2.3 版

2024 年 5 月 16 日制定

一般社団法人

情報通信技術委員会
THE TELECOMMUNICATION TECHNOLOGY COMMITTEE本書は、一般社団法人情報通信技術委員会が著作権を保有しています。
内容の一部又は全部を一般社団法人情報通信技術委員会の許諾を得ることなく複製、転載、改変、転用及びネットワーク上での送信、配布を行うことを禁止します。

－ 2 －ＪＪ－３００．１０

目次<参考> ............................................................................................................................................................................. 41.

標準の概要 .............................................................................................................................................................. 52.

本標準で規定する内容 .......................................................................................................................................... 5
1.1.

2.1.

規定の対象 ............................................................................................................................................. 5

1.2.

2.2.

各方式の概要 ......................................................................................................................................... 53.

参照規格・参考文献 .............................................................................................................................................. 54.

方式 A ...................................................................................................................................................................... 6
4.1.

概要 ................................................................................................................................................................... 6

4.2.

プロトコルスタック ....................................................................................................................................... 6

4.3.

物理層部 ........................................................................................................................................................... 6

4.4.

データリンク層 （MAC 層）部.................................................................................................................... 6

4.5.

インタフェース部 ........................................................................................................................................... 6

4.6.

シングルホップスマートメーター･HEMS 間推奨通信仕様 ...................................................................... 6

4.7.

マルチホップホームネットワーク推奨通信仕様 ........................................................................................ 6

4.8.

スマートメーター・IoT ルート無線端末間推奨通信仕様.......................................................................... 6[付録] ............................................................................................................................................................................... 6－ 3 －ＪＪ－３００．１０<参考>
１． 国際勧告等との関係
本標準に関連する国際標準等については、本文中に記載している。

２． 上記国際勧告等に対する追加項目等
本標準に関連する国際標準等に対するオプション選択項目、国内仕様として追加した項目、原標準に対す
る変更項目等については本文中に記載している。

３． 改版の履歴
版 数
1

改

訂

日

2013 年 2 月 21 日

改

版

内

容

制定
方式 A に関する仕様内容の追加 （5.622014 年 2 月 20 日

2.1

2014 年 5 月 22 日

2.2

2015 年 3 月 11 日

2.3

2024 年 5 月 16 日

セキュリティ処理、5.7

フレームフォーマット、5.9 シングルホップスマートメーター・
HEMS 間推奨通信仕様、を追加、他）
方式 B に関し、ZigBee IP の改定に合わせてパラメータ値を修正。
（6.6.1, 6.6.2, 6.6.3, 6.7, 6.7.3, 表 6-29（旧版の表 631)の記述変更、および旧版の表 6-34 を削除）
誤記訂正。（5.9.3.2.1 (3), 5.9.3.2.4 (4), 6.2.10.1,
6.3.5.1 11, 6.3.8.4）
記載内容を方式 A のみとし、付録に Wi-SUN Alliance の関係する仕様書を追加。

４． 工業所有権
本標準に係る「工業所有権等の実施に係る確認書」の提出状況は TTC のホームページでご覧になれます。

５． その他(1) 参照する主な勧告、標準
本文中に記載する。

６． 標準作成部門
第 1 版：次世代ホームネットワークシステム専門委員会
第 2 版：次世代ホームネットワークシステム専門委員会
第 2.1 版：次世代ホームネットワークシステム専門委員会
第 2.2 版：次世代ホームネットワークシステム専門委員会
第 2.3 版：IoT エリアネットワーク専門委員会－ 4 －ＪＪ－３００．１０標準の概要1.

本標準は、ECHONET Lite プロトコルを使用した家電機器、共同検針や特定計量等で使用される計器が接続される IoT ルート無線端末等の遠隔制御やモニタリング等を実現するホームネットワークを構築するためのプロトコルのうち、920MHz 特定小電力無線における仕様を規定した文書である。

2.

本標準で規定する内容

2.1.

規定の対象

ECHONET Lite や IoT アプリケーションを 920MHz 帯無線(IEEE802.15.4/4e/4g)の無線で利用するときには、以下の様な選択肢がある。
a. ネットワーク層プロトコルとして IPv6 ならびに 6LoWPAN を用いる
b. ECHONET Lite や IoT ルートアプリケーション電文を直接 IEEE802.15.4 フレームに載せる

表 2-1: 920MHz 帯無線プロトコルスタック

プロトコル・規定

セッション～アプリケーション層

ECHONET Lite、IoT ルートアプリケーション

トランスポート層プロトコル

UDP

b. Layer2 のフTCP

レーム上に直接
ネットワーク層プロトコルa.

搭載

IPv6 / 6LoWPAN

データリンク層プロトコル

IEEE802.15.4, IEEE802.15.4e/g

物理層プロトコル

IEEE802.15.4, IEEE802.15.4g

媒体

電波(920MHz 帯)

本標準のスコープは、a であり、そのうち、トランスポート層プロトコルとして UDP を使用する方式（方式 A）について規定する。

2.2.

各方式の概要本標準では、以下の方式を規定する。

表 2-2:本標準で規定する方式
方式

表１における選択肢

方式 Aa

関連する団体エコーネットコンソーシアム
テレメータリング推進協議会

Wi-SUN Alliance

方式 A は、物理層、データリンク層(IEEE802.15.4/4e/4g)の上に、IPv6/6LoWPAN、UDP 層（およびオプションとして TCP 層）を設けて ECHONET Lite や IoT ルートアプリケーションの電文を載せる。

3.

参照規格・参考文献

本標準が規定する仕様の一部を構成する内容を含む規格および関連する規格を以下に示す。
参照規格・参考文献について改訂があった場合は、本標準に基づく実装は改訂後の最新版を適用することを推奨する。他の参照規格については、その限りではない。

[付録] 2.1 および 2.2 参照－ 5 －ＪＪ－３００．１０

4.

方式 A

4.1.

概要

[付録] 3.1 参照

4.2.

プロトコルスタック[付録] 3.2 参照

4.3.

物理層部

[付録] 3.3 参照

4.4.

データリンク層 （MAC 層）部[付録] 3.4 参照

4.5.

インタフェース部[付録] 3.5 参照

4.6.

シングルホップスマートメーター･HEMS 間推奨通信仕様[付録] 3.7 参照

4.7.

マルチホップホームネットワーク推奨通信仕様[付録] 3.10 参照

4.8.

スマートメーター・IoT ルート無線端末間推奨通信仕様[付録] 3.11 参照

[付録]

－ 6 －

ＪＪ－３００．１０

HAN Working Group

1
2

Wi-SUN Alliance345Home Area Network (HAN) Working Group

6
7
8
9
10
11

Wi-SUN Profile for HAN

12
13
14

Revision 2v10

15
16
17
18

Released for TTC JJ-300.10

19
20
21
22
23
24
25
Wi-SUN Profile for HAN

7 of 206

HAN Working Group

26
27
28
29
30

Home Area Network Working Group
Home Area Network Technical Profile Specification
This document is provided under the terms of the agreement (21 Feb. 2013) between WiSUN Alliance and TTC. The contents of this document are jjointly Copyright © Wi-SUN
Alliance ™ and TTC (Telecommunication and Technology Committee).

Wi-SUN Profile for HAN

8 of 206

HAN Working Group31

1. Notices

32

1.1.

33
34
35

Copyright

The contents of this document are Copyright © Wi-SUN Alliance ™ and are strictly
confidential. No information contained herein may be supplied to any other party without
prior written permission from an authorized Wi-SUN Alliance representative.

36

37
38
39
40
41

1.2.

Provisional Document

This document is a work-in-progress and is subject to change. The specifications in thisdocument are minimum requirement for implementers. Additional information on thisspecification will be in Wi-SUN PHY/MAC/Interface specification documents for ECHONET
Lite [Wi-SUN-PHY] [Wi-SUN-MAC]

42

43

1.3.

Revision History

44

Table 4.8-1 Revision History

45

Version Date

AuthorComments

0v00

26 Jan 2013

Edited by
NICT

Provide Wi-SUN profile for Echonet Lite r3

0v01

20 Feb 2013

Edited by Phil Derived from Wi-SUN profile for Echonet Lite r3
Beecher

0v02

8 April 2013

Edited by
NICT andTOSHIBA-

Introduced security configuration in 3.5.7 forEchonet Lite over IP system-

Split previous Recommended usage section
into 3.6 single-hop home network section
and 3.7 single-hop smart meter-HEMS
section (defined PHY/MAC/Interface
parameters in each sections)

Wi-SUN Profile for HAN

9 of 206

HAN Working Group

2v01

2v02

23 October
2013

24 January
2014

Edited by
TOSHIBAand Renesas

Edited by
TOSHIBA-

Modified/changed: 6LP1.2, 6LP2, 6LP3,
6LP7, 6LP9 in Table 3.5-1, ND4 in Table
3.5.-8, and 6HC1.2, 6HC2.1, 6HC2.2 inTable 3.5-3.

-

Typo/grammatical corrections andclarifications-

Introduced the usage of Route-B credentialin 3.7.7-

Changed RX sensitivity value to follow
802.15.4g in Table 3-29.

-

Profile version number correction: 0v02
should be 2v00. Therefore this revision has
to be 2v01.

-

NS and NA messages have to carry EUI-64
format addresses in Table 3-16.

-

Added how many KeyDescriptors to hold atsame time (§3.7.5.3.1)-

Some editorial corrections-

Added the usage of list termination IE in
EB/EBR for single-hop smart meter-HEMS
network (§3.7.6.1.1)-

Transmission of NS message is optional forsingle-hop smart meter-HEMS network (§3.7.4.3.2)-

Additional statements for clarification in
Network layer section (§3.7.4.3) for singlehop smart meter-HEMS network.
Unnecessary functions in the single-hop
network are made to be optional.

-

Added a notation “50kbps is optional” in the
single-hop smart meter-HEMS network (§3.7.2).

Wi-SUN Profile for HAN

10 of 206

HAN Working Group

2v03

2v04

16 June2014

26
September
2014-

CSM is not supported if 50kbps is notsupported in the single-hop smart meterHEMS network(§3.7.2)-

Changed the notation of supporting
50kbps/100kbps for clarification in the
single-hop home network (§3.6.2)-

Table/Figure number corrections-

Added a remark and a notation in Table
3.6-9 macAckWaitDuration-

New Support status ‘Irrelevant’ in Table 3.74 ‘Network Layer: IPv6’ and 3.7-5 ‘Network
Layer: ICMPv6’.

-

Added a description about maximum link
MTU size issue (§3.7.4.5)

Edited by
Anritsu,
NICT,
Renesas, andTOSHIBA

Added §3.8 Recommended usage forsingle-hop home network among devices(TOSHIBA)

Edited by
TOSHIBA

Added §3.9 Recommended usage for thehome area network (HAN) employing relay
among devices (Anritsu, NICT, andRenesas)Above sub-sections are based on the HAN tiger
team discussion. The tiger team members
include Anritsu, Mitsubishi, NEC, NICT, NSS,
Panasonic, Procubed, Renesas, and Toshiba.
2v05

2v06

14 April2015

7 September
2015

Edited by
Anritsu,
NICT,OKI,
Renesas, andTOSHIBA-

Edited by
Anritsu,
NICT,OKI,

Revised: §3.8 and §3.9
New: Sleeping end device support
described in§3.10
Reference number corrections-

Added a clarification of the Header IE list
termination usage in §3.6.3.2-

Added clarifications of Active scan andCapability Notification IE usage in the

Wi-SUN Profile for HAN

11 of 206

HAN Working GroupTOSHIBA,and TUV

2v07

16
December
2015

Edited by
Anritsu,
NICT, OKI,
Panasonic,
andTOSHIBA

clauses 3.6.6.1.1, 3.7.6, 3.7.6.1.1, 3.8.3.1,
3.8.6.1.1, Table 3.7-3.
-

Revised clause 3.8.1-

Added resolution of IPv6 ND with Relay
device in 3.9.6.1.2-

Unified relay related IE names: SRA ID and
SLR IE-

Introduced New PANA REQ-TimeoutModification-Requet AVP for PANA Key
Exchange with Sleeping Device in 3.10.5-

Fixed typo.

-

LOWPAN_IPHC format for multicast packet
in 3.5.2-

Header IE list terminator notation in 3.6.3.2-

Recommended “Scanduration’ value in
3.8.6.1.1-

Recommended interval time between
Enhanced Active Scans in 3.8.8-

Changed the byte order of the relay related
IEs to little endian in 3.9.3.2.3-

Intermediate hop 1-N subfileds arenecessary and fixed typo in Figure 3.9-4
SLR IE-

Capability Notification IE is necessary forboth EBR and EB in 3.9.8.

-

Behavior when exceeded number ofintermediate hops is found in SRA or SLR isdescribed in 3.9.9.

-

Minimum mandatory for indirecttransmission buffer is notified in 3.10.3.1.1.

-

Variable setting for
macTransactionPersistenceTime isdescribed in 3.10.3.1.1

Wi-SUN Profile for HAN

12 of 206

HAN Working Group

2v08

2v09

2v09

2v10

6 July 2016

1 October
2021

Edited by
Anritsu, OKI,
andTOSHIBA

Edited by
ROHM andTOSHIBA

21
November
2022

Edited by
TOSHIBA

11 April
2023

Edited by
ROHM-

A limitation for 6LoWPAN fragmentation is
notified in 3.10.4.2.

-

Destination address of SLR IE for multicast
indirect transmission in 3.10.4.3.3-

PANA Time Out. modification sequence isrecommended to be limited at initial joinsequence. Specified in 3.10.5.

-

The ranges of REQ_IRT and REQ_MRT
are notified in 3.10.5.

-

How to register sleep end device in acoordinator and aging of registration is
described in 3.10.6.1.1.

-

Data request frame shall not be encrypted.
This is noted in 3.10.3.1.2.

-

Multicast transmission in 3.9.11-

Fixed Typo-

Reflected from the latest errata document(“Errata for Profile Technical Specifications
and Test Specifications” 0v06)-

Fixed reference errors-

Replaced the recommended scanduration value 6 with 5 for IEEE 802.15.4g
conformity-

Replaced with new Wi-SUN logo-

New Route-IoT support described in 3.11-

1.4 Acknowledgements section added-

Fixed Typo-

Chaneged Title and WG name on the cover(+header and footer) (“echonet” to “HAN”)-(The version number 2v09 is not changed)-

Usage of credential for Route-IoT updated(3.11.7)

Wi-SUN Profile for HAN

13 of 206

HAN Working Group

46

47
48
49

1.4.

Acknowledgements

The Wi-SUN Alliance acknowledges the substantial efforts of the following individuals who
contributed to the production of this document.

50
51

HAN Version 2v03 contributors:

52•

Fumihide Kojima, NICT

54•

Hoang Vinh Dien, NICT (Secretary)

53•

Hiroshi Harada, NICT (Chair)

55•

Mitsuru Kanda, Toshiba (Technical Editor)

56
57

HAN Version 2v04 contributors:

58•

Amarjeet Kumar, Procubed Inc.

63•

Keiichi Teramoto, Toshiba

59•

Anand M, Procubed Inc.

64•

Koichi Sato, Renesas

60•

Fumihide Kojima, NICT

65•

Mitsuru Kanda, Toshiba (Technical Editor)

61•

Hiroshi Harada, NICT (Chair)

66•

Toyoyuki Kato, Anritsu

62•

Hoang Vinh Dien, NICT (Secretary)67•

HAN tiger team:68•

Akiyoshi Yagi, Mitsubishi Electric79•

Mitsuru Kanda, Toshiba

69•

Bhupender Virk, Procubed Inc

80•

Osamu Miyashita, Anritsu

70•

Daisuke Takita, Mitsubishi Electric

81•

Satoshi Okage, Panasonic71•

Fumihide Kojima, NICT

82•

Shigekazu.Harada, NEC

72•

Fumio Sato, Toshiba

83•

Takashi Asai, Renesas

73•

Hiroshi Harada, NICT84•

Tetsuya Tamura, Anritsu

74•

Yoshihiro Izumi, NISSIN SYSTEMS

85•

Tomohito Ikeya, Anritsu

75•

Junichi Iwana, Renesas

86•

Tomoki Takazoe, Panasonic76•

Keiichi Teramoto, Toshiba87•

Toyoyuki Kato, Anritsu

77•

Koichi Sato, Renesas

88•

Verotiana Rabarijaona, NICT78•

Mikiharu Ishii, NEC89•

Yoshio Kashiwagi, NISSIN SYSTEMS

Wi-SUN Profile for HAN

14 of 206

HAN Working Group90
91

HAN Version 2v05 contributors:

92•

Fumihide Kojima, NICT

95•

Mitsuru Kanda, Toshiba (Technical Editor)

93•

Hiroshi Harada, NICT (Chair)

96•

Koichi Sato, Renesas

94•

Hoang Vinh Dien, NICT (Secretary)

97•

Toyoyuki Kato, Anritsu

98
99

HAN Version 2v06 contributors:

100•

Fumihide Kojima, NICT103•

Olga Kozeruk, TUV

101•

Hiroshi Harada, NICT (Chair)

104•

Verotiana Rabarijaona, NICT

102•

Mitsuru Kanda, Toshiba (Techinical Editor)

105
106

HAN Version 2v07 contributors:

107•

Fumihide Kojima, NICT112•

Tomohito Ikeya, Anritsu

108•

Hiroshi Harada, NICT (Chair)

113•

Toyoyuki Kato, Anritsu

109•

Mitsuru Kanda, Toshiba (Technical Editor) 114•

Yoshihisa Nakano, OKI

110•

Noriyuki Sato, OKI

115•

Verotiana Rabarijaona, NICT

111•

Satoshi Okage, Panasonic

116
117

HAN Version 2v08 contributors:

118•

Fumihide Kojima, NICT

121•

Noriyuki Sato, OKI

119•

Hiroshi Harada, NICT (Chair)

122•

Toyoyuki Kato, Anritsu

120•

Mitsuru Kanda, Toshiba (Chair)

123
124

HAN Version 2v09 contributors:

125•

Hiroshi Harada, NICT (Chair)

127•

Kiyoshi Fukui, OKI

126•

Mitsuru Kanda, Toshiba (Technical Editor) 128•

Yuki Matsumura, ROHM

129

Wi-SUN Profile for HAN

15 of 206

HAN Working Group

Contents

130

131

1

NOTICES ................................................................................................................................................................... 9

132

1.1

Copyright ................................................................................................................................................................... 9

133

1.2

Provisional Document................................................................................................................................................ 9

134

1.3

Revision History ......................................................................................................................................................... 9

135

1.4

Acknowledgements ................................................................................................................................................. 14

136

2

REFERENCES ........................................................................................................................................................ 19

137

2.1

Normative references .............................................................................................................................................. 19

138

2.2

Informative References ........................................................................................................................................... 21

139

3

WI-SUN PROFILES (ECHONET LITE OVER IP) ........................................................................................ 22

140

3.1

Overview .................................................................................................................................................................. 22

141

3.2

Protocol stack .......................................................................................................................................................... 24

142
143
144

3.3
PHY part ................................................................................................................................................................... 27
3.3.1
Overview .......................................................................................................................................................... 27
3.3.2
PHY specification ............................................................................................................................................. 27

145
146
147
148

3.4
MAC part.................................................................................................................................................................. 31
3.4.1
Overview .......................................................................................................................................................... 31
3.4.2
Beacon mode profile ....................................................................................................................................... 31
3.4.3
Non-beacon mode profile................................................................................................................................ 41

149
150
151
152
153
154
155
156
157

3.5
Wi-SUN ECHONET Lite interface part ...................................................................................................................... 52
3.5.1
Overview .......................................................................................................................................................... 52
3.5.2
Requirement .................................................................................................................................................... 52
3.5.3
Adaptation layer .............................................................................................................................................. 52
3.5.4
Network layer .................................................................................................................................................. 58
3.5.5
Transport layer ................................................................................................................................................ 62
3.5.6
Application layer .............................................................................................................................................. 62
3.5.7
Security configuration ..................................................................................................................................... 63
3.5.8
Frame format ................................................................................................................................................... 66

158
159
160

3.6
Recommended usage for single-hop home network .............................................................................................. 68
3.6.1
Overview .......................................................................................................................................................... 68
3.6.2
PHY part ........................................................................................................................................................... 68
Wi-SUN Profile for HAN

16 of 206

HAN Working Group

161
162
163
164

3.6.3
3.6.4
3.6.5
3.6.6

MAC part .......................................................................................................................................................... 69
Interface part ................................................................................................................................................... 84
Security configuration ...................................................................................................................................... 85
Recommended network configurations .......................................................................................................... 86

165
166
167
168
169
170
171
172

3.7
Recommended usage for single-hop smart meter-HEMS network ......................................................................... 91
3.7.1
Overview .......................................................................................................................................................... 91
3.7.2
PHY part ........................................................................................................................................................... 91
3.7.3
MAC part .......................................................................................................................................................... 93
3.7.4
Interface part ................................................................................................................................................... 95
3.7.5
Security configuration ...................................................................................................................................... 99
3.7.6
Recommended network configurations ........................................................................................................ 100
3.7.7
Usage of credential in Japanese market Route-B (supplemental) ................................................................. 109

173
174
175
176
177
178
179
180
181

3.8
Recommended usage for single-hop home area network (HAN) among devices ................................................. 113
3.8.1
Overview ........................................................................................................................................................ 113
3.8.2
PHY part ......................................................................................................................................................... 113
3.8.3
MAC part ........................................................................................................................................................ 113
3.8.4
Interface part ................................................................................................................................................. 115
3.8.5
Security configuration .................................................................................................................................... 116
3.8.6
Recommended network configurations ........................................................................................................ 138
3.8.7
Usage of credential ........................................................................................................................................ 142
3.8.8
Discovery and selection of the HEMS network .............................................................................................. 144

182
183
184
185
186
187
188
189
190
191
192
193

3.9
Recommended usage for multi-hop home area network employing relay device ............................................... 147
3.9.1
Overview ........................................................................................................................................................ 147
3.9.2
PHY part ......................................................................................................................................................... 148
3.9.3
MAC part ........................................................................................................................................................ 148
3.9.4
Interface part ................................................................................................................................................. 157
3.9.5
Security configuration .................................................................................................................................... 158
3.9.6
Recommended network configurations ........................................................................................................ 165
3.9.7
Usage of credential ........................................................................................................................................ 167
3.9.8
Discovery and selection of the HEMS network .............................................................................................. 167
3.9.9
Route Information ......................................................................................................................................... 169
3.9.10 Unicast Transmission ..................................................................................................................................... 169
3.9.11 Multicast Transmission .................................................................................................................................. 170

194
195
196
197
198
199
200
201
202
203

3.10

204

3.11

Recommended usage for home area network among devices with an extension of sleeping end device support
171
3.10.1 Overview ........................................................................................................................................................ 171
3.10.2 PHY part ......................................................................................................................................................... 172
3.10.3 MAC part ........................................................................................................................................................ 173
3.10.4 Interface part ................................................................................................................................................. 177
3.10.5 Security configuration .................................................................................................................................... 179
3.10.6 Recommended network configurations ........................................................................................................ 181
3.10.7 Usage of credential ........................................................................................................................................ 182
3.10.8 Discovery and selection of the HEMS network .............................................................................................. 182
Recommended usage for Route-IoT network ........................................................................................................ 184
Wi-SUN Profile for HAN

17 of 206

HAN Working Group

3.11.1
3.11.2
3.11.33.11.43.11.5
3.11.6
3.11.73.11.8

205
206
207
208
209
210
211
212

Overview ........................................................................................................................................................ 184
PHY part ......................................................................................................................................................... 185
MAC part........................................................................................................................................................ 185
Interface part ................................................................................................................................................. 186
Security configuration ................................................................................................................................... 187
Recommended network configurations ........................................................................................................ 187
Usage of credential ........................................................................................................................................ 188
Discovery and selection of the smart meter network ................................................................................... 189

213

4

WI-SUN PROFILES (ECHONET LITE OVER NON IP) .......................................................................... 191

214

4.1

Overview ................................................................................................................................................................ 191

215

4.2

Protocol stack ........................................................................................................................................................ 193

216

4.3

PHY part ................................................................................................................................................................. 194

217

4.4

MAC part................................................................................................................................................................ 194

218
219
220

4.5
Wi-SUN ECHONET Lite Interface part .................................................................................................................... 194
4.5.1
Overview ........................................................................................................................................................ 194
4.5.2
Requirement .................................................................................................................................................. 194

221

4.6

Application layer .................................................................................................................................................... 195

222

4.7

Security .................................................................................................................................................................. 195

223

4.8

Device ID ................................................................................................................................................................ 195

224
225
226

4.9
Frame format ......................................................................................................................................................... 196
4.9.1
The case interface part is employed .............................................................................................................. 196
4.9.2
The case interface part is not employed ....................................................................................................... 203

227
228
229
230
231

4.10 Recommended usage for single-hop network ....................................................................................................... 204
4.10.1 Overview ........................................................................................................................................................ 204
4.10.2 Construction of new network ........................................................................................................................ 204
4.10.3 Association to the network............................................................................................................................ 205
4.10.4 Specifications for device/PHY layer/MAC layer in order to realize the recommended usage ...................... 206

232

Wi-SUN Profile for HAN

18 of 206

HAN Working Group233

2. References

234

2.1.

235
236
237
238

Normative references

This section lists the normative references that define partial specifications of this standard
or ones that are related to the standard.
This document is to recommend that any update in those references should be reflected in
the subsequent implementations according to the standard.
[6LOWPAN]

Transmission of IPv6 Packets over IEEE 802.15.4 Networks(6LoWPAN), IETF RFC 4944

[6LPHC]

Compression Format for IPv6 Datagrams in 6LoWPAN Networks,
IETF RFC 6282

[6LPND]

Neighbor Discovery Optimization for IPv6 over Low-Power Wireless
Personal Area Networks (6LoWPANs), IETF RFC 6775

[802.15.4]

IEEE Std. 802.15.4 - 2011™, IEEE Standard for Information
Technology - Telecommunications and Information exchange between
systems - Local and metropolitan area networks - Specificrequirements - Part 15.4: Wireless Medium Access Control (MAC) andPhysical Layer (PHY) Specifications for Low-Rate Wireless Personal
Area Networks (WPANs), September 2011[802.15.4e]IEEE Std. 802.15.4e-2012™, Part 15.4: Low-Rate Wireless Personal
Area Networks (LR-WPANs) - Amendment 1: MAC sub-layer, April
2012.

[802.15.4g]

IEEE Std. 802.15.4g-2012™, Part 15.4: Low-Rate Wireless Personal
Area Networks (LR-WPANs) - Amendment 3: Physical Layer (PHY)
Specifications for Low-Data-Rate, Wireless, Smart Metering Utility
Networks, April 2012.

[802.15.10]“P802.15.10TM/D01 Draft Recommended Practice for Routing Packets
in 802.15.4 Dynamically Changing Wireless Networks[T108]

ARIB STD-T108 920MHz-BAND. TELEMETER, TELECONTROL.
AND DATA TRANSMISSION RADIO. EQUIPMENT

262[AES-CCM]

NIST SP800-38C

263[AES-GCM]

NIST SP800-38D

264

[EAP]

Extensible Authentication Protocol (EAP), IETF RFC 3748

239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261

Wi-SUN Profile for HAN

19 of 206

HAN Working Group[EAP-PSK]The EAP-PSK Protocol: A Pre-Shared Key Extensible Authentication
Protocol (EAP) Method, IETF RFC 4764

267

[EL]

The ECHONET Lite Specification Version 1.01

268

[IPv6]

Internet Protocol, Version 6 (IPv6) Specification, IETF RFC 2460

269

[IPv6-DHCP]"IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP)
version 6, IETF RFC 3633

271

[AH]

IP Authentication Header, IETF RFC 4302

272

[ESP]

IP Encapsulating Security Payload (ESP), IETF RFC 4303

273
274

[HMAC-SHA256] Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with
IPsec, IETF RFC 4886

275

[IPv6-RH]

Deprecation of Type 0 Routing Headers in IPv6, IETF RFC 5095

276

[IPv6-SAA]

IPv6 Stateless Address Autoconfiguration, IETF RFC 2462

277

[ICMP6]

Internet Control Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification, IETF RFC 4443

279

[IP6ADDR]

IP Version 6 Addressing Architecture, IETF RFC 4291

280

[MLE]

Mesh Link Establishment, IETF draft-kelsey-intarea-mesh-linkestablishment-06

282

[NAI]

The Network Access Identifier, IETF RFC 4282

283

[ND]

Neighbor Discovery for IP version 6 (IPv6), IETF RFC 4861

284

[PANA]

Protocol for Carrying Authentication for Network Access (PANA), IETF
RFC 5191[PANA-ENC]

Encrypting the Protocol for Carrying Authentication for Network
Access (PANA) Attribute-Value Pairs, IETF RFC 6786

288

[SLAAC]

IPv6 Stateless Address Autoconfiguration, IETF RFC 4862

289

[TCP]

Transmission Control Protocol (TCP), IETF RFC 793

290

[UDP]

User Datagram Protocol (UDP), IETF RFC 768

291

[ULA]

Unique Local IPv6 Unicast Addresses, IETF RFC 4193

292

[USRK]

Specification for the Derivation of Root Keys from an Extended Master
Session Key (EMSK), IETF RFC 5295

265
266

270

278

281

285
286
287

293

Wi-SUN Profile for HAN

20 of 206

HAN Working Group

294[Wi-SUN-PHY]

Wi-SUN PHY specification document for ECHONET Lite, 20120212PHYWG-Echonet-Profile-0v01[Wi-SUN-MAC]

WI-SUN MAC specification document for ECHONET Lite, 20120212MACWG-Echonet-Profile-0v01[Wi-SUN-MAC]

WI-SUN Interface specification document for ECHONET Lite,
20120212-IFWG-Echonet-Profile-0v01

295
296
297
298
299
300

[Wi-SUN-CTEST] Wi-SUN conformance test specification for ECHONET Lite

301

[Wi-SUN-ITEST] Wi-SUN interoperability test specification for ECHONET Lite

302

303
304

2.2.

Informative References
None

Wi-SUN Profile for HAN

21 of 206

HAN Working Group305

3. Wi-SUN profiles (ECHONET Lite over IP)

306

3.1. Overview

307
308
309
310
311
312
313
314
315
316
317

This section defines physical (PHY) and data link layers profiles and Wi-SUN ECHONET Liteinterface to communicate between devices using IP and IEEE 802.15.4g and 4/4e. Wi-SUN
ECHONET-Lite interface is an interface between ECHONET Lite application part and physicaland MAC layers for transmission of ECHONET Lite application data from one device to theother devices. Figure 4.8-1 shows the scope defined by this document. Figure 4.8-2 shows
the Wi-SUN profile layer structure. In this section, the mark of "M" indicates the mandatory
functions in the standards [802.15.4], [802.15.4g] and [802.15.4e], and "O" means optional
functions. The marks of "Y" and "N" mean the required and not-required functions in
ECHONET Lite operation, respectively. Specifications and procedures for certification andinteroperability tests are provided by [Wi-SUN-PHY], [Wi-SUN-MAC], [Wi-SUN-IF], [Wi-SUNCTEST] and [Wi-SUN-ITEST].

318

Wi-SUN Profile for HAN

22 of 206

HAN Working Group

Device 1

Device 2

Device 1 application

Device 2 application

ECHONET-Liteapplication part

ECHONET-Liteapplication part

Wi-SUN ECHONET Lite
Interface part

Wi-SUN ECHONET Lite
Interface part

MAC part(IEEE802.15.4/4e)

Scope of this section

PHY part(IEEE802.15.4g)

MAC part(IEEE802.15.4/4e)

PHY part(IEEE802.15.4g)

319
320

Figure 4.8-1 Scope defined by this section

321
322

Wi-SUN Profile for HAN

23 of 206

HAN Working Group323

3.2. Protocol stack

324

Protocol stack for the device defined by this profile is shown in Figure 4.8-2.

325
326
327
328

PHY layer provides the following service under this profile.
・ Up-to-2047 bytes PSDU exchange (Note that the profile recommends 255 bytes or lessas mentioned later)

329
331

Data link (MAC) layer provides the following services under this profile.
・ Successful discovery of IEEE 802.15.4 PAN in radio propagation range

332

・ Support of low energy hosts that can change its status between active and sleep status

333

・ Security functions that includes encryption, manipulation detection and replay attack
protection (Note that key management is not performed by this layer)

330

334
335
336
337

6LoWPAN adaptation layer provides the following services under this profile.
・ IPv6 and UDP header compression and decompression

339

・ Fragmentation and defragmentation of IPv6 packet that exceeds maximum payload size
operable by data link layer

340

・ Neighbor discovery (Not necessary when done by the network layer)

338

341
343

Network layer provides the following services under this profile.
・ IPv6 address management and packetizing

344

・ Neighbor discovery (Not necessary when done by the adaptation layer)

345

・ IPv6 stateless address autoconfiguration and duplicate address detection (DAD)

346

・ IPv6 packet forwarding

347

・ ICMPv6 support

348

・ IPv6 packet multicast transmission and reception

342

349
350
351

Transport layer provides the following service under this profile.
・ Packet delivery that is not guaranteed by UDP

352
353
354
355

Application layer provides the following services under this profile.
・ Detection of functional units (ECHONET object) employed by the other nodes in the
network
Wi-SUN Profile for HAN

24 of 206

HAN Working Group356

・ Acquisition of parameters and statuses (ECHONET property) for the other nodes

357

・ Configuration of parameters and statuses for other nodes

358

・ Notification of parameters and statuses for the local node359

・ Security configuration is provided by PANA for ECHONET Lite over IP

360➢ PANA runs over UDP and provides security capabilities below:361

 Mutual authentication between coordinator and host362

 Link layer ciphering key management after successful authentication

363

Wi-SUN Profile for HAN

25 of 206

HAN Working Group

364
365
366
367

Layer 5-7

368

Application layer(ECHONET Lite) PANA Security(For UDP/IP)

369

Wi-SUN ECHONET Lite Interface part

370
371

Wi-SUN Transport layer Security (option)

Layer 4

372

Wi-SUN Transport layer profiles(TCP, UDP)

373
374

Wi-SUN Network layer profiles(IPv6, ICMPv6)

375
376

Layer 3377

Wi-SUN Adaptation layer profiles(6LowPAN)

378
379
380

Layer 2

Wi-SUN MAC part
(MAC profiles based on IEEE 802.15.4/4e)Layer 1

Wi-SUN PHY part
(PHY profiles based on IEEE 802.15.4g)

381
382
383
384
385
386

Figure 4.8-2 Layer structure defined by this section

387
388

Wi-SUN Profile for HAN

26 of 206

HAN Working Group

389

3.3.

390

3.3.1. Overview

391

This section defines the PHY profiles required for PHY part supporting ECHONET Lite
applications. The profiles are based on features and capabilities defined in standards[802.15.4] and [802.15.4g]. For each profile, references are given to the appropriate subclauses in [802.15.4] and [802.15.4g].

392
393
394

PHY part

395

396

3.3.2. PHY specification

397

3.3.2.1. PLF and PLP capabilities

398
399

The requirements for the PHY Layer Function (PLF) and PHY Layer Packet (PLP) aredescribed in Table 4.8-2.

400

Table 4.8-2 PLF and PLP capabilities
Item
numberItem description

Reference
section instandard

Status instandard(M:Mandatory,
O:Option)

Support(Y:Yes, N:No,
O:Option)

PLF1

Energydetection (ED)[802.15.4]8.2.5 FD1:M

FD1:Y

PLF2

Link quality
indication (LQI)[802.15.4]8.2.6 M

Y

PLF3

Channelselection[802.15.4]8.1.2 M

Y

PLF4

Clear channel
assessment(CCA)[802.15.4]8.2.7 M

Y

PLF4.1Mode 1[802.15.4]8.2.7 O.2

Y

PLF4.2Mode 2[802.15.4]8.2.7 O.2

N

PLF4.3Mode 3[802.15.4]8.2.7 O.2

N

Wi-SUN Profile for HAN

27 of 206

HAN Working Group

PLP1

PSDU size up
to 2047 octets[802.15.4g]9.2

FD8:M

Y

401

Wi-SUN Profile for HAN

28 of 206

HAN Working Group402

3.3.2.2. RF capabilities

403

The requirement for the RF capabilities is described inTable 4.8-3.
Table 4.8-3 RF capabilities

404

Reference
section instandard

Status instandard

SupportItemnumberItem description

RF12

SUN PHYs

RF12.1

MR-FSK[802.15.4g] 18.1

FD8:M

Y(*1)

RF12.2

MR-OFDM[802.15.4g] 18.2

FD8:O

N

RF12.3MR-O-QPSK[802.15.4g] 18.3

FD8:O

N

RF12.4

MR-FSK-Generic
PHY[802.15.4g]
8.1.2,10.2

RF12.1:O

N

RF12.5

Transmit and receive [802.15.4g] 8.1ausing CSM

M

Y

RF12.6

At least one of the
bands given in Table
66 [802.15.4g][802.15.4g] 8.1

FD8:M

Y (920MHz, *2)

RF13

SUN PHY operating
modes

RF13.4

Operating mode #1
and #2 in 920 MHz
band[802.15.4g] 18.1

FD8:M

Y

RF 13.5

Operating mode #3
and #4 in 920 MHz
band[802.15.4g] 18.1

FD8:O

N

RF14

MR-FSK Options

RF14.1

MR-FSK FEC[802.15.4g]
18.1.2.4

O

N

RF14.2

MR-FSK interleaving[802.15.4g]
18.1.2.5

O

N

Wi-SUN Profile for HAN(Y:Yes,(M:Mandatory, N:No,
O:Option)
O:Option)

29 of 206

HAN Working Group

405
406
407
408

RF14.3

MR-FSK data
whitening[802.15.4g]
18.1.3O

Y

RF14.4

MR-FSK modeswitching[802.15.4g]18.1.4 O

N*1: The frequency tolerance requirements in [802.15.4g] 18.1.5.3 do not apply. The
frequency tolerance shall be +-20ppm.
*2: All channels shown in [802.15.4g] Table 68d within the supported operating mode(s) for
the respective band shall be supported.

409

Wi-SUN Profile for HAN

30 of 206

HAN Working Group

410

3.4.

411

3.4.1. Overview

412This section defines Wi-SUN 15.4 and 15.4e MAC profiles for MAC part. The capabilities are
generated from standards [802.15.4] and [802.15.4e], and summarized in the Tables.

413
414
415
416
417
418
419

MAC part

Nodes defined by this profile employ 64 bit address out of MAC address modes defined by[802.15.4]. 64 bit EUI-64 address shall be stably allocated to each device. This address is
globally unique and is expected permanently stable for the device.
Clause 3.4.2 defines the support required for Beacon-enabled deployments and Clause
3.4.3 defines the support required for Non-Beacon-enabled deployments. Either of those
two deployments shall be implemented by this data link profile.

420

421

3.4.2. Beacon mode profile

422
423

This sub-clause defines Wi-SUN 15.4 and 15.4e MAC profiles for ECHONET Lite, when
beacon-enabled PAN is employed.

424

3.4.2.1. Functional device (FD) types

425

The requirements for the functional device types are described in Table 4.8-4.

Wi-SUN Profile for HAN

31 of 206

HAN Working Group

Table 4.8-4 Functional device types

426

Status instandard

SupportItemnumberItem description

Reference
section instandard

FD1

FFD[802.15.4] 5.1

O.1

O.1

FD2

RFD

[802.15.4] 5.1

O.1

O.1

FD3

Support of 64 bit
IEEE address[802.15.4]
5.2.1.1.6

M

Y

FD4

Assignment ofshort network
address (16 bit)[802.15.4]
5.1.3.1

FD1:M

FD1:Y

FD5

Support of shortnetwork address(16 bit)[802.15.4]
5.2.1.1.6

M

Y

FD8

SUN PHY device[802.15.4g] 8.1

O.2

Y (#1)(Y:Yes,(M:Mandatory, N:No,
O:Option)
O:Option)

427

429

O.1: Optional but at least one of the features described in FD1 and FD2 is required to be
implemented

430

O.2: At least one of these features is supported

431#1: MR-FSK is employed.

428

432
433

3.4.2.2. Major capabilities for the MAC sub-layer

434

The major capabilities for the MAC sub-layer are described in this sub-clause.

435
436

3.4.2.2.1.MAC sub-layer functions

437

The MAC sub-layer function requirements are described in Table 4.8-5.

Wi-SUN Profile for HAN

32 of 206

HAN Working Group

438

Table 4.8-5 MAC sub-layer functions

Wi-SUN Profile for HAN

33 of 206

HAN Working Group

Item
numberItem description

Reference section
in standard

SupportStatus instandard(M:Mandatory, O:Option)(Y:Yes,
N:No,
O:Option)

MLF1

Transmission of data[802.15.4] 6.3

M

Y

MLF1.1Purge data[802.15.4]6.3.4,6.3
.5

FD1:M

FD1:Y

FD2:O

FD2: NMLF2

Reception of data[802.15.4] 6.3

M

Y

MLF2.1

Promiscuous mode

[802.15.4] 5.1.6.5

FD1:M

FD1:Y

FD2:O

FD2: N

MLF2.2Control of PHY receiver[802.15.4] 6.2.9

ON

MLF2.3

Timestamp of incoming data[802.15.4] 6.3.2

O

N

MLF3

Beacon management[802.15.4] 5

M

Y

MLF3.1

Transmit beacons[802.15.4] 5,
5.1.2.4

FD1:M

FD1:Y

FD2:O

FD2: N

MLF3.2

Receive beacons[802.15.4] 5, 6.2.4

M

Y

MLF4

Channel access mechanism[802.15.4] 5, 5.1.1

M

Y

MLF5

Guaranteed time slot (GTS)
management[802.15.4] 5, 6.2.6,

O

N

O

N

O

N

MLF5.1

5.3.9, 5.1.7

GTS management (allocation) [802.15.4] 5, 6.2.6,
5.3.9, 5.1.7

MLF5.2

GTS management (request)[802.15.4] 5, 6.2.6,
5.3.9, 5.1.7

MLF6

Frame validation[802.15.4] 6.3.3,
5.2, 5.1.6.2

M

Y

MLF7

Acknowledged frame delivery[802.15.4] 5, 6.3.3, M
5.2.1.1.4, 5.1.6.4

Y

Wi-SUN Profile for HAN

34 of 206

HAN Working GroupMLF8

Association anddisassociation[802.15.4] 5, 6.2.2,
6.2.3, 5.1.3

M

Y

MLF9

Security[802.15.4] 7

M

Y

MLF9.1

Unsecured mode

[802.15.4] 7

M

Y

MLF9.2

Secured mode

[802.15.4] 7

OY

MLF9.2.1

Data encryption[802.15.4] 7

O.4

Y

MLF
9.2.2

Frame integrity[802.15.4] 7

O.4

YMLF10.1

ED[802.15.4] 5.1.2.1,
5.1.2.1.1

FD1:M

FD1:Y

FD2:O

FD2: N[802.15.4]
5.1.2.1.2

FD1:M

FD1:Y
FD2:Y

MLF10.2

Active scanning

FD2:O

MLF10.3

Passive scanning[802.15.4]
5.1.2.1.2

M

Y

MLF10.4

Orphan scanning[802.15.4] 5.1.2.1,
5.1.2.1.3

M

Y

MLF11

Control/define/determine/decl
are superframe structure[802.15.4] 5.1.1.1

FD1:O

FD1:O

MLF12

Follow/use superframe
structure[802.15.4] 5.1.1.1

O

Y

MLF13

Store one transaction[802.15.4] 5.1.5

FD1:M

FD1:Y

MLF14

Ranging[802.15.4] 5.1.8

RF4:O

N

MLF14.1

DPS[802.15.4]
5.1.8.3,6.2.15

ON

MLF15(4g)

MPM for all coordinators
when operating at more than
1% duty cycle[802.15.4g] 5.1.13

M

FD8:Y

MLF15

TSCH Capability[802.15.4e]Table
8a

O

N

Wi-SUN Profile for HAN

35 of 206

HAN Working GroupMLF16

LL Capability[802.15.4e]Table
8b

O

N

MLF17

DSME Capability[802.15.4e] 6.2,

O

N

Table 8c
MLF18

EBR capability[802.15.4e] 5.3.12

O

Y

MLF18.1

EBR commands[802.15.4e] 5.3.7

MLF18:OY

MLF18.1.
1

EBR Enhanced Beacon
request command[802.15.4e] 5.3.7.2

FD1:M

FD1:Y
FD2:Y

MLF19

LE capability[802.15.4e]
5.1.1.7, 5.1.11

O

O (#1)

MLF19.1

LE specific MAC sub-layer
service specification[802.15.4e] 6.4.3.7

MLF19:M

MLF19:Y

MLF19.2

Coordinated Sampled
Listening (CSL) capability[802.15.4e]5.1.11.
1

MLF19:O.1

N

MLF19.3

Receiver InitiatedTransmission[802.15.4e]5.1.11.
2

MLF19:O.1

N

FD2:O

(RIT) capability
MLF19.4

LE superframe[802.15.4e]
5.1.1.7.1,
5.1.1.7.2, 5.1.1.7.3

MLF19:O.1

MLF19:Y

MLF19.5

LE-multipurpose Wake-up
frame[802.15.4e]5.2.2.8

MLF19.2:M

N

MLF19.6

LE, CSL Information Element[802.15.4e]5.2.4.7

MLF19.2:M

N

MLF19.7

LE RIT Information Element[802.15.4e]5.2.4.8

MLF19.3:O

N

MLF19.8

LE-commands[802.15.4e]5.3.12

MLF19.3:M

N

MLF20

MAC Metrics PIB Attributes[802.15.4e]6.4.3.9

O

N

MLF21

FastA commands[802.15.4e]5.1.3.3

O

N

MLF23

Channel Hopping[802.15.4e] Table
52f

O

N

Wi-SUN Profile for HAN

36 of 206

HAN Working GroupMLF23.1

Hopping IEs[802.15.4e]5.2.4.1
6,

MLF18:M

N

5.2.4.17
439

441

O.1: Optional but at least one of the features described in FD1 and FD2 is required to be
implemented

442

O.4: At least one of these features shall be supported.

443

#1:

440

Implementation is optional.

444

Wi-SUN Profile for HAN

37 of 206

HAN Working Group445

3.4.2.2.2.MAC frames

446

The MAC frame requirements are described in Table 4.8-6.

Wi-SUN Profile for HAN

38 of 206

HAN Working Group

447

Table 4.8-6 MAC frames

Wi-SUN Profile for HAN

39 of 206

HAN Working Group

Item
numberItem description

Reference
section instandard

Status in standard

Support(M:Mandatory, O:Option)
Transmitter

Receiver(Y:Yes,
N:No,
O:Option)

MF1

Beacon[802.15.4]
5.2.2.1

FD1:M

M

Y

MF2

Data

[802.15.4]
5.2.2.2

M

M

Y

MF3

Acknowledgment[802.15.4]
5.2.2.3

M

M

Y

MF4

Command[802.15.4]
5.2.2.4

M

M

Y

MF4.1

Association
request[802.15.4]
5.2.2.4, 5.3.1

M

FD1:M

Y

MF4.2

Association
response[802.15.4]
5.2.2.4, 5.3.2

FD1:M

M

Y

MF4.3

Disassociation
notification[802.15.4]
5.2.2.4, 5.3.3

M

M

Y

MF4.4

Data request[802.15.4]
5.2.2.4, 5.3.4

M

FD1:M

Y

MF4.5

PAN identifierconflict notification[802.15.4]
5.2.2.4, 5.3.5

M

FD1:M

Y

MF4.6

Orphaned device
notification[802.15.4]
5.2.2.4, 5.3.6

M

FD1:M

Y

MF4.7

Beacon request[802.15.4]
5.2.2.4, 5.3.7

FD1:M

FD1:M

Y

MF4.8

Coordinatorrealignment[802.15.4]
5.2.2.4, 5.3.8

FD1:M

M

Y

MF4.9

GTS request[802.15.4]
5.2.2.4, 5.3.9

MLF5:O

MLF5:ON

MF54-octet FCS[802.15.4g]
5.2.1.9

FD8:M

FD8:M

FD8:Y

448
449

Wi-SUN Profile for HAN

40 of 206

HAN Working Group450

3.4.3. Non-beacon mode profile

451
452

This sub-clause defines Wi-SUN 15.4 and 15.4e MAC profiles for ECHONET Lite, when
non-beacon-enabled PAN is employed.

453

3.4.3.1. Functional device (FD) types

454

The requirements for the functional device types are described in Table 4.8-7.

455

Table 4.8-7 Functional device types

456

Item
numberItem description

FD1

FFD

FD2

Reference
section instandard

Status instandard

Support(M:Mandatory,
O:Option)(Y:Yes,
N:No,
O:Option)[802.15.4] 5.1

O.1

O.1

RFD

[802.15.4] 5.1

O.1

O.1

FD3

Support of 64 bit
IEEE address[802.15.4]
5.2.1.1.6

M

Y

FD4

Assignment ofshort network
address (16 bit)[802.15.4]
5.1.3.1

FD1:M

FD1:Y

FD5

Support of shortnetwork address(16 bit)[802.15.4]
5.2.1.1.6

M

Y

FD8

SUN PHY device[802.15.4g]
8.1

O.2

Y (#1)

457

459

O.1: Optional but at least one of the features described in FD1 and FD2 is required to be
implemented

460

O.2: At least one of these features is supported

461#1: MR-FSK is employed.

458

462
463
Wi-SUN Profile for HAN

41 of 206

HAN Working Group

464
465
466
467
468
469

3.4.3.2. Major capabilities for the MAC sub-layer

470

The major capabilities for the MAC sub-layer are described in this sub-clause.

471
472

3.4.3.2.1.MAC sub-layer functions

473

The MAC sub-layer function requirements are described in Table 4.8-8.

Wi-SUN Profile for HAN

42 of 206

HAN Working Group

474

Table 4.8-8 MAC sub-layer functions

Wi-SUN Profile for HAN

43 of 206

HAN Working Group

Item
numberItem description

Reference
section instandard

Status instandard

Support(M:Mandatory, O:Option)(Y:Yes,
N:No,
O:Option)

MLF1

Transmission of data[802.15.4]
6.3

M

Y

MLF1.1Purge data[802.15.4]
6.3.4, 6.3.5

FD1:M

FD1:Y

FD2:O

FD2: NMLF2

Reception of data[802.15.4]
6.3

M

Y

MLF2.1

Promiscuous mode

[802.15.4]
5.1.6.5

FD1:M

FD1:Y

FD2:O

FD2: N

MLF2.2Control of PHY receiver[802.15.4]
6.2.9

O

O

MLF2.3

Timestamp of incoming data[802.15.4]
6.3.2

O

N

MLF3

Beacon management[802.15.4] 5

M

Y

MLF3.1

Transmit beacons[802.15.4] 5,
5.1.2.4

FD1:M

FD1:Y

FD2:O

FD2: N

MLF3.2

Receive beacons[802.15.4] 5,
6.2.4

M

Y

MLF4

Channel access mechanism[802.15.4] 5,
5.1.1

M

Y

MLF5

Guaranteed time slot (GTS)
management[802.15.4] 5,
6.2.6, 5.3.9,
5.1.7

O

N

MLF5.1

GTS management (allocation)[802.15.4] 5,
6.2.6, 5.3.9,
5.1.7

O

N

Wi-SUN Profile for HAN

44 of 206

HAN Working Group

Item
numberItem description

Reference
section instandard

Status instandard

Support(M:Mandatory, O:Option)(Y:Yes,
N:No,
O:Option)

MLF5.2

GTS management (request)[802.15.4] 5,
6.2.6, 5.3.9,
5.1.7

O

N

MLF6

Frame validation[802.15.4]
6.3.3, 5.2,
5.1.6.2

M

Y

MLF7

Acknowledged frame delivery[802.15.4] 5,
6.3.3,
5.2.1.1.4,
5.1.6.4

M

Y

MLF8

Association and disassociation[802.15.4] 5,
6.2.2, 6.2.3,
5.1.3

M

Y

MLF9

Security[802.15.4] 7

M

Y

MLF9.1

Unsecured mode

[802.15.4] 7

M

Y

MLF9.2

Secured mode

[802.15.4] 7

OY

MLF9.2.1

Data encryption[802.15.4] 7

O.4

YMLF 9.2.2

Frame integrity[802.15.4] 7

O.4

YMLF10.1

ED[802.15.4]
5.1.2.1,
5.1.2.1.1

FD1:M

FD1:Y

FD2:O

FD2: N[802.15.4]
5.1.2.1.2

FD1:M

FD1:Y

FD2:O

FD2: YMLF10.2

Active scanning

MLF10.3

Passive scanning[802.15.4]
5.1.2.1.2

M

Y

MLF10.4

Orphan scanning[802.15.4]
5.1.2.1,
5.1.2.1.3

M

Y

Wi-SUN Profile for HAN

45 of 206

HAN Working Group

Item
numberItem description

Reference
section instandard

Status instandard

Support(M:Mandatory, O:Option)(Y:Yes,
N:No,
O:Option)

MLF11

Control/define/determine/declar
e superframe structure[802.15.4]
5.1.1.1

FD1:O

N

MLF12

Follow/use superframe
structure[802.15.4]
5.1.1.1

O

N

MLF13

Store one transaction[802.15.4]
5.1.5

FD1:M

FD1:Y

MLF14

Ranging[802.15.4]
5.1.8

RF4:O

N

MLF14.1

DPS[802.15.4]
5.1.8.3,6.2.1
5ON

MLF15(4g)

MPM for all coordinators when
operating at more than 1% duty
cycle

[802.15.4g]
5.1.13

M

Y

MLF15

TSCH Capability[802.15.4e]
Table 8a

O

N

MLF16

LL Capability[802.15.4e]
Table 8b

O

N

MLF17

DSME Capability[802.15.4e]
6.2,

O

N

Table 8c
MLF18

EBR capability[802.15.4e]
5.3.12OY

MLF18.1

EBR commands[802.15.4e]
5.3.7

MLF18:O

Y

FD1:M

FD1:Y

FD2:O

FD2: YMLF18.1.1 EBR Enhanced Beacon request [802.15.4e]
command5.3.7.2

Wi-SUN Profile for HAN

46 of 206

HAN Working Group

Item
numberItem description

Reference
section instandard

Status instandard

Support(M:Mandatory, O:Option)(Y:Yes,
N:No,
O:Option)

MLF19

LE capability[802.15.4e]
5.1.1.7,
5.1.11O

O (#1)

MLF19.1

LE specific MAC sub-layer
service specification[802.15.4e]
6.4.3.7

MLF19:M

MLF19:YMLF19.2

Coordinated Sampled Listening(CSL) capability[802.15.4e]
5.1.11.1

MLF19:O.1

MLF19:O.
1

MLF19.3

Receiver Initiated Transmission[802.15.4e]
5.1.11.2

MLF19:O.1

MLF19:O.
1(RIT) capability
MLF19.4

LE superframe[802.15.4e]
5.1.1.7.1,
5.1.1.7.2,
5.1.1.7.3

MLF19:O.1

N

MLF19.5

LE-multipurpose Wake-up
frame[802.15.4e]
5.2.2.8

MLF19.2:M

MLF19.2:Y

MLF19.6

LE, CSL Information Element[802.15.4e]
5.2.4.7

MLF19.2:M

MLF19.2:Y

MLF19.7

LE RIT Information Element[802.15.4e]
5.2.4.8

MLF19.3:O

MLF19.3:
O

MLF19.8

LE-commands[802.15.4e]
5.3.12

MLF19.3:M

MLF19.3:Y

MLF20

MAC Metrics PIB Attributes[802.15.4e]
6.4.3.9

O

N

MLF21

FastA commands[802.15.4e]
5.1.3.3

O

N

MLF23

Channel Hopping[802.15.4e]
Table 52f

O

N

Wi-SUN Profile for HAN

47 of 206

HAN Working Group

Item
number

MLF23.1

Item description

Hopping IEs

Reference
section instandard[802.15.4e]
5.2.4.16,
5.2.4.17

Status instandard

Support(M:Mandatory, O:Option)(Y:Yes,
N:No,
O:Option)

MLF18:M

N

475

477

O.1: Optional but at least one of the features described in FD1 and FD2 is required to be
implemented

478

O.4: At least one of these features shall be supported.

479

#1:

476

Implementation is optional.

480
481

Wi-SUN Profile for HAN

48 of 206

HAN Working Group482

3.4.3.2.2.MAC frames

483

The MAC frame requirements are described in Table 4.8-9.

Wi-SUN Profile for HAN

49 of 206

HAN Working Group

484

Table 4.8-9 MAC frames

Wi-SUN Profile for HAN

50 of 206

HAN Working Group

Item
numberItem description

Reference
section instandard

Status in standard

Support(M:Mandatory, O:Option)
Transmitter

Receiver(Y:Yes,
N:No,
O:Option)

MF1

Beacon[802.15.4]
5.2.2.1

FD1:M

M

Y

MF2

Data

[802.15.4]
5.2.2.2

M

M

Y

MF3

Acknowledgment[802.15.4]
5.2.2.3

M

M

Y

MF4

Command[802.15.4]
5.2.2.4

M

M

Y

MF4.1

Association
request[802.15.4]
5.2.2.4, 5.3.1

M

FD1:M

Y

MF4.2

Association
response[802.15.4]
5.2.2.4, 5.3.2

FD1:M

M

Y

MF4.3

Disassociation
notification[802.15.4]
5.2.2.4, 5.3.3

M

M

Y

MF4.4

Data request[802.15.4]
5.2.2.4, 5.3.4

M

FD1:M

Y

MF4.5

PAN identifier[802.15.4]
conflict notification 5.2.2.4, 5.3.5

M

FD1:M

Y

MF4.6

Orphaned device
notification[802.15.4]
5.2.2.4, 5.3.6

M

FD1:M

Y

MF4.7

Beacon request[802.15.4]
5.2.2.4, 5.3.7

FD1:M

FD1:M

Y

MF4.8

Coordinatorrealignment[802.15.4]
5.2.2.4, 5.3.8

FD1:M

M

Y

MF4.9

GTS request[802.15.4]
5.2.2.4, 5.3.9

MLF5:O

MLF5:ON

MF54-octet FCS[802.15.4g]
5.2.1.9

FD8:M

FD8:M

Y

485
486

Wi-SUN Profile for HAN

51 of 206

HAN Working Group

487

3.5.

488

3.5.1. Overview

489

Wi-SUN ECHONET Lite interface shall be composed of transport layer, network Layer, andadaptation layer. The data from transport/network layer is converted to PHY and MAC layer
data via adaptation layer. On the other hand, the data from PHY/MAC layer is converted to
network/transport layer data via adaptation layer. As transport layer protocol TCP or UDP
may be used.

490
491
492
493

Wi-SUN ECHONET Lite interface part

494

495

3.5.2. Requirement

496(1) Wi-SUN ECHONET Lite interface shall provide Network Interface (NIC). MAC addressin the NIC shall be one that can be extracted from MAC layer.

497
498
499
500
501
502
503
504
505
506
507
508

(2) Wi-SUN ECHONET Lite interface shall know address configuration used in MAC layer
in advance.
(3) Wi-SUN ECHONET Lite interface shall analyze IPv6 header by taking addressconfiguration in MAC layer and convert the destination address in IPv6 header to thedestination address used in MAC layer(4) Wi-SUN ECHONET Lite interface shall analyze IPv6 header. When the destination
address is multicast address, the interface shall instruct MAC layer to do broadcast
transmission.
(5) Wi-SUN ECHONET Lite interface shall use neighbor discovery (ND) function based oneither IPv6 or 6LowPAN. The ND function is chosen not by every node but for every
system.

509
510

3.5.3. Adaptation layer

511
513

The adaptation layer in the Wi-SUN ECHONET Lite Interface shall perform compression of
IPv6 headers according to RFC6282 [6LPHC] and packet fragmentation according to
RFC4944 [6LOWPAN]. The specific configurations are given in Table 4.8-10.

514

Table 4.8-10 Adaption layer of 6LoWPAN

512

SupportItem number
6LP1.1

Item description
Addressing Modes (EUI-64)
Wi-SUN Profile for HAN

Reference section
in standard[6LOWPAN] 3(Y:Yes, N:No,
O:Option)Y
52 of 206

HAN Working Group

6LP1.2
6LP2
6LP3
6LP4
6LP5
6LP6
6LP7
6LP8
6LP9
6LP10

Addressing Modes (short address)
Frame Format
Stateless Address
Autoconfiguration
IPv6 Link Local Address
Unicast Address Mapping
Multicast Address Mapping
Encoding of IPv6 Header Fields
Encoding of UDP Header Fields
Non-Compressed Fields
Frame Delivery in a Link-Layer
Mesh[6LOWPAN] 3[6LOWPAN] 5[6LOWPAN] 6

NO (#1)Y[6LOWPAN] 7[6LOWPAN] 8[6LOWPAN] 9[6LOWPAN] 10.1
[6LOWPAN] 10.2
[6LOWPAN] 10.3
[6LOWPAN] 11

Y
Y (#2)
N
N (#3)N (#3)
Y
N

515

517

(#1) Header Type = LOWPAN_HC1 shall not be used and Header Type = LOWPAN_BC0
and [6LOWPAN] 5.2 are option

518(#2) 16bit address (short address) shall not be used519(#3) For header compression, IPHC[6LPHC] shall be used and HC1 and HC2 in[6LOWPAN] shall not be used.

516

520
521
522

3.5.3.1. Fragmentation

523

The 6LoWPAN fragmentation requirements shall be implemented in Wi-SUN ECHONET
Lite interface are described in Table 4.8-11.

524

Table 4.8-11 Fragmentations of 6LoWPAN

525

Item number

Item description

6LPF1

Fragmentation type and Header

Reference
section instandard[6LOWPAN]
5.3

Support(Y:Yes, N:No,
O:Option)
Y

526
527

3.5.3.2. Header compression

528

The 6LoWPAN Header compression requirements are described in Table 4.8-12.

529

Basically every node shall support header compression described in [6LPHC] but theheader compression used context ID including compression of stateful multicast address
shall not be supported. Moreover, compression for IPv6 extension header and UDP header

530
531

Wi-SUN Profile for HAN

53 of 206

HAN Working Group

532
533
534

by LOWPAN_NHC shall not be supported. The node that has capability to receive IPv6
packet shall receive non-compressed IPv6 packet, IPv6 packet compressed by theconditions in this section, and IPv6 packet partially compressed by [6LPHC].

535
536
537
538
539
540
541
542

Table 4.8-12: 6LoWPAN Header compression

543

Item number

Item description

6HC1.1
6HC1.26HC2.1LOWPAN_IPHC (Base Format)
Context Identifier Extension
Stateless Multicast Address
Compression
Stateful Multicast Address
Compression
LOWPAN_NHC(IPv6 Extension Header
Compression)
LOWPAN_NHC(UDP Header Compression)

6HC2.2
6HC4

6HC5

Reference
section instandard

Support[6LPHC] 3.1.1[6LPHC] 3.1.2[6LPHC] 3.2.3(Y:Yes, N:No,
O:Option)
Y
N
Y[6LPHC] 3.2.4

N[6LPHC] 4.2

N[6LPHC] 4.3

N

544
545
546
547

Since Wi-SUN ECHONET Lite interface shall not support context ID and shall support link
local address based on EUI-64 address for IPv6 packet, LOWPAN_IPHC encoding header[6LPHC] in IPv6 packet shall be composed in Figure4.8-3.

548

Wi-SUN Profile for HAN

54 of 206

HAN Working Group

(bit)
0
1
0
1

2
1

3
4
*1
TF

5
NH *2

6
7
HLIM *3

8
0

9
0

10
1

11
1

12 13 14 15
00
1
1

Figure4.8-3 LOWPAN_IPHC encoding header for unicast packet

549
550

*1: TF = 0b11(Traffic Class and Flow Label are elided)551*2: NH = 0b0(Full 8 bits for Next Header are carried in-line)552*3: HLIM = 0b11(The Hop Limit field is compressed and the hop limit is 255)

553
554
555

When the IPv6 packet is a multicast packet, LOWPAN_IPHC format presented in Figure
4.8-4 and field values specified in Table 4.8-13 are used instead of Figure4.8-3.

556

(bit)
0 1
0 1

2
1

3

4
TF

5
NH

6
7
HLIM

8
9
CID SAC

10 11
SAM

12 13 14 15
M DAC DAM

Figure 4.8-4 LOWPAN_IPHC encoding header for multicast packet

557
558
559

Table 4.8-13 Values to be set into LOWPAN_IPHC for multicast packet

560

FieldsPacket TypeTF

NH HLIM CID SAC SAM

M

DAC

DAM

Bit
3-4

5

12

13

14-15

6-7

8

Solicitednode
multicast for
DAD
0b11 0b0 0b11
Solicitednode
multicastfor ND

9

10-11

1*1

0b00*1
1*2*3 0*2*3

0
0

0b11

Wi-SUN Profile for HAN

0b01*2

Remarks

Destination address
takes the form
FF02::1:FFXX:XXXX,
where “XX:XXXX” isthe low-order 24 bitsof the target address.

55 of 206

HAN Working GroupAny other
type ofmulticastpackets
561
562
563
564
565
566
567
568
569

Destination address takes theform FF02::00XX, where XX is
0b11*30x01 or 0x02 to be specified in
the in-line header.

*1: The UNSPECIFIED address is set to the source address of NS for DAD, as specified in
4.3 of [ND]. It is converted to SAC=1 and SAM=00 according to the method specified in
3.1.1 of [6LPHC]*2: The solicited-node multicast address is set to the destination address of NS, as specified
in 4.3 of [ND]. It is converted to M=1, DAC=0, and DAM=01 according to the method
specified in 3.1.1 of [6LPHC].
*3: A link-local multicast address is set to the destination address of other multicast packet
which is not NS. It is converted to M=1, DAC=0, and DAM=11 according to the method
specified in 3.1.1 of [6LPHC]

570
571

3.5.3.3. Neighbor discovery

572

Wi-SUN ECHONET Lite interface shall support either RFC 4861[ND] or RFC6775 [6LND].
6LoWPAN Neighbor discovery requirements in RFC6775 are described in Table 4.8-14.
The requirements of routing function to realize multihop operation are out of scope of thisdocument.

573
574
575
576
577
578
579
580
581
582

Table 4.8-14 6LoWPAN Neighbor discovery

Wi-SUN Profile for HAN

56 of 206

HAN Working Group

Item number
6ND1
6ND2
6ND3
6ND4
6ND5
6ND6
6ND7
6ND8
6ND9
6ND10
6ND11
6ND12
6ND13
6ND14
6ND15
6ND16
6ND17
6ND18
6ND19
6ND20
6ND21
6ND22

Item description
DHCPv6 Address Assignment
for 6LBR, 6LR and Host
DHCPv6 Prefix Delegation for
6LBR
DHCPv6 Prefix Delegation for
6LR and Host
Static IPv6 addressconfiguration on 6LBR
Static IPv6 addressconfiguration on 6LR and Host
EUI-64 based IPv6 Address
Generation
802.15.4 16-bit short address
802.15.4 64-bit extended
address
Duplicate Address Detect
Duplicate Address messages(DAR and DAC)
Support Source Link-Layer
Address Option (SLLAO)
Support Address Registration
Option (ARO)
Support Authoritative BorderRouter Option (ABRO)
Support Prefix Information
Option (PIO)
Support 6LoWPAN Context
Option (6CO)
Multihop Prefix and Context
Distribution
Multihop DAD
Support Router Discovery
Support RA based Address
Configuration on 6LR and Host
Support Neighbor Cache
Management
Support Address Registration
Support Address unregistration
Wi-SUN Profile for HAN

Reference
section instandard[6LPND] 3.2

Support(Y:Yes, N:No,
O:Option)O[6LPND] 3.2,
7.1
[6LPND] 3.2,
7.1
[6LPND] 5.4.1

O[6LPND] 5.4.1

O[6LPND] 5.4.1

Y[6LPND] 1.3[6LPND] 1.3

O
Y[6LPND] 4.4[6LPND] 4.4

O
O[6LPND] 4.1,
5.3
[6LPND] 5.5

Y[6LPND] 3.3,
3.4, 4.3, 6.3[6LPND] 3.3,
5.4
[6LPND] 4.2

O[6LPND] 8.1

O[6LPND] 8.2[6LPND][6LPND]5.4.1

O
YO[6LPND] 3.5

Y[6LPND] 3.2[6LPND] 3.2

Y
Y

O
O

Y

O
O

57 of 206

HAN Working Group

6ND23
6ND24
6ND25

Support Neighbor Unreachable
Detection
Send Multicast NS
Send Unicast NS[6LPND] 5.5

Y[6LPND] 6.5.5[6LPND]5.5

O
Y

583
584

3.5.4. Network layer

585

Wi-SUN ECHONET Lite interface shall support IPv6 protocol [IPv6] in Table 4.8-15. Hop-byhop options extension header, Routing extension header, Fragment extension header,
Destination Options extension header, AH extension header, and ESP extension header are
optional. Wi-SUN ECHONET Lite interface also shall support ICMPv6 protocol [ICMPv6] inTable 4.8-16. Wi-SUN ECHONET Lite interface shall support Echo Request Message(type=128) and Echo Reply Message (type=129), Destination Unreachable Message(type=1), Time Exceeded Message (type=3) and Parameter Problem Message (type=4).
For Packet Too Big Message (type=2), Wi-SUN ECHONET Lite interface may not support
transmission function but may support receipt function.

586
587
588
589
590
591
592
593
594
595

Item number
IP1
IP1.1
IP1.2
IP1.3
IP1.4
IP1.5
IP1.6
IP1.7
IP1.8
IP1.9
IP1.10
IP2
IP3
IP4
IP5

Table 4.8-15 Network Layer: IPv6
Reference
Item description
section instandard
Header Format[IPv6] 3
Extension Headers
Extension Header Order[IPv6]4.1
Options[IPv6] 4.2
Hop-by-Hop Options Header[IPv6] 4.3
Routing Header[IPv6]4.4
Fragment Header[IPv6] 4.5
Destination Options Header[IPv6] 4.6
No Next Header[IPv6]4.7
AH Header[AH]
ESP Header[ESP]
Deprecation of Type 0 Routing[IPv6-RH]
Headers
Path MTU Discovery[IPv6] 5
Flow Labels[IPv6] 6
Traffic Classes[IPv6] 7

Support(Y:Yes, N:No,
O:Option)
Y
Y
Y
Y
O
O
O
O
Y
O
O
Y
Y
Y
Y

596

Wi-SUN Profile for HAN

58 of 206

HAN Working Group597

Item number
ICMP1
ICMP2
ICMP3
ICMP4
ICMP5
ICMP6
ICMP7
ICMP8
ICMP9
ICMP10

Table 4.8-16 Network Layer: ICMPv6
Reference
Item description
section instandard
Message Format[ICMP6] 2.1
Message Source Address[ICMP6] 2.2
Determination
Message Checksum Calculation[ICMP6] 2.3
Message Processing Rules[ICMP6] 2.4
Destination Unreachable[ICMP6] 3.1
Message
Packet Too Big Message[ICMP6] 3.2
Time Exceeded Message[ICMP6] 3.3
Parameter Problem Message[ICMP6] 3.4
Echo Request Message[ICMP6] 4.1
Echo Reply Message[ICMP6] 4.2

Support(Y:Yes, N:No,
O:Option)
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y

598
599

3.5.4.1. IP addressing

600

Wi-SUN ECHONET Lite interface shall support IPv6 addressing [IP6ADDR] and IPv6
Stateless Address Autoconfiguration [SLAAC] defined in Table 4.8-17. Wi-SUN ECHONET
Lite interface shall support link local address based on EUI-64. In the case, according todescription in [6LOWPAN] and [SLAAC], well known link-local prefix FE80::0/64 shall be
used as prefix and interface identifier shall be generated from EUI-64 address. IPv6 linklocal address, global address, and unique local address derived the short address definedin [802.15.4] shall not be used.

601
602
603
604
605
606
607

Table 4.8-17 IP Addressing

Wi-SUN Profile for HAN

59 of 206

HAN Working Group

Item number

Item description

IPAD1
IPAD1.1

IPv6 Addressing
Global Unicast Address

IPAD1.2

Link Local Unicast Address

IPAD1.3
IPAD1.4
IPAD1.5
IPAD1.6
IPAD2

Unique Local Unicast Address
Anycast Address
Multicast Address
Prefix Length
Stateless Address
Autoconfiguration
Creation of Link Local Address
Creation of Global Addresses

IPAD2.1
IPAD2.2

Reference
section instandard[IP6ADDR][IP6ADDR]
2.5.4[IP6ADDR]
2.5.6
[ULA]
[IP6ADDR] 2.6[IP6ADDR] 2.7

Support(Y:Yes, N:No,
O:Option)
Y (*1)N
Y (*2)[SLAAC]NN
Y (*3)/64Y[SLAAC] 5.3[SLAAC] 5.5

Y
N

608
609
610
611

(*1) Some of the functions may not be used.
(*2) EUI-64 address based Link Local Address shall be supported.
(*3) ff02::1 shall be used for transmission.

612
613

Wi-SUN Profile for HAN

60 of 206

HAN Working Group614

3.5.4.2. Neighbor discovery

615

Wi-SUN ECHONET Lite interface shall support either RFC 4861[ND] or RFC6775 [6LND].
IPv6 Neighbor discovery requirements in RFC4861 are described in Table 4.8-18. Wi-SUN
ECHONET Lite interface shall support two functions: Address Resolution and Duplicate
Address Detection and shall support two messages: Neighbor Solicitation message: Type =135 and Neighbor Advertisement message: Type = 136.

616
617
618
619
620

622

Table 4.8-18 IPv6 Neighbor discovery
Reference
SupportItem number
Item description
section in(Y:Yes, N:No,
standard
O:Option)
ND1
Router and Prefix Discovery
[ND]6
N
ND2
Address Resolution[ND] 7.2
Y
ND3
Neighbor Unreachability[ND] 7.3
N
Detection
ND4
Duplicate Address Detection[SLAAC] 5.4
O
ND5Redirect Function[ND] 8N
ND6Router Solicitation Message[ND]4.1
N
ND7
Router Advertisement Message[ND] 4.2
N
ND8
Neighbor Solicitation Message[ND] 4.3Y(*1)
ND9Neighbor Advertisement[ND] 4.4
Y(*2)
Message
ND10
Redirect Message[ND] 4.5
N
ND11
Source/Target Link-layer[ND] 4.6.1
Y
Address Option
ND12
Prefix Information Option[ND] 4.6.2
N
ND13
Redirected Header Option[ND] 4.6.3
N
ND14
MTU Option[ND] 4.6.4
N*1: The Source Link-Layer Address option contains an EUI-64 format address.

623*2: The Target Link-Layer Address option contains an EUI-64 format address.

621

624
625

3.5.4.3. Multicast

626

In transmitting multicast packet for ECHONET Lite, ff02::1 is set as destination address
based on [EL].

627
628

Wi-SUN Profile for HAN

61 of 206

HAN Working Group629

3.5.5. Transport layer

630

UDP [UDP] shall be implemented and TCP [TCP], may be implemented. The destination
port number of UDP and TCP frames and operation procedure for TCP shall follow thespecification in [EL].

631
632
633

634

3.5.6. Application layer

635

Wi-SUN ECHONET Lite interface shall support ECHONET Lite [EL] as application layer.
The node implemented specifications in this document shall support mandatory function
defined in [EL].

636
637
638

Wi-SUN Profile for HAN

62 of 206

HAN Working Group639

3.5.7. Security configuration

640

3.5.7.1. Overview

641

This clause describes a security mechanism for single-hop network.

642
643

PANA [PANA] shall be used as the EAP [EAP] transport for authentication between thecoordinator and a host.

644

EAP-PSK [EAP-PSK] shall be used as the EAP method carried in PANA messages.

645

The coordinator and the host share a link key after successful authentication. The link key
shall be used for AES-128-CCM* ciphering described in [802.15.4] MAC layer security.

646
647
648

3.5.7.2. Authentication

649

The coordinator shall be PANA Authentication Agent (PAA) and the host shall be PANA
Client (PaC).

650
651
652

3.5.7.2.1.PANA

653⚫

PANA messages shall be sent using IPv6 UDP.

654⚫

PaC knows the IP address of PAA before starting PANA session negotiation.

655⚫

The UDP destination port number shall be set to 716.

656⚫

The PANA session shall be initiated by the PaC.

657⚫

Compliant nodes shall support PRF_HMAC_SHA2_256 (AVP Value=5).

658⚫

Compliant nodes shall support AUTH_HMAC_SHA2_256_128 (AVP Value=12).

659⚫

An EAP-Response should be piggybacked on the PANA-Auth-Answer message.

660⚫

The length of the nonce value in the Nonce AVP shall be 16 octets.

661⚫

The lifetime value in the Session-Lifetime AVP shall not be set less than 60 seconds.

662
663

3.5.7.2.2.EAP

664⚫

EAP-PSK shall be used.

665⚫

The length of the pre-shared key is 16 octets.
Wi-SUN Profile for HAN

63 of 206

HAN Working Group⚫

The length of Master Session Key (MSK) and Extended Master Session Key (EMSK) is
64 octets.

668⚫

EAP Server ID (ID_S) and peer’s ID (ID_P) shall use Network Address Identifier (NAI).

669⚫

The length of ID_S and ID_P shall not be greater than 63 octets.

670⚫

The retransmission in EAP layer shall not be used.

666
667

671
672

3.5.7.3. Key generation

673

The lifetime of the link key which shared with the peer after PANA session establishment
shall be the same as the PANA session lifetime. Both PAA and PaC shall use the newest
derived key after PANA session renewal (PANA Re-Authentication phase or Authentication
and Authorization phase). If a PANA session is terminated before the PANA session lifetime
expiration, any keys derived in this session shall be revoked.

674
675
676
677
678
679

3.5.7.3.1.PANA

680

The following algorithms shall be used for PANA message authentication.
Table 4.8-19 PANA algorithm types (defined in [HMAC-SHA256])

681

Algorithm

Type

Value

PRF

PRF_HMAC_SHA2_256

5

PANA_AUTH_HASH

AUTH_HMAC_SHA2_256_128

12

682
683

3.5.7.3.2.EAP-PSK

684

See [EAP-PSK].

685
686

3.5.7.3.3.MAC layer security (link key)687

The link key (LK) is derived from the EMSK after successful PANA negotiation.

688

The master secret Usage-Specific Root Key (USRK) is generated by Key Derivation
Function (KDF). The KDF is described in [USRK] and then the LK is derived from the
USRK.

689
690

Wi-SUN Profile for HAN

64 of 206

HAN Working GroupUSRK = KDF(EMSK, “String(*1)” | “\0” | optional data | length)•

optional data = NULL(0x00)•

length = 64

LK = KDF(USRK, “String(*2)” | “\0” | optional data | length)•

optional data = EAP ID_P | EAP ID_S | IEEE802.15.4 Key Index•

length = 16

*1,*2: These strings are defined in each recommended usage sections.
691
692
693
694
695
696
697
698

The KDF algorithm is the same as the PANA PRF (PRF_HMAC_SHA2_256). The length
value in the KDF is unsigned 8-bit integer. The IEEE 802.15.4 Key Index is the lower 8-bit
value of the MSK Identifier in Key-Id AVP.
PAA shall not assign consecutively MSK Identifiers that has same lower 8-bit value to thesame PaC.
As the result of successful PANA authentication, a LK is shared between the PAA and the
PaC.

699
700

3.5.7.4. Encryption and Integrity check in MAC layer

701

MAC data frame shall be ciphered by the LK described in [802.15.4].

702

Compliant nodes shall use the newest LK in every PANA session renewal.

703

The Frame Counter value in the MAC frame shall be set to zero in every renewal of LK.

704
705

The host shall renegotiate new PANA session before the incoming/outgoing Frame Counter
overflow.

706

ENC-MIC-32 (security level 5) shall be used for MAC layer security.

707

Both coordinator and host shall discard invalid MAC frame.

708

Key identifier mode is 0x01, Key Source is not used (1 octet Key-Index).

Wi-SUN Profile for HAN

65 of 206

HAN Working Group

709
710
711
712

All PANA messages (UDP destination port 716) and IPv6 Neighbor Solicitation (NS)(ICMPv6 Type 135 Code 0)/Neighbor Advertisement (NA) (ICMPv6 Type 136 code 0)
messages shall not be applied MAC layer security (do not add MAC Auxiliary Security
header).

713
714

3.5.7.5. Replay protection

715

All ciphered MAC frames are protected from replay attacks by checking Frame Countervalue in MAC Auxiliary Security header.

716
717

718

3.5.8. Frame format

719

A sample procedure of frame formatting in the case of UDP communication is shown in
Figure4.8-5 –Figure4.8-8.

720

Variable
ECHONET Lite Payload

721

Figure4.8-5 ECHONET-Lite payload

722
723

724

40 byte0 – n byte

8 byteVariable

IPv6 Header

Ext Header

UDP Header

ECHONET
Lite Payload

Figure4.8-6 IPv6 frame configured by Wi-SUN ECHONET Lite interface

725

726

2 byteDepends on
LOWPAN_IPHCLOWPAN_IP
HC Encoded

In-line IP
fields

0 – n byte

Variable

In-line UDP
HeaderFieldsECHONET
Lite
PayloadFigure4.8-7 6LowPAN frame configure by Wi-SUN ECHONET Lite interface

727

Variable

2 byteDepends on
LOWPAN_IPHC

0 – n byte

Wi-SUN Profile for HAN

Variable

2 byte66 of 206

HAN Working GroupIEEE802.1
5.4 header
728

LOWPAN_I
PHC
Encoded

In-line IP
fieldsIn-line UDP
HeaderFieldsECHONET
Lite Payload

FCS

Figure4.8-8 IEEE802.15.4 frame configured by MAC layer

729
730

Wi-SUN Profile for HAN

67 of 206

HAN Working Group731

3.6. Recommended usage for single-hop home network732

3.6.1. Overview

733

This clause clarifies the recommended usage in constructing single-hop network for
ECHONET Lite over IPv6. Note that this profile does not exclude other usages.

734
735
736
737
738
739

Compliant nodes to this clause constructs single hop network where a coordinator iscentered. And, with assuming a gateway connection provided by application layer as theconnection measure to the outer networks, a closed IP network is assumed inside thisprofile. On those assumptions, the indoor network construction based on ECHONET Lite
provides expandability as well as feasibility.

740

741

3.6.2. PHY part

742

Required specifications in terms of IEEE 802.15.4/4e/4g standards in order to realize thisusage are shown in Table 4.8-20 and Table 4.8-21.

743
744

Table 4.8-20 Device/PHY layer specifications in order to realize the usage

745

Recommend
Recommend
Recommend
Item
Item
Item
Item
(Y:Yes,(Y:Yes,(Y:Yes,numbernumbernumbernumber
N:No,
N:No,
N:No,
*1
*2
*3
*3
O:Option)
O:Option)
O:Option)
FD1
O.1
PLF1 Y
RF12―
RF13.4

FD2
FD3
FD4
FD5
FD8

O.1
Y
N
N
Y

PLF2 YPLF3 YPLF4 YPLF4.1 Y
PLF4.2 N
PLF4.3 N

RF12.1
RF12.2
RF12.3
RF12.4
RF12.5
RF12.6

Wi-SUN Profile for HAN

Y
N
N
N
N
Y

RF13.5
RF14
RF14.1
RF14.2
RF14.3
RF14.4

Recommend(Y:Yes,
N:No,
O:Option)
Supporting
100kbps
only OR
both of
100kbpsand 50kbps
N
―
N
N
Y
N

68 of 206

HAN Working Group

PLP1

PSDU size
up to 255
octets

RF13

―

746
747
748
749
750

*1: Corresponding to item number in Table 4.8-7 Functional device types*2: Corresponding to item number in Table 4.8-2 PLF and PLP capabilities PLF and PLP
capabilities*3: Corresponding to item number in Table 4.8-3 RF capabilities

751
752
753
754
755

Table 4.8-21: Additional PHY layer specifications in order to realize the usage
Parameters
Modulation scheme
Data rate
Transmission power
Frequency channel

Frequency channel
widthTransmission
preamble length
Preamble length
assumed at receiver

Recommend
GFSK
100kbps or 50kbps
20mW or less
Channels of No. 33 to 60 definedby ARIB with bundling of an odd
channel and the next evenchannel, or channels of No. 33 to
61 without bundling.
400kHz (with 2 channel bundling),
or 200kHz
1200us - 4000us

Remarks

Channels of No. 33 to 38 are
also utilized by systems
employing 250 mW
transmission power.

1200us756

757

3.6.3. MAC part758

3.6.3.1. MAC layer specifications

759

Required specifications in terms of IEEE 802.15.4/4e/4g standards in order to realize therecommended usage by ECHONET Lite are shown in Table 4.8-22. Non-beacon enabled
configurations are selected by MAC layer when these specifications are deployed.

760
761

Wi-SUN Profile for HAN

69 of 206

HAN Working Group

762

Table 4.8-22 MAC layer specifications in order to realize the usage

763
764

765
766
767
768
769
770
771
772
773
774
775

Recommend
Item
Item(Y:Yes,numbernumber
N:No,*1*1
O:Option)

Recommend(Y:Yes, N:No,
O:Option)

Recommend
Recommend
Item number (Y:Yes,
Item number(Y:Yes, N:No,
*1
N:No,
*2
O:Option)
O:Option)

MLF1

MLF7

Y

MLF15

N

MF1

Y

MLF1.1 O*3*5

MLF8

O*6

MLF16

N

MF2

Y

MLF2

MLF9

Y

MLF17

N

MF3

Y

MLF2.1 N

MLF9.1

Y

MLF18

Y

MF4

Y

MLF2.2 O*4

MLF9.2Y

MLF18.1

Y

MF4.1

O*6

MLF2.3 N

MLF9.2.1

Y

MLF18.1.1

Y

MF4.2

O*6

MLF3

MLF9.2.2

Y

MLF19

N*8

MF4.3

O*6

MLF3.1 Y*5

MLF10.1

Y*5

MLF19.1

N*8

MF4.4

O*3

MLF3.2 Y

MLF10.2

Y

MLF19.2

N*8

MF4.5

N

MLF4

Y

MLF10.3

N

MLF19.3

N

MF4.6

O*3

MLF5

N

MLF10.4

O*3

MLF19.4

N

MF4.7

Y*9

MLF5.1 N

MLF11N

MLF19.5

N*8

MF4.8

O*3

MLF5.2 N

MLF12N

MLF19.6

N*8

MF4.9

N

MLF6

MLF13

O*3

MLF19.7

N

MF5

Y*10

MLF15(4g) O*7

MLF19.8

N

MLF20

N

MLF21

N

MLF23

N

Y
Y

Y

Y

MLF23.1
N*1: Corresponding to item number in Table 4.8-8 MAC sub-layer functions*2: Corresponding to item number in Table 4.8-9 MAC frames*3: Not mandated for the network constructed only by devices with permanent power supply.
*4: May be employed as necessary.
*5: Not employed by FD2.
*6: Not mandated when done by upper layer.
*7: Employed when 50kbps and 100kbps modes coexist.
*8: Not employed since single-hop communications are assumed.
*9: May be employed by FD2 (not clarified in references).
*10: 2-octet FCS is employed when PSDU size is no more than 255 octets

776

3.6.3.2. MAC frame format

777

This section describes frame format, based on [802.15.4] 5.2 MAC frame formats.

Wi-SUN Profile for HAN

70 of 206

HAN Working Group

778
779
780
781

Enhanced Beacon and Enhanced Beacon Request are not allowed to be encrypted. Any
frame shall not be encrypted if it contains IEs.
Header IE shall not be used and Payload IE follows MHR without Header IE list terminatorwhen IEs List Present field in the frame control is one.

782
783

Note that this omission of Header IE list terminator may be incompatible with [802.15.4e].

784
785

3.6.3.2.1.Data frame format

786

Figure 4.8-9 shows the DATA frame format used in this specification. (Clarifies the usage inthis specification, based on [802.15.4e] 5.2.2.2 Data frame format)

787

255 octets or lessOctets:2

1

2

Frame
ControlSequence
NumberDestination
PAN
Identifier

2/8

8

0/6

Destination
Address

SourceAddress

Auxiliary
Security
HeaderVariable2

Frame
PayloadFCS

MAC Payload

MFR

Addressing fields
MHR

788

Figure 4.8-9 DATA frame format

789
790
791

(1) Frame Control field

792

The fields of the Frame Control field are shown in Table 4.8-23.
Table 4.8-23 Frame Control (DATA frame)

793

bit

fieldsremark

2-0

Frame Type"001", meaning DATA frame

3

Security Enable

4

Frame Pending"0" if the security is disabled, "1" if security isenabled.
"0", do not use

Wi-SUN Profile for HAN

71 of 206

HAN Working Group5

AR (Ack Request)"0" in case ACK is not requested (broadcast),"1" in case ACK is requested (unicast)

6

PAN ID Compression"0", based on [802.15.4e] Table 2a7

Reserved

as a rule set to "0", but don't care

8

Sequence Number Suppression"0", do not suppress Sequence Number field

9

IE List Present"0", do not use IEs.

1110

Destination Addressing Mode"11", for 64 bit extended address

1312

Frame Version"10", for extended format*1,*2

1514

Source Addressing Mode"11", for 64 bit extended address"10", for 16-bit broadcast address

795*1:This field is always set to 0b10 to indicate a frame non-compatible with 802.15.42003/2006, because enhanced acknowledgment frame is assumed.

796*2:ECHONET Lite profile assumes the following specifications:

797a) ECHONET Lite devices shall be capable of receiving a beacon, data, acknowledgment
and command frames (frames with frame type field set to 0,1,2 or 3) with the frame version
field set to 10b and process the frame according to 802.15.4;

794

798
799
800
801
802
803
804

b) ECHONET Lite devices may be capable of receiving a beacon, data, acknowledgment
and command frame with frame version field set to 00 or 01, and will process the frame
according to 802.15.4;c) ECHONET Lite devices shall, when generating beacon, data, acknowledgment andcommand frame, set the frame version field to 10b" to this table.

805
806

(2) Sequence Number field

807

See [802.15.4] 5.2.1.2 Sequence Number field.

808
809

(3) Addressing field

810

Source address is 64-bit MAC address and destination address is either 16-bit broadcast
address (0xFFFF) or 64-bit MAC address. These address fields are transmitted leastsignificant octet first and each octet shall be transmitted least significant bit (LSB) first.

811
812

Wi-SUN Profile for HAN

72 of 206

HAN Working Group

813
814

The source PAN Identifier is not included in the address field. PAN Identifier is transmitted
from LSBit, treated as 16-bit numerical number.

815
816

(4) Auxiliary Security Header field

817

Table 4.8-24 shows the fields of the Auxiliary Security Header that is used to encrypt theframe.

818

Table 4.8-24 Auxiliary Security Header

819
octet

bit

fields1

b2-b0

Security
Controlb4-b3

remarkb7-b5

Security Level"101", for ENC-MIC-32

Key Identifier Mode"01" for 1 octet Key Identifier

Reserved-

4-

Frame Counter1-

Key Identifier

820
821

3.6.3.2.2. ACK frame format

822

Figure 4.8-10 shows the ACK frame format used in this specification. (clarifies the usage inthis specification, based on [802.15.4e] 5.2.2.3 Acknowledgment frame format）

823

Octets:2

1

2

8

Frame
ControlSequence
NumberDestination
PAN
Identifier

Destination
Address2
FCS

Addressing fields
MHR

MFR

824

Figure 4.8-10 ACK frame format

825
826
827

(1) Frame Control field

828

Table 4.8-25 shows the fields of the Frame Control field.

Wi-SUN Profile for HAN

73 of 206

HAN Working Group

Table 4.8-25 Frame Control (ACK frame)

829

bit

fieldsremark

2-0

Frame Type"010", meaning ACK frame

3

Security Enable"0", security is disabled

4

Frame Pending"0", do not use

5

AR(Ack Request)

set to "0"6

PAN ID Compression"0", based on [802.15.4e] Table 2a7

Reserved

set to "0"8

Sequence Number Suppression"0", do not suppress Sequence Number field

9

IE List Present"0" , do not use IEs

1110

Destination Addressing Mode"11", for 64 bit extended address

1312

Frame Version"10", for extended format

1514

Source Addressing Mode"00", do not use Source Address

830
831

(2) Sequence Number field

832

Refer to [802.15.4] 5.2.1.2 Sequence Number field. Ack frame uses the same value of thereceived Data frame in response.

833
834
835

(3) Addressing field

836

Destination Address is set to the Source Address of the received frame to respond. Refer tosection 3.6.3.2.1 DATA frame format (3) Addressing field of this specification.

837
838
839

3.6.3.2.3.Enhanced Beacon frame format

840

Figure 4.8-11 shows the Enhanced Beacon frame format used in this specification. (clarifies
the usage in this specification, based on [802.15.4e] 5.2.2.1 Beacon frame format).

841

Wi-SUN Profile for HAN

74 of 206

HAN Working Group

Octets:2

Frame
Control1

Sequence
Number2

8

Destination
Destination
PAN
Address
Identifier

8
SourceAddress

Variable2

PayloadIE

FCS

MAC Payload

MFR

Addressing fields
MHR
842

Figure 4.8-11 Enhanced Beacon frame format

843
844
845

(1) Frame Control field

846

Table 4.8-26 shows the fields of the Frame Control field.
Table 4.8-26 Frame Control (Enhanced Beacon frame)

847

bit

fieldsremark

2-0

Frame Type"000", meaning Beacon frame

3

Security Enable"0", security is disabled

4

Frame Pending"0", do not use

5

AR (Ack Request)"1", ACK is requested (unicast)

6

PAN ID Compression"0", based on [802.15.4e] Table 2a7

Reserved

as a rule set to "0", but don't care

8

Sequence Number Suppression"0", do not suppress Sequence Number field

9

IE List Present"1" , in case use IEs, "0" in case do not use IEs

1110

Destination Addressing Mode"11", for 64 bit extended address

1312

Frame Version"10" required for Enhanced Beacon

1514

Source Addressing Mode"11", for 64 bit extended address

848
849

(2) Sequence Number field
Wi-SUN Profile for HAN

75 of 206

HAN Working Group

850
851

Based on [802.15.4e] 5.2.2.1.1 Beacon frame MHR fields, Sequence Number (macEBSN)
held by the device.

852
853

(3) Addressing field

854
855

Destination Address is set to the source address of the enhancement beacon request. Referto section 3.6.3.2.1 DATA frame format (3) Addressing field of this specification.

856

Destination PAN Identifier is set to the source PAN Identifier.

857
858

(4) Payload IE field859

The same IEs of the Enhanced Beacon Request.

860
861

3.6.3.2.4. Enhanced Beacon request command frame format

862

Figure 4.8-12 shows the Enhanced Beacon request command frame format used in thisspecification. (Clarifies the usage in this specification, based on [802.15.4e] 5.3.7.2
Enhanced beacon request)

863
864

Octets:2

Frame
Control

1

2

2

Destination
Destination
PAN
Address
Sequence
Identifier
Number8
SourceAddress

Variable

PayloadIE

12

Command
FCS
Frame
Identifier

Addressing fields
MHR

MAC Payload

MFR

865

Figure 4.8-12 Enhanced Beacon request command frame format

866
867
868

(1) Frame Control field

869

Table 4.8-27 shows the fields of the Frame Control field.
Table 4.8-27 Frame Control (Enhanced Beacon request command frame)

870

bit

fieldsremark
Wi-SUN Profile for HAN

76 of 206

HAN Working Group

2-0

Frame Type"011", meaning MAC command

3

Security Enable"0", security is disabled

4

Frame Pending

"0",

5

AR (Ack Request)"0", ACK is not requested (broadcast)

6

PAN ID Compression"0", based on [802.15.4e] Table 2a7

Reserved

set to "0"8

Sequence Number Suppression"0", do not suppress Sequence Number field

9

IE List Present"1" , in case use IEs, "0" in case do not use IEs

1110

Destination Addressing Mode"10", for 16-bit broadcast address

1312

Frame Version"10" required for Enhanced Beacon Request

1514

Source Addressing Mode"11", for 64 bit extended address

do not use

871
872

(2) Sequence Number field

873

Refer to [802.15.4] 5.2.1.2 Sequence Number field

874
875

(3) Addressing field

876

Refer to section 3.6.3.2.1 DATA frame format (3) Addressing field of this specification.

877
878

(4) Payload IE field

879

Refer to section 3.6.6.1.1 MAC procedure

880
881

(5) Command Frame Identifier field882"0x07",based on [802.15.4e] Table 5.

883
884

3.6.3.3. MAC functional description

885This section describes the MAC features of this specification.
Wi-SUN Profile for HAN

77 of 206

HAN Working Group

886
887

3.6.3.3.1.Transmission timing

888(1) Transmission timing of DATA frame

889

Figure 4.8-13 shows the transmission timing of DATA frame. (Clarifies the timing descriptionof this specification, based on [802.15.4] 5.1.1.4 CSMA-CA algorithm, [802.15.4g] Table 51)

890
891

aUnitBackoffPeriod

any Frame

DATA Frame
LIFS

Backoff

phyCCADuration RX to TX TurnaroundTime
CSMA-CA892

parameter *1

formulanominal value *2 [μsec]

LIFS

aTurnaroundTime

1000

aUnitBackoffPeriod

phyCCADuration＋
aTurnaroundTime

1130

phyCCADuration－

130

RX to TX
TurnaroundTime－

300 or more , 1000 or
less

893

*1: Refer to 3.6.3.3.5 of this specification894*2: For the error range of each value, refer to [802.15.4], [802.15.4e], [802.15.4g].

895

Figure 4.8-13 Transmission timing description of DATA frame

896
897

(2) Transmission timing of ACK frame

898

Figure 4.8-14 shows the transmission timing of ACK frame. (Clarifies the timing descriptionof this specification, based on [802.15.4] 5.1.1.3 Interframe spacing (IFS))

899

Wi-SUN Profile for HAN

78 of 206

HAN Working Group

ACK requested Frame

ACK
tack

900
901

parameter*1
tackformulanominal value [μsec]

RX to TX TurnaroundTime

300 or more, 1000 orless *2902*1: Refer to 3.6.3.3.5 of this specification903*2: TX to RX TurnaroundTime shall be 300μs or less.

904

Figure 4.8-14 Transmission timing description of ACK frame

905
906

3.6.3.3.2.CSMA-CA

907

Figure 4.8-15 shows the CSMA-CA algorithm including retry. (Clarifies CSMA-CA algorithm
including retry of this specification, based on [IEEE802.15.4e] 5.1.1.4 CSMA-CA algorithm)

908

Wi-SUN Profile for HAN

79 of 206

HAN Working Group

Frame Transmission

NR = 0

NB = 0BE = macMinBE

Delay forRandom(2BE-1)×aUnitBackoffPeriod

NB： number of back offBE： backoff exponent
macMinBE： minimum BE
macMaxBE： maximum BE
macMaxCSMABackoffs ： maximum NB
NR： number of retries
macMaxFrameRetries ： maxmum NR

Perform CCA

N
Channel Idle ?
NB = NB + 1
BE = min(BE+1,macMaxBE)

Y
Transmit FrameN
NB＞macMaxCSMAbackoffs ?
N
Unicast FrameYYNUnicast Frame

Receive ACK within
waiting time for ACKNYNR = NR + 1

YN
NR＞macMaxFrameRetries ?

Y

Success909

Wi-SUN Profile for HAN

Failure (drop the frame)

80 of 206

HAN Working Group

Figure 4.8-15 CSMA-CA algorithm

910
911
912

3.6.3.3.3.Backoff operation

913

Figure 4.8-16 shows the backoff operation of this specification. The operation isprincipally based on the description of the [802.15.4] 5.1.1.4 CSMA-CA algorithm except forthat ECHONET Lite profile assumes optional capability of receiving frames in the backoff
period. When a node receives a frame in the backoff period, the backoff process issuspended till the receiving is finished and then resumed. (See node 3 in Figure 4.8-16.) In
Figure 4.8-16, 'backoff(first)' and 'backoff(second)' reveal backoffs activated when NB is 0
and NB is 1, respectively.

914
915
916
917
918
919
920

backoff（first）
CCA

LIFS

TX Frame

RX Frame

RX Frame

Node 1
Send request
backoff（first）

backoff（second）

RX Frame

TX Frame

Node 2
Backoff(first)（Suspend）

Backoff(first)（Remaining）

RX Frame

TX Frame

RX Frame

Node 3921

Send request

Node
Node

Description of Operation
1

Idle at CCA after backoff (first)-> Transmission

Node 2Busy at CCA after backoff (first)-> Waiting for Idle (If possible, receive data) *1-> Idle at CCA after backoff (second)-> Transmission

Node 3

Data reception during the backoff (first)-> Idle transition after receiving data-> Idle at CCA after remaining backoff (first)-> Transmission
Wi-SUN Profile for HAN

81 of 206

HAN Working Group922

In this figure the ACK frame is not shown.

923*1: If busy at CCA, it is implementation dependent whether to receive the data, .
Figure 4.8-16 backoff operation

924
925
926

3.6.3.3.4.Transmission time management

927
928
929

(1) Pause duration management
Wait for the pause duration, based on [T108].

930
931

(2) Total emission time management

932

Have a function that limit the sum of emission time per arbitrary one hour to be 360 sec
or less, based on [T108].

933
934
935

3.6.3.3.5.MAC Constant and variable936(1) MAC constant

937

Table 4.8-28 shows the MAC Constant of this specification. (Specify the nominal value of
this specification, based on [802.15.4g] Table 51, Table 71)

938
939

Table 4.8-28 MAC constant

940

Constant

Description [unit]

phyCCADuration

The duration for CCA[μsec]

130

aTurnaroundTime

turnaround time
between RX and TX[μsec]

1000

RX to TX
TurnaroundTime(=tack)turnaround time fromRX to TX [μsec]

300 ormore, 1000
or less

Wi-SUN Profile for HAN

NominalValue *1

Remark128 or more

82 of 206

HAN Working GroupTX to RX
TurnaroundTime

turnaround time from
TX to RX [μsec]

less than300

macMinLIFSPeriod

minimum LIFS [μsec]

1000

Refer to 3.6.3.3.1

aUnitBackoffPeriod

unit period of backoff[μsec]

1130

Refer to 3.6.3.3.1

5

See the description of
macEnhAckWaitDurationin [802.15.4e] Table 52.

macAckWaitDuration*2 time to wait for ACK
frame after completionof frame transmission.
[ms]

The EACK is regarded asreceived if the PHY
header is received within
macEnhAckWaitDuration.

941*1: For the error range of each value, refer to [802.15.4], [802.15.4e], [802.15.4g].

942*2: The macAckWaitDuration means macEnhAckWaitDuration in this table.

943
944

(2) MAC variable

945

Table 4.8-29 shows the MAC variable of this specification. (specify the default value of thisspecification, based on [802.15.4] Table 52)

946
947

Table 4.8-29 MAC variable

948

variable
macMaxBE

Description

Rangemaximum value of the backoff 3-15 *1

Default Remark
8exponent
macMinBE

minimum value of the backoff
exponent

macMaxCSMABackoffs The maximum number of08
macMaxBE
0-5

4

0-7

3

backoffs
macMaxFrameRetries

The maximum number of
retries
Wi-SUN Profile for HAN

83 of 206

HAN Working Group

949
950

*1: range is extended to increase the variation (however, default value is within the standard
range)

951

952

3.6.4. Interface part953

3.6.4.1. Overview

954

The interface of a single-hop home network for ECHONET Lite over IPv6 shall be compliant
with Clause 3.5 unless otherwise specified in the following sub clauses.

955
956
957

3.6.4.2. Adaptation layer

958

See 3.5.3 in this document.

959
960

3.6.4.2.1.Fragmentation

961

See 3.5.3.1 in this document.

962
963

3.6.4.2.2.Header compression

964

See 3.5.3.2 in this document

965
966

3.6.4.2.3.Neighbor discovery

967
968

The coordinator and the host described in this clause shall not support 6LoWPAN ND in
Clause 3.5.3.3 due to applying ND based on IPv6 specified in the next clause.

969

3.6.4.3. Network layer

970

See 3.5.4 in this document.

971
972

3.6.4.3.1.IP addressing973

See 3.5.4.1 in this document.

974
Wi-SUN Profile for HAN

84 of 206

HAN Working Group975

3.6.4.3.2.Neighbor discovery

976

See 3.5.4.2 in this document.

977
978

3.6.4.3.3.Multicast

979

See 3.5.4.3 in this document.

980
981

3.6.4.4. Transport layer

982

See 3.5.5 in this document.

983
984

3.6.4.5. Application layer

985

See 3.5.6 in this document.

986

987

3.6.5. Security configuration

988

3.6.5.1. Overview

989

This clause describes a security mechanism for single-hop network.

990

Most of the security configuration is the same in the clause 3.5.7 except special descriptionsin this clause.

991
992
993

3.6.5.2. Authentication

994

The coordinator shall be PANA Authentication Agent (PAA) and the host shall be PANA
Client (PaC).

995
996
997

3.6.5.3. Key generation998

3.6.5.3.1.MAC layer security (link key)

999

The USRK and the LK are generated by following functions.
Wi-SUN Profile for HAN

85 of 206

HAN Working Group1000

USRK = KDF(EMSK, “Wi-SUN JP SH-HAN” | “\0” | optional data | length)•

optional data = NULL(0x00)•

length = 64

LK = KDF(USRK, “Wi-SUN JP SH-HAN” | “\0” | optional data | length)•

optional data = EAP ID_P | EAP ID_S | IEEE802.15.4 Key Index•

length = 16

1001
1002

3.6.6. Recommended network configurations

1003

3.6.6.1. Construction of new network

1004

Once turned on, a coordinator constructs a new network compliant to this profile. The
network construction is conducted by successive steps of (1) data link layer configuration,(2) network layer configuration and (3) security configuration. Overview of the network
construction procedure is shown in Figure 4.8-17.

1005
1006
1007
1008

Wi-SUN Profile for HAN

86 of 206

HAN Working GroupA coordinator turned on(1)Channel selection(2)

PAN ID determination(3)

IPv6 address generation

(4)

DAD

Data link layer
configurations

Network layer
configurations

Security
configurations
1009
1010

Figure 4.8-17

Overview of network construction procedures

1011
1012

3.6.6.1.1.Data link layer configurations

1013

Once turned on, a coordinator constructs an IEEE 802.15.4 PAN. Detailed procedures for
PAN construction is shown as follows.

1014
1015
1016
1017

The coordinator first selects a channel to use. The channel selection is conducted via ED
scanning or active scanning, or both. In the selection, channel with less interference to theother systems are more preferable. (Step 1)

1022

Next, the coordinator selects the PAN ID that is not occupied on the selected channel in
Step 1, and defines it as the PAN ID for the local network. A special control for PAN ID
confliction avoidance is not defined in this profile, since the current specifications can copewith the case by using the existing functions such as discarding by MAC address. Selection
criteria of PAN ID out of candidate IDs is out of scope of this profile. (Step 2)1023

With conducting of the previous steps, PAN construction by the coordinator is completed.

1018
1019
1020
1021

1024

Wi-SUN Profile for HAN

87 of 206

HAN Working Group1025

3.6.6.1.2.Network layer configurations

1026

After data link layer configurations are completed, the coordinator conducts initialconfigurations for network layer (IPv6).

1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037

First, the coordinator generates its own IPv6 address. The prefix is FE80::0/64, andinterface ID is generated based on the coordinator's MAC address (EUI-64) according todefinitions in [6LoWPAN] and [SLAAC]. (Step 3)
The coordinator may provide the global address or an unique local address to IEEE
802.15.4/4e/4g interface that defines IP address generated in Step 3, which is out of scopeof this profile.
In general cases, DAD (Duplicate Address Detection) is conducted in this step in order toavoid IP address confliction to the other nodes in the network. However, nodes compliant tothis profile always generate their own IPv6 addresses from EUI-64 addresses and there isbasically no confliction of IP addresses. Therefore, DAD may be omitted. (Step 4)

1038
1039

3.6.6.1.3.Security configurations

1040

The coordinator conducts security configurations following data link layer and network layer
configurations.

1041
1042
1043

3.6.6.2. Association to the network

1044

Once turned on, a new host tries to association to the existing network compliant to thisprofile. Association procedure by the host includes (1) data link layer configuration, (2)network layer configuration and (3) security configuration just in a same manner as PAN
construction by a coordinator. Overview of association procedures to the existing network
by a host is shown in Figure 4.8-18.

1045
1046
1047
1048
1049

Wi-SUN Profile for HAN

88 of 206

HAN Working GroupA new host turned on(1)

Network detection(2)

Network selection to associate

A coordinator(3)

Association(4)

IP address generation

(5)

DAD

(6)

Device authentication

1050
1051

Figure 4.8-18 Overview of association to the network

1052
1053

3.6.6.2.1.Data link layer configurations

1054

After turned on, a new host uses an enhanced active scan feature and sets MLME IE to its
information Elements (IE) fields. As a response to the enhanced beacon request commandfrom the host, the coordinator should send an enhanced beacon that set the same MLME IE
to its information Elements fields; the host broadcasts an enhanced beacon request withsome IEs command that is defined in [802.15.4e] on all available channels out of radio
channels defined in [802.15.4] and [T108], a coordinator that receives the command returns
an enhanced beacon with some IEs frame as a response, and the new host receives theenhanced beacon. Moreover, the new host recognizes a radio channel and a PAN ID
employed by the coordinator, as results of those procedures. The content of MLME IE is outof scope of this profile. (Step 1)

1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070

In case only one PAN is detected, the host moves to the next step as for the PAN. In caseseveral PANs are detected, the host needs to select one PAN in order to move to the next
step. PAN selection criteria for the latter case is implementation matter and out of scope of
this profile. (Step 2)
In case the host fails to associate to the PAN after those association procedures, the host isrecommended to retry the procedures from Step 1 or Step 2, where the other network
should be tried in Step 2.

Wi-SUN Profile for HAN

89 of 206

HAN Working Group

1071
1072
1073

At this point, the new host may conduct association procedures defined in [802.15.4].
However, such association procedures by data link layer can be omitted since thecoordinator is recognized by upper layer. (Step 3)

1074
1075

3.6.6.2.2.Network layer configurations

1076

After association to IEEE 802.15.4 PAN is completed, the new host generates its own IPv6
address. The prefix is FE80::0/64, and interface ID is generated based on the host’s MAC
address (EUI-64) according to definitions in [6LoWPAN] and [SLAAC]. (Step 4)

1077
1078
1079
1080
1081
1082
1083
1084

In general cases, DAD (Duplicate Address Detection) is conducted in this step in order toavoid IP address confliction to the other nodes in the network. However, nodes compliant tothis profile always generate their own IPv6 addresses from EUI-64 addresses and there isbasically no confliction of IP addresses. Therefore, DAD may be omitted. (Step 5)
At this point, the host initiates the device authentication with the coordinator. Thisauthentication procedure should be a mutual authentication process. (Step 6)

1085
1086

3.6.6.2.3.Security configurations

1087

The new host conducts security configurations after data link layer and network layer
configurations.

1088
1089
1090

Wi-SUN Profile for HAN

90 of 206

HAN Working Group

1091

3.7.

1092

Recommended usage for single-hop smart meter-HEMS
network1093

3.7.1. Overview

1094This clause clarifies the recommended usage in constructing single-hop smart meter-Home
Energy Management System (HEMS) which controls home devices for energy efficiency
and has an interface of [802.15.4][802.154g][802.15.4e]. HEMS network for ECHONET Liteover IPv6. Note that this profile does not exclude other usages.

1095
1096
1097
1098
1099

Compliant nodes to this clause constructs single hop network with only a smart meter as acoordinator and a HEMS as a host without the other nodes on the same link.

1100

1101

3.7.2. PHY part

1102

Required specifications in terms of IEEE 802.15.4/4e/4g standards in order to realize thisusage is shown in Table 4.8-30.

1103
1104

Table 4.8-30 Device/PHY layer specifications in order to realize this usage

1105

SupportItem(Y:Yes,number N:No,*1
O:Option)

SupportItem(Y:Yes,number
N:No,*2
O:Option)

Itemnumber*3

SupportItem(Y:Yes,number
N:No,*3
O:Option)

Recommend(Y:Yes,
N:No,
O:Option)

FD1

PLF1

RF12

―

100 kbps

O.1

Y

RF13.4

*4
FD2

O.1

PLF2

Y

RF12.1

Y

RF13.5

N

FD3

Y

PLF3

Y

RF12.2

N

RF14

―

FD4

N

PLF4

Y

RF12.3N

RF14.1N

FD5

N

PLF4.1 Y

RF12.4N

RF14.2N

FD8

Y

PLF4.2 N

RF12.5

N

RF14.3Y*5

Wi-SUN Profile for HAN

91 of 206

HAN Working GroupPLF4.3 N
PLP1

RF12.6PSDU size RF13
is up to 255
octetsY

RF14.4

N

―

1106
1107

*1: Corresponding to the item number in Table 4.8-7 Functional device types

1108*2: Corresponding to the item number in Table 4.8-2 PLF and PLP capabilities1109*3: Corresponding to the item number in Table 4.8-3 RF capabilities

1110
1111
1112

*4: Only 100kbps is mandatory for single-hop smart meter-HEMS network. 50kbps is
optional.
*5: CSM is not supported if 50kbps is not supported.

1113
1114
1115
1116
1117
1118
1119

The required specifications for the Additional PHY layer are shown in Table 4.8-31. This
usage assumes compliance with the domestic regulation [T108] and compliant to the PHY
specifications defined in [802.15.4g]. This specification uses GFSK modulation, 100 kbps
data rate, 400 kHz occupied bandwidth (bundling 2 channels), and the 20 mW antenna
power. In order to mitigate the impact of the deployment environment, antenna diversity is
recommended.

1120
1121

Table 4.8-31 Additional PHY layer specifications in order to realize this usage
Parameters

Recommend

Modulation scheme

GFSK

Data rate

100 kbps

Transmission power

20 mW or lessFrequency channel

Channels of No. 33 to 60 definedby
ARIB with bundling of an odd andan even channel.

Occupied bandwidth

400 kHz (with 2 channel bundling),
Wi-SUN Profile for HAN

Remarks

Channels of No. 33 to 38 are
alsoutilized by systems employing
250
mW transmission power.

92 of 206

HAN Working Group

Receiver sensitivity-88 dBm or less
（PSDU length = 250 octets, data rate = 100kbps, PER<10%, Power measured at antenna
terminals, Interference not present ）Transmission
preamblelength1200us - 4000us

Preamble length
assumed at receiver

1200usAntenna gain

3 dBi or less

Antenna diversity

2 antenna selection diversity,
recommended

1122

1123

3.7.3. MAC part1124

3.7.3.1. MAC layer specifications

1125

Required specifications in terms of IEEE 802.15.4/4e/4g standards are shown in Table
4.8-32. Non-beacon enabled configurations are selected by MAC layer when these
specifications are deployed.

1126
1127
1128

Table 4.8-32 MAC layer specifications in order to realize this usage1129

SupportItem
Item(Y:Yes,numbernumber
N:No,*1*1
O:Option)

SupportItem(Y:Yes,number
N:No,*1
O:Option)

SupportSupportItem(Y:Yes,(Y:Yes,number
N:No,
N:No,
*2
O:Option)
O:Option)

MLF1

Y

MLF7

Y

MLF15

N

MF1

Y

MLF1.1 N

MLF8

N

MLF16

N

MF2

Y

MLF2

MLF9

Y

MLF17

N

MF3

Y

MLF9.1Y

MLF18

MLF10.2: MF4
Y *13

Y

Y

MLF2.1 N

Wi-SUN Profile for HAN

93 of 206

HAN Working GroupMLF2.2 N

MLF9.2Y

MLF18.1

MLF18:Y MF4.1

N

MLF2.3 N

MLF9.2.1

Y

MLF18.1.1 MLF18:Y MF4.2

N

MLF3

MLF9.2.2

Y

MLF19

N

MF4.3

N

MLF10.1

Y*5

MLF19.1

N

MF4.4

N

MLF10.2

FD1:O*12

MLF19.2

N

MF4.5

N

Y

MLF3.1 FD1:Y
FD2:N
MLF3.2 Y

FD2:M
*11
MLF4

Y

MLF10.3

N

MLF19.3

N

MF4.6

N

MLF5

N

MLF10.4

N

MLF19.4

N

MF4.7

Y*9

MLF5.1 N

MLF11N

MLF19.5

N

MF4.8

N

MLF5.2 N

MLF12N

MLF19.6

N

MF4.9

N

MLF6

MLF13

N

MLF19.7

N

MF5

Y*10

MLF15(4g) N

MLF19.8

N

MLF20

N

MLF21

N

MLF23

N

MLF23.1

N

Y

1130
1131

*1：Corresponding to item number in Table 4.8-5 MAC sub-layer functions

1132*2：Corresponding to item number in1133*9：May be employed by FD2 (not clarified in references).

1134*10：2 octet FCS is employed when PSDU size is no more than 255octets

Table 4.8-6 MAC frames

Wi-SUN Profile for HAN

94 of 206

HAN Working Group1136*11 Active scanning is employed by FD1 for the channel selection and by FD2 for the
network identification.

1137*12 FD1 must have capability to respond to the Active scanning performed by other devices.

1138*13 FD1 must have capability to respond to the EBR.

1135

1139
1140

3.7.3.2. MAC frame format

1141

See 3.6.3.2 in this document.

1142
1143

3.7.3.3. MAC functional description

1144

See 3.6.3.3 in this document.

1145
1146

3.7.4. Interface part1147

3.7.4.1. Overview

1148

The interface of a single-hop smart meter-HEMS network for ECHONET Lite over IPv6 shallbe compliant with Clause 3.5 unless otherwise specified in the following sub clauses.

1149
1150
1151

3.7.4.2. Adaptation layer

1152

See 3.5.3 in this document.

1153
1154

3.7.4.2.1.Fragmentation

1155

See 3.5.3.1 in this document.

1156
1157

3.7.4.2.2.Header compression1158

See 3.5.3.2 in this document

1159

Wi-SUN Profile for HAN

95 of 206

HAN Working Group

1160

3.7.4.2.3.Neighbor discovery

1161

The smart meter and the HEMS described in this clause shall not support 6LoWPAN ND in
Clause 3.5.3.3 due to applying ND based on IPv6 specified in the next clause.

1162
1163
1164

3.7.4.3. Network layer

1165

The single-hop smart meter-HEMS network shall support IPv6 protocol [IPv6] in Table
4.8-33.

1166
1167

Table 4.8-33 Network Layer: IPv6

1168

Item number

Item description

IP1
IP1.1
IP1.2
IP1.3
IP1.4
IP1.5
IP1.6
IP1.7
IP1.8
IP1.9
IP1.10IP2Header Format
Extension Headers
Extension Header Order
Options
Hop-by-Hop Options Header
Routing Header
Fragment Header
Destination Options Header
No Next Header
AH Header
ESP Header
Deprecation of Type 0 Routing
Headers
Path MTU Discovery
Flow Labels
Traffic Classes

IP3
IP4
IP5

[IPv6] 3[IPv6]4.1[IPv6] 4.2[IPv6] 4.3[IPv6]4.4[IPv6] 4.5[IPv6] 4.6[IPv6]4.7
[AH]
[ESP]
[IPv6-RH]

Support(Y:Yes, N:No,
O:Option,
I:Irrelevant)
Y
I
I
I
I
I
I
I
I
I
I
I

[IPv6] 5[IPv6] 6[IPv6] 7

I
NN

Reference
section instandard

1169
1170
1171
1172

The single-hop smart meter-HEMS network also shall support ICMPv6 protocol [ICMPv6] inTable 4.8-34.

Wi-SUN Profile for HAN

96 of 206

HAN Working Group

1173

Table 4.8-34 Network Layer: ICMPv6

1174

Item number

Item description

ICMP1
ICMP2

1175

Message Format
Message Source Address
Determination
ICMP3
Message Checksum Calculation
ICMP4
Message Processing Rules
ICMP5
Destination Unreachable
Message
ICMP6
Packet Too Big Message
ICMP7
Time Exceeded Message
ICMP8
Parameter Problem Message
ICMP9
Echo Request Message
ICMP10
Echo Reply Message*1: The port unreachable (code=4) is only applicable.

[ICMP6] 2.1[ICMP6] 2.2

Support(Y:Yes, N:No,
O:Option,
I:Irrelevant)Y
Y[ICMP6] 2.3[ICMP6] 2.4[ICMP6] 3.1

Y
Y
Y*1

[ICMP6] 3.2[ICMP6] 3.3[ICMP6] 3.4[ICMP6] 4.1[ICMP6] 4.2

I
I
Y
Y
Y

Reference
section instandard

1176
1177

3.7.4.3.1.IP addressing

1178

See 3.5.4.1 in this document.

1179
1180

3.7.4.3.2.Neighbor discovery

1181

See 3.5.4.2 in this document except for the parts of Neighbor Solicitation Message and
Neighbor Advertisement Message. In the single-hop smart meter-HEMS network, thetransmission of Neighbor Solicitation Message is optional but the node shall respond bysending a Neighbor Advertisement Message to the received Neighbor Solicitation Message(see Table 4.8-35).

1182
1183
1184
1185
1186
1187

Wi-SUN Profile for HAN

97 of 206

HAN Working Group

1188
1189

Table 4.8-35 Neighbor Solicitation and Neighbor Advertisement Messages
Item number

ND4
ND8

Item description

Support(Y:Yes, N:No,
O:Option,
I:Irrelevant)Duplicate Address
Detection
Neighbor Solicitation (NS)Message

I
-

ND8.1

NS Transmission

O

ND8.2

No NS Transmission

O

ND8.3

Y

ND9.1

NS Reception
Neighbor Advertisement(NA) Message
Solicited NA Transmission

ND9.2

Solicited NA Reception

ND9

ND9.3
ND9.4

Notes

-

See ND8.1, ND8.2 and ND8.3

Optional but at least one of
the specifications described in
ND8.1 and ND8.2 is required
to be supported.

See ND9.1, ND9.2, ND9.3
and ND9.4

Y
ND8.1:Y
ND8.2:N

Unsolicited NA
Transmission
Unsolicited NA Reception

N
N

1190
1191
1192

3.7.4.3.3.Multicast

1193

See 3.5.4.3 in this document.

1194
1195

3.7.4.4. Transport layer

1196

See 3.5.5 in this document.

1197

Wi-SUN Profile for HAN

98 of 206

HAN Working Group

1198

3.7.4.5. Application layer

1199

See 3.5.6 in this document.

1200

Application should not send packets larger than 1280 octets as a link MTU.

1201

This means application maximum PDU size is below:

1202
1203
1204
1205

1280 - 'size of IPv6 header (incl. extension header)' - 'size of Transport layer header’For example: In the case that an application uses UDP and does not use IPv6 extension
headers, the application maximum PDU size is below:
1280 - 40(IPv6 header size) - 8(UDP header size) = 1232 octets.

1206

1207

3.7.5. Security configuration

1208

3.7.5.1. Overview

1209

This clause describes a security mechanism for single-hop smart meter-HEMS network.

1210

Most of the security configuration is the same in the clause 3.5.7 except special descriptionsin this clause.

1211
1212
1213

3.7.5.2. Authentication

1214

The smart meter shall be PAA and the HEMS shall be PaC.

1215
1216

3.7.5.3. Key generation

1217

3.7.5.3.1.MAC layer security (link key)

1218

The USRK and the LK are generated by following functions.

Wi-SUN Profile for HAN

99 of 206

HAN Working GroupUSRK = KDF(EMSK, “Wi-SUN JP Route B” | “\0” | optional data | length)•

optional data = NULL(0x00)•

length = 64

LK = KDF(USRK, “Wi-SUN JP Route B” | “\0” | optional data | length)•

optional data = EAP ID_P | EAP ID_S | IEEE802.15.4 Key Index•

length = 16

1219
1220
1221

The smart meter and the HEMS shall have two or more KeyDescriptors to hold at least two
keys at the same time. Both nodes shall use the latest key at the time of transmission.

1222

1223
1224
1225
1226
1227

3.7.6. Recommended network configurations
Both a smart meter and HEMS have “Pairing ID”, which length is 8 octets, and the ID isused to associate the smart meter with the HEMS. In this specification, suppose the ID is
set to a smart meter and HEMS in advance. In addition, NAI and authentication key for
PANA/EAP are also set to a smart meter and HEMS in advance.

1229

A smart meter determines the radio channel and PAN ID that is used to construct the
network, by following procedure.

1230

1-1: Data link (MAC) layer configuration,

1231
1233

Radio channel selection and PAN ID detection are conducted via ED scanning or Enhanced
Active scanning, or both. Selection criteria of radio channel and PAN ID is out of scope of
this profile.

1234

1-2: Network layer configuration,

1235

A smart meter generates its own IPv6 link local address compliant to [SLAAC].

1236
1237

After the smart meter that is coordinator completes the network construction, HEMS attempt
to connect to the smart meter, as the following configurations.

1238

2-1: Data link (MAC) layer configuration,

1239

HEMS identifies the smart meter network by using Enhanced Active scanning.

1228

1232

Wi-SUN Profile for HAN

100 of 206

HAN Working Group

1240

2-2: Network layer procedure,

1241

HEMS generates its own IPv6 link local address compliant to [SLAAC].

1242

HEMS should calculate the IPv6 link local address of the smart meter from the source
address of Enhanced Beacon message. And HEMS requests a smart meter to authenticate
by [PANA] using NAI and authentication key, which are pre-shared. The smart meterestablishes PANA session with the HEMS, and the smart meter authenticates HEMS basedon NAI and authentication key. When authentication succeeds, the smart meter and theHEMS share the MAC layer encryption key.

1243
1244
1245
1246
1247
1248
1249
1250
1251

After sharing the MAC layer encryption key, the smart meter can communicate with the
HEMS, by using encrypted messages. HEMS conducts service discovery procedure using
ECHONET Lite protocol, and the smart meter can notify the HEMS of meter readings every
30 minutes.

1252
1253
1254
1255
1256
1257
1258

3.7.6.1. Bootstrapping
Once a smart meter is turned on, it constructs a new network compliant to this profile. This
procedure is same as sub clause 3.6.6.1. And, once HEMS is turned on, it attempts toconnect to the network that is constructed by the smart meter. This procedure is same as
sub-clause 3.6.6.2. Overview of network configuration and association procedure to the
network is shown in Figure 4.8-19.

Wi-SUN Profile for HAN

101 of 206

HAN Working Group1259

AAcoordinator
coordinatorturned
turnedonon(1)ChannelChannel selection
selection(2)

PAN
PAN IDID determination
determination

(3)

IPv6
IPv6 address
address generation
generation

(4)

DAD
DAD

AAnew
newHostHostturned
turnedonon
Data link layer
configurations

Network layer
configurations(1’)

Network
Network detection
detection(2’)

Network
Network selection
selection toto associateassociate

(3’)

IPv6
IPv6 address
address generation
generation

(4’)

DAD
DAD

Data link layer
configurations

Network layer
configurations

1260
1261

Figure 4.8-19：Overview of network construction procedure

1262
1263

3.7.6.1.1. Data link layer configuration

1264

Data link layer configuration of a coordinator is same as sub clause 3.6.6.1.1, but smart
meter must set no information to its Information Elements fields in Enhanced Beacon
Request if Active scan is employed.

1265
1266
1267
1268
1269
1270
1271
1272
1273
1274

To detect the smart meter network, HEMS uses an Enhanced Active scan feature and set
MLME IE to its Information Elements field which is terminated with a list termination IE(ID=0xf). As a response to the Enhanced Beacon Request command from the HEMS, thesmart meter should send an Enhanced Beacon that set the same MLME IE to its
Information Elements field which is terminated with a list termination IE (ID=0xf).
Association procedure should be omitted. Other data link layer configuration of HEMS issame as sub-clause 3.6.6.2.1.
Configuration information is shown in Table 4.8-36.
Table 4.8-36 Sub-ID (MLME IE)

1275

Sub-ID value

Content length

Name

Wi-SUN Profile for HAN

Description
102 of 206

HAN Working Group

0x68

Variable

Unmanaged(Pairing ID)

This Sub-ID is used as theinformation to help HEMS
detect the corresponding
smart meter network. This
Sub-ID is defined by thisprofile.

1276
1277

3.7.6.1.2.Network layer configuration

1278

A smart meter use IPv6 link local address only. Other network layer configuration of a smart
meter is the same as sub-clause 3.6.6.1.2.

1279

1281

HEMS use IPv6 link local address only, too. Other network layer configuration of HEMS is
the same as sub-clause 3.6.6.2.2.

1282

Authentication procedure refers to sub clause 3.7.6.3.

1280

1283
1284

3.7.6.2. IP Address Detection

1285

1288

Before the authentication procedure by PANA, HEMS should calculate the IPv6 address ofthe smart meter. As a way to detect IPv6 address of the opposite device, HEMS uses thesource MAC address field of an Enhanced Beacon message from the smart meter, andHEMS estimates IPv6 link local address of the opposite smart meter.

1289

HEMS may be omitted Neighbor Discovery procedure defined in [ND].

1286
1287

1290
1291

3.7.6.3. Authentication and Key Exchange

1292

The HEMS conducts security configurations after data link layer and network layer
configurations. In other words, the HEMS acting as a PaC initiates a PANA session to thesmart meter acting as the PAA.

1293
1294
1295
1296

3.7.6.4. Application

1297

As stated in 3.7.4.5, use ECHONET Lite as an application protocol, and support using
compound data format.

1298
1299

Wi-SUN Profile for HAN

103 of 206

HAN Working Group

1300

3.7.6.4.1.ECHONET Object

1301

Smart meter and HEMS use the ECHONET object (EOJ) as described in Table 4.8-37.

1302

Table 4.8-37 ECHONET Objects (EOJ)

1303

Class group code

Class code

Instance code

Smart meter

0x02

0x88

0x01

HEMS

0x05

0xFF

0x01
Note: An instance code is fixed as 0x01.

1304
1305
1306

3.7.6.4.2.ECHONET Lite Service (ESV)

1307

Smart meter and HEMS use The ECHONET Lite service code as described in Table 4.8-38.

1308

Table 4.8-38 ECHONET Lite Service (ESV) Code1309

Service Code(ESV)ECHONET Lite Service Content

Symbol0x51

Property value write request“response not possible”

SetC_SNA

0x52

Property value read “response notpossible”

Get_SNA

0x61

Property value write request(response required)

SetC

0x62

Property value read request

Get

0x71

Property value Property value write
response

Set_Res

0x72

Property value read response

Get_Res

0x73

Property value notification

INF

0x74

Property value notification(response required)

INFC

Wi-SUN Profile for HAN

104 of 206

HAN Working Group

0x7A

Property value notification
response

INFC_Res

1310
1311

3.7.6.4.3.The ECHONET device object (EPC)1312

The ECHONET device object (EPC) for Smart meter is described in Table 4.8-39 and Table
4.8-40, and is used between the communication of Smart meter and HEMS.

1313
1314
1315

Table 4.8-39 Definition of Device Object Super Class Properties
Property name

EPC

Contents of property

Access rule

Operation status

0x80

This property indicates the
ON/OFF status.

Get

Installation location

0x81

This property indicates theinstallation location.

Set/GetStandard version
information

0x82This property indicates theversion number of thecorresponding standard.

Get

Fault status

0x88

This property indicates
whether a fault (e.g. a
sensor trouble) has
occurred or not.

Get

Manufacturer code

0x8A

Manufacturer code definedby the ECHONET
Consortium.

Get

Production number

0x8D

It’s used for specifying asmart meter.

Get

Current time setting

0x97

Current time (HH:MM
format)Get

Current date setting

0x98

Current date
(YYYY:MM:DD format)

Get

Status changeannouncement property
map

0x9D

Wi-SUN Profile for HAN

Get

105 of 206

HAN Working GroupSet property map

0x9E

Get

Get property map

0x9F

Get

1316
1317
1318

Table 4.8-40 Definition of ECHONET Lite Device Object for Smart electric energy
meter class
Property name

EPC

Contents of property

Access rule

Operation status

0x80

This property indicates the
ON/OFF status.

Get

Compositetransformation ratio

0xD3

This property indicates thecomposite transformation
ratio using a 6-digit
decimal notation number.

Get

Number of effective
digits for cumulative
amounts of electricenergy0xD7This property indicates the Get
number of effective digits
for measured cumulative
amounts of electric energy.

Measured cumulative
amount of electricenergy(normal direction)

0xE0This property indicates themeasured cumulative
amount of electric energy
using an 8-digit decimal
notation number.

Unit for cumulative
amounts of electricenergy(normal and reverse
directions)

0xE1

This property indicates the Get
unit (multiplying factor)
used for the measured
cumulative amount ofelectric energy and thehistorical data of measured
cumulative amounts ofelectric energy)

Historical data ofmeasured cumulative
amounts of electricenergy(normal direction)

0xE2

This property indicates thedate of historical data andmeasured cumulative
amounts of electric energy(maximum 8 digits) for
normal direction, which
consists of 48 data value

Wi-SUN Profile for HAN

Get

Get

106 of 206

HAN Working Group

of half-hourly data for thepreceding 24 hours.
Measured cumulative
amount of electricenergy(reverse direction)

0xE3

This property indicates themeasured cumulative
amount of electric energy
using an 8-digit decimal
notation number.

Get

Historical data ofmeasured cumulative
amounts of electricenergy(reverse direction)

0xE4

This property indicates thedate of the historical data
and measured cumulative
amounts of electric energy(maximum 8 digits) for
reverse direction, which
consists of 48 data valueof half-hourly data for thepreceding 24 hours.

Get

Day for which the
0xE5
historical data ofmeasured cumulative
amounts of electricenergy is to be retrieved

This property indicates theday for which the historical
data of measured
cumulative amounts ofelectric energy (which
consists of 48 pieces ofhalf-hourly data for thepreceding 24 hours) is tobe retrieved.

Set/GetMeasured
instantaneous electricenergy0xE7This property indicates themeasured effective
instantaneous measured
effective instantaneouselectric energy in watts.

Get

Measured
instantaneous currents

0xE8This property indicates themeasured effective
instantaneous R and T
phase currents inamperes.

Get

Cumulative amounts ofelectric energy
measured at fix time(normal direction)

0xEA

This property indicates themost recent cumulative
amount of electric energy(normal direction)

Get/INF/INFC

Wi-SUN Profile for HAN

107 of 206

HAN Working Groupmeasured at 30-minuteintervals, and measured
date of measurement, timeof measurement, andcumulative electric energy(normal direction).
Cumulative amount ofelectric energy
measured at fix time
(reverse direction)

0xEB

This property indicates themost recent cumulative
amount of electric energy(reverse direction)measured at 30-minuteintervals, and measured
date of measurement, timeof measurement, andcumulative electric energy(reverse direction).

Get/INF/INFC

1319
1320
1321

3.7.6.4.4.The response for consecutive request

1322

Smart meter and HEMS make both request and a response as a set of communication, andperform one response to one request. In case sending the request of Get commandconsecutively, you need to receive the Get response before requesting another Get request
command.

1323
1324
1325
1326
1327

In addition, these specifications are the regulations to one-to-one communications, so a
consecutive demand means that the demand from the same equipment continues.

1328
1329

3.7.6.4.5.Handling multiple data

1330

Such as in a case that there is no change of the serial number accompanying exchange ofa smart meter, etc., and when HEMS receives multiple time of the integral-powerconsumption value (30-minute value) of the same measurement time, etc. from the same
smart meter, the latter data shall be handled as correct data.

1331
1332
1333
1334

Wi-SUN Profile for HAN

108 of 206

HAN Working Group

1335

3.7.7. Usage of credential in Japanese market Route-B (supplemental)

1336

In Japanese Route-B (smart meter-HEMS) network, a Route-B specific credential (Table
4.8-41) is defined and required to use it. For this purpose, this subsection defines how to
use the credential in the communication protocols.

1337
1338
1339

Table 4.8-41 Route-B credential

1340

Name

Description

Route-Bauthentication
ID

Unique ID used to pair up a specific smart meter and HEMS.
Character string of 32 comprised of 0~9 and A~F ASCII
characters (32 octets). In this profile, this is converted to the ID([NAI] format) used by PANA (EAP-PSK) and the “Pairing ID”
by the rule described later.

(Route B
Password linked to Route B authentication ID (character string
authentication) of 12 comprised of 0~9, a~z, and A~Z ASCII characters). In
Password
this profile, this is used in generating PSK, which is utilized in[EAP-PSK], by the rule described later.
1341
1342

3.7.7.1. Conversion of Route-B authentication ID to EAP Identifiers

1343

Based on the 32 digit, Route-B authentication ID, the following rules are used to generate EAP
Identifiers (ID_S, ID_P) ([NAI]).

1344
1345

Wi-SUN Profile for HAN

109 of 206

HAN Working Group[NAI generation rules]
Smart meter side NAI (EAP ID_S): "SM" +"Route-B authentication ID" (34 octets)
HEMS meter side NAI (EAP ID_P): "HEMS" +"Route-B authentication ID" (36 octets)

Example:When Route-B authentication ID is "0023456789ABCEDF0011223344556677",
Smart meter side NAI (EAP ID_S): "SM0023456789ABCEDF0011223344556677"
HEMS side NAI (EAP ID_P): "HEMS0023456789ABCEDF0011223344556677"

1346
1347

3.7.7.2. Conversion of Password to PSK

1348

PSK used in EAP-PSK is generated using the following rules.

1349

Wi-SUN Profile for HAN

110 of 206

HAN Working Group[PSK generation rules]
Based on the Password linked to Route-B authentication ID, the following PSK generation
function (PSK_KDF) is used to generate the 16 octet PSK.

PSK = PSK_KDF (Password)= LSBytes16 (SHA-256 (Capitalize (Password))(lower order 16 octets of the output created by using SHA-256 in the hash function on thecapitalized Password character string)

Example:When the Password is "0123456789ab"
PSK = LSBytes16(SHA-256(“0123456789AB”))= 0xf58d060cc71e7667b5b2a09e37f602a2

1350
1351

3.7.7.3. Conversion of Route-B authentication ID to Pairing ID

1352

HEMS performs Enhanced Active Scan using IEs field to detect the home smart meter.
MLME IE (Group ID=0x1) will be used for the Payload IEs field of the Enhanced Beacon
Request sent by HEMS, and the lower order 8 octets (Pairing ID) of the Route-B
authentication ID will be included in the IE Contents of Sub-ID=0x68(Unmanaged).When the
Pairing ID stored in MLME IE of the Payload IEs matches the Pairing ID stored in the smart
meter, the smart meter responds by returning the Enhanced Beacon. This Enhanced
Beacon is unicast and also includes the same Pairing ID in the Payload IEs field. Afterconfirmation that the smart meter has the same Pairing ID, HEMS will start PANA
negotiation with this smart meter. (Figure 4.8-20)

1353
1354
1355
1356
1357
1358
1359
1360
1361

Wi-SUN Profile for HAN

111 of 206

HAN Working Group

Route-B ID : “00112233445566778899AABBCCDDEEFF”
Pairing ID : “CCDDEEFF”
ID_S : “SM00112233445566778899AABBCCDDEEFF”
ID_P : “HEMS00112233445566778899AABBCCDDEEFF”
Smart
Meter

HEMS

Enhanced Beacon Request with IE(Paring ID)

Enhanced Beacon with IE(Paring ID)

Start PANA authentication process

1362
1363

Figure 4.8-20 Smart meter discovery process

1364

.

1365
1366

Wi-SUN Profile for HAN

112 of 206

HAN Working Group

1367
1368

3.8.

Recommended usage for single-hop home area network(HAN) among devices1369

3.8.1. Overview

1370

This clause clarifies the recommended usage in constructing network for ECHONET Liteover IPv6 communication between a HEMS and multiple devices. Compliant nodes to thisclause constructs a network with the HEMS as a central coordinator as shown in Figure
4.8-21.

1371
1372
1373

DeviceHEMS(PAN
Coordinator)

Device1374
1375

Figure 4.8-21 Home area network for multiple devices

1376
1377

3.8.2. PHY part1378

See 3.7.2 in this document.

1379
1380

3.8.3. MAC part1381

See 3.7.3 in this document if there is no additional description in this clause. An upper layerof the relay-unaware device defined in 3.8 should ignore a MAC frame which is security
enabled and contains the IE List present field at the same time. Also it should ignore a MAC
frame (MSDU) which hasSRA IE or SLR IE defiend in 3.9.3.2.4.

1382
1383
1384
1385

Wi-SUN Profile for HAN

113 of 206

HAN Working Group1386

3.8.3.1. Capability Notification IE

1387

Figure 4.8-22 shows the structure of Capability Notification IE. The Sub-ID of this IE is 0x67
(Unmanaged).

1388
1389
1390
1391
1392

Capability Notification IE is a payload IE that is attached to Enhanced Beacon Request
command frame or Enhanced Beacon frame to inform to corresponding node regarding
what capabilities the sender has. Two flags below are defined to be used to inform what
capabilities on HAN relay function the sender has.

1393
1394

・ Sleeping-support (bit 5) – see 3.10.3.2.1

1395
1396
1397

・ Relay-endpoint (bit 6) – if this flag is set, it indicates that the sender can be a relay endpoint and thatmeans that the sender is either a HEMS or HAN-end-device (defined in 3.9) within the HAN network
which relaying function is supported. The detail is specified in 3.9.3.2.1.

1398
1399

・ Relay-intermediate (bit 7) – if this flag is set, it indicates that the sender can be a relay device within
the HAN network which relaying function is supported. The detail is specified in 3.9.3.2.1.

1400
1401
1402
1403
1404
1405

If the sender of this IE does not support any capabilities regarding HAN relay network, bothof these flags must not be set. Also, if the sender needs to inform nothing, it can omit toattach this IE to the EBR or to the EB, disregarding of the presence of this IE in thecorresponding EBR. PAN coordinator is also allowed to attach this IE to the EB even if thisIE was not attached to the corresponding EBR.

1406

Bits: 0-7

8-14

15

Octets: Variable

LengthSub-ID(0x67)

Type(Short format)

IE content

Bits: 0-4

5

6

7

Reserved(0)

Sleeping-support

Relay-endpoint

Relay-intermediate

HAN relay function

1407
1408

Figure 4.8-22 Capability Notification IE

1409
Wi-SUN Profile for HAN

114 of 206

HAN Working Group

1410
1411
1412
1413
1414
1415
1416
1417

At the sending of this IE, the sender of Enhanced Beacon Request command must set all
the possible functions to this IE. On the other hand, the sender of Enhanced Beacon mustset proper and minimum set of necessary functions to this IE according to decision to bemade by its self. More detailed procedure for this IE shall be presented in relevant part foreach recommended usage in this document respectively.
At the reception of EB or EBR with the Capability Notification IE attached, the device must
not discard the frame regardless of its capabilities of sending this IE and support of relay orsleeping functions.

1418

1419

3.8.4. Interface part1420

3.8.4.1. Overview

1421

The interface of a single-hop home network among devices for ECHONET Lite over IPv6
shall be compliant with clause 3.7.4 unless otherwise specified in the following sub clauses.

1422
1423
1424

3.8.4.2. Adaptation layer

1425

See 3.5.3 in this document.

1426
1427

3.8.4.2.1.Fragmentation1428

See 3.5.3.1 in this document.

1429
1430

3.8.4.2.2.Header compression

1431

See 3.5.3.2 in this document.

1432
1433

3.8.4.2.3.Neighbor discovery

1434

HEMS and devices described in this clause shall not support 6LoWPAN ND in clause
3.5.3.3 due to applying ND based on IPv6 specified in the next clause.

1435
1436

Wi-SUN Profile for HAN

115 of 206

HAN Working Group

1437

3.8.4.3. Network layer

1438

See 3.5.4 in this document.

1439
1440

3.8.4.3.1.IP addressing

1441

See 3.5.4.1 in this document.

1442
1443

3.8.4.3.2.Neighbor discovery

1444

See 3.5.4.2 in this document.

1445
1446

3.8.4.3.3.Multicast

1447

See 3.5.4.3 in this document.

1448
1449

3.8.4.4. Transport layer

1450

See 3.5.5 in this document.

1451
1452

3.8.4.5. Application layer

1453

See 3.5.6 in this document.

1454
1455

3.8.5. Security configuration

1456

3.8.5.1. Overview

1457

This clause describes a security mechanism for single-hop home network among devices.
Most of the security configuration is the same in the clause 3.5.7 except special descriptionsin this clause.

1458
1459
1460

Wi-SUN Profile for HAN

116 of 206

HAN Working Group

1461

3.8.5.2. Authentication

1462

The HEMS shall be PAA and the devices shall be PaC.

1463
1464

3.8.5.2.1.PANA

1465
1466

PAA and PaC shall conform to 3.5.7.2.1 in this document except two modification described
below:

1467⚫

In addition to PaC-initiated session, PANA session can be initiated by PAA (PAAinitiated).

⚫

PANA session lifetime shall be set to 0xFFFFFFFF (136 years: practically permanent).

1468
1469
1470
1471

In addition, PAA and PaC shall support following items:

1472

⚫

Unicast and multicast messages shall be protected by ciphered MAC frames with “HAN
group key” shared by all the nodes authenticated in the network.

1474

⚫

PAA shall distribute HAN group key to PAC in the final phase of PANA authentication.

1475

⚫

HAN group key shall be distributed in a vendor-specific AVP which is newly defined inthis document. The Vendor-ID in the vendor-specific AVP shall be 45605 (Wi-SUN
Alliance).

⚫

The vendor-specific AVP defined for HAN group key distribution shall be encrypted in
Encryption-Encap AVP [PANA-ENC]⚫

The vendor-specific AVP used for HAN group key distribution shall contain HAN groupkey, MLE key, Key-ID, authentication counter, and outgoing frame counter of PAA.

⚫

PANA session lifetime shall be set to 0xFFFFFFFF and it has no relation to HAN group
key expiration.

⚫

Therefore PANA session lifetime and HAN group key’s lifetime are not necessarilyequal.

⚫

PAA shall increment an authentication counter for a PaC each time PAA authenticates
the PaC.

⚫

PAA shall maintain an authentication counter for each PaC, and shall keep its valueeven if the PANA session with the PaC is terminated.

1490

⚫

HAN group key’s lifetime shall be maintained by PAA inside, and is not notified to PaC.

1491

⚫

When PAA updates a HAN group key, PAA shall distribute the new key to PaCs.

1473

1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489

Wi-SUN Profile for HAN

117 of 206

HAN Working Group

1492

⚫

PAA shall update the current HAN group key before the MAC frame counter overflow.

1493

⚫

Updated HAN group key is distributed to PaC with PANA protocol in a unicast manner.

1494

⚫

PaC can request PAA for the current HAN group key.

1495

⚫

MAC key generation function and MAC key defined in 3.7.5.3 are not used.

1496

⚫

It is recommended PAA supports at least 16 PaCs in the network. PAA shall maintaindifferent ID and password for each PaC.

1497
1498

3.8.5.2.2.EAP

1499

See 3.5.7.2.2 in this document.

1500
1501

3.8.5.3. Authentication and key distribution

1502

Figure 4.8-23 shows PANA authentication and HAN group key distribution sequence.
PAA

PaC

1: PANA-Client-Initiation()
2: PANA-Auth-Request(PRF-ALGO, INT-ALGO, ENC-ALGO, S-bit)(Encryption-Algorithm AVP = AES128_CTR)
3: PANA-Auth-Answer(PRF-ALGO, INT-ALGO, ENC-ALGO, S-bit)(Encryption-Algorithm AVP = AES128_CTR)
4: PANA-Auth-Request(NONCE, EAP-PAYLOAD)
5: PANA-Auth-Answer(NONCE, EAP-PAYLOAD)
6: PANA-Auth-Request(EAP-PAYLOAD)
7: PANA-Auth-Answer(EAP-PAYLOAD)
Derive the value of authentication counterand PAA's outgoing frame counter
8: PANA-Auth-Request(RESULT-CODE,EAP-PAYLOAD,KEY-ID, SESSION-LIFETIME,ENC-ENCAP, AUTH, C-bit)

9: PANA-Auth-Answer(KEY-ID, AUTH, C-bit)
MAC key configuration

Incoming frame counter
configuration

Authentication(Outgoing)
counter configuration

Incoming frame counter
configuration

1503
1504

Figure 4.8-23 PANA authentication and HAN group key distribution
Wi-SUN Profile for HAN

118 of 206

HAN Working Group

1505

1509

The default value for initial timeout of PCI (PCI_IRT) is 3 seconds in the single-hop home
network among devices unlike original default value (1 second) defined in [PANA]. The
default value of the initial retransmission interval for other messages (REQ_IRT) is 3
seconds as well.

1510

3.8.5.3.1.Authentication request by PAA

1511

PAA shall add Encryption-Algorithm AVP to Step2 PAR message in order to convey an
encryption algorithm to be used to encrypt vendor-specific AVP contained in Step 8 PAR
and subsequent messages. Table 4.8-42 shows Step2 PAR message including an
Encryption-Algorithm AVP.

1506
1507
1508

1512
1513
1514
1515
1516
1517

Table 4.8-42 Authentication and key distribution Step2：Message of PAR(PRFALGO,INT-ALGO,ENC-ALGO,S=bit)
Field

Subfield

PANA

Reserved

Size(octet) Description (value etc.)
2

Message Message Length252

HeaderFlags

2‘R’bit=1、’S’bit=1

Message Type

2

2=PANA-Auth-Request

Session Identifier

4

Sequence Number

4

PRF-Algorithm
AVP

12Contains PRF-Algorithm=5Integrity-Algorithm
AVP

12Contains Integrity-Algorithm=12

EncryptionAlgorithm AVP

12

Contains EncryptionAlgorithm=1(AES128_CTR)

PANA
Payload1518

Wi-SUN Profile for HAN

119 of 206

HAN Working Group

1519

3.8.5.3.2.Authentication response by PaC

1520

PaC shall add an Encryption-Algorithm AVP to Step3 PAN in order to convey an encryption
algorithm to be used to encrypt vendor-specific AVP. Table 4.8-43 shows Step2 PAN
including an Encryption-Algorithm AVP.

1521
1522
1523
1524
1525

Table 4.8-43 Authentication and key distribution Step3：Message of PAN(PRFALGO,INT-ALGO,ENC-ALGO,S-bit)
Field

Subfield

Size(octet) Description

PANA

Reserved

2

Message Message Length252

HeaderFlags

2’S’bit=1

Message Type

2

2=PANA-Auth-Answer

Session Identifier

4

Sequence Number

4

PRF-Algorithm AVP

12

Contains PRF-Algorithm=5Integrity-Algorithm
AVP

12Contains Integrity-Algorithm=12

PANA
PayloadEncryption-Algorithm 12
AVP

Contains EncryptionAlgorithm=1(AES128_CTR)

1526
1527

3.8.5.3.3.Distribution of HAN group key by PAA

1533

When PAR with ‘C’ bit set is transmitted to PaC after successful authentication, HANGroup-Key AVP (vendor-specific AVP) described below shall be added (Authentication /Key distribution: Step 8). HAN group key, MLE Key, Key-ID, authentication counter value(AuthCounter), and outgoing frame counter of PAA are included in HAN-Group-Key AVP.
PAA increments an AuthCounter value by one with each authentication (See 3.8.5.4.5 fordetails). HAN-Group-Key AVP shall be encrypted using Encryption-Encap AVP.

1534

See 3.8.5.4.6 for more information about HAN group key generation.

1535

See 3.8.5.4.7 for more information about HAN-Group-Key AVP encryption.

1528
1529
1530
1531
1532

Wi-SUN Profile for HAN

120 of 206

HAN Working Group

1536

See 3.8.5.4.3 for more information about HAN-Group-Key AVP.

1537
1538

After distribution of HAN group key, PAA sets the following information on its MAC layer:

1539

Incoming frame counter of the PaC to which PAA sent the HAN group key

1540= AuthCounter || 00 00 00(Note: ‘||’ indicates concatenation.)

1541
1542

Wi-SUN Profile for HAN

121 of 206

HAN Working Group

1543

Table 4.8-44 shows the detail of the PAR message with HAN-Group-Key AVP.

1544
1545

Wi-SUN Profile for HAN

122 of 206

HAN Working Group

1546
1547
1548

Table 4.8-44 Authentication / Key distribution (Step 8): Message of PAR (Result-Code,
EAP-Payload, Key-ID, SESSION_LIFETIME, ENC-ENCAP [HAN-Group-Key AVP],
AUTH and ’C’ bit)Field

Sub field

Size(octet)

Description

PANA

Reserved

2

Messa
ge

Message Length

2

132

Flags

2

‘R’bit=1、’C’bit=1

Message Type

2

2=PANA-Auth-Request

Session Identifier

4

Sequence
Number4

PANA

Result-Code AVP

12contains Result-Code

Payload

EAP-Payload AVP 12

contains EAP-Payload

Key-Id AVP

12contains EAP MSK Identifier

Session-Lifetime
AVP

12contains PANA session lifetime

Encryption-Encap
AVP

60

HAN-Group-Key AVP is a vendor specific AVP
which contains a HAN group key. This AVP isdefined in this document. It is encrypted andencapsulated in Encryption-Encap AVP.

Header

HAN–Group-Key AVP
AUTH AVP

52
24

contains Message Authentication Code

1549
1550

3.8.5.3.4.Response to HAN group key reception by PaC

1551

1555

If a PaC receives a PAR message with HAN-Group-Key AVP (vendor-specific AVP) from
PAA (Authentication / Key distribution: Step 8), the PaC replies a PAN (Key-ID, AUTH and‘C’bit) message (Authentication / Key distribution: Step 9). The PaC acquires HAN groupkey, Key-ID, AuthCounter and PAA’s outgoing frame counter value and sets them on its
MAC layer.

1556

See 3.8.5.4.7 for more information about HAN-Group-Key AVP decryption.

1557

Security information set in MAC layer is shown below.

1552
1553
1554

Wi-SUN Profile for HAN

123 of 206

HAN Working Group1558

MAC layer key (LK) = HAN group key

1559

Key Index = Key-ID in HAN-Group-Key AVP

1560

Outgoing frame counter = AuthCounter || 00 00 00

1561

Incoming frame counter for PAA = PAA’s outgoing frame counter (Frame Counter Out)

(Note: ‘||’ indicates concatenation.)

1562
1563
1564
1565

If the PAA rejects the entry of a new device due to the restriction of its resources (e.g. upper
limit number of macDeviceTable), the PAA returns PANA_AUTHORIZATION_REJECTED(2) to the device (PaC) in PANA authentication procedure.

1566
1567

3.8.5.4. Key update

1568

There are two types of key update method: Push and Pull. Push type is PAA distributes the
updated key to PaC and Pull type is PaC acquires the updated key from PAA. Push type ismandatory for both PAA and PaC. Pull type is mandatory for PAA and optional for PaC.

1569
1570
1571
1572

3.8.5.4.1.Distribution of updated HAN group key by PAA (Push)

1573

The sequence of key update for Push type is shown below.

Wi-SUN Profile for HAN

124 of 206

HAN Working Group

PAA

PaC

Generate updated key

1: PANA-Notification-Request(ENC-ENCAP[HAN-Group-Key AVP], AUTH, P-bit)

Receive updated key

2: PANA-Notification-Answer(AUTH, P-bit)

Set updated key

3: MLE Update (Multicast)

Set updated key

1574
1575

Figure 4.8-24 Key update sequence for Push type

1576
1577
1578
1579
1580
1581

If PAA updates a HAN group key, it adds HAN-Group-Key AVP (vendor-specific AVP) to
PNR message and transmits it to each PaC by unicast manner (Push type key update: Step
1). HAN-Group-Key AVP contains HAN group key, MLE Key, Key-ID, AuthCounter, andoutgoing frame counter value of PAA. HAN-Group-Key AVP shall be encrypted using
Encryption-Encap AVP.

1585

PAA shall reset the AuthCounter value to 0 in HAN-Group-Key AVP and reset Each PaC ‘s
incoming frame counter to 0 as is the case in the HAN group key distribution. The
AuthCounter will thus become 0 and the outgoing frame counter of PAA itself and theincoming frame counter of each PaC will become 0x00000000.

1586

See 3.8.5.4.6 for more information about HAN group key generation.

1587

See 3.8.5.4.7 for more information about HAN-Group-Key AVP encryption.

1588

See 3.8.5.4.3 for more information about HAN-Group-Key AVP.

1589

The detail of PNR message with vendor specific AVP is shown below.

1582
1583
1584

1590
Wi-SUN Profile for HAN

125 of 206

HAN Working Group

1591
1592

Table 4.8-45 Key update Push (Step 1): Message of PNR (ENC-ENCAP [HAN-GroupKey] and AUTH) and P-bit
Field

Sub field

PANA

Reserved

2

Message Message
LengthHeader
Flags

2

84

2

‘R’bit=1、’P’bit=1

Message Type

2

4=PANA-Notification-Request

Session
Identifier

4

Sequence
Number4

EncryptionEncap AVP

60

PANA
PayloadSize(octet) Description

HANGroup-Key
AVP
AUTH AVP

HAN-Group-Key AVP is a vendor specific AVP
containing HAN group key, which is defined inthis document. It is encrypted and encapsulated
in Encryption-Encap AVP.
52

24

contains Message Authentication Code

1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604

PAA initiates a new HAN group key distribution for each PaC with valid session. If PaC
receives this PNR message from PAA, it activates the new MLE key and responses PNA
message (Key update Push: Step 2).
When PAA finishes distribution of the new HAN group key to all PaCs with valid session, it
transmits a multicast packet of encrypted MLE Update message using the new MLE-key tothe link-scope all-nodes multicast address (FF02::1) (Key update Push: Step 3). FrameCounter field of auxiliary security header in this MLE message is set to zero. The
cryptographic protection of MLE Update message is set to ENC-MIC-32 (Security level 5).
The input values for cryptographic protection of MLE Update message are shown in Table
4.8-46. The MLE Update message carries Network Parameter TLV with Parameter ID=1
(PAN ID) shown in

Wi-SUN Profile for HAN

126 of 206

HAN Working Group

1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617

Table 4.8-47. PaC should discard the MLE Update message if different PAN ID is containedin the MLE Update message. When PAA sends this MLE Update message or PaC receives
it and succeeds in decrypting it, the key update procedure finishes. Both PAA and PaCs use
an old HAN group key for sending and receiving frames until completing the key update.
Once they complete the key update, they change the key for transmission and reception to
the new HAN group key.
If PAA is unable to receive PNA message from PaC due to retransmission timeout, it
terminates the session for that PaC.
PaC must wait at least 300 seconds in all for MLE Update message to be broadcasted by
PAA after responding with PNA message once. If the MLE Update message cannot bereceived within the period, the PaC should query a current key by Pull method first. And if
the PaC cannot receive a PNA (Pull response), the PaC must assume that the valid session
for itself does no longer exist.

1618

Table 4.8-46 CCM* inputs for MLE Update message

1619

Value
a datam data
CCM
nonce
Key

How to generate the Value
Source IP Address | Destination IP Address | Auxiliary Security Header
Note) Use AUX Header in the MLE message as above ”Auxiliary Security
Header”
From the Command Type field to the end of TLV in the MLE message
Source Address | Frame Counter | Security Level
Note) "Source Address" is retrieved from MAC Header, "Frame Counter" isretrieved from Aux Header of the MLE message, and "SerucirtyLevel" isretrieved from the Security Control field of the MLE message
Byte order must be big endian.
Use latest MLE key which received from PAA

1620
1621

Wi-SUN Profile for HAN

127 of 206

HAN Working Group

Table 4.8-47 The payload of MLE Update message

1622

Field
Initial byte

Value

Length(bits)

Description

08Initial byte of "0" indicates that the message is secured(encrypted and authenticated) as described in [802.15.4]
and [802.15.4g].

3

Security Level = 5

2

Length of Key Identifier field is 1 octet.

Aux Header (6 octets)
Security Control (1 octet)
Security Level
0b101
Key Identifier
0b01
Mode
Reserved
0b000
Frame Counter (4 octets)
Frame Counter0
Key Identifier (1 octet)
Key Source
Key Index

3320

No Key Source is used.

Key-ID

8“Key-ID” shall be same value as it to be set in Key-ID field of
HAN Group Key AVP sent with previous PNR message from
PAA.

0x05

8

Update command to inform of changes to link parameters
shared by all nodes in a network.

0x07
0x07

8
8

“Network Parameter”
Length of the Value field in octets.

0x01
0x0
Arbitrary
Arbitrary

8
32
16
32

”PAN ID”
No delay shall be specified.
PAN ID participating currently.
ENC-MIC-32

Command (10 octets)
Command TypeTLV (9 octets)
Type
LengthValue (7 octet)
Parameter ID
Delay
Value
MIC
1623
1624
1625
1626
1627

Note: All values in TLV are in network byte order (big endian).
PAA is allowed to perform PAA-Initiated PANA Authentication in any time and to try to reestablish a PANA session for a PaC with the session terminated due to key update failure.
(Authentication / Key distribution: Step 2 is changed to “Unsolicited PANA-Auth-Request(PRF-ALGO, INT-ALGO, ENC-ALGO and S-bit)” and restarts from here.)

1628
1629
1630
1631

PaC has some possible recovery methods from the loss of key information in the lower layer
and where key update procedure does not complete due to failure of receiving the PNR
message from PAA. PaC can periodically send either PANA Ping message or Pull message
Wi-SUN Profile for HAN

128 of 206

HAN Working Group

1632
1633

below in detail to PAA if the session lifetime is valid, and also PaC can start key updateprocedure again from sending PCI message if the session lifetime expires.

1634
1635

3.8.5.4.2.Acquisition of HAN group key by PaC (Pull)

1636

The sequence of key acquisition for Pull type is shown below.

1637

PAA

PaC

1: PANA-Notification-Request(ENC-ENCAP[HAN-Group-Key Request AVP], AUTH, P-bit)

2: PANA-Notification-Answer((ENC-ENCAP[HAN-Group-Key AVP]), AUTH, P-bit)

1638
1639

Figure 4.8-25 Key acquisition sequence for Pull type

1640
1641
1642
1643
1644
1645

PaC can request to acquire a HAN group key from PAA at any time within valid session(Pull).
HAN-Group-Key-Request AVP (vendor-specific AVP) is used to request a HAN group key.
In this case, the AVP contains Key-ID of current HAN group key in the PaC. HAN-GroupKey-Request AVP shall be encrypted using Encryption-Encap AVP.

1646
1647

The detail of the PNR message with HAN-Group-Key-Request AVP is shown below.

1648
Wi-SUN Profile for HAN

129 of 206

HAN Working Group

1649

Wi-SUN Profile for HAN

130 of 206

HAN Working Group

1650
1651

Table 4.8-48 Key update Pull (Step 1): Message of PNR (ENC-ENCAP[HAN-Group-Key
Request AVP],AUTH,P-bit)
Field

Sub field

Size(octet) Description

PANA

Reserved

2

Message Message Length264

HeaderFlags

2‘R’=1、’P’=1

Message Type2

4= PANA-Notification-Request

Session Identifier

4

Sequence
Number4

PANA
PayloadEncryption-Encap 24
AVP
HANGroup-Key
RequestAVP
AUTH AVP

16

24

HAN-Group-Key Request AVP is a vendor
specific AVP containing Key-ID, which isdefined in this document. It is encrypted andencapsulated in Encryption-Encap AVP.

contains Message Authentication Code

1652

1659

If PAA receives a PNR message with HAN-Group-Key-Request AVP (vendor-specific AVP)
from a PaC, it returns a PNA message with HAN-Group-Key AVP (vendor-specific AVP).
The HAN-Group-Key AVP contains HAN group key, MLE Key, Key-ID, AuthCounter, andoutgoing frame counter of PAA. The HAN-Group-Key AVP shall be encrypted using
Encryption-Encap AVP. If the Key-ID in the HAN-Group-Key-Request AVP is equal to thatof current HAN group key, the PNA message which PAA returns does not contain HANGroup-Key AVP (PAA returns PNA message without vendor-specific AVP).

1660

See 3.8.5.4.6 for more information about HAN group key generation.

1661

See 3.8.5.4.7 for more information about HAN-Group-Key-Request AVP encryption.

1662

See 3.8.5.4.3 for more information about HAN-Group-Key-Request AVP.

1653
1654
1655
1656
1657
1658

1663
1664

The detail of the PNA message with vendor-specific AVP is shown below.

1665
Wi-SUN Profile for HAN

131 of 206

HAN Working Group

1666

Wi-SUN Profile for HAN

132 of 206

HAN Working Group

1667
1668

Table 4.8-49 Key update Pull (Step 2): Message of PNA (((ENC-ENCAP[HAN-GroupKey]),AUTH, P-bit))Field

Sub field

Size(octet) Description

PANA

Reserved

2

Message Message Length

284

Header

Flags

2

’P’=1

Message Type2

4= PANA-Notification-Answer

Session Identifier

4

Sequence
Number4

Encryption-Encap
AVP

60

PANA
PayloadHANGroup-Key
AVP
AUTH AVP

52

24

HAN-Group-Key AVP is a vender-specific
AVP containing HAN-Group-Key, which isadded in this specification. It is encrypted andthen encapsulated in Encryption-Encap AVP.

contains Message Authentication Code

1669
1670
1671

If PaC receives this PNA message with HAN-Group-Key AVP from PAA, PaC sets security
information on its MAC layer. See 3.8.5.5 for more information.

1672
1673

Wi-SUN Profile for HAN

133 of 206

HAN Working Group1674

3.8.5.4.3.Vendor-specific AVP

1675
1676

The definition of the HAN-Group-Key AVP and the HAN-Group-Key-Request AVP are as
follows.

1677-

HAN-Group-Key AVP
OctetsFieldsRemark2

AVP code

1

2

AVP flags

1, meaning V bit, indicates Vendor-ID field
is present

2

AVP length

AVP value length is 40

2

Reserved

As a rule set to 0, but don’t care

4

Vendor-ID

45605

16

HAN Group Key

16 octets HAN Group Key

16

MLE Key

16 octets MLE Key

1

Key-IDThe Key-Index (one octet) of the Auxiliary
security header in a MAC header. If the
HAN group key is different from provided
in last time, it's must set another Key-ID

1Auth counter

One octet authorization counter2

Reserved

As a rule set to 0, but don’t care

4

Frame counter out

Four octets frame counter. This is a PAA’s
outgoing frame counter of the Auxiliary
security header in a MAC header.

1678
1679
1680

Wi-SUN Profile for HAN

134 of 206

HAN Working Group

1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709

0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|AVP Code(1)|AVP Flags(V bit=1)|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|AVP Length(40)|Reserved|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|
Vendor-Id (45605)|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
+
+
|
HAN Group Key
|
+
+
|
|
+
+
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
+
+
|
MLE Key
|
+
+
|
|
+
+
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|
Key-ID| Auth Counter |Reserved|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|
Frame Counter Out|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1710
1711

Wi-SUN Profile for HAN

135 of 206

HAN Working Group

1712

-

•HAN-Group-Key-Request AVP
OctetsFieldsRemark2

AVP code2

2

AVP flags

1, meaning V bit, indicates Vendor-ID field
is present

2

AVP length

AVP value length is 1

2

Reserved

As a rule set to 0, but don’t care

4

Vendor-ID

45605

1

Key-ID

It is used as the Key-Index (one octet) of
the Auxiliary security header in a MAC
header

1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725

0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|AVP Code(2)|AVP Flags(V bit=1)|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|AVP Length(1)|Reserved|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|
Vendor-Id (45605)|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|
Key-ID |Padding|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1726
1727

3.8.5.4.4.HAN group key Management

1728

PAA should update HAN group key by Push before expiration, before outgoing frame
counter overflows, or before incoming frame counter overflows. PAA manages both of
maximum and minimum lifetimes for the HAN group key. The maximum lifetime shall haveenough margin of the time for the frame counter overflow (one month, 30 days
recommended). Also the minimum lifetime shall have enough margin in order to prevent
frequent updating a key by the PaC continuously authentication (one hour recommended).

1729
1730
1731
1732
1733
1734
1735
1736
1737
1738

PAA can update the HAN group key after minimum lifetime of key update interval and shallupdate the HAN group key if there is a PaC of which authentication counter reached 255.
PAA will update the HAN group key and reset the authentication counters of all PaCs to 0.
In other cases, PAA checks authentication counter of a PaC whenever it is (re)authenticatedand update the HAN group key if the authentication counter reached 255 as well.
Wi-SUN Profile for HAN

136 of 206

HAN Working Group

1739
1740
1741
1742
1743
1744
1745

In the minimum lifetime of key update interval, If PAA receives authentication request from a
PaC of which authentication counter reached 255, PAA shall refuse the request with
Result-Code＝PANA_AUTHORIZATION_REJECTED(2) to the PaC and shall not update
key in the period of minimum lifetime.
This lifetime for the HAN group key shall start to be counted down at immediate after the
PANA session against very first PaC has established successfully or the key update anddistribution has been completed.

1746
1747

3.8.5.4.5.Authentication counter (AuthCounter) management

1748

PAA manages the value of the authentication counter (AuthCounter) which indicates thenumber of PaC’s authentication times.

1749
1750
1751
1752
1753
1754
1755
1756

AuthCounter is one byte value, and effective range is 0 to 255. PAA increments its value
when PAA authenticates a PaC in either ‘Authentication and Authorization’ phase or ‘ReAuthentication’ phase. PAA will notify AuthCounter value 0 of the PaC at successfulauthentication in the first time.
PAA manages AuthCounter value in each PaC. The range is 0 to 255. Even if PAA
terminates the session of the PaC, AuthCounter value of the PaC is kept until updating HAN
group key. PAA can identify the individual PaC with its IPv6 address.

1757
1758

3.8.5.4.6.HAN group key generation

1759

The length of the HAN group key is 128 bits and the key is generated with a pseudo randomfunction by PAA (HEMS) at start-up or key-update. PAA (HEMS) sets this HAN group key toits MAC layer as a common security key for unicast and multicast. And a 128-bit MLE key isalso generated with a pseudo random function by PAA in the same manner. This MLE key
is used for encrypting MLE Update message in the Push type key-update.

1760
1761
1762
1763
1764
1765

3.8.5.4.7.Encryption/decryption key generation for vendor-specific AVP

1766

The HAN-Group-Key AVP and the HAN-Group-Key-Request AVP are vendor-specific
AVPs .They are transmitted after encrypted in the Encryption-Encap AVP [PANA-ENC].
Encryption/decryption algorithm of Encryption-Encap is derived from
PANA_PAA_ENCR_KEY/PANA_PAC_ENCR_KEY according to the [PANA-ENC]. The prf+
uses the PRF_HMAC_SHA 2_256 algorithm in the pseudorandom-number function.

1767
1768
1769
1770
1771

Wi-SUN Profile for HAN

137 of 206

HAN Working Group

1772

3.8.5.4.8.Network reconfiguration notification

1773

The HEMS (PAA) uses a PTR message to notify network reconfiguration to the device(PaC). PAA transmits PTR messages to all of PaC which has an effective session. Each
PaC which received a PTR, replies a PTA to the PAA. After receiving PTA messages fromall of PaC which has an effective session, the PAA immediately starts network
reconfiguration. The PAA can transit to network reconfiguration even if there is any noresponded PaC (the session of no-responded PaC will be terminated).

1774
1775
1776
1777
1778
1779
1780
1781
1782

PAA does not need to respond to the Enhanced Active Scan during waiting PTA responses
from PaCs or incomplete network reconfiguration.
Each device starts to do Enhanced Active Scan after sending PTA and tries to reconnect /re-authenticate to the HEMS.

1783
1784

3.8.5.5. Encryption and Integrity check

1785

The MAC data frame shall be ciphered based on [802.15.4] using the latest HAN group key
distributed by PAA. In order to realize both of confidentiality and integrity, ENC-MIC-32(Security level 5) is used. The node shall discard a frame with invalid MIC.

1786
1787
1788
1789

Key identifier mode is 0x01. Key Source in the key identifier field is not used and one-octet
Key Index is used.

1790
1791

Exception of MAC security

1792

All PANA messages (UDP destination port 716), MLE message (UDP port 19788) and IPv6
Neighbor Solicitation (NS) (ICMPv6 Type 135 Code 0)/Neighbor Advertisement (NA)(ICMPv6 Type 136 code 0) messages shall not be applied MAC layer security (do not add
MAC auxiliary security header).

1793
1794
1795
1796
1797

3.8.5.6. Replay protection

1798

See 3.5.7.5 in this document.

1799
1800
1801
1802
1803

3.8.6. Recommended network configurations
The HEMS and devices share a “Pairing ID” with 8-octet length, and this ID is used in the
network discovery. There are two network discovery procedures defined in this document.
They are “Initial setup mode” and “Normal operation mode”. The “Initial setup mode” is a
Wi-SUN Profile for HAN

138 of 206

HAN Working Group

1808

special mode for devices joining the network in the first time. Once the devices learns their
network (HEMS’ MAC address as the Pairing ID in the Normal operation mode), the HEMS
and devices move to “Normal operation mode”. The “Normal operation mode” is used in theregular operation. In addition, NAI and pre-shared key for PANA/EAP are also set to eachnode in advance.

1809

The HEMS sets the radio channel and PAN ID in accordance with following procedure.

1804
1805
1806
1807

1810
1811

1-1: Data link (MAC) layer configuration,

1812

Radio channel selection and PAN ID selection are conducted via ED scan and Enhanced
Active Scan. The criteria of the radio channel selection and PAN ID selection is out of scopein this document.

1813
1814
1815
1816

1-2: Network layer configuration,

1817

The HEMS generates its own IPv6 link local address compliant to [SLAAC].

1818

After the HEMS as a coordinator completes the network construction, the devices attempt toconnect to the HEMS in accordance with the following configurations.

1819
1820
1821

2-1: Data link (MAC) layer configuration,

1822

The device identifies the HEMS network by Enhanced Active Scan.

1823
1824

2-2: Network layer procedure,

1825

The device generates its own IPv6 link local address compliant to [SLAAC].

1826
1827

3.8.6.1. Bootstrapping

1828

Once the HEMS is turned on, it constructs a new network compliant to this document. This
procedure is same as sub clause 3.6.6.1. And, once the device is turned on, it attempts toconnect to the network that is constructed by the HEMS. This procedure is same as sub
clause 3.6.6.2. Overview of network configuration and association procedure to the network
is shown in Figure 4.8-26.

1829
1830
1831
1832
1833

Wi-SUN Profile for HAN

139 of 206

HAN Working GroupA coordinator turned on(1)Channel selection(2)

PAN ID determination(3)

IPv6 address generation

(4)

DAD

A new Host turned on

Data link layer
configurations

Network layer
configurations(1’)

Network detection(2’)

Network selection to associate(3’)

IPv6 address generation

(4’)

DAD

Data link layer
configurations

Network layer
configurations

1834
1835

Figure 4.8-26 Overview of network construction procedure

1836
1837

3.8.6.1.1.Data link layer configuration

1838

Data link layer configuration of a coordinator is same as sub clause 3.6.6.1.1, butcoordinator must set no information to its Information Elements fields in Enhanced Beacon
Request if Active scan is employed.

1839
1840

1847

In order to detect the HEMS network, the device uses an Enhanced Active Scan and sets
MLME IE to its Information Elements field which is terminated with a list termination IE(ID=0xf). As a response to the Enhanced Beacon Request command from the device, theHEMS should send an Enhanced Beacon that sets the same MLME IE to its Information
Elements field which is terminated with a list termination IE (ID=0xf). Association procedure
should be omitted. Other data link layer configuration of the device is same as sub-clause
3.6.6.2.1.

1848

Configuration information is shown in Table 4.8-50

1841
1842
1843
1844
1845
1846

1849

Wi-SUN Profile for HAN

140 of 206

HAN Working Group

Table 4.8-50 Sub-ID (MLME IE)

1850

Sub-ID
value

Content length Name

Description

0x68

VariableThis Sub-ID is used as the information to
help the device detects thecorresponding HEMS network. This SubID is defined by this profile.

Unmanaged(Pairing ID)

1851
1852
1853

"ScanDuration" value for Enhanced Active Scan, that is specified in [802.15.4], is
recommended to set to 5 in order to establish the network connection in a short time.

1854
1855

3.8.6.1.2.Network layer configuration

1856

The HEMS uses IPv6 link local address only. Other network layer configuration of the
HEMS is the same as sub clause 3.6.6.1.2.

1857

1859

The device also uses IPv6 link local address only. Other network layer configuration of thedevice is the same as sub clause 3.6.6.2.2.

1860

Authentication procedure refers to sub clause 3.7.6.3.

1858

1861
1862

3.8.6.2. IP Address Detection

1863
1865

Before starting the PANA authentication procedure, the device figure out the HEMS’ IPv6
link local address from the source MAC address in the Enhanced Beacon message
responded by the HEMS.

1866

The device may omit Neighbor Discovery procedure defined in [ND].

1864

1867
1868

3.8.6.3. Authentication and Key Exchange

1869

The device performs security setup after its data link layer and network layer configurations.
In other words, the device acts as a PaC and initiates a PANA session to the HEMS (PAA)..

1870
1871

Wi-SUN Profile for HAN

141 of 206

HAN Working Group

1872

3.8.6.4. Application

1873

As stated in 3.8.4.5, use ECHONET Lite as an application protocol, and support using
compound data format.

1874
1875

1876

3.8.7. Usage of credential

1877

In HAN network, a HAN specific credential (Table 4.8-51) is defined and required to use it.
For this purpose, this subsection defines how to use the credential in the communication
protocols.

1878
1879
1880

Table 4.8-51 HAN Credential

1881

Name

Description

HAN
authentication
ID

Unique ID used to pair up a specific HAN device and HEMS. Character
string of 24 comprised of 0~9 and A~F ASCII characters (24 octets).
The first character string of eight characters is “01000000” and thefollowing string of 16 characters (16 octets) is described inhexadecimal notation of MAC address of the HAN device (end-device
or HEMS). In this profile, this is converted to the ID ([NAI] format) used
by PANA (EAP-PSK) by the rule described later.

(HAN
Password linked to the HAN authentication ID (character string of 16
authentication) comprised of 0~9, a~z, and A~Z ASCII characters). In this profile, thisPasswordis used in generating PSK, which is utilized in [EAP-PSK], by the ruledescribed later.
1882
1883
1884

3.8.7.1. Conversion of HAN authentication ID to EAP Identifiers

1885

Based on the 24 digit HAN authentication ID, the following rules are used to generate theEAP Identifiers (ID_S, ID_P) ([NAI]).

1886[NAI generation rules]
HEMS side NAI (EAP ID_S): ”CTRL” + ”HAN authentication ID of HEMS” (24 octets)

Wi-SUN Profile for HAN

142 of 206

HAN Working Group

HAN device side NAI (EAP ID_P): ”NODE” + ”HAN authentication ID of HAN device” (24octets)Example:When HEMS HAN authentication ID is "010000001111222233334444"
and HAN device HAN authentication ID is “010000005555666677778888”
HEMS side NAI (EAP ID_S): "CTRL010000001111222233334444"
HAN device side NAI (EAP ID_P): "NODE010000005555666677778888"
The MAC address in the HEMS is supposed to be “1111222233334444”
The MAC address in the HAN device is supposed to be “5555666677778888”
1887

3.8.7.2. Conversion of Password to PSK1888

PSK used in the EAP-PSK negotiation is generated using the following rules.

[PSK generation rules]
Based on the Password linked to the HAN authentication ID, the following PSK generation
function (PSK_KDF) is used to generate the 16 octet PSK.

PSK = PSK_KDF(Password)= LSBytes16(SHA-256(Capitalize(Password))(lower order 16 octets of the output created by using SHA-256 in the hash function on thecapitalized Password character string)

Example:When the Password is ”0123456789abcdef”
PSK = LSBytes16(SHA-256(“0123456789ABCDEF”))= 0x91d828cb942c2df1eeb02502eccae9e9
1889

Wi-SUN Profile for HAN

143 of 206

HAN Working Group1890

3.8.8. Discovery and selection of the HEMS network

1891

The HAN device performs Enhanced Active Scan with IEs field in order to detect a HEMS.
MLME IE (Group ID=0x1) will be used for the Payload IEs field of the Enhanced Beacon
Request sent by the HAN device, and the eight octets Pairing ID defined in both Initial setup
mode and Normal operation mode will be included in the IE Contents of SubID=0x68(Unmanaged). When the Pairing ID stored in MLME IE of the Payload IEs matches
the Pairing ID stored in the HEMS, the HEMS responds by returning the Enhanced Beacon.
This Enhanced Beacon is unicast and includes the same Pairing ID in the Payload IEs fieldof the Enhanced Beacon Request. After confirmation that the HEMS has the same Pairing
ID, the HAN device will start PANA negotiation with this HEMS. (Figure 4.8-27)

1892
1893
1894
1895
1896
1897
1898
1899
1900

Pairing ID: “HAN_INIT”
ID_S : “CTRL010000001111222233334444”
ID_P : “NODE010000005555666677778888”

HEMS

HAN device

Enhanced Beacon Request with IEs (Paring ID& Capability Notification)
Enhanced Beacon with IEs (Paring ID &Capability Notification)

Start PANA authentication process

1901
1902

Figure 4.8-27 HEMS discovery procedure (Initial setup mode)

1903
1904

< Initial setup mode (Figure 4.8-27) >1905

The HEMS enters the Initial setup mode before a new HAN device trying to connect to theHEMS. The HAN device uses an Enhanced Active Scan and detects the target HEMS. The
Initial setup mode has a valid period and the recommended value is five minutes. During
this mode, the Pairing ID shall be “HAN_INIT”. The HAN device starts PANA authentication
procedure with the corresponding HEMS after Enhanced Active Scan with this Pairing ID.
After the expiration of the valid period, the HEMS disables the Pairing ID “HAN_INIT” for theInitial setup mode and turn into the Normal operation mode. After successful PANA

1906
1907
1908
1909
1910
1911

Wi-SUN Profile for HAN

144 of 206

HAN Working Group

1912
1913
1914
1915
1916

authentication in the Initial setup mode, the HAN device sets the HEMS’ MAC address as
the Pairing ID in the Normal operation mode. If PANA authentication failed, the HAN device
tries to find the corresponding HEMS until PANA authentication succeeds. The HAN device
can use an Enhanced Active Scan again to the all radio channels if it finds no HEMS on all
channels or authentication fails.

1917

Paring ID: 0x1111222233334444
ID_S : “CTRL010000001111222233334444”
ID_P : “NODE010000005555666677778888”

HEMS

HAN device

Enhanced Beacon Request with IEs (Paring ID& Capability Notification)
Enhanced Beacon with IEs (Paring ID &Capability Notification)

Start PANA authentication process

1918
1919

Figure 4.8-28 HEMS discovery procedure (normal mode)

1920
1921

< Normal operation mode (Figure 4.8-28) >1922

The HEMS’ MAC address is used as the Pairing ID in the Normal operation mode.

1923

When the HAN device detects that the session is being expired, the HAN device mayproceed Enhanced Active Scan to discover HEMS. In this case, it is not desired that theHAN device continues frequent Enhanced Active Scan for a long time from radio traffic
perspective. When the HAN device continues the Enhanced Active Scan for more than 5
minutes, after that, the HAN device is recommended to set at least 3 minutes interval
between each Enhanced Active Scan.

1924
1925
1926
1927
1928
1929
1930
1931
1932

Once the HAN device connects to a HEMS, the HAN device should calculate the IPv6 link
local address of the HEMS from the source MAC address of Enhanced Beacon message.
And the HAN device starts a PANA authentication with its NAI and PSK which are preshared. The HEMS authenticates the HAN device(s) based on the NAI and PSK. The
Wi-SUN Profile for HAN

145 of 206

HAN Working Group

1933
1934
1935
1936
1937
1938
1939

HEMS distributes a HAN group key for which the HEMS and the HAN device share theMAC layer encryption key after successful authentication.
After sharing the MAC layer encryption key, the communication between the HEMS and the
HAN device(s) is encrypted by the HAN group key. The HEMS conducts a service discovery
procedure and sends some commands to the HAN device using ECHONET Lite protocol,and the HAN device(s) can run some operations based on the requests and respond their
execution results to the HEMS.

1940

Wi-SUN Profile for HAN

146 of 206

HAN Working Group

1941
1942

3.9.

Recommended usage for multi-hop home area network
employing relay device

1943

3.9.1. Overview

1944This clause clarifies the recommended usage in the case the relaying is employed by themultiple devices that are shown in 3.8. Figure 4.8-29 shows a typical example assumed
network topologies.

1945
1946
1947

HEMS
(PAN coordinator)

HAN-end/relay-device(Device/Coordinator)
1948
1949

HAN-relay-device(Coordinator)

HAN-end/relay-device(Device/Coordinator)

Figure 4.8-29 Network topology for HAN employing relay among devices

1950
1951
1952
1953

Since this clause shows only the required amendment from the previously clarified
specifications, it is recommended that authors should refer the existing 3.8 for the otherspecifications as necessary.

1954
1955

3.9.1.1. Installation order of HAN-relay-device and HAN-end-device

1956

In the situation of Figure 4.8-30 device A is as HEMS, device B with relaying capability is
named HAN-relay-device and device C without relaying capability is named as HAN-enddevice. In the network topology assuming relaying as shown in Figure 4.8-30, B is assumed
to be installed before C. Details is described in 3.9.3.3.

1957
1958
1959
1960

Wi-SUN Profile for HAN

147 of 206

HAN Working Group

1961
1962

A

B

C

HEMS
(PAN Coordinator)

HAN-relay-device(Coordinator)

HAN-end-device(Device)

Figure 4.8-30 Installation order of HAN-relay-device and HAN-end-device

1963
1964

3.9.2. PHY part

1965

Since there is no new amendment, the HEMS and the devices shall follow 3.8.2.

1966

1967

3.9.3. MAC part

1968

This clause shows amendments for HAN employing relay in MAC layer. The otherspecifications should be referred in 3.8.3.

1969
1970
1971

3.9.3.1. MAC sub-layer function

1972

Table 4.8-52 shows amendments in MAC sub-layer functions.

1973

Wi-SUN Profile for HAN

148 of 206

HAN Working Group

Table 4.8-52 Amendments in MAC sub-layer functions

1974

Item
numberItem description

Reference
section instandard

Status instandard(M:Mandatory,
O:Option)

Support(Y:Yes,
N:No,
O:Option)

MLF24

Relay support in HAN

O

MLF24.1

MHR management forforwarding

MLF24:Y

MLF24.2

Frame counter management

MLF24:Y

MLF24.3

Multicast transmission

MLF24:Y

MLF24.4

IEs for relay in HAN

MLF24:Y

1975
1976

3.9.3.1.1.MHR management for forwarding

1977

The device supporting this function shall conduct relaying of the MAC payload by the MAC
layer management entity by updating Source/Destination addresses in the MAC header
according to the IE as described later.

1978
1979
1980
1981

3.9.3.1.2.Frame counter management

1982

The device supporting this function shall realize the frame counter information exchange
between HAN-end-device and the HAN-relay-device that is on the next hop towards the
PAN coordinator after the HAN-end-device is authorized via PANA.

1983
1984
1985
1986

3.9.3.2. MAC frame format

1987

This clause shows the amendments in MAC frame format.

1988

This profile employs the [802.15.10] Short Route Announcement (SRA) IE and the Short
L2R Routing (SLR) IE to support HAN relay.

1989

Wi-SUN Profile for HAN

149 of 206

HAN Working Group

1990

3.9.3.2.1.Capability Notification IE (CN IE)

1996‘Relay-endpoint’ flag and ‘HAN-relay-device’ flag in CN IE are used to exchange capabilityof relay enabled HAN. At the sending of this IE, the sender of Enhanced Beacon Request
command must set flags for all the available functions to this IE as request. On the other
hand, the sender of Enhanced Beacon must set flags for the functions to use in response to
the CN IE in the EBR. The following shows an example to handle relay and sleep function
capabilities change.

1997

i)

If the sender of EB is HEMS or HAN-end-device which supports the relay function,
Relay-endpoint (bit 6) in the sending EB shall be set to "1". Otherwise, it must be
set to "0".

ii)

If a HAN-relay-device received EBR but it has CN IE which sets all flags to "0", or no
CN IE attached, the HAN-relay-device must not respond with EB to the requesting
device.

1991
1992
1993
1994
1995

1998
1999
2000
2001
2002
2003
2004

3.9.3.2.2.DATA frame

2005

Differently from the definition in 3.8.3., Payload IE deployments of SLR IE as described later
are assumed. The Payload IEs shall be included in the portion of the data frame to be
encrypted together with the data payload.

2006
2007
2008
2009

3.9.3.2.3.Enhanced beacon frame

2010

Similarly to the definition in 3.8.3., Payload IE deployment of SRA IE is assumed.

2011

Wi-SUN Profile for HAN

150 of 206

HAN Working Group2012

3.9.3.2.4.IEs for relay in HAN
The SRA IE and theSLR IE are depicted in Figure 4.8-31 and2013
Bits: 0-10

11-14

15

Octets: Variable

LengthGroup ID (MLME IE)

Type = 1 (Payload)

Sub IE

Bits: 0-7

8-14

15

Octets: Variable

LengthSub ID

Type = 0 (Short)

IE Content

Octets:2/8

2/8

1

0/1

0/Variable

SourceAddress

Destination
Address

L2R Sequence
NumberNumber ofIntermediate Address

Intermediate
Address List

2014
2015
Octets: 0/2/8…

Octets: 0/2/8

Intermediate hop 1…

Intermediate hop N

2016
2017

Figure 4.8-32 respectively.

2018
2019

The MLME IEs to be defined in this clause shall be nested within single MLME IE together
with the other MLME IEs to be conveyed with same frame if existing.

2020

The contents of these IEs should be aligned to little endian byte order.

2021

2024

The SRA IE (Sub-ID=0x3A) is included in the Enhanced beacon frame that is transmitted
by Coordinators except for PAN coordinators, in order to indicate the addresses of HANrelay-device(s) as well as the PAN coordinator. Details of its fields are shown below.

2025(1) Vendor Specific Usage field

2022
2023

Wi-SUN Profile for HAN

151 of 206

HAN Working Group

2028

This field indicates if the following field represents the Sequence Number of the SRA IE (0)or if it is vendor specific. This field is set to 1 to specify the use of the following fieldaccording to the HAN relay requirements.

2029(2) SN or Vendor Specific field

2030

2034

Since the Vendor Specific Usage field is set to 1, this field is defined as vendor specific for
HAN Relay usage. The first 4 bits are reserved. The bits 5 to 7 contain the Priority field. This
field indicates the priority of the HAN-relay-devices that transmits the IE in the Enhanced
beacon. In this specification, this Priority field can be ignored by received node (HAN-enddevice).

2035(3) Source Address field

2036

This field contains the address of the PAN coordinator.

2037(4) Number of Intermediate Addresses field

2038
2039

This field indicates the number of intermediate HAN-relay-devices to the PAN coordinatorthat excludes the initiating device of the IE in order starting next to the HAN-end-device.

2040(5) Intermediate Address List field

2041

This field indicates the addresses of intermediate HAN-relay-devices to the PAN coordinatorthat excludes the initiating device of the IE. The indicated addresses are shown in the subfields of Intermediate hop 1-N.

2026
2027

2031
2032
2033

2042
2043
2044
2045
2046

The addressing mode used in the SRA IE shall be the same address mode as in the MHR.
This IE can support up to 12 hops if EUI-64 addresses are used, and up to 49 hops if 16-bit
addresses are used.

2047

Wi-SUN Profile for HAN

152 of 206

HAN Working Group

Bits: 0-10

11-14

15

Octets: Variable

LengthGroup ID (MLME IE)

Type = 1 (Payload)

Sub IE

Bits: 0-7

8-14

15

Octets: Variable

LengthSub ID

Type = 0 (Short)

IE Content

2048

2049

Bits: 01-7

Octet:2/8

1

0/Variable

Vendor SpecificUsage

SN or Vendor
Specific

SourceAddress

Number of Intermediate
Addresses

Intermediate
Address List

Bits: 1-4

5-7

Octets: 0/2/8…

Octets: 0/2/8

Reserved

Priority

Intermediate hop 1…

Intermediate hop N

2050

2051

Figure 4.8-31 SRA IE

2052
2053

2058

The SLR IE (Sub-ID=0x3D) is included in several frames such as data frame and indicates
Source/Destination information of end-to-end devices of the frame payload. This IE also
indicates the addresses of the intermediate HAN-relay-devices that relay the frame towards
the PAN coordinator according to the SRA IE received during Enhanced Active Scan.
Details of its fields are shown below.

2059

(1)

2060
2061

(2) The Destination Address field contains the address of the destination device of theframe.

2062(3) L2R Sequence number field

2063
2064

This field indicates the identifier of the frame payload. By referring the value of this field,
duplicated frames can be discarded in the multicast transmission.

2065(4) Number of intermediate Address field

2054
2055
2056
2057

The Source Address field contains the address of the device originating the frame.

Wi-SUN Profile for HAN

153 of 206

HAN Working Group

2066
2067

This field indicates the number of intermediate HAN-relay-devices to the PAN coordinatorthat excludes the initiating device of the IE in order starting next to the HAN-end-device.

2069

The Number of Intermediate Address field is always present, and if it is set to zero, theIntermediate Address List field is omitted.

2070(5) Intermediate Address List field

2071

This field indicates the addresses of intermediate HAN-relay-devices to the PAN coordinatorthat excludes the initiating device of the IE. The indicated addresses are shown in the subfields of Intermediate hop 1-N.

2068

2072
2073
2074

Bits: 0-10

11-14

15

Octets: Variable

LengthGroup ID (MLME IE)

Type = 1 (Payload)

Sub IE

Bits: 0-7

8-14

15

Octets: Variable

LengthSub ID

Type = 0 (Short)

IE Content

Octets:2/8

2/8

1

0/1

0/Variable

SourceAddress

Destination
Address

L2R Sequence
NumberNumber ofIntermediate Address

Intermediate
Address List

2075
2076
Octets: 0/2/8…

Octets: 0/2/8

Intermediate hop 1…

Intermediate hop N

2077
2078

Figure 4.8-32 SLR IE

2079
Wi-SUN Profile for HAN

154 of 206

HAN Working Group

2080

3.9.3.3. Examples of typical device operation

2081

Figure 4.8-33 shows an example of relay operation in the MAC layer. At turned on, theHEMS starts the PAN as the PAN coordinator, defines the employed channel according to
the situation. After that, a HAN-relay-device named as device A is turned on and finds the
HEMS via the scan procedure. Here, HEMS responds to the Enhanced beacon requestfrom device A by returning an Enhanced beacon without SRA IE. That is, frame exchanges
between device A and HEMS is conducted without exploiting relay in MAC layer. Then, in
the Figure 4.8-33, a HAN-end-device named as device B is turned on. Here it should be
noted that device A is assumed to be a coordinator. While device B can also find device A
after its scan procedure in the similar manner, device A returns an Enhanced beacon with a
SRA IE since device A is not the PAN coordinator and needs to show the relay route to the
PAN coordinator. After that, device B can send a frame whose final destination is HEMS byconstructing it as a MAC frame including a suitable SLR IE and initially addressed to device
A according to the received SRA IE information. At receiving the frame, device A relays theframe by updating the Source/Destination addresses in the MAC header according to the
SLR IE in MAC layer. As a result, the frame initiated on device B reached to HEMS throughdevice A. Since HEMS acquires the relay route to device B as well as confirms theexistence of device A and B, which is required on the higher layer operations, by reversing
the addresses in the Intermediate hops field in the received SLR IE, HEMS can realize therelayed transmission to device B hereafter.

2082
2083
2084
2085
2086
2087
2088
2089
2090
2091
2092
2093
2094
2095
2096
2097
2098
2099
2100

Wi-SUN Profile for HAN

155 of 206

HAN Working GroupHEMS(PAN coordinator)
Device A(Coordinator)

Device B(Coordinator/Device)EBR

EB w/ SRA-IE
EBR

EB w/ SRA-IE

Data to HEMS w/ SLR-IE generated
according to the received SRA-IE

Relayed data after MHR translation
by referring the SLR-IE
HEMS can send a data to Device B by
employing SLR-IE that is reversed form theone once received from Device B

Relayed data after MHR translation byreferring the SLR-IE

2101
2102

Figure 4.8-33 Example of relay operation in MAC layer

2103
2104
2105
2106
2107
2108

3.9.3.3.1.Examples of operations in case HAN-relay-device is installed after HAN-enddevice
When a HAN-relay-device is newly installed in the situation a HEMS and a HAN-end-device
are operating a network, the HAN-end-device shall reset after installing the HAN-relaydevice.

2109

Wi-SUN Profile for HAN

156 of 206

HAN Working Group

2110

3.9.4. Interface part2111

3.9.4.1. Overview

2112

The interface of a home area network employing relay devices for ECHONET Lite over IPv6
shall be compliant with clause 3.8.4 unless otherwise specified in the following sub clauses.

2113
2114
2115

3.9.4.2. Adaptation layer

2116

See 3.8.4.2 in this document.

2117
2118

3.9.4.2.1.Fragmentation

2119

See 3.8.4.2.1 in this document.

2120
2121

3.9.4.2.2.Header compression

2122

The 6LoWPAN Header compression requirements shall be compliant with clause 3.8.4.2.2,
except identification method of source destination IP addresses at the final destination.
When final destination node of 6LoWPAN packet needs to identify or reproduce the source
and/or destination IP address of receiving 6LoWPAN packet, it must be done based on
original source address and final destination address conveyed with theSLR IE, instead ofsource and destination addresses contained in the MHR.

2123
2124
2125
2126
2127
2128
2129

3.9.4.2.3.Neighbor Discovery

2130

See 3.8.4.2.3 in this document

2131

.

2132

3.9.4.3. Network layer

2133

See 3.8.4.3 in this document.

2134
2135

3.9.4.4. Transport layer

2136

See 3.8.4.4 in this document.
Wi-SUN Profile for HAN

157 of 206

HAN Working Group

2137
2138

3.9.4.5. Application layer

2139

See 3.8.4.5 in this document.

2140

2141

3.9.5. Security configuration

2142

3.9.5.1. Overview

2143

HEMS and devices shall conform to specification described in 3.8.5.1 in this document
unless otherwise described in this clause.

2144
2145
2146

3.9.5.2. Authentication

2147

HEMS and devices shall conform to specification described in 3.8.5.2 in this document
unless otherwise described in this clause.

2148
2149
2150

3.9.5.2.1.PANA

2151

3.8.5.2.1 shall be supported, additionally assuming that the PAA-PaC session is supportedby the relay in MAC as in 3.9.3, as necessary.

2152
2153
2154
2155
2156

PANA termination sequence between HEMS and HAN-relay-device is just run in regularmanner. HAN-relay-device should keep at least 15 (=16 – relay device itself) routing
information entries at same time (The number ‘16’ is same as the minimum capacity for
PaCs defined in 3.8.5.2.1).

2157
2158

3.9.5.2.2.EAP

2159

3.8.5.2.2 shall be supported.

2160
2161

3.9.5.3. Authentication and key distribution

2162

The specification defined in 3.8.5.3 shall basically be supported in this section, so there isno difference to that on authentication and encryption key distribution to be done between
HEMS and HAN-relay-device. Additionally, HAN-relay-device shall be allowed to not accept

2163
2164

Wi-SUN Profile for HAN

158 of 206

HAN Working Group

2165
2166
2167
2168

any communication to be requested from HAN-end-device while HAN-relay-device isongoing authentication and key distribution process.
The specification below shall be applied to these procedures to be done between HEMS
and HAN-end-device.

2169
HAN-relaydevice

HEMS

HAN-enddevice

1: PANA-Client-Initiation()
2: PANA-Auth-Request(PRF-ALGO, INT-ALGO, S-bit)(Encryption-Algorithm AVP = AES128_CTR)
3: PANA-Auth-Answer(PRF-ALGO, INT-ALGO, S-bit)(Encryption-Algorithm AVP = AES128_CTR)
4: PANA-Auth-Request(NONCE, EAP-PAYLOAD)
5: PANA-Auth-Answer(NONCE, EAP-PAYLOAD)

6: PANA-Auth-Request(EAP-PAYLOAD)
7: PANA-Auth-Answer(EAP-PAYLOAD)
Derive the value of outgoing frame
counter for HAN-end-device.
8: PANA-Notification-Request (FCN AVP, AUTH, P-bit)
Incoming frame counter to
HAN-end-device configuration
9: PANA-Notification-Answer (FCN AVP, AUTH, P-bit)
Incoming frame counter to HANrelay-device configuration
Derive the value of authentication
counter for HAN-end-device
Derive the value of incoming
frame counter to HAN-relay-device
10: PANA-Auth-Request(RESULT-CODE,EAP-PAYLOAD,KEY-ID, SESSION-LIFETIME,AUTH, C-bit)

11: PANA-Auth-Answer(KEY-ID, AUTH, C-bit)
MAC key configuration
Authentication counter
configuration

Incoming frame counter to
HAN-end device configuration

2170
2171

Figure 4.8-34 Authentication and key distribution sequence for HAN-end-device

2172
2173
2174

In the above sequence chart, any message to be exchanged between HEMS and HAN-end-device shall be forwarded via HAN-relay-device.
Wi-SUN Profile for HAN

159 of 206

HAN Working Group

2175
2176
2177
2178
2179
2180
2181
2182
2183
2184
2185
2186
2187
2188
2189
2190
2191
2192
2193
2194
2195
2196
2197
2198
2199
2200
2201

Regarding the procedure from step 1 to step 7, except that all the messages to beexchanged are forwarded by the HAN-relay-device, it shall be identical to usual proceduresof authentication and keys distribution to be done between ordinary HEMS and devices
unsupporting the relay function, but subsequent procedure shall be as follows.
1) Based on the method described in 3.8.5.3.3, HEMS derives outgoing frame countervalue for HAN-end-device from the authentication counter value relevant to HAN-enddevice, stores the derived counter value and HAN-end-device's IPv6 address into FrameCounter Notification AVP, and sends PNR message containing this AVP to HAN-relaydevice (Figure 4.8-34 Step 8). HEMS extracts frame counter value from the FrameCounter Notification AVP received from HAN-relay-device, and sets this value as theincoming frame counter relevant to HAN-relay-device.
2) HAN-relay-device generates Frame Counter Notification AVP that contains own IPv6
address and outgoing frame count, attaches this AVP to PNA message, and then send it
to HEMS (Figure 4.8-34 Step 9). HAN-relay-device extracts frame counter value fromthe Frame Counter Notification AVP received from HEMS, and sets this value as theincoming frame counter relevant to HAN-end-device.
3) Then HEMS sends a PAR message to HAN-end-device (Figure 4.8-34 Step 10). Here,the counter value notified by prior PNA message from HAN-relay-device is copied to the
Frame Counter Out field in the Frame Counter Notification AVP which is attached to thisPAR message. By means of this, HAN-end-device can obtain latest value for incoming
frame counter relevant to HAN-relay-device.
4) In response to this, HAN-end-device responds HEMS by sending PAA message (Figure
4.8-34 Step 11).
5) Then HAN-end-device derives its own outgoing frame counter value according to theauthentication counter value notified by HEMS (see 3.8.5.3.3), and sets it into its own
configuration, together with key information, and incoming frame counter value relevant
to HAN-relay-device that were received from HEMS.

2202
2203
2204
2205
2206

The detail of Frame Counter Notification AVP is specified in “3.9.5.4.3 Vendor-specific
AVP”. PNR message that contains this vendor-specific AVP shall be specified as follows.
Table 4.8-53 Frame Counter Notification (Step10): Message of PNR (Frame Counter,
AUTH)
Field

Sub field

PANA

Reserved

Size(octet) Description
2

Message Message Length2

Wi-SUN Profile for HAN

64
160 of 206

HAN Working Group

Header

PANA
PayloadFlags

2‘R’bit=1、’P’bit=1

Message Type

2

4=PANA-Notification-Request

Session Identifier

4

Sequence
Number4

EncryptionEncap AVP

40

FrameCounterNotification
AVP
AUTH AVP

32

24

Frame Counter NotificationAVP is a Vendor-specific AVP
which is introduced to thisrevision. It shall be
encapsulated with EncryptionEncap-AVP after encrypted.

AVP containing Message
Authentication Code.
Message

2207
2208

3.9.5.3.1.Authentication request by PAA

2209

3.8.5.3.1 shall be supported.

2210
2211

3.9.5.3.2.Authentication response by PaC

2212

3.8.5.3.2 shall be supported.

2213
2214

3.9.5.3.3.Distribution of HAN group key

2215

When PaC is a HAN-relay-device, 3.8.5.3.3 shall be supported.

2216
2218

When PaC is a HAN-end-device, a part of contents in Group Key Distribution AVP differ, but
the other part shall support 3.8.5.3.3. Table 4.8-54 shows content of Group Key Distribution
AVP.

2219

Table 4.8-54 Field values in Group Key Distribution AVP

2217

PaC
Wi-SUN Profile for HAN

161 of 206

HAN Working Group

Fields in Group Key
Distribution AVP

HAN-relay-device

HAN-end-device

Group KeyGroup KeyGroup Key ID

Key Identifier for Group Key

Auth Counter

Authentication Counter

Frame Counter Out

Outgoing Frame Counterof PAA

Incoming Frame Counterfor HAN-relay-device

2220
2221

3.9.5.3.4.Response to HAN group key reception by PaC

2222

When PaC is a HAN-relay-device, 3.8.5.3.4 shall be supported in this section.

2223

When PaC is a HAN-end-device, it differs that Group Key Distribution AVP attached to PAR
message from PAA contains Incoming Frame Counter value for HAN-relay-device insteadof Outgoing Frame Counter value of PAA. Therefore security related information to be set to
MAC layer shall be as follows.

2224
2225
2226
2227
2228

LK ＝ Group Key

2229

Key ID ＝ Key Identifier for the Group Key

2230

Outgoing Frame Counter ＝ Auth Counter || 00 00 00

2231

Incoming Frame Counter for PAA ＝Incoming Frame Counter for HAN-relay-device

2232
2233

3.9.5.4. Key update2234

3.9.5.4.1.Distribution of updated HAN group key by PAA (Push)

2235

3.8.5.4.1 shall be supported. As far as it is assured that frame counter of HEMS and all
devices can be set to zero simultaneously at this moment, extra process does not need tobe added.

2236
2237
2238

Wi-SUN Profile for HAN

162 of 206

HAN Working Group

2239

3.9.5.4.2.Acquisition of HAN group Key by PaC (Pull)

2240

The specification defined in 3.8.5.4.2 shall basically be supported in this section. However,when PaC is a HAN-end-device, a part of contents in HAN Group Key AVP shall bedifferent. See “Table 4.8-54 Field values in Group Key Distribution AVP” about thedetail.

2241
2242
2243
2244
2245

3.9.5.4.3.Vendor-specific AVP

2246

Other than AVPs defined in 3.8.5.4.2, the Frame Counter Notification AVP defined below
shall be used in relay network.

2247
2248
2249
2250
2251
2252
2253
2254
2255
2256
2257
2258
2259
2260
2261
2262
2263
2264
2265
2266
2267
2268
2269
2270
2271
2272
2273
2274
2275
2276
2277
2278
2279

•

Frame-Counter-Notification AVP

When HEMS must notify incoming frame counter value for the HAN-end-device to the HANrelay-device, this AVP shall be attached to PANA Notification Request message. HANrelay-device that received PNR message containing this AVP shall respond the HEMS bysending PNA (AUTH) message.
012
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|AVP Code(3)|AVP Flags(1)|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|AVP Length(4)|Reserved|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|
Vendor-Id (45605)|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|
IPv6 address (1st 4octets)|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|
IPv6 address (2nd 4octets)|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|
IPv6 address (3rd 4octets)|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|
IPv6 address (4th 4octets)|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|
Frame Counter Out|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 4.8-35 shows the Pull sequence. The HEMS shall contain its incoming frame counter value in the
Frame-Counter-Notification (FCN) AVP of the PANA Notification Request message to the HAN-relay-device(step2). HAN-relay-device shall contain its outgoing frame counter value in the Frame-Counter-Notification
AVP of the PANA Notification Answer message to the HEMS (step3). The HEMS shall contain the outgoingframe counter value of the HAN-relay-device in the HAN-Group-Key AVP to the HAN-end-device (step4).
Wi-SUN Profile for HAN

163 of 206

HAN Working GroupHEMS as PAA

Relay Device

End Device as PaC

1: PANA-Notification-Request (ENC-ENCAP[HAN-Group-Key-Request AVP], AUTH, P-bit)
2: PANA-Notification-Request(FCN AVP, AUTH, P-bit)
3: PANA-Notification-Answer(FCN AVP, AUTH, P-bit)

4: PANA-Notification-Answer (ENC-ENCAP[HAN-Group-Key AVP], AUTH, P-bit)

2280

Figure 4.8-35 Pull Sequence

2281
2282
2283
2284
2285
2286

The Frame Counter Out field shall set a value of outgoing counter, and the IPv6 address
field shall indicate owner of the outgoing counter value to be stored in the Frame Counter
Out field. This vendor specific AVP shall be sent with encryption by using Encryption Encap
AVP, and shall be decrypted on the recipient.

2287
2288

3.9.5.4.4.HAN group key Management2289

3.8.5.4.4 shall be supported, additionally assuming that the frame counters for the HANend-devices can be relayed to the HEMS by the HAN-relay-device when PAA-PaC session
is supported by relay on MAC layer, as in 3.9.5.3.

2290
2291
2292
2293

3.9.5.4.5.Authentication counter (AuthCounter) management2294

3.8.5.4.5 shall be supported.

2295
2296

3.9.5.4.6.HAN group key generation

2297

3.8.5.4.6 shall be supported.

2298
2299

3.9.5.4.7.Encryption/decryption key generation for vendor-specific AVP

2300

3.8.5.4.7 shall be supported.
Wi-SUN Profile for HAN

164 of 206

HAN Working Group

2301
2302

3.9.5.4.8.Network reconfiguration notification

2303

The specification defined in 3.8.5.4.8 shall basically be supported in this section. Regarding
the relation between HAN-relay-device and HAN-end-device, 3.8.5.4.8 shall be supported
as well. For example, while HAN-relay-device as PaC is under ongoing Enhanced Active
Scan against PAA, the HAN-relay-device may ignore another Enhanced Active Scan from
HAN-end-device on the other side until it as PaC receives the response from the PAA.

2304
2305
2306
2307
2308
2309

3.9.5.5. Encryption and Integrity check2310

3.8.5.5 shall be supported.

2311
2312

3.9.5.6. Replay protection

2313

3.8.5.6 shall be supported.

2314

2315

3.9.6. Recommended network configurations

2316

Follow the 3.8.6.

2317
2318

3.9.6.1. Bootstrapping

2319

Follow the 3.8.6.1 on all devices including a HAN-relay-device and a HAN-end-device.

2320
2321

3.9.6.1.1.Data link layer configuration

2322

The HEMS shall include Pairing ID and Capability Notification IE when it returns an
Enhanced Beacon.

2323

2326

A HAN-relay-device shall include a SRA IE as well as a Pairing ID as MLME IEs when it
returns an Enhanced Beacon. A device which associates with the HAN-relay-device stores
the SRA IE information as a route to the HEMS.

2327

MAC association procedure should be omitted.

2328

Data link configuration except above terms follows the 3.8.6.1.1.

2324
2325

Wi-SUN Profile for HAN

165 of 206

HAN Working Group

2329
2330

3.9.6.1.2.Network layer configuration

2331

2335

The HEMS, a HAN-relay-device and a HAN-end-device use IPv6 link local address only.
Network layer configuration follows the 3.8.6.1.2. with the exception that if a HAN-enddevice which needs a HAN-relay-device to relay frames to the HEMS (PAN coordinator)
performs IPv6 ND before PANA session, a HAN-end-device should send a frame prior to
IPv6 ND to allow HEMS to send a unicast frame to the device as follows.

2336

-

2332
2333
2334

A MAC frame with the SLR IE
Source Address in MHR

The HAN-end-device

Destination Address in MHRHEMS (PAN coordinator)

Intermediate Address in SLR IE

Necessary the HAN-relay-device(s)MAC payload

6LoWPAN dispatch with NALP (0x00 in the fistbyte)**: NALP is defined in [6LOWPAN].

2337
2338
2339

Authentication procedure is described in the 3.8.6.3.

2340
2341

3.9.6.2. IP Address Detection

2342

Follow the 3.8.6.2, except that the IP address should be obtained from its SRA-IE not fromits MAC header when an EB with SRA IE is included in the received frame.

2343
2344
2345

3.9.6.3. Authentication, Key Exchange, Route information notification to the HEMS

2346

The device performs security setup after data link layer and network layer configurations. In
other words, the device acting as a PaC initiates a PANA session to the HEMS acting as the
PAA.

2347
2348
2349
2350
2351
2352
2353
2354
2355

A device which doesn’t communicates with the HEMS directly but communicates with a
HAN-relay-device shall set a SLR IE in a frame when it transmits a PCI message. The routeinformation from the device to the HEMS shall be stored in the SLR IE.
When the HEMS sends a PANA message to a device which doesn’t associated with the
HEMS directly, the HEMS shall set aSLR IE in the frame as route information from theHEMS to the device. TheSLR IE is generated from the route information stored in theSLR IE
in the PCI message from the device.
Wi-SUN Profile for HAN

166 of 206

HAN Working Group

2356
2357
2358
2359
2360
2361

A device which relays a message between the HEMS and the joining device refers to the
SLR IE in the received frame and forwards the frame with replacing the MAC destination
address to the next hop address and the MAC source address to its address. IEs and PANA
message fields shall not be changed.
A PANA message exchanged between the HEMS and a device which associates with the
HEMS directly shall not include a SLR IE.

2362
2363

3.9.6.4. Application

2364

Follow the 3.8.6.4.

2365

2366

3.9.7. Usage of credential

2367

Use the HAN authentication ID and Password described in the 3.8.7.

2368
2369

3.9.7.1. Conversion of HAN authentication ID to EAP Identifiers

2370

NAI is generated according to the3.8.7.1.

2371
2372

3.9.7.2. Conversion of Password to PSK

2373

PSK is generated according to the 3.8.7.2.

2374
2375

3.9.8. Discovery and selection of the HEMS network

2376

A HAN device performs Enhanced Active Scan using IEs field to detect the HEMS or a
HAN-relay-device. MLME IE (Group ID=0x1) will be used for the Payload IEs field of theEnhanced Beacon Request sent by the HAN device. The eight octets (Pairing ID) defined inboth initial mode and normal mode will be included in the IE Contents of Sub-ID=0x68(Unmanaged) and also the appropriate sender’s capability set according to 3.8.3.1 will be
included in the IE Contents of Sub-ID=0x67 (Unmanaged) (Capability Notification IE). Whenthe Pairing ID stored in MLME IE of the Payload IEs matches the Pairing ID stored in the
HEMS or a HAN-relay-device, the HEMS or the HAN-relay-device responds by returning theEnhanced Beacon. This Enhanced Beacon is unicast and also includes the same Pairing ID
and Capability Notification IE which is set according to 3.8.3.1 in the Payload IEs field. Afterconfirmation that the HEMS or the HAN-relay-device has the same Pairing ID and the

2377
2378
2379
2380
2381
2382
2383
2384
2385
2386

Wi-SUN Profile for HAN

167 of 206

HAN Working Group

2387
2388

appropriate capability, the HAN device will start PANA negotiation with the HEMS or the
HAN-relay-device.

2389
2390

< Initial setup mode >2391

The HEMS or a HAN-relay-device is set to initial setup mode in advance before a new HAN
device tries to connect to the HEMS or the HAN-relay-device. The HAN device uses anenhanced active scan feature and detects the target HEMS or the target HAN-relay-device.
The HEMS or the HAN-relay-device initial mode has a valid period and its suggested value
is five minutes. During the time, Pairing ID is set to the fixed strings “HAN_INIT”. The HAN
device starts PANA authentication process with the corresponding the HEMS or the HANrelay-device after enhanced active scanning by Pairing ID. After the valid period expires, theHEMS or the HAN-relay-device invalidates the Pairing ID “HAN_INIT” for initial mode andturns into normal mode. When authentication succeeds, the HAN device set the HEMS’s or
the HAN-relay-device’s MAC address for Pairing ID. If authentication fails, HAN device tries
to find the corresponding HEMS or HAN-relay-device until PANA authentication succeeds.
The HAN device can use an enhanced active scan again to the all channels if it finds no
HEMS or HAN-relay-device on all channels or authentication fails.

2392
2393
2394
2395
2396
2397
2398
2399
2400
2401
2402
2403
2404
2405

< Normal operation mode >2406

The HEMS or a HAN-relay-device set its MAC address for Pairing ID in normal operation
mode to be ready for scanning from a device by enhanced active scan. HAN-relay-device
would have two Pairing IDs, one is its parent device MAC address and the other is its own
MAC address.

2407
2408
2409
2410
2411
2412
2413
2414
2415
2416
2417
2418
2419
2420
2421

Once a HAN device connects to the HEMS or a HAN-relay-device, HAN device should
calculate the IPv6 link local addresses of the HEMS and the HAN-relay-device from the
MAC source address or theSRA IE of Enhanced Beacon message. And HAN device
requests the HEMS to authenticate by [PANA] using NAI and authentication key, which are
pre-shared. The HEMS establishes PANA session with the HAN device, and the HEMS
authenticates HAN device based on NAI and authentication key. The HEMS delivers HANGroup-Key for which the HEMS and the HAN device share the MAC layer encryption key
after successful authentication. Furthermore, a device which connected to a HAN-relaydevice obtains a MAC security transmit frame counter of the HAN-relay-device according to
the 3.9.5.3 and set the counter value to the Frame Counter of the associated Device
Descriptor of the MAC layer.

2422

Wi-SUN Profile for HAN

168 of 206

HAN Working Group

2423
2424
2425
2426
2427

After sharing the MAC layer encryption key, the HEMS can communicate with the HAN
device, by using encrypted messages. The HEMS conducts service discovery procedureand sends some commands to the HAN device using ECHONET Lite protocol, and the HAN
device can do some operations based on the requests and respond execution results to the
HEMS.

2428

2429

3.9.9. Route Information

2430

Following the procedure described in the 3.9.6.3, a HAN-relay-device notifies a HAN deviceof route information to the HEMS by using a SRA IE in an Enhanced Beacon and the device
stores the route information. The HAN device sets the route information to theSLR IE when
it sends a unicast frame to the HEMS, including the period of PANA authentication. If thenumber of intermediate records exceeds supported number, a device shall ignore anddiscard the frame.

2431
2432
2433
2434
2435
2436
2437
2438
2439
2440
2441
2442
2443
2444
2445
2446
2447

The HEMS obtains route information to the HAN device by referring the SLR IE in thereceived frames during PANA authentication and stores the route information. During PANA
authentication or later, the HEMS sets the route information to the SLR IE when it sends aunicast frame to the HAN device. In case PANA authentication fails, the HEMS discards theroute information. If the number of records of intermediate node exceeds supported number,a device shall ignore and discard the frame.
After PANA authentication, the HEMS and the HAN device shall not update the routeinformation which they have stored during PANA authentication. In case route change
becomes necessary, when such like replacing the HAN-relay-device, scanning and PANA
authentication shall be carried out again. In that case, the HEMS needs to keep the newroute information to the same device temporarily during PANA authentication, and only if the
PANA authentication succeeds, the old route information is replaced with the new one.

2448

2449

3.9.10. Unicast Transmission

2450

The HEMS and a HAN device shall directly transmit a frame without SLR IE if HAN-relaydevice is not used to send the frame to a final destination. The HEMS and a HAN device
shall transmit a frame withSLR IE if HAN-relay-device(s) is used to send the frame to a finaldestination.

2451
2452
2453
2454
2455
2456
2457
2458

When a HAN-relay-device receives a frame which has SLR IE, it forwards the frame after
putting its own MAC address to the source MAC address field and the next hop address tothe destination MAC address field. The next hop address is determined by referring the SLR
IE in the received frame. A HAN-relay-device shall not change IEs and frame payload in theframe.
Wi-SUN Profile for HAN

169 of 206

HAN Working Group

2459
2460
2461

Note that when an encrypted MAC frame is received, a HAN-relay-device decrypts theframe first, and then changes the MAC header address fields, encrypts the updated frame
and forwards the encrypted frame to the next hop.

2462

2463

3.9.11. Multicast Transmission

2464

When a device wants to transmit a frame to a multicast group, the frame is treated as abroadcast frame by the MAC sublayer and is filtered by the recipients at the next higher
layer.

2465
2466
2467
2468

3.9.11.1. Transmission by the HEMS

2469

When the HEMS wants to transmit a multicast frame, it shall transmit the frame twice. The
first frame is transmitted without the SLR IE in order to allow reception by devices that do
not support relay. The second frame is transmitted with the SLR IE in order to allow HANrelay devices to forward the multicast frame.

2470
2471
2472
2473
2474
2475
2476

If the network solely comprises devices of the same type, i.e. supporting or not supporting
relay, the HEMS transmits the multicast frame only once with or without the SLR IE
respectively. The determination of whether devices of the same type are deployed in the
network is out of the sscope of this profile.

2477
2478

3.9.11.2. Transmission by HAN-relay and HAN-end devices

2479

When a HAN-relay or HAN-end device supporting relay wants to transmit a multicast frame,
the SLR IE is inserted in the frame.

2480
2481
2482
2483
2484
2485
2486
2487
2488

If a HAN-end device that does not support relay wants to transmit a multicast frame, theframe shall be sent without an SLR IE.
When the HEMS, a HAN-relay, or a HAN-end device supporting relay transmits a multicast
frame with the SLR IE, the Source Address field is set to the address of the originator andthe Destination Address field is set to the broadcast address. The Number of Intermediate
Addresses field is set to 0 and the Intermediate Address List field is omitted.The Source
Address and the Destination Address fields of the MHR are also set to the originator’s
address and the broadcast address respectively.

2489

Wi-SUN Profile for HAN

170 of 206

HAN Working Group

2490

3.9.11.3. Multicast frame reception

2491

When device receives a multicast frame:

2492
2493

・ If it is a HAN-end-device or the HEMS, it removes the MHR and the SLR IE and delivers the frame to
the next higher layer.

2494
2495

・ If it is a HAN-relay-device, it leaves the SLR IE intact and sets the source address of the MHR to its
own address. The frame is then forwarded.

2496

The source device and any device receiving the frame records the Sequence Number andthe Original source address found in the SLR IE. If a frame with the same Sequence
Number and Original source address is received, the frame is dropped in order to avoid
duplicate forwarding.

2497
2498
2499
2500
2501

An appropriate jitter is applied to each multicast frame transmission in order to reduce thenumber of possible collisions.

2503

3.10. Recommended usage for home area network among devices
with an extension of sleeping end device support

2504

3.10.1. Overview

2505This clause clarifies the recommended extension to the usage in constructing network for
ECHONET Lite over IPv6 communication between a HEMS and multiple devices describedin 3.8. A HEMS with the sleeping end device (e.g. a battery operated device like a gas
meter) support extension described in this clause shall communicate with a device
described in 3.8 in same manner described in 3.8. Compliant nodes to this clause
constructs a network with the HEMS as a central coordinator as shown in Figure 4.8-36. A
HAN consists of HEMS (PAN coordinator) and devices or/and sleeping end devices. In therelay supported HAN specified in 3.9, not all coordinator shall support sleeping end device
but a coordinator which needs to connect to sleeping end device directly shall support thisfunctionality. For example, if a PAN coordinator supports sleeping end device and relay
devices don’t support it, a sleeping end device only connect to the PAN coordinator. If a
PAN coordinator doesn’t support and one of relay devices support this extension, a sleeping
end device is able to connect only to the relay device which supports the extension as
example illustrated in Figure 4.8-37.

2502

2506
2507
2508
2509
2510
2511
2512
2513
2514
2515
2516
2517
2518

Wi-SUN Profile for HAN

171 of 206

HAN Working Group

DeviceHEMS(PAN Coordinator withsleep end device support)

DeviceSleeping Device

2519
2520

Figure 4.8-36 Home network with sleeping end device support for multiple devices

2521

Note that this recommended usage does not exclude any extensions such as relay function.

HEMS(PAN coordinator)

HAN-end/relay-device(Device/Coordinator)

HAN-relay-device(Coordinator) withsleep end device
extension
Sleep HAN-end device

2522
2523
2524

Figure 4.8-37 An example home area network with an relay device which supports
sleeping end device

2525
2526

3.10.2. PHY part2527

See 3.8.2 in this document.

2528

Wi-SUN Profile for HAN

172 of 206

HAN Working Group

2529

3.10.3. MAC part

2530

This clause shows amendments for HAN supporting a sleeping end device in MAC layer.
What is specified here supersedes 3.8 and 3.9 but other specifications should follow3.8.3
and 3.9.3 respectively.

2531
2532
2533
2534

3.10.3.1. MAC sub-layer function

2535

Table 4.8-55 shows amendments in MAC sub-layer functions.

2536

Wi-SUN Profile for HAN

173 of 206

HAN Working Group

Table 4.8-55 Amendments in MAC sub-layer functions

2537

Item
numberItem description

MLF25

Sleeping End Device support in
HAN

MLF25.1

Status inReferencestandard
section instandard (M:Mandatory,
O:Option)(Y:Yes,
N:No,
O:Option)

New in this
usage

O

Transmission of Capability
Notification IE in EBR andreception of Capability Notification
IE in EB

New in thisusage

MLF25,
FD2:Y

MLF25.2

Transmission of Capability
Notification IE in EB and receptionof Capability Notification IE in EBR

New in thisusage

MLF25,
FD1:Y

MLF25.3

Multicast Transaction Handling for
the Indirect Transmission

New in thisusage

MLF25,
FD1: YMLF 1.1

Purge data[802.15.4]
6.3.4,
6.3.5

FD1:M

MLF25,
FD1:Y[802.15.4]
5.1.5

FD1:M

MLF13

Store one transaction

3.10 inthisdocument

Support

FD2:O

FD2:N
MLF25,
FD1:Y
FD2:N

MF4.4

Data request[802.15.4]
5.2.2.4,
5.3.4

Transmitter: M Transmitter:
MLF25,
Receiver:
FD2:Y
FD1:M
Receiver:MLF25,
FD1:Y

2538

Wi-SUN Profile for HAN

174 of 206

HAN Working Group2539

3.10.3.1.1. Coordinator requirement for the handling indirect transmission

2540

This clause describes what the coordinator which supports sleeping end device connectivity
needs to suffice.

2541
2542
2543

The coordinator needs to support capability exchange specified in 3.10.8.

2544

The coordinator supporting sleeping end device shall support indirect transmission, which isenabled by supporting “Purge data” functionality, a frame buffer for “Store one transaction”
and handling “Data request” format. Acknowledgment frame specified in 3.6.3.2.2 shallsupport “pending bit” to inform existence of a stored frame in the buffer to sleeping end
device when it asked by “Data request” command frame.

2545
2546
2547
2548

2550

When the next higher layer of MAC layer in the coordinator sends a frame, it needs to
invoke MCPS-DATA.request as follows.

2551

-

If the sending frame is unicast frame to a sleeping end device, MCPS-DATA.request
with indicating “indirectTX” as TRUE shall be invoked.

-

If the sending frame is unicast frame to other than sleeping end devices, MCPSDATA.request by indicating “indirectTX” as FALSE shall be invoked as usual.

-If the sending frame is broadcast frame and the coordinator has a sleeping end device
as a neighbor by exchanging capability as described in 3.10.8, MCPS-DATA.request
with “DstAddr” set as “0xffff” and with “indirectTX” set as “FALSE” shall be invoked andthen MCPS-DATA.request shall be invoked per sleeping end devices by setting each
MAC address with “indirectTX set as “TRUE”.

-

If the sending frame is broadcast frame but the coordinator has no sleeping end device
as a neighbor, MCPS-DATA.request shall be invoked by setting “DstAddr” as “0xffff”
and setting “indirectTX” as “FALSE”

2549

2552
2553
2554
2555
2556
2557
2558
2559
2560
2561
2562
2563
2564
2565
2566
2567
2568
2569
2570
2571
2572
2573

When a frame is buffered and a sleeping end device queried by “Data request” command
frame, the coordinator send an acknowledgment frame with pending bit =TRUE. If there isno buffered frame for the sleeping end device, acknowledgment frame with pending bit=FALSE will be returned.
In this profile specification, it is required that a coordinator including HEMS and relay device
should have 8 indirect transmission buffers (8 x 255B) at least to assure to send fragmented
IP packet (MTU = 1280 bytes).
In this profile specification, macTransactionPersistenceTime in MAC PIB should be
configured as ‘0x3d09’ to extend timeout for indirect transmission to incorpolate a longsleep application device like a gas meter. The value ‘0x3d09’ corresponds to ‘5 minutes’ innon beacon enabled mode with the PHY specified in 3.7.2.This profile specification doesn’t
Wi-SUN Profile for HAN

175 of 206

HAN Working Group

2574
2575

avoid to use bigger value for this PIB if the implementer requires longer sleep application
device.

2576
2577

3.10.3.1.1.1. Purging operation

2578
2579

The next higher layer of MAC layer in a coordinator is recommended to invoke MCPSPURGE.reuqest primitive in the situations described as following example

2580
2581

-

When a data request command frame doesn’t come from the sleeping end device for fairamount of time

2582
2583

3.10.3.1.2. Sleeping end device requirement for the handling indirect transmission

2589

The sleeping end device shall support transmission of “Data request” command frame toretrieve a buffered frame from the coordinator. When a sleeping end device needs to send aframe, it is done as well as other non-sleeping end device. When a sleeping end device
wakes up and needs to check any frame is buffered during the sleep, it send a “Datarequest” command frame to the coordinator with which capability exchange is done during
network joining.

2590

The Data request command frame shall not be encrypted in this profile.

2584
2585
2586
2587
2588

2591
2592
2593
2594

If acknowledgment frame with pending bit =TRUE is returned, the sleeping end device shallwait a frame from the coordinator for enough time to receive. (c.f.
macMAXFrameTotalWaitTime is specified in [802.15.4].)

2595
2596
2597

3.10.3.2. MAC frame format

2598

This clause shows the amendments in MAC frame format. If the HAN support relay
functionality, it shall follow 3.9.3.2 as well.

2599
2600
2601

3.10.3.2.1. Capability Notification IE

2602

Capability Notify IE is a payload IE that is attached to Enhanced Beacon Request command
frame or Enhanced Beacon frame to inform to corresponding node regarding what
capabilities the sender has. A flags below is defined to be used to inform weather the device

2603
2604

Wi-SUN Profile for HAN

176 of 206

HAN Working Group

2605
2606

supports sleeping end device extension. If the relay function is supported, flags for relaying
support should be carried in same frame.

2607
2608
2609
2610
2611
2612
2613
2614

- Sleeping-support (bit 5) – if this flag is set, it indicates that the sender support sleeping
extension. If the IE is carried by EBR, that indicates whether the sender device is sleeping
end device. If the IE carried by EB, that indicates whether the sender supports indirecttransmission to communicate with a sleeping end device. If a coordinator doesn’t support
sleeping end device extension or it doesn’t have enough buffers for indirect transmission, it
should not reply EB in response of EBR or should reply EB without this IE or with this IE
setting this flag as zero.

2615
2616

3.10.3.2.2. Acknowledgement frame

2617

The acknowledgment frame for this recommendation shall support pending bit fortransmission in a coordinator and for reception in sleeping end device to support indirecttransmission.

2618
2619
2620
2621

3.10.4. Interface part2622

3.10.4.1. Overview

2623

The interface of a single-hop home network among devices for ECHONET Lite over IPv6
shall be compliant with clause 3.7.4 unless otherwise specified in the following sub clauses.

2624
2625
2626

3.10.4.2. Adaptation layer

2627

It shall follow 3.8.4.2 in this document except other than the following limitation. The
6LoWPAN fragmentation should not be performed with more than 8 fragments since thisprofile just requires a coordinator to have 8 indirect transmission buffers at least (see3.10.3.1.1).

2628
2629
2630
2631
2632

3.10.4.3. Network layer

2633

See 3.8.4.3 in this document.

2634

Wi-SUN Profile for HAN

177 of 206

HAN Working Group

2635

3.10.4.3.1. IP addressing

2636

See 3.8.4.3.1 in this document.

2637
2638

3.10.4.3.2. Neighbor discovery

2639

See 3.8.4.3.2 in this document.

2640
2641

3.10.4.3.3. Multicast

2642

See 3.8.4.3.3 in this document for the basic operation. When the network layer needs tosend IP Multicast (e.g. The destination address is FF02::1.) in a coordinator (PAN
coordinator or relay device), it needs to invoke MCPS-DATA.request primitive of MAC layer
for the regular devices and for each sleeping end device with indirect transmission
respectively. A coordinator is informed whether a neighbor device is sleeping end device or
not during bootstrap sequence. A data frame for the regular devices shall be with IP header
which destination is multicast address and with MAC header which destination is broadcast
address (0xffff) and a data frame for each sleeping end device shall be with IP header which
destination is multicast address and with MAC header which destination is the end device
address and shall be sent by unicast indirect transmission.

2643
2644
2645
2646
2647
2648
2649
2650
2651
2652
2653
2654
2655
2656
2657
2658
2659
2660
2661

For example, a PAN coordinator invokes MCPS-DATA.request with MAC destination
address as 0xffff to send an IP multicast packet. After that, it invokes MCPS-DATA.request
with a MAC address for each sleeping end device to send the same IP packet. It will bedone twice if a PAN coordinator has 2 sleeping end devicesregistered. A data frame which
is sent by indirect transmission is stored into a frame buffer once and it is actually sent when
Data request command is sent to the coordinator from an end device.
When a relay device performs unicast indirect transmission to send multicast packet withSLR IE, it shall replace destination address, ‘0xffff’ in SLR IE with EUI-64 address of asleeping end device as well as it replaces MAC destination address ‘0xffff’ with sleeping end
device’s EUI-64.

2662
2663

3.10.4.4. Transport layer

2664

See 3.8.4.4 in this document.

2665

Wi-SUN Profile for HAN

178 of 206

HAN Working Group

2666

3.10.4.5. Application layer

2667

See 3.8.4.5 in this document.

2668

2669

3.10.5. Security configuration

2670

See 3.8.5, or see 3.9.5 if the HAN supports relay. All the transactions use indirecttransmission for the communication from a coordinator to a sleeping end device. A data
request from a sleeping end device to a coordinator is recommended to be done frequently
so that time out may not happen during boot strap sequence. A PNR (PANA Notification
Request) message with a REQ-Timeout-Modification-Request AVP (vendor specific AVP) isused to extend PANA time out in the HEMS to avoid a sleeping device to be deleted due to
PANA session time out. In the response to PNR, the HEMS shall reply with the PNA withrequested REQ-Timeout-Modification-Request AVP to the originator of PNR (the joining
sleeping device). If the requested values are not valid or unacceptable, the HEMS shallreturn the default value (REQ_IRT = 3, REQ_MRT = 30) or acceptable value to theoriginator of the PNR. Since a broadcast frame for MLE update may be lost, an
implementation for the sleeping end device is recommended to detect key update from adata frame. An implementation of sleeping end device may have no process to receive anddeal MLE update if it can detect key update from a data frame.This procedure isrecommended to be limited only for initial sequence immediately after PANA sequence ofthe bootstrapping before a device sends a data frame to make the management simple in
the HEMS.

2671
2672
2673
2674
2675
2676
2677
2678
2679
2680
2681
2682
2683
2684
2685
2686

2690

When the HEMS handles key distribution in the network with sleeping end devices, it may
take much time to finish all of key distributions. That may cause an issue that the HEMS
takes much more time to update key. To reduce it, the HEMS may handle multiple PANA
transactions for PaCs at same time.

2691

The definition of the REQ-Timeout-Modification-Requet AVP is as follows.

2692

-

2687
2688
2689

REQ-Timeout-Modification-Requet

AVP

OctetsFieldsRemark2

AVP code

4

2

AVP flags

1, meaning V bit, indicates Vendor-ID field
is present

2

AVP length

AVP value length is 4

2

Reserved

As a rule set to 0, but don’t care

4

Vendor-ID

45605
Wi-SUN Profile for HAN

179 of 206

HAN Working Group

2693
2694

2

REQ_IRT

Requested REQ_IRT in seconds. It shallbe in the range 3 - 600.

2

REQ_MRT

Requested REQ_MRT in seconds, shallbe more than or equal to REQ_IRT and it
shall be in the range 3 - 600

Table 4.8-56 REQ Timeout Modification Request : Message of PNR (ENC-ENCAP[REQ-Timeout-Modification-Request], AUTH, P-bit)
Field

Sub field

Size(octet)

PANA

Reserved

2

Description

Message Message Length264

HeaderFlags

2‘R’bit=1、’P’bit=1

Message Type

2

4=PANA-Notification-Request

Session Identifier

4

Sequence
Number4

EncryptionEncap AVP

24

PANA
Payload

REQ-TimeoutModificationRequest AVP

REQ-Timeout-Modification-Request AVP is avendor specific AVP containing RQT_IRT,
RQT_MRT which is defined in thisdocument. It is encrypted and encapsulated
in Encryption-Encap AVP.
16

AUTH AVP

24

contains Message Authentication Code

2695

Table 4.8-57 REQ Timeout Modification Request : Message of PNA (ENCENCAP[REQ-Timeout-Modification-Request],AUTH, P-bit)

2696
2697

Field

Sub field

Size(octet) Description

PANA

Reserved

2

Message Message Length

264

Wi-SUN Profile for HAN

180 of 206

HAN Working Group

Header

PANA
Payload

Flags

2

’P’=1

Message Type2

4= PANA-Notification-Answer

Session Identifier

4

Sequence
Number4

Encryption-Encap
AVP

60

REQ-TimeoutModificationRequest AVP
AUTH AVP

52

24

REQ-Timeout-Modification-Request AVP is avender-specific AVP containing RQT_IRT,
RQT_MRT, which is added in thisspecification. It is encrypted and thenencapsulated in Encryption-Encap AVP.
contains Message Authentication Code2698

3.10.6. Recommended network configurations

2699

3.10.6.1. Bootstrapping

2700

3.10.6.1.1. Data link layer configuration

2701

See 3.8.6.1.1, or see 3.9.6.1.1 if the HAN supports relay functionality for other than the
exception as follows.

2702
2703
2704
2705
2706
2707
2708
2709
2710
2711
2712
2713
2714
2715
2716
2717
2718

When the sleeping end device invokes an active scan in order to detect a HEMS (PAN
coordinator), it shall emit EBR including Capability Notification IE as well as MLME IE which
sub ID is the Pairing IE. Coordinator which supports sleeping end device shall response EB
including Capability Notification IE as well as MLME IE which sub ID is the Pairing IE as
described in 3.10.3.2.1. When a non-sleeping end device described in 3.8 and 3.9 emits
EBR without Capability Notification IE or emits EBR with Capability Notification IE but
sleeping-support flag set as false ,a coordinator shall response EB as described in 3.8 and3.9 respectively. If a transactions of EBR and EB with Capability Notification IE withsleeping-support flag between a coordinator and a sleeping end device, the sleeping end
device is registered in the coordinator as a device to use indirect transmission tocommunicate. A coordinator in this profile shall have capability to register one sleeping end
device at least. If a coordinator receive an EBR from another sleeping end device when
there is no more capability to register a sleep end device, the coordinator response EB withdisabled sleeping-support flag. If a coordinator which registered a sleep end device doesn’t
receive any frame during 3 times of macTransacionPersitenceTime, it can remove theregistration.

2719

Wi-SUN Profile for HAN

181 of 206

HAN Working Group2720

3.10.6.1.2. Network layer configuration

2721

See 3.8.6.1.2 or see 3.9.6.1.2 if the HAN supports relay functionality.

2722
2723

3.10.6.2. IP Address Detection

2724

Follows 3.8.6.2 or follow 3.9.6.2 if the HAN supports relay functionality.

2725
2726

3.10.6.3. Authentication and Key Exchange

2727

Follows 3.8.6.3 or follow 3.9.6.3 if the HAN supports relay functionality.

2728
2729

3.10.6.4. Application

2730

Follows 3.8.6.4 or follow 3.9.6.4 if the HAN supports relay functionality.

2731

2732

3.10.7. Usage of credential

2733

Follows 3.8.7 or follow 3.9.7 if the HAN supports relay functionality.

2734
2735

3.10.8. Discovery and selection of the HEMS network

2736

See 3.8.8 or see 3.9.8 for HAN with relay support with exceptions of using Capability
Notification IE as described in 3.10.3.2.1 and of using indirect transmission for thecommunication from coordinator to sleeping end device as described in 3.10.3.1 and3.10.3.2. An example sequence is illustrated in Figure 4.8-38.

2737
2738
2739

Wi-SUN Profile for HAN

182 of 206

HAN Working Group

HEMS

HAN
sleeping
end device

MAC layer
In HEMSEnhanced Beacon Request with MLME IE(Paring ID) and Capability Notification IE(Ｓｌｅｅｐ = On )Enhanced Beacon with MLME IE (Paring ID)
and Capability Notification IE (Sleep = On)

PCI

Start Periodical
Transmission of Data
RequestPAR (Buffered)
Data Request

Sleep

Ack with Pending bit = On
PAR (PRF/ENC/INIT-ARGO, S-bit)
PAA
PAR (Buffered)
Data Request

PANA Sequence
Sleep

Ack with Pending bit = On
PAR (in Air)

Data Request

Sleep

Ack with Pending bit = On
PAR (RESULT T-CODE, EAP PAYLOAD, …)
PAA (KEY-ID, Auth, C-bit)

2740
2741

Figure 4.8-38 An example sequence for network discovery

2742

Wi-SUN Profile for HAN

183 of 206

HAN Working Group2743

3.11. Recommended usage for Route-IoT network2744

3.11.1. Overview

2745This clause clarifies the recommended usage in constructing network between a smart
meter and IoT devices (Route-IoT). The “IoT device” is a generic expression for a terminal
which is attached to a gas meter, water meter, and so on to communicate with a (electricity)
smart meter. Compliant nodes to this clause construct a network with the smart meter as acentral coordinator as shown in Figure 4.8-39. This network consists of one smart meterand one or more IoT devices that act as end devices or sleeping end devices or relay
devices. All coordinators described in this clause shall support sleeping end device. In thisnetwork, non ECHONET Lite application can be adopted as an upper layer application.

2746
2747
2748
2749
2750
2751
2752
2753

End device

Smart meter(PAN Coordinator withsleep end device support)

Sleeping end device

Relay device(Coordinator)
with sleeping end
device extension
Sleeping end device

2754
2755

Figure 4.8-39 Route-IoT network for multiple devices

2756
2757

Wi-SUN Profile for HAN

184 of 206

HAN Working Group

2758

3.11.2. PHY part2759

See 3.8.2 in this document.

2760

3.11.3. MAC part

2761
2763

This clause shows additional specifications for Route-IoT in MAC layer. What is specified
here supersedes 3.8, 3.9, and 3.10 but other specifications should follow 3.8.3, 3.9.3, and3.10.3 respectively.

2764

3.11.3.1. Capability Notification IE (CN IE)

2765

Figure 4.8-40 shows the structure of modified CN IE.

2766

In this CN IE, the "Application specific" field (bit 1-4) is introduced in this recommended
usage. The bit 1 is a flag to use this field. If this flag is set, it indicates that sender set theapplication specific content (bit 2-4). This content is opaque at the MAC level and used byupper layers. If this flag is not set (0), the content (bit 2-4) shall be set to 0.

2762

2767
2768
2769
2770

Bits: 0-7

8-14

15

Octets: Variable

LengthSub-ID(0x67)

Type(Short format)

IE content

Bits: 0

1

2-4

5

6

7

Reserved(0)

flag

content

Sleepingsupport

Relay-endpoint

Relay-intermediate

Application specific

HAN relay function

2771
2772
2773

Figure 4.8-40 Capability Notification IE with Application specific field

2774

Wi-SUN Profile for HAN

185 of 206

HAN Working Group2775

3.11.4. Interface part2776

3.11.4.1. Overview

2777

The interface of Route-IoT network shall be compliant with clause 3.10.4 unless otherwise
specified in the following sub clauses.

2778
2779
2780

3.11.4.2. Adaptation layer

2781

See 3.10.4.2 in this document.

2782
2783

3.11.4.3. Network layer

2784

See 3.8.4.3 in this document.

2785
2786

3.11.4.3.1. IP addressing

2787

See 3.8.4.3.1 in this document.

2788
2789

3.11.4.3.2. Neighbor discovery

2790

See 3.8.4.3.2 in this document.

2791
2792

3.11.4.3.3. Multicast

2793

See 3.8.4.3.3 in this document.

2794
2795

3.11.4.4. Transport layer

2796

See 3.8.4.4 in this document.

2797
2798

3.11.4.5. Application layer

2799

See 3.8.4.5 in this document.
Wi-SUN Profile for HAN

186 of 206

HAN Working Group

2800

2801

3.11.5. Security configuration2802

See 3.10.5 and 3.8.5, or see 3.9.5 if the network supports relay.

2803
2804
2805
2806
2807
2808

3.11.6. Recommended network configurations
The smart meter(s) and IoT device(s) share a “Pairing ID” with 8-octet length, and this ID isused in the network discovery. The IoT device selects a suitable smart meter for the IoT
device to connect to from one or more smart meter candidates in the network discovery.
The Pairing ID, NAI and pre-shared key for PANA/EAP are set to each node in advance.

2809
2810

Note:

2811

The Pairing ID may be shared by several smart meters and IoT devices, or it may be uniquefor each smart meter and IoT device pair. The Pairing-ID is given in advance, which is
assigned by someone (e.g., power company) via offline.

2812
2813
2814
2815

See 3.8.6 in this document for radio channel and PAN ID settings.

2816
2817

3.11.6.1. Bootstrapping

2818

3.11.6.1.1. Data link layer configuration

2819

See 3.10.6.1.1 in this document.

2820
2821

3.11.6.1.2. Network layer configuration

2822

See 3.8.6.1.2 or see 3.9.6.1.2 if the network supports relay functionality.

2823
2824

IP Address Detection

2825

Follows 3.8.6.2 or follow 3.9.6.2 if the network supports relay functionality.

2826
Wi-SUN Profile for HAN

187 of 206

HAN Working Group2827

3.11.6.1.3. Authentication and Key Exchange

2828

Follows 3.8.6.3 or follow 3.9.6.3 if the network supports relay functionality.

2829
2830

3.11.6.1.4. Application

2831

Follows 3.8.6.4 or follow 3.9.6.4 if the network supports relay functionality.

2832

2833

3.11.7. Usage of credential

2834

In Route-IoT network, a Route-IoT specific credential (Table 4.8-58) is defined and required
to use it. For this purpose, this subsection defines how to use the credential in thecommunication protocols.

2835
2836
2837

Table 4.8-58 Route-IoT Credential

2838

Name

Description

HAN
authentication
ID

Smart meter: Character string of 24 comprised of 0~9 and A~F ASCII
characters (24 octets). The first character string of eight characters is“01000000” and the following string of 16 characters (16 octets) is
described in hexadecimal notation of MAC address of smart meter. In
this profile, this is converted to the ID ([NAI] format) used by PANA
(EAP-PSK) by the rule described later.
IoT device: Character string of 24 comprised of 0~9 and A~Z ASCII
characters (14 octets). In this profile, this ID is used by PANA (EAPPSK) as it is.

(HAN
Password linked to the HAN authentication ID (character string of 16
authentication) comprised of 0~9, a~z, and A~Z ASCII characters). In this profile, thisPasswordis used in generating PSK, which is utilized in [EAP-PSK], by the rule
following 3.8.7.2.
2839
2840

3.11.7.1. Conversion of HAN authentication ID to EAP Identifiers

2841

Based on the HAN authentication ID, the following rules are used to generate the EAP
Identifiers.

2842

Wi-SUN Profile for HAN

188 of 206

HAN Working Group[NAI generation rules]
Smart meter side NAI (EAP ID_S): ”CTRL” + ”HAN authentication ID of Smart meter” (24octets)IoT device side NAI (EAP ID_P): ”HAN authentication ID of IoT device” (14 octets)

Example:When Smart meter HAN authentication ID is "010000001111222233334444"
and IoT device HAN authentication ID is “55556666777788”
Smart meter side NAI (EAP ID_S): "CTRL010000001111222233334444"
IoT device side NAI (EAP ID_P): "55556666777788"
The MAC address in the Smart meter is supposed to be “1111222233334444”
The MAC address in the IoT device is “AAAABBBBCCCCDDDD”,
which is not related to the HAN authentication ID
2843
2844

2845

3.11.8. Discovery and selection of the smart meter network

2846

An IoT device uses an Enhanced Active Scan and detects one or more smart meters. The
IoT device selects one smart meter to connect to based on the received EB. The IoT device
starts the PANA authentication procedure with the selected smart meter after Enhanced
Active Scan. If PANA authentication failed, the IoT device tries to authenticate PANA toother detected smart meters until PANA authentication succeeds. The IoT device can use
an Enhanced Active Scan again to the all radio channels if it finds no smart meter on all
channels or authentication fails.

2847
2848
2849
2850
2851
2852
2853
2854
2855
2856

Figure 4.8-41 shows an example sequence for a shared Pairing ID in the smart meterdiscovery procedure. Figure 4.8-42 shows an example sequence for a unique Pairing ID in
the smart meter discovery procedure.

2857

Wi-SUN Profile for HAN

189 of 206

HAN Working Group

Pairing ID: “IOT*****” (shared by SM#1, SM#2 and IoT device)
ID_S : “CTRL010000001111222233334444”
ID_P : “55556666777788”

SM #1

SM #2

IoT device

Enhanced Beacon Request with IEs (Pairing ID& Capability Notification)
Enhanced Beacon with IEs (Pairing ID& Capability Notification)

Start PANA authentication process

2858
2859

Figure 4.8-41 Smart meter discovery procedure (Shared Pairing ID case)

2860

Pairing ID: 0xAAAABBBBCCCCDDDD (Unique ID, shared only by SM#2 and IoT device )ID_S : “CTRL010000001111222233334444”
ID_P : “55556666777788”

SM #1

SM #2

IoT device

Enhanced Beacon Request with IEs (Pairing ID& Capability Notification)
Enhanced Beacon with IEs (Pairing ID& Capability Notification)

Start PANA authentication process

2861
2862

Figure 4.8-42 Smart meter discovery procedure (Unique Pairing ID case)

2863

Wi-SUN Profile for HAN

190 of 206

HAN Working Group2864

4. Wi-SUN profiles (ECHONET Lite over non IP)

2865

4.1.

2866
2867
2868
2869
2870
2871
2872
2873
2874
2875
2876
2877
2878

Overview

This section defines physical (PHY) and data link layers profiles and Wi-SUN ECHONET
Lite interface to communicate between devices using non-IP and IEEE 802.15.4g and 4/4e.
Wi-SUN ECHONET-Lite interface is an interface between ECHONET Lite application partand physical and MAC layer parts and transmits ECHONET Lite application data from one
device to the other devices. Figure4.8-43 shows the scope of this section. Figure 4.2-1
shows the Wi-SUN profile layer structure.
In this section, the mark of "M" indicates the mandatory functions in the standards[802.15.4], [802.15.4g] and [802.15.4e], and "O" means optional functions. The marks of "Y"and "N"mean the required and not-required functions in ECHONET Lite operation,
respectively. Specifications and procedures for certification and interoperability tests areprovided by [Wi-SUN-PHY], [Wi-SUN-MAC], [Wi-SUN-IF], [Wi-SUN-CTEST] and [Wi-SUNITEST].
Device 1

Device 22879
2880
Device 1 application

Device 2 application

ECHONET-Liteapplication part

ECHONET-Liteapplication part

Wi-SUN ECHONET Lite
Interface part *1

Wi-SUN ECHONET Lite
Interface part *1

2881
2882
2883
2884
2885
2886

MAC part(IEEE802.15.4/4e)

Scope of this section

MAC part(IEEE802.15.4/4e)

2887
2888

PHY part(IEEE802.15.4g)

PHY part(IEEE802.15.4g)

2889
2890
2891
2892
2893

Figure4.8-43 Scope defined by this section (*1: Not required in case addressing
architectures are same between ECHONET Lite application layer and data link layer)
Wi-SUN Profile for HAN

191 of 206

HAN Working Group2894

Wi-SUN Profile for HAN

192 of 206

HAN Working Group

2895

4.2.

Protocol stack

2896

Protocol stack for the device defined by this profile is shown in Figure4.8-44.

2897
2898

Layer 5-7

2899

Application layer(ECHONET Lite)

2900
2901

Wi-SUN ECHONET Lite Interface part

2902
2903
2904
2905

Layer 2

MAC part(MAC profiles based on IEEE 802.15.4/4e)Layer 1

PHY part(PHY profiles based on IEEE 802.15.4g)

2906
2907
2908
2909
2910
2911

Figure4.8-44 Layer structure defined by this section (*1: Not required in case addressing
architectures are same between ECHONET Lite application layer and data link layer)

2912
2913

PHY layer provides the following service under this profile.

2914

・ Up-to-2047 bytes PSDU exchange (Note that the profile recommends 255 bytes or lessas mentioned later)

2915
2916
2917

Data link (MAC) layer provides the following services under this profile.

2918

・ Successful discovery of IEEE 802.15.4 PAN in radio propagation range

2919

・ Support of low energy hosts that can change its status between active and sleep status

2920

・ Security functions that includes encryption, manipulation detection and replay attack
protection (Note that key management is not performed by this layer)

2921

Wi-SUN Profile for HAN

193 of 206

HAN Working Group

2922
2923

Application layer provides the following services under this profile.

2924
2925

・ Detection of functional units (ECHONET object) employed by the other nodes in the
network

2926

・ Acquisition of parameters and statuses (ECHONET property) for the other nodes

2927

・ Configuration of parameters and statuses for other nodes

2928

・ Notification of parameters and statuses for the local node

2929

4.3.

2930

Refer to “3.3 PHY part”

2931

4.4.

2932

Refer to “3.4 MAC part”

2933

4.5.

2934

4.5.1. Overview

2935

2939

Wi-SUN ECHONET Lite interface shall provide a function to communicate between
ECHONET Lite application part and Wi-SUN PHY and MAC layer. This part is not required incase addressing architectures are same between ECHONET Lite application layer and datalink layer. This interface can improve high frame utilization efficiency by reducing overhead
when IP is used.

2940

4.5.2. Requirement

2941(1) Wi-SUN ECHONET Lite interface shall specify unique destination address and shallconfigure an ECHONET Interface header by specifying source address and Interface
Type. In the case, the Interface Type shall use 0xEC00.

2936
2937
2938

2942
2943
2944
2945
2946
2947
2948

PHY part

MAC part

Wi-SUN ECHONET Lite Interface part(2) Wi-SUN ECHONET Lite interface shall know address configuration used in MAC layer
in advance. The address configuration may be 64 bit IEEE Address.
(3) Wi-SUN ECHONET Lite interface shall convert the unique specified destination
address in Wi-SUN ECHONET Lite to MAC address used in MAC part and transmit to
MAC part.
Wi-SUN Profile for HAN

194 of 206

HAN Working Group2951(4) Wi-SUN ECHONET Lite interface shall analyze the unique specified destination
address. When the destination address is multicast address, the interface shall instruct
MAC layer to do broadcast transmission.

2952

4.6.

2949
2950

Application layer

2955

Wi-SUN ECHONET Lite interface shall support ECHONET Lite [EL] as application layer.
The node implemented specifications in this document shall support mandatory function
defined in [EL].

2956

4.7.

2953
2954

Security

2958

There are two ways for security in Non-IP based communications. Either way shall beselected.

2959•

Data encryption on MAC layer

2960

•

Data encryption on Wi-SUN ECHONET Lite interface

2957

2969

AES-CCM and/or AES-GCM shall be used in the case of data encryption for Wi-SUN
ECHONET Lite interface [EL][CMAC][AES-CCM][AES-GCM]. To use AES-CCM and/or AESGCM, MIC (message integrity code) shall be used. In the case of data encryption on MAC
layer, the MIC and/or AAD （ Additional Authenticated Data ） shall be included in the
IEEE802.15.4 MAC frame defined by [802.15.4], respectively. On the other hand, in the caseof data encryption on Wi-SUN ECHONET Lite interface, the MIC shall be included in the
security header described in Section 4.9.1.4.5. Multiple keys can be managed and stored in
the interface part. Since field of security ID in the security header (Figure4.8-55) is 1 byte,
255 keys can be managed.

2970

4.8.

2961
2962
2963
2964
2965
2966
2967
2968

2971
2972
2973
2974
2975
2976
2977
2978

Device ID

As an optional function, Wi-SUN ECHONET Lite interface may use unique device ID
allocated for each ECHONET Lite device. The device ID is used in order to identify
ECHONET devices. The value in this field is to be defined in the future according to theimplementers' preferences and not in the current version. The length of the device ID is 8
bytes. MAC address may be used for initial setting of the device ID. In the case, there are
two kinds of payloads: information payload and setting payload. Information payload will be
used for the transmission and receipt of ECHONET Lite information data, and setting
payload will be used for the transmission and receipt of device ID.

Wi-SUN Profile for HAN

195 of 206

HAN Working Group

2979

4.9.

Frame format

2981

This section describes frame format to support f Wi-SUN ECHONET Lite payload. The
frame format is dependent whether Wi-SUN ECHONET Lite interface part is used or not.

2982

4.9.1. The case interface part is employed2983

4.9.1.1. The case when data is encrypted on MAC layer

2984

A sample procedure of frame formatting in the case when data is encrypted on MAC layer isshown in Figure4.8-45 - Figure4.8-47. This is the case that destination and source MAC
addresses in ECHONET Interface header are different from those in IEEE 802.15.4 MAC
header. But integration between those in both headers may be possible.

2980

2985
2986
2987
2988

Variable
ECHONET Lite Payload
2989
2990

Figure4.8-45 ECHONET-Lite payload

2991
2992

8Byte

8Byte

2Byte

Variable

Destination
MAC address

Source
MAC address

Interface TypeECHONET Lite Payload

ECHONET Interface header
2993
2994

Figure4.8-46 Frame configured by Wi-SUN ECHONET Lite interface

2995
2996

Wi-SUN Profile for HAN

196 of 206

HAN Working Group

Encrypted part
Variable

8Byte

8Byte

2Byte

Variable

2ByteIEEE 802 .15 .4 header

Destination
MAC address

Source
MAC address

Interface TypeECHONET Lite Payload

FCS

ECHONET Interface header

2997

Figure4.8-47 IEEE802.15.4 frame configured by MAC layer

2998
2999
3000

4.9.1.2. The case when data is encrypted on Wi-SUN ECHONET Lite interface

3001

A sample procedure of frame formatting in the case when data is encrypted on Wi-SUN
ECHONET Lite interface is shown in Figure4.8-48 - Figure4.8-50. This is the case that
destination and source MAC addresses in ECHONET Interface header are different fromthose in IEEE 802.15.4 MAC header. But integration between those in both headers may bepossible.

3002
3003
3004
3005
3006

Variable
ECHONET Lite Payload
3007

Figure4.8-48 ECHONET-Lite payload

3008
3009
8Byte

8Byte

2Byte

9Byte

Variable

8Byte

Destination
MAC address

Source
MAC address

Interface Type

Security header

ECHONET Lite Payload

MIC

ECHONET Interface header

Encrypted part

3010
3011

Figure4.8-49 Frame configured by Wi-SUN ECHONET Lite interface

3012

Wi-SUN Profile for HAN

197 of 206

HAN Working Group

Variable
IEEE802 .15 .4 header

3013
3014

8Byte

8Byte

Destination
Source
MAC address MAC address

2Byte

9Byte

Variable

8Byte

2Byte

Interface Type

Security header

ECHONET Lite Payload

MIC

FCS

ECHONET Interface header

Encrypted part

Figure4.8-50 IEEE802.15.4 frame configured by MAC layer

3015
3016

Wi-SUN Profile for HAN

198 of 206

HAN Working Group

3017
3018
3019
3020
3021
3022
3023

4.9.1.3. The case when data is encrypted on Wi-SUN ECHONET Lite interface and optional
device ID is used
A sample procedure of frame formatting in the case when data is encrypted on Wi-SUN
ECHONET Lite interface and optional device ID is used is shown in Figure 4.9-7 - Figure
4.9-9. This is the case that destination and source MAC addresses in ECHONET Interface
header are different from those in IEEE 802.15.4 MAC header. But integration between
those in both headers may be possible.

3024

Variable
ECHONET Lite Payload
3025

Figure4.8-51 ECHONET-Lite payload

3026
3027
3028

8Byte

8Byte

2Byte

1Byte

9Byte

Variable

8Byte

3029

Destination
MAC address

Source
MAC address

Interface Type

Protocol info

Security header

Data Payload

MIC

3030
3031
3032

ECHONET Interface header

Encrypted part

Figure4.8-52 Frame configured by Wi-SUN ECHONET Lite interface

3033

3034
3035

Variable

8Byte

8Byte

2Byte

1Byte

9Byte

Variable

8Byte

2Byte

IEEE 802 .15 .4 header

Destination
MAC address

Source
MAC address

Interface Type

Protocol info

Security header

Data Payload

MIC

FCS

ECHONET Interface header

Encrypted part

Figure4.8-53 IEEE802.15.4 frame configured by MAC layer

3036

Wi-SUN Profile for HAN

199 of 206

HAN Working Group

3037

4.9.1.4. Elements in frame

3038

4.9.1.4.1.ECHONET Lite payload

3039
3040

ECHONET Lite payload consists of ECHONET Lite information generated by ECHONET
Lite application part.

3041

4.9.1.4.2.ECHONET Interface header

3042

Ether2 header is unique header used in WI-SUN ECHONET Lite interface.
shows the format.

3043
3044
3045
3046
3047
3048
3049
3050
3051
3052

Byte #

Bit7

Bit6

0
1
2
3
4
5
6
7
8
9

Bit5

Bit4

Bit3

Bit2

Bit1

Figure4.8-54

Bit0

Destination MAC address

10
11
12
13
14
15

Source MAC address

16
17Interface Type

3053

Figure4.8-54 Format of ECHONET Interface header

3054
3055
3056

(a) Destination address

3057
3058

Destination address defined by collaborating between ECHONET Lite application part and
Wi-SUN ECHONET Lite interface.

3059(b) Source address

3060
3061

Source address defined by Wi-SUN ECHONET Lite interface on the basis of addressconfiguration in MAC part

3062(c) Interface Type3063

0xEC00：Interface Type for ECHONET Lite

Wi-SUN Profile for HAN

200 of 206

HAN Working Group3064

4.9.1.4.3.IEEE802.15.4 header

3065
3066

IEEE802.15.4 header is a header for data transmission and receipt and is generated by
MAC part.

3067

4.9.1.4.4.FCS (Frame check sequence)

3068

FCS is a frame check sequence generated by MAC part.

3069
3070

4.9.1.4.5.Security header

3071

Security header defines information on encryption of transmission data.
shows the format.

3072

Figure4.8-55

3073
3074

Byte #

Bit7

Bit6

0

3075
3076

1
2
3

3077

4
5

3078

6

3079

7

Bit5

Bit4
Bit3
Security key ID

Bit2

Bit1

Bit0

Nonce：Reset information

Nonce：Message counter

8

3080

Figure4.8-55 Format of security header

3081
3082
3083

(a) Security key ID

3084

Security key ID is an identifier corresponds to encryption key used.

3085(b) Nonce (byte# 1-8)

3086
3087

A unique number is set to each transmission data and encrypted with data. The followings
define each element.

3088

Reset information (byte# 1-4): The number is incremental when the device is reset.

3089

Message counter (byte# 5-8): This is counter that counts the number of messages
transmitted

3090

Wi-SUN Profile for HAN

201 of 206

HAN Working Group

3091

4.9.1.4.6.MIC (Message Integrity Code)3092

The code is used for AES-CCM encryption.

3093

4.9.1.4.7.Protocol info

3094

Protocol info defines class of protocol. The info is mainly used when unique device ID isused and consists of version information and protocol class. Figure4.8-56 shows theformat.

3095
3096

Byte #

3097

Bit7

0

Bit6
Bit5
Version info

Bit4

Bit3

Bit2
Bit1
Protocol class

Bit0

Figure4.8-56 Format of protocol info

3098
3099
3100

(a) Version info: 4 bit is assigned and 16 versions are defined

3101(b) Protocol class: Classify setting payload and information payload

3102

0000: information payload, 0001: setting payload

3103

4.9.1.4.8.Data payload

3104

Data payload carries either information data or setting data based on device ID. The classof data payload is defined by protocol class. Figure4.8-57 and Figure4.8-58 show theformats for them. Figure4.8-58 shows format of settings request payload and settings
response payload. The Device ID for request is ID of request device. And The Device ID for
response is ID of response device.

3105
3106
3107
3108
3109
3110

Byte #

3111

Bit7

Bit6

Bit5

Bit4

Bit3

Bit2

Bit1

Bit0

ECHONET Lite Payload (Variable)

3112
3113
3114

1
2
3

3115

4
5

3116

6
7

3117
3118

MIC(Message Integrity Code)8

Figure4.8-57 Format of information data payload
Wi-SUN Profile for HAN

202 of 206

HAN Working Group

3119

Byte #

Bit7

Bit6

Bit5

0
1
2
3
4
5
6
7

Bit4
Bit3
Message identifier

Bit2

Bit1

Bit0

Device ID

8
9
10
11

3120

12
13
14
15
16

Figure4.8-58 Format of setting data payload

3121
3122

MIC(Message Integrity Code)(Interface part sets setting data payload including Device ID.)

3123
3124

(a) Message identifier: Identify between setting request and setting response

3125

00000000: Setting request

3126

00000001: Setting response

3127

4.9.2. The case interface part is not employed

3128

When ECHONET Lite application part employs IEEE802.15.4 MAC address directly, the
Wi-SUN ECHONET Lite interface part is not required. A sample procedure of frame
formatting is shown in Figure4.8-59 - Figure4.8-60.

3129
3130

Variable

ECHONET Lite
PayloadFigure4.8-59 ECHONET-Lite payload

3131
3132
Variable

Variable

2 Byte

Wi-SUN Profile for HAN

203 of 206

HAN Working GroupIEEE802.15.4
headerECHONET Lite Payload

FCS

Figure4.8-60IEEE802.15.4 frame configured by MAC layer

3133
3134

3135

4.10. Recommended usage for single-hop network

3136

4.10.1. Overview

3137

This clause clarifies the recommended usage in constructing single-hop network for
ECHONET Lite over non IP. Note that this profile does not exclude other usages.

3138

3143

Compliant nodes to this clause constructs single hop network where a coordinator iscentered. And, with assuming a gateway connection provided by application layer as theconnection measure to the outer networks, a closed IP network is assumed inside thisprofile. On those assumptions, the indoor network construction based on ECHONET Lite
provides expandability as well as feasibility.

3144

4.10.2. Construction of new network

3145

Once turned on, a coordinator constructs a new network compliant to this profile. The
network construction are conducted by successive steps of (1) data link layer configuration,(2) network layer configuration and (3) security configuration. Overview of the network
construction procedure is shown in Figure4.8-61 .

3139
3140
3141
3142

3146
3147
3148
3149

A coordinator turned on(1)Channel selection(2)

PAN ID determination

Data link layer
configurations

Security
configurations
3150
3151

Figure4.8-61 Overview of network construction procedure
Wi-SUN Profile for HAN

204 of 206

HAN Working Group

3152
3153

4.10.2.1. Data link layer configurations

3154

Once turned on, a coordinator constructs a IEEE 802.15.4 PAN. Detailed procedures for
PAN construction is shown as follows.

3155
3156
3157
3158

The coordinator first selects an employed channel. The channel selection is conducted via
ED scanning or active scanning. In the selection, channel with less interference to the othersystems are more preferable. (Step 1)

3161

Next, the coordinator selects the PAN ID that is not occupied on the selected channel in
Step 1, and define it as the PAN ID for the local network. Selection criteria of PAN ID out ofcandidate IDs is out of scope of this profile. (Step 2)

3162

With conducting of the previous steps, PAN construction by the coordinator is completed.

3163

4.10.2.2. Security configurations

3164

3167

The coordinator conducts security configurations following data link layer and network layer
configurations. Security technologies employed in the constructed network should beselected according to the application requests. This profile does not describe a concrete
procedure for security configurations conducted by the coordinator.

3168

4.10.3. Association to the network

3169

Once turned on, a new host tries to association to the existing network compliant to thisprofile. Association procedure by the host includes (1) data link layer configuration, (2)network layer configuration and (3) security configuration just in a same manner as PAN
construction by a coordinator. Overview of association procedures to the existing network
by a host is shown in Figure4.8-62.

3159
3160

3165
3166

3170
3171
3172
3173
3174

A new host turned on(1)

Network detection(2)

Network selection to associate

A coordinator(3)

Association(4)

Device authentication

3175
Wi-SUN Profile for HAN

205 of 206

HAN Working Group

3176

Figure4.8-62 Overview of association to the network

3177
3178

4.10.3.1. Data link layer configurations

3179

After turned on, a new host conducts IEEE 802.15.4 PAN detection existing around. The
PAN detection is conducted by the successive procedures; the host broadcasts a beacon
request commands that is defined in [802.15.4] on all available channels out of radio
channels defined in [802.15.4] and [T108], a coordinator that receives the command returns
a beacon frame as a response, and the new host receives the beacon. Moreover, the newhost recognizes a radio channel and PAN ID employed by the coordinator, as results of
those procedures. (Step 1)

3180
3181
3182
3183
3184
3185
3186
3187
3188
3189
3190
3191

In case only one PAN is detected, the host moves to the next step as for the PAN. In caseseveral PANs are detected, the host needs to select one PAN in order to move to the next
step. PAN selection criteria for the latter case is implementation matter and out of scope of
this profile. (Step 2)
The new host conducts association procedures defined in IEEE 802.15.4 to the selected
PAN in Step 2. (Step 3)3194

In case the host fails to associate to the PAN by those association procedures, for example
owing to rejection by the coordinator, the host is recommended to retry the procedures from
Step 1 or Step 2, where the other network should be tried in Step 2.

3195

4.10.3.2. Security configurations

3196

The new host conducts security configurations after data link layer and network layer
configurations. Security technologies employed in the constructed network should beselected according to the application requests. This profile does not describe concrete
procedures for security configurations.

3192
3193

3197
3198
3199

3201

4.10.4. Specifications for device/PHY layer/MAC layer in order to realize therecommended usage

3202

Refer to "3.6.2 and 3.6.3."

3200

3203
3204

Wi-SUN Profile for HAN

206 of 206