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

2. 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.

3. 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)

4. 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

5. 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

6. 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

7. 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)

8. 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