GBSM FLEXNET SMWAN GATEWAY

Transcription

1 Product Line GBSM FLEXNET SMWAN GATEWAY STUDENT GUIDE C-PAMI-GE /5/16

2 Copyright This document contains proprietary information. It is to be used only for the purpose for which it is intended. Information in this document is subject to change without notice and does not represent a commitment on the part of Sensus. No part of this publication may be reproduced, transmitted, stored in a retrieval system, or granulated into any language in any form by any means, without the written permission of Sensus. Copyright 2014, 2015, 2016 Sensus. All Rights Reserved. FlexNet and associated logos are trademarks of Sensus and its subsidiaries and affiliates. All other brand names may be trademarks of their respective owners. Sensus Unit 3/Lindenwood/Crockford Lane Chineham Business Park Chineham, RG24 8QY (0) Document: GBSM FlexNet SMWAN Gateway Document Number: C-PAMI-GE Revision History Revision Date Description Jul-14 Initial release. NA 14-May-15 Updates for CB4a Sep-15 Updates for CB5a May-16 Clarifications; Minor clarifications to verbiage and typo corrections; Standardisation of terminology; Describes CB5a PS1.1 / CB5b release. ii

3 DESCRIPTION This guide provides an overview of the operation and usage of the Smart Metering Wide Area Network (SMWAN) Gateway Application Programming Interface (API) used in the Great Britain Smart Metering Communications Services Provider North (CSPN) solution from Sensus. It describes each of the web services delivered with this solution. PREREQUISITES UK FlexNet Solution Introduction Series UK FlexNet RNI Operations Series Familiarity with basic data and radio frequency networking concepts Familiarity with APIs DURATION 4 hours CONTENTS This class contains the following topics: Module I: SMWAN Gateway Overview Module II: SMWAN Gateway Message Flows Module III: GBSM FlexNet FWDL Multiplexing REFERENCES SD DCC SMWAN Gateway Interface Specification GBSM FlexNet Solution Introduction Student Guide (C-SGAMI-GE-0317-xx) GBSM FlexNet RNI Operations Student Guide (C-SGAMI-GE-0318-xx) Sensus Smart Energy Glossary (C-SDAMI-GE-0252-xx) The -xx in the above references are the designation for the document revision. iii

4 This page left intentionally blank. iv

5 MODULE I: SMWAN GATEWAY OVERVIEW INTRODUCTION This module introduces GBSM FlexNet Solution integrators to the SMWAN Gateway API, including a description of the overall structure of the API and the operation of its individual web services. Note: Information in this instruction is deemed reliable and correct for instructional purposes. However, ongoing design development and refinements to the FlexNet Communication Network may occasionally result in a variance between educational materials and FlexNet architecture. Refer to Sensus Project Management for the latest details on design updates. MODULE CONTENTS Topics covered in this module include: Section I: SMWAN Gateway Overview Section II: GBCS Message Web Services Section III: Send Schedule Web Service Section IV: Receive Outage Web Service Section V: Distribute Firmware Image Web Service SMWAN Gateway Overview 1

6 SECTION I: SMWAN GATEWAY OVERVIEW INTRODUCTION This section reviews the features and functions of the SMWAN Gateway and provides a highlevel view of the flow of data through the gateway. A more detailed view of data flow is provided in Module II: SMWAN Gateway Message Flows on page 18. SECTION OBJECTIVES Following this section, you should be able to: 1. Describe the primary purpose of the WAN Gateway component. 2. Identify the supported web services. 3. Indicate whether a supported web service is a server or client service for the SMWAN GW. 4. Describe the two types of errors reported by the Gateway and how they are handled. 5. Describe the high-level data flow through the gateway. Note: This instruction provides an overview of the SWMWAN Gateway interface. Refer to the SD DCC SMWAN Gateway Interface Specification if you require additional details. SMWAN Gateway Overview 2

7 1. SMWAN GATEWAY DEFINITION The SMWAN Gateway API is a collection of web services that provide communication between the DCC Data Service Provider (DSP) and the Communications Hub (Comms Hub). It is used by the DSP to: Send Great Britain Companion Specification (GBCS) commands to smart metering devices Receive GBCS command response from smart metering devices Receive GBCS defined meter alerts from smart metering devices Receive Power Outage from Communications Hubs Distribute Firmware images to Communications Hubs It is a JAVA software component based on Red Hat Enterprise Linux (RHEL). Currently, five web services are defined: Send GBCS Message Receive GBCS Message Send Schedule Receive Outage Notification Distribute Firmware Image/Firmware Delivery Notification Each of these web services interacts with the DSP by transporting JavaScript Object Notation (JSON) formatted requests over HTTPS. 2. CLIENT-SERVER WEB SERVICE OPERATION Both the DSP and the SMWAN Gateway may play the role of client or server. In the server role, the gateway hosts the service. In the client role, the gateway requests the service. As the server, the SMWAN Gateway hosts the Send GBCS Message, Send Schedules, and Distribute Firmware Image services. As the client, the SMWAN Gateway receives the Receive GBCS Message and Receive Outage Notification services. Refer to Figure 1. FIGURE 1: SMWAN GATEWAY WEB SERVICES CLIENT-SERVER OPERATION SMWAN Gateway Overview 3

8 3. API ERROR HANDLING The SMWAN Gateway represents the CSP to the DSP and thus reports an error to the DSP if the CSP rejects a request. Examples of errors that can be logged: The FlexNet RNI cannot accept a request or has an error condition The DSP does not accept a request from the SMWAN Gateway Note: The SMWAN GW does not report or log errors in transmission to the smart metering endpoint (SME). HTTP status codes indicate the status of the requests. For example: 200: Message accepted 400: Bad Request Syntax error in request; view response for details 500: Internal Server Error SMWAN Gateway or other RNI component within FlexNet Solution is unavailable or otherwise malfunctioning The DSP attempts to re-send/retry a request at a later time when a pre-determined number of errors are received. Details about the number of retries and the retry interval are available in the DCC SD5 Error Handling Strategy document. Data Flow Through SMWAN Gateway Figure 2 illustrates the data flows from the DSP through the SMWAN Gateway to the RNI and on to a Comms Hub and back. Each of the web services are described in more detail in the following sections. FIGURE 2: DATA FLOW THROUGH SMWAN GATEWAY SMWAN Gateway Overview 4

9 SECTION II: GBCS MESSAGE WEB SERVICES INTRODUCTION This section describes the key functions and operation of the Great Britain Companion Specification (GBCS) send and receive messages web services. SECTION OBJECTIVES Following this section, you should be able to: 1. Describe the primary function of the Send GBCS Message web service. 2. Describe the operation of the Send GBCS Message web service. 3. Describe the primary function of the Receive GBCS Message web service. 4. Describe the operation of the Receive GBCS Message web service. GBCS Message Web Services 5

