RFC 9938

A Framework for the Deterministic Networking (DetNet) Controller Plane

📅 published March 2026, from ietf

RFC 9938: A Framework for the Deterministic Networking (DetNet) Controller Plane 🎀

Okay bestie, this is RFC 9938, an IETF doc published in March 2026 🌸 It's Informational, so it's guidance and not a Standards Track spec. ISSN 2070-1721. The authors are A. Malis (listed as Independent), X. Geng, Ed. (Huawei, with "Ed." meaning editor), M. (Guoyi) Chen (Huawei), B. Varga (Ericsson), and CJ. Bernardos (UC3M). The title block doesn't list any RFCs it obsoletes or updates ✨

Abstract ✨

Okay so the abstract is giving overview 💅 It's a framework overview for the DetNet Controller Plane. It goes through the concepts and requirements for that plane, which could be the basis for a future solution spec 🦋

Status of This Memo 📜

This is not an Internet Standards Track spec. It's published for informational purposes 💜

This is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 if you're curious 🙈

For the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9938 🌈

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

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as in effect on the date of publication. Please read those carefully, because they spell out your rights and restrictions for this doc 📚 Code Components pulled out of this doc must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Revised BSD License 🍓

Table of Contents 🗂️

1.  Introduction
2.  DetNet Controller Plane Requirements
  2.1.  DetNet Control Plane Requirements
  2.2.  DetNet Management Plane Requirements
  2.3.  Requirements for Both Planes
3.  DetNet Control Plane Architecture
  3.1.  Distributed Control Plane and Signaling Protocols
  3.2.  Fully Centralized Control Plane
  3.3.  Hybrid Control Plane (Partly Centralized and Partly
        Distributed)
4.  DetNet Control Plane for DetNet Mechanisms
  4.1.  Explicit Paths
  4.2.  Resource Reservation
  4.3.  PREOF Support
  4.4.  Data-Plane-Specific Considerations
    4.4.1.  DetNet in an MPLS Domain
    4.4.2.  DetNet in an IP Domain
    4.4.3.  DetNet in a Segment Routing Domain
  4.5.  Encapsulation and Metadata Support
5.  Management Plane Overview
  5.1.  DetNet Operations, Administration, and Maintenance (OAM)
    5.1.1.  OAM for Performance Monitoring (PM)
    5.1.2.  OAM for Connectivity and Fault Management (CFM)
6.  Multi-Domain Aspects
7.  IANA Considerations
8.  Security Considerations
9.  References
  9.1.  Normative References
  9.2.  Informative References
Acknowledgments
Contributors
Authors' Addresses

1. Introduction ✨

Deterministic Networking (DetNet) gives you the ability to carry specified unicast or multicast data flows for real-time apps, with extremely low packet loss rates and assured maximum end-to-end delivery latency 🔥 The general background and concepts are in [RFC8655], so start there if you're new 🦋

The DetNet data plane is defined in the DetNet data plane framework [RFC8938]. It gets more detail in the associated DetNet MPLS [RFC8964], the DetNet IP [RFC8939], and other data plane specs [RFC9023] [RFC9024] [RFC9025] [RFC9037] [RFC9056] 💅

Here's the tea 🫖 In the overall DetNet architecture, the controller plane covers what are usually treated as separate control and management planes (see Section 4.4.2 of [RFC8655]). The management plane is mainly about fault management, configuration management, and performance management. Accounting management and security management are sometimes considered part of it too (Section 4.2 of [RFC6632]), but they're out of scope for this doc 🙈 The control plane, meanwhile, is mainly responsible for instantiating and maintaining flows, MPLS label allocation and distribution, and active in-band or out-of-band signaling to support DetNet functions. In the DetNet architecture, all of that gets combined into a single controller plane. For more, see Section 4.4.2 of [RFC8655] and the aggregation of control and management planes in [RFC7426] 💖

The DetNet architecture and data plane docs are mostly about data plane operations, but they do include some requirements and considerations for the functions you'd need to automate DetNet service provisioning and monitoring through a DetNet Controller Plane (for example, see Section 4 of [RFC8938]) 🧚 This doc gathers all of those into one place. It extends the discussion of how different possible DetNet Controller Plane architectures could meet those requirements. It does not give protocol details for a DetNet Controller Plane solution, since those will be the subject of later documents 🌸 So this doc should be considered as the authoritative reference to be considered if/when protocol work on the DetNet Controller Plane starts 👑

