< 上一个 | 内容 | 下一个 >

C.2 Registration: Remote

The flow diagram in Figure C.1 describes client device remote registration to the customer HAN. Note that these are application layer details only, agnostic to the various layer 2 network joining techniques used by various PHY/MAC.


image

Figure C.1—Remote registration


NOTE—An XML example in POX encoding is provided along with the EXI equivalent.


Table C.1—POX example: Registration remote


Step

Description

1

(Out of band) Service provider populates client device’s EndDevice (containing short form device identifier [SFDI]) and Registration (containing personal identification number [PIN]) resources to appropriate HAN registration server (typically the ESI).

2

Client device joins the HAN (layer 2).

3

Client issues DNS-SD request to locate its EndDevice (keyed by its SFDI).

4

A server or multiple servers provides DNS-SD responses with URL to client’s EndDevice. If no reply is found, then there are no specific registrations for this device on this network.

5

For each reply received the client performs TLS and client authentication and executes the following steps. Note that client certificate is sent in the clear and thus SFDI can be determined.

6

Client and server now have an encrypted connection. Each has determined it is talking to an authenticated IEEE 2030.5 device, but have not confirmed they are talking to the correct specific IEEE 2030.5 device.

7

Server verifies client identity because client certificate hashes to the client SFDI.

8

Client GETs its EndDevice from Server as returned in DNS-SD Discovery. Client sends the following request:

GET /edev/3 HTTP/1.1 Host: {hostname}

Accept: application/sep+xml

9

Server responds with the EndDevice resource. Server sends the following response:

HTTP/1.1 200 OK

Content-Type: application/sep+xml Content-Length: {contentLength}

<EndDevice href="/edev/3" subscribable="0" xmlns="urn:ieee:std:2030.5:ns">

<ConfigurationLink href="/edev/3/cfg"/>

<DeviceInformationLink href="/edev/3/di"/>

<DeviceStatusLink href="/edev/3/ds"/>

<FileStatusLink href="/edev/3/fs"/>

<PowerStatusLink href="/edev/3/ps"/>

<sFDI>987654321005</sFDI>

<changedTime>1379905200</changedTime>

<FunctionSetAssignmentsListLink all="3" href="/edev/3/fsal"/>

<RegistrationLink href="/edev/3/reg"/>

<SubscriptionListLink all="0" href="/edev/3/subl"/>

</EndDevice>

10

Client GETs its Registration (containing its PIN) from the server as found in the EndDevice resource. Client sends the following request:

GET /edev/3/reg HTTP/1.1 Host: {hostname}

Accept: application/sep+xml

11

Server responds with the Registration resource. Note: the PIN is thus transmitted over a secure channel. Server sends the following response:

HTTP/1.1 200 OK

Content-Type: application/sep+xml Content-Length: {contentLength}

<Registration href="/edev/3/reg" xmlns="urn:ieee:std:2030.5:ns">

<dateTimeRegistered>1364774400</dateTimeRegistered>

<pIN>123455</pIN>

</Registration>

12

Client verifies its PIN versus that provided by the server. If the PIN is found to be invalid, then the client knows it is not registered with this server.


Table C.2—EXI example: Registration remote


Step

Description

1

(Same as POX example)

2

(Same as POX example)

3

(Same as POX example)

4

A server or multiple servers provides DNS-SD responses with URL to client’s EndDevice. If no reply is found, then there are no specific registrations for this device on this network.

TXT Record: level=+S1


Note: level=+S1 indicates the server can send/receive EXI with the IEEE 2030.5-2018 schema with arbitrary extensions, so subsequent HTTP content on the server may contain extended parts (not used in IEEE Std 2030.5-2018 but may be defined in future versions of IEEE Std 2030.5).

5

(Same as POX example)

6

(Same as POX example)

7

Client GETs its EndDevice from the server as returned in DNS-SD Discovery. Client sends the following request:

GET /edev/3 HTTP/1.1 Host: {hostname}

Accept: application/sep-exi; level=-S1


Note that level=-S1 indicates the client can receive EXI with the IEEE 2030.5-2018 schema without any arbitrary elements and attributes.

8

Server responds with the EndDevice resource. Server sends the following response:

HTTP/1.1 200 OK

Content-Type: application/sep-exi Content-Length: {contentLength}

a030 114c c66e 0092 f656 4657 62f3 3000 0069 7b2b 232b b179 997b 1b33 3881 85ec

ac8c aec5 e665 ec8d 2006 17b2 b232 bb17 9997 b239 8030 bd95 9195 d8bc ccbd 99cd 0185 ecac 8cae c5e6 65ee 0e63 b79a 8e9b 7c70 2c37 7fa4 4146 0183 8bd9 5919 5d8b

cccb d99c d85b 041a 5eca c8ca ec5e 665e e4ca ce00 0071 7b2b 232b b179 997b 9bab 1360


(130 bytes in binary, shown in hexadecimal)

9

Client GETs its Registration (containing its PIN) from the server as found in the EndDevice resource. Client sends the following request:

GET /edev/3/reg HTTP/1.1 Host: {hostname}

Accept: application/sep-exi; level=-S1

10

Server responds with the Registration resource. Note that the PIN is thus transmitted over a secure channel. Server sends the following response:

HTTP/1.1 200 OK

Content-Type: application/sep-exi Content-Length: {contentLength}

a030 114c c6f7 034b d959 195d 8bcc cbdc 9959 d202 738e 2814 5fe2 0380


(28 bytes in binary, shown in hexadecimal)

11

(Same as POX example)