DLT Architectures for Trust Anchors in 6G

Abstract

This manuscript investigates viable Distributed Ledger Technology (DLT) architecture approaches to be used as basis for the distribution of integrity verification data. We discuss what can be a Trust Anchor and how the property of trust can be enabled as a service for mobile communications infrastructures. This follows up on a preceding publication, in the course of which a service was developed that can be utilized to create trust and traceability in transactions between other services. Crucial for the integrity of such an audit trail is proof for which side was committing, in case a tampering was detected. For such verification in the aftermath, mechanisms for the distribution of meta data are necessary. Where our ultimate goal is to develop a versatile framework for Trust as a Service (TaaS), the work at hand contributes the investigation on header distribution. We put a major focus on providing Trust as a Service (TaaS) especially in the mobile communications domain since a reliable concept for trustworthiness is indispensable for the vision of organic infrastructures beyond 5G, which means that such networks are flexible regarding their composition and open for stakeholders. Preprint.

Full text

DLT Architectures for Trust Anchors in 6G
Dennis Krummacker1,∗, Benedikt Veith2,∗, Daniel Lindenschmitt3,†and Hans D. Schotten4,∗†
∗German Research Center for Artificial Intelligence GmbH, DFKI. D-67663 Kaiserslautern.
†Institute for Wireless Communication and Navigation. University of Kaiserslautern. D-67663 Kaiserslautern.
1dennis.krummacker@dfki.de,2benedikt.veith@dfki.de,3lindenschmitt@eit.uni-kl.de,
4hans_dieter.schotten@dfki.de,schotten@eit.uni-kl.de
Abstract
This manuscript investigates viable Distributed Ledger Technology (DLT) architecture approaches to be used as basis for
the distribution of integrity verification data. We discuss what can be a Trust Anchor and how the property of trust can be
enabled as a service for mobile communications infrastructures. This follows up on a preceding publication, in the course
of which a service was developed that can be utilized to create trust and traceability in transactions between other services.
Crucial for the integrity of such an audit trail is proof for which side was committing, in case a tampering was detected.
For such verification in the aftermath, mechanisms for the distribution of meta data are necessary. Where our ultimate
goal is to develop a versatile framework for Trust as a Service (TaaS), the work at hand contributes the investigation on
header distribution. We put a major focus on providing Trust as a Service (TaaS) especially in the mobile communications
domain since a reliable concept for trustworthiness is indispensable for the vision of organic infrastructures beyond 5G,
which means that such networks are flexible regarding their composition and open for stakeholders.
Preprint.
Keywords— DLT, 5G, 6G, Trustworthiness, Trust as a Service
1 Introduction
Some of the major enhancements of mobile communica-
tions beyond 5G do grant worthwhile capabilities but do
also inflict new challenges as they impose risks to certain
areas previously not an issue there. The idea of Organic
Infrastructures [1]–[5] can present a great deal regarding
flexibility, universal applicability and future-oriented evolu-
tion.
Part of this vision is that the functional diversity of 6G in-
frastructures is not limited to the collection provided right
with commissioning or restricted to shipment by the ded-
icated manufacturer of one comprehensive overall system.
Instead, expansions can come at any time from anyone; at
least technically. But with granting the technical capability
for everyone to contribute to a system, the question arises
who shall be allowed to do so; or put differently, who can
be trusted. Because then intentionally malicious intrusion
is easily possible. To avoid this, tools for permission man-
agement are vital in order to control which stakeholder is
allowed to perform which actions.
Similar for the availability of data throughout a network.
Re-thinking the architecture of future mobile communica-
tions infrastructures and its dedicated parts (Core, Radio
Access Network (RAN)) can aid measuring and exchang-
ing information more efficiently [6]. But again, a certain
degree of control over such extensive features is required.
Special confidential information might be worth protecting.
Or in general, inserting and fetching of data should not be
randomly allowed to anyone.
The common issue is Trustworthiness. Who can be trusted
– their intention, or even qualification. For that purpose, the
authors of the present manuscript consider it to be conve-
nient having trust provided through an infrastructure as a
service for utilization by functionalities running within.
The work at hand follows up on the previous work pub-
lished with the IEEE as [7]. This presented a twofold result
as it proposed a solution for a trustworthy and verifiable co-
existent spectrum allocation mechanism between disjoint in-
frastructures. A novel service (Spectrum Allocation & Shar-
ing Function (SASF)) alongside additionally required tools
were introduced that enable Core-to-Core (CtC) communi-
cation between independent 6G systems and that utilize this
to perform a negotiation, which eventuates in sharing spec-
trum inside a common coverage area. Such a mechanism
– that is, the negotiation’s result as well as the subsequent
operation – has to be unalterably traceable. Both parties
have to trust each other that they proceed as agreed.
For this purpose, the second part introduced another service
based on Distributed Ledger Technology (DLT) for granting
trust. This so-called Trust & Traceability Function (TTF)
was developed as a Core service that can be employed by
other services to create trust in their operation. This was
finally designed together so that the two SASFs interact
over their respective TTFs through which the negotiation
and its result is logged. Afterwards in the active operation
phase, the factually utilized spectrum is logged as well. In
the end, this enables a trustworthy analysis of the entire
transaction, which can ultimately be used, for instance, to
issue an invoice.
The current manuscript further elaborates on the topic of
trustworthiness. The ultimate goal is to have an universal
solution as a modular system component that is capable of
granting trust in various types of operations. This can be
for example regarding the trust in a stakeholder of a service,
the trustworthiness of polled data, trust in a requested trans-

