Version 1: Release Note 28 November 2014


Activation Date-Time Attribute



Download 4.8 Mb.
Page107/258
Date03.04.2021
Size4.8 Mb.
1   ...   103   104   105   106   107   108   109   110   ...   258
Activation Date-Time Attribute

Passive Attribute

Active Attribute

Class ID

OBIS

Attr. ID

Class ID

OBIS

Attr. ID

Class ID

OBIS

Attr. ID

TariffSwitchingTable(SpecialDays)

9000

0-0:94.44.128.29

6

11

0-1:11.0.0.255

2

11

0-0:11.0.0.255

2

StandingCharge.period

9000

0-0:94.44.128.32

6

9000

0-0:94.44.128.32

4

113

0-0:19.2.4.255

8

TariffThresholdMatrix

9000

0-0:63.1.1.255

6

21

0-0:16.1.12.255

2

21

0-0:16.0.12.255

2

TariffSwitchingTable(SecondaryElement).specialDays

9000

0-0:94.44.128.30

6

11

0-1:11.0.1.255

2

11

0-0:11.0.1.255

2

DisablementThreshold(MeterBalance)

9000

0-0:94.44.128.22

6

9000

0-0:94.44.128.22

4

21

0-0:16.0.1.255

2

DebtRecoveryRateCap

9000

0-0:94.44.128.12

6

9000

0-0:94.44.128.12

4

111

0-0:19.0.0.255

18

DebtRecoveryRateCap(period)

9000

0-0:94.44.128.13

6

9000

0-0:94.44.128.13

4

111

0-0:19.0.0.255

19

EmergencyCreditLimit

9000

0-0:94.44.128.2

6

9000

0-0:94.44.128.2

4

112

0-0:19.10.1.255

9

EmergencyCreditThreshold

9000

0-0:94.44.128.3

6

9000

0-0:94.44.128.3

4

112

0-0:19.10.1.255

10

LowCreditThreshold

9000

0-0:94.44.128.9

6

9000

0-0:94.44.128.9

4

111

0-0:19.0.0.255

16

Non-DisablementCalendar

9000

0-0:94.44.128.28

6

10

0-0:12.1.1.255

2

10

0-0:12.0.1.255

2

LoadLimitPeriod(Timer)

9000

0-0:94.44.128.6

6

9000

0-0:94.44.128.6

4

71

0-0:17.0.0.255

6

LoadLimitPowerThreshold

9000

0-0:94.44.128.7

6

9000

0-0:94.44.128.7

4

71

0-0:17.0.0.255

4

LoadLimitRestorationPeriod(Timer)

9000

0-0:94.44.128.8

6

9000

0-0:94.44.128.8

4

71

0-0:17.0.0.255

7

AuxiliaryLoadControlSwitchesCalendar

9000

0-0:94.44.128.26

6

10

0-0:12.0.2.255

2

10

0-1:12.0.2.255

2

Non-DisablementCalendar(SpecialDays)

9000

0-0:94.44.128.31

6

11

0-1:11.0.2.255

2

11

0-0:11.0.2.255

2

AuxiliaryLoadControlSwitchesCalendar(SpecialDays)

9000

0-0:94.44.128.35

6

11

0-1:11.0.3.255

2

11

0-0:11.0.3.255

2

Table 9.2.2.7: Values for Active and Passive Attributes for Account objects
  1. ZSE Implementation


Italicised terms in this Section 10 shall have their meaning in the ZCL / ZSE specifications.
    1. Introduction - informative


This Section 10 sets out specific requirements relating to the implementation of ZSE in Devices:

  • Tunnels: requirements relating to Devices’ support for the Tunneling Cluster. This includes specific differences between GSME, HHT and other Devices, related to their use of the Tunneling Cluster. Note that all Devices except Type 2 Devices shall support the Tunneling Cluster, since this is the mechanism by which Remote Party Messages (and HAN Only Messages between a PPMID and a GSME) are transported over the HAN;

  • GSME and GPF interactions (including the Tapping Off Mechanism): this includes requirements relating to the GPF maintaining a copy of GSME data items, where copies are not supported natively by ZSE mirroring;

  • GPF structured data items: requirements relating to how structured data items on the GPF are updated by the GSME and resulting values on the GPF are calculated; and

  • HHT interactions – requirements relating to HHT connection to the SMHAN, including specific Tunneling Cluster related requirements.
    1. Tunnels

      1. Overview – informative