10 1. SEND GBCS MESSAGE WEB SERVICE OVERVIEW The Send GBCS Message web service transports GBCS Application Protocol Data Units (APDUs) to the Comms Hub (SDK). The web service is not concerned with the function of the command or the APDU protocol used (e.g. DLMS-COSEM). It handles all requests in the same manner. The web service supports the transmission of all Category 4 and 5 commands: Category 4: Demand Response On-Demand Category 5: Other On-Demand There are several on-demand command types supported by the service.they are summarized in Table 1. TABLE 1: ON-DEMAND COMMAND TYPES Command Type Execution Behaviour Response Behaviour DCC User Issued to meter or Comms Hub and executed immediately Returned to DSP within 30 seconds DSP Scheduled Issued and executed at designed date and time Returned to DSP within 24 hours Future-Dated Compound request where the command is issued to the meter and acknowledged immediately, but executed at a later time Returned to DSP within 24 hours Examples of DCC user on-demand requests include: Update tariff, balance, or payment mode Display message to customer Reset Customer PIN Read register values, network data, maximum demand values, pre-payment configuration, or profile data Retrieve daily consumption log or billing data log Update device configuration (selected parameters) Perform round Trip Tests to verify benchmark network performance Examples of DSP scheduled on-demand requests include: Retrieve daily read log or billing data log Read network data, maximum demand values, pre-payment configuration, or profile data Examples of future-dated on-demand requests include: Update tariff, price, balance, payment mode, or supplier name Display message to customer Update device configuration (selected parameters) Issue security credentials Reset maximum demand registers GBCS Message Web Services 6

11 2. SEND GBCS MESSAGE WEB SERVICE OPERATION The Send GBCS Message web service interacts with an RNI-hosted Scheduler service, via a Java Message Service (JMS) interface to verify the ability of the RNI to accept the request given the designated priority and target service level. The web service encapsulates the APDU over User Datagram Protocol (UDP) and sends the IPv6 packet to the Comms Hub IP Address. It also creates a transaction record, stored in a.csv file, containing the request ID and other details. The following acronyms are used in the Figure 3 which illustrates the web service operation: GBCS = Great Britain Companion Specification IP = Internet Protocol GP = Gas proxy GSME = Gas Smart Metering Endpoint ESME = Electric Smart Metering Endpoint CHF = Communications Hub Function FIGURE 3: SEND GBCS MESSAGE OPERATION GBCS Message Web Services 7

12 3. RECEIVE GBCS MESSAGE WEB SERVICE OVERVIEW The Receive GBCS Message web service receives GBCS APDUs from the Comms Hub and pushes those messages to the DSP. The web service listens for unsolicited messages and on-demand responses from the Comms Hubs: Unsolicited Messages Category 2: Scheduled Billing Read Category 3: Meter Alert Category 4 and 5: Future Dated Command Responses On Demand Responses Category 4: Responses to Demand Response On-Demand Category 5: Responses to Other On-Demand Includes Meter Acknowledgements to Future Dated Commands 4. RECEIVE GBCS MESSAGE WEB SERVICE OPERATION The Receive GBCS Message web service listens on four UDP ports for messages from the Comms Hubs: 11117: Category 2 Scheduled Reads 11118: Category 3 Meter Alerts 11119: On Demand Responses and Future Dated Command Notifications 11120: Comms Hub Manager The web service retrieves the APDU from the IPv6 message packets and forwards it to the DSP with a unique response ID. It also creates a transaction record, stored in a.csv file, containing the response ID and other details. No correlation is made between ingress and egress requests. (Figure 4) GBCS Message Web Services 8

13 FIGURE 4: RECEIVE GBCS MESSAGE OPERATION 5. ABOUT THE GBCS MESSAGE TRANSACTION LOG The GBCS web services interacts with the transaction log as follows: 1. Records for category 2-5 requests are written daily by the SMWAN Gateway to the following flat file: /san/gateway/gateway_<hostname>.log 2. At midnight each day the file is renamed to include the date and saved as san/gateway/ gateway_<hostname>.<date>.log 3. Transactions for the next day begin recording in /san/gateway/ gateway_<hostname>.log and the process repeats. Typically, the record format looks similar to the following: Msgtype,Req/RespId,Source_IP,HubId,BusTargetId,endpoint_type, command_type,priority,gwtimestamp1,hubtimestamp/gwtimestamp2, activation_time,status_code,status_message Note: This is an example only of the record format. This format and related information are subject to change. Consult the latest Implementation Guidance Memorandum (IGM) for the Head End System for actual details. For information on ingress and regress transactions, you also may consult SD 4.4.1, DCC SMWAN Gateway (Arqiva) Interface Specification. Some attributes may not be required for every request. The definition and value of the attributes may also vary according to the direction (ingress or egress) and message category of the transaction. Consult the IGM for the Head End System for details. GBCS Message Web Services 9

14 SECTION III: SEND SCHEDULE WEB SERVICE INTRODUCTION This section describes the key functions and operation of the Send Schedule web service. SECTION OBJECTIVES Following this section, you should be able to: 1. Describe the primary function of the Send Schedule web service. 2. Describe the operation of the Send Schedule web service. Send Schedule Web Service 10

15 1. SEND SCHEDULE WEB SERVICE OVERVIEW The Send Schedule web service instructs the RNI when to scan Comms Hubs for periodic (i.e., daily, weekly, monthly) read schedules. Service is hosted by SMWAN Gateway Interacts with an RNI-hosted scanner service Messages between the SMWAN GW and the RNI use JMS 2. SEND SCHEDULE WEB SERVICE OPERATION Operational summary: Schedule information is used by CSPN to perform an out-of-band poll to retrieve cached data from the Comms Hub Access to schedule is achieved by: Encoding (Base64) the original Service Request XML Passing it via the sendschedule object s Schedule parameter Schedule is acknowledged If the service request is accepted by CSPN, an HTTP 200 status code is returned with a requestacknowledgement object If not accepted, requestacknowledgement includes error information Figure 5 illustrates the web service operation. FIGURE 5: SEND SCHEDULE WEB SERVICE OPERATION Send Schedule Web Service 11

16 SECTION IV: RECEIVE OUTAGE WEB SERVICE INTRODUCTION This section describes the key functions and operation of the Receive Outage Notification web service. SECTION OBJECTIVES Following this section, you should be able to: 1. Describe the primary function of the Receive Outage Notification web service. 2. Describe the operation of the Receive Outage Notification web service. Receive Outage Web Service 12

17 1. RECEIVE OUTAGE NOTIFICATION WEB SERVICE OVERVIEW The Receive Outage Notification web service delivers power outage messages from a Comms Hub to the DSP. This service is hosted by the DSP. The Outage Notification is an unsolicited response generated at the start of a Comms Hub power outage message to the DSP. 2. RECEIVE OUTAGE NOTIFICATION WEB SERVICE OPERATION Power outage events are detected on the comms hub and messages are transmitted from the SDK on an alarm channel using native FlexNet communications protocol rather than UDP datagrams. The SMWAN gateway is registered to observe the associated Java Message Service (JMS) topics corresponding to these events. Figure 6 which illustrates the web service operation: FIGURE 6: RECEIVE OUTAGE NOTIFICATION OPERATION Receive Outage Web Service 13