action or a component accessing others. To have common
means for different objectives is of high significance in or-
der to allow a proper standardization, which in turn is of
paramount importance for such a crucial concern as trust.
This can be achieved by having an instance that is known
to be trustworthy, from which trust in other elements can be
granted through a proper coordination protocol. Trustwor-
thiness is a delicate property that can only be adjudicated
to some entity by an origin distinct from the target for trust-
worthiness. The genesis of initial trust within a collective,
its maintenance and propagation are key. Trust can propa-
gate hierarchically, where the root is some first entity that is
assumed or certified to be trustworthy and that declares or
denies trustworthiness for the lower entities. Or the initial
trust arises from a consensus procedure within a collective.
The abstraction of any entity, a device, software or mecha-
nism, from which the trust originates initially before being
propagated as a service, can be referred to as Trust Anchor.
As one step towards a viable Trust Anchor for an universal
trustworthiness framework, the work at hand investigates
different architecture approaches for such a trust enabling
service via DLT.
2 Related Work
No concept for a service, which could enable a secured CtC
communication between two or more cores of one or more
operators is available in the 5G mobile communications
standard. One of the reasons therefor is that solutions and
systems in 5G are still very static e.g. in respect to their ge-
ographical location. With the upcoming concept of private
mobile networks in the 5G standard, new fields of applica-
tion are introduced. One of these fields is the idea to have
spatially dynamic networks, which are able to roam in order
to fulfill their demands e.g. in an agricultural surrounding.
On the new path of scientific research to a standardized 6G
also this category of private mobile networks, which can be
referred to as nomadic, should be investigated. It is hence
necessary to analyze new requirements for communication
between distinct mobile networks.
To be able to establish a reliable and secure communication
across all participating private mobile networks, one of the
major tasks for CtC communication is that all aligned par-
ties have to be unalterably traceable and trust each other to
only behave as agreed. A first solution for that was intro-
duced in [7]. The work at hand now focuses on different
approaches to enable a trusted infrastructure by using DLT
e.g. blockchain concepts. As a concept for achieving trust
in mobile 5G and Beyond 5G (B5G) networks, [8] identified
different trust dimensions like applications or communica-
tion, which need to be considered by a trust management
system. Security measures need to establish and maintain
every of those dimensions. The authors sum up, that with
blockchain or trusted platforms, new issues will come up,
by which it is necessary to achieve a balance between a cer-
tain trust level in a network and the costs to achieve it. In
[9], prominent trust approaches were analyzed. Addition-
ally, a pre-standardization approach for trust and reputation
models for 6G networks is suggested. Four modules for
accomplishing key actions in trust models and fulfilling the
requirements and KPIs by using new technologies are intro-
duced.
The authors of [10] investigated into security and privacy
issues of future 6G networks and uncovered issues related
to new technologies. To establish TaaS in upcoming 6G mo-
bile networks, challenges and opportunities are discussed in
[11]. By reviewing the usage of blockchain in combination
with future technologies, an outlined number of possible
solutions was defined. It is assumed, that blockchain will
support the growth of 6G and is able to face security threats.
As in [8], the authors of [11] too addressed the necessary
balance of security and performance in future 6G networks.
In [12], blockchain technologies are also explored in the
setting of future 6G wireless networks. The authors inves-
tigated the increasing attention on data security especially
for AI applications. Their simulation results have shown
that blockchain could enable resistance against tampering
of data in a mobile network. As in [12], the utilization of
DLTs in 6G networks was also discussed in [13]. The au-
thors identified emerging directions by using blockchain in
6G. One of those are Trust-based Secure Networks, which
shall enable trust, security and privacy in future mobile net-
works through privacy compliance and access control. Also
the application of AI methods like federated learning could
be used for enabling trusted infrastructures.
3 Preceding Work
The previously published work [7] discussed three areas:
CtC communication, the newly introduced core service
SASF for co-existent spectrum allocation and the newly in-
troduced core service TTF for creating trust in the
SASF’s
transactions. In the following a brief digest is provided.
Simplified, the scenario is that one full infrastructure
(called licensee) has spectrum licensed in a coverage area.
Another full infrastructure (called applicant) approaches
spatially and initiates a negotiation about getting spectrum
granted for operation.
3.1 Architecture
Figure 1 5G Service Based Architecture (SBA) Functions. The SASFs
interact across the distinct cores (Figure 1). All such communication
flows through the related TTF.
The SASF contains the logic behind controlling the whole
procedure. This requests spectrum from the other core, re-

