The architecture for the SEAL data delivery enabler is based on the generic functional model specified in clause 6.2 of TS 23.434. This clause provides the overall architecture description:

• Clause 7.2 describes the functional architecture;
• Clause 7.3 describes the functional entities;
• Clause 7.4 describes the reference points; and
• Clause 7.5 describes the cardinality of functional entities and reference points.

This clause describes the architecture for enabling SEAL Data Delivery applications in the following representations:

• A service-based representation as specified in TS 23.434, where the SEAL Data Delivery Enabler Layer functions (e.g. SEALDD server) enable other authorized Vertical Application Layer functions (e.g. VAL server) to access their services.
• A service-based representation as specified in TS 23.501, where the Network Functions (e.g. NEF) enable authorized SEAL Data Delivery Layer functions (e.g. SEALDD server) i.e. Application Functions, to access their services;
• A service-based representation, where the Core Network Northbound APIs as specified in TS 23.501 and TS 23.502, are utilized by authorized SEAL Data Delivery Enabler Layer functions via CAPIF core function specified in TS 23.222; and
• A reference point representation, where existing interactions between any two functions (e.g. SEALDD client and SEALDD server) is shown by an appropriate point-to-point reference point (e.g. SEALDD-UU).

SEAL Data Delivery Enabler Layer functions shown in the service-based representation of the SEAL Data Delivery architecture shall only use service-based interfaces for their interactions. The service based representation of SEAL Data Delivery function in the overall SEAL service-based representation is specified in clause 15 of TS 23.434. The SEALDD function exhibits service-based interfaces which are used for providing and consuming SEALDD services. The service-based interface for SEALDD function is representation as Sdd. Figure 7.2-1 illustrates the service-based representation for utilization of the 5GS network services based on the 5GS SBA specified in TS 23.501.

The SEALDD server acts as AF for consuming network services from the 3GPP 5G Core Network entities over the Service Based Architecture specified in TS 23.501. Figure 7.2-2 illustrates the service-based representation for utilization of the Core Network (5GC, EPC) northbound APIs via CAPIF.

The SEALDD server acts as authorized API invoker to consume services from the Core Network (5GC, EPC) northbound API entities like SCEF, NEF, SCEF+NEF which act as API Exposing Function as specified in TS 23.222. The mechanism for northbound APIs discovery using the service-based interfaces depicted in Figure 7.2-3 is as specified in TS 23.222. Figure 7.2-3 illustrates the architecture for SEAL Data Delivery enabler service.

The SEALDD server can communicate with the control plane of 3GPP core network via N33/N5 interface with the SEALDD control plane functionality. The SEALDD server may consume other SEAL (e.g. NRM) services. For uplink traffic, VAL client sends application data traffic to SEALDD client for SEALDD service over SEALDD-C. After data plane packet processing by SEALDD client, the application data traffic is converted to SEALDD data traffic and transferred to SEALDD server over SEALDD-UU. The SEALDD server restores the application data traffic and sends it to VAL server over SEALDD-S. For downlink traffic, VAL server sends application data traffic to SEALDD server for SEALDD service over SEALDD-S. After data plane packet processing by SEALDD server, the application data traffic is converted to SEALDD data traffic and transferred to SEALDD client over SEALDD-UU. The SEALDD client restores the application data traffic and sends it to VAL client over SEALDD-C. Optionally, VAL deployments may choose to route application signalling traffic and application data traffic for some or all functions it offers using SEALDD service and Figure 7.2-4 illustrates the architecture for achieving this. In this case the VAL client and VAL server may choose not to maintain application connection by themselves and transfer all the application traffic over SEALDD connections for those functions. The data storage functionality may be provided by SEALDD server or provided by other storage functions in VAL server, or other cloud platform. To facilitate the specific optimization for XR application provided by 5G network, the application enablement architecture for the XRApp service is based on the generic functional model specified in TS 23.434.

The SEAL Data Delivery client interacts with the SEAL data delivery server to establish application layer data transport path. Through this path, the SEALDD server and client provides data transport service capabilities such as data plane packet processing (e.g. packet duplication, elimination or transport coordination), data forwarding, data caching, background data transfer, etc. to support the VAL server and VAL client. Annex C describes a typical lifecycle of SEALDD to establish the SEALDD connection for the VAL client and VAL server. Figure 7.2-5 illustrates the architecture for SEAL Data Delivery enabler service used to support UE-to-UE communication.

VAL UE 1 and VAL UE 2 have on-network connectivity, and both VAL UEs can directly communication with each other via off-network connectivity (i.e. SEALDD-PC5 reference point) or via on-nework connectivity (i.e. SEALDD-UU reference point). Multi-modal services are based on several data flows related to each other and subject to application coordination. The data flows can transfer different types of data (for example audio, video, positioning, haptic data) and may come from different sources(e.g. a single UE, a single device or multiple devices connected to the single UE, or multiple UEs). Figure 7.2-6 illustrates XR multi-modal services using two different XR Servers. To support E2E multi-modal communication flows between multiple VAL clients and servers, a SEALDD server and clients may support multi-modal service capabilities. The SEALDD server and clients perform multi-modal traffic transfer and management processing (e.g., E2E synchronization of application traffic having multi-modal dependencies with one another).

To support the Tethered device, there are two types of Application enablement architectures based on SEALDD and PINAPP, corresponding to two types of tethered devices. One is the tethered XR device, where XR application client is deployed on the tethered XR device, i.e., Tethered Standalone AR Glasses, and Tethered AR Glasses with 5G Relay. The other is the Tethered Display XR device, who deploys the XR application on the 5G client, with only the XR runtime residing on the tethered UE. For the tethered XR device, the application enablement layer architecture is shown in the Figure 7.2-7. The SEALDD client on the 3GPP UE, acting as PIN client, could get tethered device information from the PEMC using the PIN-3 interface. Then the SEALDD client could interact with XR client on the tethered device to do the tethered link measurement. The interaction between the SEALDD client and XR client on different device is conducted over SEALDD-C.

For the Tethered Display XR device, the application enablement layer architecture is shown in the Figure 7.2-8. The SEALDD client on the 3GPP UE, acting as PIN client, could get tethered device information from the PEMC using the PIN-3 interface. The SEALDD-UUc interface supports the interaction between the SEALDD client on the tethered UE and SEALDD client on the 3GPP UE.