2. DetNet Controller Plane Requirements 📋

Other DetNet docs, including [RFC8655], [RFC8938], [RFC9551], and [RFC9055], among others, contain requirements for the controller plane. For convenience, they've been compiled here. The requirements are organized into three groups: 1) requirements mainly for the control plane, 2) requirements mainly for the management plane, and 3) requirements for both planes. Security requirements for the DetNet Controller Plane are discussed in [RFC9055], and a summary of them is in Section 2.3 🔐 Where it helps, the doc where each requirement first shows up is cited, for clarity ✨

2.1. DetNet Control Plane Requirements 🎀

The primary requirements for the DetNet Control Plane are:

  • Support the dynamic instantiation, modification, and deletion of DetNet flows. This may include some or all of explicit path determination, link bandwidth reservations, restriction of flows to specific links (e.g., IEEE 802.1 Time-Sensitive Networking (TSN) links), node buffer and other resource reservations, specification of required queuing disciplines along the path, the ability to manage bidirectional flows, etc., as needed for a flow [RFC8938].
  • Support DetNet flow aggregation and de-aggregation by being able to dynamically create and delete flow aggregates (FAs) and modify existing FAs by adding or deleting participating flows [RFC8938].
  • Allow flow instantiation requests to come from an end application (via an Application Programming Interface (API), via static provisioning, or via a dynamic control plane such as a Software-Defined Networking (SDN) controller or distributed signaling protocols). See Section 3 for more on these options.
  • In the case of the DetNet MPLS data plane, manage DetNet Service Label (S-Label), Forwarding Label (F-Label), and Aggregation Label (A-Label) [RFC8964] allocation and distribution [RFC8938].
  • Also in the case of the DetNet MPLS data plane, support the DetNet service sub-layer, which provides DetNet service functions such as protection and reordering through the use of Packet Replication, Elimination, and Ordering Functions (PREOF) [RFC8655].
  • Support the queue control techniques defined in [RFC8655], Section 4.5 and [RFC9320] that require time synchronization among the network data plane nodes.
  • Advertise static and dynamic node and link characteristics, such as capabilities and adjacencies to other network nodes (for dynamic signaling approaches) or to network controllers (for centralized approaches) [RFC8938].
  • Scale to handle the number of DetNet flows expected in a domain (which may require per-flow signaling or provisioning) [RFC8938].
  • Provision flow identification information at each of the nodes along the path. Flow identification may differ depending on the location in the network and the DetNet functionality (e.g., transit node vs. relay node) [RFC8938].

2.2. DetNet Management Plane Requirements 🔍

The primary requirements for the DetNet management plane are:

  • Monitor the performance of DetNet flows and nodes to make sure they're meeting required objectives, both proactively and on demand [RFC9551].
  • Support DetNet flow continuity check and connectivity verification functions [RFC9551].
  • Support testing and monitoring of packet replication, duplicate elimination, and packet ordering functionality in the DetNet domain [RFC9551].

2.3. Requirements for Both Planes 💜

The following requirements apply to both the DetNet control and management planes:

  • Operate in a converged network domain that contains both DetNet and non-DetNet flows [RFC8655].
  • Adapt to DetNet domain topology changes such as link or node failures (fault recovery/restoration), additions, and removals [RFC8655].

On top of those, the DetNet Controller Plane should also satisfy security requirements derived from [RFC9055], which defines the security framework for DetNet. These are the especially relevant ones 🚨

  • Integrity and authenticity of control/signaling packets: The controller plane should ensure that signaling and control messages cannot be modified or injected by unauthorized entities, and should prevent spoofing and segmentation attacks.
  • Protection against controller compromise: Mechanisms should exist to verify the legitimacy of controllers and to prevent unauthorized components from impersonating them.
  • System-wide security design: The architecture must account for the possibility of compromised nodes or controllers, ensuring resilience so that the failure or subversion of a single component does not cause catastrophic impact 💀
  • Timely delivery of control plane messages: The controller plane should ensure that control and signaling messages are delivered without undue delay, so DetNet services aren't disrupted and resources don't leak 🫶

3. DetNet Control Plane Architecture ✨

