This eight-page technical brief synthesizes the attached University of Florence theses and presentations. It explains how Snap4City is connected to Data Space ecosystems through Node-RED and the FIWARE Data Space Connector (DSC), with a specific focus on the path toward a Mobility Data Space deployment.

The integration turns Snap4City into a Data Space participant that can play both roles: as a Provider, it publishes selected urban and mobility data under explicit usage policies; as a Consumer, it discovers, negotiates and retrieves data exposed by other participants and can reinject those data into the Snap4City knowledge base.

The bridge is deliberately split into two responsibilities. Node-RED handles data movement and transformation between Snap4City and the connector, while the FIWARE DSC handles federation-level functions: identity, authorization, catalog publication, contract negotiation and controlled data transfer.

Snap4City  ⇄  Node-RED IoT-APP  ⇄  FIWARE DSC  ⇄  Mobility Data Space

1. Integration architecture

Snap4City is connected to external Data Spaces through a connector-based boundary, not by exposing its internal platform directly.

At the platform side, Snap4City retains its existing data management, dashboards and Orion-based knowledge base. A Node-RED IoT-APP provides the adaptation layer. At the federation side, the FIWARE DSC provides the standardized Data Space interfaces and the trust, catalog, policy, negotiation and transfer functions required to interact with other participants.

Figure 1 - General integration architecture from the source presentation. The Mobility DataSpace is shown as one of the external Data Space targets reachable through the FIWARE DSC. Original labels are retained from the source.

The architectural boundary is important for data sovereignty. Snap4City does not give a Data Space direct access to its internal repositories. Instead, selected data are copied or exposed through the connector, catalogued as assets, associated with policies and transferred only after the Data Space interaction sequence has been completed.

Responsibility	Component	Role in the integration
Smart-city data and services	Snap4City	Produces and consumes urban/mobility information; stores integrated results.
Data adaptation	Node-RED IoT-APP	Retrieves, reformats and routes data in both directions.
Federation boundary	FIWARE DSC	Implements identity, policy enforcement, catalog, negotiation and transfer.
External ecosystem	Mobility Data Space	Target federation in which independent participants exchange governed mobility data.

2. Data bridge: Node-RED and context brokers

The Node-RED flows are the practical adapter that makes Snap4City data usable by the connector and makes negotiated Data Space data usable by Snap4City.

For the Snap4City → DSC direction, the flow starts from a Snap4City service-information node, retrieves a selected observation, converts the payload into JSON-LD and submits it through HTTP to Scorpio, the NGSI-LD context broker inside the connector. The example test uses PeopleCounter entities as mobility-oriented data.

For the DSC → Snap4City direction, Node-RED performs the inverse adaptation after a transfer has been negotiated. It prepares the HTTP headers, retrieves the transferred NGSI-LD entities from the protected endpoint, splits an array into individual entities, reformats them and writes them into Snap4City through the FIWARE Orion output node.

Figure 2 - Bidirectional Node-RED flows used to move data between Snap4City and the FIWARE DSC. The upper flow publishes data to the connector; the lower flow reinjects consumed data into Snap4City.

Operational detail observed in the prototype

The DSC → Snap4City flow requires the negotiated data endpoint and a valid access token. In the prototype these values were manually updated because the endpoint is generated for the completed negotiation and the token is time-limited..

 

3. FIWARE Data Space Connector: trust, policy and protocol layers

The DSC isolates Snap4City from federation complexity and exposes standards-based interfaces toward other connectors.

Four functional layers Authentication: VCVerifier, Credentials Config Service, Trusted Issuers List and Keycloak implement decentralized identity based on DIDs and Verifiable Credentials. In M2M use, the Consumer presents a signed Verifiable Presentation and obtains a JWT access token. Authorization: Apache APISIX acts as the Policy Enforcement Point; OPA evaluates authorization rules; ODRL-PAP stores ODRL policies and translates them into Rego for runtime evaluation. Control Plane: TMForum APIs model Catalog, Category, Product Specification and Product Offering entities. FDSC-EDC implements the DataSpace Protocol for catalog discovery, contract negotiation and transfer-process coordination. Data Plane: Scorpio stores NGSI-LD data. The EDC dataplane provisions controlled HTTP-based access after the contract and transfer process have been established.

Figure 3 - Layered FIWARE DSC architecture (source presentation, p. 5).

Why this matters for Mobility Data Space participation

The connector means that Snap4City can keep its existing internal data model and services while presenting a Data Space-compliant external behavior. Trust is verified through credentials, access is checked through explicit policies, and the resource lifecycle is represented through standardized catalog and contract semantics.

4. Publishing Snap4City mobility data as a Data Space asset

Publishing is more than copying data: the resource must be described, governed and made discoverable before another participant can negotiate access.

The validation starts by bringing selected Snap4City data into the Provider connector through the Node-RED flow. Scorpio stores the observations as NGSI-LD entities. The prototype uses PeopleCounter entities with a peopleDetected property and an observedAt timestamp; values were randomly generated to emulate mobility observations for testing.