solves a decision for a request and collaborates with the lo-
cal Radio Resource Management (RRM) to either acquire
spectrum for sharing, restrict the own utilized range or con-
figures to operate in the granted frequency area.
So the applicant’s RRM would be configured to request a
certain amount of radio resources from the connected SASF.
The latter performs the negotiation and afterwards grants
the RRM spectrum and capacity according to the result.
During operation, requests for radio resources arrive at the
licensee’s SASF. In this system, a decision has to be made
how much resources and what spectrum precisely can be
dispensed.
The TTF is responsible for creating trustworthiness in the
negotiation and the achieved agreement, but also the mea-
surements during operation. It internally implements a DLT-
based storage mechanic to immutably store data. During
negotiation, the SASF sends its messages to or receives
them from the TTF, which forwards them in respectively
opposing direction while concurrently logging. During suc-
ceeding operation, DLT is utilized to store the measurement
values.
As common, internally within one core, all functions com-
municate via a REST-API. As far as this level is concerned,
it is sufficient for functioning to insert the two new core
functions, including their specified API and they are able
to exchange information according to a simple application
level protocol representing the access methods – until the
CtC communication becomes involved.
3.2
Novel Functions & Required Capabili-
ties
Looking deeper into the system, changes on several points
are required to enable a mechanism as striven for. Mostly
because dedicated CtC communication is not envisaged in
current systems. Nonetheless is such an interaction indis-
pensable, since involved operations for proposed function-
alities are clearly a management plane task and are thus
proposed to be integrated as core function, whereas the des-
ignated usage scenario tackles to have fully independent
infrastructures coexisting (depicted in Figure 2).
This leads to the areas that need to be touched in addition
to solely implementing the novel core functions. The first
obstacle is that a nomadic network in the very first instance
requires a physical interconnection with the stationary net-
work to enable a fundamental reachability. For this, evi-
dently a radio link is desired. Already the physical condi-
tions for this link – like establishing first contact – are not
trivial to solve and on top a protocol is necessary that allows
to exchange messages dedicated to CtC communication.
Means for such a communication is yet to be elaborated
in more detail in future work, as the previously published
work focused on the DLT technology to create the trustwor-
thiness. Hence, this manuscript refers to it as “Nx interface”
as a placeholder. Depending on how it will exactly be im-
plemented, this Nx can have logical contact points with N1,
N2, Next Generation Application Protocol (NGAP) and of
course how the 5G gNodeB Basestation (gNB) operates the
radio link. Possible solution strategies are also discussed in
a later Section of the preceding publication.
Candidates are Protocol-regarding implications on Xn
Application Protocol (XnAP) or extending the Self-
Backhauling mechanism that is already in use for direct
over the air communication between base stations albeit be-
ing actually only applicable within one network operator
and with one core. The Xn interface describes a logical
point-to-point link between two NG-RAN nodes in 3GPP
5G networks (3GPP TS 38.420). It provides the infrastruc-
ture for the XnAP (3GPP TS 38.423) and enables Control
Plane functions for User Equipment (UE) mobility manage-
ment, dual connectivity or resource coordination, as well as
User Plane functions for data transfer or fast retransmission.
Nx
Core
SASF TTF
gNB Core
TTF SASF
Licensee
(stationary)
Applicant
(mobile)
Figure 2 Direct radio connection between independent networks for
Core-to-Core communication
The second obstacle is then the logical communication,
which goes further than only introducing a protocol to use
over the Nx interface. The key topic here is that messages
have to be transported from one core function to another
inside a distinct core, which consequently transit over the
RAN. When sticking to 5G’s system architecture, various
elements in sequence would be involved in such a commu-
nication. Hence, the protocols involved between such el-
ements (i.e. NGAP) and the interface specifications (i.e.
N2) have to be extended for carrying required informa-
tion. Equally the elements themselves (Access and Mobility
Management Function (AMF), gNB) require modifications
to their logic to parse respective messages correctly.
3.3 Logical & Physical Communication
Communication from inside the core to outside is not part
of the 5G design. The only other component a core talks
to is the RAN. And for this, one singular message gate
exists: The AMF, which connects to the base station over
the N2 interface. We expect that this is the appropriate
point to add the novel CtC capability in. CtC messages
would then tunnel through the AMF, go over the N2 and
are transmitted over the air between base stations. As said,
transmitting messages over such sequence is not part of the
current core design. Actually, the AMF is responsible for
(simplified spoken) handling tasks regarding UE connection
and similarly, over N2, configuration data is handed to the
RAN regarding operating the radio communication.
But the idea to use the AMF as a forwarding gateway is not
totally alien. On N2 as the reference point between the base
station and the core, the NGAP is in use to support both
UE and non UE related services and to create a decoupling
between AMF and other services talking beyond it. For this
purpose, NGAP supports information that the AMF is just
responsible to relay (which is for instance done between the
5G-AN and the SMF).