Okay so, like we said in the Introduction, the DetNet Control Plane is the one in charge of setting up and looking after flows 💖. It also hands out flow-related info (like an MPLS label, e.g., 🏷️) and sends that info around, either in-band or out-of-band, to keep everything running 🧚. It's lowkey the backbone of the whole vibe 💅.

There are three types of DetNet Control Plane architecture, and they're all giving different energy 🌈:

  • 1) a fully distributed control plane that uses dynamic signaling protocols 🦋
  • 2) a fully centralized, SDN-like control plane 👑
  • 3) a hybrid control plane that mixes distributed protocols with centralized control 🫶

This section walks through the different information exchanges between entities in the network for each of these, plus the pros and cons of each one. Spoiler: nothing is perfect, bestie 💀.

The examples coming up are just possible mechanisms that could be used in each architecture. They are not meant to be exhaustive, and they don't rule out any other mechanism that could be used in place of the ones shown 🌸.

3.1. Distributed Control Plane and Signaling Protocols

In a fully distributed setup, the User-Network Interface (UNI) information gets sent over a DetNet UNI protocol from the user side to the network side 📨. After that, the UNI and network configuration info spreads through the network using distributed control plane signaling protocols 🌊. Such a DetNet UNI protocol is not necessary when the end systems are DetNet capable ✨.

Let's take an RSVP-TE [RFC3209] MPLS network as an example, where the end systems are not part of the DetNet domain 🎀:

  1. Network nodes collect topology information and the DetNet capabilities of the network nodes through IGP 🗺️.
  2. The ingress edge node receives a flow establishment request from the UNI and calculates one or more valid paths 🧮.
  3. The ingress node sends a PATH message with an explicit route through RSVP-TE 📤. After receiving the PATH message, the egress edge node sends a RESV message with the distributed label and the resource reservation request 📥.

In this example, both the IGP and RSVP-TE may require extensions for DetNet 🔧.

3.2. Fully Centralized Control Plane

In the fully centralized setup (for example, using an SDN controller 🎛️), both flow and UNI information can be transmitted from a centralized user controller, or from other applications, via an API or northbound interface, to a centralized controller 🛰️. The controller then configures the network nodes for DetNet flows using a protocol such as NETCONF [RFC6241], YANG [RFC6020] [RFC7950], DetNet YANG [RFC9633], or a PCE-based central controller (PCE-CC) [RFC8283] 🧠.

Take this as an example 👀:

  1. A centralized controller collects topology information and the DetNet capabilities of the network nodes via NETCONF/YANG 📚.
  2. The controller receives a flow establishment request from a UNI and calculates one or more valid paths through the network 🧩.
  3. The controller picks the optimal path and configures the devices along that path for DetNet flow transmission via PCE-CC 🎯.

The protocols in the example above may require extensions for DetNet 💜.

3.3. Hybrid Control Plane (Partly Centralized and Partly Distributed)

In the hybrid model, the controller and the control plane protocols team up to provide DetNet services 🤝, and there are a bunch of possible combinations 🍓.

In the following case, RSVP-TE and a controller are used together:

  1. A controller collects topology information and the DetNet capabilities of the network nodes via an IGP and/or the Border Gateway Protocol - Link State (BGP-LS) [RFC9552] 🗂️.
  2. A controller receives a flow establishment request through an API and calculates one or more valid paths through the network 📬.
  3. Based on that calculation, the controller distributes flow path information to the ingress edge node, and configures the network nodes along the path with the DetNet information they need (e.g., for replication/duplicate elimination) 🔁.
  4. Using RSVP-TE, the ingress edge node sends a PATH message with an explicit route. After receiving the PATH message, the egress edge node sends a RESV message with the distributed label and the resource reservation request 🎶.

There are many other variations that could be included in a hybrid control plane 🌈. The requested DetNet extensions for a protocol in each possible case are left for future work 🔮.

4. DetNet Control Plane for DetNet Mechanisms 🦄

This section talks about the control plane features people have requested for DetNet mechanisms defined in [RFC8655], including PREOF 📋. Different DetNet services may implement any or all of these, depending on their requirements 💅.

4.1. Explicit Paths