All Remote Party Messages are carried across the SMHAN using the Tunneling Cluster’s TransferData command.

Type 2 Devices such as IHDs are not required to send or receive Remote Party Messages and so are not required to support the Tunneling Cluster.

Remote Party Messages to and from the GPF do not cross the SMHAN and so do not use the Tunneling Cluster.

All other types of Device need to be able to send and receive Remote Party Commands over the SMHAN and so, as specified in Section 10.2.2, shall support the Tunneling Cluster.

Section 10.2.2 lays out the associated requirements, across all Devices including those for the GSME and HHT.

GSME requirements are different than all other Devices since a GSME is a ‘sleepy’ Device. Additional GSME requirements are laid out in Sections 10.2.4 and 10.3.

HHT interactions also have specific requirements due to their function. These specific requirements are laid out in Section 10.5.

A PPMID may be a sleepy device, and therefore may have different requirements to other Type 1 devices.


      1. Requirements for the Tunneling Cluster


Remote Party Messages and SME.C.PPMID-GSME Messages shall be transported over the SMHAN using the Tunneling Cluster’s TransferData command. Except where a TransferData command is to or from a GSME, the value of the Data field’s payload in the TransferData command shall be the Remote Party Message or SME.C.PPMID-GSME Message. Where a TransferData command is to or from a GSME, the Data field’s payload of the TransferData command shall take the values specified in Section 10.2.4.

Devices supporting the Tunneling Cluster as a Server shall have a MaximumIncomingTransferSize set to 1500 octets, in line with the ZSE default. All Devices supporting the Tunneling Cluster shall use this value in any RequestTunnelResponse command and any RequestTunnel command.

Devices shall set the value of the ManufacturerCode field in any RequestTunnel command to 0xFFFF (‘not used’).

The ProtocolID of all Remote Party Messages shall be 6 (‘GB-HGRP’). Devices shall set the value of the ProtocolID field in any RequestTunnel command to 6.

Devices shall set the value of the FlowControlSupport field in any RequestTunnel command to ‘False’.

All Devices except Type 2 Devices and GPFs shall support the Tunneling Cluster and, within that Cluster, the use of the protocol with a ProtocolID of 6 (GB-HGRP).

An ESME, an HCALCS and a PPMID shall support the Tunneling Cluster as a Server.

A GSME and an HHT shall support the Tunneling Cluster as a Client.

A CHF and PPMID shall support the Tunneling Cluster as a Client and as a Server.

A GPF shall support mirroring functionality. The Basic Cluster Physical Environment attribute shall be supported and shall have the value 0x01.

When a Device receives a CloseTunnel command, the Device shall not close that tunnel unless the command is sent from the Device which opened the tunnel.

        1. ESME, HCALCS and PPMID


When a Communications Hub has successfully established a shared secret key using CBKE with a Device of type ESME, HCALCS or PPMID, the CHF shall send a RequestTunnel command to the Device to request a tunnel association with the Device.

Where an ESME, a HCALCS or a PPMID remains in the CHF Device Log, the CHF shall send a RequestTunnel command to the Device whenever:



  • 0xFFFF seconds have elapsed since receipt of the most recent RequestTunnelResponse command from that Device; or

  • the CHF receives a Remote Party Message addressed to the Device but does not have a functioning tunnel association with the Device; or

  • the CHF powers on.

Where the CHF receives a RequestTunnelResponse command from a Device with a TunnelStatus of 0x01 (Busy), the CHF shall send another RequestTunnel command three minutes later.

Where the CHF receives a RequestTunnelResponse command from a Device with a TunnelStatus of 0x02 (No More Tunnel IDs), the CHF shall send a CloseTunnel command for any TunnelID that may relate to an active tunnel association with that Device and, after receiving responses to all such commands, send another RequestTunnel command.


        1. GSME