One major challenge is to first establish a physical con-
nection between two independent mobile communications
networks. Though private networks are defined in 5G, the
communication between two or more cores respectively two
or more RANs of distinct full infrastructures is not part of
the standard. 6G needs to provide a solution for this exist-
ing gap to enable the functionality of spectrum sharing or
spectrum licensing between different operators within the
coverage of a local network. The most crucial obstacle here
is that an initial radio connection means already utilizing
spectrum, which will only be the object of the following ne-
gotiation about whether the applicant is granted permission
to use it.
More detail on the issue as well as 5G Private Networks is
provide within the preceding publication [7].
4
Trust & Traceability Function
(TTF)
The TTF provides the service of establishing traceable and
verifiable communication links to the core of a peer net-
work, as well as a trusted logging facility. Its current design
is intended to integrate into the context of the SBA in B5G
cores. The endpoints of a link within a session share a com-
mon view of a ledger instance, where the trail of exchanged
data is stored in a tamper-proof manner. The majority of
the described mechanisms originate from existing DLTs,
whereas a set of adaptions need to be considered in order
to apply DLT specific features to the application field of
CtC communication in 6G networks. The most influential
adaption comes from the fact that the communication link
usually is set up between two points instead of distributing
the ledger to an arbitrarily sized set of network participants.
For this case, no consensus algorithm for decentralized peer-
to-peer networks is deployed, but rather a protocol for es-
tablishing a measurement of trust between two entities is
discussed. The architecture discussed in this section is pri-
marily aimed to support a CtC scenario, which maps to a
collaborative negotiation process as described in [7]. Core
internal logging applications as in Phase 2) depict a special
case, where no peer is present.
We describe a ledger as a state machine, where the updated
state depends on newly issued transactions and the previous
state. The following terms are based on the notation used
in the Ethereum Yellow Paper [14]:
σi+1=Π(σi,Bi+1)
A state is denoted by
σ
.
B
depicts a Block, which contains
one or several transactions and
Π
describes the state transi-
tion function. This kind of describing a ledger allows for
defining complex business logic, which can be executed on
top of the block storage, as it is used for example on the
Ethereum Blockchain. However, the application of using
the ledger as an audit trail can be seen as a special case
with a simple, transparent state transition function, i.e. the
ledger state directly describes the accumulation of all sub-
mitted transactions. While the requirements of such kinds
of applications already can be met by transaction based DLT
without a dedicated state defined by additional application
logic, the concept is nonetheless introduced at this point in
order to ensure compatibility for further application fields.
For example to enable the implementation of application
logic within the TTF for the execution of Smart Contracts,
like they are described for example in [15]. This way, for
instance, it would be possible to likewise record and attest
the logic of a service as opposed to merely its result.
4.1 Architecture
Figure 3 Functional elements of the Trust & Traceability Function
The internal architecture of the TTF, which is discussed in
this section, is depicted in Figure 3. The TTF requires two
kinds of externally accessible interfaces. The Service API
exposes the services necessary for the submission of mes-
sages to an active session and retrieving the current state of
the ledger. Core functions consuming the service submit a
session by sending a payload along with metadata necessary
for addressing the session and the respective service within
a session. The TTF then initiates a procedure to append the
payload to the ledger. The Transport API provides the log-
ical link to the peer network via the respective forwarding
mechanisms of the AMF and the RAN.
The highest management layer within the TTF, the Ledger
Management, is responsible for the instantiation and ad-
dressing of different Audit Sessions. Active Audit Sessions
are described by Ledger Instances, whereas the message
trail of terminated sessions is stored and retrievable on de-
mand. When a new session is established, the Ledger Man-
agement communicates with the peer TTF to build a Gene-
sis Block, which describes the initial state of the session.
A particular Ledger Instance is administrated by a State
Management Layer. It maintains a logical link to the State
Management of the respective session within the peer TTF
and orchestrates state transitions resulting from newly is-
sued transactions on the ledger. It furthermore checks the
signatures included in message payloads for validity and
applies read and write permissions.
Within a Ledger Instance, the State Management accesses
modules describing the current state of the session, in partic-
ular a TX queue, a state instance and application protocols.
The TX queue holds newly issued transactions to the ledger
with pending consensus status, which means the TTF is
waiting for a response from the peer with the consent to
append the transaction to the ledger. The application proto-
cols process submitted transactions and compute a resulting
ledger state. This means, the application protocols define

