RFC 8477

Report from the Internet of Things (IoT) Semantic Interoperability (IOTSI) Workshop 2016

📅 published October 2018, from ietf

RFC 8477 💖 Report from the Internet of Things (IoT) Semantic Interoperability (IOTSI) Workshop 2016 🎀

okay bestie, this one is from the Internet Architecture Board (IAB) 👑 and it's the write-up of a workshop, not a spec you have to build from.

The deets 🧾

  • RFC number: 8477
  • Authors: J. Jimenez, H. Tschofenig, and D. Thaler ✨
  • Category: Informational 🦋
  • ISSN: 2070-1721
  • Date: October 2018 🍓
  • Obsoletes / Updates: the title block doesn't list anything for either one, so it isn't replacing or changing any other RFC 🙈

Abstract ✨

okay so this doc is a recap of the "Workshop on Internet of Things (IoT) Semantic Interoperability (IOTSI)" 🧚 which happened in Santa Clara, California on March 17-18, 2016. The big goal was to get people talking about how different companies and Standards Developing Organizations (SDOs) try to get things to interoperate at the application layer 💅 It summarizes the discussions and lists recommendations for the standards community 📝

And here's the important tea 🫖 the views and positions in here belong to the workshop participants, not necessarily to the authors or to the Internet Architecture Board (IAB), even though the IAB is the one that organized the workshop. It's a report on what was said at the workshop, so the IAB views and positions aren't the same thing 🙅‍♀️

Status of This Memo 🌸

this is not an Internet Standards Track specification 🙅‍♀️ it's just published for information 📚

It's a product of the Internet Architecture Board (IAB) and it's basically info the IAB decided was valuable enough to keep on the permanent record 🗂️ It represents the consensus of the IAB. Documents the IAB approves for publication are not candidates for any level of Internet Standard, see Section 2 of RFC 7841 💜

If you want the current status, any errata, or a way to send feedback, go to https://www.rfc-editor.org/info/rfc8477 🔗

Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved ©️

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the date this was published. Read those carefully, bestie, because they spell out your rights and restrictions for this doc 🫶

Table of Contents 🗺️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
3.  What Problems to Solve  . . . . . . . . . . . . . . . . . . .   5
4.  Translation . . . . . . . . . . . . . . . . . . . . . . . . .   7
5.  Dealing with Change . . . . . . . . . . . . . . . . . . . . .   9
6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
7.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
8.  Collaboration . . . . . . . . . . . . . . . . . . . . . . . .  11
9.  Informative References  . . . . . . . . . . . . . . . . . . .  12
Appendix A.  Program Committee  . . . . . . . . . . . . . . . . .  14
Appendix B.  Accepted Position Papers . . . . . . . . . . . . . .  14
Appendix C.  List of Participants . . . . . . . . . . . . . . . .  17
IAB Members at the Time of Approval . . . . . . . . . . . . . . .  18
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  18
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18

1. Introduction 🌈

okay so the Internet Architecture Board (IAB) runs workshops every so often 🧠 to think about long-term issues and strategies for the Internet, and to suggest where the Internet architecture should head next ✨ The topics usually need a lot of organizations and industry groups working together to fix a problem, so one big goal of these workshops is getting relevant organizations talking to each other, especially when the topic is outside the Internet Engineering Task Force (IETF) 🤝 This long-term planning is the IAB's job, and it sits alongside the day-to-day engineering the IETF working groups do 💅

Now, with the Internet of Things (IoT) growing like crazy 📈 interoperability matters more and more 😭 SDOs have put in a massive amount of work to standardize new protocols and to profile existing ones 🫶

The thing is, at the application layer and at the level of solution frameworks, interoperability isn't mature yet 🙈 Especially the work on data formats (in the form of data models and information models) hasn't been consistent across SDOs 💔

Some of the common problems are:

  • there's no encoding-independent standardization of the information, which is the so-called information model 🧩
  • data formats are tightly tied to the underlying communication architecture, like an RPC-style design or a RESTful design (where REST refers to Representational State Transfer) 🔗
  • groups build solutions that look super similar on the surface but differ slightly in the standardized outcome, and that causes interoperability problems 😵‍💫
  • finally, some groups prefer different encodings for different application-layer protocols 🎭