18 SECTION V: DISTRIBUTE FIRMWARE IMAGE WEB SERVICE INTRODUCTION This section describes the key functions and operation of the Distribute Firmware Image web service. SECTION OBJECTIVES Following this section, you should be able to: 1. Describe the primary function of the Distribute Firmware Image web service. 2. Describe the operation of the Distribute Firmware Image web service. Note: This section introduces the Firmware Download (FWDL) web service. For information on multiple FWLDL jobs that are transmitted on multiple channels, refer to Firmware Download Multiplexing in this education series. Distribute Firmware Image Web Service 14

19 1. DISTRIBUTE FIRMWARE IMAGE WEB SERVICE OVERVIEW The Distribute Firmware Image web service receives requests from the DSP to distribute firmware images. This service is hosted by the SMWAN Gateway. The FlexNet Firmware download service is designed for downloading both endpoint firmware and Comms Hub firmware. As such, this service can be used by the DSP for distributing FWDL images for smart metering endpoints (SMEs) or by Arqiva for distributing FWDL images for Comms Hubs. In both cases the web service is responsible for successfully delivering the firmware image to the Communications Hub. Note: The Distribute Firmware Image web service does not activate the image upgrade process on the endpoint or provide a confirmation of upgrade completion. FWDL completion responses are sent by the target device using the Receive GBCS Message web service. 2. DISTRIBUTE FIRMWARE IMAGE WEB SERVICE OPERATION Requests from the DSP are received by the SMWAN Gateway which then interacts with the Distribute Firmware Image web service to authorize and perform download of firmware images. Requests are issued with an image and a list of Comms Hub/ Business Target ID pairs that identify the particular devices targeted to be upgraded. Request attributes include: RequestId: unique id specified by the API user ApprovedFirmwareVersionId: unique identifier of the image List of: BusinessTargetID: identifier of the target endpoint. This information is needed at the Comms Hub to determine the ultimate destination of the image. CommsHubID: REPID Firmware Image: the image file The image delivered to the specified Comms Hubs using the FlexNet messaging protocol. The Comms Hub host layer is responsible for forwarding the image to the business target ID (endpoint). The SMWAN Gateway creates a transaction record, stored in a.csv file, including the details of each FWDL job. Distribute Firmware Image Web Service 15

20 Figure 7 illustrates the web service operation. FIGURE 7: DISTRIBUTE FIRMWARE IMAGE WEB SERVICE OPERATION 3. ABOUT THE DISTRIBUTE FIRMWARE IMAGE TRANSACTION LOG The SMWAN Gateway creates a record for each FWDL job into the following flat file by default: /san/fwdl/<requestid>.log Distribute Firmware Image Web Service 16

21 4. SUMMARY DATA FLOW THROUGH SMWAN GATEWAY TO A SME FIGURE 8: SUMMARY DATA FLOW Distribute Firmware Image Web Service 17

22 MODULE II: SMWAN GATEWAY MESSAGE FLOWS INTRODUCTION This module describes the flow of messages from the DSP to the SMWAN Gateway through the RNI to an endpoint, and back. It presents the various handling a message receives during this journey by the various functional blocks of the FlexNet Solution in an attempt to provide a basis for basic troubleshooting. MODULE CONTENTS Topics covered in this module include: Section I: GBSM Message Flows Overview Section II: Example On-Demand Requests Message Flow Section III: Example Scheduled Reads Message Flow Section IV: Example Meter Alerts Message Flow Section V: Example Future Dated Response Message Flow Section VI: Example Power Outage Notification Message Flow Section VIII: Example Distribute Firmware Image Message Flow Section VII: Example Round Trip Test Message Flow SMWAN Gateway Message Flows 18

23 SECTION I: GBSM MESSAGE FLOWS OVERVIEW INTRODUCTION This section introduces the message flows that occur in the GB Smart Metering solution, including a high-level description of categories and classes of message flows along with their differentiating characteristics. SECTION OBJECTIVES Following this section, you should be able to: 3. Identify the three categories of transaction flows. 4. Identify the sub-classes of each transaction flow. 5. Compare the various on-demand categories. GBSM Message Flows Overview 19

24 1. SMWAN GATEWAY TRANSACTION FLOW CATEGORIES The SMWAN Gateway API uses three categories of transactions: DSP-initiated Meter-initiated Communications Hub-initiated Each of these transaction types are described in the following sections. 2. DSP-INITIATED TRANSACTIONS DSP-initiated transactions are commonly called On Demand transactions. From the Communications Service Provider (CSP) and SMWAN Gateway perspective, all on-demand transactions originate from the DSP. From DSP/DCC User perspective, three sub-classes exist, differentiated by their handling priority: DCC User On Demand Future Dated DSP Scheduled Requests enter the CSP network through the SMWAN Gateway Send GBCS Message method. The following parameters are used by the SMWAN Gateway to properly process the request: requestid: unique identifier supplied by DSP. CommsHubId: REPID of the Comms Hub to receive message. priority: urgency with which to handle a given message. payload: content of message endpointtype: type of endpoint receiving the message; used to determine the minimum amount of time required before the endpoint can use an assigned response (uplink) timeslot. BusinessTargetID EUI64 identifier defined by the GBCS. CommandType: Service Reference Variant as defined by DUGIDS reference. ActivationTime: non mandatory identifier for future dated service requests only, with activation time in format of YYYYMMDDHHMMSS.SSS. A special value of is used to indicate cancellation of a future dated Service Request GBSM Message Flows Overview 20

25 A. DCC USER ON DEMAND TRANSACTIONS As the name suggests, DCC User on-demand requests are initiated by the DCC User at the utility. These requests occur largely during business hours and can be made to a variety of endpoints: ESME: Electric Smart Metering Endpoint GSME: Gas Smart Metering Endpoint Comms Hub: FlexNet Radio Card installed in Communications Hub DCC User on demand requests are expected to be completed, end to end (from DSP User to endpoint and back), in 30 seconds (25 seconds across the CSP network), and thus all use the highest priority (3) of any on demand requests from the DSP. The DSP waits 60 seconds; however, before giving up and reporting an error back to the user. B. FUTURE DATED TRANSACTIONS Future-dated requests are actually compound requests. Each request is comprised of: An on-demand request which is acknowledged by the metering endpoint, and A future dated response pushed by the endpoint when it has completed execution of the command at some future time. Future-dated on-demand requests are expected to be completed, end to end, in 24 hours (2 hours across the CSP network), and thus use a priority 2. GBSM Message Flows Overview 21

