TT-eWIS/2018: Real-time messaging Jeremy Tandy (Chair)

GTS is dead, long live GTS Messaging Switching, routeing tables and bulletins will be phased out Replacement with open-standard pub/sub messaging GTS will continue – albeit with new technology GTS [governance] is exactly the same model as the Internet; each part is owned by Members, coordinated by a centralised body (i.e. WMO) … this has proven to be robust since 1970s.

Internet and IP Confusion among Members about use of “Internet” implying unrestricted access to data … need to distinguish between private network, Internet etc. IP addressing; messaging routeing delegated to network Retain existing technologies – IP can run over HF radio, VSAT etc. – to leverage previous investments (e.g. ASECNA invested £Ms in VSAT)

Requirements Fast ‘real-time’ end-to-end transfer – WIS requirement is < 2-min … fault tolerant [network] design Need to be able to replay most recent 24-hours of data (Cache function) Secure / controlled access to data-streams (not everything is public) Are concepts like ‘Global Exchange’ still relevant? out-of-band ‘back channel’ communications in emergencies – e.g. when consumer messaging networks are swamped … what about priority, safety critical communications? … this is a strong requirement … solution providers need to demonstrate that they can meet these stringent requirements

Messaging network topology Publication end-points need to be robust – operational NWP centre unlikely to want to subscribe to a feed from an automatic weather station Probably need to support proxy end-points; we know that not all Centres are able to directly connect (e.g. technical or political reasons) Likely need to support data-streams being published at multiple end- points What does the messaging ‘topology’ look like? Message hubs? Parallel running during implementation? With gateways? While the ‘sensor Web’ of connected sensors directly forming a network of data-streams looks attractive, individual sensor platforms are unlikely to be sufficiently robust. Furthermore, WIS Centres may want to apply some QC to data _before_ publishing it to the world at large… The real-time messaging solutions _may_ be pertinent to connect sensor platforms to the hub; for example- AWS IoT using MQTT

Protocol choice Can we recommend a protocol today? (no) Should we recommend a single protocol or require that messages publishers support “at least one” of a short-list? Are protocols evolving too rapidly? (see article: Does PubNub use WebSockets or some other protocol?) Is message protocol choice a candidate topic for the Furure Technlogy workshop Amazon AWS IoT solution uses MQTT

Implementation? Need a decentralised / federated approach – single monolithic message service provider unlikely to be politically acceptable Single technology solutions unlikely to work across different governance jurisdictions Example: EUMETCAST, CMACAST and NOAACAST - 3 different implementations, interoperable because they all comply with a single standard Members may collaborate regionally (similar to RMDCN approach in Europe) or coordinate at the national level Members (individually or collectively) could delegate to enterprise providers (e.g. PubNub) with multiple global PoPs to reduce latency Solution needs to be EXTENSIBLE Important to allow Members to select their own solutions – which may include enterprise messaging services such as PubNub or AWS IoT (which uses MQTT) All of these solutions need to be ‘stitched’ together into a coherent whole; creating a patchwork of solutions including national networks – perhaps operated by telecoms providers, enterprise solutions, point solutions etc. > How to register these components? > How to discover publication end-points? (via the WIS Catalogue? Which implies need for new metadata)

Industry partnership Work with industry and public sector to develop a change programme for Members driving the retirement of message switching ... migration, equipment renewal (tie in with equipment lifecycle management & existing replacement dates), technical design, open standards Most Members will only implement WIS 2.0 through replacement of equipment Leverage WMO Resource Mobilisation programme; identify donor funding sources (HydroMet Development Alliance, Green Climate Fund) to accelerate implementation Reduce risk Lower cost Could work with mobile operators to operate infrastructure - discussions w GFDRR indicate that they are “keen to move up the food chain” … talk to WMO DRR about engagement with mobile service providers; currently working w GSMA to distribute alerts over the last mile using mobile telephony