So the IAB decided to host a workshop to reach out to the relevant stakeholders, explore the state of the art, and figure out what's common and what's missing [IOTSIAG] [IOTSIWS] 🧐 In particular, the IAB wanted to learn about the following:

  • What is the state of the art in data and information models? What should an information model look like? 🤔
  • What is the role of formal languages, such as schema languages, in describing information and data models? 📜
  • What is the role of metadata, which is attached to data to make it self-describing? 🏷️
  • How can we achieve interoperability when different organizations, companies, and individuals develop extensions? 🧑‍🤝‍🧑
  • What is the experience with interworking various data models developed from different groups, or with data models that evolved over time? ⏳
  • What functionality should online repositories for sharing schemas have? 🗄️
  • How can existing data models be mapped against each other to offer interworking? 🗺️
  • Is there room for harmonization, or are the use cases of different groups and organizations so unique that there is no possibility for cooperation? 🥺
  • How can organizations better work together to increase awareness and information sharing? 📢

2. Terminology 💜

the first roadblock to interoperability at the data model level is that nobody has a common vocabulary to even start the convo 🙃 [RFC3444] gives a starting point by separating conceptual models for designers, called "information models," from concrete, detailed definitions for implementers, called "data models" 🎀 There are also concepts that RFC 3444 and other places don't define, like how you interact with the resources of an endpoint, which is the "interaction model" ✨ So the workshop identified three "main" common models:

Information Model 🧠 An information model defines an environment at the highest level of abstraction and expresses the desired functionality. It can be defined informally (e.g., in prose) or more formally (e.g., Unified Modeling Language (UML), Entity-Relationship Diagrams, etc.). Implementation details are hidden 🫥

Data Model 🧱 A data model defines concrete data representations at a lower level of abstraction, including implementation- and protocol-specific details. Some examples are SNMP Management Information Base (MIB) modules, World Wide Web Consortium (W3C) Thing Description (TD) Things, YANG modules, Lightweight Machine-to-Machine (LwM2M) Schemas, Open Connectivity Foundation (OCF) Schemas, and so on 📦

Interaction Model 🔁 An interaction model defines how data is accessed and retrieved from the endpoints, so it's tied to the specific communication pattern the system uses (e.g., REST methods, Publish/Subscribe operations, or RPC calls) 📞

Another issue they flagged is that some terms are overloaded with meaning, and the meaning shifts depending on context 🌀 Examples include: semantics, models, encoding, serialization format, media types, and encoding types 😩 Due to time constraints, no concrete terminology was agreed on, but work will keep going inside each organization to make various terminology documents 📚 The participants also agreed to set up a GitHub repository [IOTSIGIT] for sharing info 💻

3. What Problems to Solve ✨

okay so the participants agreed it's not just ONE problem, it's a whole range of them 😭 the workshop talked through these:

  • Formal Languages for Documentation Purposes 📚

bestie, SDOs need formal descriptions of their data and interaction models so reviewing and publishing stuff is easier. a bunch of them already have tables in the spec itself, but they also use a formal language as another way to describe objects and resources. some examples:

The Open Mobile Alliance (OMA), now OMA SpecWorks, used an XML Schema [LWM2M-Schema] to describe their object and resource definitions. the XML files of standardized objects are available for download at [OMNA].

The Bluetooth Special Interest Group (SIG) defined Generic Attribute Profile (GATT) services and characteristics for use with Bluetooth Smart/Low Energy. they're shown in tabular form on the Bluetooth SIG website [SIG] and defined as XML instance documents. 🎀

The Open Connectivity Foundation (OCF) uses JSON Schemas to formally define data models and RESTful API Modeling Language (RAML) to define interaction models. the standard files are online at <oneIoTa.org>. 🌸

The AllSeen Alliance uses AllJoyn Introspection XML to define data and interaction models in the same formal language, tailored for RPC-style interaction. the standard files are online on the AllSeen Alliance website, but both standard and vendor-defined model files can be grabbed by directly querying a device for them at runtime. main character energy 💅

The World Wide Web Consortium (W3C) uses the Resource Description Framework (RDF) to define data and interaction models using a format tailored for the web. 🕸️

The Internet Engineering Task Force (IETF) uses YANG to define data and interaction models. other SDOs may use various other formats. 🦋

  • Formal Languages for Code Generation 🧚

