Applicability of GMPLS for fine grain Optical Transport Network
draft-lin-ccamp-gmpls-fgotn-applicability-00
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Yi Lin , Liuyan Han , Yang Zhao , Raul Munoz | ||
| Last updated | 2024-03-04 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-lin-ccamp-gmpls-fgotn-applicability-00
CCAMP Working Group Y. Lin
Internet Draft Huawei Technologies
L. Han
Y. Zhao
China Mobile
R. Munoz
CTTC
Category: Informational
Expires: September 05, 2024 March 04, 2024
Applicability of GMPLS for fine grain Optical Transport Network
draft-lin-ccamp-gmpls-fgotn-applicability-00
Abstract
ITU-T Recommendation G.709/Y.1331 Edition 6.5 [G709-E6.5] introduced
new fine grain OTN (fgOTN) for the efficient transmission of sub-1G
client signals.
This document reviews the fgOTN control plane requirements, examines
the applicability of using existing GMPLS control plane for fgOTN, and
provides the standard gap analysis and considerations on GMPLS
extensions.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 05, 2024.
Lin, et al. Expires September 2024 [Page 1]
Internet-Draft GMPLS fgOTN Applicability March 2024
Copyright Notice
Copyright (c) 2024 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction .................................................. 3
2. G.709 Optical Transport Network Overview ...................... 3
2.1. fgOTN Mapping and Multiplexing Architecture .............. 4
2.1.1. fgODUflex(p) into ODUj(fgTS) or ODUflex(fgTS,n)
Multiplexing ............................................... 5
2.1.2. ODUj(fgTS) or ODUflex(fgTS,n) into ODUk Multiplexing 5
2.2. fgOTN Connection Model ................................... 5
2.3. fgOTN Use Cases .......................................... 7
2.3.1. Point-to-Point (P2P) Private Line Service............ 7
2.3.2. Multi-Point-to-Multi-Point (MP2MP) Cloud Access ..... 8
3. General fgOTN Control Consideration ........................... 8
3.1. Signal Type .............................................. 8
3.2. fgOTN Label .............................................. 9
4. fgOTN Connection Control Consideration ........................ 9
4.1. Connection Hierarchy ..................................... 9
4.2. Hitless Resizing ......................................... 9
4.3. Scalability Consideration ............................... 10
5. fgOTN Service Control Consideration .......................... 10
6. fgOTN Routing Consideration .................................. 12
6.1. fgOTN Resource Distribution ............................. 12
6.2. Scalability Consideration ............................... 12
7. fgOTN Link Management Consideration .......................... 12
8. Manageability Considerations ................................. 12
9. Security Considerations ...................................... 13
10. IANA Considerations.......................................... 13
11. References .................................................. 13
11.1. Normative References ................................... 13
11.2. Informative References ................................. 13
12. Authors' Addresses .......................................... 14
Lin, et al. Expires September 2024 [Page 2]
Internet-Draft GMPLS fgOTN Applicability March 2024
1. Introduction
Optical Transport Networks (OTN) is a mainstream layer 1 technology
for the transport network. Over the years, it has continued to
evolve, to improve its transport functions for the emerging
requirements.
OTN control plane capabilities are also introduced and improved
according to the evolution of OTN technologies. The OTN control
plane brings benefits to operators, including improving OTN network
resiliency and resource usage efficiency. Generalized Multi-Protocol
Label Switching (GMPLS) [RFC3945], as a control plane technology,
support different classes of interfaces and switching capabilities
including OTN.
In the latest version of OTN, ITU-T G.709/Y.1331 Edition 6.5 [G709-
E6.5], the fine grain OTN (fgOTN) is introduced for the efficient
transmission of low rate signals (e.g., sub-1G).
This document reviews the latest OTN standard technologies
(especially the fgOTN) and their requirements to the OTN control
plane.
This document also examines the applicability of using existing
GMPLS control plane for fgOTN, and provides the standard gap
analysis and considerations on GMPLS extensions.
2. G.709 Optical Transport Network Overview
Recommendation ITU-T G.709/Y.1331 [G709-E6.5] defines the
requirements for the optical transport network (OTN) interface
signals of the optical transport network.
The most important new feature introduced by G.709/Y.1331 [G709-
E6.5], compared with the previous editions of G.709 series
standards, is the introduction of fine grain OTN (fgOTN) for the
efficient transmission of low rate signals (e.g., sub-1G). This can
be an alternative to the existing SDH networks, which phases out in
operators' networks.
Recommendation ITU-T G.709.20 [G709.20] provides an overview of
functions provided by the fgOTN layer network.
The main functional requirements of fgOTN, described in G.709.20
[G709.20], include:
- Support TDM hard isolation with deterministic latency to
guaranteed performance of OTN networks.
Lin, et al. Expires September 2024 [Page 3]
Internet-Draft GMPLS fgOTN Applicability March 2024
- Support mapping packet services and Constant Bit Rate (CBR)
services into fgODUflex path layer.
- Support multiplexing multiple fgODUflex signals into
ODU0/1/2/flex(fgTS,n) (where n = 3 to 7).
- Support fgODUflex SNCP 1+1 protection.
- Support timing transparent transport for CBR services.
- Support fgODUflex hitless bandwidth adjustment function for packet
services.
The detail definition of fgOTN, including frame format, mapping of
client signals into fgOTN and mapping of fgOTN into ODUk, is
described in G.709 [G709-E6.5].
2.1. fgOTN Mapping and Multiplexing Architecture
fgOTN layer network is a service layer network of the OTN ODU layer
network. Figure 1 shows the overview of fgOTN mapping and
multiplexing architecture.
p=1~119
+------+ +------------+ +---------------+ +------+
|Client|-->|fgODUflex(p)|-->| | | |
+------+ +------------+ |ODUflex(fgTS,n)|-->| |
... --> ...... -->| n=3~7 | | |
+---------------+ | |
+------+ +------------+ +---------------+ | |
|Client|-->|fgODUflex(p)|-->| | | |
+------+ +------------+ | ODU0(fgTS) |-->| |
... --> ...... -->| | | |
+---------------+ | |
+------+ +------------+ +---------------+ | |
|Client|-->|fgODUflex(p)|-->| | | |
+------+ +------------+ | ODU1(fgTS) |-->| ODUk |
... --> ...... -->| | | |
+---------------+ | |
+------+ +------------+ +---------------+ | |
|Client|-->|fgODUflex(p)|-->| | | |
+------+ +------------+ | ODU2(fgTS) |-->| |
... --> ...... -->| | | |
+---------------+ | |
| |
+---------------+ | |
+------+ | | | |
|Client|------------------->| ODUj |-->| |
+------+ | | | |
+---------------+ +------+
Lin, et al. Expires September 2024 [Page 4]
Internet-Draft GMPLS fgOTN Applicability March 2024
Figure 1: fgOTN mapping and multiplexing architecture
Note that, similar to ODUj into OTUj mapping, the ODUj(fgTS)
(j=0,1,2) may also be mapped into OTUj directly, which is not shown
in Figure 1 for simplicity.
2.1.1. fgODUflex(p) into ODUj(fgTS) or ODUflex(fgTS,n) Multiplexing
The ODUj(fgTS) (j=0,1,2) and the ODUflex(fgTS,n) are the new
containers used for fgODUflex(p), which contain multiple fine grain
Tributary Slots (fgTSs) with an approximate bit rate of 10 Mbit/s.
More specifically:
- The ODU0(fgTS) contains 119 fine grain Tributary Slots (fgTSs),
and the bit rate of each fgTS is approximately 10411 kbit/s.
- The ODU1(fgTS) contains 238 fgTSs, and the bit rate of each fgTS
is approximately 10455 kbit/s.
- The ODU2(fgTS) contains 952 fgTSs, and the bit rate of each fgTS
is approximately 10499 kbit/s.
- The ODUflex(fgTS,n) (3<=n<=7) contains n*119 fgTSs, and the bit
rate of each fgTS is approximately 10411 kbit/s.
When multiplexing an fgODUflex(p) into an ODUj(fgTS) (j=0,1,2) or an
ODUflex(fgTS,n), the fgODUflex(p) occupies p fgTSs of the ODUj(fgTS)
or ODUflex(fgTS,n), where p is an integer that less than or equal to
119.
Packet or CBR client signals which are less than 1 Gbit/s can be
carried by an fgODUflex(p) to improve the efficiency of OTN
bandwidth utilization.
2.1.2. ODUj(fgTS) or ODUflex(fgTS,n) into ODUk Multiplexing
The ODUj(fgTS) or ODUflex(fgTS,n) into ODUk multiplexing is similar
to the ODUj (including ODUflex) into ODUk multiplexing. Traditional
ODUj and ODUj(fgTS) / ODUflex(fgTS,n) can be multiplexed into the
same ODUk.
2.2. fgOTN Connection Model
Figure 2 shows a simple example about the fgOTN connection model.
Lin, et al. Expires September 2024 [Page 5]
Internet-Draft GMPLS fgOTN Applicability March 2024
+-----+ ODUk +-----+ ODUk +-----+ ODUk +-----+ ODUk +-----+
| | Link | | Link | | Link | | Link | |
| A |======| B |======| C |======| D |======| E |
| | | | | | | | | |
+-----+ +-----+ +-----+ +-----+ +-----+
Conn#1 Conn#2
**************************** ****************************
ODUj(fgTS) or ODUflex(fgTS,n) ODUj(fgTS) or ODUflex(fgTS,n)
------------------------------------------------------------
Conn#3: fgODUflex(p)
Figure 2: example of fgOTN connection model
In this example, there are five OTN nodes which are interconnected
by ODUk links. Two ODUj(fgTS) or ODUflex(fgTS,n) connections are
created:
- Conn#1: ODUj(fgTS) or ODUflex(fgTS,n), A-B-C
- Conn#2: ODUj(fgTS) or ODUflex(fgTS,n), C-D-E
These two connections form two virtual links, which are used for the
fgODUflex(p) connection.
- Conn#3: fgODUflex(p), A-C-E
From the OTN node point of view (only describe one connection
direction for simplicity. The other connection direction is exactly
the same):
- Node A multiplexes the fgODUflex(p) into an ODUj(fgTS) or
ODUflex(fgTS,n), which are further multiplexed into ODUk.
- Node B and D perform the cross-connect for the ODUj(fgTS) or
ODUflex(fgTS,n), without being awareness of the fgODUflex(p)
inside.
- Node C demultiplexes the Conn#1 signal from the ODUk,
demultiplexes the fgODUflex(p) from the Conn#1, perform
fgODUflex(p) cross-connect, and multiplexes the fgODUflex(p) into
Conn#2 and then into ODUk.
- Node E demultiplexes the Conn#2 signal from the ODUk, and further
demultiplexes the fgODUflex(p) from the Conn#2.
Lin, et al. Expires September 2024 [Page 6]
Internet-Draft GMPLS fgOTN Applicability March 2024
2.3. fgOTN Use Cases
2.3.1. Point-to-Point (P2P) Private Line Service
One of the motivations of fgOTN is to provide an alternative to
carry sub-1G private line services. Figure 3 below shows an example
of reference network model for multi-domain fgOTN private line
service (also see Annex A of G.709.20 [G709.20]).
In this example, there are one backbone OTN domain, two Metro OTN
domains and two fgOTN CPEs in the network. The Metro OTN networks
support both fgODUflex and ODUk switching. At the boundary nodes
(e.g., metro core nodes) of the metro OTN domains, the fgODUflexes
to other metro OTN networks are multiplexed into ODUk of backbone
networks. Therefore, the backbone OTN nodes could only support ODUk
switching.
***********************
* *
+------* Backbone OTN (ODUk) * -----+
| * * |
| *********************** |
Metro A | | Metro B
***************** *****************
* +-----+-----+ * * +-----+-----+ *
* | fgOTN | * * | fgOTN | *
* | core | * * | core | *
* +-----+-----+ * * +-----+-----+ *
* | * * | *
* +-----+-----+ * * +-----+-----+ *
* | fgOTN | * Metro OTN * | fgOTN | *
* |aggregation| * (fgOTN & ODUk) * |aggregation| *
* +-----+-----+ * * +-----+-----+ *
* | * * | *
* +-----+-----+ * * +-----+-----+ *
* | fgOTN | * * | fgOTN | *
* | access | * * | access | *
* +-----+-----+ * * +-----+-----+ *
***************** *****************
| |
+-----+-----+ +-----+-----+
| fgOTN | | fgOTN |
| CPE | Customer network | CPE |
+-----------+ +-----------+
Figure 3: Example of fgOTN-based private line (from [G709.20])
Lin, et al. Expires September 2024 [Page 7]
Internet-Draft GMPLS fgOTN Applicability March 2024
2.3.2. Multi-Point-to-Multi-Point (MP2MP) Cloud Access
Cloud applications are becoming widely deployed in enterprises and
vertical industries. Organizations with multiple campuses are
interconnected together with the remote cloud Data Centers (DCs) for
storage and computing. Such cloud services demand that the
underlying network provides Multi-Point-to-Multi-Point connectivity
with high quality of experience, such as high availability, low
latency, and on-demand bandwidth adjustments. fgOTN, as a TDM-based
technology, can be used to meet such requirements. This could be
seen as an MP2MP private network service.
[F5G-UC] provides several use cases on how OTN is used for multi
cloud access, including enterprise private line connectivity to
multiple clouds and premium home broadband connectivity to multiple
clouds.
[opt2cloud] also provides similar multi cloud access use cases, and
further provides the problem statement and control plane technical
gap analysis on using fgOTN for multi cloud access. See Figure 4
below and see more detail description in [opt2cloud].
__________ ________
/ \ / \
| Enterprise | ___________ | Vertical |
| CPE |\ / \ +-----+ /| Cloud |
\__________/ \ +---+/ \+---+ |Cloud|/ \________/
\|O-A* *O-E|----+ GW |
+---+ +---+ +-----+
________ | OTN | _______
/ \ +---+ +---+ +-----+ / \
| Vertical |----+O-A* *O-E|----+Cloud|---| Private |
| CPE | +---+\ /+---+ | GW | | Cloud |
\________/ \___________/ +-----+ \_______/
Figure 4: Multi-cloud access through an OTN (from [opt2cloud])
3. General fgOTN Control Consideration
3.1. Signal Type
[G709-E6.5] introduces new signal types including fgODUflex,
ODUj(fgTS) (j=0,1,2) and ODUflex(fgTS,n).
The fgOTN control plane needs to support these fgOTN related signal
types.
Lin, et al. Expires September 2024 [Page 8]
Internet-Draft GMPLS fgOTN Applicability March 2024
3.2. fgOTN Label
In a control plane for a TDM network, labels are used to indicate
the tributary slots in a link which are used by a connection.
In [FRC7139], the ODU label for ODUj into ODUk multiplexing is
defined. There are at most 80 tributary slots in an ODUk (i.e., ODU4
link).
In [G709-E6.5], the bit rate of the tributary slot (10 Mbit/s) is
much smaller than before (1.25 Gbit/s), therefore the total number
of fgOTN tributary slots will be much larger. There are 119*n
(1<=n<=8) tributary slots in an ODUj(fgTS) or ODUflex(fgTS,n) (952
tributary slots in maximum).
An fgODUflex(p) occupies p (1<=p<=119) tributary slots of the
ODUj(fgTS) or ODUflex(fgTS,n).
New fgOTN label needs to be designed to support the maximum number
of tributary slots.
4. fgOTN Connection Control Consideration
4.1. Connection Hierarchy
As described in Section 2 of this document, two-stage multiplexing
may happen when creating an fgODUflex connections (e.g., fgODUflex
into ODUflex(fgTS,n) and then into ODUk multiplexing). The fgOTN
control plane needs to support the control of the multi-stage
multiplexing.
4.2. Hitless Resizing
[RFC7139] supports the control of hitless resizing of ODUflex.
[G709-E6.5] defines the data plane procedure to support fgODUflex
hitless resizing. The support of control of hitless resizing of
fgODUflex needs to be further considered.
Lin, et al. Expires September 2024 [Page 9]
Internet-Draft GMPLS fgOTN Applicability March 2024
4.3. Scalability Consideration
fgOTN support much finer granularity of ODU connections. Therefore,
the number of ODU connections will be significantly increased.
For example, there could be up to 952 (119*8) fgOTN connections
within a single ODU2 link. As a comparison, there are at most 8 ODU0
connections within an ODU2 link and 80 ODU0 connections within an
ODU4 link in a traditional OTN network.
Therefore, the scalability and the performance of fgOTN connection
control need to be considered. Specifically, when an ODU link fails,
there may be thousands of fgOTN connections which are affected by
the failure and need to be rerouted at the same time. Even in such
case, the performance of fgOTN connection restoration still needs to
be guaranteed.
If the General Communication Channel (GCC) overhead bytes are used
as the Data Communication Network (DCN) of the OTN, the DCN
bandwidth may become the bottleneck when transmitting thousands of
rerouting signaling messages at the same time.
Further analysis on the scalability of using RSVP-TE for fgOTN
connection control is needed.
5. fgOTN Service Control Consideration
Section 2.3.2 of this document describes the scenarios where fgOTN
is used for multi-cloud access services. In such scenarios, multiple
fgODUflex connections will be created for a customer, to form an
MP2MP private network interconnecting multiple customer's branches
and multiple cloud DCs.
Since an OTN edge node may have multiple fgOTN connections connected
to different destinations for a customer, the OTN edge node needs to
support identification of customer's service flows, and support
mapping different service flows (with different destination
addresses) into corresponding fgOTN connections. This requires the
OTN edge nodes to be able to:
- Collect the client side (including the customer side and the cloud
side) service address information;
- Generate the service mapping rules;
- Identify the service identification information (e.g., source and
destination IP or MAC addresses) from the packet headers of the
received service flow;
Lin, et al. Expires September 2024 [Page 10]
Internet-Draft GMPLS fgOTN Applicability March 2024
- Mapping the received service flow into corresponding fgOTN
connections, according to the generated service mapping rules.
Service packets
+-----+---+
|Ser-A| |
+-----+---+
+-----+---+ fgOTN domain +-----+---+
|Ser-B| | *************** |Ser-A| |
+-----+ +-----+---+ +---*+ Conn-1 +*---+ +-----+---+ +---------+
| C-1 |-------------|OE1*|===========|*OE3|-------------| Cloud-A |
+-----+ ------> +---*+===== +*---+ ------> +---------+
* = *
* = *
+-----+ +---*+ = +*---+ ------> +---------+
| C-2 |-------------|OE2*| =======|*OE4|-------------| Cloud-B |
+-----+ +---*+ Conn-2 +*---+ +-----+---+ +---------+
*************** |Ser-B| |
+-----+---+
Figure 5: Example of multi-cloud access service
Figure 5 shows an example on multi-cloud access service. In this
example, an fgOTN-based private network service is provisioned, with
multiple fgOTN connections interconnecting customer's branches (C-1
and C-2) and two cloud DCs (Cloud-A and Cloud-B). When the OTN Edge
node OE1 receives the service flow packets with service
identifications (e.g., the destination addresses) Ser-A and Ser-B,
OE1 needs to map the service packets identified as "Ser-A" into
fgOTN connection #1, and map the service packets identified as "Ser-
B" into fgOTN connection #2. In this way, the service flow can be
transmitted to the correct destination cloud DCs.
New protocol in the control plane is needed for the OTN edge nodes,
so that they can know which fgOTN connections can be selected to
transmit a certain service flow.
Note that traditional OTN with 1.25 Gbit/s or 2.5 Gbit/s tributary
slots can also be used in this scenario.
[opt2cloud] provides more detail description on how the service
address information is learned, and how the service flows are mapped
to the fgOTN connections.
[PCE-fg] further provides the extension to the PCEP to support the
service address learning and service flow mapping.
Lin, et al. Expires September 2024 [Page 11]
Internet-Draft GMPLS fgOTN Applicability March 2024
6. fgOTN Routing Consideration
6.1. fgOTN Resource Distribution
[RFC7138] defines the routing protocol for the traditional OTN with
1.25 Gbit/s and 2.5 Gbit/s tributary slot types.
[G709-E6.5] introduces new type of ODU tributary slot, i.e., the
fine grain tributary slot with a bit rate of approximately 10
Mbit/s.
The fgOTN control plane routing protocols need to support the
discovery and distribution of fgOTN node and link resource
information and capability information, including:
- support of fine grain tributary slot, as well as the fine grain
tributary slot resource information;
- fgODUflex multiplexing capabilities;
- fgODUflex switching capabilities.
6.2. Scalability Consideration
The typical scenarios for fgOTN is to provide low bit rate private
line or private network services for more customers. This implies
that the OTN network will cover a larger scope of networks, which
may include the backbone network, metro core, metro aggregation,
metro access, and even the OTN CPE in the customers' networks.
Routing protocols such as OSPF-TE and ISIS-TE use flooding
mechanisms to distribute the routing information. The route
convergence time may increase when if the scale of the network
becomes larger. Therefore, the scalability of the fgOTN routing
protocols needs to be considered, which is for further study.
7. fgOTN Link Management Consideration
For further study.
8. Manageability Considerations
For further study.
Lin, et al. Expires September 2024 [Page 12]
Internet-Draft GMPLS fgOTN Applicability March 2024
9. Security Considerations
For further study.
10. IANA Considerations
This document requires no IANA actions.
11. References
11.1. Normative References
None.
11.2. Informative References
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC7138] Ceccarelli, D., Ed., Zhang, F., Belotti, S., Rao, R., and
J. Drake, "Traffic Engineering Extensions to OSPF for
GMPLS Control of Evolving G.709 Optical Transport
Networks", RFC 7138, March 2014.
[RFC7139] Zhang, F., Ed., Zhang, G., Belotti, S., Ceccarelli, D.,
and K. Pithewan, "GMPLS Signaling Extensions for Control
of Evolving G.709 Optical Transport Networks", RFC 7139,
March 2014.
[G709-E6.5] ITU-T, "Interfaces for the optical transport network",
G.709 E6.5 (2023).
[G709.20] ITU-T, "Overview of fine grain OTN", G.709.20 (2023).
[F5G-UC] ETSI GR F5G 008 (V1.1.1), "Fifth Generation Fixed Network
(F5G); F5G Use Cases Release #2", 2022.06.
[opt2cloud] S. Liu, H. Zhang, A. Guo, Y. Zhao, and D. King, "draft-
liu-ccamp-optical2cloud-problem-statement".
[PCE-fg] L. Han, H. Zheng, M. Wang, and Y. Zhao, "draft-han-pce-
path-computation-fg-transport".
Lin, et al. Expires September 2024 [Page 13]
Internet-Draft GMPLS fgOTN Applicability March 2024
12. Authors' Addresses
Yi Lin
Huawei France
Marco Polo A2, 790 Avenue Maurice Donat
Mougins France
Email: yi.lin@huawei.com
Liuyan Han
China Mobile
No.32 Xuanwumen west street
Beijing, 100053
China
Email: hanliuyan@chinamobile.com
Yang Zhao
China Mobile
No.32 Xuanwumen west street
Beijing, 100053
China
Email: zhaoyangyj@chinamobile.com
Raul Munoz
Centre Tecnologic de Telecomunicacions de Catalunya (CTTC)
Av. Carl Friedrich Gauss, 7 - Building B4
08860 - Castelldefels, Spain
Email: raul.munoz@cttc.es
Lin, et al. Expires September 2024 [Page 14]