the state transition function of the ledger. The state instance
depicts the storage of all previously appended blocks as
well as the current version of the ledger state.
Since the information written to the ledger does not orig-
inate from the TTF itself, but rather comes from arbi-
trary core functions consuming the service (in our case the
SASF), the framework requires a measure to verify the iden-
tity of transaction authors. This can be provided by using
digital signatures, i.e. via ECDSA [16]. By requiring ev-
ery transaction author to add a digital signature to the pay-
load, the system ensures non-repudiation (an author can not
deny having created a signature before) and data integrity
on transaction level (manipulations of the payload result in
an invalid signature).
4.2 Procedures
On establishing a new session, both peers need to exchange
information to build a Genesis Block. It depicts the first
entry on the common ledger and is the starting point of
the consensus between the peers. It contains information
necessary for maintaining consensus on future ledger en-
tries. Since the block needs to match on both sides of the
communication link, a protocol for its format is required
beforehand, for example the following order:
• Metadata from the requesting peer
• Metadata from the responding peer
• Settings and protocol metadata for the ledger
Peer related metadata include public keys from authors on
the respective side of the link, which can also be used as
account identifiers of the authors on the ledger, and the
session ID corresponding to the ledger instance on each
peer, respectively. The settings section also may include
information on which application protocols are used in the
session.
After the setup of a ledger instance, new blocks are ap-
pended to the ledger when a core function sends a respec-
tive request containing the signed payload to the TTF (here:
P1, for on Peer-1). Via the session ID, the ledger manage-
ment forwards the payload to the ledger instance, where the
state transition is calculated by the application protocols,
resulting in a block to be appended to the ledger. The block
contains the signed transaction(s) and a header with at least
the following information:
•
The hash over the previous block on the ledger (Block
Hash): This builds a hash chain over all submitted blocks,
so any manipulation on a block would require to manipu-
late all succeeding blocks on the ledger.
•
A hash over each transaction (TX Hash): Can be used to
verify the inclusion of a transaction into a block, without
having to access the whole block, i.e. other transactions
in the same block.
•
A value identifying the state resulting from the applica-
tion of transactions (State Root): In DLT, this can be
implemented by using a Merkle Patricia Tree for storing
the state, where a hash tree structure is built upon all
storage items, resulting in a single root hash, which com-
pletely describes the sum of all storage items [14]. In the
TTF, the application protocols would set storage items in
the state according to newly issued transactions and the
root hash of the Merkle Patricia Tree would be included
in the block header.
After the state transition is calculated, the transactions are
stored at the TX queue and sent to the peer TTF (here: P2,
for on Peer-2) in a Block Inclusion Request, along with the
metadata from the new block header. Using the Block Hash,
P2 validates that P1 is building on top of the same view of
the ledger, i.e. the previous block matches on each side.
By computing the state transition via the local application
protocols and comparing the State Root, P2 validates that
the ledger state matches the new state, calculated at P1. On
success, P2 appends the block to its ledger instance and
sends a Successful Outcome Response to P1, which then
also appends the block to the ledger.
This procedure also allows to handle the special case of
concurrent Inclusion Requests, where both sides nearly si-
multaneously send Block Inclusion Requests to each other.
This situation is detected at each side when it receives a
Block Inclusion Request before receiving a response to its
own request. For this case, the order in which transactions
from both peers are applied to the ledger state must be de-
fined by a protocol beforehand. The procedure is then ter-
minated by an additional message roundtrip to ensure the
accumulative state transition of all new transactions is valid
to both peers.
The application built on top of the services of the TTF not
only relies on submitting data to the ledger, but also on
reading information from it, especially in the use case of
building a traceable communication medium, i.e. for ra-
dio resource allocation negotiations. In the proposed frame-
work, we identify three ways of retrieving information from
a ledger instance, provided that the respective read access
is granted:
•
Block Query: The client retrieves one or several blocks
from the ledger instance
•
State Query: The client queries storage items from the
current state of the ledger instance
•
Application Protocol API: Depending on the read ac-
cess to the state, application protocols also might expose
an API to retrieve an application-specific pre-processed
view on the ledger state
4.3
Communication Audit Trail as Main
Application Protocol
As stated earlier, the application of using the ledger as a
common storage for the exchange of information depicts a
special case for the use of the TTF. The use case of spec-
trum allocation discussed in this work is an example hereof
since the application logic mainly takes place at the level of
SASF instances, using the TTF only as a transport layer for
exchanged information. The application protocol used in
the ledger instance therefore fulfills the task of storing the
list of transactions directly in the state, which can then be
queried by the SASF, where they are interpreted within the
spectrum allocation context.