developers literally need code-generation tools that run on formal data and information modeling languages. for example, the AllSeen Visual Studio Plugin [AllSeen-Plugin] has a wizard that generates code from the formal description of the data model. YANG is another data modeling language you can use for code generation, and a popular tool for that is pyang [PYANG]. OpenDOF [OpenDOF] is a tool that can generate code for multiple ecosystems, which is so iconic. the use cases discussed for code generation included easing development of server-side device functionality, clients, and compliance tests. 💖

  • Debugging Support 🐛

debugging tools are needed that act as generic object browsers. they use standard data models and/or pull formal language descriptions straight from the devices themselves. one example: the nRF Bluetooth Smart sniffer from Nordic Semiconductor [nRF-Sniffer] can display the services and characteristics defined by the Bluetooth SIG. another: AllJoyn Explorer [AllJoynExplorer] can browse and interact with any resource exposed by an AllJoyn device, including standard and vendor-defined data models, by retrieving the formal descriptions from the device at runtime. the way that's so helpful 🫶

  • Translation 🔁

the working assumption is that devices need a common data model with a priori knowledge of data types and actions. BUT ngl that means every consortium/organization would try to define their own data model, and that causes a major interoperability problem. possibly a completely intractable one, given how many variations, extensions, compositions, or versioning changes each data model will go through. 😩

another potential approach is having a minimal amount of information on the device so it can do a runtime binding to a specific model. the goal is to need as little prior knowledge as possible. lowkey genius 🧠

also, gateways, bridges, and similar devices need to dynamically translate (or map) one data model to another. complexity goes up because there are multiple protocols and schemas making interoperability harder to achieve. 💀

  • Runtime Discovery 🔍

runtime discovery lets IoT devices exchange metadata about the data, potentially along with the data itself. sometimes the metadata describes the interaction model too. an example of this approach is Hypermedia as the Engine of Application State (HATEOAS) [HATEOAS]. another: all AllJoyn devices support runtime discovery through a protocol mechanism called "introspection", where the metadata is queried from the device itself [AllSeen]. 🌈

there are various models, whether deployed or just possible, for this discovery. the metadata might be extracted from a specification, looked up on a cloud repository (e.g., oneIoTa for OCF models), looked up via a vendor's site, or obtained from the device itself (like in the AllJoyn case). the relevant metadata might come from one place, or different pieces might come from different places. for example, separately getting (a) syntax information, (b) end-user descriptions in a desired language, and (c) developer-specific comments for implementers. it's giving organized chaos ✨

4. Translation 🔀

okay in an ideal world where orgs and companies all cooperate and agree on ONE data model standard, nobody needs gateways to translate from one data model to another. but that is so not reality rn. there are tons of proprietary data models on top of the ones that are already standardized. so gateways are needed to translate between data models, and that leads to (n^2)-n combinations in the worst case. yikes 😭

there are analogies with the gateways from the 1980s that translated between network layer protocols. eventually IP took over and gave us the end-to-end interoperability we needed at the network layer. unfortunately, introducing gateways means losing expressiveness because of the translation between data models. IP was so valuable in the market that the advanced features of other networking protocols became less attractive and weren't used anymore. 💔

the participants discussed an alternative they called a "red star", shown in Figure 1. here, data models get translated to a common data model in the middle. that cuts the number of translations down to 2n (in the best case). the problem, obviously, is that everyone wants their own data model to be the red star in the center. ⭐

   +-----+                                        +-----+
   |     |                                        |     |
   |     |  --                                 -- |     |
   |     |    --                             --   |     |
   +-----+      --                         --     +-----+
                  --                    ---
                    --                --
                      --            --
                        --        --
     ---                  -- A  --                  ---
    /   \                ___/ \___                 /   \
   |     | ---------------',   .'---------------  |     |
    \   /                 /. ^ .\                  \   /
     ---                 /'     '\                  ---
                        --        --
                      --            --
                    --                --
                  --                    --
                --                        --
       /\     --                            --     /\
      /  \  --                                --  /  \
     /    \                                      /    \
    /      \                                    /      \
   /--------\                                  /--------\

Figure 1: The "Red Star" in Data/Information Models