26 C. DSP SCHEDULED TRANSACTIONS DSP scheduled requests are issued when the DCC User wants to execute a transaction on a meter at a scheduled date and time. These requests typically occur during non-business hours. The DSP maintains these schedules since meters generally are only capable of keeping a single schedule which is used for the regular billing read. At the designated date and time, the DSP issues the on-demand request to the meter. DSP scheduled requests are expectation to be completed, end to end, in 24 hours (2 hours across the CSP network), and thus use a priority 2, just like future-dated transactions. 3. METER-INITIATED TRANSACTIONS Meter-initiated requests originate from an ESME or GSME. Requests exit the CSP network through the SMWAN Gateway Receive GBCS Message method. From the DSP/DCC User perspective, three sub-classes exist: Future Dated response Meter Scheduled Meter Alert GBSM Message Flows Overview 22

27 A. FUTURE DATED RESPONSES A future-dated response is the reply to a prior request, occurring some time in the past. The response occurs when the requested action takes place (message 5 in the diagram). Future dated responses are expected to be completed, end to end (from meter to DCC User), in 24 hours (22 hours across the CSP network), and thus are considered low priority messages at the Comms Hub. The CSP network has no information on when these requests are dated. B. METER SCHEDULED TRANSACTIONS Meter scheduled transactions are requests that are scheduled for the meter to occur at a given date and time. This is typically used for the scheduled billing read, but may be used for other transactions if desired. Meter Scheduled requests are expected to be completed, end to end, in 24 hours (22 hours across the CSP network), and thus are considered low priority messages at the Comms Hub. C. METER ALERTS Meter alerts are unsolicited urgent messages pushed from the ESME or GSME to the DCC User. Meter alert requests are expected to be completed, end to end (meter to DSP), in 60 seconds (55 seconds across the CSP network), and thus are considered high priority messages at the Comms Hub. GBSM Message Flows Overview 23

28 4. COMMUNICATIONS HUB-INITIATED TRANSACTIONS Communications Hub-initiated transactions originate, not surprisingly, from Communications Hubs. As example of this is the Power Outage Notification. Requests exit the CSP network through the SMWAN Gateway Receive Outage Notification web service. A. POWER OUTAGE NOTIFICATION These notifications, or alarms, are pushed from Comms Hub to DSP indicating the loss of power to the Comms Hub. Power outage notifications are delivered using the dedicated FlexNet alarm channel, not the regular uplink data channel for the express purpose of avoiding excessive delivery delays. However, the SMWAN Gateway throttles alarms, limiting them to 500 per second. This prevents the DSP/DCC Systems from being overloaded. GBSM Message Flows Overview 24

29 SECTION II: EXAMPLE ON-DEMAND REQUESTS MESSAGE FLOW INTRODUCTION This section illustrates and describes the flow an on-demand request message takes as it travels from the SMWAN Gateway through the UK FlexNet RNI to an endpoint and the flow a corresponding response message takes as it returns to the SMWAN Gateway. The flow is described at the RNI services level, showing the message handling by key services, to aid Arqiva in understanding and investigating issues with message traffic. It is not intended that this be a complete description or to provide all information needed for troubleshooting issues, but as a first step in comprehension. SECTION OBJECTIVES Following this section, you should be able to: 1. Identify key steps an on-demand request message takes through the FlexNet system. Example On-Demand Requests Message Flow 25

30 1. EXAMPLE: DCC USER ON-DEMAND TO ESME MESSAGE FLOW Figure 9 illustrates the entire flow. The steps are described in the following procedures. Downlink Flow 1. The DCC User invokes a service request on the DSP passing the attributes required for the DSP to create the GBCS compliant message. The DSP forms and sends the Send GBCS Message to the SMWAN Gateway with: Comms Hub ID = CH1 priority = 3, and endpointtype = ESME. Note: Specifying a priority of 3 indicates this is a DCC User On Demand request. 2. If successful: a. FlexIP DNS (ipdns service) performs an address lookup for CH1. b. On receipt of the address, the SMWAN Gateway forms and dispatches an IPv6 packet (with IP traffic class set) to the FlexIP Route Engine (ipre service). c. The SMWAN Gateway informs the DSP that the request has been received (HTTP 200). d. The SMWAN Gateway records the request details into a transaction log. 3. The FlexIP Route Engine compresses the packet header and passes the packet to the IP Traffic service (flexnetapp) which maps the traffic class to a tower priority and determines the timeslot offset. The IP Traffic service then sends it to the RNI Scheduler (flexnet gwscheduler service) for transmission. 4. The RNI Scheduler sends the message packet to the FlexApp FlexRouter (flexnetapp service) which selects a route and sends the message to NC Progs (ncprogs service). The Scheduler may place the message on a queue if the system is busy. 5. NC Progs encrypts the message and sends it to the designated tower (S1600E). 6. The Tower selects a response timeslot (far enough into the future that the message can be processed by the Communications Hub and/or SME) and sends the message to Comms Hub (CH1). The Tower also sends a Transmission report back to FlexApp FlexRouter and Reliable Uplink (flexnet reliable uplink service) makes note of timeslot. 7. The FlexRouter begins monitoring for the L2 acknowledgment (L2Ack) from CH1/SDK and the Reliable Uplink begins monitoring for the timeslot response. 8. The SDK in CH1 de-compresses the IP layers of the message and passes it to the CH Host application. The SDK issues an L2Ack to the FlexRouter and the CH Host sends the APDU (application protocol data unit) to the electric meter using the ZigBee protocol for wireless communications. Example On-Demand Requests Message Flow 26

31 Example On-Demand Requests Message Flow 27 FIGURE 9: DCC USER ON DEMAND TO ESME MESSAGE FLOW Uplink Flow 9. The ESME responds to the message causing the CH Host to prepare a packet for the known SMWAN Gateway on port The SDK places the message on the high priority queue and waits for the previously assigned timeslot. 10.The SDK sends the response message over the air during the assigned timeslot, and the S1600E forwards it to NC Progs. 11.NC Progs decrypts the message and forwards it to the IP Traffic service which forwards it to FlexIP Route Engine. Reliable Uplink sees the message and verifies the timeslot has data. 12.The FlexIP Route Engine de-compresses the packet header, forms IPv6 packet, and forwards it to the SMWAN Gateway. 13.The SMWAN Gateway sends a Receive GBCS Message response to the DSP and records details of the message in the transaction log. The DSP acknowledges the message and forwards it to the DCC User that made the request. GBSM FLEXNET SMWAN GATEWAY