5
Architecture Approaches for
Trust Anchors
The archiving of terminated sessions in the TTFs is crucial
for establishing trust, because it allows peers to compare
both views on the ledger in the aftermath and detect tam-
pering of the audit trail. However, this procedure alone
does not provide a proof of which side has manipulated the
data. For this purpose, a framework for the distribution of
block headers to third parties is required. The distribution
or publishing needs to take place at a point in time where
both peers maintain consensus on the ledger, i.e. at nominal
operation. This provides mechanisms for future verification
to detect on which side the data has been manipulated, with-
out having to share confidential data written to the ledger.
The third party should depict a facility which all actors trust
to be neutral like a regulative authority or alternatively a
distributed ledger maintained by a sufficiently high number
of independent actors.
5.1 Ledger Manipulations
For an intentional collusion, involved parties would indeed
be able to manipulate the Ledger. If this manipulation is
done after the headers have been published, the manipula-
tion can be detected. But there is no guarantee anymore
that it can be rolled back since both peers have modified
their Ledger instance. A mutual manipulation happening
before the headers are published cannot be detected. How-
ever, both parties making agreements on the Ledger would
bypass its actual purpose of building trust, where in this
case the trust has already been established.
5.2 Header Distribution Architecture
In the following section, the third party, collecting the
header data from TTFs, is abstracted by the term Trust
Anchor, independent from the technology implementing
it. This discussion provides an expansion of the preceding
work in [7].
The Trust Anchor is responsible for maintaining only data
necessary for the verification of the consensus between
TTFs on a Ledger. It is expected to hold a verifiable consis-
tency over time, while the private data (transactions, state)
is still stored at the TTFs locally. This separation of the
Trust Anchor architecture from the private domain of TTFs
allows it to remain open and transparent. This makes it
less complex to include mechanisms for verification and
resilience, since the access to the data stored at the Trust
Anchor does not need to be restricted or regulated.
The verification data that is uploaded to the Trust Anchor
describes a checkpoint for the latest verifiable consensus
between TTFs, so it should also be possible to update it
over time. When the Trust Anchor receives data from TTFs,
it needs to verify that the data indeed describes a consen-
sus between peers. This can be done either by both peers
submitting the same set of data to the Trust Anchor indepen-
dently, or by uploading a version of the data which has been
signed by both TTFs. The former approach does not rely on
a digital signature algorithm, as the second approach does,
but it requires the Trust Anchor to buffer the data received
by one peer and wait for the submission of the exact same
data from the other peer, doubling the network load.
Multiple approaches can be compared regarding the inter-
face between the TTFs and the Trust Anchor. In all of
the cases, the information transmitted to the Trust Anchor
should be usable for verifying the consistency of a Ledger
Instance on both peers. In a first option, all header data
from every block of a Ledger can be transmitted to the
Trust Anchor. This procedure could be integrated into the
consensus procedure between TTFs, when a new block is
appended, but leads to a high network load and increased
storage demands for the Trust Anchor. On the other hand,
the existence of a particular block in the Ledger can be ver-
ified directly in any case. A second approach would be to
only transmit header data of specific blocks. This procedure
needs to be initiated asynchronously by one of the peers and
reduces network load and storage requirements alike. The
blocks of which header data are transmitted can be con-
sidered checkpoints of the Ledger, since the header data
of a particular block includes dependencies on all previous
blocks. To verify the existence of a block in the Ledger with
this approach, information from all blocks between the one
to be verified and the next checkpoint is necessary.
Regarding the architectural design of the Trust Anchor it-
self, several approaches are possible and may be combined
in some ways. The approaches discussed in the following
consider two different branches of technology, i.e., DLT
and Verifiable Databases.
DLT represents a set of technologies, where multiple in-
dependently acting entities maintain consensus on a com-
mon set of data, with its most prominent form being the
Blockchain. This property in combination with the vari-
ous required technologies like hashing, cryptography or dis-
tributed consensus algorithms ensures resiliency and non-
repudiation by design. A survey on several DLT directions
and implementations is carried out in [17].
A Verifiable Database or Verifiable Ledger, according to
[18], maintains an append-only storage, where data records
can be added but not modified or deleted on the lowest level.
It also provides the means for clients to computationally
verify that a queried record has not been tampered with and
that the overall storage of the database remains consistent.
Standard Centralized Database: For the perspective of
a single country, a standard database (SQL, NoSQL) might
be deployed by a regulative authority. In this case, the trust
purely originates from societal acknowledgment and legis-
lation. By strongly regulating the external access to data,
privacy is preserved by the architecture itself, which might
allow to associate further metadata with pure verification
data and open up new possibilities of centralized data pro-
cessing. This option requires the least resources regard-
ing the overall storage footprint. On the other hand, there
are only limited ways to validate the correct behavior of
the Trust Anchor. Limited trust in regulative authorities of
other countries in the geopolitical context might affect the
trustworthiness of the overall system in the case of roaming.
Verifiable Centralized Ledgers: By deploying a Verifi-
able Ledger on a regional basis instead of a private database,
trust is detached from an authority since it relies on the