while the workshop itself wasn't the right forum to dig into the design of translation in detail, a few questions came up:

  • Do we need a "red star" that does everything, or could we design something with more restricted functionality? 🤔
  • How do we handle loss of data and functionality?
  • Should data be translated between data models, or should data models themselves be translated?
  • How can interaction models be translated? They need to be dealt with in addition to the data models.
  • Many (if not all) data and interaction models have some bizarre functionality that can't be translated easily. how can those be handled? 🙈
  • What limitations are we going to accept in these translations?

the participants also talked about when translation should happen. two use cases came up:

  • (a) Design time: A translation between data model descriptions, such as translating a YANG module to a RAML/JSON model, can be performed once, during design time. a single information model might be mapped to a number of different data models. 📐
  • (b) Run time: runtime translation of values in two standard data models can only be done algorithmically when the data model on one side is algorithmically derived from the data model on the other side. this was called a "derived model". it was discussed that runtime discovery can help with semantic translation, like when a vendor-specific data model on one side of a protocol bridge is resolved and the translator can algorithmically derive the semantically equivalent vendor-specific data model on the other side. this situation is discussed in [BridgeTaxonomy]. 🌉

the participants agreed that algorithmic translation will generally need custom code whenever you're translating to anything other than a derived model. 🛠️

and participants concluded that it's typically easier to translate data between systems that follow the same communication architecture. 💜

5. Dealing with Change 🔄

Okay so a huge chunk of the workshop was about how devices and server-side apps evolve over time, and bestie, it's giving complicated 😭 Devices and services interact, and how their relationship changes over time gets messy because each one has its own interaction model.

The participants talked through different ways to deal with change. In the most basic version, a developer reads a description of an API and implements the protocol steps by hand 🛠️. Sometimes the data or information model can be used to generate code stubs ✨. The catch is that when the API changes later, the clients have to be upgraded to the new version, and that means writing new code to meet the needs of the new API. Not iconic 💀

Here's the dream: these interactions could be made machine-understandable in the first place, so changes can happen at runtime 🦋. In that world, a machine client could discover the possible interactions with a service and adapt to changes as they happen, without anyone writing specific code to adapt to them. Main character energy 👑

The challenge is turning the human-readable specification into a machine-readable format. Machine-readable languages need a shared vocabulary to give meaning to the tags 💜.

These kinds of interactions are often based on the REST architectural style 🌸. Its principle is that a device or endpoint only needs a single entry point, and the host provides descriptions of the API in-band, using web links and forms. Obsessed with how neat this is 🫶

By defining IoT-specific relation types, it's possible to drive interactions through links instead of hard-coding URIs into a RESTful client. That makes the system flexible enough for later changes 🌈. Quick reality check: the definition of the basic hypermedia formats for IoT is still a work in progress 🚧. Some of the existing mechanisms can be reused, though, like resource discovery, forms, or links. Lowkey iykyk 🧚

6. IANA Considerations 🎀

This document has no IANA actions.

7. Security Considerations 🔐

Okay, this section is serious, so let's be serious 🥺 Two types of security considerations came up: using formal data models for security configuration, and the security of data and data models in general.

It was observed that the security assumptions and configuration (the "security model") differ from ecosystem to ecosystem today, which makes the job of a translator really hard 😩. For example, the types of security principals vary (user vs. device vs. application). So do the use of Access Control Lists (ACLs) versus capabilities, and the kinds of policies that can be expressed. Because of all that, the security model architecture generally decides where translation can happen.

One approach discussed was whether two endpoints could use some overlay security model across a translator between two ecosystems. That only works if the two endpoints agree on a common data model for their communication 🤝. Another approach was simply having a translator act as a trusted intermediary, which lets the translator translate between different data models.

Careful, this one's spicy: one suggestion was either adding metadata into the formal data model language, or having that metadata travel alongside the data values over the wire, tagging the data with privacy levels 🙈. However, sometimes even the privacy level of information can itself be sensitive. Still, it was observed that being able to dynamically learn security requirements might help provide better UIs and translators ✨.

8. Collaboration 🫶

The participants talked about how best to share information across their different organizations 💬. One idea was joint meetings. One challenge reported was that organizations weren't aware of when and where each other's meetings were scheduled. Sharing that info could help them collocate meetings better 📅. To make this happen, the participants agreed to add links to their respective meeting schedules from a common page in the IOTSI repository [IOTSIGIT].