Step	Provider-side action	Data Space effect
1	Insert Snap4City data into Scorpio	Creates the protected NGSI-LD data resource.
2	Create TMForum Category and Catalog	Defines the logical catalog structure.
3	Create Product Specification	Describes endpoint, format, target NGSI-LD collection and credential configuration.
4	Create Product Offering with ODRL policy	Attaches contract/access conditions and turns the resource into a negotiable offer.

Figure 4 - Publication validation. The catalog response exposes a test mobility dataset (ASSET-MobilityDataTest) with an ODRL read policy and an HTTP distribution.

The connector maps the provider-side TMForum representation into the Data Space vocabulary used by the protocol. In the thesis, the TMForum Catalog maps to a DCAT Catalog; the Product Specification supplies the Dataset/Distribution information; and the Product Offering becomes the ODRL Offer attached to the dataset. This mapping is what makes a Snap4City-originated resource discoverable and negotiable by an independent Data Space connector.

5. Discovery, contract negotiation and controlled transfer

Once published, access follows the DataSpace Protocol rather than a direct platform-to-platform API call.

 

Figure 5 - The three DataSpace Protocol phases: catalog, negotiation and transfer.

End-to-end sequence 1. Discovery - The Consumer sends a catalog request to the Provider and receives DCAT-described datasets and their ODRL offers. 2. Negotiation - The Consumer selects the desired dataset/policy and starts the contract-negotiation state machine. The successful result is an Agreement. 3. Transfer setup - The Consumer requests transfer according to the Agreement. The Provider provisions the protected route and the Consumer obtains an Endpoint Data Reference (EDR). 4. Data access - The Consumer obtains the required access token by presenting Verifiable Credentials to the Provider VCVerifier, then calls the protected NGSI-LD endpoint. 5. Reintegration - Node-RED can retrieve the authorized entities from the connector and insert them into Snap4City.

Sovereignty is enforced at runtime

A direct request without the authorization token returns an authorization error in the validation. APISIX checks the request and token, OPA evaluates the applicable policy, and only compliant requests are forwarded to the protected data service. In this way, the Provider retains control even after the dataset is visible in the catalog.

6. End-to-end validation

The laboratory test reproduces Provider/Consumer behavior and demonstrates the data lifecycle from Snap4City publication to authorized consumption.

Figure 6 - Negotiation/transfer validation and protected NGSI-LD data retrieval. The sample response contains PeopleCounter entities used as mobility-oriented test data.

For validation, two separate FDSC-EDC instances were deployed with different identities, one acting as Provider and the other as Consumer. This reproduces the protocol interaction between distinct participants while keeping the calls inside the Kubernetes test environment. The Provider first publishes the Snap4City-derived dataset; the Consumer then discovers the offer, negotiates it, starts the transfer process, acquires the required credentials/token and finally retrieves the data.

Validated capability	Evidence in the attached work	Implication
Bidirectional integration	Node-RED flows move data Snap4City→DSC and DSC→Snap4City.	Snap4City can act as Provider and Consumer.
Protocol interoperability	Catalog, negotiation and transfer are executed through DSP/FDSC-EDC.	Other conformant connectors can interact without Snap4City-specific APIs.
Policy-controlled access	ODRL policy, VC-based token and 401 response without authorization.	Provider sovereignty is preserved at access time.
Current constraints	FDSC-EDC 1.1.0 lacks manual counter-offer negotiation; dataplane is HTTP-Pull only.	Production federation requires further maturation/automation.

7. Path to a real Mobility Data Space deployment

The source material demonstrates the connector pattern and identifies federation with a populated Mobility DataSpace as the next natural validation step.

The practical result of the work is a reusable participation node: Snap4City supplies the smart-city data and applications, Node-RED provides platform adaptation, and the FIWARE DSC provides the federation contract. This separation is well suited to mobility ecosystems because datasets can be published with standardized metadata, explicit usage policies and verifiable participant identities while Snap4City remains the system that manages and exploits the data locally.

Readiness assessment from the attached documents

Technically, the main integration mechanisms are implemented and tested: data adaptation, NGSI-LD persistence, catalog publication, ODRL policy handling, decentralized identity, negotiation, transfer and controlled access.

Next step	Recommended focus	Expected outcome
1. Automate the bridge	Automatically inject negotiated endpoint/EDR and refreshed access tokens into Node-RED flows; generate flows per asset.	Removes manual prototype steps and supports repeatable operations.
2. Federate with Mobility Data Space	Test with real participant identities, heterogeneous catalogs, policies and remote connectors.	Validates interoperability in a multi-organization environment.
3. Broaden mobility assets	Move beyond the random PeopleCounter demonstration to real Snap4City mobility datasets and multiple NGSI-LD entity types.	Demonstrates domain value, not only protocol correctness.
4. Extend transfer/negotiation	Adopt additional transfer modes and manual/counter-offer negotiation when supported by the FIWARE components.	Improves flexibility and alignment with production governance needs.

Conclusion

The integration is best understood as a governed gateway between a mature smart-city platform and a federated data-sharing ecosystem. Snap4City remains responsible for collecting, managing, visualizing and exploiting urban data; the FIWARE DSC makes selected resources discoverable and exchangeable under Data Space rules; and Node-RED translates the two operational worlds. The attached validation shows that this architecture can preserve data sovereignty while enabling interoperable mobility-data sharing.