transparency of the Trust Anchor and the exposed verifi-
cation mechanisms. Any institution with the necessary re-
sources may provide such a Ledger. An approach to auto-
mate and globalize the consistency verification of all Veri-
fiable Ledgers can be to deploy a Distributed Ledger with
all Logs and additional monitoring entities (Auditors) as
nodes. Logs may submit their root hashes to this Ledger
periodically, which are then used by Auditors to validate
the consistency of the Logs. This option and the first one,
i.e. all in essence centralized approaches, have in common
that additional measures for the rollback of detected manip-
ulations of the Ledgers have to be taken, e.g. continuous
independent backups need to be maintained for resiliency.
Global Distributed Ledger: In a fully decentralized ap-
proach, all TTFs may additionally run nodes of a single
Distributed Ledger, which provides the global Trust An-
chor storage for header validation. This approach is archi-
tecturally simple and a new TTF may easily be added to
the public Trust Anchor network. This Global Distributed
Ledger also can provide reputation mechanisms between
TTFs, e.g. via the provision of Smart Contracts. One disad-
vantage of such a global solution is clearly the large amount
of data that must be processed and stored at each node par-
ticipating in the network.
Cascaded Distributed Ledgers: A possibility to tackle
the scalability issues of big public DLT networks as de-
scribed in the previous part can be the cascading of smaller
Distributed Ledgers by linking them via a global relay chain.
This means that a local group of TTFs runs a Distributed
Ledger as local Trust Anchor. The set of local Trust Anchor
networks is then connected to an additional Blockchain net-
work via specific nodes, which provides a globally validated
overall state. A prominent example of such a Blockchain
of Blockchains is the Polkadot network [19]. This archi-
tecture approach requires a complex consensus procedure
to track the correct behavior of the nodes, which link the
local Ledgers to the relay chain. The separation into mul-
tiple local Distributed Ledgers enables the local networks
for independent implementations and updates, as long as
the interface towards the relay chain matches the standard
protocol.
5.3 Trusted Infrastructure
The discussions on the infrastructure carried out in this
work focused on the establishment of a trustworthy consen-
sus between two independent network infrastructures. The
verifiable operation of the trust building framework how-
ever can also be exposed to third party applications, thereby
propagating the trustworthiness of the underlying architec-
ture to external modules, e.g. for verifiable accountability.
This leads to the concept of TaaS provided by the infras-
tructure operator to third party applications running on top
of the 6G network. Here not the infrastructure is the entity
seeking trustworthiness but the established basis for others,
i.e. acts as Trust Anchor for devices and applications that
utilize it.
The fundamental idea, i.e. the hierarchical concept behind
the feature from [7] and a Trusted Infrastructure are very
similar, whereas the major difference is that the root of the
tree is represented by a different element. Or differently put,
when combining both scenarios, the initial trustworthiness
originates on a different level. The authors believe that a
proper framework can serve both scenarios equally, which
is object for upcoming development.
6 Conclusion and Outlook
The preceding publication [7] introduced a mechanism to
enable multiple 6G infrastructures to coexist in a shared fre-
quency range with respect to licensing issues as it proposed
core functions for negotiating and logging the coexistent
operation. Major focus was put on being able to trust in
historic logging data because the frequency occupation as-
pect is a question of licensing and hence a legal issue. The
most in-depth focus was afforded to a core function, which
enables trustworthiness using DLT. Mainly missing was a
procedure for the distribution of the raised meta data. The
manuscript at hand thus investigated on viable architecture
approaches for Trust Anchors for the purpose of verification
of audit trail integrity.
The ultimate goal of our endeavors is a versatile frame-
work that can be utilized in various use-cases, even to en-
able slightly distinct scenarios in conjunction as briefly ad-
dressed in Section 5.3. Intended future work hence cov-
ers to further elaborate a header distribution mechanism,
a more thorough concept for a Trust Anchor and finally a
comprehensive implementation of the developed tools into
a framework that can be rolled-out as a modular service into
networks.
The authors acknowledge the financial support by the
German Federal Ministry for Education and Research
(BMBF) within the project »Open6GHub« {16KISK003K
& 16KISK004}. A related manuscript was priorly pub-
lished with the IEEE as [7].
References
[1]
R. Bless, B. Bloessl, M. Hollick, et al., “Dynamic network
(re-)
configuration across time, scope, and structure,” English, in
2022 Joint European Conference on Networks and Communi-
cations & 6G Summit (EuCNC/6G Summit), (Grenoble, France,
Jun. 7–10, 2022), IEEE, IEEE Xplore, Jun. 2022, pp. 547–552.
[2]
D. Krummacker, C. Fischer, Y. Munoz, and H. D. Schotten, “Or-
ganic & Dynamic Infrastructure: Getting ready for 6G,” English,
in Mobile Communication-Technologies and Applications; 26th
ITG-Symposium, (Osnabrück, May 18–19, 2022), ser. ITG, VDE,
vol. 304, IEEE Xplore, VDE, May 2022.
[3]
M. Corici, E. Troudt, P. Chakraborty, and T. Magedanz, “An Ultra-
Flexible Software Architecture Concept for 6G Core Networks,”
English, in 2021 IEEE 4th 5G World Forum (5GWF), (Osnabrück,
May 18–19, 2022), ser. ITG, VDE, vol. 304, IEEE Xplore, VDE,
May 2021, pp. 400–405. DOI:
10 . 1109 / 5GWF52925 . 2021 .
00077.
[4]
D. Krummacker and H. D. Schotten, “Status-preserving, Seam-
less Relocation of Processes in Orchestrated Networks such as Or-
ganic 6G,” English, in 2022 IEEE 5th International Conference
on Industrial Cyber-Physical Systems (ICPS), (Warwick, Coven-
try, United Kingdom, May 24–26, 2020), ser. ITG, IEEE, vol. 304,
IEEE Xplore, May 2022, pp. 1–8. D OI:
10.1109/ICPS51978.
2022.9816860.