32 2. VARIATIONS ON THE ON-DEMAND REQUEST MESSAGE FLOW The general flow shown in example above can vary under specific circumstances, such as when: The uplink message is fragmented The response timeslot is missed The request is sent to an ORD (out-of-reach) Comms Hub The request is targeted for a Comms Hub (not an SME) The request is targeted for a GSME The DSP wants the response to occur on a scheduled basis The changes to the example flow are described for each of these circumstances in the following sections. Use Figure 9 for reference. A. ON DEMAND REQUEST TO ESME WITH FRAGMENTED UPLINK MESSAGE In this scenario, the response from the ESME is too large to be contained in a single message and must be fragmented into smaller messages to be transmitted. The downlink flow is unchanged. The uplink flow is modified at Step 10. Instead of sending a single message, the SDK sends the first of the message fragments during the assigned timeslot. When the RNI receives this packet, it requests additional timeslots for the remaining message fragments. B. ON DEMAND REQUEST TO ESME WITH MISSED TIMESLOT In this scenario, the response message is not ready (has not yet been prepared by the CH and put on the queue by the SDK) when the timeslot arrives. The downlink flow is unchanged. The uplink flow is modified at Steps 9/10. The SDK transmits an alternative message in the assigned timeslot, such as a full tower signal report. Then, when the response message is ready, the SDK issues a Request to Send (RTS) to acquire a new response timeslot. It waits for the new timeslot and sends it. C. ON DEMAND REQUEST TO AN OUT-OF-REACH COMMS HUB In this scenario, a Comms Hub (CH) is out of reach of the main network and must use a buddy Comms Hub to receive and transmit messages. The downlink flow is modified at Steps 6a-9. Instead of sending the message to CH1, the tower sends the message to CHN acting as a buddy for CH1. CHN forwards the message on to CH1. The uplink flow is modified such that the response from the ORD CH1 is returned through CHN to CH1. It follows the standard path after that. D. ON DEMAND REQUEST TO A COMMUNICATIONS HUB OR GAS PROXY In this scenario, the target endpoint is either CH1 itself or a Gas Proxy.This affects the downlink flow at Step 3, 8c, and 9. In Step 3, the minimum amount of time needed for a response is determined. It would be significantly smaller for the CH or a gas proxy than for Example On-Demand Requests Message Flow 28

33 an SME. In Steps 8c and 9, CH1 does not send the APDU to a physical SME which means no HAN communications are needed. There are no changes to the uplink flow. E. ON DEMAND REQUEST TO GAS SME In this scenario, the target is a gas SME (GSME) which respond more slowly than ESMEs.The uplink flow is modified at Step 6a. The tower sends the message to CH1, but does not select a timeslot since it is unknown when the GSME will respond. The uplink flow is also modified, at Steps 9 and 10. When the GSME responds, CH1 prepares the message and provides it to the SDK. The SDK must issue an RTS to acquire a timeslot for transmission. When the timeslot arrives, the SDK sends the message in the usual fashion. F. DSP SCHEDULED ON DEMAND In this scenario, the request is scheduled to occur at a specific date and time. This type of on demand request expects a shorter response time than the standard on demand command. The uplink flow is modified at Step 1. When the DSP forms and sends the Send GBCS Message to the SMWAN Gateway, it sets a priority of 2 to indicated an expected target service level of 2 hours. The uplink flow is unchanged. Example On-Demand Requests Message Flow 29

34 SECTION III: EXAMPLE SCHEDULED READS MESSAGE FLOW INTRODUCTION This section illustrates and describes the flow a scheduled read request message takes as it travels from the SMWAN Gateway through the UK FlexNet RNI to an endpoint and the flow a corresponding response message takes as it returns to the SMWAN Gateway. The flow is described at the RNI services level, showing the message handling by key services, to aid Arqiva in understanding and investigating issues with message traffic. It is not intended that this be a complete description or to provide all information needed for troubleshooting issues, but as a first step in comprehension. SECTION OBJECTIVES Following this section, you should be able to: 1. Identify key steps a scheduled read request message takes through the FlexNet system. Example Scheduled Reads Message Flow 30

35 1. ABOUT SCHEDULED READS In general, SME read messages are collected through a Scan service in the RNI. The Scan service contains the schedule by which to collect the read data. Scan schedules define a start time and window within which the RNI polls (via a beacon) a Comms Hub to retrieve low priority cached messages. A scheduled read is this sort of message and handled in a similar manner. 2. EXAMPLE ESME SCHEDULED READ MESSAGE FLOW The following example assumes that the Scan schedules have already been configured and stored in the database. For the Capability Bundle 2 release, scan schedules are created by a database administrator by directly inserting them into the FlexNet Solution Database. Note: For details about the database tables and commands used to manage scan schedules, refer to the Database Overview module in the RNI Operations series. Figure 10 illustrates the entire flow. The steps are described in the following procedures. Downlink Flow 1. The FlexIP Scan service (flexnet scanner) retrieves a list of Communications Hubs that require polls during a given time period from the FlexNet Database. 2. The ESME has a billing schedule and collects read data at designated time. The ESME sends data to CH1 Host specifying a low priority and type of message (category = 2). 3. The CH1 Host creates the read message, which: includes an envelope containing an EPOCH-formatted timestamp of when the message was received on the CH, is addressed to a well-known SMWAN Gateway (using an alias address which is resolved by FlexIP Route Engine to the real IP address), Specifies an IP Class of Service (CoS) that reflects a low priority message, and specifies the UDP port on which the SMWAN Gateway listens for scheduled reads The CH1 Host sends the read message to the SDK which compresses the IP packet headers and places the message on a low priority queue. The SDK then waits up to 21 hours for a poll from the tower. 4. The Scan service requests, from the RNI Scheduler (flexnet gwscheduler), an uplink timeslot that is within the scan window for CH1. The RNI Scheduler accepts the request if the system has the resources available to issue the poll within the scan window. 5. The RNI Scheduler forwards the message to the FlexApp FlexRouter (flexnetapp) which selects a route and sends the message to NC Progs (ncprogs). 6. NC Progs sends the Request to Send Response (RTSR) message to the tower. 7. The Tower reports the assigned timeslot(s) back to RNI and sends the message to CH1 (and any other Comms Hubs with read messages in this scan window). Example Scheduled Reads Message Flow 31

36 Example Scheduled Reads Message Flow 32 FIGURE 10: ESME SCHEDULED READ MESSAGE FLOW Uplink Flow 8. The SDK inserts the read message into the timeslot delivered from the tower and sends it back to the tower. The Tower sends the message to NC Progs. 9. NC Progs decrypts the message and forwards it to the IP Traffic service (flexnetapp). The Reliable Uplink service sees the response timeslot has data. 10.The IP Traffic service forwards to the message to the FlexIP Route Engine (ipre) which decompresses the IP packet header and sends to SMWAN Gateway. 11.The SMWAN Gateway records the details of the message into the transaction log and forwards a Receive GBCS Message to the DSP, which in turn forwards it to the DCC User. GBSM FLEXNET SMWAN GATEWAY