When a GSME has successfully established a shared secret key using CBKE with a Communications Hub, the GSME shall:

  • send a request to the ZigBee Gas ESI Endpoint requesting the creation of mirrored Basic, Metering and Prepayment Clusters using the RequestMirror command;

  • configure, using the ConfigureMirror command, the ZigBee Gas Mirror Endpoint to use the two way mirroring notification scheme ‘Predefined Notification Scheme B’ ; and

  • send a RequestTunnel command to the CHF to request a tunnel association with the CHF.

Where the Communications Hub has successfully actioned a ConfigureMirror command, the GPF shall set the Push All Static Data - Basic Cluster, Push All Static Data - Metering Cluster and Push All Static Data - Prepayment Cluster flags.

For clarity, the GSME:



  • shall not action ZSE / ZCL commands received from the GPF in relation to any of the flags within NotificationFlags2, NotificationFlags3 and NotificationFlags5;

  • for NotificationFlags4, shall only action ZSE / ZCL commands received from the GPF in relation to the flags specified in Table 10.2.2.2a.

Bit Number

Waiting Command

6

Get Prepay Snapshot

7

Get Top Up Log

9

Get Debt Repayment Log

Table 10.2.2.2a: flags in NotificationFlags4 to be actioned by the GSME

  • for FunctionalNotificationFlags, shall only action ZSE / ZCL commands received from the GPF in relation to the flags specified in Table 10.2.2.2b:

Bit Number

Waiting Command

0

New OTA Firmware

1

CBKE Update Request

4

Stay Awake Request HAN

5

Stay Awake Request WAN

6-8

Push Historical Metering Data Attribute Set

9-11

Push Historical Prepayment Data Attribute Set

12

Push All Static Data - Basic Cluster

13

Push All Static Data - Metering Cluster

14

Push All Static Data - Prepayment Cluster

15

NetworkKeyActive

21

Tunnel Message Pending

22

GetSnapshot

23

GetSampledData

Table 10.2.2.2b: flags in FunctionalNotificationFlags to be actioned by the GSME

  • shall have access to the Notification Flags on the Communications Hub whenever it can communicate with the Communications Hub; and

  • shall not provide any metering data to the ZigBee Gas Mirror Endpoint until and unless the GPF’s Entity Identifier is recorded in the GSME Device Log.

The GSME shall send a RequestTunnel command to the CHF to request a tunnel association with the CHF whenever it does not have a currently valid tunnel association with the CHF, and one of the following is true:

  • the GSME has created an Alert or Response that is to be sent; or

  • the GSME has ascertained, via the Tunnel Message Pending flag, that there is a Command for it buffered on the Communications Hub.

Where the GSME receives a RequestTunnelResponse command from the CHF with a TunnelStatus of 0x01 (Busy), the GSME shall send another RequestTunnel command the next time it turns its HAN Interface on.

Where the GSME receives a RequestTunnelResponse command from the CHF with a TunnelStatus of 0x02 (No More Tunnel IDs), the GSME shall send a CloseTunnel command for any TunnelID that may relate to an active tunnel association between it and the CHF and, after receiving responses to all such commands, send another RequestTunnel command.



      1. Directory: government -> uploads -> system -> uploads -> attachment data -> file
        file -> Remove this if sending to pagerunnerr Page Title Light Rail Security Recommended Best Practice
        file -> 8 Section 1 : Sport
        file -> Notice of exercise of additional powers of seizure under Sections 50 or 51 of the Criminal Justice and Police Act 2001
        file -> Home office circular 004/2014 Powers to search for and seize invalid travel documents in Schedule 8 to the Anti-social Behaviour, Crime and Policing Act 2014
        file -> Consultation on the Royal Parks and Other Open Spaces (Amendment) (No. 2) Regulations 2012
        file -> Crown copyright 2012
        file -> This is the Report to Government by the Film Policy Review Panel The brief
        file -> Impact Assessment (IA)
        file -> Dcms/Wolfson Museums and Galleries Improvement Fund a public-Private Partnership (2002-2010)


        Share with your friends:
1   ...   103   104   105   106   107   108   109   110   ...   258




The database is protected by copyright ©essaydocs.org 2020
send message

    Main page