Commands are sent from the Communications Hub via the tunnel to the GSME. Since the GSME is a ‘sleepy’ Device, a mechanism is needed for the GSME to request that Commands are sent to it by the CHF.
In common with the transport of all Remote Party Messages, the mechanism used is the TransferData command, but TransferData commands sent between a GSME and CHF need to distinguish between when:
the GSME is sending a Remote Party Message, so an Alert or a Response or a GBT Message containing part of an Alert / Response;
the GSME is asking the CHF to send it a Command, or a GBT Message containing part of a Command; and
the CHF is sending the GSME a Command, or a GBT Message containing part of a Command.
To meet this need, the following sections specify additional structure in the first part of the Data parameter of the TransferData commands sent between GSME and CHF. Specifically the sending Device shall:
where a Remote Party Message is not being sent (so when the GSME is requesting that a Message is sent), set the Data parameter payload in a TransferData command to the value of Tunnel Manager Header.
A mechanism is also required to notify the GSME that one or more Commands are available for retrieval from the CHF.
The ZSE specification has a flag called Tunnel Message Pending in the Functional Flag Notification definition. This flag is used to notify a GSME that the CHF has a Remote Party Message waiting to be transferred to the GSME. The flag is set on the first pending Command and is reset when all Remote Party Messages have been transferred to the GSME. The flag is available through the ReadAttribute or MirrorAttributeResponse command. The requirements for setting this flag are specified in Section 10.3.4. The Tunnel Manager Header identifies three different kinds of TransferData command usage:
GET (the value 0x01): this is used by the GSME to retrieve waiting Message from the CHF;
GET-RESPONSE (the concatenation 0x02 || number of Remote Party Messages remaining): this is used by the CHF to send a Remote Party Message to the GSME. It also indicates how many Remote Party Messages have yet to be retrieved; and
PUT(the value 0x03): this is used by the GSME to send a Message via the CHF.
Where a Command is waiting on the CHF for the GSME to retrieve it, the following sequence shall apply:
the Tunnel Message Pending flag is set on the Communications Hub as detailed in Section 10.3.4;
the GSME turns on its HAN Interface and obtains the value of the Tunnel Message Pending flag; and
If the Tunnel Message Pending flag is set:
the GSME sends a TransferData command to the CHF with the GET structure in the Tunnel Manager Header. The Tunnel Manager Header is the only content in the Data field of this TransferData command;
the CHF sends a TransferData command to the GSME with the GET-RESPONSE structure in the Tunnel Manager Header and a Message in the remaining part of the Data field of the command. The GET-RESPONSE structure details how many more Messages are available for retrieval; and
the GET and GET-RESPONSE pattern repeats until all Messages have been transferred or the GSME decides to stop requesting Messages.
When the GSME wishes to send a Message, the GSME sends a TransferData command to the CHF with the PUT structure in the Tunnel Manager Header and the Message in the remainder of the Data field in the TransferData command.