37 3. VARIATIONS ON THE SCHEDULED READ MESSAGE FLOW The general flow shown in example above can vary under specific circumstances, such as when: The request is sent to an ORD (out-of-reach) ESME The response timeslot is missed The changes to the example flow are described for each of these circumstances in the following sections. Use Figure 10 for reference. A. SCHEDULED READ TO AN OUT OF REACH COMMS HUB In this scenario, a Comms Hub (CH) is out of reach of the main network and must use a buddy CH to receive and transmit messages. The uplink flow is unchanged from CH1. The downlink flow is modified at Step 7. Instead of sending the message to CH1, the tower sends the message to CHN acting as a buddy for CH1. CHN forwards the message on to CH1. The uplink flow is modified such that the response from the ORD CH1 is returned through CHN to CH1. It follows the standard path after that. B. SCHEDULED READ WITH MISSED BEACON In this scenario, the response message is not ready (has not yet been prepared by the CH and put on the queue by the SDK) when the timeslot arrives. The downlink flow is unchanged. The uplink flow is modified at Step 8. The SDK does not receive a poll within 21 hours of receiving the low priority scheduled read message so it issues a Request to Send (RTS) to acquire a new response timeslot. It waits for the new timeslot and sends it. Example Scheduled Reads Message Flow 33

38 SECTION IV: EXAMPLE METER ALERTS MESSAGE FLOW INTRODUCTION This section illustrates and describes the flow a meter alert message takes as it travels from the Smart Metering Endpoint (SME) through the UK FlexNet RNI to the SMWAN Gateway. The flow is described at the RNI services level, showing the message handling by key services, to aid Arqiva in understanding and investigating issues with message traffic. It is not intended that this be a complete description or to provide all information needed for troubleshooting issues, but as a first step in comprehension. SECTION OBJECTIVES Following this section, you should be able to: 1. Identify key steps a meter alert message takes through the FlexNet system. Example Meter Alerts Message Flow 34

39 1. ABOUT METER ALERTS Meter Alerts are generated by the SMEs to the DCC User. They are similar to scheduled reads in that they are unsolicited. They are different from scheduled reads in that they must be flagged as high priority messages such that the SDK will take action (invoke an RTS) to transmit them immediately. 2. EXAMPLE ESME METER ALERT MESSAGE FLOW A Meter Alert message is only transmitted in the uplink direction. Figure 11 illustrates the entire flow. The steps are described in the following procedures. Uplink Flow 1. A fault is detected on the SME causing the SME to send a message to CH1. The SME identifies it as a high priority alert message. 2. The CH1 Host creates the alert message, which: includes an envelope containing an EPOCH-formatted timestamp of when the message was received on CH1, is addressed to a well-known SMWAN Gateway (using an alias address which is resolved by FlexIP Route Engine to the real IP address), specifies the UDP port on which the SMWAN Gateway listens for these alerts The CH1 Host sends the alert message to the SDK which compresses the IP packet headers 3. The SDK issues an RTS to the FlexApp FlexRouter (flexnetapp) to request a timeslot for transmission of the alert and places the message on a high priority queue. The SDK then waits for a poll from the tower. 4. FlexApp FlexRouter sends a request via NC Progs (ncprogs) for the tower to poll CH1. 5. The Tower returns information about the timeslot allocated for poll to the FlexApp FlexRouter and sends beacon to CH1. Reliable Uplink (flexnet reliable uplink) begins monitoring for the timeslot. 6. SDK inserts the alert message into the assigned timeslot delivered from the tower and sends it back to the tower. The Tower sends the message to NC Progs. 7. NC Progs decrypts the message and sends it to the IP Traffic service (flexnetapp). 8. The IP Traffic service forwards the alert message to the FlexIP Route Engine (ipre) which decompresses the IP packet header and sends it on to the SMWAN Gateway. 9. The SMWAN Gateway records the details of the alert message into the transaction log and forwards a Receive GBCS Message to the DSP, which forwards it to the DCC User. Example Meter Alerts Message Flow 35

40 Example Meter Alerts Message Flow 36 FIGURE 11: METER ALERTS MESSAGE FLOW 3. VARIATIONS ON METER ALERTS MESSAGE FLOW There is only one circumstance that modifies the above flow-when the SME in categorised as an ORD. The changes to the example flow are described for this circumstance in the following section. Use Figure 11 for reference. A. METER ALERTS MESSAGE FLOW FROM ORDS In this scenario, the Comms Hub (CH) is out of reach of the main network and must use a buddy meter to receive and transmit messages. The uplink flow is unchanged from CH1. The downlink flow is modified at Step 3. Instead of sending the message to CH1, the tower sends the message to CHN acting as a buddy for CH1. CHN forwards the message on to CH1. The uplink flow is modified in that the response from the ORD CH is returned through CHN to CH1. SDK on CH1 issues an RTS to the FlexApp FlexRouter to request a timeslot, places the message into the high priority queue, and waits for poll. It follows the standard path at this point. GBSM FLEXNET SMWAN GATEWAY

41 SECTION V: EXAMPLE FUTURE DATED RESPONSE MESSAGE FLOW INTRODUCTION This section illustrates and describes the flow a future-dated response message takes as it travels from the Smart Metering Endpoint (SME) through the UK FlexNet RNI to the SMWAN Gateway. The flow is described at the RNI services level, showing the message handling by key services, to aid Arqiva in understanding and investigating issues with message traffic. It is not intended that this be a complete description or to provide all information needed for troubleshooting issues, but as a first step in comprehension. SECTION OBJECTIVES Following this section, you should be able to: 1. Identify key steps a future-dated response message takes through the FlexNet system. Example Future Dated Response Message Flow 37

42 1. ABOUT FUTURE DATED RESPONSES Future Dated Responses are generated by the Communications Hub once a standard Send GBCS Message marked for execution at a later time and date has been executed at the SME. 2. EXAMPLE FUTURE DATED RESPONSE MESSAGE FLOW A Future Dated Response message is only transmitted in the uplink direction, but the corresponding Send GBCS Message is shown in our example. Figure 12 illustrates the entire flow. The response is represented by the uplink flow. The steps are described in the following procedures. Downlink Flow 1. The DCC User invokes a service request on the DSP passing the attributes required for the DSP to create the GBCS compliant message. The DSP forms and sends the Send GBCS Message to the SMWAN Gateway with: Comms Hub ID = CH1 priority = 2, and endpointtype = ESME. Note: Specifying a priority of 2 indicates this is a Future Dated On Demand request. 2. If successful: a. FlexIP DNS (ipdns service) performs an address lookup for CH1. b. On receipt of the address, the SMWAN Gateway forms and dispatches an IPv6 packet (with IP traffic class set) to the FlexIP Route Engine (ipre service). c. The SMWAN Gateway informs the DSP that the request has been received (HTTP 200). d. The SMWAN Gateway records the request details into a transaction log. 3. The FlexIP Route Engine compresses the packet header and passes the packet to the IP Traffic service (flexnetapp) which maps the traffic class to a tower priority and determines the timeslot offset. The IP Traffic service then sends it to the RNI Scheduler (flexnet gwscheduler service) for transmission. 4. The RNI Scheduler sends the message packet to the FlexApp FlexRouter (flexnetapp service) which selects a route and sends the message to NC Progs (ncprogs service). The Scheduler may place the message on a queue if the system is busy. 5. NC Progs encrypts the message and sends it to the designated tower (S1600E). 6. The Tower selects a response timeslot and sends the message to Comms Hub (CH1). The Tower also sends a Transmission report back to FlexApp FlexRouter and Reliable Uplink (flexnet reliable uplink service) makes note of timeslot. Example Future Dated Response Message Flow 38