Explicit paths are required in DetNet to give a stable forwarding service and make sure the DetNet service isn't affected when the network topology changes 🛤️. These are the control plane features needed to make explicit paths work in DetNet:

  • Path computation: DetNet explicit paths need to meet the application's Service Level Agreement (SLA) requirements, which include bandwidth, maximum end-to-end delay, maximum end-to-end delay variation, maximum loss ratio, and so on 📏. In a distributed network, an IGP with Constrained Shortest Path First (CSPF) may be used to compute a set of feasible paths for a DetNet service 🧭. In a centralized network, the controller can compute paths that satisfy the DetNet requirements, using the network information collected from the DetNet domain 🎛️.
  • Path establishment: The computed path for the DetNet service has to be sent, configured, or signaled to the network device, so the corresponding DetNet flow can pass through the network domain along the specified path 🚀.

4.2. Resource Reservation

DetNet flows are supposed to be protected from congestion 🛡️, so reserving enough resources for a DetNet service can protect that service from congestion 💖. There are several types of network resources that can be allocated to DetNet flows, such as packet processing resources, buffer resources, and the bandwidth of the output port 📦. The network resources a specific DetNet service requests are determined by its SLA requirements and the network's capability 📊.

  • Resource Allocation: Port bandwidth is one of the basic attributes of a network device, and it's easy to get or calculate 🔢. In current traffic engineering implementations, network resource allocation is basically the same thing as bandwidth allocation 🚦. A DetNet flow is described by a traffic specification, defined in [RFC9016], with attributes such as Interval, MaxPacketsPerInterval, and MaxPayloadSize 📐. The traffic specification describes the worst case, not the average case, so that enough bandwidth and buffering resources get reserved to satisfy it 😤. But for DetNet, resource allocation is more than simple bandwidth reservation 🙈. For example, allocating buffers and the required queuing disciplines during forwarding may also be needed 🧃. Resources also have to be ensured for running DetNet service sub-layer functions on the node, like protection and reordering using PREOF 🛟.
  • Device configuration with or without flow discrimination: The resource allocation can be guaranteed through device configuration ⚙️. For example, an output port bandwidth reservation can be configured as a parameter of queue management and the port scheduling algorithm 🧁. When DetNet flows are aggregated, a group of DetNet flows shares the allocated resource on the network device 🫧. When DetNet flows are treated independently, the device should maintain a mapping between each DetNet flow and its corresponding resources 🗺️.

4.3. PREOF Support

DetNet path redundancy is supported via Packet Replication, Elimination, and Ordering Functions (PREOF) 🪞. A DetNet flow gets replicated and forwarded over multiple network paths, so packet loss caused by device or link failures is avoided 🌈. In general, the current control plane mechanisms that can be used to establish an explicit path, whether distributed or centralized, support point-to-point (P2P) and point-to-multipoint (P2MP) path establishment 🛣️. PREOF, though, needs the ability to compute and establish a set of multiple paths (for example, multiple Label Switched Path (LSP) segments in an MPLS network) from the point(s) of packet replication to the point(s) of packet merging and ordering 🧵. Mapping DetNet flows, or DetNet member flows, to explicit path segments also has to be ensured 🔗. Protocol extensions will be required to support these new features 🛠️. Terminology will also be needed to refer to this coordinated set of path segments, such as an "LSP graph" for the DetNet MPLS data plane 🕸️.

4.4. Data-Plane-Specific Considerations

4.4.1. DetNet in an MPLS Domain

For this document, "legacy MPLS" means MPLS without Segment Routing (see Section 4.4.3 for a discussion of MPLS with Segment Routing) or MPLS Transport Profile (MPLS-TP) [RFC5960] 🧸.

In legacy MPLS domains, a dynamic control plane using distributed signaling protocols is typically used to distribute the MPLS labels that forward MPLS packets 📡. The dynamic signaling protocols most commonly used for label distribution are LDP [RFC5036], RSVP-TE [RFC4875], and BGP [RFC8277] (which enables BGP-based MPLS Layer 3 VPNs [RFC4384], Layer 2 VPNs [RFC4664], and EVPNs [RFC7432]) 💜.