Another challenge was that organizations didn't know how to find each other's published data models. Sharing that could make it easier to reuse the same information model 🍓. The participants discussed whether a common repository could be used by multiple organizations. The OCF's oneIoTa repository was discussed as one possibility, but it was reported that its terms of use at the time of the workshop prevented this. The OCF agreed to take that back and look at updating the terms of use so other organizations can use it, since the restriction was not the intent 👑. <schema.org> was discussed as another possibility. In the meantime, the participants agreed to add links to their respective repositories from a common page in the IOTSI repository [IOTSIGIT].

It was also agreed that the iotsi@iab.org mailing list would stay open and available for sharing information between all relevant organizations 📬💖

9. Informative References 📚

Appendix A. Program Committee 🌟

This workshop was organized by the following individuals: Jari Arkko, Ralph Droms, Jaime Jimenez, Michael Koster, Dave Thaler, and Hannes Tschofenig 💅✨

Appendix B. Accepted Position Papers 📚✨

Okay bestie, these are the position papers that got accepted for the workshop. The IoT crowd really came through with these 🦋

  • Jari Arkko, "Gadgets and Protocols Come and Go, Data Is Forever"
  • Carsten Bormann, "Noise in Specifications hurts"
  • Benoit Claise, "YANG as the Data Modelling Language in the IoT space"
  • Robert Cragie, "The ZigBee Cluster Library over IP"
  • Dee Denteneer, Michael Verschoor, and Teresa Zotti, "Fairhair: interoperable IoT services for major Building Automation and Lighting Control ecosystems"
  • Universal Devices, "Object Oriented Approach to IoT Interoperability"
  • Bryant Eastham, "Interoperability and the OpenDOF Project"
  • Stephen Farrell and Alissa Cooper, "It's Often True: Security's Ignored (IOTSI) - and Privacy too"
  • Christian Groves, Lui Yan, and Yang Weiwei, "Overview of IoT semantics landscape"
  • Ted Hardie, "Loci of Interoperability for the Internet of Things"
  • Russ Housley, "Vehicle-to-Vehicle and Vehicle-to-Infrastructure Communications"
  • Jaime Jimenez, Michael Koster, and Hannes Tschofenig, "IPSO Smart Objects"
  • David Jones, "IOTDB - interoperability Through Semantic Metastandards"
  • Sebastian Kaebisch and Darko Anicic, "Thing Description as Enabler of Semantic Interoperability on the Web of Things"
  • Achilleas Kemos, "Alliance for Internet of Things Innovation Semantic Interoperability Release 2.0, AIOTI WG03 - IoT Standardisation"
  • Ari Keraenen and Cullen Jennings, "SenML: simple building block for IoT semantic interoperability"
  • Dongmyoung Kim, Yunchul Choi, and Yonggeun Hong, "Research on Unified Data Model and Framework to Support Interoperability between IoT Applications"
  • Michael Koster, "Model-Based Hypertext Language"
  • Matthias Kovatsch, Yassin N. Hassan, and Klaus Hartke, "Semantic Interoperability Requires Self-describing Interaction Models"
  • Kai Kreuzer, "A Pragmatic Approach to Interoperability in the Internet of Things"
  • Barry Leiba, "Position Paper"
  • Marcello Lioy, "AllJoyn"
  • Kerry Lynn and Laird Dornin, "Modeling RESTful APIs with JSON Hyper-Schema"
  • Erik Nordmark, "Thoughts on IoT Semantic Interoperability: Scope of security issues"
  • Open Geospatial Consortium, "OGC SensorThings API: Communicating "Where" in the Web of Things"
  • Jean Paoli and Taqi Jaffri, "IoT Information Model Interoperability: An Open, Crowd-Sourced Approach in Three Parallel Parti"
  • Joaquin Prado, "OMA Lightweight M2M Resource Model"
  • Dave Raggett and Soumya Kanti Datta, "Input paper for IAB Semantic Interoperability Workshop"
  • Pete Rai and Stephen Tallamy, "Semantic Overlays Over Immutable Data to Facilitate Time and Context Specific Interoperability"
  • Jasper Roes and Laura Daniele, "Towards semantic interoperability in the IoT using the Smart Appliances REFerence ontology (SAREF) and its extensions"
  • Max Senges, "Submission for IAB IoT Sematic Interoperability workshop"
  • Bill Silverajan, Mert Ocak and Jaime Jimenez, "Implementation Experiences of Semantic Interoperability for RESTful Gateway Management"
  • Ned Smith, Jeff Sedayao, and Claire Vishik, "Key Semantic Interoperability Gaps in the Internet-of-Things Meta-Models"
  • Robert Sparks and Ben Campbell, "Considerations for certain IoT-based services"
  • J. Clarke Stevens, "Open Connectivity Foundation oneIoTa Tool"
  • J. Clarke Stevens and Piper Merriam, "Derived Models for Interoperability Between IoT Ecosystems"
  • Ravi Subramaniam, "Semantic Interoperability in Open Connectivity Foundation (OCF) - formerly Open Interconnect Consortium (OIC)"
  • Andrew Sullivan, "Position paper for IOTSI workshop"
  • Darshak Thakore, "IoT Security in the context of Semantic Interoperability"
  • Dave Thaler, "IoT Bridge Taxonomy"
  • Dave Thaler, "Summary of AllSeen Alliance Work Relevant to Semantic Interoperability"
  • Mark Underwood, Michael Gruninger, Leo Obrst, Ken Baclawski, Mike Bennett, Gary Berg-Cross, Torsten Hahmann, and Ram Sriram, "Internet of Things: Toward Smart Networked Systems and Societies"
  • Peter van der Stok and Andy Bierman, "YANG-Based Constrained Management Interface (CoMI)"