43 Example Future Dated Response Message Flow 39 FIGURE 12: FUTURE DATED RESPONSE MESSAGE FLOW 7. The FlexRouter begins monitoring for the L2 acknowledgment (L2Ack) from CH1/SDK and the Reliable Uplink begins monitoring for the timeslot response. 8. After some amount of time has passed, the meter performs the original command and then sends a message to Comms Hub 1 with low priority and message type = future dated. Uplink Flow 9. CH Host creates the response message, which: is addressed to a well-known SMWAN Gateway (using an alias address which is resolved by FlexIP Route Engine to the real IP address), specifies an IP class of service that reflects a low priority message, and specifies the UDP port on which the SMWAN Gateway listens for responses The CH Host sends the message to the SDK which compresses the IP packet headers and places the message on a low priority queue. The SDK then waits 21 hours for a poll from the tower 10.A timeslot is not assigned within the 21 hour wait window because the original timeslot has already been used. Therefore, the SDK issues a Request to Send (RTS) to acquire a response timeslot and the FlexRouter sends a request to tower to poll CH1. GBSM FLEXNET SMWAN GATEWAY

44 11.The tower returns information about the timeslot to the FlexRouter and the Reliable Uplink service begins listening for the assigned timeslot. The Tower sends a beacon to CH1 with the timeslot information. 12.The SDK sends the future dated response message over the air during the assigned timeslot and the tower (S1600E) forwards it to NC Progs. 13.NC Progs decrypts the message and forwards it to the IP Traffic service, and the Reliable Uplink service sees the message and verifies the timeslot has data. The IP Traffic service forwards the message to the FlexIP Route Engine. 14..The FlexIP Route Engine (ipre) which decompresses the packet header, forms the IPv6 packet, and sends it on to the SMWAN Gateway. 15.The SMWAN Gateway records the details of the alert message into the transaction log and forwards a Receive GBCS Message to the DSP, which forwards it to the DCC User. Example Future Dated Response Message Flow 40

45 SECTION VI: EXAMPLE POWER OUTAGE NOTIFICATION MESSAGE FLOW INTRODUCTION This section illustrates and describes the flow a power outage notification message takes as it travels from the Communications Hub (Comms Hub) through the UK FlexNet RNI to the SMWAN Gateway. The flow is described at the RNI services level, showing the message handling by key services, to aid Arqiva in understanding and investigating issues with message traffic. It is not intended that this be a complete description or to provide all information needed for troubleshooting issues, but as a first step in comprehension. SECTION OBJECTIVES Following this section, you should be able to: 1. Identify key steps a power outage notification message takes through the FlexNet system. Example Power Outage Notification Message Flow 41

46 1. ABOUT POWER OUTAGE NOTIFICATIONS Power Outage notifications are generated by Communications Hubs when they lose or gain electrical power. These unsolicited notifications do not indicate power loss or gain for any associated SMEs. 2. EXAMPLE POWER OUTAGE MESSAGE FLOW A power outage notification message is only transmitted in the uplink direction. Figure 13 illustrates the entire flow. The steps are described in the following procedure. Uplink Flow 1. A power loss or power gain is experienced at Comms Hub (CH) 1 causing the CH Host to create three notification messages. 2. CH Host sends the notification messages to the SDK at a random time within three intervals of 45 seconds, 240 seconds, and 240 seconds. The SDK sends the messages on the alarm channel to the tower. 3. The tower sends each of the notification messages to NC Progs (ncprogs), which places the notification message on the alarms JMS queue. 4. The SMWAN Gateway listens for alarms on the JMS queue, and when a notification arrives on the queue, it sends the notification to the DSP which then forwards it to the DCC User. The SMWAN Gateway records details of the notification message in the transaction log. FIGURE 13: POWER OUTAGE NOTIFICATION MESSAGE FLOW Example Power Outage Notification Message Flow 42

47 SECTION VII: EXAMPLE ROUND TRIP TEST MESSAGE FLOW INTRODUCTION This section illustrates and describes the flow a round trip test message takes as it travels from the SMWAN Gateway through the UK FlexNet RNI to an endpoint and the flow a corresponding response message takes as it returns to the SMWAN Gateway. The flow is described at the RNI services level, showing the message handling by key services, to aid Arqiva in understanding and investigating issues with message traffic. It is not intended that this be a complete description or to provide all information needed for troubleshooting issues, but as a first step in comprehension. SECTION OBJECTIVES Following this section, you should be able to: 1. Identify key steps a round trip test message takes through the FlexNet system. Example Round Trip Test Message Flow 43

48 1. ABOUT ROUND TRIP TESTS Round Trip Tests (RTTs) are used to measure the performance of the system being tested. In the case of the UK FlexNet Solution, it is measuring the time it takes to process a message in the Communications Service Provider (CSP) network. The RTT may be invoked by the DSP or from an Arqiva test head platform. It uses the same Send GBCS Message method as on demand requests, however it forms the request a bit differently as described in the example below. 2. EXAMPLE ROUND TRIP TEST MESSAGE FLOW Figure 14 illustrates the entire flow. The steps are described in the following procedures. Downlink Flow 1. The DCC User invokes a service request on the DSP and the DSP forms and sends an on-demand request using the Send GBCS Message to the SMWAN Gateway with: Comms Hub ID = CH1 priority = 4 (indicates an RTT message) command type = RTT, and endpointtype = ECHO. 2. The SMWAN Gateway forms the Fully Qualified Domain Name (FQDN) of CH1 from a template and the CH s REPID. The SMWAN Gateway discovers the IPv6 address of CH1 using a local cache or through a request to the FlexIP DNS service (ipdns). 3. The SMWAN Gateway forms and dispatches the IPv6 packet to the FlexIP Route Engine (ipre), which compresses the packet header and sends it to the RNI Scheduler (flexnet gwscheduler) for transmission. 4. The RNI Scheduler sends the message packet to the FlexRouter (flexnetapp), which fragments the 300 Byte message into multiple packets, selects a route and sends the first message fragment to NC Progs (ncprogs). 5. NC Progs encrypts the message fragment and sends it to the S1600E. The FlexRouter sends the additional message fragments to NC Progs which encrypts and sends them to the S1600E as well. 6. On transmission of the last message fragment, the Tower selects a response timeslot and sends the final message fragment to CH1. The Tower also sends a transmission report back to FlexRouter. The Reliable Uplink service (flexnet reliable uplink) begins monitoring for the timeslot. 7. The CH1 SDK un-compresses the IP packet and hands it to the CH Host layer. The ECHO service on the CH Host receives the packet and returns it immediately. Example Round Trip Test Message Flow 44