Any of these protocols could be used to distribute DetNet Service Labels (S-Labels) and Aggregation Labels (A-Labels) [RFC8964] 🏷️. As discussed in [RFC8938], S-Labels are similar to other MPLS service labels, like pseudowire, L3 VPN, and L2 VPN labels, and could be distributed in a similar way, such as through targeted LDP or BGP 🎀. If these were used for DetNet, they would need extensions to support DetNet-specific features like PREOF, aggregation (A-Labels), node resource allocation, and queue placement 🧩.

4.4.2. DetNet in an IP Domain

For this document, "legacy IP" means IP without Segment Routing (see Section 4.4.3 for a discussion of IP with Segment Routing) 🌐. Worth noting: a DetNet IP data plane [RFC8939] is simpler than a DetNet MPLS data plane [RFC8964] and doesn't support PREOF, so only one path per flow or flow aggregate is required 🦋. That means possible protocol extensions are expected to be limited, e.g., to existing IP routing protocols 🫶.

4.4.3. DetNet in a Segment Routing Domain 🦋

okay bestie, so Segment Routing [RFC8402] is giving scalable 💅. It's a way of building network domains where the path is spelled out right inside the packet headers (that's the explicit source routing part ✨), and it's paired with centralized network control that does the path computing 🧠. The forwarding paths get handed out, along with their policies, to the network edge nodes so they can stick them into packet headers 🎀.

Why is this so iconic? It cuts down on the signaling traffic from distributed signaling protocols like RSVP-TE 📉, and core nodes need way less state than they would with legacy MPLS and IP routing 😭. The state is now living in the packets instead of in the routers, so the routers aren't stuck carrying it all. This could be super useful for DetNet 🌸, where a huge number of flows are expected to go through one network domain. Otherwise, every single flow would need state installed at every node it crosses, and nobody has time for that 💀.

Note that the DetNet MPLS and IP data planes described in [RFC8964] and [RFC8939] were built to be compatible with both kinds of Segment Routing: Segment Routing over MPLS (SR-MPLS) [RFC8660] and Segment Routing over IPv6 (SRv6) [RFC8754] [RFC8986] 🌈.

4.5. Encapsulation and Metadata Support 🧚

okay so to manage DetNet flows effectively, the controller plane is going to need a super clear picture of the encapsulation and metadata capabilities of the underlying network nodes 🔍. That means it needs a control mechanism that can discover, configure, and manage these parameters for each flow. No skipping this part, bestie 🫶.

The controller plane needs to understand and manage those encapsulation and metadata capabilities so it can provision DetNet flows properly ✨. This might involve a discovery phase, where the controller finds out which encapsulation types (e.g., MPLS, IP) and metadata schemes (e.g., sequencing, timestamping) each node supports 🕵️‍♀️. Once discovery is done, the controller might tell nodes exactly which encapsulation and companion metadata to apply for a given flow. This is how DetNet packets get handled consistently across the whole network 💖. For example, the controller might tell a node to use an MPLS header and add a sequence number for a particular flow 🍓.

5. Management Plane Overview 🌈

The management plane is the part that lets you statically provision network nodes, and it also lets you use Operations, Administration, and Maintenance (OAM) to keep an eye on DetNet performance and catch outages or other issues at the DetNet layer 👀. Main character monitoring energy 👑.

5.1. DetNet Operations, Administration, and Maintenance (OAM) 🔧

This document covers the general considerations for OAM 📝.

5.1.1. OAM for Performance Monitoring (PM) 📊

5.1.1.1. Active PM 💉

Active PM works by injecting OAM packets into the network, then measuring how those OAM packets perform so it can estimate the network's performance 🧪. The catch is that adding extra traffic can affect the delay and throughput performance of the network 😬. For that reason, Active PM is not recommended for use in operational DetNet domains. It is still a useful test tool, though, when you're commissioning a new network or troubleshooting something 🛠️.

5.1.1.2. Passive PM 🦋

Passive PM, like In Situ Operations, Administration, and Maintenance (IOAM) [RFC9197], watches the actual service traffic in a network domain to measure its performance, and it doesn't have a detrimental effect on the network 🙌. Compared to Active PM, Passive PM is much preferred for use in DetNet domains. Chef's kiss 💋.

5.1.2. OAM for Connectivity and Fault Management (CFM) 🔗

The detailed requirements for CFM in a DetNet IP domain and a DetNet MPLS domain are defined in [RFC9551], [RFC9634], and [RFC9546], respectively 📚.