[5]
M. Corici, E. Troudt, T. Magedanz, and H. Schotten, “Organic
6G Networks: Decomplexification of Software-based Core Net-
works,” English, in 2022 Joint European Conference on Networks
and Communications & 6G Summit (EuCNC/6G Summit), (Os-
nabrück, May 18–19, 2022), ser. ITG, IEEE, vol. 304, IEEE Xplore,
VDE, May 2022, pp. 541–546.
[6]
D. Krummacker, C. Fischer, B. Veith, and H. D. Schotten, “6G
Core-Architecture – Approaches for Enhancing Flexibility across
Control and User Plane,” English, in Mobile Communication-
Technologies and Applications; 26th ITG-Symposium, (Osnabrück,
May 18–19, 2022), ser. ITG, VDE, vol. 304, IEEE Xplore, VDE,
May 2022.
[7]
D. Krummacker, B. Veith, D. Lindenschmitt, and H. D. Schotten,
“Radio Resource Sharing in 6G Private Networks: Trustworthy
Spectrum Allocation for Coexistence through DLT as Core Func-
tion,” English, in 2022 1st International Conference on 6G Net-
working (6GNet), (Paris, France, Jul. 6–8, 2022), ser. ITG, IEEE,
vol. 304, IEEE Xplore, May 2022, pp. 1–8. DOI:
10 . 1109 /
6GNet54646.2022.9830407.
[8]
C. Benzaïd, T. Taleb, and M. Z. Farooqi, “Trust in 5G and Beyond
Networks,” English, IEEE Network, ITG, vol. 35, no. 3, pp. 212–
222, May 2021. DOI:10.1109/MNET.011.2000508.
[9]
J. M. Jorquera Valero, P. M. Sánchez Sánchez, M. Gil Pérez, et al.,
“Toward pre-standardization of reputation-based trust models be-
yond 5G,” English, Computer Standards & Interfaces, ITG, vol. 81,
pp. 1–8, May 2022. DOI:
https://doi.org/10.1016/j.csi.
2021.103596.
[10]
M. Wang, T. Zhu, T. Zhang, et al., “Security and privacy in 6G net-
works: New areas and new challenges,” English, Digital Communi-
cations and Networks, ITG, vol. 6, no. 3, pp. 281–291, May 2020.
DOI:https://doi.org/10.1016/j.dcan.2020.07.003.
[11]
T. Nguyen, N. Tran, L. Loven, et al., “Privacy-Aware Blockchain
Innovation for 6G: Challenges and Opportunities,” English, in 2020
2nd 6G Wireless Summit (6G SUMMIT), (Paris, France, Jul. 6–8,
2022), ser. ITG, IEEE, vol. 304, IEEE Xplore, May 2020, pp. 1–5.
DOI:10.1109/6GSUMMIT49458.2020.9083832.
[12]
W. Li, Z. Su, R. Li, et al., “Blockchain-Based Data Security for Ar-
tificial Intelligence Applications in 6G Networks,” English, IEEE
Network, ITG, vol. 34, no. 6, pp. 31–37, May 2020. D O I:
10.1109/
MNET.021.1900629.
[13]
A. Kalla, C. De Alwis, G. Gur, et al., “Emerging Directions for
Blockchainized 6G,” English, IEEE Consumer Electronics Maga-
zine, ITG, vol. 304, pp. 1–8, May 2022. D O I:
10.1109/MCE.2022.
3164530.
[14]
G. Wood, Ethereum: A secure decentralised generalised trans-
action ledger, Berlin Version b8ffc51 - 2022-02-21, English,
Accessed: 2022-02-25, IEEE, May 2022. DOI:
10 . 1109 /
6GNet54646.2022.9830407.
[15]
M. Alharby and A. van Moorsel, “Blockchain Based Smart Con-
tracts : A Systematic Mapping Study,” English, in 2022 1st Inter-
national Conference on 6G Networking (6GNet), (Paris, France,
Jul. 6–8, 2022), ser. ITG, IEEE, vol. 304, IEEE Xplore, Aug. 2017,
pp. 125–140. D O I:10.5121/csit.2017.71011.
[16]
M. Al-Zubaidie, Z. Zhang, and J. Zhang, “Efficient and secure
ECDSA algorithm and its applications: A survey,” English, Interna-
tional Journal of Communication Networks and Information Secu-
rity, ITG, vol. 11, pp. 1–8, Jan. 2019. DOI:
10.1109/6GNet54646.
2022.9830407.
[17]
C. Antal, T. Cioara, I. Anghel, et al., “Distributed Ledger Technol-
ogy Review and Decentralized Applications Development Guide-
lines,” English, Future Internet, ITG, vol. 13, no. 3, pp. 1–8, May
2021. DO I :
10.3390 /fi13030062
. [Online]. Available:
https:
//www.mdpi.com/1999-5903/13/3/62.
[18]
M. Zhang, Z. Xie, C. Yue, and Z. Zhong, “Spitz,” English, Pro-
ceedings of the VLDB Endowment, ITG, vol. 13, no. 12, pp. 3449–
3460, Aug. 2020. DOI:
10.14778/3415478.3415567
. [Online].
Available: https://doi.org/10.14778.
[19]
G. Wood, Technology | Polkadot, English, Online, IEEE, May 2022.
DOI:
10.1109 / 6GNet54646 . 2022 . 9830407
. [Online]. Avail-
able:
https://polkadot.network/technology/
(visited on
08/18/2022).