49 Example Round Trip Test Message Flow 45 FIGURE 14: ROUND TRIP TEST MESSAGE FLOW Uplink Flow 8. CH Host prepares packet for transmission to the source IP and port that sent the request, and the SDK places the message on the high priority queue. The SDK waits for assigned response timeslot. 9. The SDK sends the response message over the air during the assigned timeslot, and the tower (S1600E) forwards it to NC Progs. 10.NC Progs decrypts the message and forwards it to the IP Traffic service (flexnetapp). Reliable Uplink sees the message and verifies the timeslot has data. The IP Traffic service forwards the message to the FlexIP Route Engine. 11.The FlexIP Route Engine un-compresses the packet header, reassembles the message, forms the IPv6 packet, and forwards it to the originating source IP address and port number of the SMWAN Gateway. 12.The SMWAN Gateway sends the Receive GBCS Message response to the DSP and records details of the message in the transaction log. It also sends an acknowledgement of the original request (HTTP 200). The DSP acknowledges the message and forwards it to the DCC User. GBSM FLEXNET SMWAN GATEWAY

50 SECTION VIII: EXAMPLE DISTRIBUTE FIRMWARE IMAGE MESSAGE FLOW INTRODUCTION This section illustrates and describes the flow a Distribute Firmware Image message takes as it travels from the SMWAN Gateway through the UK FlexNet RNI to an endpoint and the flow a corresponding response message takes as it returns to the SMWAN Gateway. The flow is described at the RNI services level, showing the message handling by key services, to aid Arqiva in understanding and investigating issues with message traffic. It is not intended that this be a complete description or to provide all information needed for troubleshooting issues, but as a first step in comprehension. SECTION OBJECTIVES Following this section, you should be able to: 1. Identify key steps a distribute firmware image message takes through the FlexNet system. Example Distribute Firmware Image Message Flow 46

51 1. ABOUT DISTRIBUTE FIRMWARE IMAGE MESSAGES Distribute Firmware Image messages are created when a DCC User wants to download a firmware image to one or more Communications Hubs and/or SMEs. The Sensus UK FlexNet solution manages the distribution of the image to the Comms Hubs, but is not responsible for the installation or activation of the image itself. Note: This section outlines how a single Firmware Download (FWDL) message flows through the FlexNet system. For information on multiple FWLDL jobs that are transmitted on multiple channels, refer to Firmware Download Multiplexing education module. 2. FIRMWARE DOWNLOAD TARGET DEVICES Firmware Download requests may originate either from Arqiva or the DSP as follows: CSPN (Arqiva) FWDL request flows to Comms Hub DSP FWDL request flows to Endpoints After the request is accepted by the SMWAN Gateway, all FWDL requests are handled the same way within the Gateway and RNI. The Comms Hub sorts out which requests should be forwarded to the End Point. FIGURE 15: ARQIVA AND DSP-ORIGINATED FIRMWARE DOWNLOAD REQUESTS Example Distribute Firmware Image Message Flow 47

52 3. EXAMPLE DISTRIBUTE FIRMWARE IMAGE MESSAGE FLOW Figure 16 illustrates the entire flow. The steps are described in the following procedures. FIGURE 16: DISTRIBUTE FIRMWARE IMAGE MESSAGE FLOW Downlink Flow 1. A DCC User invokes a service request to the DSP for a firmware (FW) download. The request contains a list of BusinessTargetID (device to receive update) and CommsHubID pairs, and the desired FW image. The DSP forms and sends the Distribute Firmware Image message to the SMWAN Gateway using the list, FW image, and FW version ID. 2. The SMWAN Gateway verifies the Firmware Download (FWDL) service (flexnet fwdl) in the RNI is able to accept the request, replying with a success or failure. If the request can be supported, the SMWAN Gateway informs the DSP the request has been accepted (HTTP 200). 3. The FWDL service issues a Load Start command via the tower to CH1/SDK to receive the new firmware. The command indicates the FWDL channel for CH1 to switch to for the process, and how long to stay on that channel before returning to its standard communications channel. This step is repeated for every CH that requires the designated FW image. 4. CH1/SDK and all other CHs in job acknowledge the receipt of the Load Start command. Once every CH has responded, the FWDL service sends, through multicast messages, image blocks to all CHs identified for the job. This part of the process is performed in a carousel manner, repeating the transmission of images the designated number of times. 5. Once the carousel phase is complete, the FWDL service sends an Image Check command to a CH1 to determine if it is missing one or more image blocks. If so, the missing blocks are broadcast. 6. A second Image Check command is sent to CH1 to determine if it is still missing one or more image blocks. If so, the missing blocks are broadcast. Example Distribute Firmware Image Message Flow 48

53 7. A third image check command is sent and the process repeats for CH1 until it indicates it is no longer missing any blocks. Steps 5-7 are performed for each CH that is to receive the image. 8. Once all of CHs/SDKs respond indicating they have received the complete FW image (or the job times out) and verified that the image passes a checksum validation, each CH/ SDK sends the FW Image to the CH application layer for delivery to the target device (possibly itself or an SME). 9. FWDL service issues a FWDL report in a flat file. Note: Transfer of the FW image to the CH or other SME and the activation of the FW is then managed by Arqiva or the DSP. Note: View the status of the FWDL process through the Device Manager user interface. Example Distribute Firmware Image Message Flow 49

54 MODULE III: GBSM FLEXNET FWDL MULTIPLEXING INTRODUCTION This module reviews at a high level how FlexNet multiplexes Firmware Download (FWDL) jobs in order to ensure a high probability of success. MODULE OBJECTIVES Following this module, you should be able to: 1. Summarize the Firmware Download (FWDL) processing flow for multiplexed requests. 2. Review the specifications associated with multiplexing Firmware Download requests. 3. Explain FWDL Job Splitting. 4. Describe what SAFE is and what it does. GBSM FlexNet FWDL Multiplexing 50

55 1. FWDL MULTIPLEXING SUMMARY The figure below illustrates a multiplexed Firmware Download (FWDL) flow. FIGURE 17: MULTIPLEXED FIRMWARE DOWNLOAD FLOW 2. SPECIFICATIONS The Firmware Download service supports: Up to 200 concurrent active requests. Once this limit has been reached, further requests will be rejected until an active request completes. Each request may result in multiple jobs, some potentially queued. Up to 510,000 endpoints in a single request. Up to four requests multiplexed over a single TGB/FWDL-channel. The S1600E transceiver supports up to six FWDL channels, resulting in 24 multiplexed requests per S1600E transceiver. Multiple FWDL channels for direct Comms Hubs. I.E., not Out of Reach Devices (ORDs). A single pre-defined FWDL channel for ORDs. GBSM FlexNet FWDL Multiplexing 51