6. Multi-Domain Aspects 🌍

When there are multiple domains involved, multiple Controller Plane Functions (CPFs) have to work together to carry out the requests received from the Flow Management Entity (FME) [RFC8655]. The end result is per-flow, per-hop behaviors installed in the DetNet nodes for each individual flow 🤝. Adding multi-domain support might require some support at the CPF 🧩. For example, CPFs of different domains (e.g., PCEs) need to discover each other, then authenticate and negotiate per-hop behaviors 🔐.

In the case of wireless domains, per-domain functions specific to Reliable and Available Wireless (RAW) [RAW-ARCH] also have to be considered 📡. Things like Point of Local Repairs (PLRs) are on the list, and they need to be considered in addition to the PCEs 📋. Depending on the multi-domain support the application plane provides, the controller plane might get relieved of some responsibilities. For example, if the application plane takes care of splitting what each domain needs to provide, the controller plane gets a little breather 😌.

7. IANA Considerations 🎀

This document has no IANA actions ✨.

8. Security Considerations 🔐

⚠️ Serious security talk incoming, bestie. Read this one carefully 🚨.

This document provides a framework for the DetNet Controller Plane and does not include any protocol specifications 📖. That means there's no protocol-level security behavior specified here. Any future specification that is defined to support the DetNet Controller Plane is expected to include the appropriate security considerations 🛡️. For the overall security considerations of DetNet, see [RFC8655] and [RFC9055] 🔒.

9. References 📚

9.1. Normative References 💜

   [RFC8655]  Finn, N., Thubert, P., Varga, B., and J. Farkas,
              "Deterministic Networking Architecture", RFC 8655,
              DOI 10.17487/RFC8655, October 2019,
              <https://www.rfc-editor.org/info/rfc8655>.

   [RFC8938]  Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S.
              Bryant, "Deterministic Networking (DetNet) Data Plane
              Framework", RFC 8938, DOI 10.17487/RFC8938, November 2020,
              <https://www.rfc-editor.org/info/rfc8938>.

   [RFC9016]  Varga, B., Farkas, J., Cummings, R., Jiang, Y., and D.
              Fedyk, "Flow and Service Information Model for
              Deterministic Networking (DetNet)", RFC 9016,
              DOI 10.17487/RFC9016, March 2021,
              <https://www.rfc-editor.org/info/rfc9016>.

   [RFC9055]  Grossman, E., Ed., Mizrahi, T., and A. Hacker,
              "Deterministic Networking (DetNet) Security
              Considerations", RFC 9055, DOI 10.17487/RFC9055, June
              2021, <https://www.rfc-editor.org/info/rfc9055>.

   [RFC9551]  Mirsky, G., Theoleyre, F., Papadopoulos, G., Bernardos,
              CJ., Varga, B., and J. Farkas, "Framework of Operations,
              Administration, and Maintenance (OAM) for Deterministic
              Networking (DetNet)", RFC 9551, DOI 10.17487/RFC9551,
              March 2024, <https://www.rfc-editor.org/info/rfc9551>.

9.2. Informative References

Okay so these are the informative ones, bestie 🦋 They're the background reading that backs up everything above 💅

Acknowledgments 💖

Huge thanks to Jim Guichard, Donald Eastlake 3rd, and Stewart Bryant for reviewing and commenting on this work 🫶

The authors also want to thank Deb Cooley, Mike Bishop, Mohamed Boucadair, Gorry Fairhurst, and Dave Thaler for their comments during the different directorate and IESG reviews. You all ate 👑

Contributors 🧚

Fengwei Qin
China Mobile
Email: qinfengwei@chinamobile.com

Authors' Addresses 🦋

Andrew G. Malis
Independent
Email: agmalis@gmail.com

Xuesong Geng (editor)
Huawei
Email: gengxuesong@huawei.com

Mach (Guoyi)Chen
Huawei
Email: mach.chen@huawei.com

Balazs Varga
Ericsson
Email: balazs.a.varga@ericsson.com

Carlos J. Bernardos
Universidad Carlos III de Madrid
Av. Universidad, 30
28911 Leganes, Madrid
Spain
Phone: +34 91624 6236
Email: cjbc@it.uc3m.es
URI:   http://www.it.uc3m.es/cjbc/
📦 where this page comes from