Appendix C. List of Participants 🎀

Here's everyone who showed up and got involved. Such a squad 🫶

  • Andy Bierman, YumaWorks
  • Carsten Bormann, Uni Bremen/TZI
  • Ben Campbell, Oracle
  • Benoit Claise, Cisco
  • Alissa Cooper, Cisco
  • Robert Cragie, ARM Limited
  • Laura Daniele, TNO
  • Bryant Eastham, OpenDOF
  • Christian Groves, Huawei
  • Ted Hardie, Google
  • Yonggeun Hong, ETRI
  • Russ Housley, Vigil Security
  • David Janes, IOTDB
  • Jaime Jimenez, Ericsson
  • Shailendra Karody, Catalina Labs
  • Ari Keraenen, Ericsson
  • Michael Koster, SmartThings
  • Matthias Kovatsch, Siemens
  • Kai Kreuzer, Deutsche Telekom
  • Barry Leiba, Huawei
  • Steve Liang, Uni Calgary
  • Marcello Lioy, Qualcomm
  • Kerry Lynn, Verizon
  • Mayan Mathen, Catalina Labs
  • Erik Nordmark, Arista
  • Jean Paoli, Microsoft
  • Joaquin Prado, OMA
  • Dave Raggett, W3C
  • Max Senges, Google
  • Ned Smith, Intel
  • Robert Sparks, Oracle
  • Ram Sriram, NIST
  • Clarke Stevens
  • Ram Subramanian, Intel
  • Andrew Sullivan, DIN
  • Darshak Thakore, CableLabs
  • Dave Thaler, Microsoft
  • Hannes Tschofenig, ARM Limited
  • Michael Verschoor, Philips Lighting

IAB Members at the Time of Approval 🌸

These are the IAB folks who were around when this got approved:

  • Jari Arkko
  • Alissa Cooper
  • Ted Hardie
  • Christian Huitema
  • Gabriel Montenegro
  • Erik Nordmark
  • Mark Nottingham
  • Melinda Shore
  • Robert Sparks
  • Jeff Tantsura
  • Martin Thomson
  • Brian Trammell
  • Suzanne Woolf

Acknowledgements 🫶

The authors want to give a huge thank-you to every paper author and participant for their contributions, and to Ericsson for hosting the workshop. Iconic behaviour from everyone 💜

Authors' Addresses 💌

Jaime Jimenez Email: jaime.jimenez@ericsson.com

Hannes Tschofenig Email: hannes.tschofenig@arm.com

Dave Thaler Email: dthaler@microsoft.com

📦 where this page comes from